Reprendre la main sur un système devenu difficile à faire évoluer

Comment on s’en aperçoit

Rarement par une panne. Plutôt par une dérive : une demande simple prend trois semaines, plus personne ne sait dire ce qui casse si l’on touche à tel module, les mises en production se font le vendredi soir et font peur, et chaque nouveau besoin s’ajoute par-dessus au lieu de s’intégrer.

Ce sont des symptômes d’architecture, pas de compétence. Une équipe excellente sur un système mal découpé produira les mêmes délais qu’une équipe moyenne — la différence se joue dans les dépendances, pas dans le code.

Un état des lieux avant une cible

Nous commençons par cartographier ce qui existe : les applications, ce qui les relie, où vivent les données, ce qui dépend de quoi, ce qui n’est plus maintenu et ce que plus personne ne sait redéployer. Cette étape produit souvent la première décision utile, avant tout projet — il y a presque toujours des choses à débrancher.

Vient ensuite la cible, et surtout la trajectoire : l’ordre dans lequel y aller, ce qui peut attendre, ce qui doit passer en premier parce que tout le reste en dépend. Une cible sans trajectoire est un document ; c’est le chemin qui a de la valeur.

Des choix argumentés, pas des choix à la mode

Nos consultants portent plusieurs casquettes — architecte IT, responsable infrastructure, CTO, DevOps, lead développeur — et nous exploitons nous-mêmes une infrastructure depuis 2001. Cela nous rend prudents sur les architectures élégantes qui ne s’exploitent pas.

Découper un monolithe en microservices, par exemple, résout des problèmes réels et en crée d’autres : plus de réseau, plus de pannes partielles, plus d’outillage à tenir. Nous poserons la question du gain avant celle de la méthode, et il nous arrive de conclure qu’un monolithe bien découpé est la bonne réponse.

Découper selon le métier, pas selon la technique

La question qui revient sur toute refonte : où passer les frontières ? La réponse habituelle découpe par couche technique — une brique pour la base, une pour les écrans, une pour les traitements. C’est le découpage le plus intuitif, et le moins utile : la moindre évolution fonctionnelle traverse alors les trois.

Nous découpons par domaine métier. La facturation, le suivi de production et la relation client ne parlent pas de la même chose, même quand ils emploient les mêmes mots — « commande » ne désigne pas la même réalité dans un atelier et dans un service comptable. Reconnaître ces frontières, plutôt que d’imposer un modèle unique à tout le système, est ce qui permet ensuite de faire évoluer une partie sans réveiller les autres.

C’est aussi ce qui rend une trajectoire de refonte praticable : on bascule un domaine, puis un autre, chacun ayant sa propre valeur — au lieu d’un grand soir qu’il faut réussir en une fois.

Jusqu’où nous allons

L’étude seule laisse un rapport. Nous accompagnons donc la mise en œuvre : présence pendant les premières étapes, choix d’outillage, revue des décisions au fil de l’eau. Vos équipes gardent la main ; nous sommes là pour que la trajectoire tienne quand elle rencontre le réel.