Dans cet article
Choisir une frontière avec un résultat métier visible
Imaginons une ancienne application de commandes où modifier un rapport impose de tout redéployer. Le reporting peut constituer une première frontière si ses lectures sont séparables des écritures de commande. Remplacer d’abord la transaction centrale peut embarquer bien davantage de dépendances cachées. Choisissez selon les faits, pas selon l’apparence vieillissante du code.
Le modèle Strangler Fig décrit le remplacement progressif de capacités autour d’un système existant. Ici, un routage envoie les demandes de reporting vers la nouvelle version tandis que les commandes restent disponibles. Ce routage devient lui-même une dépendance : prévoyez supervision et repli. Une migration progressive réduit l’exposition seulement si chaque tranche peut réellement être exploitée et évaluée séparément.
Commencer par les preuves d’échec et de changement
Cartographiez incidents, délai de release, modules fragiles, dépendances non supportées, contournements manuels et erreurs de qualité des données. Une « technologie ancienne » ne suffit pas à justifier un remplacement.
Identifiez ce qui doit rester stable : contrats, calendriers opérationnels, identifiants, rapports, intégrations et preuves réglementaires. Ces contraintes définissent davantage la migration que la stack cible.
Créer des seams autour du changement utile
Placez une frontière testée autour d’une capacité qui change souvent ou concentre un risque disproportionné. Stabilisez entrées et sorties avant de changer l’intérieur ; n’exposez pas la base legacy comme nouvelle API publique.
Un chemin strangler peut router certains cas vers un nouveau composant tandis que l’existant reste autoritaire ailleurs. Utilisez responsabilité et compatibilité explicites plutôt qu’un double système permanent et invisible.
Remplacer une frontière utile à la fois
Une migration doit conserver un retour arrière vérifiable.
Observer l’existant
Identifier le changement actuellement coûteux ou fragile.
Créer une frontière
Placer une interface stable autour de la capacité choisie.
Migrer et comparer
Réconcilier les données et arrêter si les critères ne sont pas atteints.
Migrer les données avec réconciliation et règles d’arrêt
Définissez l’autorité canonique à chaque phase, testez des migrations représentatives, réconciliez volumes et totaux métier, et conservez une fenêtre de rollback. Évitez les écritures bidirectionnelles sans politique de conflit exécutable et monitorée.
Chaque incrément exige un résultat mesurable et une condition d’arrêt. S’il n’améliore ni sécurité de release, reprise, parcours utilisateur ni coût d’exploitation, ne poursuivez pas les extractions pour l’apparence architecturale.
Préserver le comportement avant de le modifier
Capturez des entrées et sorties représentatives du fonctionnement ancien, y compris les cas historiques gênants. Un comportement surprenant peut être une règle métier ou un bug que les utilisateurs contournent. Examinez les écarts avec le responsable du processus, sans supposer que la nouvelle version a raison parce que son code est plus propre.
Pour un rapport en lecture seule, exécutez les deux chemins sur le même instantané et comparez totaux, dates et sélection des dossiers. Étudiez les divergences. Ne dupliquez pas les écritures réelles vers les deux systèmes sans conception explicite de la cohérence : vous pourriez multiplier les effets. Définissez d’abord quel système possède chaque enregistrement et comment ses modifications rejoignent l’autre pendant la transition.
Déplacer une capacité à la fois
Exemple de migration de rapports en lecture seule. Les écritures demandent une conception distincte de propriété et synchronisation.
Documenter l’existant → réaliser la tranche → comparer les sorties
Écarts compris et critères d’acceptation satisfaits ?
Oui
- Router un périmètre limité → observer
- Retirer l’ancien chemin après le bilan convenu
Non
- Conserver le routage existant
- Étudier les écarts → répéter la comparaison
Le retour arrière doit couvrir les données depuis la bascule
Renvoyer les utilisateurs vers l’ancienne interface n’est simple que si elle comprend encore les données actuelles. Avant bascule, décidez si les écritures restent compatibles, si un journal permet leur rejeu ou si la migration possède un point au-delà duquel une correction en avant est préférable. Rendez cette limite explicite plutôt que de qualifier toute version de réversible.
Après la période d’observation convenue, retirez ancien chemin, tâches planifiées, identifiants et alertes. Sinon, l’organisation exploite deux systèmes indéfiniment. Évaluez le résultat selon le problème initial : le rapport doit désormais évoluer indépendamment, avec résultats cohérents et responsabilité claire. La tranche est modernisée lorsque l’ancienne dépendance peut disparaître, pas dès l’apparition du nouvel écran.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Quand une réécriture complète est-elle justifiée ?+
Seulement lorsque des seams incrémentaux ne peuvent préserver le comportement obligatoire ou que la plateforme existante ne peut être exploitée pendant la transition. La réécriture exige malgré tout migration, parité et rollback.