Sécurité du code généré par IA : ce que disent les études et la liste de contrôle

Le code généré par IA fonctionne en général, mais il est souvent vulnérable. Dans les tests 2026 de Veracode, les modèles produisaient du code qui compilait presque à 100 %, tout en échouant aux contrôles de sécurité sur près de 44 % des tâches, un taux qui ne s'est pas amélioré depuis 2025. La solution n'est pas d'interdire les outils d'IA, mais de traiter leur production comme celle d'un prestataire inconnu : relecture, analyse et tests avant toute mise en production.

Voici ce que disent les études, les failles qui reviennent le plus souvent, et une liste de contrôle à transmettre à votre développeur ou à votre agence.

Ce que montrent les études

Veracode : environ une tâche sur deux échoue, sans amélioration

Pour son rapport 2025 sur la sécurité du code généré, Veracode a soumis 80 tâches de programmation à plus de 100 grands modèles de langage. Quand une solution sûre et une solution vulnérable étaient possibles, les modèles ont choisi la mauvaise dans 45 % des cas. Java était le langage le plus risqué, avec plus de 70 % d'échecs de sécurité ; Python, C# et JavaScript échouaient entre 38 et 45 % du temps. Les modèles ne se protégeaient pas contre le cross-site scripting (XSS) dans 86 % des cas, ni contre l'injection dans les journaux dans 88 %. Les grands modèles ne faisaient pas significativement mieux que les petits.

L'édition 2026 constate que le taux moyen de réussite en sécurité « se situe à 56 %, quasiment inchangé depuis le rapport de l'an dernier ». Le meilleur modèle du classement de l'été 2026 atteint 68 %, ce qui revient encore à échouer sur près d'une tâche de sécurité sur trois. Le code Python réussit dans 63 % des cas, le code Java dans 30 % seulement. Les modèles spécialisés dans le code (51 %) ne font pas mieux que les modèles généralistes (52 %), la taille du modèle ne change rien de net, mais les modèles de raisonnement gardent un avantage (56 % contre 51 %).

Les travaux universitaires : suggestions vulnérables et excès de confiance

• Une des premières études sur GitHub Copilot, « Asleep at the Keyboard? » (IEEE Symposium on Security and Privacy 2022), a généré 1 689 programmes dans 89 scénarios sensibles et en a jugé environ 40 % vulnérables.
• Une étude publiée à la conférence ACM CCS 2023 montre que les participants aidés d'un assistant IA écrivaient un code nettement moins sûr que les autres, tout en étant plus nombreux à le croire sûr.
• Un article présenté à USENIX Security 2025 a analysé 576 000 extraits de code issus de 16 modèles : au moins 5,2 % des paquets suggérés par les modèles commerciaux et 21,7 % de ceux des modèles open source n'existaient pas, soit 205 474 noms de paquets inventés différents. Un attaquant peut publier un paquet malveillant sous un nom que les modèles ont tendance à inventer ; quiconque l'installe sans vérifier est compromis.

À l'échelle des équipes : plus de changements, moins de stabilité

Le rapport DORA 2025 de Google associe l'adoption de l'IA à un débit de livraison plus élevé, mais aussi à une stabilité moindre. Son explication vaut directement pour la sécurité : sans tests automatisés solides ni boucles de retour rapides, davantage de changements signifie davantage d'incidents.

Pourquoi le code généré échoue aux contrôles de sécurité

La sécurité dépend presque toujours d'un contexte que le modèle ignore : quelle donnée vient d'un utilisateur non fiable, qui a le droit de voir quel enregistrement, quels secrets existent dans votre environnement. Le XSS, qui suppose de savoir où une donnée sera affichée, fait partie des pires résultats des tests Veracode 2025 (86 % d'échecs). Le modèle écrit un code qui fait ce que vous avez demandé ; sa sûreté dépend de ce que vous n'avez pas précisé.

Les failles à surveiller

• Des données non fiables qui atteignent l'affichage ou les requêtes : XSS, injection SQL, injection dans les journaux.
• Des contrôles d'autorisation absents : une route qui vérifie que l'utilisateur est connecté, mais pas que l'enregistrement lui appartient.
• Des secrets dans le code : clés d'API collées dans les sources ou dans le code envoyé au navigateur.
• Des dépendances inventées ou obsolètes : paquets inexistants, ou anciennes versions aux failles connues.
• Des réglages par défaut dangereux : CORS trop permissif, mode debug actif, messages d'erreur détaillés en production.
• Une cryptographie fragile ou une authentification « maison » au lieu des outils intégrés au framework.

Liste de contrôle pour relire du code généré par IA

Pas besoin de savoir lire du code pour l'utiliser. Demandez à votre développeur de confirmer chaque point pour toute fonctionnalité qui touche aux utilisateurs, aux paiements ou aux données. Les points 1 à 4 s'appliquent avant toute fusion, les points 5 à 7 concernent les dépendances et les secrets, les points 8 à 12 les tests et l'organisation.

1. Une personne qui comprend le code a relu chaque modification générée par IA, ligne par ligne.
2. Chaque route vérifie l'autorisation (qui peut accéder à cet enregistrement), pas seulement l'authentification.
3. Toutes les saisies sont validées côté serveur, et l'affichage est échappé par le framework (pas de rendu HTML brut de contenu utilisateur).
4. L'accès à la base passe par le query builder du framework ou des requêtes paramétrées, jamais par du SQL concaténé.
5. Chaque nouveau paquet a été vérifié : il existe, il est maintenu, et c'est bien celui que le développeur voulait installer.
6. Un audit des dépendances tourne automatiquement (par exemple npm audit, composer audit ou GitHub Dependabot).
7. Aucun secret n'est commité dans le dépôt ni envoyé au navigateur ; la détection de secrets est activée.
8. Des tests automatisés couvrent la connexion, les droits d'accès et les paiements, et tournent à chaque modification. Des tests de bout en bout comme la configuration Playwright que nous utilisons repèrent tôt les règles d'accès cassées.
9. Un outil d'analyse statique (SAST) tourne dans l'intégration continue à chaque pull request.
10. La production tourne sans mode debug, avec un CORS restrictif et des pages d'erreur génériques.
11. Les agents IA n'ont aucun accès direct aux données ni aux identifiants de production.
12. Quelqu'un est responsable des décisions de sécurité, et vous savez qui.

Les questions à poser à votre développeur ou à votre agence

• Quels outils d'IA utilisez-vous, et quelle est votre règle de relecture pour ce qu'ils produisent ?
• Qu'est-ce qui tourne automatiquement à chaque pull request : tests, audit des dépendances, analyse statique, détection de secrets ?
• Comment les règles d'autorisation sont-elles testées ?
• Qui remarquerait qu'un nouveau paquet n'existait pas la veille ?

Ces questions ont leur place dans toute sélection d'un partenaire de développement. Si votre application a surtout été construite avec un générateur d'applications par IA, lisez aussi où les MVP en vibe coding cassent : l'absence de règles d'accès aux données y est le problème le plus courant.

Questions fréquentes

Le code généré par IA est-il sûr ?

Pas par défaut. Les tests 2026 de Veracode donnent un taux moyen de réussite en sécurité de 56 %, inchangé depuis 2025, alors que presque tout le code généré compilait. Il demande autant de relecture et de tests que n'importe quel code, sinon davantage.

Quel langage est le plus risqué avec l'IA ?

Dans les tests de Veracode, Java : 30 % de réussite en sécurité en 2026, contre 63 % pour Python. Mais le langage compte moins que la relecture : tous les langages échouent sur une part importante des tâches.

Une IA peut-elle vérifier la sécurité de son propre code ?

Elle peut aider à repérer des problèmes, mais ces mêmes modèles choisissent souvent l'option vulnérable dans les tests de Veracode. Utilisez la relecture par IA comme une couche parmi d'autres, avec l'analyse statique, l'audit des dépendances, les tests et une relecture humaine.

Faut-il un audit de sécurité pour un MVP ?

S'il gère des données personnelles, des paiements ou des comptes utilisateurs, passez au minimum la liste ci-dessus avant le lancement. Un audit externe complet se justifie dès que vous avez de vrais utilisateurs ou des données sensibles en volume.

Sources

1. LLMs Are Getting Smarter but Not Safer: Veracode 2026 GenAI Code Security Report, Veracode, 2026-07
2. AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks, Veracode Research Reveals, Veracode, 2025-07
3. Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (IEEE S&P 2022), Pearce, Ahmad, Tan, Dolan-Gavitt, Karri (arXiv), 2021-12
4. Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023), Perry, Srivastava, Kumar, Boneh (arXiv), 2023-12
5. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025), Spracklen et al. (arXiv), 2025-03
6. Announcing the 2025 DORA Report, Google Cloud, 2025-09