Vibe coding : que vérifier avant la mise en production

Le vibe coding consiste à décrire à une IA ce que l'on veut, en langage courant, et à la laisser écrire le code sans le relire ligne à ligne. Le terme vient d'Andrej Karpathy, en février 2025 ; le dictionnaire Collins en a fait son mot de l'année 2025. Pour un prototype, c'est la méthode la plus rapide qui existe. Pour une application qui stocke des données réelles, c'est là que les ennuis commencent : personne n'a relu ce qui protège.

Ce n'est pas un procès de l'IA. Les mêmes trous existaient dans le code écrit à la main par des débutants. La différence, c'est le volume : en quelques soirées, on produit une application entière, et donc autant de surface à protéger.

Deux données publiques donnent l'ordre de grandeur.

Veracode a fait écrire du code à plus de 100 modèles d'IA sur 80 tâches types. Les modèles ont choisi l'option non sécurisée dans près d'un cas sur deux, et les modèles les plus récents ne font pas mieux que les anciens sur ce point. Le rapport complet est en ligne. C'est un banc d'essai, pas une mesure sur des applications réelles, mais la tendance est nette : l'IA écrit du code qui marche, pas forcément du code qui protège.

En 2025, un chercheur a parcouru les applications mises en avant par Lovable. Environ une sur dix exposait sa base de données (e-mails, adresses, parfois des clés d'accès) faute de règles d'accès correctes. La faille porte un numéro officiel, CVE-2025-48757. Lovable conteste la qualification : selon l'éditeur, protéger les données reste la responsabilité de chaque créateur d'application. C'est exactement le point. L'outil génère, vous restez responsable.

Un cas récent, anonymisé. Un dirigeant de PME a construit lui-même, avec l'IA, le logiciel de gestion de son activité pour remplacer un logiciel du marché qu'il payait chaque année. L'outil est complet : fiches clients, documents générés, suivi pour une certification. Son équipe s'en sert. Il nous a demandé de le rendre fiable. Voici ce que la première heure de lecture du code a montré.

“La sécurité passe avant l'ergonomie : on commence par fermer les portes, ensuite on améliore les écrans.”

Aucun de ces points n'était visible à l'écran. L'application marchait parfaitement. C'est ce qui rend le sujet piégeux : tout va bien jusqu'au jour où ça ne va plus du tout. Les données étant sensibles, un accord de traitement des données (RGPD) a été signé avant que quiconque y touche, puis un environnement de test a été monté pour ne plus jamais essayer une modification sur les vraies données.

Neuf points, du plus grave au moins urgent. Ils valent pour un SaaS vendu à des clients comme pour un outil interne qui porte votre activité.

Si vous comptez aussi vendre l'outil à d'autres entreprises, ajoutez le paiement, les comptes par organisation et le cadre légal : on décrit les sept briques dans transformer son projet Claude en vrai SaaS.

Vous ne pourrez pas tout vérifier seul, mais cinq tests simples révèlent les problèmes les plus fréquents.

Dès que l'une de ces conditions est remplie : l'outil stocke des données personnelles ou sensibles, des personnes extérieures à l'entreprise s'y connectent, de l'argent y transite, ou votre activité s'arrête s'il s'arrête. À ce stade, quelques heures de relecture coûtent beaucoup moins qu'une fuite à déclarer à la CNIL.

Une bonne relecture ne commence pas par tout réécrire. Elle commence par fermer les portes (secrets, accès, sauvegardes), monte un environnement de test, puis reprend l'outil là où il en est. Le travail que vous avez fait avec l'IA a de la valeur : il contient vos règles métier, testées par votre équipe.

On explique comment on combine IA et relecture humaine dans des développeurs, de l'IA, vérifié par un humain. Si votre outil doit remplacer un logiciel du marché, lisez aussi remplacer son logiciel métier par un outil fait avec l'IA. Et pour comparer honnêtement avec le fait de continuer seul : Figue ou le faire soi-même avec l'IA.