Le coût caché d'un logiciel qui marche — et pourquoi je le corrige avant qu'il n'explose

Cette semaine, j'ai retravaillé en profondeur une application qui n'avait aucun bug, aucune plainte utilisateur, et n'a pas gagné une seule fonctionnalité au passage. C'est probablement le chantier le plus rentable que j'aie fait cette année. Voici pourquoi.

Le vrai problème : le coût d'un ajout augmente avec la taille de l'application

Une petite application de gestion des stages pour une faculté de médecine avait été construite vite, pour une bonne raison : en phase de découverte, la seule question qui compte est « est-ce qu'on a bien compris le besoin ? », pas « le code est-il élégant ? ». Tout tenait dans un seul bloc de logique, sans découpage — le bon choix, à ce stade-là.

Mais ce choix a un coût, et ce coût ne se voit pas tout de suite : il grandit avec l'application. Modifier un seul détail — la disponibilité d'un médecin, par exemple — obligeait à recharger tout le bloc, comprendre tout le contexte, et accepter un risque de casser autre chose ailleurs, sans moyen simple de prouver que le reste n'avait pas bougé.

Et ce problème touche autant un développeur humain qu'un agent IA. Un agent ne peut raisonner correctement que sur un périmètre qu'il peut charger et vérifier entièrement. Face à un bloc de logique sans découpage, il doit tout recharger à chaque modification — plus de risque d'erreur, moins de certitude sur le résultat, et aucune façon mécanique de vérifier que rien d'autre n'a été cassé.

Pourquoi on ne réécrit jamais tout d'un coup

La bonne réponse n'est pas de tout reconstruire d'un bloc — trop risqué, trop long, et ça immobilise le service. La bonne réponse est de migrer une zone à la fois, et surtout de poser un filet de sécurité avant de toucher à la moindre règle métier.

Concrètement, la méthode suit toujours le même ordre :

Mesurer avant de bouger — cartographier précisément ce qui existe, sans rien changer.
Poser le filet de sécurité — une suite de vérifications qui capture le comportement actuel de l'application, dans le détail. Rien n'est déplacé tant que ce filet n'est pas fiable à 100 % : migrer sans lui reviendrait à migrer sur du sable.
Extraire zone par zone — chaque étape est vérifiée avant de passer à la suivante.
Verrouiller — les vérifications deviennent automatiques et bloquantes, pour que le problème ne puisse plus se reformer en silence.
Prouver, puis faire valider par un humain — on remesure ce qui a été mesuré au départ, pour prouver que rien n'a régressé, et une personne valide avant de considérer l'étape terminée.

Sur le premier périmètre migré : 16 fonctionnalités sur 16 déplacées, 170 vérifications automatiques prouvant que le comportement externe reste identique, un audit de sécurité entièrement rejoué — et l'application n'a jamais cessé de tourner pendant l'opération.

Ce que ça change pour le prix de vos futures évolutions

Voici le vrai bénéfice, celui qui compte pour vous : une fois ce travail fait, modifier un détail précis — la disponibilité d'un médecin, dans notre exemple — ne touche plus qu'une petite zone bien délimitée du code, pas l'ensemble de l'application. Que l'application ait 10 fonctionnalités ou 100, une modification bien délimitée coûte à peu près la même chose à chaque fois. Le coût cesse de grimper avec la taille du projet.

C'est aussi ce qui rend la délégation à un agent IA réellement fiable dans la durée : un agent ne peut travailler en confiance que sur un périmètre qu'il peut charger et vérifier en entier. Une application construite en un seul bloc devient, avec le temps, structurellement difficile à confier à un agent — même bien encadré. Une application découpée en zones vérifiables reste, elle, confiable à n'importe quelle taille : c'est ce qui me permet de cadrer le travail et de vérifier le résultat, plutôt que de tout relire ligne par ligne à chaque changement.

Qui décide quoi

Je n'agis jamais avec une responsabilité dont je ne pourrais pas répondre. Concrètement, appliqué à ce type de travail :

L'agent IA exécute et tranche ce qui est délimité et vérifiable mécaniquement : comment structurer un module, comment figer un comportement existant.
Vous décidez quoi construire, dans quel ordre, pour quel besoin — jamais comment le code est organisé en interne.
Moi, j'interviens sur ce qui engage réellement : le découpage retenu, ce qui reste ou disparaît de l'ancien code, les décisions difficiles à annuler. Ces points-là sont validés à la décision, pas relus commit par commit.

Pourquoi le bon moment, c'est maintenant — pas plus tard

Ce type de remise à plat coûte le moins cher quand l'application est encore petite : moins de code à sécuriser, moins de zones à couvrir. Si vous attendez que les demandes s'accumulent, vous ferez ce même travail plus tard — en même temps que les nouvelles fonctionnalités, sur un système déjà en usage réel, avec vos utilisateurs comme filet de test. C'est exactement le scénario que cette méthode permet d'éviter.

Ce que ça signifie pour votre projet

Si votre application a été construite vite pour valider une idée — ce qui est souvent le bon choix — la question à se poser n'est pas « faut-il tout refaire ? » mais « combien coûtera votre prochaine évolution dans six mois, si rien ne change d'ici là ? ». Si la réponse n'est pas claire, c'est le moment d'en parler — contactez-moi pour qu'on regarde ça ensemble.