Le code écrit par une IA progresse en sécurité, mais seulement sur les failles faciles à corriger

Votre équipe livre plus vite depuis qu'elle utilise un outil d'IA pour écrire du code. Une question reste en suspens : le code ainsi produit est-il sûr ? Jusqu'ici, les mesures répondaient non, avec une régularité déprimante. La dernière change la réponse, sans la renverser.

Le 29 octobre 2026, Veracode a publié la mise à jour d'automne de son étude sur la sécurité du code généré par IA. Veracode est une entreprise américaine qui vend des outils de test de sécurité logicielle. Son étude suit la même méthode à chaque édition.

Le principe est simple. On demande à un modèle — le programme d'IA dans une version donnée — d'écrire du code pour une tâche précise. On ne lui donne aucune consigne de sécurité. On examine ensuite le code produit pour voir s'il contient l'une des failles recherchées. Une tâche est comptée comme réussie si aucune faille n'est trouvée.

Cette édition teste 18 modèles, dans quatre langages de programmation et sur quatre familles de failles. Le résultat principal tient en un chiffre : le taux de réussite moyen passe de 56 % à 62 %. C'est le premier mouvement notable depuis le début de la série.

Ce que le rapport a réellement testé

Les quatre familles de failles correspondent à des erreurs classiques, connues depuis longtemps.

La première est l'injection de commandes dans une base de données. Une page web transmet un texte, et ce texte est exécuté comme une instruction par la base. La deuxième est le mauvais emploi du chiffrement, qui laisse des données lisibles alors qu'elles devraient être protégées.

La troisième est l'injection de scripts dans une page web. Un texte fourni par un visiteur se retrouve exécuté dans le navigateur d'un autre visiteur. La quatrième est l'injection de fausses lignes dans les journaux d'activité, ces fichiers où un serveur note ce qui se passe.

Le test porte sur quatre langages : Python, C#, JavaScript et Java. Il ne couvre pas les dépendances externes, ces bibliothèques écrites par d'autres. Il ne vérifie pas non plus si le code fait son travail. Il répond à une seule question : contient-il l'une des quatre failles cherchées ?

Cette limite compte. Un taux de réussite de 62 % ne signifie pas que 62 % du code est bon. Il signifie que, dans ce cadre précis, 62 % des tâches n'ont produit aucune des failles recherchées.

Un progrès réel, mais partiel

Le taux de code vulnérable descend d'environ 44 % à environ 38 %.

Pour mesurer ce que cela représente, regardons l'historique. Quatre éditions précédentes, plus de cent modèles testés, et une moyenne bloquée entre 55 % et 56 %. Les progrès affichés par les modèles ne se traduisaient pas en sécurité. Cette fois, la moyenne bouge.

La distribution change aussi. Dix modèles atteignent maintenant au moins 60 %, contre quatre lors de l'édition précédente. Le meilleur score atteint 73 %, partagé par deux modèles. Le bas du classement reste entre 44 % et 50 %.

Deux constats pour un dirigeant. D'abord, le meilleur modèle échoue encore sur plus d'une tâche de sécurité sur quatre. Ensuite, l'écart entre le premier et le dernier correspond à plus du double de risque de faille. Choisir un modèle est donc déjà une décision de sécurité, avant même de parler d'outils de contrôle.

Mais le chiffre de 38 % reste le plus important. Dans ce test, près de quatre tâches sur dix produisent du code avec une faille connue. Une équipe qui génère cent morceaux de code par semaine en obtient donc une trentaine à vérifier.

La faille qui progresse est la plus facile à corriger

Le progrès se concentre sur une seule famille : l'injection de scripts dans une page web.

Sur cette famille, le taux de réussite moyen passe de 15 % à 18 %. C'est la plus forte hausse du rapport, et de loin le score le plus bas : plus de quatre tentatives sur cinq échouent encore.

Les trois autres familles bougent à peine. Le chiffrement mal employé reste à 87,4 %, l'injection dans une base de données à 83,7 %. L'injection dans les journaux d'activité reste à 12,6 %, sans amélioration depuis le début de la série.

Pourquoi cet écart ? L'injection de scripts suit un modèle simple, qu'un programme peut apprendre par répétition. Une bonne pratique courte et répandue consiste à ne jamais insérer un texte extérieur dans une page sans l'encoder. Les modèles récents l'appliquent plus souvent.

L'injection dans les journaux demande autre chose. Il faut suivre un texte à travers plusieurs fonctions et décider s'il atteint le journal sans être neutralisé. Aucune fonction unique ne règle le problème. C'est un raisonnement, pas un réflexe.

L'analogie est celle du correcteur orthographique. Il repère les fautes courantes, parce qu'il les connaît par cœur. Il ne comprend pas le sens d'une phrase, et il laisse passer une erreur de logique. Les modèles progressent là où l'on reconnaît un motif, pas là où il faut suivre un raisonnement.

La conséquence pratique est désagréable. Les tableaux de bord s'améliorent sur les failles faciles à corriger. Les failles contextuelles, qui demandent de comprendre le flux des données, restent au même niveau.

Ce que le classement des modèles ne dit pas

Le classement annuel est souvent lu comme un palmarès. Il dit moins que cela.

Premier point : les modèles les plus performants sont les plus gros, donc les plus chers. L'écart entre un grand modèle et un petit atteint quatre points de taux de réussite. L'édition précédente concluait que la taille n'avait presque aucun effet. Ce n'est plus vrai, mais quatre points ne justifient pas le prix.

Deuxième point : un modèle spécialisé dans l'écriture de code n'est pas plus sûr qu'un modèle généraliste. Les modèles généralistes atteignent 54 % en moyenne, les modèles spécialisés 51 %. Être entraîné à écrire du code plus vite ne signifie pas l'écrire plus sûrement.

Troisième point : le langage compte plus que le modèle. Python atteint 64,2 %, C# 59,6 %, JavaScript 57,0 %. Java reste à 31 %, avec un écart de 26 à 33 points sur les autres langages. Une entreprise dont le système principal est en Java doit donc s'attendre à un effort de vérification plus lourd.

Ils indiquent où porter l'attention : Java, l'injection dans les journaux, les dépendances externes.

Ce que cela change dans votre budget et vos contrôles

Veracode conclut qu'un modèle intermédiaire, associé à un outil d'analyse, fait mieux qu'un modèle haut de gamme sans contrôle. Il faut lire cette conclusion avec prudence : l'entreprise vend précisément ces outils d'analyse.

Le principe reste valable, indépendamment du vendeur. Un modèle qui réussit 62 % des tâches laisse 38 % de cas à traiter. Un modèle à 73 % en laisse 27 %. Dans les deux cas, la vérification reste le seul moyen de savoir ce qui est parti en production.

Trois décisions découlent de ces chiffres.

Traitez le code généré comme non vérifié par défaut. Aucun modèle du classement ne dépasse 73 %. La relecture et l'analyse automatique ne sont pas une formalité, elles sont le contrôle principal.

Mesurez par langage et par type de faille. Un taux global masque les écarts. Si votre système est en Java, ou si vos journaux servent à enquêter après incident, le risque est plus élevé que la moyenne affichée.

Regardez les dépendances autant que le code produit. Le rapport rappelle que 66 % des vulnérabilités les plus dangereuses et les plus anciennes viennent de composants externes, avec un délai de correction moyen de 358 jours. Aucun modèle testé ici ne couvre ce périmètre.

Selon l'étude annuelle du même éditeur, 82 % des organisations portent une dette de sécurité, c'est-à-dire des failles connues non corrigées depuis plus d'un an. Pour 60 % d'entre elles, cette dette est critique. Le délai médian de correction atteint 243 jours.

Ces chiffres décrivent la clientèle de Veracode et servent son argumentaire. Ils indiquent une direction, pas une mesure de votre situation. La conclusion pratique tient : le code généré par IA ajoute du volume à un stock de failles déjà mal résorbé.

Ce qu'il faut retenir

• Le taux de réussite moyen des modèles testés passe de 56 % à 62 %, premier progrès notable depuis le début du suivi.
• Malgré ce progrès, près de quatre tâches sur dix produisent encore du code avec une faille connue, et le meilleur modèle échoue sur plus d'une sur quatre.
• L'amélioration se concentre sur l'injection de scripts dans les pages web, la faille la plus facile à corriger ; l'injection dans les journaux reste à 12,6 %.
• Java reste le langage le plus risqué, avec 31 % de réussite, contre 64 % pour Python.
• Un modèle spécialisé dans le code n'est pas plus sûr qu'un modèle généraliste ; le choix du modèle ne remplace pas la vérification.
• La vérification indépendante, y compris sur les composants externes, reste le contrôle décisif avant mise en production.