Remplacer un système sans l’arrêter.
Une refonte d’un bloc mise tout sur un seul week-end. Voici comment remplacer un système existant pièce par pièce, sans arrêter l’activité.
Par Nizar Oukhchi, Architecte solution
Publié le · 7 min de lecture
Imaginez qu’on vous demande de remplacer le système sur lequel tourne votre entreprise depuis quinze ans. Le plan sur la diapositive est simple : tout reconstruire à l’écart, puis basculer en un seul week-end.
C’est aussi le plan le plus risqué qui soit.
C’est pourtant le plus courant, justement parce qu’il paraît simple. Alors, que faire à la place ? Je vais vous montrer l’approche 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 tournent mal
Un système qui fait tourner une entreprise depuis dix ou quinze ans, ce n’est pas juste 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 discrètement un partenaire.
Une refonte doit toutes les redécouvrir. En général, après le lancement.
Ensuite, l’activité ne s’arrête pas pendant que vous reconstruisez. Chaque mois passé sur le nouveau système, ce sont de nouvelles demandes qui arrivent sur l’ancien. Vous visez une cible qui bouge.
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.
À quel point, au juste ?
Faisons le calcul. Disons que chacune de douze fonctionnalités a 95 % de chances de basculer proprement. Ça paraît très bien ! Mais la probabilité que les douze y parviennent la même nuit dépasse à peine celle d’un pile ou face.
Voici ce que ça donne :
Une bascule unique transforme une série de petits risques en un gros.
Remplacer pièce par pièce
L’alternative porte souvent le nom de « strangler fig ». Elle le doit au figuier étrangleur, qui pousse autour d’un arbre jusqu’à tenir seul. (Pardonnez-moi cette botanique un peu sinistre.)
L’idée est la suivante. Vous placez une couche fine devant l’ancien système. Puis vous déplacez une fonctionnalité à la fois vers un nouveau logiciel, derrière cette couche.
Les utilisateurs continuent de travailler pendant tout ce temps.
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, plus des leçons pour la suivante.
La différence saute aux yeux :
| 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 % |
Concrètement, comment s’y prendre ? 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.
Étape 1 : cartographier ce que fait vraiment le système
Commencez par un inventaire. Quelles fonctionnalités, quelles intégrations, quels flux de données, et qui utilise quoi ?
La documentation aide. Mais elle décrit ce que quelqu’un pensait que le système ferait.
Pour savoir ce qui se passe réellement, lisez les journaux, interrogez la base de données et parlez avec les personnes qui utilisent le système tous les jours. On (moi compris) saute bien trop souvent cette dernière étape.
L’objectif : une carte que l’on peut découper en tranches.
Étape 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.
- 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.
Pourquoi être aussi exigeant ?
Parce que cette première tranche valide aussi la méthode. Choisissez une première tranche dont le succès se voit facilement.
Étape 3 : placer un point de passage devant l’ancien système
Il vous faut une couche de routage. Une passerelle d’API, un proxy ou un service d’intégration fera l’affaire. Elle 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, quelque chose d’agréable se produit.
Déplacer une fonctionnalité devient un simple changement de routage, et non plus un week-end de migration. Et revenir en arrière est tout aussi simple.
Étape 4 : migrer les données par étapes
C’est ici que les modernisations se compliquent.
Pour chaque type d’enregistrement, décidez quel système en est responsable à chaque instant. 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. Puis produisez des rapports de rapprochement qui montrent que les deux côtés concordent.
Alors seulement, vous pouvez faire confiance au nouveau. Pas avant.
Étape 5 : faire tourner les deux, comparer, puis basculer
Avant qu’une tranche passe en production, envoyez-lui du trafic réel en parallèle. Comparez ses résultats avec ceux de l’ancien système.
Est-ce que ça va concorder ? Souvent, non !
Et c’est tout l’intérêt. Les écarts révèlent les règles non écrites que vous aviez manquées à l’étape 1.
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.
Étape 6 : retirer ce qui reste
C’est fini ? Pas tout à fait.
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. Deux systèmes coûtent plus cher que l’un ou l’autre.
Quand une refonte complète est le bon choix
Je ne veux pas en faire trop. 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. Même chose quand l’ancienne plateforme ne peut plus fonctionner en sécurité.
La bonne question n’est donc pas « ancien ou nouveau ? »
C’est plutôt : 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 envisagez une modernisation, voici comment nous l’abordons. Et si un regard extérieur vous serait utile, parlez-nous de votre système.