Tu fais confiance à ton assistant IA. Il écrit des fonctions propres, gère les cas limites, laisse des commentaires utiles. Le code compile, les tests passent, la pull request — une proposition de fusionner du nouveau code dans le projet principal — reçoit un pouce levé. Trois mois plus tard, un pentester trouve une faille dans une fonction que ton agent a pondue à 2h du mat'. Personne n'a rien dit parce que ça "avait l'air bien."

Ce n'est pas une expérience de pensée. C'est un mardi ordinaire.

L'écart entre confiance et compétence

Le code généré par l'IA représente désormais environ 46 % du nouveau code dans beaucoup d'entreprises. Tu ne peux pas y échapper. Mais quelque part entre "c'est l'IA qui l'a écrit" et "on l'a mis en prod", une hypothèse dangereuse s'est glissée : que la machine sait ce qu'elle fait. Ce n'est pas le cas. C'est une dactylo ultra-rapide qui n'a aucune notion d'attaquant.

Tu as besoin d'un guide de survie. Le voici.

Un snippet sur quatre a une faille

En février 2026, le groupe de recherche en sécurité AppSecSanta a testé six LLMs majeurs — les grands modèles de langage, les cerveaux derrière ChatGPT, Claude, Gemini et compagnie — sur 89 prompts orientés sécurité. Python et JavaScript. Des tâches réelles mappées sur le OWASP Top 10 — la liste de référence des risques de sécurité les plus critiques pour les applications web.

Le résultat : 25,1 % du code généré contenait des vulnérabilités confirmées. Un snippet sur quatre. Ton IA produit des failles à l'échelle industrielle, et elle le fait avec le calme d'un type qui n'a jamais été piraté.

Taux de vulnérabilité par modèle :

Modèle Taux de vuln
GPT-5.2 19,1 % (meilleur)
Gemini 2.5 Pro 22,4 %
Grok 4 23,7 %
Claude Opus 4.6 29,2 %
DeepSeek V3 29,2 %
Llama 4 Maverick 29,2 %

Cet écart de 10 points signifie que ton choix de modèle compte. Mais même le meilleur balance une faille dans presque une sortie sur cinq. Choisir GPT-5.2 plutôt que Llama 4 aide. Ça ne te sauve pas.

Là où les modèles échouent le plus :

  • SSRF (Server-Side Request Forgery — quand ton serveur se fait piéger pour appeler des URLs internes au nom d'un attaquant) : 32 découvertes. La catégorie numéro un.
  • Injection (injection SQL, injection de commandes — quand l'input utilisateur se faufile dans les requêtes de base de données ou les commandes système) : 30 découvertes, 33,1 % de tous les problèmes.
  • Mauvaise configuration de sécurité : 25 découvertes — secrets codés en dur, mode debug laissé activé en production.
  • Contrôle d'accès cassé (laisser les utilisateurs faire des choses qu'ils ne devraient pas pouvoir faire) : présent dans chaque modèle testé.

Une étude séparée de Help Net Security de mars 2026 a testé Claude Code, OpenAI Codex et Google Gemini en mode agent — pas juste de l'autocomplétion, mais du codage entièrement autonome. Les agents ont produit 143 problèmes de sécurité sur 38 scans couvrant 30 pull requests. 87 % de ces PRs contenaient au moins une vulnérabilité. Le contrôle d'accès cassé apparaissait dans la sortie de chaque agent. Chaque. Agent. Sans exception.

Pourquoi la machine écrit du code non sécurisé

Les modèles ne sont pas malveillants. Ce sont des machines à probabilités entraînées sur GitHub, et GitHub regorge de code non sécurisé. Des réponses Stack Overflow de 2015 qui codent les secrets JWT en dur (JWT — JSON Web Token, un badge numérique qui prouve que tu es connecté). Du code de tutoriel qui zappe la validation des entrées parce que "c'est juste une démo". Du code de production d'entreprises qui n'ont jamais lancé d'audit de sécurité.

Trois patterns reviennent sans cesse :

1. Validation côté serveur absente. Les agents IA acceptent des valeurs côté client — scores, soldes, rôles utilisateur — sans les vérifier côté serveur. Le modèle a appris de milliers de tutoriels qui "laissent la validation comme exercice au lecteur". Le lecteur n'a jamais fait l'exercice. L'IA non plus.

2. Paramètres par défaut non sécurisés. Tokens JWT sans date d'expiration. Implémentations OAuth (OAuth — un protocole qui te permet de "Te connecter avec Google" au lieu de créer encore un mot de passe) sans le paramètre state qui empêche le détournement. Refresh tokens qui ne peuvent pas être révoqués. Les modèles génèrent du code qui marche mais choisissent le réglage fainéant, pas le sécurisé.

3. SSRF partout. Quand un modèle écrit du code qui récupère une URL, il ne vérifie presque jamais où pointe cette URL. Pas de liste blanche, pas de blocage des adresses IP internes, pas de restrictions sur le protocole. Il fait juste requests.get(user_input) et c'est parti. Un attaquant lui passe http://169.254.169.254/ et soudain il a tes identifiants cloud.

Ton arsenal de défense en cinq couches

Arrête d'attendre que les modèles deviennent plus malins en sécurité. Construis un pipeline — une séquence automatisée de vérifications — qui attrape les problèmes peu importe qui ou quoi a écrit le code.

Couche 1 : Prompting orienté sécurité

Le correctif le plus simple ne coûte rien. Une étude Veracode a montré qu'ajouter un simple rappel de sécurité au prompt améliorait le taux de code sécurisé de 56 % à 66 % pour Claude Opus 4.6. Dix pour cent d'amélioration avec une phrase. Pas de la magie. Mais gratuit.

Ajoute ceci à ton system prompt, tes règles Cursor, ou ton CLAUDE.md :

When writing code: validate all inputs server-side. Never trust
client data. Use parameterized queries. Set secure defaults for
auth tokens (expiration, rotation). Block SSRF by validating URLs
against allowlists. Never hardcode secrets.

Pour les agents de codage IA comme Claude Code, Codex ou Copilot en mode agent, glisse ces instructions dans les fichiers de configuration de ton projet. L'agent les lit à chaque tâche.

Couche 2 : SAST dans ton éditeur

SAST — Static Application Security Testing — scanne ton code à la recherche de vulnérabilités sans l'exécuter, comme un correcteur orthographique mais pour les failles de sécurité. La découverte clé d'AppSecSanta : un seul outil SAST a détecté 78 % des vulnérabilités générées par l'IA. Utiliser plusieurs scanners améliore considérablement la couverture.

Configuration recommandée :

  • Semgrep — gratuit, rapide, plus de 3 000 règles. Tourne dans VS Code, JetBrains et la CI. Détecte injection, SSRF, secrets codés en dur.
  • Bandit (Python) — attrape les problèmes de sécurité Python courants. Zéro configuration nécessaire.
  • Plugins de sécurité ESLint (JavaScript) — eslint-plugin-security et eslint-plugin-no-unsanitized.

Installe Semgrep en pre-commit hook — un script qui s'exécute automatiquement avant chaque commit, bloquant le mauvais code avant qu'il n'entre dans le dépôt :

pip install semgrep
semgrep --config auto --error .

Maintenant chaque commit est scanné. L'IA écrit le code, Semgrep lui met une claque avant que tu push.

Couche 3 : Scanning dans le pipeline CI

Ton pre-commit hook attrape les trucs évidents. Ton pipeline CI — le système automatisé de build et de tests qui tourne quand tu push du code — devrait lancer une analyse plus profonde :

# Exemple GitHub Actions
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Concentre tes règles sur les catégories où l'IA échoue le plus : SSRF (CWE-918), injection (CWE-89, CWE-78), désérialisation non sécurisée (CWE-502 — quand des données malveillantes sont transformées en objets exécutables) et path traversal (CWE-22 — quand un attaquant utilise ../../ pour s'échapper d'un répertoire et lire des fichiers qu'il ne devrait pas voir).

Couche 4 : Review humaine avec un œil sécurité

La code review pour du code généré par l'IA est différente d'une review classique. Tu ne cherches pas des erreurs de logique — l'IA gère ça raisonnablement bien. Tu cherches :

  • Des endpoints sans vérification d'authentification. L'IA écrit le route handler mais oublie le middleware — le code gardien qui vérifie "est-ce que tu as le droit d'être là ?"
  • De l'input utilisateur qui arrive dans des endroits dangereux. Requêtes de base de données, opérations fichiers, requêtes HTTP, commandes shell. Si l'input utilisateur touche l'un de ces éléments sans assainissement, tu as un problème.
  • Du rate limiting absent. L'IA n'ajoute jamais de rate limiting sauf si tu le demandes explicitement. Chaque endpoint public en a besoin, sinon quelqu'un va le marteler avec 10 000 requêtes par seconde.
  • Des secrets dans le code. Le modèle génère parfois des clés API placeholder qui ont l'air assez vraies pour être livrées. Ensuite elles atterrissent sur GitHub. Ensuite elles atterrissent dans les mains de quelqu'un d'autre.

Entraîne ton équipe à poser une question pour chaque fonction générée par l'IA : "Que se passe-t-il si l'input est hostile ?"

Couche 5 : Le fichier de règles OpenSSF

L'OpenSSF — Open Source Security Foundation — a publié un guide standardisé d'instructions de sécurité pour les assistants de codage IA. C'est un fichier de règles que tu déposes à la racine de ton projet. Chaque outil de codage IA qui supporte les instructions au niveau projet le lit automatiquement.

Le fichier couvre la validation des entrées, l'encodage des sorties, l'authentification, la gestion des sessions, la cryptographie, la gestion des erreurs et la journalisation. Au lieu d'écrire tes propres règles de sécurité en partant de zéro, utilise les leurs — maintenues par des professionnels de la sécurité, mises à jour régulièrement, et gratuites.

Ce que ça te coûte

Du temps. Chaque couche ajoute de la friction. Les pre-commit hooks ajoutent 5 à 15 secondes par commit. Les scans CI ajoutent des minutes à ton pipeline. La review humaine nécessite des humains qui savent à quoi ressemble une SSRF. Le fichier OpenSSF nécessite de le lire une fois et de comprendre ce qu'il fait.

Les faux positifs vont t'agacer. Semgrep va flagger du code qui est en fait correct. Tu vas passer du temps à enquêter sur des non-problèmes. C'est l'impôt que tu paies pour attraper les vrais.

Et rien de tout ça n'est infaillible. L'étude AppSecSanta a découvert que 22 % des vulnérabilités passaient à travers tous les outils SAST testés. Certaines failles nécessitent des tests dynamiques — exécuter le code et l'attaquer concrètement — pour être trouvées. L'analyse statique est nécessaire mais pas suffisante.

Ce que tu fais lundi matin

Tu n'as pas besoin d'implémenter les cinq couches d'ici la semaine prochaine. Commence par deux :

  1. Ajoute des instructions de sécurité à ta config IA. Copie le bloc de prompt de la Couche 1. Colle-le dans ton projet. Cinq minutes.
  2. Installe Semgrep en pre-commit hook. Deux commandes. Fait avant que ton café refroidisse.

Ça seul te met devant la majorité des équipes qui livrent du code généré par l'IA aujourd'hui. Ajoute le scan CI quand tu as un sprint avec un peu de marge. Ajoute le fichier OpenSSF quand quelqu'un dans ton équipe l'a lu et compris. Forme les reviewers au fil du temps.

La nouvelle normalité

Le taux de vulnérabilité dans le code généré par l'IA est passé d'environ 40 % en 2024 à 25 % en 2026. Du progrès, certes. À ce rythme, on atteint "acceptable" quelque part vers 2030. Tu ne peux pas attendre quatre ans.

Traite le code généré par l'IA comme la sortie d'un développeur junior qui tape à 500 mots par minute, dégage une confiance absolue et n'a jamais entendu parler d'OWASP. Relis-le. Scanne-le. Teste-le. Ensuite livre-le.

L'IA écrit du code à une vitesse 10x. Ton outillage de sécurité doit suivre. Les outils existent. La seule pièce manquante, c'est l'habitude de les utiliser.