Ton projet a été vibe codé ? Voici ce que je trouve quand je reprends le code

"Ça marche sur mon écran"

La scène se répète de plus en plus souvent. Quelqu'un me contacte avec un projet web ou une application SaaS. Le prototype existe, l'interface claque, et la personne est fière de me montrer ce qu'elle a construit. "J'ai tout fait avec l'IA, sans écrire une ligne de code." Puis elle ajoute : "Mais il y a quelques bugs."

Ces "quelques bugs", c'est en général la partie visible de l'iceberg.

Depuis début 2025, j'ai repris plusieurs projets qui avaient été entièrement générés par IA. Pas par des développeurs qui utilisent l'IA comme accélérateur (ça, c'est mon quotidien, et c'est très différent), mais par des personnes non techniques qui ont utilisé Claude, Cursor, Bolt ou d'autres outils pour construire leur produit de A à Z. Le fameux vibe coding.

Je ne suis pas là pour cracher sur cette approche. L'accessibilité de la création logicielle, c'est une révolution. Mais il y a une réalité que personne ne raconte : ce qui se passe quand le prototype doit devenir un vrai produit.

Le pattern que je retrouve à chaque fois

Chaque projet est différent, mais les problèmes de fond sont étonnamment similaires. Ce n'est pas une question de langage ou de framework. C'est une question de fondations.

Pas de base technique solide

Quand un développeur expérimenté démarre un projet, il commence par poser l'architecture. La structure des dossiers, le typage des données, les conventions de nommage, la gestion des erreurs, les variables d'environnement, la configuration du linting et du formatting. Ce n'est pas du code "utile" au sens fonctionnel, mais c'est ce qui fait que le projet tient debout dans la durée.

Un projet vibe codé, lui, part directement dans le fonctionnel. L'IA génère ce qu'on lui demande : un formulaire, une page, une connexion à une API. Ça marche. Mais il n'y a pas de squelette en dessous. Pas de types partagés entre le front et le back. Pas de validation côté serveur. Pas de gestion centralisée des erreurs. Chaque feature est un îlot, connecté aux autres par des fils invisibles qui cassent dès qu'on touche quelque chose.

La base de données, c'est souvent le chaos

C'est probablement le problème le plus grave et le plus fréquent. La base de données est le cœur de tout projet, et c'est là que je trouve les dégâts les plus importants.

Pas de migrations versionnées, donc impossible de savoir comment le schéma a évolué. Des relations entre les tables qui ne sont pas correctement définies, ou qui sont gérées côté application au lieu de côté base de données. Des champs dupliqués parce que l'IA a créé une nouvelle colonne au lieu de réutiliser celle qui existait. Des données sensibles stockées en clair. Et parfois, le plus vicieux : ça fonctionne en local, parce que l'IA a contourné les contraintes d'intégrité au lieu de les respecter.

Le jour où tu déploies en production avec de vrais utilisateurs, tout s'effondre.

La sécurité ? Quelle sécurité ?

C'est le point qui me fait le plus grincer des dents. Sur pratiquement tous les projets vibe codés que j'ai repris, la sécurité était au mieux partielle, au pire inexistante.

J'ai vu des APIs sans aucune authentification. Des tokens stockés dans le localStorage sans expiration. Des requêtes SQL construites par concaténation de strings. Des formulaires sans protection CSRF. Des uploads de fichiers sans validation de type ni de taille. Des clés d'API en dur dans le code source, pushées sur GitHub en public.

Le problème, c'est que l'IA génère du code qui fonctionne. Elle répond à la demande : "fais-moi un login". Et elle fait un login. Mais elle ne pense pas spontanément à tout ce qui entoure ce login : la gestion des sessions, le rate limiting, le hashage des mots de passe, la protection contre les injections. Ce sont des réflexes qu'un développeur a internalisés après des années de pratique. L'IA, elle, fait ce qu'on lui demande. Ni plus, ni moins.

Du code qui marche, mais impossible à maintenir

Imaginons que tu passes à travers tous les problèmes précédents. Ton application fonctionne, elle est déployée, des gens l'utilisent. Super. Maintenant, tu veux ajouter une feature. Ou corriger un bug. Ou changer le comportement d'un composant.

Et là, tu te retrouves face à un mur.

Le code généré par IA a une caractéristique très particulière : il est souvent localement correct mais globalement incohérent. Chaque fichier, pris individuellement, a l'air propre. Mais l'ensemble ne suit aucune logique d'architecture. Le même pattern est implémenté de trois manières différentes dans trois fichiers différents. Des fonctions utilitaires sont dupliquées plutôt que partagées. Les dépendances entre les modules forment un spaghetti impossible à démêler.

Résultat : pour chaque heure passée à ajouter une feature, tu en passes trois à comprendre ce qui existe déjà et à essayer de ne rien casser.

Pourquoi ça arrive (et ce n'est pas la faute de l'IA)

Je veux être très clair là-dessus : le problème, ce n'est pas l'IA. L'IA est un outil extraordinaire. Je l'utilise tous les jours dans mon travail et elle a transformé ma productivité.

Le problème, c'est l'absence de supervision technique.

Quand je travaille avec Claude Code, je sais quoi lui demander, je sais évaluer ce qu'il produit, et je sais quand il fait fausse route. Pas parce que je suis meilleur que l'IA, mais parce que j'ai le contexte métier et l'expérience pour juger si le code est bon, maintenable et sécurisé.

Une personne non technique qui vibe code, c'est comme quelqu'un qui utilise un GPS sans connaître les routes. Tant que le GPS fonctionne, tout va bien. Le jour où il propose un itinéraire absurde, tu ne le remarques pas. Tu suis. Et tu te retrouves dans une impasse.

Réparer ou recommencer ? La question qui fait mal

C'est la première question que me posent les gens qui me contactent. "Est-ce qu'on peut sauver ce qui existe ?"

La réponse honnête : ça dépend, mais souvent, recommencer va plus vite.

Pas parce que le code est "mauvais" au sens esthétique du terme. Mais parce que le temps nécessaire pour comprendre la logique implicite, identifier les effets de bord, corriger les failles de sécurité, restructurer la base de données et rendre le code maintenable dépasse souvent le temps qu'il faudrait pour reconstruire proprement à partir de zéro.

Et surtout : quand tu reconstruis, tu repars sur des fondations solides. Le prototype vibe codé n'est pas perdu pour autant. Il sert de spécification fonctionnelle. C'est un brouillon interactif qui montre ce que le produit doit faire. C'est précieux. Mais ce n'est pas le produit final.

Ce que ça veut dire pour toi

Si tu es en train de construire un projet avec l'IA et que tu n'as pas de background technique, ce n'est pas grave. Mais il faut en être conscient.

Le vibe coding est génial pour valider une idée. Tu veux voir si ton concept tient la route ? Tu veux tester un parcours utilisateur ? Tu veux montrer un prototype à des investisseurs ou à des premiers utilisateurs ? Fonce. L'IA va te permettre d'aller vite et de tester des hypothèses sans investir des dizaines de milliers de francs.

Mais le moment où tu veux passer du prototype au produit, c'est le moment où tu as besoin de quelqu'un qui comprend ce qui se passe sous le capot. Pas pour tout jeter et repartir de zéro (même si c'est parfois la meilleure option), mais pour poser un diagnostic honnête sur ce qui tient et ce qui ne tient pas.

Un audit, ça prend combien de temps ?

En quelques heures, je peux te dire où en est ton projet. Ce qui fonctionne, ce qui est fragile, ce qui est dangereux. Pas un rapport de 50 pages, mais un diagnostic concret avec des priorités claires : ce qu'il faut corriger maintenant, ce qu'on peut garder, et ce qu'il vaut mieux reconstruire.

Si tu as un projet qui a été vibe codé et que tu te demandes si c'est viable pour la suite, on en discute. Pas de jargon, pas de jugement, juste un regard professionnel sur ce qui existe.

Parce que le pire scénario, ce n'est pas d'avoir vibe codé. C'est de continuer à construire sur des fondations qui ne tiennent pas.