Vibe coding : risques, failles de sécurité et ce qui aide vraiment

Le plus grand risque du vibe coding n'est pas le code erroné, mais le code qui fonctionne et qui est pourtant peu sûr. Dans le GenAI Code Security Report 2025 de Veracode, 45 pour cent des réponses d'IA examinées ont échoué aux tests de sécurité et apportaient des vulnérabilités de l'OWASP Top 10 — avec un code syntaxiquement irréprochable et exécutable.

Dans quelle mesure le code généré par IA est-il vraiment peu sûr ?

De façon mesurable, et indépendamment du modèle. Pour le GenAI Code Security Report 2025, Veracode a soumis quatre-vingts tâches de programmation sélectionnées à plus de cent modèles de langage dans quatre langages : Java, JavaScript, Python et C#.

• 45 pour cent de tous les exemples de code produits n'ont pas passé le contrôle de sécurité.
• 86 pour cent de taux d'échec pour le cross-site scripting (CWE-80) — de loin la discipline la plus faible.
• 72 pour cent de taux d'échec pour Java, le plus risqué des quatre langages étudiés.

Ce qui compte, c'est le constat derrière les chiffres : les modèles se sont nettement améliorés pour produire du code fonctionnel, mais pas dans la même mesure pour la sécurité. Une mise à jour de printemps de Veracode datant de 2026 arrive à la même conclusion. Les nouvelles générations de modèles ne résolvent donc pas le problème d'elles-mêmes.

Pourquoi une IA produit-elle du code peu sûr alors qu'elle a tout lu ?

Parce qu'un modèle de langage est optimisé pour la plausibilité, pas pour la résistance aux attaques. Trois mécanismes expliquent la majeure partie des cas.

Premièrement, la moyenne de l'entraînement. Les modèles apprennent à partir de code public. La moyenne du code public n'est pas sûre, elle est moyenne — y compris les tutoriels où les entrées passent sans vérification dans une requête de base de données, parce que l'exemple devait rester court.

Deuxièmement, l'absence de perspective de l'attaquant. Un prompt décrit ce qui doit se passer. La sécurité, c'est la question de ce qui peut se passer. Ce que personne n'a demandé n'est pas construit non plus : la vérification d'une autorisation manquante, la prise en charge du cas particulier, la limitation du débit des requêtes.

Troisièmement, l'absence de contexte. Le modèle ne connaît pas votre architecture. Il ne sait pas que ce point d'accès est joignable publiquement, que tel champ provient d'un système tiers ou que votre séparation des clients tient à une condition précise.

Quelles failles de sécurité apparaissent typiquement dans le code IA ?

L'OWASP Top 10 a été révisé en novembre 2025 et publié sous sa forme définitive en janvier 2026, sur la base de plus de 175 000 entrées CVE. Deux catégories sont nouvelles, et toutes deux touchent particulièrement le développement assisté par IA.

• Contrôle d'accès défaillant (A01:2025) — toujours en première place. Le code IA implémente la logique métier et laisse sans réponse la question « cet utilisateur a-t-il le droit ? », parce qu'elle ne figurait pas dans le prompt.
• Mauvaise configuration de sécurité (A02:2025) — passée de la cinquième à la deuxième place. Les configurations générées sont optimisées pour « ça tourne tout de suite » : règles CORS généreuses, sorties de débogage, mots de passe par défaut.
• Défaillances de la chaîne d'approvisionnement (A03:2025) — nouvelle. Une IA ajoute des dépendances sans que personne ne les ait choisies. À cela s'ajoute l'hallucination de paquets inexistants, dont les noms sont enregistrés à dessein par des attaquants.
• Mauvaise gestion des exceptions (A10:2025) — également nouvelle. Le cas normal est implémenté, le cas d'erreur est avalé.
• Cross-site scripting — le champion empirique du test Veracode avec 86 pour cent de taux d'échec.

Quels contrôles dois-je exécuter avant de fusionner du code IA ?

Quatre contrôles couvrent l'essentiel des schémas évoqués ci-dessus, et tous les quatre peuvent être automatisés.

• Analyse statique avec règles de sécurité. Détecte les schémas d'injection, la désérialisation non sécurisée et l'absence d'échappement en sortie avant l'exécution du code. Outils et limites : l'analyse statique de code en comparaison.
• Contrôle des dépendances. Chaque nouveau paquet est signalé : existe-t-il seulement, qui le maintient, quelle licence, quelles vulnérabilités connues ?
• Revue des autorisations. Pour chaque nouveau point d'accès, une réponse explicite à la question de savoir qui peut l'appeler. C'est le contrôle le moins souvent automatisé et celui qui manque le plus souvent.
• Tests des cas d'erreur. Pas seulement le chemin heureux, mais entrée manquante, type erroné, identifiant étranger, appel en double. Voir la couverture de tests pour le code IA.

Ne suffit-il pas de relire simplement le code généré ?

Comme seule mesure, non, car la lecture se relâche précisément quand beaucoup de code est produit. Dans la Stack Overflow Developer Survey 2025, 66 pour cent des personnes interrogées ont cité « presque correct, mais pas tout à fait » comme principale frustration dans l'usage des outils d'IA. 45 pour cent ont déclaré perdre beaucoup de temps à déboguer du code IA.

« Presque correct » est la catégorie la plus difficile pour une revue. Un code manifestement faux se remarque. Un code qui ressemble à ce qu'il doit être et omet un contrôle à un endroit ne se remarque pas à la lecture en diagonale — et on lit en diagonale dès que le volume augmente. Une revue humaine reste nécessaire ; elle a cependant besoin d'un préfiltre automatisé qui écarte l'évident. Comment construire une telle revue, l'article Revue de code pour le code généré par IA l'explique.

Questions fréquentes sur les risques du vibe coding

Le code généré par IA est-il moins sûr que le code écrit à la main ?

Il est établi que 45 pour cent des réponses d'IA examinées par Veracode en 2025 ont échoué aux tests de sécurité. Cette étude ne fournit pas de comparaison propre avec du code humain dans des conditions identiques — les facteurs de comparaison qui circulent doivent donc être traités avec prudence. L'affirmation solide est la suivante : le taux d'erreur est suffisamment élevé pour justifier une couche de vérification propre.

Quel langage de programmation est le plus risqué avec l'IA ?

Dans le test Veracode 2025, Java, avec 72 pour cent de taux d'échec, était le plus faible des quatre langages étudiés (Java, JavaScript, Python, C#).

Qu'est-ce que le slopsquatting ?

Une attaque qui exploite le fait que les modèles d'IA inventent des noms de paquets. Les attaquants enregistrent les noms hallucinés dans les registres publics de paquets et attendent que quelqu'un exécute sans vérification l'instruction d'installation. La parade est un contrôle des dépendances qui signale chaque nouveau paquet.

Est-ce que cela aide d'écrire « écris du code sûr » dans le prompt ?

Cela aide très peu, de façon mesurable. Le rapport Veracode montre que les performances en matière de sécurité n'ont pas progressé au même rythme que la qualité générale des modèles. Une instruction dans le prompt est une demande, pas un point de contrôle — la vérification doit avoir lieu en dehors du modèle.

Dois-je donc renoncer aux outils d'IA ?

Non. Le risque ne vient pas de l'outil, mais du fait que du code non vérifié arrive en production. Une étape de vérification entre la génération et la livraison résout le problème sans renoncer à l'avantage de vitesse.

Vendredi, 17 h, un correctif urgent doit partir. C'est précisément à ce moment que la vérification des autorisations est sautée — non par négligence, mais parce que personne n'ouvre une liste de contrôle à cet instant. C'est pourquoi Code Guardian place les quatre contrôles comme gates devant le déploiement, la migration et toute nouvelle dépendance.

Sources

• Veracode, GenAI Code Security Report 2025 (80 tâches, plus de 100 modèles, quatre langages), juillet 2025, ainsi que la mise à jour du printemps 2026.
• OWASP Top 10:2025 — présenté en novembre 2025, version finale en janvier 2026, base de données de plus de 175 000 entrées CVE et 589 CWE.
• Stack Overflow Developer Survey 2025, section « AI ».

État au 27 juillet 2026. Information professionnelle générale, pas un conseil de sécurité pour un cas particulier.