Comment migrer un monolithe sans interruption

Migrer un monolithe sans interruption exige plus qu’un nouveau stack : cartographie, bascule progressive, données cohérentes et retour arrière testé.

Un monolithe qui facture, expédie, collecte des données ou pilote des opérations n’est pas un problème théorique. C’est un actif de production, souvent imparfait mais indispensable. Vouloir migrer monolithe sans interruption commence donc par une discipline simple : comprendre ce qui tourne réellement avant de décider ce qui doit être remplacé.

La plupart des échecs ne viennent pas d’un manque de frameworks ou de compétences cloud. Ils viennent d’une hypothèse fausse : croire que le périmètre du système est visible dans le dépôt Git. En production, le monolithe dépend aussi de tâches planifiées, d’imports manuels, de comptes tiers, de scripts sur un serveur, d’un tableur métier et parfois d’un comportement connu d’un seul salarié. On ne migre pas une application. On migre un système vivant.

Ce que « sans interruption » veut vraiment dire

Pour une PME, zéro interruption absolue est rarement une promesse utile. Il y a toujours un risque résiduel : une fenêtre de latence, une fonctionnalité temporairement dégradée, ou un retour arrière à déclencher. Le bon objectif est plus concret : ne pas interrompre les parcours critiques et conserver une capacité de retour rapide si la nouvelle trajectoire échoue.

Les parcours critiques ne sont pas les mêmes pour tous. Pour un e-commerce, ce sont la consultation du catalogue, le panier, le paiement et la remontée des commandes. Pour un SaaS B2B, cela peut être l’authentification, l’accès aux données clients et les traitements planifiés. Pour un outil interne, c’est parfois la génération d’un document ou la synchronisation comptable du soir.

Cette hiérarchie doit être écrite avant tout chantier. Sans elle, l’équipe optimise des éléments visibles mais secondaires, tandis qu’une dépendance discrète bloque la production le jour de la bascule.

Migrer un monolithe sans interruption commence par l’inventaire

Avant de découper le code, il faut produire une cartographie exploitable. Pas un schéma d’architecture décoratif, mais un document qui permet de prendre des décisions : services appelés, flux entrants et sortants, schéma de données, volumes, dépendances externes, tâches asynchrones, secrets, règles métier critiques et points de surveillance existants.

Lisez le code, les journaux, les configurations de déploiement et les historiques d’incidents. Comparez ensuite cette lecture à ce que les équipes métier disent utiliser. Les écarts sont normaux. Ils sont aussi précieux : ils révèlent les contournements et les fonctions dont personne ne se souvenait jusqu’à ce qu’elles cassent.

Il faut également établir une mesure de référence. Temps de réponse, taux d’erreur, délai de traitement, nombre de transactions, utilisation de la base, taux d’échec des jobs : sans métrique de départ, il est impossible de dire si la migration améliore réellement la situation. Une plateforme peut sembler disponible alors qu’elle accumule des commandes perdues dans une file d’attente.

Définir des frontières métier, pas des frontières de fichiers

Un monolithe peut être correctement structuré, ou au contraire mêler facturation, comptes utilisateurs et logistique dans les mêmes tables et les mêmes classes. Dans les deux cas, le découpage doit partir des responsabilités métier : gestion des commandes, identité, catalogue, facturation, notifications, reporting.

Extraire un composant n’a de sens que s’il peut posséder une responsabilité claire, une interface stable et, à terme, ses données ou au moins son modèle de lecture. Découper parce qu’un diagramme de microservices paraît moderne est une manière coûteuse de déplacer la complexité sur le réseau.

Il est souvent raisonnable de garder un monolithe modulaire comme cible intermédiaire. Si le problème actuel est un déploiement dangereux, des tests insuffisants ou une base de données mal maîtrisée, passer immédiatement à dix services ne résout rien. Cela ajoute dix pipelines, dix jeux de logs et de nouvelles défaillances distribuées.

Remplacer progressivement, jamais à l’aveugle

La stratégie la plus fiable consiste à faire cohabiter l’ancien et le nouveau assez longtemps pour prouver le comportement du nouveau. Le monolithe continue à servir la production. Une nouvelle capacité est introduite derrière une interface contrôlée, puis reçoit progressivement le trafic réel.

Pour y parvenir, les feature flags sont utiles, à condition d’être gérés comme du code de production. Chaque flag doit avoir un propriétaire, un critère d’activation et une date de suppression. Des dizaines de flags permanents finissent par créer une application que plus personne ne sait raisonner.

Le routage progressif permet de limiter le rayon d’impact. On commence par des utilisateurs internes, un client pilote ou une faible part du trafic. Si les métriques restent correctes, le périmètre augmente. Si elles se dégradent, on repasse vers l’ancien chemin sans redéployer dans l’urgence.

Le trafic miroir est particulièrement utile pour les fonctions de lecture ou de calcul. La nouvelle implémentation reçoit une copie de requêtes réelles, sans que sa réponse soit montrée à l’utilisateur. On compare ensuite les résultats, les temps de traitement et les erreurs. Cette approche révèle les cas limites que les jeux de tests ne contiennent pas : données anciennes, formats inattendus, règles métier non documentées.

Pour une écriture critique, la prudence est plus forte. Écrire dans deux systèmes peut créer des divergences si la transaction échoue à mi-chemin. Il faut définir une source d’autorité, des identifiants idempotents, des mécanismes de reprise et une procédure de réconciliation. Une double écriture sans contrôle explicite est un problème différé, pas une stratégie de migration.

La base de données est le vrai chantier

Dans de nombreuses migrations, le code applicatif se déplace facilement. Les données, elles, concentrent les risques. Elles portent l’historique, les contraintes implicites et les traces de décisions métier prises sur plusieurs années.

Évitez les changements destructifs en une seule livraison. La méthode expand-contract est plus sûre : on ajoute d’abord la nouvelle structure compatible avec l’ancienne, l’application écrit ou lit selon une règle contrôlée, les données historiques sont migrées et vérifiées, puis l’ancien schéma est retiré une fois qu’il n’est plus utilisé.

Chaque migration doit être idempotente. Elle doit pouvoir être rejouée sans corrompre les données. Prévoyez aussi des contrôles de cohérence concrets : nombre d’enregistrements, totaux financiers, clés orphelines, états impossibles, échantillons comparés avec l’ancien système. Pour les données financières ou contractuelles, une validation métier est nécessaire. Une égalité de nombre de lignes ne garantit pas une égalité de sens.

Les longues opérations de base doivent être étudiées en conditions proches de la production. Un index créé au mauvais moment, un verrou prolongé ou une requête de rattrapage mal écrite peut provoquer précisément l’interruption que le programme cherchait à éviter.

Préparer le retour arrière avant la première bascule

Un rollback crédible n’est pas « on remet l’ancienne version ». Si le nouveau système a déjà écrit des données, le retour arrière doit expliquer quoi faire de ces écritures. Les ignorer, les réimporter ou les rejouer sont trois choix différents, avec des conséquences différentes.

Avant une bascule, l’équipe doit savoir qui décide de l’arrêt, quels indicateurs déclenchent cette décision, comment le trafic est rerouté et comment les données sont réconciliées. Ce scénario doit être testé. Une procédure rédigée pendant un incident a peu de valeur.

La supervision doit suivre les symptômes métier autant que les symptômes techniques. Surveillez les erreurs HTTP, bien sûr, mais aussi les paiements confirmés sans commande, les emails non envoyés, les délais de traitement et les écarts entre systèmes. Le client ne distingue pas une erreur de code d’un message qui n’est jamais arrivé. Il constate seulement que le service ne tient pas sa promesse.

Organiser une migration qui reste gouvernable

Une migration longue échoue souvent par dilution de responsabilité. Décidez qui possède chaque domaine, qui valide les données, qui surveille la production et qui arbitre entre délai, risque et périmètre. Les dépendances doivent être visibles dans un plan court, mis à jour régulièrement, pas enterrées dans un outil de gestion de projet.

La documentation doit rester opérationnelle : architecture actuelle, flux de données, procédures de déploiement, inventaire des accès, alertes et décisions prises. C’est ce qui permet à une PME de ne pas redevenir dépendante d’une seule personne lorsque le chantier se termine.

L’objectif n’est pas de prouver que le monolithe était une erreur. Il est de réduire le risque de changement tout en conservant ce qui fonctionne. Une migration bien menée avance par preuves : une fonction isolée, des données vérifiées, un trafic augmenté, une procédure de retour testée. C’est moins spectaculaire qu’une réécriture totale. C’est aussi la méthode qui laisse l’entreprise continuer à travailler pendant que sa technologie évolue.