Votre MVP vibe-codé est une boule de boue (et ce n'est pas grave si vous le savez)

Le scénario est devenu banal. Une petite entreprise a une idée d'outil interne, de portail client ou d'application métier. Plutôt que de payer un développeur, quelqu'un dans l'équipe ouvre un assistant de code, décrit ce qu'il veut en français, corrige, redemande, sans jamais vraiment lire le code produit. C'est ce qu'on appelle le vibe coding : on pilote au ressenti, l'IA écrit. Au bout de quelques semaines, ça tourne, et de vrais clients s'en servent. Puis arrive le jour où il faut aller plus loin : une fonctionnalité que l'IA n'arrive plus à ajouter sans casser autre chose, un bug que personne ne sait localiser. Et on appelle un développeur.

Ce billet s'adresse à la personne qui va passer cet appel. Je ne vais pas lui faire la morale : le vibe coding a servi à valider une idée vite et pour pas cher, c'est déjà beaucoup. Je veux plutôt lui dire ce qu'elle a probablement entre les mains, ce qu'elle peut faire cette semaine, et comment juger le développeur qu'elle va recevoir.

Ce que vous avez probablement entre les mains

Le Nielsen Norman Group a publié début octobre un article de Tanner Kohler, « The New Big Ball of Mud ». La « grosse boule de boue », c'est un vieux nom d'informaticien pour un logiciel sans plan lisible, fait de rustines empilées, que tout le monde maintient et que plus personne ne comprend. Ce que Kohler ajoute, c'est l'effet de l'IA : construire ne coûte presque plus rien, donc on construit trop. Un des participants de son étude le résume ainsi : parce que l'IA rend la construction si facile, les gens se mettent à surconstruire.

Le point qui devrait vous inquiéter concerne la compréhension. Avec le temps, écrit Kohler, même la personne qui a construit le système en perd le fil et dépend de l'IA pour s'y retrouver. Si votre collaborateur ne sait plus expliquer pourquoi l'outil marche, il n'a pas démérité, il est dans le cas normal de ce mode de fabrication.

Le coût de fabrication a baissé, pas le coût de compréhension

C'est là que se loge le malentendu. Le MVP a coûté peu, donc on s'attend à ce que sa reprise coûte peu aussi. Or ce qui a baissé, c'est le coût d'écrire du code. Le coût de comprendre du code, lui, n'a pas bougé. Le développeur qui arrive doit toujours lire, reconstituer les intentions, vérifier ce qui marche vraiment. Et dans un projet construit par conversation, les intentions ne sont écrites nulle part : elles dorment dans un historique de discussion que personne n'a gardé.

Personne ne vous reproche d'avoir avancé vite : pour valider l'idée, c'était le bon choix. Reste que le temps de compréhension, c'est vous qui allez le payer. Un article de DEV Community paru la même semaine cite une formule de Google Cloud qui dit bien les choses : l'IA ne répare pas une équipe, elle amplifie ce qui est déjà là.

Cette semaine, avant d'appeler

Quatre gestes, aucun ne demande de savoir coder. La plupart reviennent au collaborateur qui a construit l'outil, avec vous en appui.

Geler les nouvelles demandes. Chaque fonctionnalité ajoutée maintenant agrandit ce que le développeur devra comprendre, et donc la facture. Corrigez ce qui bloque vos clients, rien de plus.

Sauvegarder l'historique des conversations avec l'IA. S'il existe encore, le collaborateur l'exporte depuis l'outil qu'il a utilisé (la plupart proposent un export ou un partage de conversation). C'est le seul endroit où sont consignées les intentions, et c'est une mine pour quiconque reprend le projet.

Faire la liste des accès. Qui peut entrer dans l'outil en ligne, dans l'hébergement, dans la base de données, dans les comptes des services branchés (paiement, envoi d'e-mails…). Un MVP monté en vitesse sème souvent des « clés d'API », ces mots de passe que les logiciels utilisent entre eux, un peu partout, parfois en clair dans le code. Faites la distinction : si un ancien stagiaire ou un prestataire parti a encore un compte, coupez-le maintenant. Les clés utilisées par l'outil, en revanche, notez-les sans y toucher : en révoquer une encore en service, c'est casser la production vous-même. Leur remplacement revient au développeur.

Vérifier qu'une sauvegarde existe et qu'on sait la restaurer. Pas seulement qu'elle existe : que quelqu'un l'a déjà remise en place une fois. Une sauvegarde jamais restaurée, on ne sait pas si elle marche. Si votre collaborateur ne sait pas répondre, posez la question à votre hébergeur, puis notez-la pour le développeur.

Ce qu'un développeur vous demandera dès le premier jour

L'article de DEV liste six éléments à préparer avant l'arrivée d'un premier développeur. Les voici traduits pour une PME, avec qui peut s'en charger chez vous.

1. Un projet qui démarre ailleurs que chez son auteur. Le développeur doit pouvoir récupérer le code et le lancer sur son ordinateur en moins d'une heure. Qui : le collaborateur qui l'a construit. S'il n'y arrive pas sans l'assistant, notez-le, c'est une information utile.
2. Une carte d'une page. Quels services sont utilisés, où sont les données, comment les utilisateurs se connectent, quels outils sont branchés. Qui : vous. Une liste suffit, et vous la connaissez mieux que vous ne le croyez, parce que vous recevez les factures.
3. Les décisions et leurs raisons. Pourquoi ce prestataire de paiement, pourquoi ce parcours d'inscription bizarre. Qui : le collaborateur. Si la réponse est « l'IA l'a proposé », écrivez-le : le développeur saura qu'il peut remettre ce choix en question sans casser une contrainte cachée.
4. La liste de ce qui ne doit jamais casser. La prise de commande, l'envoi de devis, et surtout l'étanchéité entre clients. Qui : vous. Vous ne pouvez pas écrire les tests automatiques qui vérifieront tout ça, mais vous pouvez écrire la liste.
5. Une procédure de mise en ligne et de retour en arrière. Comment on publie une nouvelle version, comment on revient à l'ancienne si ça casse. Qui : le collaborateur, à défaut le développeur, qui la rédigera en premier.
6. La liste des accès, celle de la section précédente.

Comment juger le développeur qui reprend

Arrive le moment que beaucoup de clients redoutent : le développeur annonce qu'une partie est à refaire. On l'entend comme un verdict, voire comme une manœuvre pour gonfler le devis. Kohler propose de le voir autrement : le but n'a jamais été d'éviter la reconstruction, mais de rester en position de la diriger. Un MVP vibe-codé a fait son travail s'il a validé l'idée ; qu'une partie soit ensuite reconstruite proprement, c'est le chemin normal. Ce qui coûte cher, c'est de reconstruire en urgence parce que tout a lâché un vendredi soir.

Encore faut-il que la reconstruction soit justifiée, et pas seulement confortable pour le prestataire. Une reprise honnête suit généralement trois étapes. D'abord un audit court et payant, à durée fixée d'avance. Il se compte en jours de travail : demandez combien, et ce que vous aurez en main à la fin. Si vous consultez deux développeurs, comparez ce qu'ils promettent de livrer, pas seulement le prix. Ensuite un document de sortie que vous pouvez lire : l'état des lieux, les risques classés par gravité, et plusieurs options (consolider, refaire une partie, refaire le tout) avec leurs avantages et leurs inconvénients. Enfin un chiffrage par lots, que vous pouvez arrêter après chacun.

Ensuite, quelques signaux qui doivent vous alerter :

• une refonte totale annoncée avant d'avoir lu le code ;
• un devis global sans étape intermédiaire où vous pouvez dire stop ;
• le refus de documenter ce qui est fait, ou de vous laisser la propriété du code et des accès ;
• aucune réponse claire à la question « qu'est-ce qui sera vérifié en premier ? ».

Et une question à poser dès le premier appel : comment saura-t-on que la reprise avance ? L'article de DEV propose une mesure simple, le nombre de jours avant la première modification mise en ligne par le nouvel arrivant. Je ne vous donnerai pas de seuil, il dépend trop du projet. Mais ce délai doit se raccourcir d'une modification à l'autre. S'il stagne, posez des questions.

Votre MVP est probablement une boule de boue. Ce n'est pas grave tant que vous le savez et que vous préparez la suite. Ce qui est grave, c'est de le découvrir au moment où il ne tient plus.

Sources

• Tanner Kohler, « The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile », Nielsen Norman Group, 2 octobre 2026 : nngroup.com/articles/big-ball-of-mud-ai
• « Your first engineering hire inherits an AI-built codebase: what has to be ready on day one? », DEV Community, 4 octobre 2026 : dev.to
• Brian Foote et Joseph Yoder, « Big Ball of Mud », 1997-1999, le texte d'origine de l'expression : laputan.org/mud
• CNIL, « Les violations de données personnelles » (notification sous 72 heures) : cnil.fr

The Interstice, développement web freelance. Entre le pixel et l'idée.