Le code écrit par des machines est devenu bien meilleur pour s’exécuter, et pas du tout meilleur pour être sûr. La mise à jour Spring 2026 GenAI Code Security de Veracode situe le taux de réussite en sécurité du code généré par IA à environ 55 %, soit exactement là où il se trouvait deux ans et plusieurs générations de modèles plus tôt. La correction du code a progressé nettement sur la même période, pas la sécurité, parce qu’un compilateur et une suite de tests notent la correction gratuitement, alors qu’aucun outil comparable n’existe pour noter la sécurité. Le commerce a acheté sur la courbe qui a bougé. Les stacks commerciales qui ont ajouté des intégrations générées cette année portent une dette de relecture, et celle-ci s’est installée sur le code qui touche aux paiements et aux données clients.

L’écart que révèlent ces données est d’abord un problème de mesure, avant d’être un problème de modèle. Sur l’injection SQL et les algorithmes cryptographiques faibles, les modèles de Veracode ont réussi entre 82 % et 86 % des tâches, parce que ces défauts portent une signature locale qu’un vérificateur peut nommer sans quitter la ligne qu’il lit. La détection est bon marché partout où la faille est visible dans la syntaxe qui la contient. Sur le cross-site scripting et l’injection de logs, les mêmes modèles ont obtenu entre 13 % et 15 %, car ces défauts dépendent de la destination des données une fois qu’elles ont voyagé. Les détecteurs automatisés héritent exactement de cette frontière, ce qui explique pourquoi le marché des scanners a toujours été le plus solide sur les catégories qui ont une forme, et le plus faible sur celles qui dépendent d’un contexte. Un outil peut prouver qu’une requête est paramétrée ; il ne peut pas décider si le service des retours a le droit de lire l’adresse d’un client, parce que cette règle vit dans une politique commerciale et n’a jamais été inscrite dans le dépôt de code.

Personne n’a publié la part du code propre au commerce qu’un agent a écrite, et cette absence fait elle-même partie de l’exposition au risque. La mesure disponible la plus proche est AIDev, un jeu de données assemblé par Hao Li, Haoxiang Zhang et Ahmed E. Hassan et publié en février 2026, qui recense 932 791 pull requests écrites par des agents provenant de cinq agents de codage commerciaux sur GitHub public. Le code commercial ne réside quasiment jamais dans des dépôts publics, si bien qu’un marchand qui cherche à évaluer sa propre exposition extrapole à partir d’un échantillon qui l’exclut. Aucun tableau de bord du commerce ne rapporte la part du parcours de paiement qu’un agent a écrite.

Le chiffre qui compte n’est pas la fréquence à laquelle un agent écrit une faille, mais la fréquence à laquelle cette faille survit à la relecture. Une étude de juillet 2026 menée par A H M Nazmus Sakib, Dipayan Banik et Murtuza Jadliwala a fait passer 16 112 modifications de fichiers écrites par des agents issues de ce corpus au crible d’un juge LLM et d’une analyse manuelle, et a trouvé une odeur de code liée à la sécurité dans 38,9 % des pull requests. Une odeur de code n’est pas une preuve d’exploitation ; c’est le motif qu’un relecteur existe pour repérer. Les problèmes d’intégrité de la chaîne d’approvisionnement logicielle formaient la plus grande catégorie, avec 82,3 % de toutes les odeurs détectées ; les identifiants codés en dur représentaient une part plus étroite, mais concentraient presque tous les cas de gravité critique.

Parmi les véritables fuites de secrets confirmées par les auteurs, 81,1 % avaient franchi à la fois la relecture automatisée et la relecture humaine avant que le changement ne soit intégré. La détection de secrets est le détecteur le plus mature en usage commercial, calibré sur une décennie d’historique de commits humains, et c’est celui qui a échoué ici. Dans un dépôt commercial, le secret en question est une clé de passerelle de paiement, un jeton d’API d’entrepôt, ou un identifiant vers la base de données clients.

La même étude a montré que ce sont des collaborateurs humains, et non des agents, qui ont introduit 67,6 % des fuites confirmées. Cela ressemble à une disculpation ; ce n’en est pas une. La défaillance se situe dans la couche de relecture, pas dans l’écriture, et c’est l’endroit le plus coûteux pour la trouver. L’écriture peut se corriger par une politique ; la capacité de relecture s’achète une personne qualifiée à la fois.

Le commerce est l’un des rares secteurs où cette étape de relecture constitue une obligation contractuelle, et cette obligation désigne une personne. La norme PCI DSS v4.0.1, publiée par le PCI Security Standards Council, exige que les logiciels sur mesure et personnalisés soient relus avant leur mise en production, et lorsque la relecture est manuelle, l’exigence 6.2.3.1 impose qu’elle soit effectuée par une personne autre que l’auteur original du code, compétente en codage sécurisé, avec en plus l’approbation de la direction. Ce contrôle achète de l’indépendance, et il définit cette indépendance par l’auteur. Quand un agent écrit le changement et qu’un second agent de la même famille de modèles le relit, l’artefact traverse le contrôle intact et l’indépendance, elle, n’existe pas. La ressource rare dans l’intégration commerciale était déjà la signature plutôt que le code ; le scanner est censé lire précisément cette signature.

Un marchand peut passer l’évaluation et n’avoir malgré tout personne qui ait lu le diff.

L’objection la plus solide est que la détection elle-même s’automatise sur la même courbe que la génération. Code-Augur, publié en juin 2026 par Zhengxiong Luo, Mehtab Zafar, Dylan Wolff et Abhik Roychoudhury, s’ouvre en qualifiant la détection agentique de vulnérabilités de « moment charnière pour la sécurité logicielle », note que des failles détectées de cette manière étaient « restées masquées pendant des années », et rapporte 22 nouvelles vulnérabilités dans des projets open source majeurs. Si les agents de détection montent en puissance au même rythme que les agents d’écriture, la dette est transitoire et la contrainte déterminante revient au code. Mais pour que cela tienne, le détecteur devrait savoir ce que le code était censé faire. La conception même de Code-Augur concède ce point : l’outil fonctionne en forçant l’agent à consigner ses hypothèses tacites sous forme d’assertions de sécurité inscrites dans le code source, puis en exécutant un fuzzer guidé pour tenter de les invalider. Un fuzzer peut faire échouer une assertion sur les entrées d’un parseur ; il n’a aucun moyen de faire échouer une assertion sur le service habilité à lire l’adresse enregistrée d’un client.

Le commerce dispose aussi d’une démonstration récente de ce qui se passe après le succès de la détection. Le CVE-2025-54236, la faille de prise de contrôle de session d’Adobe Commerce baptisée SessionReaper, a été découverte en août 2025 puis corrigée et publiée en septembre. Sansec a recensé 38 % des boutiques Magento corrigées au 23 octobre, le jour même où l’exploitation de masse a débuté. La détection avait fait son travail dans cette séquence, et la population de marchands n’a pas pu absorber le résultat. Au 26 octobre, la société estimait qu’entre 16 % et 18 % de l’ensemble des boutiques Magento portaient au moins une porte dérobée injectée. Ajouter un rédacteur plus rapide à une population dont le taux d’application des correctifs est aussi bas ne déclenche pas une course entre génération et détection ; cela allonge une file d’attente.

La décision qui se présente à chaque marchand est de savoir quelle moitié du pipeline recevra des effectifs. La capacité de génération s’achète au poste, la capacité de relecture ne s’achète pas de cette manière, ce qui fait paraître la moitié bon marché comme un progrès et la moitié coûteuse comme une friction. Si les intégrations générées continuent d’arriver au rythme actuel pendant que le nombre de personnes qualifiées pour relire du code de paiement reste stable, le manque ne s’annoncera pas sous la forme d’une panne. Il se manifestera sous la forme d’un marchand incapable de dire qui a relu le code qui touche au numéro de carte, et qui apprendra la réponse par le blog de recherche de quelqu’un d’autre. La syntaxe dispose d’un correcteur automatique. La sécurité dépend d’une personne, et le commerce a acheté comme si cette personne venait gratuitement.