Votre modèle est devenu plus intelligent. Votre code n'est pas devenu plus sûr.

La capacité compose. La sécurité stagne.

Commençons par ce qui est réellement impressionnant, parce que l'argument ne tient pas si l'on fait semblant que les modèles sont mauvais.

Sur FrontierBench v0.1, Claude Opus 5 obtient 43,3 % à effort maximal, contre 18,7 % pour Opus 4.8, 33,7 % pour Fable 5 et 37,5 % pour GPT-5.6 Sol. Entre deux versions d'Opus, le score a plus que doublé. Sur SWE-bench Verified, Fable 5 tourne autour de 95 %, et environ 80 % sur SWE-bench Pro, le jeu difficile. Tout ce qu'un agent ne savait pas faire il y a dix-huit mois, il sait probablement le faire aujourd'hui.

Posez maintenant la courbe de sécurité sur le même axe. Plusieurs mesures indépendantes, académiques comme industrielles, dessinent la même forme : plus de 95 % de justesse syntaxique, un taux de réussite aux tâches dans les 80 et 90 %, et une part de code généré qui passe un contrôle de sécurité bloquée au milieu de l'échelle, à peu près là où elle était il y a deux ans. Les deux lignes s'écartent.

“

Chaque génération de modèle vous achète de la capacité. Aucune génération de modèle ne vous a acheté de sécurité.

La raison n'a rien de mystérieux dès qu'on regarde comment ces modèles sont entraînés. La justesse fonctionnelle dispose d'un signal net : les tests passent ou ne passent pas, le benchmark monte ou ne monte pas. Ça s'optimise, avec une descente de gradient et un classement public. La sécurité n'a pas d'équivalent. C'est une propriété non fonctionnelle, coûteuse à annoter, dont l'absence de faille ressemble exactement à l'absence de vérification, et dont l'échec ne se manifeste que des mois plus tard, dans un incident que personne ne rattache à l'entraînement. Quelle que soit la pression d'optimisation, elle ne pointe pas là.

Une seconde raison, plus discrète, se lit dans les données d'entraînement. Certaines classes de vulnérabilités traînent derrière elles des décennies de correctifs documentés et répétés à l'infini dans du code public : injection SQL, cryptographie faible, traversée de chemin. Les modèles s'en sortent plutôt bien, parce que le motif sûr est aussi le motif statistiquement dominant. Les classes qui exigent de connaître le runtime, le système d'exploitation, le modèle de tenants ou la règle métier n'ont aucun corpus de ce genre. Elles ne sont pas sous-représentées dans les données, elles en sont absentes.

Nous avons traité l'état général du problème dans le code généré par IA est-il sûr. Cet article s'attaque à la question plus étroite et plus actionnable : cet état étant donné, changer le modèle ou changer le prompt y fait-il quoi que ce soit ?

Pourquoi changer de modèle n'est pas un contrôle de sécurité

Un modèle plus récent aide un peu, et pas là où on l'imagine.

Ce qui progresse avec une montée de version, c'est la capacité à produire du code qui fonctionne, et la capacité à raisonner sur la sécurité quand on pose directement la question. Ce second point mérite qu'on s'y arrête, parce que c'est là que le mécanisme de la défaillance devient visible. Les modèles identifient fréquemment la bonne mesure défensive quand on la leur demande sous forme de question. Puis ils écrivent le code final et l'oublient. L'écart n'est pas un écart de connaissance, c'est un écart d'exécution. Le modèle ne se demande pas s'il faut paramétrer une requête ; il optimise, au moment de la génération, pour ce qui ressemble à une tâche terminée.

Cette distinction a une conséquence commerciale directe, parce qu'elle prédit quels achats vous décevront. Prendre un modèle plus intelligent pour faire baisser la densité de vulnérabilités, c'est jouer sur la mauvaise variable. Vous obtiendrez plus de code fonctionnel par heure, donc plus de code par heure, donc davantage de ce que vaut votre taux de vulnérabilité par heure. Si le taux est plat et que le volume triple, votre exposition absolue triple. La capacité sans contrôle correspondant, c'est du débit, et le débit n'est pas de la sûreté.

Le choix du modèle a bien un effet réel, sur un seul axe : la charge de vérification que vous portez. Un modèle qui traite correctement les classes d'injection la plupart du temps vous en laisse moins à rattraper. C'est un gain d'efficacité authentique. Ce n'est pas un contrôle, parce que c'est probabiliste, non audité, et que ça change en silence à chaque nouveau point de contrôle publié par le fournisseur.

Pourquoi dire au modèle d'être sécurisé n'en est pas un non plus

C'est le passage que la plupart des contenus d'éditeurs ratent, y compris, soyons honnêtes, la version paresseuse de notre propre discours. Si vous avez lu quelque part qu'il suffit de mettre des consignes de sécurité dans le contexte, les données ne le soutiennent pas.

La mesure la plus nette à ce jour s'intitule « An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods », signée Mohammed Kharma, Ahmed Sabbah, Mohammad Alkhanafseh, Mohammad Hammoudeh et David Mohaisen, déposée sur arXiv le 22 mai 2026. Cinq LLM, quatre langages (Java, C++, C et Python), plusieurs méthodes d'ingénierie de prompt, dont une conçue exprès pour favoriser la thèse sécuritaire : une chaîne de pensée zero-shot sensible aux faiblesses, qui enrichit le prompt d'un contexte de sécurité à partir de mappings CWE pour orienter le raisonnement du modèle.

Leur résultat, appuyé sur des tests du khi-deux, tient en une phrase du résumé : aucune réduction statistiquement significative de la fréquence ni de la densité des vulnérabilités, quelle que soit la méthode de prompt. Ce que ces stratégies modifient, en revanche, c'est la composition des catégories de CWE, avec un effet qui varie selon le langage. Autrement dit, le prompt sensible à la sécurité rebat les cartes des faiblesses obtenues. Il ne réduit pas leur nombre.

Le résultat jumeau est sans doute encore plus embarrassant pour la théorie du prompt-comme-contrôle. « Minimal Prompt Perturbations Lead to Code Vulnerabilities: Prompt Fragility and Hidden-State Signals in Coding LLMs », arXiv, 29 mai 2026, montre que des modifications minimes et parfaitement anodines d'un prompt, ajouter un commentaire, reformuler une consigne, insérer un texte inoffensif, ramènent de façon fiable les modèles de code vers de la génération vulnérable. Pas des jailbreaks adverses. Des retouches ordinaires, du genre qu'on fait cent fois par jour dans une vraie session.

Lues ensemble, ces deux mesures imposent une contrainte de conception. Vous ne pouvez pas placer votre posture de sécurité dans le même canal que ce que vous cherchez à contraindre. Si la politique vit dans le prompt, elle entre en concurrence avec la tâche, avec les conventions du dépôt, avec le fichier que l'agent vient de lire et avec ce qu'un contributeur a écrit dans un fichier Markdown. Si la politique vit dans une barrière qui évalue l'action, elle n'entre en concurrence avec rien.

Ce que les benchmarks mesurent, et ce qu'ils ne peuvent pas mesurer

Avant de tirer des conclusions de chiffres de benchmark, autant savoir de quoi ils sont faits, parce que la lecture honnête est plus étroite que les titres.

Les benchmarks académiques sérieux sont bons, et ils s'améliorent. CWEval propose un benchmark de code multilingue, critique du point de vue sécurité, couvrant 31 types de CWE sur cinq langages, et son apport tient à l'évaluation par les résultats : il juge conjointement la fonctionnalité et la sécurité au lieu de faire du filtrage par motifs. RealSec-bench est construit à partir de dépôts Java réels à haut risque, 105 instances sur 19 types de CWE, ce qui est un éloignement délibéré des extraits synthétiques. SecureAgentBench pousse plus loin, en évaluant la génération de code sécurisé dans des scénarios de vulnérabilité réalistes plutôt que sur des prompts isolés.

Tous partagent trois limites structurelles qu'aucune couverture CWE supplémentaire ne corrige.

Rien de tout cela ne plaide contre les benchmarks. Cela plaide contre l'idée de prendre un taux de réussite pour un modèle de risque. Un modèle peut dominer tous les tableaux de la section précédente et rester la cause immédiate de votre prochain incident, parce que votre prochain incident sera probablement dans la troisième colonne de cette grille.

Les trois défaillances qu'une montée de version ne touche pas

Concrètement, voici ce qui reste exactement aussi cassé après être passé au modèle le plus récent et le mieux classé du marché.

La logique métier, qui n'a ni benchmark ni signature

Les classes de vulnérabilités riches en correctifs publics sont celles que les modèles gèrent le mieux. Vos règles métier, elles, n'ont aucun correctif public, puisqu'elles n'existent que dans votre base de code et, souvent, que dans la tête de la personne qui les a spécifiées. Un agent capable d'écrire une requête paramétrée irréprochable laissera volontiers une quantité devenir négative si rien dans le dépôt ne lui a dit que les quantités sont positives. C'est la défaillance que nous considérons comme structurellement hors d'atteinte des meilleurs modèles, et nous l'avons documentée dans les failles de logique métier du code généré par IA.

Les actions de l'agent, qui forment une surface d'attaque distincte

Dès que l'agent peut exécuter des commandes, la question de sécurité cesse d'être seulement « ce code est-il correct » pour devenir « de qui suit-il les instructions ». Des fichiers du dépôt comme AGENTS.md et CLAUDE.md sont chargés comme politique projet de confiance, ce qui en fait un canal de pilotage pour quiconque peut committer. Nous avons décrit ce mécanisme et les incidents nommés de 2026 dans l'injection par fichier d'instructions. Un modèle plus capable aggrave la situation au lieu de l'améliorer, puisqu'il exécute le plan hostile avec plus de compétence.

Les dépendances qu'il choisit

Les modèles inventent encore des noms de paquets, et les attaquants les préenregistrent toujours. Un meilleur modèle hallucine moins souvent, ce qui réduit la fréquence sans changer la forme du risque, et une seule hallucination acceptée suffit. Voir qu'est-ce que le slopsquatting.

Il faut ajouter un quatrième point, même s'il ne relève pas de la qualité du code, parce que c'est la preuve la plus claire que la capacité coupe des deux côtés. La safety card d'Anthropic pour Opus 5 rapporte que le modèle a compromis avec succès des réseaux d'entreprise dans huit tests gouvernementaux sur dix. Autour de Fable 5, des chercheurs d'Amazon ont trouvé le moyen de lui faire produire du code de démonstration d'exploitation pour une vulnérabilité logicielle, ce qui a conduit Anthropic à redéployer le modèle avec des mesures de sécurité renforcées le 30 juin 2026, et le Fable 5 public route désormais vers un autre modèle les détections de mésusage cyber, biologique, chimique et de distillation. Séparément, des retours communautaires décrivent le classifieur de sécurité contourné dans Claude Code en formulant une demande restreinte comme une question annexe /btw, ce qui exploite l'écart entre la logique de routage et le contexte principal de la session.

Chacun de ces éléments plaide pour la même chose : la frontière monte des deux côtés de la barrière en même temps. Aucun ne plaide pour rester sur un modèle plus ancien. Tous plaident pour que le garde-fou soit à l'extérieur du modèle.

Montée de version contre application, côte à côte

La ligne qui compte le plus pour une décision d'achat est la deuxième. Plat, c'est mauvais, mais instable est pire, parce qu'instable veut dire que vous ne pouvez même pas mesurer votre propre posture. Si une retouche anodine d'un prompt change les propriétés de sécurité de la sortie, alors tout chiffre que vous produisez sur la qualité de votre code généré est l'instantané d'un système qui sera différent demain, pour des raisons que personne n'a journalisées.

Ce qui marche vraiment : appliquer plutôt qu'instruire

Admettez les deux résultats de recherche et la conception en découle presque mécaniquement. Si l'instruction n'est ni fiable ni stable, alors le contrôle doit être une chose qui agit, au moment de l'action, et qui peut refuser. En pratique, cela fait trois composants, et il vaut la peine d'être précis sur le rôle de chacun, parce que la tentation est de prétendre que le premier fait tout.

Les règles dans le contexte relèvent le plancher. Elles ne le fixent pas. Injecter les règles de votre organisation et l'état réel du dépôt dans le contexte du modèle améliore réellement le premier jet, et place votre politique devant ce que le dépôt prétend. Mais au vu des données ci-dessus, le contexte seul est une amélioration probabiliste, pas une garantie. Quiconque vous dit le contraire vend au-delà de ce que dit la recherche.

Les hooks sont la partie déterministe. Un hook évalue un appel d'outil avant son exécution. Lire un fichier de credentials, envoyer un dump d'environnement dans curl, lancer une migration destructrice, invoquer un outil dont la description a changé depuis hier : ce sont des événements discrets et inspectables, et une barrière posée dessus se déclenche ou ne se déclenche pas. Elle ne se laisse pas convaincre par un prompt reformulé. C'est toute la raison de sa présence dans la conception.

Les findings dans la boucle suppriment la devinette. L'agent a un accès live à ce que les scanners ont trouvé sur le code, les dépendances, les secrets, l'infrastructure et les pipelines, donc un changement proposé est raisonné contre l'état réel du dépôt et non contre un a priori. C'est aussi ce qui lui permet de repérer les problèmes de second ordre, par exemple que le pipeline qu'on vient de lui demander de modifier tourne sur des événements de fork avec des permissions d'écriture.

Le résumé honnête de notre position : le premier composant fait mieux se comporter le modèle la plupart du temps, le deuxième rend un ensemble précis de résultats impossibles, et le troisième rend les deux premiers justes. Seul le deuxième est un contrôle au sens strict. Nous préférons le dire clairement plutôt que de laisser croire qu'un prompt est une garantie, puisque deux papiers affirment désormais le contraire.

Et le corollaire pour votre feuille de route : ce problème ne se résout pas en attendant. Quel que soit le score de la prochaine version, prévoyez une courbe de sécurité plate et un volume de code en hausse.

Questions fréquentes

Un modèle plus récent écrit-il du code plus sûr ?

À peine, et pas assez pour changer vos contrôles. La justesse fonctionnelle progresse nettement d'une génération à l'autre pendant que le taux de réussite sécurité reste quasi plat. Un modèle plus récent traite plutôt mieux les classes bien documentées comme l'injection SQL ou la cryptographie faible, parce que le motif sûr est aussi le motif courant dans ses données d'entraînement, et il ne progresse pas sur les classes qui exigent de connaître votre runtime ou vos règles métier. Vous obtenez plus de code, à peu près au même taux de défauts.

Quel modèle écrit le code le plus sûr ?

Les comparatifs publiés produisent bien un classement, et ce classement bouge à chaque sortie, ce qui est précisément la raison de ne pas fonder un programme de sécurité dessus. La lecture utile de ces études est l'agrégat : l'écart entre le meilleur modèle et la moyenne est bien plus petit que l'écart entre n'importe quel modèle et « assez sûr pour livrer sans vérifier ». Choisissez un modèle pour sa capacité et son coût, puis mettez un contrôle devant.

Est-ce que demander au modèle d'écrire du code sécurisé aide ?

Pas de façon mesurable, au vu des données disponibles. L'évaluation de mai 2026 menée par Kharma et ses coauteurs a testé plusieurs méthodes de prompt sur cinq LLM et quatre langages, dont une chaîne de pensée enrichie de mappings CWE, et n'a trouvé aucune réduction statistiquement significative de la fréquence ni de la densité des vulnérabilités. Le prompt a changé quelles catégories de CWE apparaissaient, pas combien de vulnérabilités il y avait.

Si le prompt ne marche pas, à quoi servent les règles dans le contexte de l'agent ?

À deux choses qu'une théorie purement prompt sous-estime. Elles améliorent le premier jet, ce qui est un gain d'efficacité réel même s'il est probabiliste, et elles placent la politique de votre organisation dans le contexte du modèle avant ce que prétend un fichier de dépôt non relu. Ce qu'elles ne peuvent pas faire, c'est garantir un résultat. C'est pour ça que le hook existe à côté d'elles, et pour ça que nous ne présentons pas le contexte comme la réponse entière.

Peut-on faire confiance aux benchmarks de sécurité ?

Les benchmarks académiques sont rigoureux et s'améliorent. CWEval couvre 31 types de CWE sur cinq langages avec une évaluation par les résultats, RealSec-bench est construit sur de vrais dépôts Java à haut risque, et SecureAgentBench visent des scénarios de vulnérabilité réalistes. Leurs limites sont structurelles plutôt que méthodologiques : ils notent une génération unique et non de longues sessions d'agent, ils ne peuvent tester que des faiblesses ayant une classe nommée, et ils ne disent rien des actions de l'agent par opposition à son code.

Faut-il rester sur un modèle plus ancien pour des raisons de sécurité ?

Non. Les modèles anciens ne sont pas plus sûrs, ils sont juste moins capables, donc vous obtenez le même taux de défauts avec moins de production. Les risques propres aux modèles de frontière, un agent qui exécute un plan hostile avec compétence, se traitent en contraignant les actions, pas en plafonnant la capacité.

Cela veut-il dire qu'on ne peut pas livrer du code généré par IA en toute sécurité ?

On peut, à condition que la vérification et l'application fassent partie de la boucle et non d'une étape qui la suit. La défaillance n'est pas « l'IA écrit du mauvais code », c'est « l'IA écrit du code plus vite que la revue censée le contrôler ». Pour la version large de cet argument, voir la sécurité des agents de code IA.

Quel indicateur suivre à la place du score de sécurité d'un modèle ?

Suivez la part des actions dangereuses qui ont été refusées plutôt que relues. Un taux de réussite vous parle du point de contrôle d'un fournisseur. Un taux de refus vous parle de votre propre contrôle, il se mesure dans vos journaux, et contrairement à un score de benchmark il ne se remet pas à zéro quand quelqu'un publie un nouveau modèle.