fabernovel loader

Nov 15, 2017 | 5 min de lecture

Tech

Comment coderons-nous demain ?

comment coderont nous demain ?
comment coderont nous demain ?

Antoine Michel

CTO


FABERNOVEL TECHNOLOGIES
Comment coderons-nous demain ? En tirant les leçons du passé et en cherchant à conjuguer le meilleur des deux mondes. Le développement applicatif a réussi le tour de force de rester en rythme avec les marchés et l'économie, les usages et les exigences des utilisateurs. Personne n'aurait parié dessus il y a vingt ans, quand il fallait des mois pour opérer le moindre changement. Mais avec la vélocité, voilà que le SI a pu y perdre en cohérence. Pour retrouver l'unité, les applications de demain devront réintroduire une dose de cette centralisation, si décriée.

Une brève histoire du code

Avec un spectre fonctionnel si large que l’on n’en voyait pas l’horizon, nos logiciels et systèmes d’information en entreprises, d’un autre temps, semblaient être conçus pour rivaliser en démesure avec les dolmens et les menhirs cathares. Peut-être les ingénieurs gardaient-ils, enfoui, le désir inconscient d’élever à la gloire de dieux numériques les autels témoins d’une nouvelle religion… Une forme de mégalithisme informatique en quelque sorte.
Plus sérieusement, l’usage (l’absence de réponse technique différente et la prévalence du mainframe) voulait que l’on concentre un nombre important de fonctionnalités et d’aspects métier au sein d’une même application (un CRM par exemple). On en gérait la complexité par la componentization*, le découpage d’applications de type librairie ou software, embarqués avec des appels locaux à des fonctionnalités.
Mais, souvenons-nous, avec des systèmes de cette nature, plusieurs inconvénients se sont présentés. Le plus visible était évidemment les cas d’échecs ou de panne, entraînant l’indisponibilité de pans entiers du système d’information (cf. La théorie fumeuse des oeufs dans le même panier). Au même degré de crispation arrivaient les besoins d’évolution, même réduits, quasiment impossibles à opérer dans le cadre d’un couplage aussi fort et local sans affecter une large portion du système (l’effet papillon appliqué au SI).
D’autres phénomènes sont apparus. La prédictibilité d’impact est passée à une telle complexité qu’elle s’en est rendue anxiogène. La technologie, coercitive, forçait les entreprises à développer avec les outils de l’éditeur en place, pour répondre à des problématiques très différentes, avec un moindre choix mais certainement pas à moindre coût. Enfin, il était très difficile de pouvoir extraire les morceaux utiles de ces applications pour en créer de nouvelles.

Haro sur la centralisation

Autant dire que les développements d’aujourd’hui n’ont plus rien à voir avec ceux d’hier. Le grand enjeu du développement des applications est sans aucun doute la rapidité de création de valeur fonctionnelle, de surcroît avec un investissement minimum dans la résolution de problématiques techniques. Aux antipodes, donc, des méthodes traditionnelles.
Avec les progrès technologiques, on a pu décentraliser à tout va, en déployant d’abord des ensembles de fonctionnalités métiers réunis sous une même gouvernance et un même cycle de vie. Et, pour offrir à chaque product owner la plus grande autonomie sur les évolutions qu’il souhaite donner à son application, ses choix technologiques et ses déploiements (dont le rythme), chaque aspect métier fut isolé des autres.
C’est un découpage fonctionnel (au sens métier) qui demande une certaine habileté, le périmètre devant vivre indépendamment tout en étant suffisamment petit pour supporter, au besoin, une réécriture complète du code en un court laps de temps.
Outre une résolution facilitée et rapide des problèmes techniques et une autonomie de développement et de déploiement, le grand avantage est d’autoriser toute application à consommer rapidement et sans contrainte de nouveaux services (content management, asset management…) Quand la componentization embarquée exigeait de procéder à la mise à jour d’un nouveau service au niveau de toutes les applications l’utilisant, la distribution permet de ne pas avoir à gérer cette complexité au niveau des apps consommatrices.
Brique après brique, le système s’enrichit, avec simplicité pour ses utilisateurs, qu’ils soient collaborateurs de l’entreprise, clients ou partenaires. Voici en quelques lignes, et très schématiquement, à quoi ressemble une application d’entreprise aujourd’hui. Un monde idéal ? Pas encore. La décentralisation pose de nouvelles problématiques, auxquelles il est indispensable de songer dès que l’on aborde les systèmes distribués.
Imaginons un conseiller bancaire, lequel gère au quotidien de multiples produits, chacun présenté dans une application différente (avec son cycle de vie propre). Ce conseiller peut avoir besoin d’une vue générale de l’ensemble de ses produits, pour x raisons, qui se présenteront très rapidement.

Retour à une centralisation d’affichage

Pour l’utilisateur, la centralisation reste une nécessité. Le nouvel enjeu dès lors est de travailler sur les propriétés d’intégration de ces entités séparées, de façon à ce qu’elles apparaissent comme ne formant qu’un tout aux yeux des utilisateurs. Pour interroger globalement ces applications autonomes, celles-ci doivent partager certains traits. Historiquement, elles partageaient la machine, puis le protocole. Aujourd’hui, elles partagent le vocabulaire. C’est une sémantique, extrêmement fonctionnelle, basée sur les métiers des utilisateurs.
Le système d’information entre alors dans sa phase de standardisation, définissant des ensembles de vocabulaires, communs ou localisés dans des applications. Le couplage est opéré par des systèmes transverses de services plus techniques (autorisation, identification…). Enfin, vient s’ajouter une solution d’API management dont le rôle est de permettre à chaque application de s’enregistrer dans le SI.
Une fois les applications centralisées, il faut pouvoir savoir ce qu’elles font. Non seulement une application exécute un service métier, mais elle doit aussi être capable de le décrire pour que le SI, intelligent, sache faire appel à elle. C’est ainsi qu’à une même demande, la réponse sera différente (enrichie en général) au fur et à mesure que les services du SI augmentent. Avec une sémantique fonctionnelle partagée, on ne contraint plus le SI par la technique et les protocoles, mais par le métier, qui présente l’avantage d’être très stable (un relevé de compte sera toujours un relevé de compte).
Bref, une application demain portera un périmètre métier, accompli par un ensemble de services indépendants les uns des autres, et interrogés de façon fonctionnelle.

Les pré-requis les plus élémentaires

Si la décentralisation est devenue la norme, FABERNOVEL TECHNOLOGIES s’intéresse en outre à la recentralisation apparente du SI pour apporter aux utilisateurs la cohérence nécessaire à l’exécution de leurs missions et la simplicité de consommation des informations.
L’expérience montre que la principale difficulté reste de définir correctement les frontières d’une application ou d’un périmètre fonctionnel. Un sur-découpage risque de créer des liens trop forts, conduisant au pire des deux mondes, un monolithe distribué ! Il y a donc une réflexion amont indispensable à conduire sur l’architecture du système, en adoptant une démarche raisonnée.
Par ailleurs, cela va sans dire, une entreprise bien lancée dans le développement d’applications le fait de façon industrialisée, afin de garder le contrôle sur sa production applicative et notamment sur ses coûts de déploiement. Certes l’investissement initial n’est pas négligeable, mais il est la garantie de sa liberté, et de l’évolutivité et l’extensibilité de ses plateformes. Des qualités qui ont trop longtemps fait défaut et bridé la croissance.

* Modularisation

Prenez contact avec FABERNOVEL TECHNOLOGIES pout tous vos projets d'architecture technique !

Contactez-nous !
logo business unit

FABERNOVEL TECHNOLOGIES

150 talents pour répondre aux défis technologiques de la transformation digitale.

à lire