Une refonte applicative sans interruption n’est pas une promesse d’absence totale d’incident. C’est une stratégie qui réduit le rayon d’impact, conserve un chemin de retour et évite de faire dépendre toute la valeur d’une bascule unique après des mois de développement caché.
La page refonte de logiciel métier doit relier architecture et continuité d’exploitation. La stratégie strangler devient utile quand une frontière peut être isolée et livrée progressivement, pas quand elle sert seulement à rebaptiser une longue coexistence.
Ce guide organise situation initiale, choix de tranche, routage, données, fonctionnement parallèle, parité, cohortes, retour arrière et retrait. Chaque vague doit déplacer une responsabilité complète et supprimer une part mesurable de l’ancien système.
Le danger principal est le système à deux têtes : deux interfaces, deux sources, des synchronisations permanentes et aucun critère de fin. La gouvernance de sortie compte donc autant que la construction du nouveau composant.
Vérifier que la stratégie progressive est adaptée
Le strangler convient si le domaine possède des capacités séparables, si le trafic peut être routé et si l’entreprise peut financer une coexistence temporaire. Il est moins adapté lorsque la transformation exige une rupture immédiate de modèle ou qu’aucune frontière ne peut être créée sans tout modifier.
La criticité et la fréquence des changements sont examinées ensemble avant de choisir la trajectoire. Un module stable mais risqué peut être encapsulé avant d’être remplacé ; un domaine en évolution constante peut justifier une extraction plus rapide.
Le commanditaire accepte que la trajectoire livre par tranches et que certaines fonctions restent volontairement sur l’ancien système. Sans cette discipline de périmètre, chaque vague devient une mini-réécriture exhaustive qui reporte indéfiniment la première suppression.
Deux signaux faibles annoncent une coexistence qui s’installe : les nouvelles fonctions nécessitent encore des modifications dans l’ancien système et aucune date de retrait n’accompagne les règles de routage. Ils indiquent que la tranche déplace l’interface sans déplacer la responsabilité.
Établir la situation initiale de l’ancien système
La situation initiale mesure volumes, latence, erreurs, incidents, temps de déploiement, charge support et principales règles métier. Elle inclut les comportements non documentés que les utilisateurs considèrent comme normaux.
Les parcours critiques sont enregistrés avec leurs données d’entrée et résultats. Cette collection devient un référentiel de comparaison, tout en reconnaissant que certains comportements historiques sont des défauts à ne pas reproduire.
Le coût actuel est explicité : hébergement, licences, maintenance, contrôles, contournements et risque. Il permettra de vérifier que la coexistence ne consomme pas indéfiniment plus que la valeur déplacée.
Choisir la première tranche strangler
La première tranche doit avoir une valeur visible, une frontière possible et un risque borné. Un parcours fréquent mais réversible ou une lecture sans effet de bord constitue souvent un meilleur apprentissage qu’une clôture financière.
La tranche est verticale : interface, règle, donnée, intégration, supervision et support. Extraire seulement un écran qui continue à appeler toutes les règles historiques ne déplace presque aucune responsabilité.
Le dossier précise ce qui sera supprimé après le succès de chaque tranche livrée. Cette ligne empêche de célébrer une mise en production qui ajoute un composant sans réduire la surface de l’ancien système.
Poser frontières et sources de vérité
Chaque capacité possède un responsable et une source maîtresse explicitement nommée pendant la coexistence. Une donnée ne doit pas être modifiable librement des deux côtés. Les écritures sont dirigées vers un système puis propagées avec un contrat explicite.
Une couche de traduction isole le modèle historique du nouveau domaine métier. Elle localise les conventions anciennes sans les répandre dans le nouveau code. Ses transformations sont testées sur des cas réels et versionnées avec leur période de validité.
Les événements portent un identifiant, une version, un horodatage et une corrélation utilisable. Les conflits sont visibles et résolus par règle, pas par « dernière écriture gagnante » implicite.
Le coût caché d’un double maître apparaît dans les corrections et les arbitrages quotidiens : quelle valeur conserver, qui a écrit en dernier et comment réconcilier les historiques. Une frontière plus stricte paraît contraignante, mais réduit durablement ces enquêtes.
Router sans rendre le parcours illisible
Le routage peut dépendre d’une URL, d’une organisation, d’un utilisateur, d’une fonction ou d’un mécanisme d’activation progressive. La règle doit être observable et stable pendant une transaction afin qu’un même dossier ne saute pas entre deux comportements.
Le support voit précisément quelle version a traité l’utilisateur et quelle règle l’y a dirigé. Les journaux et les données d’usage conservent la cohorte pendant toute la période d’analyse. Sans ce contexte, une anomalie de migration ressemble à un défaut intermittent.
Le routeur reste volontairement simple, observable et temporaire pendant toute la migration. Une accumulation de règles de cohortes sans date d’expiration crée une plateforme de variantes plus difficile à maintenir que le système initial.
Migrer les données sans double maître
La migration sépare la reprise historique de la synchronisation courante entre les deux systèmes. La reprise est répétable, contrôlée par manifeste et rapprochée avec la source. Le flux courant capture les changements intervenus pendant la copie.
La règle d’écriture change une seule fois pour chaque population et laisse une preuve consultable. Un basculement qui dépend uniquement de l’heure sans version de donnée peut perdre les transactions retardées ou les appliquer dans le mauvais ordre.
Les règles de qualité sont écrites avant le transfert : doublons, champs obligatoires, références orphelines, formats et valeurs impossibles. Les anomalies sont mises en quarantaine plutôt que transformées silencieusement.
Une bascule de source maître possède une fenêtre, un gel éventuel, une preuve et un retour arrière. L’ancienne donnée devient lecture seule avant d’être archivée ou supprimée selon les obligations.
Concevoir un fonctionnement parallèle limité
Le fonctionnement parallèle exécute les deux traitements sur une population bornée et compare leurs résultats, sans produire deux effets externes. Pour une écriture, un seul système reste autoritaire ; l’autre calcule sans effet aval.
La durée, le coût et les critères de sortie sont fixés avant le démarrage. Prolonger peut être nécessaire, mais la décision doit répondre à un écart précis.
Les divergences sont classées : défaut nouveau, défaut ancien, différence acceptée ou donnée d’entrée non comparable. La simple égalité binaire masque les améliorations voulues et les erreurs du système historique.
Mesurer parité fonctionnelle et métier
La parité couvre règles, états, droits, documents, délais et résultats. Elle ne signifie pas reproduire chaque écran ; elle garantit que les utilisateurs peuvent accomplir les tâches nécessaires avec les preuves attendues.
Les métriques métier comparent taux de succès, erreurs, durée, conversion, tickets et corrections manuelles. La nouvelle solution doit améliorer ou maintenir ces résultats, pas seulement passer ses tests unitaires.
Les écarts acceptés sont documentés avec le commanditaire, leur population et leur date de réévaluation. Une fonction rare peut être retirée volontairement si une procédure alternative est prête, comprise et testée par ses utilisateurs.
Ouvrir par cohortes
Les cohortes commencent par utilisateurs internes ou pilotes représentatifs, puis s’élargissent par organisation, région ou type de dossier. Chacune possède des seuils d’erreur, de performance et de support.
Les mécanismes d’activation progressive sont gouvernés : responsable, date de revue, états possibles et plan de suppression. Ils ne doivent pas devenir des paramètres permanents sans modèle.
La décision d’élargir se prend sur une fenêtre suffisante pour couvrir les exceptions du parcours. Une journée sans incident ne prouve pas une clôture mensuelle ou un retour rare.
Tester un retour arrière réellement possible
Le retour arrière distingue le code, le routage et les données écrites depuis l’ouverture. Revenir vers l’ancien écran est simple uniquement si les écritures produites par le nouveau restent compatibles ou peuvent être reconverties.
Après un point de non-retour, la trajectoire prévoit une progression vers l’avant avec une capacité renforcée. Cette option plus honnête remplace une promesse de retour impossible lorsque de nouvelles entités ou règles n’existent plus dans l’ancien modèle.
Le test crée des transactions, ouvre la nouvelle cohorte, provoque une condition d’arrêt puis revient. Il vérifie intégrité, files, caches, utilisateurs et capacité de diagnostic.
Retirer l’ancien composant au lieu d’empiler
Après stabilisation, les routes historiques sont fermées, les écritures bloquées, les tâches arrêtées et les accès retirés. Les données sont archivées avec une procédure de consultation si nécessaire.
Le code, les configurations et la supervision obsolètes sont supprimés. Garder « au cas où » des chemins actifs entretient le risque et oblige les équipes à les sécuriser.
Le retrait produit une économie mesurable : licences, infrastructure, incidents ou complexité. Cette économie finance les vagues suivantes et prouve que la stratégie réduit réellement l’ancien système.
Piloter coûts, risques et décisions
Le tableau de programme suit capacités déplacées, surface historique retirée, coût de coexistence, écarts de parité, incidents et prochaines décisions. Les pourcentages de code réécrit restent secondaires, car ils ne prouvent aucune responsabilité effectivement supprimée.
Chaque vague possède une décision d’élargissement et une revue structurée après sa livraison. Les dépendances organisationnelles, la formation et le support entrent dans la feuille de route au même titre que les composants.
Un plafond de coexistence déclenche un arbitrage si la migration ralentit. L’entreprise décide alors de réduire le périmètre, augmenter la capacité ou changer de stratégie au lieu d’accepter un fonctionnement parallèle permanent.
Conclusion : réduire l’ancien système à chaque vague
La stratégie strangler réussit lorsqu’elle déplace une capacité complète et retire une responsabilité de l’ancien système. La coexistence n’est qu’un moyen temporaire de réduire le risque de bascule pendant l’apprentissage.
Les sources de vérité, le fonctionnement parallèle et les métriques de parité rendent les écarts visibles. Les cohortes et le retour arrière limitent l’exposition pendant l’apprentissage et la stabilisation.
Le retrait effectif constitue la preuve finale que la capacité a réellement changé de système. Sans suppression, la refonte additionne des couches et conserve les coûts qu’elle devait éliminer.
Dawap accompagne ces trajectoires dans ses projets de développement web sur mesure, depuis l’audit du système existant jusqu’aux vagues de migration, à la reprise de données et à la sortie effective des anciens composants.
