La sécurité du code généré¶
La sécurité est le domaine où la recherche sur le code généré par IA est la plus ancienne et la plus solide : les premiers travaux datent de 2021, avec des protocoles reproductibles. Ce chapitre les présente dans l'ordre, puis en tire les conséquences pour le contrôle qualité.
Le code proposé seul¶
Pearce et al. (2022) : 40 % de suggestions vulnérables¶
L'étude fondatrice, Asleep at the Keyboard? (Pearce et al., IEEE Symposium on Security and Privacy 2022, arXiv 2108.09293), a demandé à GitHub Copilot de compléter 89 scénarios conçus pour exposer des failles connues, et a analysé les 1 689 programmes obtenus.
| Axe de l'étude | Scénarios | Programmes valides | Vulnérables |
|---|---|---|---|
| Diversité des failles (18 des 25 CWE les plus dangereuses) | 54 | 1 084 | 44,0 % |
| Diversité des formulations (injection SQL) | 17 | 407 | 37,4 % |
| Diversité des domaines (matériel, Verilog) | 18 | 198 | 28,3 % |
Au total, environ 40 % des suggestions étaient vulnérables, que l'on regarde la première suggestion seule ou l'ensemble.
Ce que mesure exactement cette étude
Les scénarios ont été conçus pour tenter le modèle : chacun place le développeur juste avant une ligne où une faille classique est possible. Les 40 % ne sont donc pas un taux de vulnérabilité du code IA « en général » ; c'est la fréquence à laquelle le modèle tombe dans le piège quand on le lui tend. C'est néanmoins le bon chiffre pour le contrôle qualité : les situations à risque sont précisément celles qu'il faut contrôler.
Fu et al. (2025) : dans les vrais dépôts¶
Fu et al. (TOSEM 2025, arXiv 2310.02059) sont allés chercher sur GitHub des extraits de code attribués à Copilot, CodeWhisperer et Codeium dans de vrais projets. Résultat : 29,5 % des extraits Python et 24,2 % des extraits JavaScript présentent une faiblesse de sécurité, répartie sur 43 catégories CWE. Copilot Chat, quand on lui fournit l'avertissement de l'analyseur statique, corrige jusqu'à 55,5 % des problèmes.
Ce dernier chiffre est important pour la conception d'un orchestrateur : l'IA corrige mieux qu'elle ne produit quand on lui fournit un signal externe. C'est la boucle analyse statique → correction, qui revient dans le chapitre Agents autonomes.
Le développeur assisté¶
Perry et al. (2023) : moins sûr, et plus confiant¶
L'étude de Perry, Srivastava, Kumar et Boneh (Stanford, ACM CCS 2023, arXiv 2211.03622) ne mesure plus le modèle seul, mais le développeur avec le modèle. 47 participants, dont 33 avec un assistant (codex-davinci-002) et 14 sans, ont réalisé cinq tâches à risque.
| Tâche | Avec assistant | Sans assistant |
|---|---|---|
| Signature ECDSA : solutions sûres | 3 % | 21 % |
| Répertoire isolé : solutions sûres | 12 % | 29 % |
| Insertion SQL : code injectable | 36 % | 7 % |
Le résultat le plus important n'est pas dans ce tableau : les participants aidés par l'IA étaient plus nombreux à croire leur code sûr. Ceux qui faisaient moins confiance à l'IA et reformulaient leurs requêtes produisaient moins de failles.
Sandoval et al. (2023) : un résultat contraire¶
La même année, Sandoval et al. (USENIX Security 2023, arXiv 2208.09727) trouvent un effet faible : 58 étudiants implémentant une liste chaînée en C produisent des failles critiques à un taux « pas plus de 10 % supérieur » au groupe témoin.
Erreur fréquente : opposer les deux études
Les deux résultats ne se contredisent pas vraiment. Sandoval étudie une tâche de programmation générale où la sécurité n'est qu'un effet de bord ; Perry étudie des tâches choisies parce qu'elles sont piégeuses (cryptographie, injection). La leçon combinée : l'IA dégrade peu la sécurité moyenne, mais beaucoup la sécurité dans les zones à risque. C'est exactement la justification de la règle « toujours relu » pour le code sensible (Échantillonnage).
Une faille nouvelle : les paquets hallucinés¶
Spracklen et al. (USENIX Security 2025, arXiv 2406.10279) ont fait générer 576 000 extraits de code Python et JavaScript par 16 modèles, contenant environ 2,23 millions de références à des paquets :
- 19,7 % des paquets référencés n'existent pas ;
- 205 474 noms inventés distincts ;
- taux moyen d'au moins 5,2 % pour les modèles commerciaux, 21,7 % pour les modèles ouverts ; le meilleur (GPT-4 Turbo) à 3,59 % ;
- surtout, 43 % des noms inventés reviennent dans les 10 relances d'une même requête.
Ce dernier point rend l'attaque possible : un attaquant peut publier un paquet malveillant sous un nom que les modèles inventent de façon répétée. Le terme slopsquatting, forgé en 2025 par Seth Larson de la Python Software Foundation (Wikipédia, source secondaire), désigne cette attaque.
Ce que ça change pour un orchestrateur
Une dépendance ajoutée par un agent est une caractéristique critique au sens du plan de contrôle : à vérifier unitairement à chaque run (existence du paquet, ancienneté, nombre de téléchargements, liste blanche), jamais par échantillonnage. C'est un poka-yoke simple et peu coûteux, ajouté pour cette raison à la liste du chapitre Jidoka, andon, poka-yoke et au plan de contrôle type.
À retenir
- Tendu un piège classique, un modèle y tombe environ 4 fois sur 10 (Pearce, 2022) ; dans le code réellement publié, un quart à un tiers des extraits attribués à l'IA portent une faiblesse (Fu, 2025).
- L'effet sur un développeur assisté dépend du terrain : faible en moyenne, fort sur le code sensible — avec une confiance accrue (Perry, 2023).
- Un paquet sur cinq cité par un modèle peut ne pas exister, et les inventions sont reproductibles, donc exploitables.
- L'IA corrige bien les failles qu'un outil externe lui signale.