La réponse courte
En juillet 2026, la société de sécurité Theori a lancé sa plateforme de pentest autonome Xint contre 28 applications construites avec des outils de codage IA et confirmé 434 vulnérabilités exploitables — 196 dans des applis neuves et 238 dans un seul système hérité réécrit avec l'aide de l'IA. Le point frappant est la forme des défaillances. Les modèles, répartis sur cinq versions de pointe d'Anthropic et OpenAI, s'étaient nettement améliorés : l'injection SQL classique et le cross-site scripting étaient rares parce que les requêtes préparées et l'assainissement des entrées venaient par défaut. Ce qui manquait, c'est tout ce qui exige une vue de l'ensemble du système — limites de débit absentes et requêtes non bornées (déni de service), références d'objets non vérifiées (IDOR) et secrets par défaut collés tout droit depuis des modèles de démarrage.
Pour les équipes qui ont intégré les assistants IA au quotidien du développement, la leçon n'est pas « arrêtez de les utiliser ». C'est que l'IA produit du code qui a l'air correct et qui compile, tout en omettant les propriétés de sécurité qu'un architecte humain impose sans y penser. Cette lacune est peu coûteuse à combler par la revue et coûteuse à ignorer — c'est pourquoi le code écrit par IA a sa place dans un processus de développement logiciel sécurisé, et non livré directement du prompt à la production.
Ce que Theori a testé
Theori a bâti l'étude autour de sa plateforme Xint, qui mène des tests d'intrusion autonomes pilotés par IA en combinant le sondage à l'exécution avec l'analyse de code source. L'équipe l'a pointée vers 28 applications produites par différents workflows de codage IA — d'un prompt d'une ligne « construis-moi une appli » à une génération plus structurée, guidée par spécification — avec cinq modèles de pointe d'Anthropic et OpenAI. Chaque appli a reçu un scan d'environ 30 minutes. La sortie brute était bruyante : 8 827 détections potentielles. Après déduplication et tri d'exploitabilité, 434 problèmes ont survécu comme réellement exploitables, et ce sont les chiffres qui comptent.
La répartition est instructive. Deux applis greenfield, générées de zéro, totalisaient 196 failles confirmées. Mais un seul cas brownfield — le forum PHP hérité Gnuboard7, migré avec l'aide de l'IA vers une pile Laravel et React — en portait 238 à lui seul, plus que les deux applis greenfield réunies. C'est le signal le plus clair du rapport : les réécritures assistées par IA de systèmes existants n'héritent pas seulement de l'ancien risque, elles le multiplient à mesure que les mêmes vérifications manquantes se répètent sur une surface plus large. Pour quiconque pèse une modernisation d'un système hérité accélérée par IA, c'est la ligne à souligner avant de commencer.
Quels bugs l'IA a laissés
Le mélange de vulnérabilités est la vraie histoire, car il vous dit où chercher dans votre propre code généré par IA. L'épuisement de ressources et le déni de service dominaient la liste avec environ 21 % des constats — pagination non bornée qui renvoie une table entière, endpoints sans limite de débit, et opérations synchrones bloquantes qui laissent une requête monopoliser un worker. L'impact, tel que Theori l'a cadré, n'est pas le vol de données mais « un coût serveur qui s'emballe ou un serveur qu'un attaquant peut faire tomber ». Pour un SaaS sur cloud facturé à l'usage, c'est un incident de facturation et un incident de disponibilité à la fois.
L'autorisation défaillante, surtout les références directes non sécurisées à des objets (IDOR), venait ensuite. Ici l'effet de taille est net : environ 11 % des constats dans les petites applis greenfield, montant à environ 28 % dans le CMS réécrit, parce que l'IA appliquait — ou oubliait — les vérifications de propriété de façon incohérente sur des centaines d'endpoints. Les problèmes de frontière de confiance comme le path traversal et le server-side request forgery ajoutaient une autre tranche. Et parmi les 23 failles de sévérité critique, le motif qui devrait inquiéter chaque équipe est le plus simple : 11 étaient des secrets en dur ou par défaut — valeurs SECRET_KEY par défaut, clés de signature JWT et identifiants intégrés repris de modèles de démarrage — plus 6 cas de mode debug laissé actif, qui transforme une trace de pile en exécution de code à distance.
Les constats en un coup d'œil
Les classes phares, tirées de l'ensemble confirmé de 434 problèmes exploitables de Theori :
| Constat | Ce que Theori a rapporté |
|---|---|
| Applis analysées | 28 applis générées par IA, 5 modèles de pointe (Anthropic & OpenAI) |
| Brut → confirmé | 8 827 détections triées à 434 exploitables |
| Greenfield vs brownfield | 196 dans deux applis neuves ; 238 dans une appli héritée réécrite par IA |
| Classe la plus fréquente | Épuisement de ressources / DoS (≈21 %) |
| Deuxième classe | Autorisation défaillante / IDOR (11 % petit → 28 % grand) |
| Failles critiques | 23 au total — 11 secrets en dur/par défaut, 6 RCE en mode debug |
| Bien gérés | Injection SQL et XSS — rares, grâce aux requêtes préparées & à l'assainissement par défaut |
Pourquoi le code IA échoue ainsi
Le motif n'est pas aléatoire, et le comprendre vous dit quelle revue prioriser. Un modèle de langage génère du code token par token à partir du contexte local. Il est très bon sur la forme d'une requête de base de données sûre ou d'un template échappé, car ce sont des motifs locaux et répétés qu'il a vus des millions de fois. Il est mauvais sur les propriétés qui n'existent qu'au niveau de l'ensemble du système : quel utilisateur possède cet enregistrement, combien de lignes cet endpoint devrait jamais renvoyer, quelle route ne doit jamais tourner avec le debug activé, où se situe réellement la frontière de confiance entre les données de locataires. Ce sont des faits d'architecture, pas des idiomes ligne à ligne.
Le CTO de Theori, Andrew Wesie, l'a dit sans détour : les « classes de vulnérabilités qui posent encore problème aux modèles sont celles qui exigent une compréhension au niveau système ». Cette seule phrase devrait remodeler la façon dont les équipes se répartissent le travail avec l'IA. Les modèles ont gagné la confiance sur les bugs mécaniques de type injection ; ils ne l'ont pas gagnée sur l'autorisation, la gouvernance des ressources ou l'hygiène des secrets. La recommandation même de Theori en découle directement — s'appuyer sur des outils automatisés pour cribler de grands volumes de code généré par IA à la recherche des classes récurrentes, et garder les experts humains concentrés sur la modélisation des menaces et l'architecture plutôt que sur la revue ligne à ligne. C'est la même répartition du travail que nous intégrons à la façon dont nous livrons des agents et assistants IA pour nos clients : laisser le modèle rédiger, mais jamais être le dernier regard sur une frontière de confiance.
Ce que cela implique pour les équipes en France & dans l'UE
Vue de haut, l'étude est un avertissement sur la vitesse sans filet de sécurité. Les assistants IA permettent à une petite équipe de livrer une application fonctionnelle en quelques jours, et chacune des 28 applis fonctionnait — les failles étaient invisibles jusqu'à ce qu'un pentester autonome aille chercher. Les équipes qui ne mesurent que « est-ce que ça tourne » accumulent une dette de sécurité qu'elles ne voient pas, et le résultat brownfield montre que cette dette s'aggrave à mesure que le code grandit. La réponse n'est pas un développement plus lent ; c'est faire de la revue de sécurité automatisée une étape non négociable du pipeline, pour que les classes DoS, IDOR et secrets soient attrapées par les machines à la vitesse où le code est écrit.
Pour les produits réglementés, l'enjeu dépasse le ticket de bug. En FinTech et HealthTech, un IDOR qui expose l'enregistrement d'un autre client est un événement de violation de données avec les délais évoqués. Une clé de signature en dur dans un dépôt public est une divulgation qui n'attend que son heure. L'AI Act européen et des cadres comme l'ISO 27001 et SOC 2 attendent déjà un cycle de développement documenté et contrôlé. Les équipes qui avanceront vite et resteront conformes sont celles qui traitent la sortie de l'IA comme une entrée non fiable d'un vrai secure-SDLC, pas comme un travail fini.
Que faire cette semaine
Une séquence courte et pratique qui transforme l'étude en action plutôt qu'en anxiété :
- Scanner les secrets dans la CI. Ajoutez la détection de secrets à votre pipeline et bloquez les commits ; faites tourner toute clé ayant figuré dans le code source ou un modèle. Cela neutralise la plus grande classe critique unique trouvée par l'étude.
- Désactiver les réglages de développement. Auditez chaque environnement pour le mode debug, les erreurs verbeuses et les réglages de framework laissés par défaut — la source des RCE en mode debug.
- Tester la charge et limiter le débit. Ajoutez limites de débit, plafonds de pagination et timeouts aux endpoints générés par IA ; sondez les requêtes non bornées avant qu'un attaquant ou une facture cloud ne le fasse.
- Revoir l'autorisation à la main. L'IDOR est précisément ce que l'automatisation manque et ce qui croît avec l'échelle — faites vérifier par un humain les contrôles de propriété sur chaque endpoint qui renvoie des données utilisateur.
- Faire de l'AppSec une étape du pipeline. Placez la revue de sécurité automatisée avant le merge du code écrit par IA, et acheminez tout ce qui touche une frontière de confiance vers un responsable humain.
Rien de tout cela ne plaide contre les outils de codage IA — l'argument de productivité est réel, et les modèles ont réellement fermé la porte aux bugs d'injection qui ont miné une génération d'applis. Mais l'étude est un signal clair : l'IA écrit du code qui passe une démo, pas du code qui survit à un attaquant. Les équipes qui ajoutent la couche de revue manquante obtiennent les deux — vitesse et sécurité ; celles qui la sautent livrent des applis à 434 failles sans le savoir.
Questions fréquentes
Qu'a révélé l'étude Theori sur le code généré par IA ?
Theori a lancé sa plateforme de pentest autonome Xint contre 28 applis construites avec des outils IA sur cinq modèles de pointe d'Anthropic et OpenAI, a trié 8 827 détections brutes et confirmé 434 vulnérabilités exploitables — 196 dans des applis greenfield et 238 dans une appli héritée réécrite par IA. Le DoS par épuisement de ressources dominait, suivi de l'autorisation défaillante ; sur 23 failles critiques, 11 étaient des secrets en dur ou par défaut et 6 des RCE en mode debug.
Pourquoi le code généré par IA contient-il des failles de sécurité ?
Les modèles géraient bien l'injection SQL et le XSS grâce aux requêtes préparées et à l'assainissement, mais peinent sur le raisonnement au niveau système — frontières de confiance, limites de ressources et propriété des données. C'est pourquoi ils omettent les limites de débit, laissent les références d'objets non vérifiées (IDOR) et collent des secrets par défaut issus de modèles. Comme l'a noté le CTO de Theori Andrew Wesie, les classes difficiles sont celles qui exigent une compréhension au niveau système.
Les vulnérabilités s'aggravent-elles dans les bases de code IA plus grandes ?
Oui. L'IDOR apparaissait dans environ 11 % des constats des petites applis greenfield mais montait à environ 28 % dans le CMS réécrit, où la même faille se répétait sur des centaines d'endpoints. L'unique appli brownfield portait 238 failles confirmées — plus que les deux applis greenfield réunies (196) — montrant que les réécritures assistées par IA concentrent le risque à mesure que la portée grandit.
Est-il sûr d'utiliser des outils de codage IA en production ?
Oui, avec revue. Le gain de productivité est réel et les modèles gèrent les bugs d'injection courants, mais leur sortie ne devrait pas être livrée sans revue. Gardez le code écrit par IA dans un SDLC sécurisé : revue de sécurité automatisée à grand volume pour les problèmes récurrents de DoS, d'autorisation et de secrets, plus des ingénieurs humains responsables de la modélisation des menaces et de l'architecture, là où les modèles échouent.
Que doivent faire les équipes contre les secrets en dur dans les applis générées par IA ?
Les secrets en dur et par défaut représentaient près de la moitié des failles critiques. Ajoutez le scan de secrets à la CI pour bloquer les commits, déplacez les clés vers un coffre de secrets géré ou une injection d'environnement, faites tourner tout identifiant ayant figuré dans le code source ou un modèle, et ne laissez jamais un réglage de développement d'un framework atteindre la production. Ce sont des contrôles peu coûteux et automatisables qui retirent la classe la plus grave trouvée par l'étude.
Sources
SecurityWeek — Vibe-Coded Apps Riddled With Exploitable Security Flaws, 22 juillet 2026
Help Net Security — The AI code vulnerabilities that grow with your app, 23 juillet 2026
Cybersecurity News — What 434 AI-Generated Vulnerabilities Reveal About Secure Software Development, juillet 2026