Ton app fonctionne. Tu as décrit ce que tu voulais en français, l'IA a écrit le code, le bouton fait ce qu'il doit faire. Sauf qu'une application qui fonctionne et une application sûre, ce sont deux choses différentes. Le vibe coding (écrire un logiciel en dialoguant avec une IA plutôt qu'en tapant chaque ligne soi-même) produit du code qui passe le test visuel mais qui laisse souvent des portes ouvertes : clé d'API lisible dans le navigateur, base de données accessible sans mot de passe, formulaire qui accepte n'importe quoi.
La bonne nouvelle, c'est que ces failles sont presque toujours les mêmes. Elles se ferment avec des réflexes simples, sans diplôme d'ingénieur en sécurité. Tu vas voir ici les six trous les plus fréquents dans une application générée par IA, comment les repérer en quelques minutes, quoi demander exactement à ton assistant pour qu'il les corrige, et la checklist à passer avant de mettre quoi que ce soit en ligne.
Pourquoi le code généré par une IA contient des failles
Une IA écrit le code que tu lui demandes, pas celui que tu as oublié de demander. Quand tu tapes « crée-moi une page qui enregistre les inscriptions », le modèle t'obéit au pied de la lettre : il fait une page, elle enregistre. Personne ne lui a parlé de limiter le nombre de tentatives, de vérifier le format de l'adresse e-mail, ni de décider qui a le droit de relire la liste des inscrits.
Trois mécanismes expliquent ce comportement.
D'abord, les modèles ont appris sur du code public, tutoriels compris. Beaucoup de ces tutoriels simplifient volontairement : ils écrivent la clé d'API en clair pour que l'exemple tienne en dix lignes. L'IA reproduit ce style, parce que c'est celui qu'elle a le plus vu.
Ensuite, l'IA ignore où ton code va tourner. Un prototype sur ta machine et une application publique avec 500 utilisateurs n'ont pas les mêmes exigences. Sans précision de ta part, l'assistant vise le prototype, c'est le chemin le plus court vers un résultat qui marche.
Enfin, le code qui fonctionne masque le code qui fuit. Une faille ne fait pas planter l'application et ne s'affiche nulle part. Tout a l'air normal jusqu'au jour où quelqu'un regarde vraiment.
L'éditeur Veracode a publié en 2025 une analyse de plus d'une centaine de modèles de langage sur des tâches de développement : environ 45 % des extraits produits contenaient au moins une faiblesse listée dans l'OWASP Top 10, la référence mondiale des risques applicatifs. Ce n'est pas une raison d'arrêter le vibe coding, c'est une raison de relire. Ces problèmes rejoignent d'ailleurs souvent les erreurs classiques quand on débute en vibe coding.
Les six failles que l'IA laisse passer le plus souvent
Six problèmes reviennent dans la quasi-totalité des applications générées par IA, et la plupart se repèrent sans savoir lire une ligne de code.
| Faille | Ce que ça permet | Test rapide |
|---|---|---|
| Clé d'API en dur | Utiliser ton compte payant à ta place | Chercher « sk- » ou « key » dans le code envoyé au navigateur |
| Base de données ouverte | Lire ou effacer toutes les données | Ouvrir l'URL de la base sans être connecté |
| Contrôle d'accès absent | Voir les données des autres utilisateurs | Changer un chiffre dans l'URL (/facture/12 vers /facture/13) |
| Entrées non validées | Injecter du code dans ta base ou ta page | Envoyer <script>alert(1)</script> dans un champ |
| Mots de passe mal stockés | Récupérer tous les comptes d'un coup | Demander à l'IA quel algorithme elle a utilisé |
| Dépendances non vérifiées | Installer du code malveillant | Lancer npm audit |
1. La clé d'API écrite en dur
C'est la faille numéro un. L'IA place ta clé OpenAI, Stripe ou Supabase directement dans un fichier qui part dans le navigateur de tes visiteurs. N'importe qui peut la lire en trois clics, puis consommer ton quota. Des robots scannent en permanence les dépôts publics pour ramasser ces clés.
La correction : les clés vivent dans un fichier .env, jamais envoyé au navigateur ni publié sur GitHub, et les appels payants passent par un petit programme côté serveur. Demande explicitement : « déplace toutes les clés dans des variables d'environnement et ajoute .env au .gitignore ».
2. La base de données ouverte en lecture et en écriture
Les outils modernes comme Supabase ou Firebase créent par défaut une base que ton application interroge directement. Si les règles d'accès ne sont pas configurées, l'adresse de ta base devient une porte d'entrée publique. Des milliers de bases de projets personnels sont ainsi consultables sans mot de passe.
La correction : activer la sécurité au niveau des lignes (row level security) et écrire une règle par table, du type « un utilisateur ne lit que les lignes dont il est le propriétaire ».
3. Le contrôle d'accès inexistant entre utilisateurs
Ton app vérifie que l'utilisateur est connecté, mais pas qu'il a le droit de voir cette page précise. Résultat : en changeant un numéro dans l'URL, un client accède à la facture d'un autre. C'est la catégorie A01 de l'OWASP Top 10, la plus répandue dans le monde réel.
La correction : chaque requête doit vérifier l'identité du demandeur, côté serveur, jamais côté navigateur. Une vérification cachée dans l'interface ne protège rien, elle masque juste un bouton.
4. Les entrées utilisateur acceptées telles quelles
Un champ de formulaire est une entrée dans ton système. Si le texte saisi est recollé directement dans une requête à la base, un visiteur peut lui faire exécuter ses propres ordres (injection SQL). S'il est réaffiché tel quel sur une page, il peut y glisser du code qui s'exécute chez tes autres visiteurs (XSS).
La correction : requêtes paramétrées côté base, échappement systématique à l'affichage, et validation du format attendu (longueur, type, caractères autorisés) avant tout traitement.
5. Les mots de passe stockés n'importe comment
Il arrive encore qu'une IA propose un stockage en clair ou un hachage MD5, dépassé depuis vingt ans. Si ta base fuit, tous les comptes tombent, y compris ceux de gens qui réutilisent ce mot de passe ailleurs.
La correction : bcrypt, argon2 ou scrypt, jamais MD5 ni SHA1. Le plus simple reste de déléguer l'authentification à un service existant plutôt que de l'écrire toi-même.
6. Les dépendances installées sans regarder
Quand l'IA ajoute une bibliothèque, elle ajoute aussi tout ce dont cette bibliothèque dépend, parfois des centaines de paquets. Certains sont abandonnés, d'autres contiennent des failles connues, quelques-uns portent un nom volontairement proche d'un paquet légitime.
La correction : lancer npm audit (ou l'équivalent de ton langage) après chaque installation, et activer Dependabot si ton code est sur GitHub.
Trois façons d'auditer ton application avant de la publier
La méthode la plus fiable consiste à faire relire ton code par une IA à qui tu donnes un rôle précis, puis à confirmer avec des outils automatiques gratuits.
Méthode 1 : apprendre l'audit dans un cadre guidé
Le vrai obstacle quand tu débutes n'est pas de lancer un audit, c'est de comprendre la réponse. Un rapport qui annonce « exposition de secret côté client » ne t'aide pas si personne ne t'a expliqué ce qu'est un secret et pourquoi le client (le navigateur) n'est pas un endroit sûr. C'est exactement ce que couvre le programme Skilzy pour créer et sécuriser une application avec Claude Code : tu construis un projet réel, tu passes l'audit dessus, et chaque alerte est expliquée puis corrigée pas à pas.
La partie pratique se fait dans le Lab IA intégré, avec les crédits inclus, ce qui évite d'empiler trois abonnements outils juste pour t'entraîner. L'accès démarre à 29,90 € par mois sans engagement, et une démo découverte permet de tester sans carte bancaire pendant 7 jours (1 image, 1 vidéo, 1 musique et 10 messages). Il faut créer un compte, mais aucune coordonnée bancaire n'est demandée.
Méthode 2 : demander l'audit directement à ton assistant
Gratuit si tu as déjà un accès à Claude, ChatGPT ou un autre assistant. Le résultat dépend entièrement de la formulation. Une demande vague (« c'est sécurisé ? ») produit une réponse rassurante et inutile. Donne un rôle, un référentiel et un format de sortie :
Tu es auditeur en sécurité applicative. Analyse ce projet en te basant sur l'OWASP Top 10. Pour chaque problème trouvé, indique : le fichier et la ligne, le risque concret pour un utilisateur, le niveau de gravité, et le correctif exact. Ne corrige rien pour l'instant, liste seulement. Sois exhaustif, y compris sur la gestion des secrets, le contrôle d'accès et la validation des entrées.
Demande ensuite les corrections une par une, en commençant par les plus graves. Corriger huit problèmes d'un coup produit un code que tu ne peux plus relire.
Méthode 3 : les outils automatiques gratuits
Ils ne remplacent pas une relecture, mais ils attrapent ce qu'une IA oublie. npm audit liste les dépendances vulnérables. Dependabot, inclus dans GitHub, ouvre automatiquement des demandes de mise à jour. Gitleaks détecte les clés d'API oubliées dans l'historique de ton dépôt. Mozilla Observatory note la configuration de ton site en ligne (HTTPS, en-têtes de sécurité) en une minute, à partir de la simple URL.
Ce que la loi t'impose dès que tu collectes une adresse e-mail
Dès qu'une seule donnée personnelle est enregistrée, le RGPD s'applique à toi, même pour un projet gratuit lancé seul depuis ton salon. Un nom, un e-mail, une adresse IP : ce sont des données personnelles.
Quatre obligations concrètes, que ton assistant IA ne mettra jamais en place spontanément :
- Collecter le minimum. Si ton service fonctionne avec un e-mail, ne demande pas la date de naissance ni le numéro de téléphone.
- Prévoir une durée de conservation. Les données ne restent pas indéfiniment. Fixe une durée et une procédure de suppression.
- Permettre l'effacement. Un utilisateur qui demande la suppression de son compte doit l'obtenir, ce qui suppose un bouton ou une adresse de contact.
- Chiffrer les échanges. HTTPS partout, avec redirection automatique depuis HTTP. C'est gratuit et automatique chez la majorité des hébergeurs.
Le guide de la sécurité des données personnelles de la CNIL détaille ces points fiche par fiche, en français et sans jargon. C'est la référence à garder ouverte si ton application va accueillir de vrais utilisateurs. Et si tu pars de zéro sur le plan technique, notre guide pour créer une application avec l'IA sans savoir coder pose les bases avant d'aborder ces sujets.
Les règles que tu écris une fois et qui protègent tous tes projets
Plutôt que de répéter tes exigences de sécurité à chaque conversation, écris-les dans un fichier d'instructions que ton assistant relit à chaque session. Claude Code utilise pour cela un fichier CLAUDE.md placé à la racine de ton projet, et les autres outils ont leur équivalent.
Sept règles suffisent à éliminer la majorité des failles vues plus haut :
- Jamais de clé, mot de passe ou jeton écrit dans le code, toujours des variables d'environnement.
- Toujours des requêtes paramétrées, jamais de texte utilisateur collé dans une requête.
- Mots de passe hachés avec bcrypt ou argon2.
- Validation de toutes les entrées aux frontières du système.
- Vérification des droits côté serveur pour chaque action sensible.
- Pas de message d'erreur détaillé en production.
.env, clés privées et journaux toujours dans le.gitignore.
Cette liste, collée une fois, s'applique à tout ce que l'assistant écrira ensuite. Pour aller plus loin sur la rédaction de ces consignes, notre article sur le fichier CLAUDE.md et les instructions qui font vraiment obéir Claude Code donne la structure complète.
Dernier réflexe, le plus rentable : avant chaque mise en ligne, relis ce qui a changé. Pas tout le code, juste les modifications. Si tu ne comprends pas ce qu'une ligne fait, demande. Un développeur expérimenté ne valide jamais un code qu'il ne saurait pas expliquer, et cette exigence vaut aussi quand c'est une IA qui l'a écrit.
Ce qu'il faut retenir
Le vibe coding ne rend pas ton application vulnérable en soi. Ce qui la rend vulnérable, c'est de publier sans relire. Les six failles listées ici couvrent l'essentiel du risque réel pour un projet débutant, et chacune se corrige en une poignée de minutes une fois repérée. Commence par sortir tes clés du code, verrouille ta base, vérifie les droits d'accès, puis passe la checklist avant chaque publication. Tu auras déjà un niveau de sécurité supérieur à beaucoup d'applications en ligne aujourd'hui.
