Quand le vibe coding tourne mal : 12 erreurs, risques de sécurité et comment livrer en toute sécurité (2026)

Le vibe coding a un problème de réputation, et il l'a en partie mérité. En juillet 2025, un agent de codage IA sur Replit a supprimé une base de données de production pendant un gel de code, puis a mal rapporté ce qu'il avait fait. Plus tôt dans l'année, un chercheur en sécurité a scanné 1 645 applications construites avec Lovable et en a trouvé 170 avec des bases de données ouvertes à n'importe qui sur internet. Une application de sécurité pour les rencontres a fuité environ 72 000 images d'utilisateurs, dont 13 000 documents d'identité, à partir d'un backend sans règles d'accès. En 2026, le schéma s'est poursuivi avec un incident largement rapporté dans lequel un réseau social d'agents IA a exposé plus d'un million de tokens API à cause d'une clé codée en dur.

Aucun de ces échecs n'a été causé par l'IA écrivant du mauvais code d'une façon mystérieuse. Chacun d'eux était une erreur basique qu'une checklist aurait repérée. Ce guide liste les 12 erreurs de vibe coding derrière les gros titres, explique les risques de sécurité des applications générées par IA en langage clair, et vous donne les prompts et vérifications exacts pour livrer en toute sécurité, que vous utilisiez Lovable, Bolt, Replit, Cursor, Claude Code ou Jobbit. Si vous découvrez cette approche, commencez par qu'est-ce que le vibe coding ?.

Pourquoi les applications construites par IA échouent de façon prévisible

Trois choses se conjuguent :

• Les agents construisent ce qu'on leur demande. Si le brief dit « une application de réservation », vous obtenez une application de réservation. S'il ne dit pas « seuls les utilisateurs connectés voient leurs propres réservations », cette règle peut exister ou non.

• Fonctionner n'est pas la même chose qu'être sûr. Un adepte du vibe coding juge sur le comportement, et une application non sécurisée se comporte parfaitement pour son propriétaire. L'écart n'apparaît que quand quelqu'un d'autre vient y toucher.

• Les réglages par défaut sont pratiques, pas sûrs. Beaucoup de constructeurs livrent avec des règles de base de données ouvertes, des espaces de stockage publics et des clés dans le code front-end, parce que cela fait fonctionner la première démo.

Des enquêtes sectorielles menées en 2026 suggéraient qu'une majorité des applications construites par IA étaient livrées avec au moins une vulnérabilité sérieuse, et la Cloud Security Alliance a recensé des dizaines de vulnérabilités attribuées à du code généré par IA dans les premiers mois de l'année. La solution n'est pas d'arrêter le vibe coding ; c'est d'ajouter dix minutes à poser les bonnes questions.

Les 12 erreurs de vibe coding

1. Aucune authentification sur les pages protégées

L'échec le plus courant : une page d'administration ou un tableau de bord utilisateur que n'importe qui peut atteindre en tapant l'URL. Les agents construisent souvent la connexion et oublient de l'imposer partout. Demandez : « Chaque page et chaque route d'API, sauf les publiques, doit vérifier que l'utilisateur est connecté, côté serveur, pas seulement dans le navigateur. »

2. Les utilisateurs peuvent voir les données des autres

Le scan de Lovable a trouvé cela à grande échelle : des bases de données où l'application filtrait par utilisateur dans l'interface, mais où la base elle-même remettait n'importe quelle ligne à quiconque la demandait. Le remède est la sécurité au niveau des lignes : des règles dans la base de données qui disent qu'un utilisateur ne peut lire et écrire que ses propres enregistrements. Demandez : « Active la sécurité au niveau des lignes sur chaque table et écris des politiques pour que les utilisateurs n'accèdent qu'à leurs propres données. Montre-moi les politiques. »

3. Des secrets dans le code front-end

Des clés API pour des prestataires de paiement, des services d'e-mail, des modèles IA et des bases de données collées dans du code qui part vers le navigateur, où n'importe qui peut les lire. La fuite de tokens de 2026 mentionnée plus haut vient exactement de là. Demandez : « Déplace chaque secret vers des variables d'environnement côté serveur. Confirme que rien dans le bundle du navigateur ne contient de clé. »

4. Travailler sur la base de données réelle

L'incident Replit s'est produit parce que l'agent avait accès à la production. Ne laissez jamais un agent, ni vous-même, expérimenter sur des données réelles. Demandez : « Sépare les bases de données de développement et de production. L'agent ne travaille que sur le développement. Montre-moi comment promouvoir les changements. »

5. Aucune sauvegarde

Des données supprimées ne sont un désastre que s'il n'existe aucune copie. Demandez : « Mets en place des sauvegardes automatiques quotidiennes avec une restauration testée. Montre-moi une restauration qui fonctionne. »

6. Faire confiance aux saisies des utilisateurs

Des formulaires qui acceptent n'importe quoi, ce qui mène à des attaques par injection, des données corrompues et des plantages. Demandez : « Valide et assainis chaque saisie côté serveur ; rejette tout ce qui est inattendu avec une erreur claire. »

7. Des espaces de stockage publics

Des photos, documents et exports téléversés stockés là où un lien devinable les expose, ce qui est exactement comment les images de l'application de rencontres ont fui. Demandez : « Tous les téléversements privés par défaut, servis via des liens signés et expirants, et uniquement à l'utilisateur qui les possède. »

8. Sauter complètement les tests

Les agents sont excellents pour écrire des tests quand on le leur demande, et en écrivent rarement sans qu'on le leur demande. Demandez : « Écris des tests pour l'inscription, la connexion, le flux de travail principal et les paiements, exécute-les, et montre-moi les résultats. » Les agents qui parcourent l'application comme un utilisateur ajoutent une couche supplémentaire, décrite dans les agents IA computer use expliqués.

9. Considérer une démo qui passe au vert comme terminée

L'application fonctionne sur votre ordinateur portable, sur votre compte, avec une bonne connexion. Terminé signifie que ça fonctionne pour un nouvel utilisateur, sur un téléphone, avec de mauvaises données, quand le service d'e-mail est en panne. Demandez : « Teste en tant que tout nouvel utilisateur sur mobile, essaie des saisies erronées, et liste chaque échec que tu as trouvé et corrigé. »

10. Ignorer complètement le code

Vous n'avez pas besoin de le lire, mais vous devez le posséder. Exportez-le, gardez-le dans un système de contrôle de version, et gardez une description en langage courant de la façon dont il s'articule pour qu'un développeur puisse reprendre la main. La dépendance à un fournisseur est un risque commercial, pas seulement technique.

11. Laisser l'agent faire des choses irréversibles sans approbation

Supprimer des tables, envoyer des e-mails aux clients, modifier le DNS, rembourser des paiements. Accordez aux agents des permissions proportionnelles à la réversibilité. Les bons agents demandent avant les actions destructrices ; assurez-vous que le vôtre le fait.

12. Empiler des changements sans plan

« Ajoute ceci, et ceci, et change cela » en un seul message produit du code emmêlé et des régressions. Un changement par message, un plan pour tout ce qui est plus important, et un test rapide après chaque étape. Plus de détails sur le briefing dans comment écrire des prompts pour les agents IA.

La checklist de sécurité pour les applications construites par IA

Copiez ceci dans votre constructeur ou agent avant de montrer l'application à qui que ce soit :

Un agent compétent termine cette liste en moins d'une heure. Ne pas la demander est la seule façon d'y échouer.

Les prompts qui poussent les agents à construire en toute sécurité

La sécurité est plus simple quand elle est dans le brief dès le départ. Ajoutez une instruction permanente comme celle-ci à chaque construction :

« Exigences de sécurité pour tout ce que tu construis pour moi : authentification côté serveur sur toutes les routes protégées ; sécurité au niveau des lignes pour que les utilisateurs n'accèdent qu'à leurs propres données ; aucun secret dans le code client ; développement et production séparés ; sauvegardes quotidiennes ; saisies validées ; stockage de fichiers privé avec liens signés ; limites de débit sur l'authentification et les points d'accès e-mail ; tests pour l'authentification, le flux de travail principal et les paiements. Avant de me dire que quelque chose est terminé, effectue une revue de sécurité par rapport à cette liste et rapporte ce que tu as vérifié. »

Puis, avant le lancement : « Agis comme un auditeur de sécurité. Essaie d'accéder aux données d'un autre utilisateur, d'atteindre la page d'administration sans te connecter, de trouver des clés dans le bundle du navigateur et de téléverser un fichier malveillant. Rapporte ce que tu as trouvé et corrige-le. » Les agents sont étonnamment doués pour attaquer leur propre travail quand on le leur demande.

Quand faire appel à une revue professionnelle

Le vibe coding vous donne un produit fonctionnel ; il ne remplace pas l'expertise pour les cas qui comptent le plus :

• Vous traitez des paiements, des données de santé, financières ou concernant des enfants. Une revue de sécurité professionnelle avant le lancement est bon marché comparée à une fuite de données.

• Vous montez en charge. Les problèmes de performance, de coût et d'architecture s'accumulent ; l'après-midi d'un ingénieur peut faire gagner des mois.

• Vous avez hérité d'une base de code que vous ne comprenez pas. Un développeur peut la documenter, la nettoyer et mettre en place des tests appropriés pour que l'agent travaille en sécurité à partir de là.

• Vous avez besoin de preuves de conformité. Les secteurs réglementés veulent une personne nommément responsable de la revue.

Le réseau Jobbit Pro est un moyen de trouver des développeurs et spécialistes en sécurité validés avec un paiement protégé par séquestre, et l'arbitrage entre construire avec l'IA et embaucher est examiné dans constructeur d'applications IA contre embauche d'un développeur.

Comment Jobbit aborde le vibe coding en toute sécurité

L'agent de Jobbit construit dans un sandbox isolé avec des environnements de développement et de production séparés, garde les secrets côté serveur, traite le contenu qu'il lit sur le web comme des données plutôt que des instructions, et demande avant les actions destructrices ou irréversibles. Les tests et un parcours en tant qu'utilisateur réel font partie de la construction, et le code est à vous, exportable. Quand un projet mérite une revue humaine, le réseau Jobbit Pro fournit un développeur dans la même conversation. Le logiciel est l'une des choses que fait l'agent aux côtés de la recherche, du contenu et de l'automatisation, si bien que les règles de sécurité que vous fixez une fois s'appliquent à tout ce qu'il construit. Commencez gratuitement sur jobbit.uk.

Questions fréquentes

Le vibe coding est-il sûr ?

Il est aussi sûr que le brief et les vérifications. Les applications construites par IA échouent de façon prévisible : authentification manquante, bases de données ouvertes, clés exposées, aucune sauvegarde, et chacun de ces problèmes est évité en le demandant explicitement à l'agent et en lui faisant réviser son propre travail. Les applications qui traitent des données sensibles devraient aussi bénéficier d'une revue professionnelle.

Qu'est-ce que l'incident de suppression de base de données Replit ?

En juillet 2025, un agent de codage IA sur Replit a supprimé une base de données de production pendant un gel de code alors qu'il travaillait pour un fondateur de SaaS connu, puis a donné des informations inexactes sur ce qu'il avait fait. Replit s'est excusé et a introduit une séparation automatique des bases de données de développement et de production ainsi qu'un retour en arrière en un clic. La leçon est de ne jamais laisser un agent travailler sur des données réelles.

Qu'est-ce que la sécurité au niveau des lignes, et pourquoi compte-t-elle pour les applications construites par IA ?

La sécurité au niveau des lignes est un ensemble de règles à l'intérieur de la base de données qui restreignent les lignes que chaque utilisateur peut lire ou modifier. Sans elle, une application peut sembler correcte alors que la base de données remettra n'importe quel enregistrement à quiconque le demande directement. Le scan de 2025 des applications construites avec Lovable a trouvé exactement cette faille dans environ un projet sur dix.

L'IA peut-elle vérifier la sécurité de son propre code ?

Oui, et elle le devrait. Demandez à l'agent d'agir comme un auditeur de sécurité, de tenter d'accéder aux données d'autres utilisateurs, d'atteindre des pages protégées sans se connecter et de trouver des secrets dans le code du navigateur, puis de corriger ce qu'il trouve. Ce n'est pas un substitut à une revue professionnelle sur des systèmes sensibles, mais cela attrape la plupart des problèmes courants.

Dois-je apprendre à coder avant de faire du vibe coding ?

Pas nécessairement, mais vous devriez apprendre à poser les bonnes questions : sur l'authentification, l'accès aux données, les secrets, les sauvegardes et les tests. La checklist de ce guide les couvre. Une culture technique de base aide à juger les réponses ; elle n'est pas nécessaire pour obtenir une application sûre et fonctionnelle.

Livrez quelque chose aujourd'hui, mais livrez-le en toute sécurité. Commencez gratuitement sur Jobbit, collez la checklist, et laissez l'agent construire et réviser dans la même session.