Maintenir une application créée par IA : comprendre ce qu'on a fait construire

Le vibe coding marche jusqu'au jour où quelqu'un doit reprendre l'application. Deux témoignages, l'un d'un fondateur, l'autre d'un développeur français, décrivent le même mur. Ce qui le fait tomber tient dans un document que vous avez relu et validé.

Maintenir une application créée par IA bute sur un moment que décrit un fondateur sur Reddit (r/vibecoding, août 2026) : « Et d'un coup, le difficile n'est plus de construire. C'est de comprendre ce que vous avez construit. » Il énumère les signes : une fonction qui existe à deux endroits, un composant qui en fait trop, des fichiers que personne n'ose supprimer.

Le mur arrive après la livraison

La construction ne prévient pas. Les premières semaines sont grisantes : vous décrivez, l'outil produit, l'écran répond. Le mur se dresse plus tard, à la vingtième modification, quand une demande simple oblige à comprendre trois endroits du produit avant de toucher un seul. À ce stade, l'IA continue de produire du code, et c'est le sens de l'ensemble qui manque. Personne dans l'équipe ne peut dire pourquoi telle règle existe, ni ce qu'elle casse si on l'enlève.

Quand plusieurs mains touchent le même produit

Le même mur se dresse plus tôt à deux. Un développeur raconte sur Reddit (r/developpeurs, mai 2026) : « Mon manager intervient sur les projets sur lesquels je travaille en faisant du vibe coding. Résultat, les projets n'ont aucune structure, c'est un enfer à maintenir. » Il précise être le seul développeur de formation dans l'entreprise. Deux personnes qui décrivent leurs intentions à une IA, chacune de son côté, produisent deux moitiés d'application qui ne partagent aucune règle. La qualité de chaque moitié n'y change rien.

La spécification est la mémoire du produit

Un logiciel garde deux choses : le code qui tourne, et la raison pour laquelle il tourne ainsi. La deuxième vit dans la tête de qui l'a construit, et s'efface en quelques mois. Un cahier des charges validé la fixe par écrit, dans votre langue : ce que le produit doit faire, pour qui, avec quelles règles, et ce qu'il ne doit pas faire. Ce document se relit en un quart d'heure un an plus tard. C'est le sujet de vos spécifications vaudront plus cher que votre code, et la raison pour laquelle nous imposons une validation humaine avant chaque étape de construction.

Ce qui se régénère et ce qui ne se régénère pas

Avec un document qui décrit le produit et des tests écrits avant le code, une partie perdue se reconstruit : vous redemandez la construction de l'étape, les tests disent si le résultat tient. Sans ce document, la seule mémoire est le code lui-même, et le relire demande la compétence que vous avez cherché à éviter en faisant construire par IA. La différence se voit le jour où vous voulez changer de prestataire, d'outil ou de moteur : le code se refait, la connaissance de votre métier ne se refait pas.

Ce que les outils de génération rapide font mieux

Pour un prototype que vous montrez à un associé et que vous jetez la semaine suivante, tout ce qui précède est du poids inutile : Lovable, Bolt ou v0 vous donneront un écran vivant en une soirée, et aucun document ne vous manquera puisque rien ne survivra. La frontière entre les deux situations est celle que nous avons décrite dans prototype en une soirée, produit en une semaine. Elle se franchit sans prévenir, le jour où un premier client se sert de la chose.

Reprendre un produit déjà construit

Si vous êtes déjà de l'autre côté du mur, la reconstruction n'est pas le premier réflexe à avoir. Il existe un parcours de reprise : faire relire l'existant, en extraire les règles qui y sont enfouies, écrire le cahier des charges qui manquait, puis avancer par étapes vérifiées. Maestro le propose sur un logiciel existant, y compris construit par quelqu'un d'autre, et nous avons raconté ce que ce travail donne sur un outil vieillissant dans refondre un logiciel métier. Le coût de cette remise en ordre se compare à celui d'une année de maintenance, que nous avons chiffrée dans combien coûte la maintenance d'une application.

Le test des six mois

Ouvrez votre application et choisissez une règle métier au hasard : un calcul de remise, une condition d'envoi d'e-mail, un statut qui bloque une action. Essayez de l'écrire en trois phrases sans regarder le code, puis demandez la même chose à la personne qui a construit avec vous. Si vos deux versions diffèrent, ou si aucune ne vient, vous connaissez déjà l'état de votre mémoire produit. Écrire ces trois phrases coûte dix minutes par règle, et vaut mieux fait aujourd'hui que le jour où quelqu'un doit reprendre à votre place.