La dette technique du vibecoding

Un projet vibecodé passe rarement mal le premier mois. Il fonctionne, il est joli, il a coûté trois fois moins cher que prévu. Les ennuis commencent vers le sixième, quand il faut modifier quelque chose et que plus personne ne sait où ni comment.

Ce décalage explique pourquoi le sujet est mal traité : au moment où l'on décide d'adopter le vibecoding, aucun des coûts n'est encore visible, et au moment où ils le deviennent, la décision est ancienne.

Une dette de nature différente

La dette technique classique résulte de compromis conscients. On sait qu'on a bâclé, on sait où, quelqu'un a écrit un commentaire ou ouvert un ticket. Elle est documentée par le fait même d'avoir été choisie.

La dette du vibecoding n'a pas été choisie. Personne n'a décidé que ce module dupliquerait la logique de celui d'à côté ; ça s'est produit parce que les deux ont été générés séparément, à deux semaines d'intervalle, sans que le modèle sache que le premier existait. Il n'y a donc ni trace, ni conscience, ni ticket.

Les quatre formes qu'elle prend

Le code que personne ne comprend

C'est la forme la plus directe. Le code fonctionne, il est même bien écrit, mais aucun humain du projet n'a de modèle mental de son fonctionnement. Tant que rien ne casse, ça n'a pas d'importance. Le jour où il faut corriger un comportement précis, on se retrouve à faire de l'archéologie sur du code écrit trois mois plus tôt par une machine.

Le test est simple et brutal : prenez un fichier au hasard et essayez d'expliquer à voix haute ce qu'il fait et pourquoi il le fait comme ça. Si vous n'y arrivez pas pour plus d'un tiers des fichiers, la dette est déjà installée.

L'architecture accidentelle

Chaque demande produit une réponse localement raisonnable. Additionnées, ces réponses forment une structure que personne n'a dessinée. On se retrouve avec trois façons différentes d'accéder aux données, deux conventions de nommage, et une logique métier éparpillée entre l'interface et le serveur selon l'ordre dans lequel les écrans ont été générés.

Ce n'est pas de la mauvaise architecture, c'est de l'architecture par sédimentation. Elle rend chaque modification imprévisible : on ne sait pas si changer une chose en cassera une autre, parce qu'aucune règle ne dit ce qui dépend de quoi.

La duplication invisible

Le modèle ne se souvient pas d'avoir déjà écrit une fonction de formatage de date. Il en réécrit une, légèrement différente, dans chaque fichier qui en a besoin. Toutes marchent. Le jour où le format doit changer, il faut les trouver toutes — et rien n'indique combien il y en a.

Cette duplication est plus dangereuse que la duplication classique, parce que les copies ne sont pas identiques. Une recherche textuelle ne les trouve pas toutes.

L'absence de filet

Sans demande explicite, il n'y a pas de tests. Combinée aux trois formes précédentes, cette absence produit la situation qui bloque vraiment un projet : du code que personne ne comprend, dont la structure est imprévisible, et qu'on ne peut pas modifier sans risquer de casser quelque chose qu'on ne saura pas détecter.

Le seuil où regénérer coûte moins cher que corriger

Il existe un renversement propre au vibecoding, sans équivalent en développement classique : à partir d'un certain point, il devient moins coûteux de jeter un module et de le redemander depuis une description propre que de comprendre l'existant pour le réparer.

C'est une bonne nouvelle et un piège. Une bonne nouvelle parce que ça offre une sortie que la dette classique n'offre pas. Un piège parce que regénérer efface aussi les corrections accumulées — les cas particuliers traités un par un après des retours d'utilisateurs, et que personne n'a documentés.

Limiter les dégâts sans ralentir

L'objectif n'est pas d'appliquer au vibecoding toute la rigueur du développement classique — ce serait renoncer à ce qui le rend utile. Il s'agit de placer quelques contraintes aux endroits où elles rapportent le plus.

1. Fixez les conventions avant de générer : où vivent les données, comment on nomme, ce qui va côté serveur. Cinq lignes suffisent, et elles évitent l'architecture par sédimentation.
2. Donnez au modèle le contexte de l'existant plutôt qu'une demande isolée. La duplication invisible vient presque toujours d'une demande formulée hors contexte.
3. Testez les frontières, pas l'intérieur. Les tests unitaires du code généré ont peu de valeur ; les tests qui vérifient qu'un parcours complet fonctionne en ont beaucoup.
4. Imposez la règle du fichier explicable : rien ne part en production si personne ne sait dire ce qu'il fait. C'est la contrainte la plus efficace, parce qu'elle force la relecture sans imposer de la rigueur partout.
5. Datez et isolez les prototypes. Un dossier séparé et une note « généré le tant, non relu » évitent qu'un prototype devienne un produit par accident.

Aucune de ces règles ne ralentit la génération. Elles agissent sur ce qui l'entoure — le cadrage avant, la relecture après — c'est-à-dire exactement là où le vibecoding ne fait gagner aucun temps de toute façon.