Six mois de réécriture à plein régime, zéro fonctionnalité livrée pendant ce temps, et le jour du basculement on découvre que le nouveau système ne reproduit pas trois comportements que personne n’avait documentés. J’ai vu ce scénario assez souvent pour ne plus proposer la réécriture d’un bloc. Sur un de ces chantiers, l’ancien système, censé mourir, recevait encore des correctifs pendant qu’on le récrivait à côté.
Le strangler pattern évite ce pari. On remplace le monolithe par petits bouts, et l’application reste vivante du premier jour au dernier. Une façade en amont intercepte tout le trafic et l’oriente : vers le nouveau service pour ce qui est déjà extrait, vers le monolithe pour le reste.
Le strangler pattern remplace un monolithe par petits bouts : une façade en amont intercepte le trafic et le route, le domaine déjà extrait part vers son nouveau service, tout le reste continue vers l’ancien. Le monolithe rétrécit au fil des extractions, sans coupure et sans tout rejouer d’un coup. Au début presque tout file vers l’ancien. À chaque domaine sorti, une part de trafic bascule, et le monolithe maigrit. Parfois il disparaît ; souvent il en subsiste un noyau qui ne méritait pas l’effort d’une extraction.
Voici comment je déroule un chantier de ce type.
1. Poser le point d’interception. Il route absolument tout vers le monolithe, sans déplacer une seule ligne de code. L’étape a l’air vide puisqu’elle ne change rien pour personne, et c’est pourtant la fondation : sans elle, aucune extraction n’est réversible. Je préviens toujours l’équipe métier avant, sinon elle voit une semaine partie en fumée sur ce qui ressemble à du néant.
2. Choisir un domaine faiblement couplé. Pas le plus utile, pas le plus visible : le plus détachable. Chez un client industriel, le premier candidat fut l’envoi des notifications, une zone périphérique que personne n’osait toucher dans le monolithe de peur de tout casser.
3. Extraire ce domaine et basculer son trafic. On le déploie comme service à part, on modifie la règle de la façade, et désormais ses requêtes partent vers lui. En quinze jours, les notifications du client tournaient hors du monolithe, et surtout la preuve était faite que la mécanique de routage tenait sous charge réelle.
4. Observer, puis garder la main sur le retour arrière. Le service se comporte mal en production ? On rebascule son trafic vers le monolithe, le temps de comprendre, sans incident côté utilisateur. C’est là que la première étape paie : la sortie de secours existe parce qu’on a posé l’interception avant de toucher au code.
5. Traiter la propriété des données, domaine par domaine. Tant que le nouveau service et le monolithe lisent et écrivent les mêmes tables, le découplage est en trompe-l’œil : le code est séparé, l’état non. Donner à un domaine la propriété de ses données, c’est le travail qu’on rêve de repousser parce qu’il est ingrat. Le repousser produit des services qui se croient autonomes et se marchent dessus dans la base.
6. Recommencer, en remontant vers l’emmêlé. Une fois la mécanique rodée sur le périphérique, on s’attaque aux domaines plus enchevêtrés, ceux qui demandent d’abord un peu de cartographie et quelques remaniements internes du code (des refactos : on réorganise sans changer le comportement) pour dégager une couture exploitable, c’est-à-dire une ligne de séparation nette par où découper.
Sur le papier, ce chemin est plus lent qu’une réécriture franche. Il a un seul avantage, mais il est décisif : à aucun moment vous ne jouez toute l’application sur une seule date. Le dernier client qui l’a suivi a sorti onze domaines en dix-huit mois, et sa bascule la plus risquée a duré le temps d’un changement de préfixe d’URL.