Migrer en une seule fois ou de manière progressive : que choisir ?
TL;DR : La migration progressive doit être le choix par défaut : elle découpe le risque au lieu de le concentrer. Le big bang ne s'impose vraiment que lorsque l'ancien et le nouveau ne peuvent pas coexister, ou quand le système est trop petit pour mériter cette mécanique. Trois patterns couvrent la plupart des cas — Strangler Fig, Parallel Run, UI Composition — à condition de traiter la reprise de données et l'observabilité comme des prérequis, pas comme des finitions
Le logiciel vieillit ! Comme bon nombre de produits, une application peut finir par devenir obsolète et il faut parfois la remplacer par son équivalent plus moderne. La dette technique d’un socle vieillissant finit par devenir un risque d’exploitation : instabilité, pannes, impossibilité d’évoluer. La modernisation d’un legacy devient alors une nécessité, pas un confort. Sauf qu’une application… c’est aussi des données et un service qui ne peut pas s’arrêter, car ses utilisateurs l’utilisent quotidiennement.
Comment réaliser cette migration ? Faut-il basculer vers le nouveau système en une seule fois, ou faut-il migrer progressivement, sans coupure de service ?
La réponse évidente est qu’il faut migrer progressivement lorsque c’est possible : c’est la solution la moins risquée. Dans les faits, la migration en une seule fois, dite “big bang”, s’impose régulièrement pour des raisons moins techniques qu’organisationnelles : fenêtre contractuelle, arrêt d’un système tiers, calendrier réglementaire, capacité limitée à maintenir deux mondes en parallèle.
Migrer progressivement : l’option la plus sûre
La migration progressive consiste à remplacer le système par morceaux : par fonctionnalité, domaine, endpoint API, segment d’utilisateurs, écran. De fait, on fonctionne par incréments avec des périmètres à chaque fois plus circonscrits que celui de la migration “big bang”.
La complexité totale reste la même mais elle est rendue manipulable et gérable. Par exemple :
- une anomalie sur un domaine isolé se diagnostique mieux qu’une panne globale
- une bascule d’un client pilote se gère mieux qu’une bascule sur toute la base installée
- un rollback sur une route se prépare plus simplement qu’un retour arrière complet
La migration progressive permet de casser petit et donc de réparer vite. C’est l’esprit du déploiement sans coupure de service (zero downtime) : l’utilisateur ne doit jamais percevoir la bascule.
Cette logique n’a rien de nouveau côté infrastructure. Le blue-green deployment bascule le trafic entre deux environnements identiques, avec retour arrière immédiat. Le canary release envoie d’abord une fraction des utilisateurs vers la nouvelle version, observe, puis élargit. Migrer une application reprend ces principes, mais à l’échelle d’un système entier : on bascule par morceaux, on observe, on élargit.
Pour accompagner une migration progressive, il sera souvent important de disposer d’une suite de tests end-to-end solides qui permettront de valider la non régression. De bons outils d’observabilité seront également essentiels. Enfin, plus à la marge, l’emploi de techniques telles que le “feature flagging” permettra de faciliter les migrations et rollbacks.
La migration big bang : pourquoi elle s’impose moins souvent qu’on ne le croit
La migration en big bang est simple à décrire : à une date donnée, on bascule l’ancien système vers le nouveau, d’un seul coup.
Le problème c’est qu’elle concentre tous les risques au même moment : périmètre fonctionnel, déploiement, reprise de données, documentation, accompagnement des utilisateurs, disponibilité de l’infrastructure. Le moindre défaut se découvre dans une fenêtre courte, sous pression, avec plusieurs anomalies qui peuvent se superposer.
Fort heureusement, dans l’immense majorité des cas, la migration progressive reste techniquement possible : on choisit le big bang, on n’y est pas contraint. L’exemple le plus courant est de cumuler un replatforming avec un changement de l’expérience utilisateur. Dans ce cas, c’est le big bang assuré !
Il n’existe qu’un petit nombre de situations où la progressivité est réellement exclue par nature, et toutes ont la même cause : la coexistence de l’ancien et du nouveau est impossible.
- Aucun point d’insertion La migration progressive a besoin d’une couture où aiguiller les flux : gateway, feature flag. Quand elle n’existe pas et ne peut pas être créée, on ne peut pas découper. C’est le cas du passage d’un système fermé vers un système ouvert.
- Incapacité à faire fonctionner les deux systèmes en parallèle Ancien et nouveau veulent écrire la même donnée avec des modèles incompatibles, sans qu’on puisse réconcilier. Les faire coexister corromprait les données.
- Atomicité obligatoire. le “à moitié migré” n’est pas possible : la bascule doit être vraie pour tout le monde en même temps. Changement de référentiel incompatible ou contrainte réglementaire qui interdit deux régimes en parallèle à une date donnée.
Quelle stratégie adopter ? la grille de décision
Une seule question commande le choix : peut-on faire coexister l'ancien et le nouveau ? Tout le reste en découle. En pratique, on tranche sur cinq critères.
- Point d'insertion: Existe-t-il une couture — gateway, proxy, feature flag — où aiguiller les flux ? Sans elle, impossible de découper : c'est l'un des rares cas où le big bang s'impose par nature.
- Tolérance à la coupure. : Si une interruption planifiée est acceptable, le big bang redevient une option. Si le zéro coupure est exigé, le progressif n'est plus négociable.
- Poids de la reprise de données : Plus le volume est gros, sensible ou réglementé, plus on a intérêt à répéter les bascules et à étaler le risque dans le temps.
- Maturité de l'usine logicielle (intégraiton continue) : CI/CD, tests end-to-end, observabilité : sans ces prérequis, orchestrer une migration progressive coûte cher et le big bang devient un pari.
- Taille du système : Un périmètre réduit ne mérite pas toujours la mécanique du progressif — proxy, double run, comparaison. Le big bang y est parfois le choix frugal.
Trois patterns pour migrer progressivement
Sur les projets de migration que nous avons menés chez Dernier Cri, nous avons noté trois grands patterns qui permettent de répondre à la plupart des cas, notamment lorsqu’il s’agit de démanteler un monolithe legacy. Le Strangler Fig pour l’approche générale de migration progressive, le Parallel Run pour sécuriser les comportements et la UI Composition pour faire évoluer le frontend sans tout arrêter. Plutôt que des bricolages maison, ce sont des approches éprouvées, à l’état de l’art, qui se combinent.
Strangler Fig : remplacer le backend domaine par domaine
Le Strangler Fig Pattern reprend l’image du figuier étrangleur : le nouveau système pousse autour de l’ancien, puis finit par le remplacer.
Concrètement, on ne tente pas d’extraire tout le monolithe mais on choisit un domaine fonctionnel suffisamment isolé : une partie du catalogue, un module de déclaration, un flux de paiement, un pan d’administration. On construit une nouvelle implémentation iso-fonctionnelle. Puis on route progressivement le trafic vers elle. C’est d’ailleurs ce qui permet de réduire le risque.
La pièce clé est souvent une API Gateway ou un équivalent : un point d’entrée capable d’envoyer certaines requêtes vers le legacy et d’autres vers les nouveaux services.
Un autre avantage de ce pattern : l’ancien système continue de fonctionner, ce qui simplifie les rollbacks.
Parallel Run : comparer l’ancien et le nouveau avant de basculer
Le Parallel Run consiste à faire tourner l’ancien et le nouveau système en parallèle, puis à comparer leurs résultats avant de confier réellement le trafic au nouveau.
Le principe est simple. L’utilisateur continue à recevoir la réponse de l’ancien système. En arrière-plan, la même requête est envoyée à la nouvelle implémentation. Un composant de comparaison vérifie les écarts : réponse différente, statut inattendu, temps de réponse anormal, divergence de calcul, donnée manquante.
Tant que les écarts existent, on corrige. Quand les écarts deviennent rares et acceptables, on peut envisager la bascule.
Ce pattern est très utile pour les domaines où “ça marche” ne suffit pas. Calculs métier, tarification, éligibilité, règles de gestion, transformations de données : autant de sujets où l’on veut confronter le nouveau système à la vraie diversité de la production.
Il y a une condition importante : la comparaison ne doit pas dégrader l’expérience utilisateur. Sur un projet, cela passe souvent par un proxy et un consistency-checker asynchrone.
Le Parallel Run demande de la rigueur. Il faut définir ce qu’est une divergence, ignorer les différences sans valeur métier, tracer les cas, rejouer certains scénarios. C’est dans les faits un pattern assez sophistiqué et dont la difficulté de mise en oeuvre nécessite de bien peser le rapport coût / bénéfice.
UI Composition : migrer le frontend sans geler le produit
La UI Composition consiste à faire cohabiter, dans l’expérience utilisateur, des morceaux legacy et des morceaux nouveaux. Cela peut se faire par widgets, par pages, par verticales fonctionnelles ou par routes. On injecte donc progressivement des composants modernes dans l’application existante, ou l’on réutilise certains composants historiques dans une nouvelle application.
C’est une technique pour le coût assez simple à mettre en oeuvre et qui est souvent choisie instinctivement pour déployer de nouveaux composants dans une application existante.
Le seul élément technique clé est souvent le partage des sessions et de l’état applicatif, qui se résout assez facilement dans la plupart des cas.
Les reprises de données : un chantier toujours critique
Les migrations de données sont toujours un chantier délicat et on sous-estime toujours, même avec la meilleure volonté du monde, les difficultés qui seront rencontrées. Les données historiques contiennent à peu près toujours des exceptions : saisies manuelles, changements de règles, formats oubliés, doublons, anciennes conventions.
La mauvaise approche consiste à traiter la reprise de données comme un script de fin de projet. On conçoit le modèle cible, on développe l’application, puis on demande à quelqu’un de “migrer la base”.
La bonne approche consiste à intégrer la reprise dès la conception. Quelles sources reprendre ? Tout l’historique ou seulement une partie ? Quels champs doivent être transcodés ? La question est d’autant plus structurante qu’un changement de paradigme de stockage — par exemple le passage d’un modèle relationnel à une base document-orientée comme MongoDB — impose une re-conception du modèle, pas une simple copie.
Deux propriétés rendent ce chantier tenable : des scripts de reprise idempotents, qu’on peut relancer sans risque après une anomalie, et indépendants, jouables rapidement sur des échantillons de taille variable.
Les grandes étapes d’une reprise maîtrisée
En pratique, un chantier de reprise solide se déroule en cinq temps, du cadrage à la bascule :
- Cadrage — recenser les bases et données à reprendre, fixer le périmètre, identifier les points durs (dédoublonnage, transcodification, consolidation), choisir la solution technique.
- Qualification des sources — analyser la qualité des données, corriger ce qui peut l’être automatiquement ou manuellement, repérer les rejets.
- Réalisation — développer les scripts de migration, les traitements de restructuration et de transcodification, produire les indicateurs.
- Recette — double contrôle : statique (les données cible correspondent-elles aux sources ?) et dynamique (le système cible les fait-il vivre correctement ?), en répétant la bascule sur des copies de production.
- Bascule — dérouler la check-list de démarrage sur la production, retour arrière prêt à être déclenché.
Le fil conducteur, c’est le plan de retour arrière : conçu dès le cadrage, vérifié lors des répétitions, maintenu jusqu’au décommissionnement de l’ancien système. Une reprise n’est sûre que si l’on sait revenir en arrière proprement. Ce plan doit être testé.
L’observabilité : facteur clé de succès de toute migration
Dans une migration, l’observabilité est nécessaire pour ne pas opérer à vue. Sans données, on bascule sur un pari ; avec elles, sur des faits.
Il faudra être capable de monitorer les erreurs applicatives ainsi que des métriques business standards : taux de conversion, connexions etc. Tout ce qui peut être utile pour constater le bon fonctionnement du nouveau système.
Deux exemples concrets de migrations
Un SI de santé migré vers MongoDB. Le système était ancien, instable, et manipulait des données de santé soumises à des contraintes de conformité. La migration consistait à faire passer les données d’un modèle relationnel à un modèle document. Changer de paradigme de stockage a obligé à repenser le modèle cible. Nous avons donc traité la reprise comme une contrainte de conception, dès le départ. Concrètement, cela voulait dire dérouler les étapes décrites plus haut et répéter les bascules sur des copies anonymisées de production.
Un SaaS d’assurance en marque blanche, sur un monolithe Scala Sur ce système, utilisé par plus de 10.000 utilisateurs par jour, un frontend JavaScript maison était devenu obsolète. Deux contraintes fortes : pas de coupure de service et le produit devait continue d’évoluer pendant la refonte. Le plan initial combinait un Parallel Run pour sécuriser les bascules et des microfrontends pour le frontend. Ici, la mise en place du Parallel Run et de l’UI Composition ont été particulièrement complexes. Le Parallel Run ne pouvait pas s’appuyer sur les Filter de Play : nous avons déporté la comparaison dans une gateway NodeJS en façade. Pour l’UI Composition, les microfrontends butaient un framework maison qui captait les événements de navigation : nous avons migré route par route, page après page. Pour ce projet, la réalisation d’un POC permettant de valider la stratégie a été cruciale.
Progressif vs big bang : le mot de la fin
La bonne question n’est pas “progressif ou big bang ?” mais est : est-ce qu’on peut faire cohabiter l’ancien et le nouveau, et à quel coût ?
Si la coexistence est possible — et elle l’est presque toujours — la migration progressive est le choix par défaut. Elle permet d’apprendre tôt, de limiter le rayon d’impact, de faciliter les retours arrière et de basculer de manière sereine. Le big bang est légitime quand la coexistence est hors d’atteinte ou quand le système est trop petit pour mériter cette mécanique.
Questions fréquentes
Quelle est la différence entre une migration big bang et une migration progressive ?
Le big bang bascule tout l'ancien système vers le nouveau à une date donnée, d'un seul coup. La migration progressive remplace le système par morceaux — fonctionnalité, domaine, route, segment d'utilisateurs — en faisant coexister l'ancien et le nouveau. Le big bang concentre le risque, le progressif l'étale.
Quand choisir une migration big bang ?
Quand la coexistence de l'ancien et du nouveau est impossible — aucun point d'insertion, modèles de données inconciliables, atomicité imposée par une contrainte réglementaire — ou quand le système est trop petit pour justifier la mécanique du progressif. Dans la majorité des autres cas, le progressif reste plus sûr.
Qu'est-ce que le pattern Strangler Fig ?
C'est une approche de migration progressive où le nouveau système pousse autour de l'ancien : on remplace un domaine fonctionnel à la fois et on route le trafic vers la nouvelle implémentation via une API Gateway, jusqu'à décommissionner le legacy. Le nom vient du figuier étrangleur.
Comment migrer sans coupure de service (zero downtime) ?
En basculant par petits incréments derrière un point d'aiguillage, en gardant l'ancien système opérationnel pour le rollback, et en s'appuyant sur des pratiques éprouvées : blue-green deployment, canary release, schéma de données rétro-compatible (expand/contract) et observabilité pour décider de la bascule sur des faits.
Comment sécuriser la reprise de données lors d'une migration ?
En l'intégrant dès la conception, avec des scripts idempotents et indépendants, une double recette — contrôle statique et dynamique — des répétitions de bascule sur des copies de production, et un plan de retour arrière testé jusqu'au décommissionnement de l'ancien système.
Vous avez un
produit en tête ?
Construisons-le ensemble.