Le vibe coding a trahi sa promesse

Albert Santalo • avr. 2026 • 9 min de lecture

Passez une heure sur n’importe quel forum de constructeurs et vous trouverez le même aveu écrit de cent façons différentes. Quelqu’un a construit son application en un week-end avec un outil d’IA. Ça marchait. Il l’a livrée. Nous sommes lundi et l’authentification est cassée, la base de données perd silencieusement des lignes, et le bug que personne ne parvient à reproduire est celui qui lui coûte des clients.

Le rêve que nous nous sommes vendu les uns aux autres il y a six mois se présente à la porte pour réclamer son remboursement.

Je veux faire attention à la façon dont je le dis, parce que je ne pense pas que les personnes qui ont construit ou utilisé ces outils avaient tort d’être enthousiastes. Le saut était réel. Voir une interface fonctionnelle se matérialiser à partir d’un paragraphe en langage courant est l’une des expériences véritablement magiques de la dernière décennie du logiciel. Je l’ai ressentie aussi. Nous l’avons tous ressentie.

Mais quelque part entre la démonstration et le déploiement, une substitution silencieuse s’est produite. Nous avons commencé à appeler les prototypes des produits. Nous avons commencé à appeler les démonstrations des logiciels. Et la facture de cette confusion arrive maintenant à échéance.

L’erreur de diagnostic

L’explication la plus courante que je vois pour justifier ce phénomène accuse le modèle. L’IA n’est pas encore assez intelligente. Elle hallucine. Elle choisit les mauvaises bibliothèques. Elle écrit du code qu’un ingénieur expérimenté repérerait et réécrirait.

Cette explication est rassurante parce qu’elle suggère un correctif déjà en route. Attendez six mois. Le prochain modèle sera meilleur. À terme l’écart se referme et tout fonctionne.

Je n’y crois pas. Et je n’y crois pas parce que le mode de défaillance que je vois sans cesse n’a rien à voir avec la qualité du code.

Microsoft a indiqué lors de sa présentation de résultats de 2025 qu’environ 46 % de tout le code livré par les utilisateurs actifs de GitHub Copilot est désormais généré par IA. À peu près à la même période, la société de sécurité applicative Veracode a publié une étude concluant que le code généré par IA introduisait des vulnérabilités de sécurité dans environ 45 % des échantillons testés. Ces chiffres vont empirer avant de s’améliorer, et un modèle plus intelligent ne les corrigera pas.

Le modèle n’est pas le problème. Le processus l’est.

Ce qui manque réellement

Décrivez-moi comment se construit une application faite en vibe coding et dites-moi où se prend la décision d’architecture.

Vous décrivez ce que vous voulez. L’IA génère une interface et du code derrière. Vous regardez l’interface, vous cliquez un peu partout, elle fait à peu près ce que vous avez demandé, et vous considérez que c’est terminé. À aucun moment de cette boucle quelqu’un, humain ou machine, ne s’est arrêté pour définir ce qui était réellement construit.

Il n’y a pas de schéma. Il n’y a pas de modèle de données. Il n’y a pas de liste des états dans lesquels le système peut se trouver ni de définition de ce qui compte comme valide. Il n’y a pas de contrat entre le frontend et ce qui prétend être un backend. Il n’y a aucune décision sur ce qui se passe quand l’utilisateur fait quelque chose que le générateur n’a pas anticipé, parce que personne ne l’a anticipé.

Ce qui a été construit est une chose qui ressemble à celle que vous avez demandée, sur le chemin précis que vous avez emprunté pendant la démonstration. Sortez de ce chemin et toute la structure se révèle n’être qu’un échafaudage. Il n’y a jamais eu de bâtiment en dessous.

Ce n’est pas un échec de l’intelligence. C’est un échec de la définition. Et aucune quantité d’intelligence supplémentaire appliquée à un problème non défini ne produira un résultat défini. Elle produira simplement une version plus convaincante du même échafaudage.

Les trois décisions qui n’ont jamais été prises

Soyons précis, parce que c’est par les abstractions que cette conversation tourne en rond.

L’authentification n’est pas une fonctionnalité que l’on ajoute plus tard. C’est une décision sur qui sont vos utilisateurs, ce qu’ils peuvent voir et sur quelle frontière de confiance repose votre application. La greffer sur une application faite en vibe coding deux semaines après le lancement est l’équivalent logiciel d’installer une porte d’entrée sur une maison bâtie sans murs.

Un schéma de base de données n’est pas quelque chose qu’une IA devrait deviner pendant qu’elle génère le formulaire qui écrit dedans. Le schéma est la colonne vertébrale de l’application. Chaque décision en aval (ce que vous pouvez interroger, ce que vous pouvez indexer, ce que vous pouvez changer plus tard sans tout casser) est contrainte par des choix faits ou non faits au départ. Quand le schéma est improvisé, chaque changement futur devient une rénovation.

Un contrat d’API n’est pas optionnel, et dans une économie où les agents d’IA consomment directement les logiciels, il est plus proche du produit que ne l’est l’interface. Dès l’instant où votre application parle à quoi que ce soit d’autre (un processeur de paiement, un service d’e-mail, un autre logiciel, un agent d’IA) il doit exister une surface définie. Sans elle, les intégrations deviennent une série de bricolages ponctuels que personne ne peut maintenir et dont personne ne veut hériter.

Ce ne sont pas des sujets avancés. C’est le minimum requis pour construire un logiciel qui survit à son premier week-end. Et ce sont précisément les choses que l’on saute quand tout le processus de construction consiste à décrire, voir, livrer.

Le problème des 70 % a maintenant un nom

Je ne pense pas que quiconque ait entrepris de bâtir une industrie qui livre du logiciel fragile. Je pense que les outils apparus dans cette catégorie ont optimisé le moment qui vend l’outil : le moment de magie, quand une idée devient un écran fonctionnel en moins d’une minute.

Le temps jusqu’à la magie est devenu la grandeur mesurable. Le temps jusqu’à la production était le problème de quelqu’un d’autre.

C’est une optimisation raisonnable pour une démonstration. C’est une optimisation désastreuse pour une catégorie de logiciels désormais chargée de livrer de vraies applications à de vrais utilisateurs avec de vrais enjeux financiers. Elle laisse toute une génération de constructeurs échoués à la barre des 90 %, avec une chose qui fonctionne sur leur écran et s’effondre partout ailleurs.

Les constructeurs de la communauté Lovable ont donné un nom à cela : le problème des 70 %. Vous atteignez quelque chose qui semble presque fini, puis le progrès s’arrête. Chaque correction casse autre chose. Le travail restant n’est pas un travail que vous pouvez traverser à coups de prompts, parce que ce qui vous bloque n’est pas du code manquant. C’est une décision manquante, prise silencieusement, plusieurs centaines de générations plus tôt.

Le sale secret de cette catégorie est que la partie facile était les 90 % initiaux. Les 9 % suivants (faire en sorte que ça marche vraiment pour plus d’un utilisateur, sur plus d’un appareil, dans des conditions que vous n’avez pas anticipées) sont plus difficiles que les 90 % initiaux réunis. Et le dernier 1 %, celui qui distingue une application fonctionnelle d’une application fragile, est la partie qui exige que vous ayez su ce que vous construisiez avant de commencer.

La règle que l’IA n’a pas changée

Voici ce que personne ne veut entendre, parce que cela sonne comme un pas en arrière dans un moment censé n’être que mouvement en avant.

Les meilleurs logiciels ont toujours commencé par une définition. L’architecture avant le code. Un modèle clair du problème avant qu’une ligne ne soit écrite. C’était vrai quand des équipes de cinquante ingénieurs construisaient des systèmes à la main, et c’est vrai aujourd’hui quand une personne et un modèle peuvent construire le même système en un week-end.

L’IA n’a pas changé cette règle. L’IA l’a rendue plus importante, pas moins.

Quand le coût de production du code approche zéro, le coût de production du mauvais code approche zéro aussi. Ce qui signifie que la seule chose qui ait encore un coût est de déterminer quel aurait été le bon code. Ce travail (le travail de définition, le travail d’architecture, le moment où vous décidez ce que vous construisez réellement avant de commencer à le construire) est la seule partie qui n’a pas été banalisée.

C’est aussi la partie que la génération actuelle d’outils a sautée.

Où cela mène réellement

Je ne pense pas que la réponse soit de ralentir. Je ne pense pas que la réponse soit de revenir à tout écrire à la main. Le saut était réel, et le saut reste.

La réponse est d’intégrer l’étape de définition dans la boucle, la pratique que le secteur appelle désormais développement guidé par la spécification. Pas comme une barrière manuelle qui vous ralentit, mais comme la fondation réelle sur laquelle repose le reste du travail. Ceux qui cherchent comment faire cela travaillent sur quelque chose de plus discret que ce que vous avez vu passer. Ils sont sur le point de faire apparaître la version bruyante de cette catégorie pour ce qu’elle a toujours été. J’ai écrit séparément sur ce à quoi ressemble réellement cette prochaine génération.

Un écran qui fonctionne n’a jamais été la même chose qu’un système qui fonctionne. Nous sommes tous sur le point de nous rappeler pourquoi.

Lectures liées

Ce qui l’a remplacé : le développement guidé par la spécification. Comment les outils se comparent aujourd’hui : les meilleurs constructeurs d’applications par IA en 2026.

Questions fréquentes

Que signifie « vibe coding » ? Le vibe coding consiste à écrire un logiciel en décrivant ce que l’on veut en langage courant et en acceptant ce que l’IA génère, sans spécifier l’architecture, le modèle de données ni les contrats en dessous. Andrej Karpathy a forgé le terme début 2025. Il décrit une méthode de travail, pas une catégorie d’outils : on peut faire du vibe coding dans presque n’importe quel constructeur par IA.

Pourquoi les applications faites en vibe coding cassent-elles en production ? Parce que la défaillance est structurelle, ce n’est pas un problème de qualité de code. La boucle de génération ne produit jamais de schéma, ni d’ensemble défini d’états valides, ni de contrat entre frontend et backend. L’application fonctionne sur le chemin de la démonstration et s’effondre en dehors. Un modèle plus intelligent appliqué à un problème non défini produit toujours un résultat non défini.

Qu’est-ce que le problème des 70 % ? C’est le schéma où une application construite par IA atteint environ 70 % d’achèvement puis cesse de progresser : chaque correction casse autre chose et aucune quantité de prompts supplémentaires ne comble l’écart. Le blocage est généralement une décision architecturale prise implicitement, des centaines de générations plus tôt, et qui ne peut plus être changée sans réécriture.

Le code généré par IA est-il moins sûr ? Les données actuelles disent qu’il a besoin d’être relu. L’étude de Veracode a trouvé que le code généré par IA introduisait des vulnérabilités de sécurité dans environ 45 % des échantillons testés, à un moment où Microsoft indiquait qu’environ 46 % du code livré par les utilisateurs actifs de GitHub Copilot était généré par IA. Le volume augmente plus vite que la vérification.

Cela veut-il dire qu’il ne faut pas utiliser les constructeurs d’applications par IA ? Non. Pour des prototypes, des démonstrations et des outils internes, ils sont véritablement excellents et la vitesse est réelle. L’argument ici est plus étroit : un écran qui fonctionne n’est pas un système qui fonctionne, et les outils qui sautent la phase de définition ne peuvent pas produire le second, quelle que soit la qualité du modèle.