Un signal d’alerte venu d’arXiv
Un nouveau preprint publié sur arXiv, intitulé Security of LLM-generated Code: A Comparative Analysis, remet une couche de prudence sur l’enthousiasme entourant les assistants de programmation. Les auteurs, Srivathsan G Morkonda, Mahmoud Selim et Hala Assal, disent avoir évalué empiriquement le code produit par sept grands modèles de langage populaires, en reproduisant des comportements réalistes de développeurs qui demandent à une IA de générer du code.
Le résultat central est simple, et inquiétant : les sept modèles évalués produisent du code contenant des vulnérabilités, et la majorité de ces failles sont classées en sévérité élevée ou critique. Il faut toutefois lire cette conclusion avec la bonne étiquette scientifique : il s’agit d’un preprint, soumis sur arXiv le 21 mai 2026, donc non encore évalué par les pairs. Ce n’est pas une preuve définitive, mais c’est un nouveau point de données dans un corpus de plus en plus cohérent.
L’intérêt de l’étude tient à son angle : elle ne se limite pas à demander si les LLM savent écrire du code fonctionnel. Elle demande si le code obtenu introduit réellement des faiblesses de sécurité, classables selon le référentiel CWE, utilisé par MITRE pour catégoriser les erreurs de conception et de programmation qui deviennent des vulnérabilités exploitables.
Les failles CWE qui reviennent sans cesse
Les résultats détaillés du preprint devront être confirmés par la lecture critique de la communauté, mais ils s’inscrivent dans une tendance déjà bien documentée : les modèles produisent souvent du code qui paraît propre, idiomatique et prêt à l’emploi, tout en réintroduisant des erreurs classiques.
Dans les travaux et rapports récents, les familles de failles les plus fréquentes sont familières aux équipes AppSec : injections SQL, XSS, log injection, mauvaises validations d’entrée, secrets ou identifiants codés en dur, cryptographie faible, mauvaise gestion de certificats, désérialisation non sécurisée, absence d’autorisation, traversée de chemins et erreurs mémoire en C ou C++. Autrement dit, l’IA ne crée pas seulement de nouveaux risques : elle industrialise aussi de vieux antipatterns.
Le rapport 2025 de Veracode, par exemple, affirme avoir testé plus de 100 LLM sur 80 tâches couvrant Java, Python, C# et JavaScript. Son chiffre le plus cité : 45 % des échantillons de code générés échouaient aux tests de sécurité et introduisaient des vulnérabilités liées à l’OWASP Top 10. Veracode a notamment ciblé quatre catégories : injection SQL, XSS, injection de journaux et algorithmes cryptographiques risqués. Son biais doit être signalé : Veracode vend des solutions de sécurité applicative. Mais sa méthodologie et son échelle donnent un repère utile.
BaxBench, un benchmark issu notamment de l’ETH Zurich, va dans le même sens pour les applications backend. Même le meilleur modèle testé y laisse 62 % des solutions soit incorrectes, soit vulnérables. Plus troublant encore : les chercheurs indiquent que, en moyenne, des exploits fonctionnels peuvent être exécutés contre plus de la moitié des programmes corrects générés par chaque LLM. Cela montre que la correction fonctionnelle n’est pas un proxy fiable de la sécurité.
ChatGPT, Copilot, Gemini : comparer sans surinterpréter
Comparer les outils est plus délicat qu’il n’y paraît. Les performances changent vite, les modèles accessibles sous un même nom commercial évoluent, et les résultats dépendent énormément du langage, du framework, du prompt et du type d’application.
Une étude publiée dans Gazi Journal of Engineering Sciences a comparé ChatGPT, GitHub Copilot et Gemini sur du code de connexion web à l’aide d’analyses statiques et dynamiques. Elle conclut que Copilot présentait le risque cumulé le plus élevé, que ChatGPT obtenait un profil de risque plus faible, et que Gemini produisait un code parfois plus optimisé mais contenant tout de même des failles critiques. Ce n’est pas un classement universel : c’est un scénario précis, sur un type de tâche précis.
À plus grande échelle, un autre preprint arXiv sur des dépôts GitHub publics a analysé 7 703 fichiers explicitement attribués à des outils IA. Les auteurs y trouvent 4 241 instances CWE réparties sur 77 types de vulnérabilités. La distribution des fichiers est aussi révélatrice de l’usage réel : 91,52 % étaient attribués à ChatGPT, 7,50 % à GitHub Copilot, 0,52 % à Amazon CodeWhisperer et 0,46 % à Tabnine. Ce chiffre ne prouve pas que ChatGPT est plus dangereux ; il montre surtout que son empreinte est plus visible dans l’échantillon.
L’image qui se dégage est donc moins un podium qu’une constante : aucun outil ne doit être traité comme une source de code sûre par défaut. Les modèles les plus récents sont meilleurs pour produire une syntaxe valide, mais les gains de sécurité semblent beaucoup moins réguliers.
Pourquoi la revue humaine ne suffit pas toujours
Le réflexe habituel consiste à dire : l’IA génère, l’humain révise. C’est nécessaire, mais insuffisant. D’abord parce que la quantité de code généré augmente plus vite que la capacité de revue. Ensuite parce que le code IA a un effet de surface : il a souvent l’air plausible, documenté et conventionnel, ce qui réduit la vigilance.
Un article de Neil Perry, Megha Srivastava, Deepak Kumar et Dan Boneh, présenté à ACM CCS, montre que des participants ayant accès à un assistant basé sur Codex écrivent globalement du code moins sécurisé que ceux qui n’y ont pas accès, tout en étant plus enclins à croire que leurs réponses sont sûres. C’est le cœur du problème : l’IA peut augmenter à la fois la production et la confiance, mais pas nécessairement la compétence de vérification.
La littérature n’est pas parfaitement unanime. L’étude Lost at C, publiée à USENIX Security, observe dans un contexte précis de programmation C que l’assistance LLM n’augmente pas les bogues critiques de plus de 10 % par rapport au groupe contrôle. Cette nuance est importante : l’impact dépend de la tâche, de l’expérience des développeurs et du type d’assistant. Mais elle ne contredit pas le besoin d’un pipeline de sécurité plus robuste.
Le contexte : l’IA est déjà dans le cycle de développement
Le sujet est devenu urgent parce que l’adoption est massive. Stack Overflow indiquait déjà dans son enquête développeurs 2024 que 76 % des répondants utilisaient ou prévoyaient d’utiliser des outils IA de développement. GitHub Copilot, ChatGPT, Gemini, Claude, CodeWhisperer, Cursor ou Tabnine ne sont plus des curiosités : ils sont intégrés dans les IDE, les dépôts, les revues de code et les flux CI/CD.
Les autorités de cybersécurité s’en préoccupent aussi. Le NCSC britannique a averti que le vibe coding, soit la génération rapide d’applications par prompts, ouvre une possibilité de rupture positive mais présente aujourd’hui des risques intolérables pour de nombreuses organisations. OWASP a intégré des risques liés aux LLM, dont la mauvaise gestion des sorties, et son édition 2025 insiste sur la génération de code non sûr et les dépendances inventées ou mal choisies.
Du côté des référentiels, MITRE continue de maintenir le CWE Top 25, tandis que le NIST recommande avec le Secure Software Development Framework d’intégrer la sécurité dans tout le cycle de vie logiciel. Le message implicite pour les équipes IA est clair : le code généré par modèle doit être traité comme du code non fiable jusqu’à preuve du contraire.
Ce que cela change pour les équipes techniques
La conséquence pratique n’est pas d’interdire les assistants IA. Ce serait irréaliste et probablement contre-productif. La bonne conclusion est plutôt de déplacer l’IA dans un cadre de contrôle.
Première mesure : imposer des garde-fous de génération. Les prompts doivent inclure des exigences précises : validation d’entrée, requêtes paramétrées, hachage moderne, gestion des secrets, contrôle d’accès, journalisation sans données sensibles, tests négatifs et menaces attendues. Les études sur le prompt engineering montrent que les consignes vagues du type rendre ce code sécurisé sont moins efficaces que des contraintes concrètes alignées sur CWE ou OWASP.
Deuxième mesure : automatiser la vérification. SAST, analyse de dépendances, détection de secrets, tests unitaires de sécurité, fuzzing, politiques IaC et scans de conteneurs doivent être exécutés sur le code IA comme sur le code humain. L’objectif n’est pas de remplacer la revue humaine, mais de lui retirer les erreurs mécaniques et répétitives.
Troisième mesure : tracer l’origine du code. Les organisations devraient savoir quelles portions ont été générées par IA, avec quel outil, dans quel contexte et avec quels contrôles. Sans traçabilité, il devient impossible de mesurer la dette de sécurité spécifique à l’IA.
Prospective : vers des modèles sécurisés par construction ?
La prochaine étape ne sera pas seulement de meilleurs chatbots de code. Elle passera par des modèles couplés à des politiques de sécurité, des générateurs contraints, des environnements sandboxés et des tests adversariaux systématiques. Les assistants devront peut-être refuser certains patrons dangereux, proposer par défaut des bibliothèques sûres, expliquer les hypothèses de sécurité et générer les tests d’abus avec le code applicatif.
Mais le preprint arXiv rappelle une limite fondamentale : tant que les modèles apprennent à partir d’un web rempli de code ancien, incomplet ou vulnérable, ils risquent de reproduire les défauts de leur corpus. La sécurité ne peut donc pas être ajoutée comme une couche cosmétique après la génération. Elle doit être intégrée dans les données, les benchmarks, les interfaces développeurs et les processus d’approbation.
Pour l’instant, la règle la plus saine est simple : le code généré par IA peut accélérer le développement, mais il ne doit jamais accélérer la mise en production sans contrôle. Les LLM savent produire du code convaincant. La question, désormais, est de savoir si nos pipelines savent résister à ce pouvoir de persuasion.