Développement de plateformes avec le Reverse et le Forward Engineering
Construction nouvelle, remplacement ou les deux à la fois : la situation de départ décide de l’approche avec laquelle une plateforme voit le jour. Ce qui distingue le Reverse du Forward Engineering, et comment nous les combinons dans nos projets.
Dans le développement de plateformes, il existe trois situations de départ typiques. Le projet greenfield, qui peut être pensé de A à Z. Le remplacement d’un logiciel existant sur une nouvelle base technologique. Et la forme mixte : un remplacement qui intègre en même temps des améliorations. Selon le point de départ d’un projet, différentes approches d’ingénierie entrent en jeu.
Qu’est-ce que le Reverse Engineering ?
Avec le Reverse Engineering, vous analysez un système existant dans le but de le comprendre : sa conception, sa structure et son comportement. Selon la situation, on recourt à l’analyse de code, à des désassembleurs ou à des décompilateurs, mais plus souvent simplement à la reconstitution du modèle de données, des interfaces et de la logique d’utilisation.
Le résultat varie :
- une documentation du système existant : un diagramme UML, un organigramme ou une spécification ;
- un système reconstruit sur une nouvelle technologie, qui remplit les mêmes exigences que l’ancien.
L’approche convient aussi à des étapes intermédiaires : dépister des erreurs, juger la qualité d’un logiciel existant, évaluer la compatibilité avec d’autres systèmes.
Qu’est-ce que le Forward Engineering ?
Avec le Forward Engineering, un logiciel est créé de A à Z. Le système est conçu et réalisé à partir d’exigences et de spécifications. Auparavant, ces exigences doivent être détaillées, les liens et les complexités rendus visibles et les cas particuliers définis. Au fond, il s’agit de traduire des processus métier, des services et des fonctions en une application. On n’analyse pas de code existant, on en écrit du nouveau.
En terrain vierge, les idées peuvent être testées rapidement sous forme de prototype. En revanche, il faut généralement plus de temps pour que les exigences et les conditions réelles soient arrêtées. Avec le Reverse Engineering, l’ancien système les fournit.
Comment nous procédons dans les projets
Les deux approches font partie de notre quotidien, souvent dans le même projet. Là où nous utilisons le Reverse Engineering, nous intégrons des améliorations et des extensions dans la même étape, pour que la dette technique ne suive pas. S’y ajoutent des ateliers : nous apprenons à connaître en détail les processus de notre clientèle et décidons ensemble où une numérisation apporte vraiment quelque chose.
Suisse Rando
Lors de la refonte du site web et de la plateforme en 2023, les deux approches sont entrées en jeu. Nous avons analysé l’ancien CMS et la saisie des randonnées, puis reproduit leur fonctionnement dans le nouveau système. La saisie des contenus, en revanche, nous ne l’avons pas reprise : nous l’avons remplacée par un nouveau fonctionnement et étendue. D’autres éléments (l’attribution de tags aux pages de contenu, la gestion des médias) ont été créés à neuf sans analyse préalable. Les détails figurent dans la success story sur la plateforme dédiée à la randonnée.
OPAN CARE
Pour la plateforme e-santé d’OPAN CARE AG, il s’agissait d’une mise à jour technologique : une nouvelle base technique, avec en plus de nouvelles fonctions et de nouveaux modules dans l’offre de services. La partie exigeante a été le Reverse Engineering des composants existants : le système est en production, et de nombreuses intégrations d’interfaces en dépendent. Pour que la transition se fasse sans rupture, nous avons construit un connecteur legacy. Il fait correspondre les anciens appels d’API à la nouvelle API et laisse aux partenaires d’intégration le temps de migrer leurs systèmes. Pour les personnes utilisatrices, cela signifie : aucune perte de fonctionnalité.
Sanitized
Chez Sanitized, nous avons pu construire un système de A à Z et repenser les processus. Les processus métier ont d’abord été analysés et remis en question de manière critique. Des exigences est née une story map, de celle-ci des prototypes et enfin la plateforme avec toutes ses règles métier. Le projet figure dans notre liste de références.
Rotary
La plateforme associative du Rotary pour la Suisse, la France, la Belgique et le Luxembourg a permis de combiner les deux approches. Le logiciel associatif de 2012 a été entièrement remplacé par Reverse Engineering ; l’analyse des fonctions existantes a permis d’en déduire les nombreuses petites règles métier. Nous avons construit sur une base modulaire, qui peut être étendue pas à pas et exploitée sur le long terme.
Quelle approche convient à votre projet ?
Cela dépend moins de la technologie que de la quantité de savoir contenue dans l’ancien système et de la part qui doit en être conservée. Dans la plupart des projets, c’est de toute façon un mélange des deux. Décrivez-nous votre projet, nous l’examinerons.