Pillar page
Modernisation des systèmes legacy
Refactoring incrémental monolithe-vers-microservices, migration de technologies obsolètes vers des stacks modernes, migration vers le cloud — sans interruption métier, avec un plan de rollback et un audit trail complet.
Chaque entreprise a un système legacy. Certaines en ont plusieurs. Une application comptable de 2008 qui fonctionne encore tant bien que mal. Un CRM écrit par des consultants dont plus personne ne se souvient. Un entrepôt sous Access. Chacun d'eux devra être remplacé un jour — la question n'est pas si, mais quand et comment.
La modernisation des systèmes legacy est l'un des types de projets IT les plus difficiles. Elle exige d'équilibrer trois forces : maintenir la continuité métier (le système doit fonctionner en permanence), introduire des technologies modernes (microservices, cloud, IA) et contrôler les risques (chaque refactoring peut casser quelque chose qui fonctionne depuis des années).
Pourquoi ne pas simplement « tout réécrire » ?
D'après notre expérience, 9 modernisations réussies sur 10 sont des refactorings incrémentaux, pas des réécritures. Les réécritures sont conceptuellement séduisantes (« on repart de zéro »), mais en pratique elles ont trois problèmes fondamentaux :
- Logique métier invisible. L'ancien système contient des années de règles métier — conditions spéciales pour les plus gros clients, exonérations fiscales pour des secteurs spécifiques, contournements pour des réglementations de 2015. La plupart ne sont pas documentées. Une réécriture doit toutes les recréer à partir de la mémoire des personnes ou de l'analyse du code.
- Doublement du travail. Pendant l'écriture du nouveau système, le métier continue d'exiger des changements dans l'ancien (réglementations, nouveaux clients, petits bugs). L'équipe doit soit doubler le travail (changement à deux endroits), soit geler l'ancien système (risque métier).
- Big bang deployment. Après un an de travail, le nouveau système est « presque prêt ». Basculer tous les utilisateurs en une nuit génère un risque monumental. Tout problème inattendu signifie revenir à l'ancien système, perdre le moral de l'équipe et éroder la confiance du métier.
Le refactoring incrémental (le plus souvent selon le pattern Strangler Fig) résout ces trois problèmes : la logique métier est découverte progressivement, une source de vérité unique pour chaque entité, déploiement en étapes avec feature flags.
Six patterns de modernisation
Chacun adresse un risque spécifique. Dans la plupart des projets, nous en combinons plusieurs, en choisissant un pattern par module.
Strangler Fig
« Envelopper » progressivement l'ancien système avec de nouveaux composants. L'ancien code tourne toujours, mais chaque nouvelle fonctionnalité va dans un nouveau microservice et les modules existants sont remplacés un par un. Après 12 à 24 mois, l'ancien monolithe est éteint.
Anti-corruption layer
Un adaptateur protégeant le nouveau code des bizarreries de l'ancien système (noms de champs illisibles, formats de dates étranges, types incohérents). Toute la logique « moche » est isolée en un seul endroit — le nouveau code opère sur un modèle de domaine propre.
Database refactoring
Patterns du livre Refactoring Databases (Ambler/Sadalage) : expand-and-contract pour les migrations de schéma, validation des données avant suppression des anciennes colonnes, maintien des deux schémas en parallèle pendant la migration applicative.
Branch by abstraction
Introduction d'une couche d'abstraction autour de l'ancien composant, implémentation parallèle du nouveau composant, basculement progressif du trafic de 0% à 100% (feature flag). Sans déploiement « big bang ».
Shadow mode
Le nouveau code tourne en parallèle de l'ancien — les deux traitent les mêmes requêtes, mais seuls les résultats de l'ancien atteignent l'utilisateur. Les résultats sont comparés hors ligne. Après confirmation de compatibilité (typiquement 2 à 4 semaines), nous basculons le trafic sur le nouveau code.
Event sourcing pour la migration
Nous enregistrons le flux d'événements métier de l'ancien système et le rejouons dans le nouveau. Cela permet une validation préalable de la nouvelle architecture sans risque de production, et la possibilité de revenir à n'importe quel état historique.
Calendrier typique de modernisation
Pour un système de taille moyenne (monolithe d'environ 200 000 lignes de code, 5 à 10 modules métier) :
- Mois 1 : Discovery et documentation. Reverse engineering de l'architecture, cartographie des dépendances, identification des flux de données, documentation des processus métier avec l'aide des parties prenantes.
- Mois 2 : Architecture cible et pilote. Conception de la nouvelle architecture, sélection des technologies, pilote sur le module le plus simple (proof of concept). Première validation de l'approche.
- Mois 3-4 : Extraction du premier module de production. Pattern Strangler Fig, shadow mode pendant 2 à 3 semaines, bascule du trafic, hypercare. Première valeur métier réelle.
- Mois 5-12 : Extraction itérative des modules suivants. Chacun dans un cycle de 4 à 6 semaines : refactoring → tests → shadow → production → hypercare. Amélioration continue du processus, réduction du temps par module.
- Mois 12-18 : Migration des données et décommissionnement du monolithe. Une fois tous les modules critiques extraits, nous finalisons la migration des données historiques, éteignons l'ancien système, archivons. On célèbre.
Système legacy vs. modernisé
| Aspect | Système legacy (typique) | Après modernisation |
|---|---|---|
| Délai de livraison d'une nouvelle fonctionnalité | 4-8 semaines (risque de régression élevé) | 3-7 jours (les tests automatisés minimisent le risque) |
| Couverture de tests | 5-15% (ou aucune) | >80%, dans le pipeline CI/CD |
| Disponibilité des développeurs | Faible (technologie obsolète) | Élevée (stacks populaires, modernes) |
| Sécurité | Vieilles bibliothèques avec des CVE non corrigées | Scan OWASP, gitleaks, mises à jour automatisées |
| Scaling | Vertical (plus de ressources pour le monolithe) | Horizontal (scaling de microservices spécifiques) |
| Observabilité | Logs dans des fichiers, pas de métriques | Prometheus + Grafana + Sentry + SIEM |
| Conformité (RGPD, EU AI Act, ISO 27001) | Exigeante, coûteuse à prouver | Intégrée à l'architecture, prête pour l'audit |
Six risques typiques — et comment nous les adressons
Risque : Absence de tests dans le système legacy
Mitigation : Nous construisons d'abord des tests de caractérisation (capture tests) — en enregistrant le comportement actuel du système à partir des logs de production et des captures de trafic. Ce n'est qu'ensuite que nous commençons le refactoring, avec les tests comme filet de sécurité.
Risque : Connaissance concentrée chez une seule personne (« truck factor 1 »)
Mitigation : Le transfert de connaissances commence dès la première semaine du projet. Toutes les réunions avec la personne connaissant le système sont enregistrées et transcrites, les processus clés documentés, les décisions d'architecture justifiées. Après le projet, toute l'équipe comprend le système.
Risque : Ralentissement temporaire de l'équipe
Mitigation : Pendant les 2-3 premiers mois, l'équipe maintient l'ancien système + construit le nouveau. Ralentissement naturel du rythme de changement. Nous l'atténuons en : priorisant les changements qui ne vont que dans le nouveau système, en gelant les changements de faible priorité dans l'ancien code.
Risque : Migration de données
Mitigation : Chaque migration de données comporte trois phases : dry-run (sur une copie de production), staging (en environnement de test à l'échelle réelle), production (pendant une fenêtre de service ou de manière incrémentale). Plan de rollback prêt avant le démarrage.
Risque : Résistance organisationnelle
Mitigation : Communication avec le métier dès le premier jour : pourquoi moderniser, ce qui change pour l'utilisateur, quel calendrier, comment nous mesurons le succès. La première itération est choisie pour montrer rapidement une valeur tangible (par ex. une nouvelle UI ou un rapport plus rapide).
Risque : Sous-estimation du coût
Mitigation : Discovery (1-2 semaines) avant le chiffrage du projet. Itérations de 2 à 3 semaines avec des livrables concrets — plus facile de corriger le cap que dans un long projet « tout d'un coup ». Budget avec un buffer de 20-30% pour l'imprévu.
Questions fréquentes
Qu'est-ce qu'un système legacy ?
Pourquoi moderniser si le système fonctionne ?
N'est-il pas plus facile de tout réécrire de zéro ?
La modernisation exige-t-elle une interruption métier ?
Combien de temps prend une modernisation typique ?
Depuis quelles technologies migrons-nous le plus souvent ?
Et les intégrations existantes avec d'autres systèmes ?
Comment réduisez-vous le risque métier ?
Et la documentation système qui n'existe pas ?
Comment le coût de modernisation se compare-t-il au maintien de l'ancien système ?
Commençons par un audit
Audit technique d'une semaine : cartographie de l'état actuel, identification des zones de modernisation les plus urgentes, plan phasé avec des résultats métier concrets dès la première itération.