Piège du vibe coding :pourquoi les projets IA meurent

Le vibe coding — construire un logiciel en décrivant ce que vous voulez à une IA sans comprendre l'architecture sous-jacente — fonctionne à merveille pendant environ trois mois. Ensuite, chaque nouvelle fonctionnalité casse les anciennes, et la plupart des projets meurent dans le piège du vibe coding. Le piège, ce n'est pas l'IA. C'est la question de savoir qui prend les décisions d'architecture : personne.

Je vois le même cycle chaque semaine. Semaine 1 : « J'ai construit mon MVP SaaS en un week-end, l'IA, c'est magique ! » Semaine 4 : « J'ai ajouté 10 fonctionnalités cette semaine. » Semaine 12 : « Tout casse. Chaque nouvelle fonctionnalité en casse 3 anciennes. Je crois qu'il faut tout reconstruire à zéro. » Semaine 16 : « Le vibe coding, c'est de la foutaise. Je retourne au développement traditionnel. »

Des gens intelligents et capables. Un élan incroyable. Puis un mur si dur qu'ils abandonnent complètement. Voici pourquoi — et comment être l'exception.

Qu'est-ce que le vibe coding ?

Le vibe coding consiste à demander à une IA de construire des fonctionnalités sans prendre soi-même aucune décision d'architecture. « Construis-moi un tableau de bord utilisateur. » Livré. « Maintenant ajoute des équipes. » Livré. « Ajoute la facturation. » Livré. Chaque prompt fonctionne. Chaque fonctionnalité apparaît. Vous n'avez jamais décidé une seule fois comment les données sont structurées, comment les permissions fonctionnent, ni comment tout cela se relie.

Et l'expérience initiale est enivrante pour de vraies raisons : du code qui fonctionne en quelques minutes au lieu de quelques jours, aucune courbe d'apprentissage, des progrès tangibles à montrer aux autres. La dopamine est réelle. Les fonctionnalités marchent vraiment.

Jusqu'au jour où elles ne marchent plus. Car voici la vérité qui dérange : le vibe coding donne l'impression d'être productif parce que vous confondez activité et progrès. Livrer des fonctionnalités, c'est de l'activité. Construire une architecture qui survit à la fonctionnalité numéro 20, c'est du progrès.

Le piège du vibe coding : le précipice des 3 mois où meurent les projets IA

L'effondrement suit une séquence mécanique prévisible :

Semaines 1–4 : la lune de miel. Vous construisez des fonctionnalités isolées. Chacune fonctionne indépendamment, parce que rien n'est encore relié. L'IA génère du code correct parce que chaque prompt est simple et autonome.

Semaines 5–8 : les fissures. Les nouvelles fonctionnalités interagissent désormais avec les anciennes — et l'IA ne se souvient pas des décisions d'architecture qu'elle a prises il y a quatre semaines. Chaque session fait des choix différents. Parfois elle relie correctement les données avec des clés étrangères ; parfois elle les duplique. Un jour, vous remarquez que le nom de l'utilisateur est stocké dans cinq tables différentes. Modifiez-le à un endroit, il est périmé dans les quatre autres.

Semaines 9–12 : la spirale de la mort. Chaque nouvelle fonctionnalité hérite des incohérences, ajoute ses propres hypothèses et casse quelque chose qui fonctionnait. Vous demandez : « Corrige le bug où les noms d'utilisateur ne se mettent pas à jour partout. » L'IA répond : « Je vais mettre à jour les 6 endroits où nous stockons les noms d'utilisateur. » Vous demandez pourquoi il y a six endroits. Elle propose de les consolider — mais cela cassera 15 fonctionnalités. Partie terminée.

Le décalage qui piège les gens : l'IA est réellement excellente pour générer du code correct pour des fonctionnalités isolées. Elle n'est pas bonne pour se souvenir des décisions d'une session à l'autre, repérer les conflits avec les schémas existants ou faire des choix d'architecture stratégiques. Et elle répond avec une assurance totale dans les deux cas — « pour la simplicité, je recommande de dénormaliser ici » semble intelligent, et vous ne pouvez pas distinguer un bon conseil d'un mauvais si vous ne comprenez pas l'architecture.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Vous êtes l'architecte. L'IA est le maçon.

C'est le changement de paradigme qui change tout. Pas « l'IA est mon développeur et je suis le chef de produit ». Pas « nous codons ensemble en partenaires ». Vous concevez. L'IA construit.

Pensez à la construction d'une maison. L'architecte décide des fondations, des murs porteurs, du tracé de la plomberie — des décisions qu'on ne peut plus changer une fois le chantier lancé. Le maçon exécute ce plan avec un vrai savoir-faire, mais ne le crée pas. Dites à un maçon « construis-moi une maison » sans plan et vous obtiendrez quelque chose qui tient debout — jusqu'à ce que vous vouliez un deuxième étage et découvriez que les fondations ne le supportent pas.

En logiciel, les décisions de l'architecte sont les vôtres : quelles entités existent et comment elles sont liées, si le système est multi-tenant, comment les permissions sont appliquées, ce qui est normalisé, quels schémas chaque service suit. Le travail de l'IA, c'est l'exécution : les composants, le code répétitif, les migrations qui implémentent votre schéma à la lettre.

Et une partie du travail consiste à résister. Quand l'IA dit « pour la simplicité, stockons aussi le nom de l'utilisateur dans la table des commandes » — non, normalisez. Quand elle dit « pour la performance, dénormalisons » — montrez-moi d'abord le problème de performance. Quand elle suggère un correctif rapide — pas de bricolage, cherchez la cause racine. L'IA optimise pour du code qui marche vite. Vous avez besoin d'un code de production qu'on ne reconstruit jamais.

L'alternative architecture d'abord (preuves à l'appui)

Je n'ai pas développé cette approche parce que je suis malin. Je l'ai développée parce que je n'avais pas le choix. Après avoir tout perdu dans une aventure qui a échoué, je me reconstruisais chez mes parents — mes parents de 83 ans payaient mon abonnement Claude parce que je n'en avais pas les moyens. J'avais des mois de trésorerie, pas des années. Si je faisais du vibe coding et que je heurtais le mur au mois 3, il n'y aurait pas eu de seconde tentative.

Alors, avant d'écrire une seule ligne d'interface, j'ai passé 2 semaines à concevoir le schéma complet de la base de données de FIKR Space : chaque relation cartographiée, multi-tenancy sur chaque table dès le premier jour, sécurité au niveau des lignes appliquée au niveau de la base de données, plus de 90 % des données normalisées vers une source de vérité unique. Puis j'ai donné ce plan à l'IA pour qu'elle construise — en me battant avec elle tous les jours quand elle suggérait des raccourcis.

Le résultat après 11 mois : 8 à 12 produits intégrés, prêts pour la production, zéro réécriture. Une fois les fondations solides, les fonctionnalités ont fusé — un système d'OKR complet en 3 jours, la gestion de la table de capitalisation en 4. Quand des gens l'ont testé, la question était toujours la même : « Comment as-tu pu construire ça seul ? » Le devis traditionnel pour cette plateforme est de 10 à 15 développeurs pendant 2 ans — 1,6 M€–2,4 M€ rien qu'en salaires de développement, facilement plus de 2 M€ tout compris. Cela m'a coûté moins de 3 250 € la première année. (Le détail complet des coûts de la stack d'outils fait l'objet d'un article à part.)

Le choix devant vous est simple à énoncer : rapide maintenant et lent ensuite, ou lent maintenant et rapide pour toujours. Le vibe coding livre 20 fonctionnalités le premier mois, puis passe le mois 3 à réparer ce que le mois 1 a construit. L'architecture d'abord consacre 2 semaines au plan, puis livre des fonctionnalités qui continuent de fonctionner.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Comment savoir si je fais du vibe coding ?

Les signaux d'alerte : vous avez demandé à l'IA de corriger le même bug plus de 3 fois, vous ne pouvez pas expliquer votre schéma de base de données à quelqu'un d'autre, les mêmes données semblent stockées différemment d'une fonctionnalité à l'autre, vous évitez d'ajouter des fonctionnalités parce que vous ne savez pas ce qu'elles vont casser, ou vous pensez discrètement à « repartir d'une page blanche ». Trois signaux ou plus, et vous fonçez vers le précipice.

Le vibe coding est-il parfois acceptable ?

Oui — pour des prototypes et des applications simples que vous êtes prêt à jeter. Les outils conçus pour le pur prompting sont excellents pour des MVP rapides. Le piège se referme quand un prototype jetable devient discrètement le produit, et que les décisions d'architecture du mois 3 n'ont été prises par personne.

Peut-on sauver un projet de vibe coding, ou faut-il tout reconstruire ?

En général, on peut le sauver. Mettez le développement de fonctionnalités en pause quelques jours, cartographiez chaque table et leurs liens, repérez où les données sont dupliquées, concevez le schéma que ces entités auraient dû avoir, puis migrez : consolidez les doublons, ajoutez les clés étrangères manquantes, ajoutez le cloisonnement par tenant, activez la sécurité au niveau des lignes. Cela paraît lent. C'est des mois plus rapide que la réécriture vers laquelle vous allez sinon.

Faut-il apprendre à coder pour être l'architecte ?

Non — mais vous devez apprendre les fondamentaux de l'assemblage des systèmes : entités, relations, source de vérité unique, permissions. Vous prenez ces décisions ; l'IA écrit l'implémentation. Cette compétence s'acquiert en quelques semaines, et c'est la différence entre un projet qui meurt au mois 3 et un projet qui s'accumule. Si vous bâtissez votre sortie de l'entreprise dessus, commencez par mesurer à quel point vous en avez besoin — puis construisez sur de vraies fondations.