On croit souvent que découper un monolithe commence par s’attaquer au plus vilain morceau, celui dont tout le monde se plaint en réunion. C’est là que ça dérape neuf fois sur dix. Le code le plus repoussant à lire n’est presque jamais celui qui coûte le plus cher.
Pour décider quoi découper en premier, je croise trois signaux : à quelle fréquence chaque zone change, combien de bugs elle concentre, à quel point elle freine les évolutions. Là où ça se recoupe, l’extraction se rentabilise. « Par où commencer ? » reste la vraie question, et y répondre à l’instinct revient à réécrire ce qui choque l’œil pendant que la zone qui saigne continue de saigner.
La dette qui compte n’est pas celle qu’on voit
Du code mal écrit mais stable, qu’on ne rouvre jamais, ne coûte rien. Il tourne, on le laisse tourner. Le réécrire au nom de l’élégance, c’est du gaspillage déguisé en bonne pratique. La dette qui fait mal vit ailleurs : dans les zones qu’on modifie sans arrêt et qui résistent. Chaque évolution y devient lente, risquée, et finit par traîner sa série de régressions. Voilà ce qui vous ruine, pas le module moche que personne n’ouvre.
Trois signaux, et pourquoi je les croise
Pris isolément, aucun des trois ne vaut grand-chose. C’est leur recoupement qui désigne une cible.
D’abord la fréquence de modification, que l’historique Git livre tout seul : sortez les fichiers les plus touchés sur les douze derniers mois, un git log un peu travaillé suffit. Ce sont vos points chauds. Vient ensuite le taux de bugs. Quelles zones reviennent sans cesse en réparation ? Du code qui repasse en correctif tous les quinze jours vous parle assez clairement. Reste la difficulté à faire évoluer, et là on quitte le mesurable : où les développeurs ralentissent-ils, où une petite demande métier se transforme-t-elle en chantier à risque ? Neuf fois sur dix, le couplage est en cause.
Maintenant, superposez. Une zone qui cumule forte fréquence, bugs récurrents et couplage lourd n’est plus une opinion, c’est une priorité. C’est là que l’extraction se rembourse, parce qu’on y revient en permanence.
De la mesure à la décision
Une fois ces zones repérées, je les pose sur la cartographie des domaines métier. Quand une zone chaude tombe pile sur un domaine extractible et peu couplé, vous tenez votre premier candidat : fort retour parce qu’on y travaille souvent, risque maîtrisé parce que le couplage est limité. On commence par là.
Sauf que le cas inverse arrive plus souvent qu’on aimerait. Une zone brûlante, mais enchevêtrée dans tout le reste. Sur un monolithe industriel d’une grosse dizaine d’années que j’ai accompagné, le candidat « évident » était justement le plus emmêlé : tenter l’extraction directe aurait fait tomber la moitié de l’application. Six semaines à découpler en interne avant de pouvoir seulement toucher au réseau. Ce travail-là se voit venir et se planifie comme un chantier à part entière ; le découvrir en cours de route, c’est le scénario qui fait déraper un budget.
Ce que ça vous évite
Vous cessez de réécrire du code stable sous prétexte qu’il est moche. Et vous arrêtez de laisser pourrir une zone fragile parce qu’elle marche encore, jusqu’au jour où elle lâche au plus mauvais moment. Chaque heure part là où elle se rembourse. Le reste attend son tour.
Là où la méthode a ses limites
Je ne vous vendrai pas cette mesure comme une vérité. Elle regarde le passé : douze mois d’historique disent où ça a chauffé, pas où ça chauffera. Une réorganisation produit, un changement de réglementation, un client qui pèse soudain trois fois plus, et une zone tranquille devient critique du jour au lendemain. Aucun git log ne l’avait anticipé. Le diagnostic vous donne un point de départ solide, à condition de le relire quand le contexte bouge. Figé une fois pour toutes, il vieillit aussi vite que le code qu’il décrit.