Migration de systèmes legacy : comment moderniser le logiciel de votre entreprise sans interrompre l'activité

Moderniser un système legacy qui gère la facturation ou la logistique de votre entreprise est une tâche d'une grande complexité technique et opérationnelle. La pression opérationnelle quotidienne et la crainte qu'une migration échouée ne paralyse l'activité retardent souvent des décisions techniques nécessaires, augmentant silencieusement la dette technique et les coûts d'infrastructure accumulés au fil du temps.

Pourquoi l'approche « Big Bang » échoue si souvent en pratique

Une migration de type Big Bang — construire tout le nouveau système en parallèle et éteindre l'ancien en une seule coupure — est séduisante sur le papier car elle semble plus simple à planifier : un seul projet, une seule date de bascule, pas besoin de faire coexister deux systèmes à la fois. En pratique, elle échoue fréquemment pour une raison simple : un système legacy en production depuis des années a accumulé des règles métier, des cas particuliers et des correctifs ponctuels qui n'ont jamais été documentés nulle part ailleurs que dans le code lui-même. Tout réécrire depuis zéro signifie redécouvrir chacune de ces règles sous pression de temps, et ce sont presque toujours les plus importantes — celles qui affectent un grand client, ou un processus comptable critique — qui sont découvertes juste après la bascule, quand il est déjà trop tard pour revenir en arrière sans douleur.

Le pattern Strangler Fig (figuier étrangleur)

Plutôt qu'une migration massive de type « Big Bang » (réécrire tout le système et éteindre l'ancien), la meilleure pratique d'ingénierie consiste à remplacer le système de façon incrémentale. Le pattern Strangler Fig permet à la nouvelle architecture de coexister avec l'ancienne via une couche de routage (comme une API Gateway), en migrant module par module jusqu'à ce que le système obsolète soit entièrement remplacé. Le nom vient du figuier étrangleur, une plante qui grandit autour d'un arbre existant, prenant progressivement sa place jusqu'à ce que l'arbre d'origine ne soit plus nécessaire pour le soutenir — la métaphore est exacte : le nouveau système grandit en enveloppant l'ancien, au lieu de le remplacer d'un seul coup.

Comment fonctionne la couche de routage en pratique

Le composant qui rend ce pattern possible est une couche intermédiaire — typiquement une API Gateway ou un reverse proxy configuré à dessein — qui décide, pour chaque requête entrante, si c'est le système legacy ou le nouveau module qui l'a déjà remplacé qui doit la traiter. Au début, cette couche envoie pratiquement tout le trafic vers l'ancien système, avec une seule route pointant vers le module nouvellement migré. Avec le temps, davantage de routes sont redirigées vers le nouveau système, jusqu'à ce que le legacy ne reçoive plus aucun trafic et puisse être éteint sans risque, car à ce moment-là il n'a plus aucune responsabilité active.

Comment choisir quel module migrer en premier

Le bon critère n'est ni « le plus facile » ni « le plus important » — c'est le module offrant le meilleur rapport entre faible risque et valeur démontrable. Un module isolé, avec peu de dépendances vers le reste du système et non critique pour l'exploitation quotidienne (la génération de rapports ou un catalogue en lecture seule, par exemple), est idéal pour valider que le pattern fonctionne sans mettre l'activité en danger. Migrer d'abord le module le plus critique ou le plus complexe — même si c'est tentant parce que « c'est ce qui fait le plus mal » — coûte généralement cher, car l'équipe n'a pas encore d'expérience réelle du pattern de coexistence entre les deux systèmes.

Stratégie pour une migration sûre

• Identifier et isoler le module le plus simple mais utile (ex. inscription des utilisateurs ou génération de rapports).
• Créer une couche d'interopérabilité pour synchroniser les bases de données en temps réel entre l'ancienne et la nouvelle structure.
• Mettre en place des tests de régression automatisés pour garantir que la nouvelle API répond exactement comme l'endpoint legacy.
• Migrer progressivement le trafic réseau via des déploiements contrôlés (canary releases).
• Conserver un plan de retour en arrière (rollback) documenté et testé pour chaque module migré, pas seulement pour la migration globale.

Coûts cachés du report de la migration

La décision de reporter la modernisation d'un système legacy n'est presque jamais prise explicitement — elle survient par omission, parce qu'il y a toujours quelque chose de plus urgent sur la feuille de route. Le coût de ce report n'apparaît directement dans aucun état financier, mais il est bien réel : chaque nouvelle intégration construite sur l'ancien système est une dépendance de plus qu'il faudra migrer plus tard, chaque personne qui quitte l'équipe emporte avec elle une connaissance non documentée du fonctionnement réel du système legacy, et chaque version de plateforme ou de langage laissée sans mise à jour (parce que le système legacy dépend d'une version spécifique) augmente le risque de sécurité accumulé. Aucun de ces coûts n'apparaît dans un rapport trimestriel, mais tous finissent par se traduire, tôt ou tard, en une migration plus grande et plus risquée qu'elle ne l'aurait été deux ans plus tôt.

Comment communiquer la migration à l'organisation, pas seulement à l'équipe technique

Une migration Strangler Fig bien exécutée est, par conception, presque invisible pour le reste de l'organisation — et c'est précisément ce qui la rend difficile à communiquer vers le haut. Sans résultats spectaculaires à montrer du jour au lendemain, il est facile pour la direction de percevoir l'effort comme lent ou de faible impact, précisément parce qu'il fonctionne comme prévu : sans perturbation visible. Il vaut la peine de définir à l'avance des métriques simples réellement communicables — combien de modules ont déjà migré, quel pourcentage du trafic le nouveau système gère déjà, combien d'incidents ont été évités par rapport à l'ancien système — pour que le progrès réel reste visible au-delà de l'équipe d'ingénierie, sans dépendre de ce que quelqu'un remarque l'absence de problèmes.

Le rôle des tests de régression automatisés, en détail

Le troisième point de la stratégie ci-dessous — des tests de régression qui comparent le comportement du nouveau système à l'ancien — mérite plus de détails car c'est la pièce qui permet de faire confiance à la migration sans dépendre d'une revue manuelle exhaustive. La technique la plus efficace consiste à capturer du trafic réel (ou un échantillon représentatif) du système legacy, à l'envoyer en parallèle au module nouvellement migré, et à comparer automatiquement les deux réponses sans que l'utilisateur final ne voie jamais de différence — le nouveau système répond « dans l'ombre », sans prendre de décisions réelles pour l'instant. Une fois que les réponses correspondent de façon cohérente sur une période raisonnable, c'est le moment où il devient pertinent de commencer à rediriger du trafic réel vers le nouveau système, pas avant.

Il vaut la peine de résister à la tentation d'éteindre le système legacy immédiatement après la migration du dernier module actif. Une période de grâce de plusieurs semaines, avec l'ancien système arrêté mais pas encore supprimé (ne recevant plus de trafic réel, mais disponible pour une consultation ponctuelle si quelque chose d'inattendu survient), offre une marge de sécurité raisonnable avant de déclarer le processus entièrement clos et de libérer définitivement cette infrastructure.

Un bénéfice supplémentaire de l'approche incrémentale, rarement mentionné, est qu'elle réduit le risque pour l'équipe de développement elle-même, pas seulement pour l'activité. Réécrire un système entier d'un seul coup est un projet long, sans résultats visibles pendant des mois, et ce type de projet a tendance à perdre en priorité face aux besoins métier urgents — il est courant qu'une réécriture complète soit abandonnée à mi-chemin parce que « quelque chose de plus important est arrivé », laissant l'entreprise avec deux systèmes à moitié maintenus. Migrer module par module livre de la valeur visible toutes les quelques semaines, ce qui rend beaucoup plus facile de maintenir le soutien organisationnel tout au long du processus.

Il vaut aussi la peine de documenter chaque module migré non seulement avec son code, mais avec le raisonnement derrière les décisions prises pendant cette migration spécifique : quelles règles métier cachées ont été découvertes dans le système legacy, quels cas particuliers ont dû être reproduits et pourquoi. Cette documentation, générée comme sous-produit naturel du processus de migration lui-même, finit par être bien plus précieuse que n'importe quelle tentative de documenter le système legacy complet avant de commencer — car elle capture exactement la connaissance qui était réellement nécessaire, au moment où il est devenu évident qu'elle l'était, plutôt qu'un inventaire générique écrit sans ce contexte d'usage réel.

Cette modernisation par étapes, menée avec discipline et patience, réduit l'anxiété de l'organisation et garantit que les intégrations clés avec les ERP comptables locaux (tels que Siigo ou SAP) restent opérationnelles sans interruption pendant toute la transition, du premier module migré jusqu'au dernier.