Accueil › Glossaire › Red Team Testing

Red Team Testing (LLM)

Le red team testing (test par équipe rouge) pour les LLM est un processus structuré de tests adversariaux où des testeurs humains ou automatisés simulent des attaques pour découvrir les vulnérabilités d’un modèle d’IA, notamment ses faiblesses face aux jailbreaks, aux injections de prompts, à la génération de contenus nuisibles, et à la fuite de données sensibles.

Qu’est-ce que le red teaming pour les LLM

Le red teaming adapte un concept de la sécurité militaire et informatique au monde de l’IA. L’idée : une « équipe rouge » (attaquante) tente de compromettre le système, tandis que l' »équipe bleue » (défensive) travaille à le protéger. Pour les LLM, l’équipe rouge conçoit des prompts adversariaux, des jailbreaks, et des scénarios de manipulation conçus pour pousser le modèle à violer ses propres garde-fous de sécurité.

Le red teaming diffère fondamentalement de l’évaluation standard. L’évaluation classique valide que le modèle fonctionne correctement dans les cas prévus. Le red teaming tente délibérément de le faire échouer dans des cas imprévus. C’est la différence entre vérifier qu’une serrure fonctionne et essayer de la crocheter.

La pratique est devenue un pilier de la sécurité IA. Anthropic a été l’un des premiers à formaliser le red teaming à grande échelle pour la collecte de données d’alignement, en demandant à des annotateurs de tenter de provoquer des réponses nuisibles de Claude. OpenAI, Google DeepMind, Meta et Mistral ont tous intégré des programmes de red teaming dans leurs pipelines de développement. L’EU AI Act impose désormais un red teaming documenté pour les systèmes IA à haut risque.

Les catégories de vulnérabilités testées

Jailbreaks

Les attaques de jailbreak contournent les garde-fous de sécurité pour faire produire au modèle des contenus interdits. Les principales techniques incluent le roleplay (faire « jouer un rôle » au modèle qui le libère de ses contraintes), les pièges logiques (dilemmes moraux ou conditionnels), le codage (base64, caractères invisibles), et les attaques multi-tours (escalade progressive au fil de la conversation). Les taux de réussite varient : les attaques par roleplay atteignent environ 89 % de succès, les pièges logiques environ 81 %, et le codage environ 76 % sur les modèles testés.

Injection de prompts

L’injection de prompts manipule les instructions du modèle pour lui faire exécuter des actions non autorisées. L’injection directe modifie le comportement via le prompt utilisateur. L’injection indirecte passe par du contenu externe (pages web, documents) que le modèle traite et qui contient des instructions malveillantes cachées. OWASP classe l’injection de prompts en première position de son Top 10 des vulnérabilités LLM pour la deuxième année consécutive.

Fuite de données sensibles

Le modèle peut divulguer des informations confidentielles provenant de ses données d’entraînement (PII, données propriétaires), de son system prompt (révélation des instructions cachées), ou de ses intégrations (accès non autorisé à des bases de données ou API). La fuite d’informations sensibles est passée de la 6e à la 2e place du classement OWASP en 2025.

Génération de contenu nuisible

Même avec un safety tuning, les modèles peuvent produire du contenu toxique, discriminatoire, ou dangereux. Le red teaming évalue la robustesse des refus du modèle face à des requêtes de plus en plus sophistiquées. Cela inclut les hallucinations factuelles présentées avec assurance, la désinformation, et les biais amplifiés.

Abus d’agentique

Les LLM connectés à des outils (function calling, agents IA) présentent une surface d’attaque élargie. Le red teaming teste l’escalade de privilèges (le modèle exécute des actions non autorisées via ses outils), l’exfiltration de données via les intégrations, et les échecs de validation des entrées/sorties. L’OWASP a ajouté « excessive agency » comme nouvelle catégorie de vulnérabilité en 2025.

Les deux approches du red teaming

Red teaming humain

Des testeurs humains (chercheurs en sécurité, experts métier, annotateurs entraînés) conçoivent manuellement des prompts adversariaux. C’est l’approche utilisée par Anthropic pour collecter les données de harmlessness du dataset HH-RLHF : les annotateurs « red teament » le modèle en essayant de provoquer des réponses nuisibles, puis les paires de réponses sont utilisées pour le preference tuning.

L’avantage du red teaming humain est la créativité et l’intuition. Les humains identifient des angles d’attaque subtils, des contextes culturels spécifiques, et des scénarios que les systèmes automatisés ne couvrent pas. L’inconvénient est le coût et la scalabilité : Anthropic a collecté plus de 42 000 prompts écrits par des humains, complétés par 140 000 prompts générés par un LLM, pour un total de 182 000 prompts de red teaming.

Red teaming automatisé

Un LLM « attaquant » génère automatiquement des prompts adversariaux pour tester un LLM « cible ». Cette approche permet de couvrir un espace d’attaques bien plus large et de découvrir des vulnérabilités que les humains n’auraient pas imaginées. Les systèmes modernes comme GOAT (Generative Offensive Agent Tester) enchaînent des techniques d’attaque sur plusieurs tours de conversation, s’adaptant dynamiquement à chaque réponse du modèle cible.

Anthropic utilise cette approche en boucle : un modèle génère des attaques, un autre est affiné pour y résister, et le processus est itéré. MTSA (ACL 2025) formalise ce pipeline avec un modèle red-team qui apprend des stratégies de jailbreak guidées par la réflexion (« think before attack »).

La meilleure pratique combine les deux approches : les tests automatisés pour la couverture large, et les tests humains pour la profondeur et la créativité sur les cas limites.

Les outils de red teaming

Les frameworks de référence

OWASP Top 10 for LLM Applications (2025). Le classement de référence des vulnérabilités LLM. L’injection de prompts reste en première position. Cinq nouvelles catégories ont été ajoutées en 2025 : excessive agency, fuite du system prompt, faiblesses des embeddings vectoriels, désinformation, et consommation non bornée.

NIST AI Risk Management Framework (AI RMF). Le NIST recommande le red teaming comme approche de test adversarial des systèmes IA sous conditions de stress. Le framework fournit un cadre structuré pour identifier, évaluer et atténuer les risques IA.

MITRE ATLAS. Équivalent du MITRE ATT&CK pour la cybersécurité mais appliqué à l’IA. ATLAS fournit une base de connaissances des tactiques et techniques adversariales spécifiques aux systèmes IA.

EU AI Act. La réglementation européenne exige un red teaming documenté pour les systèmes IA à haut risque. Les organisations déployant des LLM dans l’UE doivent démontrer des processus de test adversarial proactifs.

Le processus de red teaming en pratique

Un engagement de red teaming structuré suit typiquement cinq phases :

Phase 1 : Cadrage (scoping). Définir la portée du test. Quels sont les cas d’usage du modèle ? Quels types de vulnérabilités sont prioritaires ? Quelles sont les contraintes réglementaires ? Le cadrage inclut la modélisation des menaces (threat modeling) : qui pourrait attaquer le modèle, avec quelles motivations, et quels moyens ?

Phase 2 : Génération d’attaques. Concevoir les prompts adversariaux. En mode automatisé, cela implique le déploiement d’outils comme DeepTeam ou Garak avec des configurations adaptées. En mode manuel, les red teamers conçoivent des scénarios ciblés. La combinaison des deux est recommandée : tests automatisés pour la couverture, tests manuels pour la profondeur.

Phase 3 : Exécution. Soumettre les attaques au modèle et collecter les réponses. Les outils automatisés peuvent lancer des milliers d’attaques en quelques minutes. La métrique principale est l’ASR (Attack Success Rate) : le pourcentage d’attaques qui contournent les garde-fous.

Phase 4 : Analyse et scoring. Évaluer les résultats. Chaque vulnérabilité est classée par sévérité (critique, haute, moyenne, basse), catégorisée (jailbreak, injection, fuite, contenu nuisible), et documentée avec le prompt d’attaque et la réponse problématique.

Phase 5 : Remédiation et rétest. Les vulnérabilités découvertes alimentent le safety tuning (ajout de données de sécurité, adversarial training), le renforcement des filtres d’entrée/sortie, ou la modification des system prompts. Les correctifs sont ensuite retestés pour vérifier leur efficacité.

Limites et réalité du terrain

Un constat sévère émerge de la recherche récente. Un article d’octobre 2025, co-signé par des chercheurs d’OpenAI, Anthropic et Google DeepMind, a examiné 12 défenses publiées contre l’injection de prompts et le jailbreaking. Résultat : en utilisant des attaques adaptatives (qui affinent itérativement leur approche), les taux de réussite d’attaque dépassent 90 % pour la plupart des défenses, alors que ces mêmes défenses avaient été initialement rapportées comme ayant des taux de réussite quasi nuls.

Un autre défi : le temps moyen pour générer un jailbreak réussi est d’environ 17 minutes pour GPT-4 et 22 minutes pour Mistral. Cela signifie qu’un attaquant motivé trouvera probablement une faille en moins d’une heure. La défense parfaite n’existe pas ; l’objectif est de rendre l’exploitation suffisamment difficile et coûteuse pour dissuader la majorité des attaquants.

Le red teaming comme source de données d’entraînement

Au-delà de l’évaluation, le red teaming est une source de données précieuse pour l’entraînement. Chaque jailbreak réussi produit une paire (prompt adversarial, réponse nuisible) qui peut être utilisée pour le safety tuning. Le modèle est ensuite réentraîné pour refuser ce type de requête, créant un cycle vertueux de découverte-correction.

Anthropic utilise cette approche systématiquement : les données de red teaming alimentent le RLHF de harmlessness et la Constitutional AI. Meta intègre les résultats du red teaming dans les rounds successifs d’alignement de Llama. C’est le pipeline « break-fix » décrit par Microsoft pour Phi-3 : tester, casser, corriger, retester.

Quand et à quelle fréquence

La meilleure pratique est un red teaming à plusieurs niveaux :

Avant le déploiement. Un engagement complet (humain + automatisé) fait partie intégrante de la validation pré-lancement. C’est l’équivalent d’un audit de sécurité avant la mise en production.

Périodique. Tous les 3 à 6 mois, ou à chaque mise à jour significative du modèle, des données d’entraînement, ou des intégrations (nouveaux outils, API, plugins).

Réactif. Quand une nouvelle technique d’attaque est publiée (un nouveau jailbreak « universel », par exemple), un sprint de red teaming ciblé est nécessaire pour vérifier la vulnérabilité du modèle.

Continu. En 2025, certaines organisations déploient un red teaming continu où des tests automatisés tournent en permanence en staging ou en monitoring de production. C’est la direction vers laquelle converge l’industrie.

Verdict

Le red teaming est le contrôle qualité adversarial indispensable pour tout LLM déployé en production. Sans red teaming, vous déployez un modèle dont vous ne connaissez pas les failles. C’est un pari risqué : les coûts de remédiation post-incident (fuites de données, contenu nuisible, atteinte à la réputation) sont de plusieurs ordres de grandeur supérieurs au coût d’un programme de red teaming proactif.

Pour les praticiens : commencez par les outils automatisés open-source (Garak, DeepTeam) pour une couverture large et rapide. Complétez par du red teaming humain pour les cas limites et les scénarios spécifiques à votre domaine. Documentez chaque vulnérabilité découverte et son correctif pour la conformité réglementaire (EU AI Act, NIST). Et surtout, ne considérez jamais le red teaming comme terminé : la sécurité des LLM est une course entre attaquants et défenseurs, et les attaquants ont structurellement l’avantage de l’initiative.