Revoir l'architecture en cours de projet n'est pas un échec de conception

Une équipe reprend tout le modèle de données, en plein développement

Une application est déjà en développement depuis plusieurs semaines quand l'équipe technique revient avec une proposition : reprendre intégralement le modèle de données. Pas parce que la première version était fausse, elle fonctionnait, les premiers écrans tournaient dessus. Mais parce qu'elle avait été pensée de façon conceptuelle, pour représenter les grandes entités du métier, pas pour porter l'ensemble des règles que le code doit maintenant gérer au quotidien. L'équipe ajoute des tables intermédiaires, clarifie des relations qui restaient implicites, rend l'ensemble lisible pour quiconque devra le reprendre dans six mois. La logique métier, elle, reste exactement la même avant et après : rien de ce que l'utilisateur final voit à l'écran ne change, seule la façon dont le système range l'information en interne se précise.

Le réflexe le plus courant, côté client, face à cette annonce, est de l'entendre comme un aveu : on aurait dû le faire bien dès le départ. Ce réflexe est compréhensible. Il est aussi, dans la majorité des cas, faux.

Ce réflexe s'explique facilement. Un client qui finance un projet associe naturellement « refaire » à « perdre du temps déjà payé », surtout si personne ne prend la peine de lui expliquer ce qui a changé entre le premier jour et aujourd'hui. Le silence sur ce point, plus que la refonte elle-même, est souvent ce qui transforme un ajustement sain en motif d'inquiétude légitime.

Ce que ce moment révèle réellement

Une équipe qui redéfinit son architecture en cours de route ne corrige pas une erreur, elle documente le fait qu'elle comprend mieux le problème qu'au premier jour. Un schéma de données conçu avant d'avoir écrit la moindre ligne de code reste, par construction, une hypothèse : il représente ce que l'équipe croyait savoir du métier au moment du cadrage. Le code réel, lui, confronte cette hypothèse à des cas que personne n'avait formulés explicitement, une typologie de statuts qui manquait, une relation à plusieurs qui avait été modélisée comme une relation simple. Ajuster la structure à ce moment-là n'est pas revenir en arrière, c'est avancer avec une information qui n'existait pas avant.

Le vrai risque n'est pas de devoir ajuster l'architecture en cours de route. C'est de refuser de le faire par peur que ce geste soit lu comme un échec, et de bloquer ainsi le système dans une structure rigide alors même que l'équipe a déjà identifié ce qui ne fonctionne pas.

Pourquoi le code en dit plus qu'un schéma conceptuel

Sur un projet de gestion des tâches, l'équipe technique a pu avancer plusieurs semaines sur un modèle de données qui restait volontairement incomplet sur un point précis : la typologie des assignations, les règles qui définissent comment telle action doit s'interpréter selon le contexte. Ce vide n'a bloqué ni le début du développement, ni les premières fonctionnalités livrées sur les notifications et les événements associés. Il n'est devenu un sujet à trancher qu'une fois que le code a buté dessus concrètement, au moment précis où l'ambiguïté cessait d'être tolérable.

C'est précisément cet ordre qui distingue une architecture qui mûrit d'une architecture bloquée dès le départ. Vouloir trancher la typologie des assignations avant d'avoir écrit la première notification aurait immobilisé l'équipe sur une question encore abstraite, sans aucun cas réel pour arbitrer entre les options possibles. Attendre que le code la fasse remonter de lui-même, au moment où elle devient concrète, coûte moins cher que de la deviner à froid.

« Les choses du modèle de données qui vont peut-être nous manquer, c'est d'avoir une typologie sur les assignments, se dire celui-là on va l'interpréter comme ça ou comme ça. Mais en fait, ce n'est pas bloquant encore pour le début du code où il y a quand même plein de choses à faire sur les notifications, les events. »

Converger, pas prédire : le principe

Chez Leando, ce principe s'appelle converger, pas prédire : la meilleure architecture n'est pas celle pensée exhaustivement avant le premier commit, c'est celle qui se corrige une fois le problème mieux compris au contact du code réel. Savoir refactorer au bon moment, sur un périmètre précis, est une compétence stratégique au même titre que savoir cadrer correctement en amont. Les deux exercices ne s'opposent pas : le cadrage fixe ce qui ne doit pas bouger (les règles métier non négociables, les scénarios qu'il faut couvrir), le reste de la structure technique reste ouvert à l'ajustement tant que le code n'a pas révélé ce qu'un schéma conceptuel ne pouvait pas anticiper.

Sur un projet de modernisation SI, ce principe change directement la manière dont une direction doit lire une demande de refactoring venant de son prestataire : non pas comme un retard à justifier, mais comme une preuve que l'équipe reste attentive à ce que le réel lui apprend plutôt que de livrer une architecture qu'elle sait déjà inadaptée. Cette logique rejoint celle qui gouverne une migration ERP menée par étapes plutôt qu'en big bang : avancer par paliers vérifiés coûte moins cher, au global, qu'une prédiction figée qu'il faudra défaire entièrement si elle se révèle fausse.

Où ce principe s'arrête : refactorer pour pouvoir faire, pas au cas où

Tous les refactorings ne se valent pas, et confondre les deux formes revient à transformer un principe sain en prétexte. Refactoriser pour débloquer une évolution stratégique déjà validée par le responsable du produit est un arbitrage légitime : le périmètre est connu, la décision est assumée, le coût est anticipé. Refactoriser « au cas où », pendant la correction d'un bug ponctuel, en élargissant progressivement le chantier à des parties du système qui fonctionnaient déjà, est un pari risqué qui multiplie les surfaces d'erreur sans garantie de valeur immédiate. Le symptôme se reconnaît facilement : une multiplication de chantiers ouverts en parallèle, un module qualifié d'« encore un peu instable » malgré l'ampleur de l'effort engagé, et personne qui ne peut dire précisément qui a validé l'élargissement du périmètre initial.

Un exemple concret de cette dérive : un développeur, chargé de corriger un bug de sélection sur un module existant, profite du chantier pour migrer l'ensemble vers une nouvelle API interne et nettoyer la dette technique accumulée autour. L'intention est bonne, le travail est réel, mais le product owner n'a validé que la correction du bug initial. Résultat typique : plusieurs chantiers de développement restent ouverts en parallèle, le module reste qualifié d'instable plusieurs semaines après le début de l'intervention, et la question de savoir si cette refonte élargie valait le coût engagé n'a jamais été posée à qui aurait dû trancher.

Le test tient en une question : quelqu'un en dehors de l'équipe technique a-t-il explicitement validé que ce chantier s'élargissait, et pourquoi ? Si la réponse est oui, avec une raison métier identifiable, c'est un refactoring qui fait converger l'architecture vers ce que le projet a appris. Si la réponse est non, le chantier a dérivé, indépendamment de la qualité du travail technique produit. Ce test rejoint directement l'esprit de notre article sur comment reprendre un code existant sans tout casser : figer d'abord ce qui fonctionne avant de toucher à la structure reste la meilleure manière de distinguer un ajustement maîtrisé d'une dérive de périmètre.

Ce que ça change dans la manière de piloter un projet sur mesure

Une direction qui comprend cette distinction change sa manière de suivre un projet. Elle ne demande plus seulement « est-ce que ça avance », elle demande « qu'est-ce que le code vient de nous apprendre sur le métier, et qu'est-ce que ça change dans la structure ». Elle accepte qu'une partie du système se précise en marchant, tout en exigeant que chaque élargissement de périmètre passe par une validation explicite plutôt que par un enchaînement silencieux de décisions techniques. Cette double exigence, accepter l'ajustement et refuser la dérive, est précisément ce qui distingue une architecture qui mûrit d'une architecture qui se dilue.

Concrètement, cela se traduit par une règle simple à instaurer avec votre prestataire ou votre équipe interne : toute proposition de refactoring s'accompagne d'une phrase qui nomme l'information nouvelle qui la justifie, et d'un périmètre précis, pas d'une formule vague du type « on en profite pour nettoyer un peu ». Cette règle ne ralentit pas les équipes compétentes, elle leur donne au contraire un langage commun pour distinguer, en quelques phrases, un ajustement qui fait avancer le projet d'un chantier qui a simplement perdu ses limites.

La prochaine fois qu'un prestataire propose de revoir une partie de la structure technique de votre projet, la question à poser n'est pas pourquoi ça n'a pas été pensé juste du premier coup. C'est quelle information nouvelle justifie ce changement, et quel périmètre précis il couvre. La réponse vous dira immédiatement si vous avez affaire à une architecture qui converge vers votre métier, ou à un chantier qui a simplement perdu ses limites.