Un client industriel, ERP maison (le logiciel de gestion central qui pilote stocks, commandes et facturation) vieux d’une douzaine d’années, voulait « extraire la facturation en premier » parce que c’était le module le plus douloureux. J’ai dit non. La facturation tapait dans les stocks, les commandes et les tarifs en permanence, des dizaines d’appels par opération. La sortir d’emblée, c’était se garantir un monolithe distribué dès le premier service. Nous avons plutôt commencé par l’export comptable, périphérique et presque autonome. Trois semaines, zéro régression. La facturation est venue bien plus tard, une fois ses dépendances clarifiées.
Cette histoire résume toute la difficulté : la première erreur du découpage n’est pas technique, c’est de couper au mauvais endroit. Et ce mauvais endroit ne saute pas aux yeux quand on a le nez dans le code depuis des années.
Un monolithe se découpe par le métier : avant de sortir le moindre service, on cartographie les domaines réels et leurs coutures. Ignorer ces frontières, c’est se refabriquer le couplage de départ, mais en pire, car il passe désormais par le réseau, avec la latence et les pannes qui vont avec.
Le métier décide, pas la technique
La tentation classique consiste à découper par couche : un service pour les contrôleurs, un autre pour l’accès aux données, parce que c’est lisible sur un schéma d’architecture. Variante tout aussi répandue, on attaque par le bout de code qu’on a sous la main, celui qu’on connaît le mieux. Les deux mènent au même mur. Ces découpes traversent les domaines métier en diagonale et font exploser le nombre d’appels entre services. Vous troquez un couplage interne, gênant mais gratuit, contre un couplage réseau qui se paie en latence et en pannes.
Le bon critère reste le domaine métier : la facturation, le catalogue, les comptes clients, les commandes. Chacun avec son vocabulaire, ses règles, son cycle de vie.
Une frontière saine se reconnaît à deux signes. Les échanges avec le reste sont rares et passent par un contrat net (le domaine commandes demande un prix au catalogue, point), et la cohérence interne tient toute seule, les données et les règles du domaine se suffisant à elles-mêmes. À l’inverse, deux modules accrochés aux mêmes tables, qui s’appellent dix fois par requête, ne forment qu’un seul domaine. Le couper en deux, c’est le massacrer.
Cartographier avant de toucher au code
Concrètement, je commence toujours par dessiner. Quels domaines existent vraiment, qui dépend de qui, où sont les zones de bavardage intense. Sur un applicatif d’une taille respectable, ça tient sur une feuille A3 et quelques flèches. Cette carte fait remonter les candidats à l’extraction : en général un domaine périphérique, faiblement couplé, qu’on peut sortir sans réveiller toute la maison, exactement comme l’export comptable de tout à l’heure.
Et quand le code n’a aucune frontière nette, juste un gros plat de spaghettis ? C’est fréquent, et c’est le signe qu’il ne faut pas découper tout de suite. On remet d’abord des frontières à l’intérieur du monolithe : des modules clairs, des contrats explicites. Une fois les coutures présentes dans le code, l’extraction devient mécanique. Sauter cette étape revient à découper à l’aveugle, et un découpage qui ignore les frontières vous rend la rigidité du monolithe augmentée de la latence réseau. Le pire des deux mondes.
En pratique
Si vous deviez retenir un seul geste : avant la moindre ligne de code, asseyez-vous avec la personne qui connaît le métier, pas l’architecture, et faites-lui raconter le cycle de vie d’une commande ou d’une facture. Notez où le récit change de vocabulaire. Ces ruptures de langage sont vos frontières. Elles valent toutes les analyses de dépendances réunies, et elles vous coûtent une matinée plutôt qu’un découpage à recoller en prod.