Ce que le red teaming IA cherche à obtenir
Le terme vient du domaine militaire : une « équipe rouge » incarne l'ennemi pour éprouver les défenses d'une « équipe bleue ». Transposé à l'intelligence artificielle, le red teaming consiste à confronter un modèle ou une application à des sollicitations hostiles, imprévues ou détournées, pour observer jusqu'où il tient — et où il cède.
L'objectif n'est pas de produire un score. Il est de répondre à une question précise : que peut faire faire à ce système une personne qui veut lui nuire, le détourner, ou en extraire ce qu'il devrait protéger ? Un modèle peut afficher 95 % d'exactitude sur un banc de test et, dans le même temps, révéler son prompt système, générer des instructions dangereuses sous un déguisement de jeu de rôle, ou exécuter une action non autorisée parce qu'une instruction était cachée dans un document.
Un système d'IA n'est pas déterministe. On ne prouve pas son innocuité en énumérant ce qu'il fait correctement : on cherche activement les entrées qui le font échouer. Le red teaming est cette recherche méthodique de l'échec provoqué.
Ce qu'il teste, ce qu'il ne teste pas
Le red teaming IA porte sur la couche de raisonnement et de comportement du système, pas seulement sur son infrastructure. C'est ce qui le distingue d'un test d'intrusion applicatif classique.
| Dans le périmètre | Hors périmètre (autres audits) |
|---|---|
| Contournement des garde-fous du modèle (jailbreak) | Failles réseau et pare-feu |
| Injection directe et indirecte de prompt | Gestion des correctifs système |
| Fuite du prompt système ou de données de contexte | Configuration des serveurs |
| Actions non autorisées d'un agent outillé | Authentification et gestion des accès applicatifs |
| Génération de contenu dangereux ou interdit | Chiffrement des données au repos |
| Hallucinations exploitables et biais systématiques | Sauvegardes et continuité d'activité |
La confusion fréquente entre red teaming et test d'intrusion mérite une clarification à part entière : elle fait l'objet de la page pentest ou red teaming. Le catalogue précis des attaques employées est détaillé dans attaques LLM & GenAI.
Comment se déroule une campagne
Une campagne de red teaming IA suit une trajectoire en cinq temps. Contrairement à un test scripté, chaque phase nourrit la suivante : ce qu'on apprend d'une faille oriente la recherche de la faille d'après.
Cadrage & menace
Définir ce qu'on protège, contre qui, et ce qui constituerait un échec inacceptable. On modélise l'attaquant plausible.
Reconnaissance
Comprendre l'architecture : quel modèle, quelle base documentaire, quels outils l'agent peut-il appeler, quels garde-fous sont en place.
Attaque itérative
Sollicitations hostiles, jailbreaks, injections, escalade. On affine à chaque tentative selon les réactions observées.
Exploitation
Une fois une faille trouvée, mesurer jusqu'où elle mène : simple écart de ton, ou fuite de données, ou action réelle non autorisée.
Restitution
Rapport factuel : chaque faille reproduite, son impact, sa criticité, et les pistes de remédiation testables.
La phase 3 peut être conduite à la main, mais elle est de plus en plus assistée par un modèle attaquant qui génère et fait muter des milliers de sollicitations. Ce basculement vers l'automatisation est traité dans une IA qui en attaque une autre.
Qui compose une équipe rouge
Un red teaming IA sérieux mobilise des compétences que rarement une seule personne réunit. La qualité de la campagne dépend de cette diversité de regards.
- Le spécialiste en sécurité offensiveIl connaît les techniques d'intrusion et la logique adversariale : penser comme celui qui veut casser le système.
- L'expert du domaine métierIl sait ce qu'une réponse fausse coûte réellement dans le contexte d'emploi — santé, finance, droit — et repère les erreurs qu'un généraliste laisserait passer.
- Le praticien du modèleIl comprend comment un LLM raisonne, où ses garde-fous sont fragiles, et comment formuler une attaque qui exploite sa mécanique interne.
- Le référent conformitéIl relie les failles trouvées aux exigences réglementaires, notamment l'article 15 de l'EU AI Act sur la robustesse.
Ce que produit le red teaming
Le livrable n'est pas une note globale mais un dossier de preuves. Chaque vulnérabilité y est reproductible : sans reproductibilité, un signalement n'a aucune valeur de preuve.
- Le journal des attaquesChaque sollicitation testée, la réponse obtenue, et si elle a produit un écart. La traçabilité complète de la campagne.
- La matrice de criticitéChaque faille classée par impact et par probabilité d'exploitation, pour prioriser les corrections.
- Les scénarios reproductiblesLa séquence exacte qui déclenche chaque faille, pour que l'équipe de développement la rejoue et vérifie sa correction.
- Les pistes de remédiationPour chaque faille, une direction concrète : durcissement du prompt, filtrage, restriction des outils de l'agent, garde-fou supplémentaire.
Ce dossier s'inscrit ensuite dans une démarche plus large d'audit, qui distingue l'analyse des besoins de l'organisation et l'évaluation de sa sécurité — objet de la page audit IA : besoins & sécurité. Pour les systèmes fondés sur une base documentaire, la mesure du taux d'hallucination complète le red teaming : voir auditer un RAG & les hallucinations.