Moderniser un système existant sans arrêter l'activité.
Pourquoi les refontes d'un bloc échouent, et une méthode pas à pas pour remplacer un système existant pendant qu'il tourne : cartographier, découper, migrer.
Publié le · 7 min de lecture
La façon la plus risquée de remplacer un système existant est de le reconstruire à l'écart, puis de basculer en un seul week-end. C'est aussi le plan le plus courant, parce qu'il paraît simple sur une diapositive. Cet article décrit l'alternative que nous utilisons : remplacer le système pièce par pièce, pendant que l'activité continue de tourner dessus.
Pourquoi les refontes d'un bloc échouent
Un système qui fait tourner une entreprise depuis dix ou quinze ans est bien plus que du vieux code. Il contient des années de règles que personne n'a écrites : la remise qui ne s'applique qu'à une région, le champ que la finance consulte le dernier jour du mois, le traitement de nuit dont dépend un partenaire. Une refonte doit toutes les redécouvrir, en général après le lancement.
L'activité continue aussi d'évoluer pendant la reconstruction. Chaque mois passé sur le nouveau système est un mois de nouvelles demandes qui arrivent sur l'ancien, et la cible ne cesse de bouger.
Enfin, une date de bascule unique concentre tout le risque au même endroit. Si quelque chose ne va pas, tout va mal en même temps, et revenir en arrière est difficile.
L'arithmétique est sans appel. Si chacune de douze fonctionnalités a 95 % de chances de basculer proprement, la probabilité que les douze y parviennent la même nuit dépasse à peine celle d'un pile ou face.
Remplacer pièce par pièce
L'alternative porte souvent le nom de « strangler fig », d'après le figuier étrangleur qui pousse autour d'un arbre jusqu'à tenir seul. On place une couche fine devant l'ancien système, puis on déplace une fonctionnalité à la fois vers un nouveau logiciel derrière cette couche. Les utilisateurs continuent de travailler. Chaque étape est assez petite pour être testée, mesurée et annulée.
Cela change aussi le moment où l'entreprise voit les résultats. Les premières tranches sont utilisées au bout de quelques mois, au lieu que tout arrive à la fin, et chacune apporte de la valeur et des enseignements pour la suivante.
| Mois depuis le lancement | Refonte d'un bloc | Pièce par pièce |
|---|---|---|
| M0 | 0 % | 0 % |
| M3 | 8 % | |
| M6 | 25 % | |
| M9 | 42 % | |
| M12 | 58 % | |
| M15 | 75 % | |
| M17 | 0 % | |
| M18 | 100 % | 92 % |
| M20 | 100 % | |
| M24 | 100 % | 100 % |
En pratique, cela tient en six étapes.
- PréparerCartographier ce que fait vraiment le systèmeFonctionnalités, intégrations, flux de données, utilisateurs.
- PréparerChoisir la première trancheUtile, petite, peu dépendante du reste.
- PréparerPlacer un point de passage devant l'ancien systèmeBasculer devient un changement de routage.
- DéplacerMigrer les données par étapesUn seul propriétaire par donnée, rapprochements réguliers.
- DéplacerFaire tourner les deux, comparer, puis basculerLe retour en arrière reste possible.
- RetirerArrêter la tranche dans l'ancien systèmeSelon un calendrier, délibérément.
1. Cartographier ce que fait vraiment le système
Commencez par un inventaire des fonctionnalités, des intégrations et des flux de données, et de qui utilise quoi. La documentation aide, mais les journaux, les requêtes en base et les échanges avec les personnes qui utilisent le système chaque jour disent ce qui se passe réellement. L'objectif est une carte que l'on peut découper en tranches.
2. Choisir la première tranche avec soin
La première tranche doit compter pour l'activité, être assez petite pour être livrée en quelques semaines et dépendre peu du reste du système. Un processus autonome, un module de reporting ou un parcours client précis sont de bons candidats. Cette première tranche valide aussi la méthode : choisissez-en une dont le succès se voit facilement.
3. Placer un point de passage devant l'ancien système
Une couche de routage, comme une passerelle d'API, un proxy ou un service d'intégration, décide quelles requêtes vont vers l'ancien système et lesquelles vont vers le nouveau. Une fois ce point de passage en place, déplacer une fonctionnalité devient un simple changement de routage plutôt qu'un week-end de migration, et revenir en arrière est tout aussi simple.
4. Migrer les données par étapes
C'est sur les données que les modernisations se compliquent. Décidez, pour chaque type d'enregistrement, quel système en est responsable à chaque instant, et ne laissez jamais deux systèmes responsables de la même chose. Gardez-les synchronisés par capture des changements ou par synchronisation planifiée, et produisez des rapports de rapprochement qui montrent que les deux côtés concordent avant de faire confiance au nouveau.
5. Faire tourner les deux, comparer, puis basculer
Avant qu'une tranche passe en production, envoyez-lui du trafic réel en parallèle et comparez les résultats avec ceux de l'ancien système. Les écarts révèlent les règles non écrites que vous aviez manquées. Basculez quand les chiffres concordent, une fonctionnalité à la fois, et gardez le retour possible tant que le nouveau chemin n'a pas fait ses preuves.
6. Retirer ce qui reste
Chaque tranche déplacée doit être désactivée dans l'ancien système, délibérément et selon un calendrier. Sinon, vous finissez par faire tourner deux systèmes pour toujours, ce qui coûte plus cher que l'un ou l'autre.
Quand une refonte complète est le bon choix
Le remplacement pièce par pièce n'est pas toujours nécessaire. Si le système est petit, a peu d'intégrations et peut être gelé pendant la reconstruction, une refonte directe peut aller plus vite. C'est aussi le cas quand l'ancienne plateforme ne peut plus fonctionner en sécurité. La bonne question n'est pas « ancien ou nouveau ? », mais « quel risque l'activité peut-elle porter sur une seule date ? »
Par où commencer
La plupart des modernisations commencent par un court audit technologique : ce qui existe, ce que cela coûte à faire tourner, ce qui doit changer, et dans quel ordre. Si vous y réfléchissez, notre offre de modernisation décrit notre approche, et vous pouvez nous parler de votre système.