Sécurité du Code Généré par IA : Risques et Bonnes Pratiques

Le code IA, entre productivité et vulnérabilité

Avril 2026. Une étude CodeRabbit sur 470 pull requests open source révèle que le code co-écrit avec une IA contient 1.7 fois plus de problèmes majeurs que le code humain. L'ANSSI publie un rapport de 12 pages sur les risques de l'IA générative appliquée au code. Et 63% des développeurs interrogés déclarent avoir passé plus de temps à débugger du code IA qu'ils n'en auraient mis à l'écrire eux-mêmes.

Le vibe coding transforme la productivité. Mais la rapidité a un coût quand la sécurité passe au second plan.

Les chiffres qui alertent

Vulnérabilités mesurées

Les études convergent sur un constat : le code généré par l'IA est moins sécurisé que le code humain.

• 15-18% plus de vulnérabilités par ligne comparé au code écrit manuellement (étude Black Duck OSSRA 2026)
• 45% du code IA contient au moins une vulnérabilité — contre ~30% pour le code humain
• +107% de vulnérabilités open source en un an, en partie attribué à l'utilisation massive d'outils de génération de code
• 1 faille sur 5 dans les applications auditées en 2026 est directement liée à du code généré par IA

Une étude de Stanford a mesuré que dans 4 tâches de développement sur 5, les participants utilisant une IA ont produit du code moins sécurisé que ceux qui codaient sans assistance.

Le paradoxe de la confiance

Le problème n'est pas seulement technique. Le code IA compile, passe les tests fonctionnels et a l'air correct. Cette apparence de qualité crée une fausse confiance. Le développeur qui copilote l'IA a tendance à réduire sa vigilance — exactement le moment où les vulnérabilités s'infiltrent.

60% des entreprises utilisent des outils d'assistance IA au développement, mais seulement 18% disposent de politiques encadrant les risques associés. L'outillage avance plus vite que les processus.

Les types de vulnérabilités fréquentes

Injection et validation

Le code IA génère souvent des requêtes SQL ou des appels API sans validation suffisante des entrées. Un prompt "crée un endpoint de recherche utilisateur" produit fréquemment du code vulnérable à l'injection SQL si le développeur ne précise pas les contraintes de sécurité.

La même logique s'applique au XSS (Cross-Site Scripting). L'IA insère des données utilisateur dans le HTML sans échappement systématique, surtout quand le contexte du framework n'est pas explicitement fourni dans le prompt.

Dépendances obsolètes

L'IA suggère des packages qu'elle connaît de son entraînement — pas nécessairement les versions actuelles. Un npm install basé sur les suggestions IA peut introduire des dépendances avec des CVE connues. Les outils comme Cursor et GitHub Copilot améliorent ce point en indexant le projet, mais les chatbots génériques (ChatGPT) ne vérifient pas les versions.

Gestion d'erreurs superficielle

Le pattern le plus courant dans le code IA : un try/catch vide ou un .catch(() => {}) qui avale silencieusement les erreurs. L'IA optimise pour "ça compile" plutôt que "ça échoue proprement". Les erreurs silencieuses masquent des problèmes de sécurité pendant des semaines jusqu'à ce qu'un attaquant les exploite.

Secrets en dur

L'IA peut générer du code avec des exemples de clés API, tokens ou mots de passe. Si le développeur remplace l'exemple par un vrai secret sans l'externaliser dans les variables d'environnement, le secret se retrouve dans le code source — et potentiellement dans l'historique Git.

Ce que recommande l'ANSSI

Le rapport CERTFR-2026-CTI-001 de l'ANSSI identifie trois catégories de risques liés à l'IA générative dans le développement :

1. Vulnérabilités dans le code généré — l'IA reproduit des patterns vulnérables présents dans ses données d'entraînement
2. Manipulation des données d'entraînement — des attaquants peuvent empoisonner les datasets pour que l'IA génère du code malveillant
3. Exfiltration de données — le code est envoyé aux serveurs de l'outil IA, ce qui expose le code propriétaire

L'ANSSI recommande une approche de surveillance continue : tests dynamiques, audits réguliers, et traçabilité du code généré par IA.

Les bonnes pratiques qui protègent

Règle 1 — Toujours préciser les contraintes de sécurité dans le prompt

Le prompt "crée un endpoint d'authentification" produit du code fonctionnel mais pas sécurisé. Le prompt efficace inclut les contraintes :

Crée un endpoint POST /api/auth/login.

Contraintes de sécurité :
- Hachage bcrypt avec 12 rounds (pas de MD5/SHA)
- Comparaison timing-safe (pas de === sur les hash)
- Rate limiting : max 5 tentatives par IP par minute
- Pas de message d'erreur qui révèle si l'email existe
- Token JWT httpOnly, secure, sameSite strict
- Pas de secret en dur — lire depuis process.env

La différence de sécurité entre les deux prompts est radicale. Les techniques de prompts efficaces s'appliquent directement à la sécurité.

Règle 2 — Linting strict et analyse statique

Configurer ESLint avec des règles de sécurité activées. Les plugins comme eslint-plugin-security et eslint-plugin-no-unsanitized détectent les patterns dangereux au commit — avant qu'ils n'atteignent la production.

Pour les projets TypeScript, le mode strict: true dans tsconfig.json élimine une catégorie entière de bugs (nulls, types implicites). Cursor respecte ces règles via les fichiers .cursorrules — une fois configuré, l'IA génère du code conforme.

Règle 3 — Revue de code systématique

Le code généré par l'IA ne devrait jamais être mergé sans revue humaine. Les outils de revue assistée (GitHub Copilot PR review, CodeRabbit) aident, mais ne remplacent pas un regard humain sur les points de sécurité critiques : authentification, autorisation, validation des entrées.

Règle 4 — Tests de sécurité automatisés

Intégrer des scans de sécurité dans le pipeline CI/CD :

• SAST (Static Application Security Testing) : analyse le code source
• DAST (Dynamic Application Security Testing) : teste l'application en fonctionnement
• SCA (Software Composition Analysis) : vérifie les dépendances pour les CVE connues

Ces outils rattrapent ce que la revue humaine manque. Le coût est négligeable comparé au coût d'une faille en production.

Règle 5 — Traçabilité du code IA

Savoir quel code a été généré par l'IA et quel code a été écrit manuellement. Pas pour pointer du doigt, mais pour prioriser les audits. Les blocs générés par l'IA méritent une attention de sécurité supérieure — c'est ce que les données montrent.

Le vibe coding sécurisé est possible

Le problème n'est pas l'IA — c'est l'absence de garde-fous. Un développeur qui utilise Cursor avec des règles .cursorrules strictes, un linting sécurité activé, des tests automatisés et une revue systématique produit du code plus rapide et plus sécurisé qu'un développeur sans IA qui n'a pas ces pratiques.

L'IA est un multiplicateur. Elle multiplie la productivité, mais elle multiplie aussi les risques si les processus de sécurité ne suivent pas. La différence tient dans les pratiques, pas dans l'outil.

Pour aller plus loin : le guide complet du vibe coding couvre les limites à connaître, et le comparatif des outils détaille les fonctionnalités de sécurité de chaque outil (Privacy Mode, code local, compliance).