Modernisation applicative
Une application héritée ne se remplace pas d'un bloc. Elle se cartographie, se découpe en lots, et se refond un lot à la fois, avec la preuve à chaque étape que rien n'a changé pour ceux qui s'en servent.
Une refonte échoue rarement sur la technique.
Sept à huit programmes de modernisation sur dix n'atteignent pas leur objectif, et presque jamais pour des raisons techniques : périmètre qui s'élargit, arbitrages jamais rendus, effet tunnel où plus rien ne sort pendant dix-huit mois.
Nous prenons le problème par l'autre bout. Le patrimoine est cartographié avant qu'on y touche, le premier lot part en production avant qu'on décide du deuxième, et chaque bascule se rejoue en sens inverse si l'écart apparaît. Ce qui rend une refonte tenable n'est pas la cible choisie, c'est la taille du pas.
Ce que nous faisons
Quatre chantiers pour qu'une refonte se décide sur des faits et se livre par morceaux.
Cartographie et diagnostic
Regarder l'existant avant d'y toucher : dépendances, technologies, obsolescence et couplages, puis un score par lot qui croise la valeur métier et la complexité technique.
l'analyse accélère la lecture du code, elle ne signe pas le diagnostic
- Dépendances, obsolescence et couplages
- Un score par lot, valeur et complexité
- Aucun constat publié sans revue d'ingénieur
Refonte par lots
Le nouveau composant prend le trafic par fractions pendant que l'ancien reste debout. Rien n'est éteint tant que le remplaçant n'a pas fait ses preuves sur du trafic réel.
un lot en production avant de décider du suivant, jamais l'inverse
- Un lot livré, l'ancien toujours debout
- Bascule par fractions de trafic
- Repli immédiat, sans redéploiement
Migration et replatforming
Déplacer, réhéberger ou réécrire se décide lot par lot, pas pour le patrimoine entier. Une application déplacée sans changement coûte souvent plus cher au même endroit.
cloud public, privé ou qualifié selon ce que la donnée impose
- Le déplacement arbitré par lot
- Cloud souverain quand la donnée l'exige
- Infrastructure décrite en code, pas configurée
Non-régression prouvée
Chaque règle est spécifiée de façon exécutable, et les tests sont produits au même rythme que le code. L'absence de régression se démontre en rejouant le trafic, pas en l'affirmant.
les deux moteurs calculent en parallèle, un seul répond
- Une spécification exécutable par règle
- Tests produits au rythme du code
- L'écart se montre, il ne se déclare pas
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : le moteur de tarification d'un back-office hérité, vingt et un ans, trois cent douze règles. Chaque ligne dit ce qui est réellement remis, dans l'ordre où on le remet.
La cartographie du patrimoine
Le fichier sur lequel se décide le premier lot : appels par jour, nombre de règles, couplage, obsolescence et valeur métier. Un lot à faible trafic et faible valeur en ressort candidat au retrait plutôt qu'à la refonte.
L'intention réécrite avant le code
Chaque règle devient une spécification exécutable avec ses critères d'acceptation et sa ligne d'origine dans le code hérité. Celles dont l'intention ne se retrouve pas partent en arbitrage métier plutôt qu'en réécriture à l'identique.
La bascule par fractions
Un pour cent, dix, cinquante, puis la totalité, chaque palier conditionné au précédent. Les deux moteurs calculent en parallèle, l'écart est journalisé à chaque appel, et le repli se déclenche sans redéploiement.
La preuve par le rejeu
Le trafic réel des trente derniers jours est rejoué sur les deux moteurs et comparé appel par appel. Ce que le rejeu trouve n'est pas toujours un défaut de la refonte, et c'est justement ce qui le rend utile.
Comment on livre
Cartographier
selon le nombre d'applications, de langages et de couplages à démêler
- Cartographie applicative et dépendances
- Score de modernisation par lot
- Trajectoire chiffrée et arbitrable
Refondre un lot
selon le nombre de règles à retrouver et de systèmes à raccorder
- Spécification exécutable du lot
- Couverture de non-régression produite avec le code
- Bascule progressive avec repli immédiat
Dérouler
selon le nombre de lots restants et leur couplage
- Lots suivants sur le même gabarit
- Extinction de l'ancien, lot par lot
- Montée en compétences des équipes
Tenir
engagement de service défini avec vous
- Dette suivie comme un indicateur
- Montées de version tenues, pas subies
- Documentation régénérée avec le code
Ce que coûte l'attente
Des refontes qui ont tenu
Des règles métier redevenues lisibles et testables
483 règles réimplémentées · 53 flux SAP intégrés
Refondre le moteur de règles de la gestion des temps, dont dépendent les horaires, les plannings et la paie de 12 000 salariés, avec des centaines de règles héritées et des dizaines de flux SAP dont l'erreur se propage en aval.
Chaque règle spécifiée de façon exécutable plutôt qu'écrite en prose, l'implémentation générée sous revue d'ingénieur, la couverture de non-régression produite au même rythme, et les flux SAP validés un par un avant la production.
Des flux interbancaires modernisés, une trésorerie rassemblée
−45 % de cycle de clôture · −60 % de temps de réconciliation
Des flux interbancaires répartis sur quatorze banques contreparties, un cycle de clôture qui s'allongeait avec les volumes, et une migration vers SAP S/4HANA à mener sans interrompre la trésorerie.
Les flux modernisés et centralisés, la réconciliation automatisée, et la migration d'ERP sécurisée par étapes plutôt qu'en une bascule. Les volumes ont triplé sans que le cycle de clôture suive.
Un site éditorial refondu, et la maintenance qui le tient
−45 % de temps de chargement · 5 Core Web Vitals verts sur 6
Un site éditorial dont la performance s'érodait de livraison en livraison, sur un titre où le confort de lecture fait partie du produit, avec une maintenance qui devait survivre à la refonte.
Une refonte pilotée par la mesure plutôt que par le goût, puis une maintenance qui garde la mesure en marche : ce qui se dégrade se voit à la livraison suivante, pas au prochain audit.
Insights & Perspectives
Anti-patterns microservices : les pièges qui font échouer les migrations
Découper trop tôt, découper trop fin, ou reproduire le monolithe dans un maillage de services : les erreurs qui coûtent le plus cher se commettent au moment du découpage.
Architecture hexagonale : principes, ports et adaptateurs
Isoler le métier de ce qui l'entoure rend une application testable et déplaçable. C'est ce qui permet de changer de base ou d'hébergeur sans rouvrir la logique.
Automatiser les montées de version : l'IA et les outils traditionnels
Ce que les outils de migration savent faire seuls, ce que l'IA ajoute, et où la revue humaine reste la seule garantie sur une montée de version de framework.
Commencez par regarder ce que vous avez
Une cartographie du patrimoine, un score par lot, et une trajectoire qui se discute avant de s'engager.
Questions fréquentes
Parce que l'obstacle est rarement technique. Sept à huit sur dix échouent sur l'organisation : un périmètre qui s'élargit, des arbitrages métier jamais rendus, et un effet tunnel où rien ne part en production pendant des mois. Livrer un lot tôt est le meilleur antidote connu.
Ni l'un ni l'autre pour le patrimoine entier. Le choix se fait lot par lot : déplacer ce qui est sain, réécrire ce qui bloque, retirer ce qui ne sert plus. Une application déplacée sans changement continue de coûter ce qu'elle coûtait, dans un endroit souvent plus cher.
Le nouveau composant prend une fraction du trafic pendant que l'ancien continue de tourner. On monte par paliers, un pour cent, dix, cinquante, chacun conditionné au précédent, et l'ancien n'est éteint qu'après une période sans écart. À aucun moment il n'y a de bascule unique à défaire.
En rejouant le trafic réel sur les deux versions et en comparant appel par appel. Une campagne de tests écrite après coup couvre ce qu'on a pensé à tester ; le rejeu couvre ce que les utilisateurs font vraiment, y compris les cas que personne n'avait documentés.
Elles partent en arbitrage métier, pas en réécriture à l'identique. Reproduire une règle qu'on ne comprend pas revient à transporter la dette dans le système neuf. C'est souvent à ce moment qu'on découvre que deux services appliquaient la même règle différemment.
Non, mais elle change l'échelle du travail. La conversion automatisée est passée d'environ 40 % de fiabilité en 2020 à 70-85 % aujourd'hui : elle absorbe le volume, retrouve l'intention dans le code et génère les tests. La décision et la revue restent humaines, sur un système dont l'erreur atteint un client.
La cartographie prend 2 à 6 semaines selon le nombre d'applications, de langages et de couplages à démêler, et produit une trajectoire chiffrée et arbitrable. Le premier lot suit en 4 à 10 semaines, avec sa spécification exécutable, sa couverture de non-régression et sa bascule progressive.