Découper un monolithe sans casser la production
- On ne découpe pas d'un coup avec de vrais utilisateurs derrière.
- Je bascule le trafic par paliers derrière un feature flag.
- Je fais tourner l'ancien et le nouveau service en double sur les mêmes entrées.
- Je garde le retour arrière sous la main.
- Une étape qui ne sait pas s'annuler ne se lance pas.
Questions fréquentes
Le client refuse de payer six mois pour un découpage. Comment vous le vendez ?
Je ne le vends jamais comme un chantier global avec une facture en bloc. Je le découpe en extractions livrables une par une, chacune avec sa valeur propre : un domaine sorti, c'est un point chaud qui cesse de bloquer les déploiements du reste. Le client paie au fur et à mesure et peut s'arrêter quand il estime que le plus douloureux est traité. Beaucoup s'arrêtent à mi-parcours, et c'est très bien : tout n'a pas vocation à devenir un service.
Vous touchez à des bases de données séparées ou tout reste sur le même schéma ?
Au début, le nouveau service tape souvent encore la base d'origine, et c'est volontaire : séparer le code et séparer les données sont deux chantiers distincts, les empiler double le risque. On extrait d'abord la logique, on stabilise, et seulement après on envisage de sortir les tables concernées dans leur propre stockage. Vouloir tout séparer en une fois, c'est le genre d'ambition qui transforme une extraction en réécriture.
Comment vous savez qu'une bascule a vraiment échoué et pas juste un faux positif ?
Je ne me fie pas au ressenti. Avant d'ouvrir le flag, je fixe deux ou trois seuils chiffrés : taux d'erreur, latence sur les requêtes qui comptent, écart de résultats métier. Si un seuil est franchi, je coupe sans débattre, quitte à rouvrir cinq minutes plus tard après vérification. Le danger, ce n'est pas de couper pour rien, c'est de laisser tourner en se disant que ça va se tasser.