Le code écrit par l’IA est-il sécuritaire?

Les outils de programmation par IA excellent à produire du code qui fonctionne. Mais fonctionner et être sûr, ce n’est pas la même chose. Un formulaire de connexion peut marcher parfaitement pour les utilisateurs honnêtes et laisser quand même un attaquant lire tous les comptes de la base de données. La recherche menée jusqu’ici va dans le même sens : les modèles choisissent souvent la façon non sécuritaire de faire les choses, et les personnes qui les utilisent ont tendance à ne pas s’en apercevoir.

Cela ne veut pas dire qu’il faut cesser d’utiliser l’IA pour écrire du code. Cela veut dire qu’il faut traiter ce qu’elle produit comme le code d’un nouveau collègue rapide et enthousiaste, à qui personne n’a encore expliqué vos règles de sécurité : utile, souvent juste, et toujours révisé avant de toucher de vrais utilisateurs ou de vraies données.

Pourquoi le code de l’IA pèche-t-il sur la sécurité?

Un modèle de langage apprend à écrire du code à partir d’énormes quantités de code public, et une bonne partie de ce code public n’est pas sécuritaire. Quand vous demandez « une page qui affiche les commandes d’un utilisateur », le modèle prend le chemin le plus court pour afficher des commandes à l’écran. Si vous ne le demandez pas, il risque de ne pas vérifier que la personne qui fait la demande est bien celle à qui appartiennent ces commandes, de ne pas échapper le texte avant de l’afficher, ou de ne pas garder une clé hors du navigateur.

Trois problèmes reviennent sans cesse :

• Des vérifications manquantes. Les entrées ne sont pas validées, le texte des utilisateurs est affiché sans être échappé (ce qui ouvre la porte au cross-site scripting, où le script d’un attaquant s’exécute dans le navigateur de quelqu’un d’autre), ou le serveur se fie à tout ce que le navigateur lui envoie.
• Des secrets qui fuient. Des clés d’API et des mots de passe se retrouvent dans le code exécuté dans le navigateur ou dans un dépôt public.
• Des dépendances inventées ou risquées. Le modèle importe un paquet (une bibliothèque de code toute faite) désuet, ou qui n’existe tout simplement pas.

Une routine de révision rapide pour le code écrit par l’IA

Pas besoin d’être spécialiste de la sécurité pour attraper les problèmes les plus courants. Avant d’accepter une modification, passez ce tableau en revue, ou collez le prompt ci-dessous dans une deuxième session d’IA pour obtenir une première lecture.

Tu es un réviseur de sécurité minutieux. Révise le code ci-dessous comme s’il allait tourner sur un site Web public avec de vraies données d’utilisateurs.
Fais la liste, par ordre de gravité :
1. Tout endroit où un utilisateur pourrait lire ou modifier des données qui ne sont pas les siennes.
2. Toute entrée d’utilisateur utilisée sans validation ni échappement.
3. Tout secret (clé, jeton, mot de passe) présent dans le code.
4. Chaque paquet externe importé, et si tu es certain qu’il existe.
Pour chaque problème, cite la ligne, explique le risque en mots simples et propose une correction. Si tu n’es pas sûr, dis-le.
[colle le code]

Une deuxième révision par l’IA est un filtre utile, pas une garantie. Elle attrape beaucoup d’erreurs évidentes, mais elle peut aussi en manquer ou lancer de fausses alertes : traitez sa liste comme une liste de choses à vérifier vous-même.

Que montrent vraiment les études?

Les modèles choisissent souvent l’option non sécuritaire. En juillet 2025, l’entreprise de sécurité Veracode a publié son rapport GenAI Code Security Report. Elle a soumis plus de 100 modèles de langage à 80 tâches de programmation, chacune pouvant être réalisée de façon sûre ou non, puis a analysé les résultats. Dans 45 % des cas, le code contenait une vulnérabilité du Top 10 de l’OWASP, une liste très utilisée des risques de sécurité Web les plus graves. Java s’en tirait le moins bien, avec plus de 70 % d’échecs; Python, C# et JavaScript échouaient de 38 % à 45 % du temps. Les modèles ne se protégeaient pas contre le cross-site scripting dans 86 % des tâches concernées. Veracode signale aussi que les modèles récents écrivent du code plus correct, sans être devenus plus sécuritaires. Gardez en tête qu’il s’agit du test d’un fournisseur, avec son propre outil d’analyse : les chiffres exacts dépendent de sa méthode.

Les gens font plus confiance au code de l’IA qu’ils ne le devraient. Une étude de Stanford menée par Perry et ses collègues, publiée d’abord en 2022, demandait à des participants de résoudre des tâches de programmation liées à la sécurité, certains avec un assistant d’IA basé sur un ancien modèle Codex d’OpenAI. Ceux qui avaient l’assistant ont écrit un code nettement moins sûr, et étaient aussi plus enclins à croire que leur code était sûr. Les participants qui se méfiaient davantage de l’IA et retravaillaient leurs prompts s’en tiraient mieux. Les outils se sont beaucoup améliorés depuis, mais le volet humain de cette conclusion, à savoir qu’un code à l’air assuré baisse notre vigilance, compte toujours.

Les modèles inventent des paquets, et des attaquants peuvent en profiter. Spracklen et ses collègues, dans un article accepté au USENIX Security Symposium 2025, ont généré 576 000 extraits de code en Python et en JavaScript avec 16 modèles populaires. En moyenne, au moins 5,2 % des paquets suggérés par les modèles commerciaux et 21,7 % de ceux suggérés par les modèles à code source ouvert n’existaient pas; ils ont recensé 205 474 noms inventés distincts. Un attaquant qui publie du code malveillant sous un nom que les modèles ont tendance à inventer peut le faire installer par quiconque fait confiance à la suggestion. Voilà pourquoi « vérifier que chaque nouveau paquet existe et que c’est bien celui voulu » figure dans le tableau de révision.

Prises ensemble, ces études ne disent pas que le code de l’IA est pire que celui des humains dans tous les cas. Elles disent qu’il échoue de façon prévisible, et que notre confiance grimpe plus vite que sa qualité. La solution est la même routine que les professionnels appliquent à tout code : précisez vos exigences de sécurité dans le prompt, gardez des humains à la révision de tout ce qui touche aux connexions, aux renseignements personnels ou à l’argent, et laissez les tests, pas les impressions, décider si une modification est prête.