À retenir
- Les réécritures complètes échouent plus souvent à cause du périmètre et du calendrier que de la technique.
- Placer d'abord une interface stable devant le système existant, puis remplacer derrière.
- Remplacer une capacité métier à la fois et la valider en production avant de passer à la suivante.
- Faire tourner l'ancien et le nouveau en parallèle et comparer les résultats avant de basculer le trafic.
Une réécriture complète promet un nouveau départ et produit le plus souvent un projet long et risqué. Remplacer un système existant pas à pas maintient l'activité et valide chaque étape.
Pourquoi les réécritures complètes s'enlisent
Un système existant est généralement ancien pour une bonne raison : il fonctionne, et l'entreprise en dépend. Il contient des années de règles, d'exceptions et de correctifs, dont beaucoup ne sont pas documentés. Une réécriture doit tous les redécouvrir pendant que l'ancien système continue d'évoluer.
Le résultat suit un schéma bien connu. Le nouveau système prend plus de temps que prévu, l'ancien nécessite entre-temps des changements urgents, et la date de bascule recule. Pendant ce temps, l'entreprise paie deux systèmes et ne profite d'aucun.
Commencer par une interface stable
La première étape n'est pas d'écrire du nouveau code pour le cœur du système. C'est de placer une interface – généralement une couche d'API – devant le système existant, afin que les autres applications dialoguent avec cette interface plutôt que directement avec l'ancienne base de données ou les anciens écrans.
Dès que les consommateurs dépendent de l'interface et non de l'implémentation, on peut changer ce qui se trouve derrière, morceau par morceau. C'est ce qu'on appelle souvent le pattern « strangler » : le nouveau système grandit progressivement autour de l'ancien jusqu'à ce que celui-ci puisse être arrêté.
Prioriser par capacité métier
Choisissez la première capacité à remplacer selon deux critères : les problèmes qu'elle cause aujourd'hui et son degré d'isolement. Un bon premier candidat a des entrées et sorties claires et peu de dépendances – par exemple la génération de devis, les notifications ou le reporting.
Ne commencez pas par la partie la plus centrale et la plus interconnectée du système. Les premières phases doivent construire la confiance et une compréhension partagée, pas mettre tout le projet en jeu.
- Recenser les capacités et les données que chacune possède.
- Évaluer chacune selon la douleur métier et le couplage.
- Commencer là où la douleur est forte et le couplage faible.
- Garder le cœur du traitement transactionnel pour quand l'équipe connaîtra bien le domaine.
Valider chaque étape en parallèle
Avant de basculer une capacité, faites tourner l'ancienne et la nouvelle implémentation en parallèle sur les mêmes entrées et comparez les résultats. Les écarts révèlent les règles non documentées plus vite que n'importe quel atelier de spécification.
Basculez le trafic progressivement – par agence, par segment de clientèle ou par pourcentage – et gardez un chemin de retour documenté. Une étape de migration impossible à annuler demande encore plus de préparation.
Traiter la migration des données comme un projet à part
Les données survivent au code. Les anciennes données contiennent souvent des doublons, des formats incohérents et des champs détournés de leur usage prévu. Prévoyez explicitement le nettoyage, la correspondance et la vérification, avec des comptages et des sommes de contrôle prouvant que rien n'a été perdu.
Quand la dernière capacité migre, l'arrêt de l'ancien système devrait être une formalité : tous les consommateurs utilisent déjà la nouvelle interface, toutes les données sont vérifiées, et l'entreprise travaille sur le nouveau système depuis des semaines.
Cet article vous a plu ? Recevez le prochain par e-mail.