Quand un système critique devient difficile à faire évoluer, la tentation est forte de repartir de zéro. Nouveaux composants, découpage propre, tests dès le premier jour : sur le papier, c’est séduisant. En pratique, la plupart des réécritures complètes de SI critiques échouent, non pas parce que la cible est mal pensée, mais parce que les conditions de passage entre l’ancien et le nouveau sont mal cadrées.
Le vrai sujet n’est jamais “quel framework choisir”. C’est : comment transformer un système qui traite des opérations réelles, jour et nuit, sans interrompre ce qui doit continuer à fonctionner pendant toute la durée de la transition.
Un SI critique ne se résume pas à son code
Avant toute transformation, il faut comprendre ce qui tient réellement le système. Et ce qui le tient dépasse toujours le code source.
Un monolithe qui traite des opérations financières depuis huit ans a accumulé des couches invisibles : des scripts lancés à 3h du matin pour consolider des données, des exports vers des partenaires qui n’acceptent qu’un format figé depuis 2017, des procédures de reprise manuelles que seul un opérateur connaît, des règles métier enfouies dans des procédures stockées que personne n’a relues depuis trois ans.
Cette cartographie prend du temps. Lire le code ne suffit pas : il faut interroger les exploitants, analyser les logs de production pour découvrir les flux réels (pas ceux de la documentation), identifier les interfaces externes et leurs contraintes, recenser les exigences de disponibilité par flux métier.
Moderniser sans cette lecture revient à déplacer un système qu’on ne comprend qu’à moitié. Et sur un SI critique, la moitié qu’on ignore est généralement celle qui cause l’incident en production.
Le premier cadrage utile : identifier les zones qu’on n’ose plus toucher
Un bon diagnostic commence rarement par la cible. Il commence par les zones de stress : modules qu’on évite de modifier, traitements nocturnes mal documentés, intégrations anciennes peu testées, règles métier dispersées, composants dont la seule stabilité vient de l’habitude de ne pas y toucher.
Ce sont généralement ces zones qui déterminent l’ordre de transformation. Plutôt qu’attaquer tout d’un bloc, on sépare ce qui peut être encapsulé, ce qui doit être isolé, ce qui doit être réécrit, et ce qui peut continuer à vivre plus longtemps qu’on ne l’imaginait.
Moderniser progressivement, pas en big bang
Moderniser sans rupture impose une transformation progressive : ne jamais couper l’ancien avant que le nouveau ait fait ses preuves en production.
L’approche la plus courante est le Strangler Fig pattern : on interpose une couche de routage devant le monolithe existant, chaque nouveau flux est implémenté dans un composant séparé, et le routage redirige progressivement le trafic. L’ancien système rétrécit au fil du temps sans jamais être coupé d’un coup. C’est l’approche la moins risquée, mais aussi la plus longue.
Quand on ne peut pas encore extraire de service autonome, par exemple parce que les transactions sont trop couplées, on travaille à l’intérieur du monolithe avec le pattern Branch by Abstraction : on introduit une abstraction entre le code appelant et le module à remplacer, on développe la nouvelle implémentation derrière cette abstraction, et on bascule quand la preuve est faite.
Dans les deux cas, le sujet reste le même : la coexistence n’est pas une phase transitoire qu’on subit. C’est un état à concevoir.
La coexistence est un problème de conception
Le scénario le plus risqué reste le basculement brutal : éteindre l’ancien un vendredi soir, allumer le nouveau lundi matin. Dans la majorité des contextes critiques, la bonne approche est progressive. On route une fraction du trafic vers le nouveau composant, on compare les résultats, on monte progressivement, on retire l’ancien quand la preuve d’équivalence est faite.
En pratique, cette coexistence crée trois problèmes structurants.
La synchronisation des données. Pendant la coexistence, deux systèmes lisent et écrivent potentiellement les mêmes données. Il faut choisir une stratégie de propagation : simplicité avec risque de divergence, ou découplage avec un léger décalage temporel. Ce choix structure tout le reste.
Les mécanismes de rollback. Si le nouveau service dégrade les performances ou produit des résultats incorrects, il faut pouvoir revenir à l’ancien en minutes, pas en heures. Un changement de configuration de routage doit suffire. Mais le rollback doit aussi couvrir les données : ce qui a été écrit par le nouveau système pendant la période de test doit être réconciliable avec l’ancien.
L’observabilité pendant la transition. Superviser deux systèmes en parallèle avec des technologies différentes est un défi en soi. Il faut pouvoir suivre une requête de bout en bout sur les deux chaînes, comparer latences et taux d’erreur, détecter les divergences entre les deux mondes. Sans cette visibilité, on pilote à l’aveugle.
Ce qui dépasse la technique
Beaucoup de projets de modernisation sont cadrés uniquement sous l’angle technique. C’est insuffisant.
Les engagements d’exploitation doivent être redéfinis pour la période de transition : qui gère les incidents quand les deux systèmes coexistent ? Les fenêtres de mise en production sont souvent plus contraintes qu’on ne l’imagine, surtout en secteur réglementé. Les habilitations doivent couvrir les deux mondes simultanément. Et la capacité de l’équipe à maintenir la cible dans la durée doit être évaluée honnêtement : si la nouvelle architecture est plus complexe à opérer, l’équipe actuelle est-elle prête ?
La dette technique n’est pas le seul facteur de décision. La dette organisationnelle, l’écart entre les compétences actuelles et celles requises par la cible, peut être un obstacle plus bloquant qu’un couplage technique. Un système plus moderne mais plus difficile à opérer n’est pas une réussite.
Les décisions à prendre tôt
Quelques décisions ont un impact disproportionné sur la suite du projet.
Ce qu’on ne modernisera pas tout de suite. Identifier explicitement les composants qui resteront en l’état est aussi important que de choisir par quoi commencer. Un batch qui tourne sans incident depuis cinq ans et qui ne bloque aucune évolution peut attendre. Cette décision libère de la bande passante pour le reste.
La stratégie de données. Base partagée entre ancien et nouveau, ou bases séparées avec synchronisation : ce choix structure tout le reste de l’architecture de coexistence.
Le niveau de découplage réellement nécessaire. Le réflexe “microservices partout” est rarement adapté à un contexte de modernisation. Un monolithe mieux structuré, avec des frontières internes propres et des interfaces bien définies, est souvent un meilleur objectif intermédiaire qu’une architecture distribuée complète.
Conclusion
Moderniser un SI critique sans rupture demande moins de promesses et plus de cadrage. La réussite tient à la capacité à lire l’existant, à concevoir la coexistence comme un système à part entière, et à transformer dans un ordre qui réduit le risque au lieu de le déplacer.
Cadrer une transition, lire un SI critique avant transformation, concevoir une coexistence opérationnelle : ce sont les phases sur lesquelles nous intervenons aux côtés des équipes techniques. Modernisation et maintien en condition de confiance.