Le code généré par l'IA est partout. GitHub Copilot, CodeWhisperer, Tabnine - ces outils écrivent maintenant jusqu'à 35 % du code dans les entreprises. Mais ce code, bien qu'il fonctionne, est souvent sécuritaire. Pas parce qu'il est mal écrit, mais parce qu'il oublie délibérément les règles de sécurité. Un développeur humain sait que ne pas valider une entrée est dangereux. Une IA ? Elle voit juste une fonction qui marche. Et c'est là que les ingénieurs de vérification entrent en jeu.
Le problème n'est pas le code, c'est l'absence de méfiance
Les outils d'IA ne créent pas des bogues comme les humains. Ils ne font pas d'erreurs de syntaxe. Ils ne confondent pas un point-virgule. Ce qu'ils font, c'est produire du code fonctionnel mais vulnérable. Une requête SQL qui concatène des chaînes au lieu d'utiliser des requêtes paramétrées. Un point de terminaison exposé sans authentification. Une clé API stockée en clair dans un fichier de configuration. Tout cela semble correct du point de vue logique. Mais c'est une porte ouverte pour un attaquant.Une étude de Kiuwan en septembre 2024 montre que 43 % du code généré par l'IA contient des vulnérabilités de sécurité, contre seulement 22 % dans le code écrit par des humains. Pourquoi ? Parce que l'IA optimise pour la fonctionnalité, pas pour la sécurité. Elle ne sait pas ce que signifie « fail-secure ». Elle ne comprend pas que « deny by default » n'est pas une option, c'est une règle fondamentale.
Les 7 vulnérabilités les plus fréquentes dans le code généré par l'IA
Les ingénieurs de vérification ne peuvent pas utiliser les mêmes checklists que pour le code humain. Les vulnérabilités sont différentes. Voici les cinq types les plus courants, basés sur des milliers d'analyses réelles :
- Validation d'entrée manquante - L'IA génère souvent des endpoints qui acceptent n'importe quelle entrée. Elle suppose que l'utilisateur est honnête. Ce n'est pas le cas.
- Gestion inadéquate des clés API - Les clés sont parfois écrites en dur dans le code, ou stockées dans des fichiers accessibles publiquement. L'IA ne comprend pas que les clés ne sont pas des constantes de configuration.
- Gestion des erreurs trop permissive - L'IA retourne des messages d'erreur détaillés qui révèlent la structure du système. « Erreur SQL : table non trouvée » est un cadeau pour un attaquant.
- Deserialization non sécurisée - L'IA propose souvent d'utiliser des bibliothèques comme Java's ObjectInputStream sans vérifier la source des données. Cela permet l'exécution arbitraire de code.
- Contrôles d'accès absents - Une fonction qui vérifie si un utilisateur est authentifié, mais pas s'il a le bon rôle. L'IA pense que « connecté » = « autorisé ». Ce n'est pas vrai.
En 2024, les ingénieurs de vérification ont signalé que 68 % des vulnérabilités critiques dans le code généré par l'IA provenaient de ces cinq points. Pas de ransomware, pas de fuite de données - juste des oublis silencieux.
Les checklists de vérification pour l'IA : ce qui change
La revue de sécurité pour le code généré par l'IA ne ressemble à aucune autre. Elle doit être structurée, répétitive, et exigeante. Voici une checklist basée sur les meilleures pratiques de l'OpenSSF et de Kiuwan, mise à jour en août 2024 :
- Tagger chaque bloc de code généré par l'IA - Utilisez un commentaire spécifique comme
// AI_GENERATEDpour permettre une traçabilité automatique dans les outils SAST. - Exiger une validation d'entrée pour chaque entrée utilisateur - Même si l'IA a utilisé une bibliothèque comme Express.js ou Spring Boot, vérifiez manuellement que les entrées sont filtrées, limitées et typées.
- Interdire l'utilisation de
eval(),exec(),system()- Même si l'IA suggère de les utiliser pour « faciliter le débogage », bloquez-les systématiquement. Aucune exception. - Vérifier que les clés API, jetons et mots de passe ne sont jamais en dur - Utilisez des secrets managers (HashiCorp Vault, AWS Secrets Manager). L'IA ne connaît pas ces outils. Elle pense que les variables d'environnement sont des commentaires.
- Exiger des comparaisons en temps constant pour les jetons et les signatures - L'IA utilise souvent
==pour comparer des jetons. Cela permet des attaques par timing. Utilisez toujourscrypto.timingSafeEqual()ou équivalent. - Exiger l'encodage de sortie pour éviter le XSS - Même dans les templates React ou Angular, vérifiez que les données dynamiques sont encodées. L'IA ne sait pas que « {{userInput}} » peut exécuter du JavaScript.
- Valider les rôles d'accès, pas seulement l'authentification - Une fonction qui vérifie
isAuthenticated()mais pashasRole('admin')est une faille. L'IA confond souvent les deux.
Ces règles ne sont pas optionnelles. Elles sont la ligne de défense entre une application qui fonctionne et une application qui est piratée.
Les outils qui font la différence
Les outils traditionnels de SAST (Static Application Security Testing) ne sont pas suffisants. Une étude de Kusari en octobre 2024 montre qu'ils détectent seulement 62 à 68 % des vulnérabilités spécifiques à l'IA. Les outils modernes, eux, ont été entraînés sur des millions de lignes de code générées par l'IA.
Voici les trois principaux outils utilisés en 2025 :
| Outil | Précision de détection | Langages pris en charge | Intégration SARIF | Remédiation automatisée |
|---|---|---|---|---|
| Mend SAST (v4.2) | 92,7 % | 15+ | Oui | Oui (83 % des cas) |
| Kiuwan | 89,1 % | 12 | Oui | Partielle |
| Snyk Code | 84,5 % | 10 | Oui | Non |
Mend SAST est le leader du marché avec 28 % de part en 2024. Ce qui le distingue, c'est sa capacité à fournir des correctifs contextuels. Si l'IA génère une requête SQL vulnérable, Mend ne dit pas seulement « vulnérabilité trouvée ». Il propose une version corrigée avec des requêtes paramétrées. Cela réduit le temps de correction de 41 % selon une étude de Mend.io.
L'intégration SARIF est obligatoire. Configurez vos outils avec export SARIF_ARTIFACT=true et reliez-les à vos pipelines CI/CD. Cela permet aux outils d'IA de lire les résultats de sécurité et d'éviter de répéter les mêmes erreurs.
Les pièges à éviter
Les ingénieurs de vérification tombent souvent dans trois pièges.
- Se fier à l'IA pour détecter ses propres erreurs - Si vous demandez à GitHub Copilot : « Est-ce que ce code est sécurisé ? », elle dira oui. Parce qu'elle ne voit que la logique, pas les implications de sécurité.
- Ignorer les faux positifs - Les outils d'IA signalent 18 % de faux positifs en moyenne. Les ignorer, c'est se désengager. Les trier manuellement, c'est la seule façon de maintenir la confiance dans le processus.
- Ne pas former les équipes - Une étude de Devcom.com montre que les équipes qui ont suivi 40 à 60 heures de formation sur les vulnérabilités spécifiques à l'IA réduisent les failles critiques de 63 % en trois mois. Les équipes qui n'ont pas formé leurs ingénieurs n'ont vu aucune amélioration.
Et surtout : ne pensez pas que l'IA va remplacer la vérification humaine. Elle l'augmente. Elle rend le travail plus difficile, mais aussi plus nécessaire.
Le futur : des outils intégrés, pas des vérifications séparées
Le marché évolue vite. En 2025, GitHub Copilot intégrera directement Semgrep dans son moteur de suggestions. Cela signifie que lorsque l'IA propose un code, elle le vérifiera en temps réel contre des règles de sécurité. Ce n'est pas une fonctionnalité optionnelle - c'est une nécessité.
Les outils comme Kiuwan ont déjà lancé MCP Server, qui analyse le code pendant qu'il est écrit. L'ingénieur ne voit même pas la vulnérabilité - elle est corrigée avant qu'elle ne soit écrite.
Le but n'est plus de vérifier après coup. Le but est d'empêcher la vulnérabilité d'exister dès la première ligne de code.
Que faire maintenant ?
Si vous êtes ingénieur de vérification :
- Commencez par tagger tout le code généré par l'IA dans votre base de code.
- Intégrez Mend SAST ou Kiuwan dans votre pipeline CI/CD avec SARIF activé.
- Formez votre équipe aux 7 vulnérabilités principales.
- Créez une checklist interne basée sur les 7 points ci-dessus et faites-la signer par chaque développeur.
- Exigez que chaque pull request contenant du code généré par l'IA passe une revue manuelle sur ces points.
Le code généré par l'IA n'est pas un raccourci. C'est un piège. Et les ingénieurs de vérification sont les seuls qui peuvent le voir avant qu'il ne soit trop tard.
Pourquoi les outils SAST traditionnels ne détectent-ils pas bien les vulnérabilités du code généré par l'IA ?
Les outils SAST traditionnels sont entraînés sur du code humain. Ils cherchent des motifs connus : une chaîne concaténée dans une requête SQL, une fonction eval(), un mot de passe en dur. Le code généré par l'IA, lui, est souvent bien structuré, avec des bibliothèques modernes, des noms de variables clairs. Il évite les motifs classiques mais omet délibérément des contrôles de sécurité. Un outil traditionnel ne voit pas l'absence - il ne voit que ce qui est présent. Les outils modernes, eux, sont entraînés sur des milliers de cas où le code fonctionnait mais était vulnérable. Ils apprennent ce que l'IA oublie.
Le code généré par l'IA est-il plus dangereux que le code humain ?
Il n'est pas plus dangereux en termes de complexité, mais il est plus insidieux. Le code humain peut contenir des erreurs grossières : un point-virgule manquant, une boucle infinie. Le code généré par l'IA est souvent propre, bien commenté, et fonctionnel. Il passe les tests unitaires. Il est donc plus difficile à détecter. C'est comme un cambrioleur qui ne casse pas la porte - il utilise une clé que vous avez oublié de retirer. Le danger n'est pas dans la force, mais dans la discrétion.
Faut-il arrêter d'utiliser les assistants d'IA pour écrire du code ?
Non. L'IA augmente la productivité de 30 à 50 %. L'objectif n'est pas de l'éliminer, mais de l'encadrer. Les entreprises qui ont abandonné les assistants d'IA ont vu leur productivité chuter. Celles qui ont mis en place des revues de sécurité spécifiques ont vu leur sécurité augmenter de 60 % et leur productivité rester stable. Le problème n'est pas l'outil. C'est l'absence de processus.
Comment vérifier la conformité (HIPAA, PCI-DSS, GDPR) dans le code généré par l'IA ?
L'IA ne comprend pas les réglementations. Elle ne sait pas ce qu'est un champ PII ou comment appliquer le principe de moindre privilège selon le GDPR. Pour vérifier la conformité, vous devez combiner deux choses : 1) des outils de SAST spécialisés qui incluent des règles pour HIPAA et PCI-DSS (comme Mend SAST), et 2) une revue humaine par un expert en conformité. L'IA peut vous dire qu'une clé est exposée. Elle ne peut pas vous dire si cette clé accède à des données médicales protégées par HIPAA. C'est là que l'humain entre en jeu.
Quels sont les langages les plus à risque pour le code généré par l'IA ?
Les langages dynamiques sont les plus vulnérables : Python, JavaScript, Ruby. Ils permettent des comportements trop flexibles : exécution dynamique, évaluation de chaînes, accès aux variables globales. L'IA les utilise plus souvent parce qu'ils sont plus « faciles ». Java et C# sont plus sécurisés par défaut, mais l'IA y génère souvent des erreurs de contrôle d'accès ou de gestion de session. En 2024, 47 % des vulnérabilités critiques provenaient de JavaScript, 28 % de Python, et 15 % de Java. Les langages compilés comme Go ou Rust sont moins exposés, mais pas exemptés.
