Un agent de code IA peut-il trouver des failles de sécurité ?

Oui, surtout les erreurs de logique que les scanners à base de motifs ne voient pas, comme une route d’API qui ne vérifie pas à qui appartient la ressource. Il signale aussi des faux positifs et rate des choses : traitez sa sortie comme des pistes à vérifier, et continuez à lancer des scanners déterministes à côté.

Que fait /security-review dans Claude Code ?

Il analyse les changements de votre branche courante à la recherche de failles de sécurité, en les comparant à la branche par défaut du remote origin, et signale des risques comme les injections, les problèmes d’authentification et l’exposition de données. Il a besoin d’un remote origin. Il relit le diff, pas tout le dépôt.

Dois-je donner mon fichier .env à l’agent pour qu’il vérifie mes secrets ?

Non. Ne collez jamais de vrais secrets dans un prompt. Utilisez un scanner de secrets comme gitleaks pour les trouver, gardez .env hors de ce que l’agent lit, et si une vraie clé a déjà été commitée, révoquez-la d’abord, puis nettoyez l’historique.

Comment gérer les faux positifs d’une revue de sécurité par l’IA ?

Exigez des preuves pour chaque résultat : le fichier et la ligne, l’origine de l’entrée non fiable, le chemin qui mène à l’appel risqué et la raison pour laquelle la validation existante ne couvre pas ce cas. Faites vérifier les résultats graves par une nouvelle session ou un autre modèle avant de toucher au code.

Un audit de sécurité par l’IA remplace-t-il un test d’intrusion ?

Non. Il lit le code source de votre copie locale et repère tôt, à faible coût, les failles probables. Il ne teste pas votre système en fonctionnement, sa configuration ni son infrastructure. Pour tout ce qui touche à l’argent, à la santé ou aux données personnelles, ajoutez une revue professionnelle.

Trouver les failles de sécurité de votre code avec l’IA

Pour trouver les failles de sécurité de votre code avec l’IA, lancez d’abord les scanners déterministes rapides (secrets, dépendances, règles statiques), puis confiez à un agent de code une classe de vulnérabilité à la fois en lui demandant de suivre le parcours des entrées non fiables dans votre code. Traitez chaque résultat comme une affirmation à vérifier, corrigez-le avec un test de régression, et gardez l’agent loin des vrais secrets du début à la fin.

Ce guide porte sur l’audit de votre propre code, dans une démarche défensive. Si vous voulez savoir comment empêcher l’agent lui-même de faire des dégâts (injection de prompt, commandes destructrices, serveurs MCP malveillants), lisez d’abord la sécurité des agents de code IA ; cet article suppose que ces garde-fous sont en place. Les noms d’outils et les commandes ci-dessous suivent la documentation officielle telle qu’elle était en octobre 2026.

Ce qu’un audit par l’IA fait bien, et ce qu’il ne fait pas

Les scanners statiques et les agents de code ne trouvent pas les mêmes bugs, c’est pourquoi il vous faut les deux.

	Scanners déterministes	Agent de code
Point fort	Motifs connus, versions de paquets vulnérables connues, formats de secrets	La logique : qui a le droit d’appeler cette route, d’où vient cette valeur, ce qu’une vérification a oublié
Point faible	Ratent la logique métier ; bruyants sur des motifs sûrs	Faux positifs, problèmes manqués, réponses différentes à chaque exécution
Coût	Quelques secondes, reproductible	Des tokens, plus lent, non reproductible
Meilleur usage	Contrôle de CI sur chaque changement	Audit ciblé des zones à risque et du nouveau code

Un agent excelle sur des cas comme un endpoint qui vérifie que vous êtes connecté mais jamais que la commande que vous consultez est bien la vôtre. Aucune regex ne voit cela. En revanche, un agent ne remarquera pas de façon fiable que le lodash de votre lockfile a trois ans ; npm audit, si.

Ce qu’aucun des deux ne fait : tester votre système en fonctionnement. Un agent lit le code source de votre copie locale. Un stockage cloud mal configuré, une règle de pare-feu ou un token divulgué dans un historique de chat échappent à sa vue.

Avant de commencer : un environnement sûr

Un audit de sécurité consiste surtout à lire du code, alors configurez-le en conséquence.

Travaillez sur une branche ou dans un git worktree. L’audit et les correctifs doivent être faciles à relire et faciles à jeter.
Commencez en lecture seule. Dans Claude Code, utilisez le mode plan (Shift+Tab ou /plan) pour l’audit lui-même ; dans Codex, /permissions → Read Only ou --sandbox read-only. Ne passez aux modifications qu’au moment de corriger.
Gardez les secrets hors de portée. Ne collez jamais de clés, de tokens ou le contenu d’un .env dans un prompt. Si l’agent doit savoir qu’une variable existe, son nom suffit. C’est un .env.example avec de fausses valeurs qu’il doit lire.
Utilisez des identifiants de développement. Si l’agent lance vos tests, ces tests doivent parler à une base locale ou de staging avec des clés jetables, jamais à la production.

Étape 1 : lancer les scanners déterministes

Ils tournent en quelques secondes et donnent à l’agent des pistes concrètes. Tous sont gratuits en local.

# Secrets in git history and in the working tree (gitleaks v8.19+)
gitleaks git -v .
gitleaks dir -v .

# Known-vulnerable dependencies
npm audit --audit-level=high
pip-audit -r requirements.txt

# Static analysis rules for your languages
semgrep scan --config auto

Quelques remarques tirées de la documentation officielle :

gitleaks a scindé son ancienne commande detect en git (analyse des commits) et dir (analyse des fichiers) dans la v8.19.0 ; les anciennes commandes fonctionnent encore mais n’apparaissent plus dans l’aide.
npm audit : --audit-level ne change que le code de sortie, pas le rapport. npm audit fix lance une vraie installation ; npm audit fix --force peut installer des mises à jour SemVer majeures, ne le lancez donc pas à l’aveugle.
pip-audit sans argument audite l’environnement Python courant ; -r audite un fichier de dépendances.
Semgrep : --config auto récupère dans le Semgrep Registry des règles adaptées à votre projet, il a donc besoin d’un accès réseau. Ajoutez --error pour sortir avec le code 1 quand il y a des résultats, ce que vous voulez en CI.

Enregistrez la sortie dans un fichier. À l’étape 3, vous la transmettrez à l’agent au lieu de la recopier.

Étape 2 : auditer une classe de vulnérabilité à la fois

« Trouve les bugs de sécurité de ce dépôt » vous donne une liste superficielle. Un prompt ciblé par classe vous donne une vraie analyse. Le OWASP Top 10:2025 est une bonne carte ; voici les classes à auditer en premier dans une application web classique :

Classe	Ce que l’agent doit suivre	Signe typique
Contrôle d’accès défaillant	Chaque route qui lit ou modifie un enregistrement : vérifie-t-elle que l’enregistrement appartient à l’appelant ?	`findById(req.params.id)` sans filtre sur le propriétaire ou le tenant
Injection (SQL, shell, XSS)	Chaque endroit où une entrée utilisateur atteint une requête, une commande shell ou du HTML	Concaténation de chaînes dans du SQL, `exec` avec une entrée, rendu de HTML brut
Défauts d’authentification	Connexion, session, réinitialisation du mot de passe et gestion des tokens	Tokens de réinitialisation qui n’expirent jamais, pas de limite de débit sur la connexion
SSRF	Chaque requête côté serveur dont l’URL vient de l’utilisateur	`fetch(req.body.url)` sans liste d’autorisation
Secrets dans le dépôt	Clés en dur, tokens dans la config, identifiants dans les tests	Chaînes qui ressemblent à des clés ; gitleaks sera plus fiable
Chaîne d’approvisionnement	Dépendances, scripts d’installation, permissions des workflows de CI	Actions non épinglées, `permissions:` trop larges dans les workflows

Un prompt qui fonctionne, en mode plan :

Audite ce dépôt à la recherche de contrôles d’accès défaillants. Ne modifie aucun fichier.

1. Liste chaque route HTTP qui lit, met à jour ou supprime un enregistrement par ID.
2. Pour chacune, trouve d’où vient l’identité de l’appelant et si la requête
   est limitée aux enregistrements qui lui appartiennent (utilisateur ou tenant).
3. Ne signale que les routes où tu peux montrer la vérification manquante.

Pour chaque résultat, donne : file:line, la route, l’origine de l’ID,
la raison pour laquelle le middleware existant ne la couvre pas, et une gravité
(high/medium/low). Si tu n’es pas sûr, dis-le au lieu de deviner.

Reprenez la même structure pour l’injection, l’authentification et la SSRF. Une classe par conversation garde la fenêtre de contexte concentrée, et vous pouvez les lancer en parallèle dans des sessions séparées.

Pour l’injection, il est utile de dire à l’agent à quoi ressemble du code « sûr » dans votre stack, pour qu’il ne signale pas chaque requête :

Nous utilisons partout des requêtes paramétrées via db.query(sql, params).
Trouve tout endroit qui construit du SQL, des commandes shell ou du HTML à partir
des données de la requête sans passer par les paramètres de db.query, par execFile
avec un tableau d’arguments ou par l’échappement du moteur de templates. Ignore le code sous tests/.

Étape 3 : utiliser les revues de sécurité intégrées

Plusieurs agents proposent désormais une revue de sécurité que vous n’avez pas à écrire vous-même.

Claude Code /security-review. La référence officielle des commandes la décrit comme une analyse des changements de votre branche courante à la recherche de failles de sécurité : elle relit le diff entre votre branche et la branche par défaut d’origin et cherche des risques comme les injections, les problèmes d’authentification et l’exposition de données. Elle a besoin d’un remote origin. Elle ne couvre que les changements de votre branche, lancez-la donc avant d’ouvrir une pull request. Le dépôt claude-code-security-review d’Anthropic explique comment la personnaliser : copiez son security-review.md dans .claude/commands/ et ajoutez vos propres règles, par exemple les motifs considérés comme sûrs dans votre code.

Le plugin security-guidance de Claude Code. Installé avec /plugin install security-guidance@claude-plugins-official, il relit le code pendant que Claude l’écrit : une vérification de motifs à chaque modification (des choses comme eval(, child_process.exec, .innerHTML =), une revue de sécurité en arrière-plan du diff de chaque tour, et une revue plus poussée quand Claude commite. Vous pouvez ajouter des règles propres au projet dans .claude/claude-security-guidance.md. La documentation est claire : il ne bloque pas les écritures et peut rater des problèmes ; c’est une couche parmi d’autres.

Codex /review. La commande de revue de Codex (et codex review --uncommitted ou --base main depuis le shell) est une code review générale. Demandez-lui explicitement de se concentrer sur la sécurité si c’est ce que vous voulez.

L’extension security de Gemini CLI. Installée avec gemini extensions install https://github.com/gemini-cli-extensions/security, elle ajoute /security:analyze pour les changements de votre branche et /security:scan-deps, qui vérifie les dépendances avec OSV-Scanner.

Pour du code déjà en place, plutôt que les changements d’une branche, utilisez les prompts classe par classe de l’étape 2. Vous pouvez aussi transmettre la sortie des scanners :

Voici la sortie de semgrep et de npm audit dans scan-results.txt.
Pour chaque résultat, vérifie s’il est atteignable depuis une entrée utilisateur
dans ce code. Classe chacun comme confirmé, probable faux positif ou
à examiner par un humain, avec une raison en une ligne. Ne modifie aucun fichier.

Étape 4 : séparer les vrais résultats des faux positifs

Les revues de sécurité par l’IA ont le même ton assuré, qu’elles aient raison ou non. Demandez des preuves, pas des verdicts :

Source : par où entre la valeur non fiable ? Le corps d’une requête, une query string, un fichier envoyé, un webhook ?
Chemin : par quelles fonctions passe-t-elle pour atteindre l’appel risqué ? Demandez la chaîne complète avec file:line pour chaque étape.
Garde-fou : quelle validation, quel échappement ou quelle autorisation se trouve sur ce chemin, et pourquoi ne couvre-t-il pas ce cas ?
Atteignabilité : la route est-elle exposée ? Un résultat dans un script d’administration inutilisé n’a pas le même poids qu’un résultat dans une API publique.

Demandez ensuite un second avis. Une nouvelle session, ou mieux un autre modèle, doit vérifier les résultats graves avant que quiconque n’écrive un correctif. Donnez-lui le résultat et le code, pas le raisonnement du premier agent, pour qu’il ne se contente pas d’approuver. La code review par l’IA explique comment évaluer les résultats et garder cette boucle sous contrôle.

Faux positifs courants à prévoir : du SQL construit uniquement à partir de constantes, du HTML qui passe par l’échappement automatique d’un framework, des fixtures de test avec de fausses clés, et des requêtes côté serveur vers une URL interne fixe. Inscrivez les motifs sûrs dans CLAUDE.md ou AGENTS.md pour que les audits suivants cessent de les signaler.

Étape 5 : corriger avec un test de régression

Un correctif de sécurité sans test a tendance à revenir. Demandez le test en premier :

Corrige la vérification de propriétaire manquante dans GET /api/orders/:id (résultat n° 2).

1. Écris d’abord un test où l’utilisateur A demande la commande de l’utilisateur B
   et attends une 404. Lance-le et montre-moi qu’il échoue.
2. Ajoute ensuite la vérification de la façon la plus simple qui s’intègre
   à notre middleware existant. Ne modifie pas de code sans rapport.
3. Lance toute la suite de tests et montre-moi le diff.

Le test qui échoue puis passe prouve que le bug existait et que le correctif le couvre. Gardez chaque correctif dans son propre commit avec un message clair, pour que l’historique explique ce qui n’allait pas. Pour l’habitude générale des correctifs guidés par les tests, voyez déboguer du code avec l’IA.

La même discipline s’applique aux résultats sur les dépendances : mettez à jour un paquet à la fois, lancez les tests, lisez le changelog pour repérer les changements cassants. Un npm audit fix --force en masse, c’est ainsi qu’un audit se transforme en panne.

Si vous trouvez un vrai secret dans le dépôt

C’est le seul cas où l’ordre des étapes compte :

Révoquez d’abord le secret. Désactivez la clé chez le fournisseur et générez-en une nouvelle. Dès qu’un secret a été poussé, considérez-le comme compromis ; supprimer le fichier ne le rend pas secret à nouveau.
Placez le nouveau secret dans votre gestionnaire de secrets ou dans l’environnement, pas de nouveau dans le code.
Ensuite seulement, nettoyez : retirez-le du code et décidez avec votre équipe s’il faut réécrire l’historique. Réécrire l’historique ne sert à rien si la clé n’a pas été révoquée.
Évitez le suivant avec un hook pre-commit. gitleaks documente cette entrée de .pre-commit-config.yaml :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Laissez l’agent vous aider pour les étapes 2 à 4, mais jamais en collant le secret dans la conversation. « La clé Stripe de src/config.ts doit passer dans une variable d’environnement nommée STRIPE_SECRET_KEY » est tout ce dont il a besoin.

En faire un processus continu

Un audit ponctuel perd sa valeur dès que du nouveau code arrive. Mettez les contrôles déterministes en CI et gardez la revue par l’IA pour les pull requests :

# .github/workflows/security.yml (excerpt)
- run: npm audit --audit-level=high
- run: semgrep scan --config auto --error

Pour un passage de l’IA sur chaque pull request, la GitHub Action anthropics/claude-code-security-review d’Anthropic publie ses résultats en commentaires sur la PR. Son entrée obligatoire est claude-api-key ; les entrées facultatives comprennent comment-pr, exclude-directories et false-positive-filtering-instructions. Si vous faites déjà tourner Claude dans GitHub Actions, Claude Code GitHub Actions couvre la configuration et la gestion des secrets.

Le faire avec AgentVera

AgentVera est une application de bureau pour macOS, Windows et Linux qui exécute Claude Code, Codex, Gemini CLI et d’autres agents CLI côte à côte dans de vrais terminaux. Pour les audits de sécurité, elle facilite plusieurs configurations :

Workspace : placez un auditeur en lecture seule (permission réglée sur Ask) à côté d’un agent correcteur qui travaille dans un worktree, et un troisième panneau avec un autre CLI pour le second avis. Chaque agent garde son propre niveau de permission.
Code review : activez la revue en fin de tour dans les réglages du projet, et un modèle Claude de votre choix relit les changements du correcteur ; les résultats arrivent avec une gravité et un lien file:line, et peuvent être renvoyés à l’agent, au plus deux tours d’affilée.
Review inbox : le travail terminé attend sous forme de cartes, et les changements risqués sont signalés : code d’authentification et de sécurité, fichiers de dépendances, fichiers de CI et d’infra, .env et changements sans tests.
Verify (Pro et Team) : un vérificateur distinct, en lecture seule, contrôle le résultat par rapport aux critères de votre demande, comme « un test de régression existe et échoue sans le correctif ».
Agents dans Docker : exécutez Claude Code ou Codex dans un conteneur qui ne voit que le dossier du projet, pour que les fichiers et les clés SSH ailleurs sur votre machine restent hors de portée pendant un audit.
Checkpoints : chaque tour est enregistré, si bien qu’un correctif qui tourne mal s’annule en un clic.

La grille, les worktrees, la code review et les agents Docker sont dans l’offre gratuite. Téléchargez AgentVera et lancez votre premier audit sur une branche.

Erreurs fréquentes

Demander « tous les problèmes de sécurité » d’un coup. Vous obtenez une checklist générique. Auditez une classe à la fois.
Corriger avant de vérifier. Un faux positif « corrigé » ajoute du code que personne ne comprend. Obtenez d’abord des preuves.
Coller des secrets pour « vérifier qu’ils sont valides ». Jamais. Révoquez-les plutôt.
Lancer npm audit fix --force dans une boucle d’agent. Les mises à jour majeures cassent des choses d’une façon qui semble sans rapport.
Prendre une revue par l’IA sans résultat pour une garantie. Cela signifie seulement que l’agent n’a rien trouvé cette fois-ci. Gardez les scanners en CI.
Laisser l’auditeur modifier le code. Gardez l’audit en lecture seule et les correctifs dans une étape séparée et relue.

En résumé

Commencez par gitleaks, votre outil d’audit des dépendances et Semgrep. Auditez ensuite une classe OWASP à la fois avec un agent en lecture seule, en exigeant des preuves file:line et un chemin atteignable. Lancez /security-review (ou l’équivalent de votre agent) avant chaque pull request, faites vérifier les résultats sérieux par une seconde session, et corrigez chacun avec un test de régression qui échoue d’abord. Si un secret fuit, révoquez-le avant toute autre chose. Quand vous êtes prêt à confier les correctifs à des agents, le pair programming avec l’IA montre comment garder la place du navigateur. Si tout cela est nouveau pour vous, apprendre à coder avec l’IA est un point de départ plus doux.