Tester un système LLM comme un attaquant le ferait.
Le red teaming IA emprunte la posture du red teaming cyber classique — simuler un adversaire réel plutôt que suivre une checklist — mais avec des cibles, des techniques et des critères de succès propres aux systèmes IA. Voici la méthodologie, de la planification à la divulgation.
Red teaming IA vs red teaming cyber vs autres méthodologies
Le red teaming cyber traditionnel teste des réseaux, des applications et des humains (ingénierie sociale) contre des objectifs d'intrusion classiques. Le red teaming IA ajoute une dimension propre au modèle : contourner un système d'alignement, extraire des données d'entraînement, manipuler la logique de décision d'un agent — des objectifs qui n'ont pas d'équivalent direct en cybersécurité classique.
Il se distingue aussi d'autres méthodologies de test complémentaires plutôt que concurrentes : l'audit de biais (évalue l'équité des sorties du modèle, pas sa résistance à un attaquant), les benchmarks de sécurité automatisés (évaluation statique à grande échelle, sans adaptation stratégique face aux défenses), et le bug bounty IA (ouvre le test à une communauté externe, généralement après qu'un premier red teaming interne a eu lieu).
Planifier un exercice
Fixer les objectifs
Que cherche-t-on à démontrer ? Extraction de données, contournement de guardrails, détournement d'agent, déni de service — l'objectif conditionne tout le reste de l'exercice, y compris ce qui sera considéré comme un succès.
Définir le threat model
Quel niveau d'accès l'attaquant simulé a-t-il ? Boîte noire (API publique seulement), boîte grise (connaissance de l'architecture), ou boîte blanche (accès aux poids et au code) — chaque niveau ouvre des techniques différentes, voir MAESTRO pour structurer cette analyse sur un système agentique.
Sélectionner les techniques adverses
Choisir dans le panorama des menaces et la matrice MITRE ATLAS les techniques pertinentes pour le système cible et le threat model retenu — inutile de tester une extraction de poids sur un système accessible en boîte noire uniquement par API.
Choisir l'outillage
Scanners automatisés (garak, PyRIT, promptfoo — voir outillage) pour la couverture large, complétés par des tentatives manuelles ciblées pour les scénarios spécifiques au système testé que l'outillage générique ne couvre pas.
Exécuter le plan — trois cas de test type
Tester systématiquement l'injection directe (en tant qu'utilisateur) et indirecte (via un document, un email, une page web ingérée par le système) pour vérifier si les instructions d'origine peuvent être détournées. Documenter précisément la formulation qui fonctionne, le taux de succès sur plusieurs tentatives, et l'effet obtenu.
Générer automatiquement de nombreuses variations d'un prompt de base (encodages, reformulations, langues, caractères spéciaux) pour découvrir des contournements de guardrails qu'une recherche manuelle n'aurait pas trouvés — l'équivalent du fuzzing en sécurité applicative classique, appliqué au langage naturel.
Certains contournements n'apparaissent qu'après plusieurs échanges : établir la confiance sur des tours anodins, puis franchir progressivement les limites (technique dite Crescendo). Un système évalué uniquement sur des prompts isolés en un seul tour manque structurellement cette classe de vulnérabilités.
targets:
- id: openai:gpt-4o-mini
redteam:
plugins:
- prompt-injection # cas de test 1
- pii
- harmful
strategies:
- jailbreak # fuzzing automatique — cas de test 2
- crescendo # multi-tours — cas de test 3
numTests: 25
# Exécution : promptfoo redteam runDivulgation responsable & reporting
Une vulnérabilité découverte doit être communiquée de façon à permettre sa correction avant publication — la divulgation coordonnée (coordinated vulnerability disclosure) reste la norme, avec un délai raisonnable accordé à l'organisation responsable du système avant toute publication publique des détails techniques.
Le rapport final gagne à distinguer deux niveaux de lecture : un rapport technique détaillant les prompts exacts, les taux de reproduction et les logs, destiné aux équipes qui vont corriger le problème ; et un rapport orienté métier qui traduit l'impact en termes de risque business (perte de données, coût de remédiation, exposition réglementaire) pour les décideurs qui arbitrent les priorités.
S'entraîner — CTF et bacs à sable
Plusieurs plateformes proposent des défis gamifiés pour s'entraîner au jailbreak et au prompt injection dans un cadre légal et sans risque : des challenges type capture-the-flag dédiés à l'IA circulent régulièrement lors de conférences de sécurité (DEF CON AI Village notamment), aux côtés de bacs à sable en ligne accessibles toute l'année qui font progresser par niveaux de difficulté croissante. Une bonne porte d'entrée avant de red teamer un système en conditions réelles.