---
title: "Red teaming des agents IA : détecter les vulnérabilités de façon systématique"
description: "Le red teaming des agents IA consiste à attaquer des agents IA de manière systématique et simulée afin de mettre au jour des vulnérabilités comme l'injection de prompt, les jailbreaks, l'utilisatio…"
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/red-teaming-des-agents-ia-detecter-les-vulnerabilites-de-facon-systematique"
category: "Agents IA"
topic: "Sécurité des agents IA & OWASP"
updated: "2026-10-28T13:26:42.151Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Red teaming des agents IA : détecter les vulnérabilités de façon systématique

Le red teaming des agents IA consiste à attaquer des agents IA de manière systématique et simulée afin de mettre au jour des vulnérabilités comme l'injection de prompt, les jailbreaks, l'utilisation abusive des outils et la fuite de données, avant que de vrais attaquants ne les exploitent. Il combine des outils d'attaque automatisés avec la créativité manuelle d'attaques en plusieurs étapes et fournit des résultats mesurables, comme des taux de réussite des attaques, plutôt que des listes binaires de vulnérabilités.

## L’essentiel

- Le red teaming IA n'est pas la même chose qu'un test d'intrusion classique : il demande d'autres compétences (culture ML, prompt engineering, aisance dans les attaques en plusieurs étapes), d'autres outils (Garak, PyRIT, DeepTeam au lieu de Burp/Metasploit) et produit d'autres formats de résultats (taux de réussite des attaques probabilistes au lieu de constats CVE binaires).
- Le scan automatisé (Garak, PyRIT, DeepTeam, Promptfoo) couvre à moindre coût des classes d'attaques larges et connues ; le red teaming manuel trouve les attaques en plusieurs étapes et propres au contexte (dérive boiling frog, A2A Session Smuggling, delayed tool invocation) que les scanners ne voient pas.
- Règle empirique pour la fréquence : un test de référence trimestriel complété par des tests déclenchés par des événements, avant chaque nouvelle intégration d'outil disposant de droits destructifs, après chaque modification substantielle du prompt ou du message système, après chaque mise à niveau du modèle et ponctuellement en cas de CVE ou de PoC touchant ta propre stack.
- Le reporting doit être mesurable et rattaché à des frameworks : taux de réussite des attaques, taux de détection, délai de détection et rayon d'impact, mis en correspondance avec l'OWASP Agentic Top 10 (ASI01–ASI10), MITRE ATLAS et, comme approches émergentes (en 2026), AIVSS et des enregistrements compatibles AVID.
- Des chercheurs compétents ont contourné chaque garde-fou publié en quelques mois (EchoLeak contre le classificateur XPIA de Microsoft, CamoLeak contre les filtres côté GitHub) ; le red teaming est donc une preuve obligatoire, pas un argument marketing. « OWASP-compliant » n'est pas une affirmation solide, car l'OWASP ne certifie pas.
- Pour les entités financières de l'UE, les tests offensifs sont réglementés : DORA exige des tests de résilience (art. 24–25) et, de la part des entités financières désignées par l'autorité de surveillance, des tests de pénétration fondés sur la menace, dits TLPT (art. 26–27). En Allemagne, le guide d'orientation non contraignant de la BaFin (18.12.2025) cite les tests d'intrusion adversariaux comme mesure appropriée.

Le red teaming des agents [IA](https://blckalpaca.at/fr/glossaire/ia) consiste à attaquer des agents IA de manière systématique et simulée afin de mettre au jour des vulnérabilités comme [l'injection de prompt, les jailbreaks, l'utilisation abusive des outils et la fuite de données](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/injection-de-prompt-directe-vs-indirecte-la-difference-et-pourquoi-avec-les-agen), avant que de vrais attaquants ne les exploitent. Il combine des outils d'attaque automatisés avec la créativité manuelle d'attaques en plusieurs étapes et fournit des résultats mesurables, comme des taux de réussite des attaques, plutôt que des listes binaires de vulnérabilités. Contrairement à un test fonctionnel, il ne demande pas « l'[agent](https://blckalpaca.at/fr/glossaire/agent) fonctionne-t-il ? », mais « comment peut-on le détourner de sa véritable finalité ? ».

Cet article fait partie du hub « Sécurité des agents IA selon l'OWASP » et précise comment tu peux tester de manière offensive les risques répertoriés dans l'[OWASP Agentic Top 10 (ASI01–ASI10)](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/owasp-agentic-security-asi-top-10-2026-les-risques-des-systemes-dia-agentique).

## Trois réponses rapides

- **Qu'attaque-t-on ?** La surface d'attaque propre aux agents : pas seulement le modèle, mais aussi les appels d'outils, la mémoire persistante, la communication entre agents et le human-in-the-loop. L'objectif est de mettre au jour le détournement d'objectif, l'utilisation abusive des outils, l'empoisonnement de la mémoire et la fuite de données.
- **Avec quoi ?** Des scanners open source (Garak, PyRIT, DeepTeam, Promptfoo) pour la couverture large, du red teaming manuel pour les attaques en plusieurs étapes et du bug bounty pour la couverture sur le long terme.
- **À quelle fréquence ?** Un test de référence trimestriel, plus des tests déclenchés par des événements (nouveaux outils, modifications du [prompt](https://blckalpaca.at/fr/glossaire/prompt), mises à niveau du modèle, CVE critiques).

## Pourquoi le red teaming IA n'est pas un pentest classique

La distinction la plus importante d'abord : le red teaming IA n'est pas synonyme de test d'intrusion traditionnel. Les équipes achats confondent régulièrement les deux, avec des conséquences coûteuses lorsqu'un pentest réalisé avec Burp Suite est accepté comme « preuve de sécurité de l'IA ».

Les différences sont fondamentales :

| Dimension | Pentest classique | Red teaming IA |
| --- | --- | --- |
| Compétences requises | Connaissances réseau / AppSec | Culture ML, créativité en prompt engineering, aisance adversariale dans les attaques en plusieurs étapes |
| Outils typiques | Burp, Metasploit, Cobalt Strike | Garak, PyRIT, DeepTeam, Promptfoo |
| Format des résultats | constats binaires de type CVE | taux de réussite des attaques probabilistes |
| Modèle d'attaque | le plus souvent, un exploit en une seule tentative | campagnes multi-tours en plusieurs étapes |
| Cible | erreurs de code ou de configuration | manipulation du comportement et du contexte |

Souvent, un [agent IA](https://blckalpaca.at/fr/glossaire/agent-ia-ai-agent) ne « casse » même pas au sens classique : il suit des instructions qu'on lui a fait passer pour légitimes. Comme les agents et le modèle sous-jacent ne savent pas distinguer de manière fiable les instructions des données, [chaque texte que lit l'agent fait partie de la surface d'attaque](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/tool-misuse-et-excessive-agency-quand-les-agents-ia-ont-trop-de-droits). Cela exige une autre discipline de test.

## Les vulnérabilités qu'une red team recherche de façon ciblée

Le red teaming passe en revue les classes de menaces propres aux agents de l'OWASP Agentic Top 10. Concrètement, il s'agit de construire de manière ciblée les attaques suivantes :

- **Injection de prompt / détournement d'objectif (ASI01).** Injection directe et indirecte, instructions cachées dans des documents, le corpus [RAG](https://blckalpaca.at/fr/glossaire/rag), des e-mails, des invitations d'agenda, des descriptions de PR ou des sorties d'outils. Particulièrement perfide : la dérive multi-tours « boiling frog », où chaque étape prise isolément paraît plausible alors que la trajectoire cumulée est malveillante.
- **Jailbreaks.** Contournement des garde-fous de sécurité pour déclencher des actions ou des contenus interdits.
- **Utilisation abusive des outils (ASI02).** Une fonction légitime (par ex. `send_email`) est détournée de son usage ; les modes d'approbation automatique ou « YOLO », qui désactivent les demandes de confirmation, sont exploités.
- **Empoisonnement de la mémoire et du contexte (ASI06).** Un contenu injecté une seule fois empoisonne durablement la mémoire persistante ; la « delayed tool invocation » ne se déclenche que des semaines plus tard, sur un mot déclencheur.
- **Fuite de données.** Exfiltration via des images Markdown manipulées, des chaînes de redirection ou des proxys détournés.
- **Attaques entre agents (ASI07) et exploitation de la confiance humain-agent (ASI09).** Messages falsifiés entre agents et neutralisation délibérée de la couche de validation humaine par des recommandations formulées avec assurance, mais manipulées.

Des incidents documentés prouvent que ces attaques sont réelles : [EchoLeak (CVE-2025-32711, CVSS 9.3 selon Microsoft)](https://nvd.nist.gov/vuln/detail/CVE-2025-32711) a été la première injection de prompt zero-click réelle dans un système [LLM](https://blckalpaca.at/fr/glossaire/llm) en production et a contourné le classificateur XPIA (Cross-Prompt Injection Attempt) de Microsoft. CamoLeak (CVSS 9.6) a exfiltré caractère par caractère des secrets de dépôts privés et du code source via le propre proxy d'images Camo de GitHub. Les deux cas le montrent : des chercheurs compétents ont contourné chaque garde-fou publié en quelques mois.

## Démarche : automatisée ou manuelle

Un red teaming mature combine deux modes complémentaires.

**Automatisé** signifie passage à l'échelle et reproductibilité. Les scanners déroulent de larges bibliothèques de sondes contre l'agent et mesurent la part qui passe. Ils se prêtent à l'intégration continue dans la CI/CD et aux tests de régression après chaque modification. Point faible : ils trouvent surtout des schémas d'attaque connus.

**Manuel** signifie créativité et contexte. Des analystes expérimentés construisent des campagnes en plusieurs étapes taillées pour l'agent concerné, précisément les attaques que les scanners ne voient pas. Exemples issus de la recherche : l'« Agent Session Smuggling » contre le protocole A2A ([Palo Alto Unit 42, 31 octobre 2025](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/)) n'est pas une injection en un seul coup, mais une campagne d'ingénierie sociale soutenue, d'agent à agent. A2A a été développé par Google ; depuis juin 2025, le protocole est confié à la [Linux Foundation](https://linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents). L'attaque contre la mémoire de Google Gemini (Johann Rehberger, février 2025) a utilisé la « delayed tool invocation » pour empoisonner la mémoire en différé.

## Outils et frameworks en 2026

Les outils suivants sont les briques établies dans la pratique. Les données de version et de marché datent de 2026.

| Outil | Origine | Positionnement |
| --- | --- | --- |
| Garak | NVIDIA (à l'origine Leon Derczynski) | Scanner de vulnérabilités LLM doté d'une large bibliothèque de sondes |
| PyRIT | Microsoft AI Red Team | Python Risk Identification Tool, extensible |
| DeepEval / DeepTeam | Confident AI | prend en charge le framework OWASP\_ASI\_2026 sous forme de plug-in |
| Promptfoo Red Team | Promptfoo ([rachat par OpenAI annoncé en mars 2026](https://www.promptfoo.dev/blog/promptfoo-joining-openai/)) | référencé par l'OWASP comme solution de sécurité GenAI |
| Spikee | [Reversec Labs](https://github.com/ReversecLabs/spikee) | Kit de test d'injection de prompt pour applications LLM (Simple Prompt Injection Kit for Evaluation and Exploitation) |
| MAESTRO Threat Analyzer | Cloud Security Alliance | Modélisation des menaces assistée par IA (pas un outil de red teaming à proprement parler) |

**Commerciaux :** Lakera Red (Lakera, basée à Zurich, [intégrée à Check Point depuis octobre 2025](https://www.checkpoint.com/press-releases/check-point-software-reports-2025-third-quarter-financial-results/)), HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise et Cranium.

**Bug bounty couvrant l'IA :** HackerOne (GitHub est passé par HackerOne pour la divulgation de CamoLeak), Bugcrowd et Intigriti, basée dans l'UE et bien implantée dans la zone DACH (Allemagne, Autriche, Suisse).

## Reporting : mesurable et rattaché aux frameworks

La valeur d'un red teaming dépend entièrement du rapport. Les résultats étant probabilistes, il faut les quantifier. Indicateurs utiles :

- **Taux de réussite des attaques :** part des attaques réussies par classe.
- **Taux de détection :** nombre d'attaques repérées par la supervision.
- **Délai de détection :** temps écoulé jusqu'à la détection.
- **Rayon d'impact :** nombre d'agents ou de systèmes en aval qui seraient touchés.

Chaque constat devrait être rattaché à des frameworks établis : [l'OWASP Agentic Top 10 (ASI01–ASI10) comme registre des risques](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), MITRE ATLAS comme playbook de l'adversaire (avec une réserve honnête : ATLAS a 6 à 12 mois de retard sur la frontière agentique, en particulier pour ASI07, ASI08 et ASI10) et, comme approche émergente (en 2026), AIVSS (version 0.8) pour le scoring quantitatif. Les constats peuvent aussi être structurés de façon compatible AVID, ce qui en fait des preuves d'audit reproductibles pour l'ISO 42001 A.5 et l'art. 9 du règlement européen sur l'IA. Point important pour les achats : « OWASP-compliant » n'est pas une affirmation solide. L'OWASP ne certifie pas.

## À quelle fréquence et par qui

**Fréquence (règle empirique) :** un test de référence trimestriel complété par des tests déclenchés par des événements, avant chaque nouvelle intégration d'outil disposant de droits destructifs, après chaque modification substantielle du prompt ou du message système, après chaque mise à niveau de version du modèle et ponctuellement dès qu'une CVE ou un PoC touche ta propre stack.

**Qui :** les grands groupes disposant de leur propre stack d'agents sur des données sensibles entretiennent une red team IA dédiée (en interne ou externe sous contrat permanent), qui travaille avec Garak, PyRIT et DeepTeam selon le framework OWASP\_ASI\_2026, ainsi qu'un programme de bug bounty. Les PME qui déploient des agents via des [API](https://blckalpaca.at/fr/glossaire/api) managées confient le red teaming à des prestataires spécialisés, faute de compétences spécifiques en ML en interne.

Pour les entités financières de l'UE, les tests offensifs sont réglementés. [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) est un règlement européen, s'applique directement [depuis le 17 janvier 2025](https://www.bafin.de/DE/Aufsicht/DORA/DORA_node.html) et exige des tests de résilience réguliers (art. 24–25). Seules les entités financières désignées par l'autorité de surveillance compétente doivent réaliser des [tests de pénétration fondés sur la menace (TLPT)](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/reglement-dora-et-ia-dans-le-secteur-financier/tests-de-resilience-dora-tlpt-threat-led-penetration-testing-pour-les-systemes-d) (art. 26–27). En Allemagne, le [guide d'orientation de la BaFin sur les risques TIC liés à l'utilisation de l'IA](https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2025/meldung_2025_12_18_orientierungshilfe_ikt_risiken.html) du 18.12.2025 cite les tests d'intrusion adversariaux et la simulation d'attaques (empoisonnement de données, évasion) comme mesures appropriées. Ce guide est expressément non contraignant. Quiconque exploite des systèmes d'IA critiques sans de tels tests devrait malgré tout pouvoir le justifier lors d'un contrôle.

## Exemple pratique chiffré

Un assureur exploite un workflow multi-agents pour la gestion des sinistres. Une red team interne construit une injection indirecte : dans la copie scannée d'un courrier médical, l'instruction de valider automatiquement les dossiers de certaines catégories est dissimulée sous forme de texte reconstituable par OCR. L'agent « Risk Scoring » reprend l'évaluation manipulée et la transmet aux agents « Pricing » et « Compliance ».

Les indicateurs mesurés : taux de réussite de l'injection 1 sur 1 (réussie), délai de détection > 4 heures, rayon d'impact 3 agents en aval. À titre de comparaison, des travaux de Galileo AI (décembre 2025) ont montré, dans des [systèmes multi-agents](https://blckalpaca.at/fr/glossaire/systemes-multi-agents) simulés, qu'un seul agent compromis empoisonnait **87 % de la prise de décision en aval en 4 heures**. Un incident documenté dans les achats d'un industriel (2025) : en trois semaines, un agent a été progressivement convaincu que sa limite de validation était de 500 000 USD ; l'attaquant a ensuite passé pour 5 millions USD de fausses commandes en 10 transactions. Ce type de résultats traduit des risques abstraits en chiffres présentables à un comité de direction.

## Check-list pratique

- Définir le périmètre : quels outils, mémoires, chemins inter-agents et points de contrôle HITL sont inclus ?
- Dériver des scénarios fondés sur le modèle de menaces à partir d'OWASP ASI01–ASI10.
- Ancrer un scan de référence automatisé (Garak/PyRIT/DeepTeam) dans la CI/CD.
- Compléter par des campagnes manuelles en plusieurs étapes (boiling frog, A2A, delayed invocation).
- Collecter les indicateurs : taux de réussite des attaques, taux de détection, délai de détection, rayon d'impact.
- Rattacher les constats à OWASP/MITRE ATLAS/AIVSS et les documenter de façon compatible AVID.
- Des « injections de test » pour vérifier que le human-in-the-loop fonctionne réellement.
- Fixer la cadence : trimestrielle, plus des tests déclenchés par des événements.

## Pour les agences et les décideurs B2B

Quiconque construit des agents pour des clients ou les utilise dans sa propre stack marketing et commerciale devrait considérer le red teaming comme une composante fixe du processus de livraison et d'exploitation, et non comme un test de recette ponctuel. Pour les agences, c'est aussi un facteur de différenciation : des taux de réussite des attaques démontrables et un reporting rattaché à l'OWASP créent chez les clients une confiance que la formule « nous utilisons des garde-fous » n'obtient pas. Blck Alpaca t'aide à [mettre en place un dispositif de red teaming adapté à la maturité et au cadre réglementaire de ton entreprise](https://blckalpaca.at/fr/services/agent-ia-entreprise) : du choix des outils jusqu'au rapport exploitable en audit, en passant par le développement des scénarios. Contacte-nous avant que ton agent passe en production.

## Questions fréquentes

### Quelle est la différence entre le red teaming IA et un test d'intrusion classique ?

Un pentest classique cherche des vulnérabilités binaires (port ouvert, injection SQL) avec des outils comme Burp, Metasploit ou Cobalt Strike. Le red teaming IA demande une culture ML, de la créativité en prompt engineering et une aisance adversariale dans les attaques en plusieurs étapes, utilise des outils comme Garak, PyRIT et DeepTeam et fournit des résultats probabilistes (taux de réussite des attaques) au lieu de constats CVE binaires. Les équipes achats confondent régulièrement les deux. Ils se complètent, mais ne se remplacent pas.
### À quelle fréquence faut-il soumettre un agent IA à un red teaming ?

En règle générale : un test de référence trimestriel, plus des campagnes déclenchées par des événements. Les déclencheurs sont une nouvelle intégration d'outil disposant de droits destructifs, une modification substantielle du prompt ou du message système, une mise à niveau de version du modèle et, ponctuellement, toute CVE ou preuve de concept qui touche ta propre stack. Les entités financières que l'autorité de surveillance a obligées, en vertu de DORA, à réaliser des tests de pénétration fondés sur la menace (TLPT) y ajoutent des cycles TLPT formels.
### Quels outils conviennent au red teaming des agents IA ?

Open source : Garak (NVIDIA, large bibliothèque de sondes), PyRIT (Microsoft AI Red Team), DeepEval/DeepTeam (Confident AI, prend en charge le framework OWASP_ASI_2026 sous forme de plug-in), Promptfoo Red Team et Spikee. Commerciaux : Lakera Red, HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise et Cranium. Les plateformes de bug bounty couvrant l'IA sont HackerOne, Bugcrowd et Intigriti, basée dans l'UE. Toutes les données de version et de marché datent de 2026.
### Le red teaming automatisé suffit-il ?

Non. Les scanners automatisés couvrent rapidement et à moindre coût des classes d'attaques larges et connues, et se prêtent à une intégration continue dans la CI/CD. Les attaques les plus graves contre les agents sont toutefois en plusieurs étapes et propres au contexte, par exemple la dérive d'objectif de type boiling frog, l'A2A Session Smuggling ou l'invocation différée d'outils qui ne se déclenche que des semaines plus tard. Seul un red teaming manuel mené par des analystes expérimentés les détecte. La bonne pratique consiste à combiner les deux approches.
### Qui doit mener le red teaming : une équipe interne ou un prestataire externe ?

Les deux options sont légitimes et dépendent de la maturité et du budget. Les grands groupes qui disposent de leur propre stack d'agents sur des données sensibles entretiennent généralement une red team IA dédiée (en interne ou externe sous contrat permanent), avec des tests trimestriels et à chaque changement, complétée par un programme de bug bounty au périmètre IA explicite. Les PME qui déploient des agents via des API managées externalisent le plus souvent le red teaming auprès de prestataires spécialisés, faute de compétences spécifiques en ML en interne.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/red-teaming-des-agents-ia-detecter-les-vulnerabilites-de-facon-systematique). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.