01Ce qui distingue l'AI Red Teaming du Red Teaming classique
Le Red Teaming classique simule des attaquants visant les réseaux, les systèmes et les identités – les constats sont en général des vulnérabilités techniques clairement reproductibles. L'AI Red Teaming, en revanche, cible le comportement du système d'IA lui-même : les modèles de langage répondent de manière probabiliste, une même attaque peut ne réussir qu'à la dixième tentative, et un constat n'est souvent pas une erreur de programmation mais un comportement indésirable du modèle. Au-delà des objectifs de sécurité classiques, les tests portent aussi sur les préjudices liés aux contenus, comme la génération de contenus nuisibles ou erronés. La distinction avec les benchmarks est tout aussi importante : les jeux de test statiques mesurent des capacités connues, tandis que le Red Teaming recherche délibérément des modes de défaillance inédits et propres au contexte – l'une des leçons centrales du Microsoft AI Red Team, tirée de plus de 100 produits GenAI testés.
02Attaques au niveau du modèle et de l'application
Quatre familles de techniques sont au cœur du sujet. Les jailbreaks contournent les garde-fous de sécurité d'un modèle pour débloquer des contenus ou des fonctions restreints. Dans la prompt injection directe, l'attaquant place des instructions manipulatrices dans sa propre saisie ; dans la prompt injection indirecte, il les dissimule dans des contenus que le système traite – pages web, documents ou e-mails par exemple. L'extraction de données vise les prompts système, les données d'entraînement ou les sources de connaissances connectées – répertoriée dans l'OWASP Top 10 for LLM Applications 2025 comme Sensitive Information Disclosure (LLM02) et System Prompt Leakage (LLM07), tandis que la Prompt Injection ouvre la liste en tant que LLM01. L'usage non sécurisé d'outils (Excessive Agency, LLM06) est particulièrement critique : si un modèle peut envoyer des e-mails, interroger des bases de données ou exécuter du code, une instruction injectée devient une action exécutée.
03Ancrages méthodologiques : OWASP GenAI Red Teaming Guide et NIST
Avec le GenAI Red Teaming Guide (version 1.0, janvier 2025), l'OWASP GenAI Security Project a publié une méthodologie structurée et indépendante des éditeurs. Le guide considère quatre niveaux de test : l'évaluation du modèle lui-même, l'implémentation (notamment les guardrails et les prompts système), l'infrastructure environnante ainsi que le comportement à l'exécution en interaction avec les utilisateurs et les processus. En complément, NIST AI 100-2 E2025 (mars 2025) fournit une taxonomie et une terminologie de l'adversarial machine learning qui classe les attaques contre les systèmes d'IA prédictifs et génératifs selon les objectifs, les capacités et la phase du cycle de vie de l'attaquant. Ensemble, ces deux documents constituent le vocabulaire permettant de définir de façon traçable le périmètre des tests et la grille d'évaluation.
04Déroulement : scénarios, grille d'évaluation, reporting
Un AI Red Teaming commence par le cadrage : quel cas d'usage, quelles classes de données, quels outils connectés, quel potentiel de préjudice ? Il en résulte une modélisation des menaces avec des scénarios d'attaque concrets, priorisés selon le dommage réaliste plutôt que la simple faisabilité. Les tests combinent deux approches : automatisée, avec des frameworks comme PyRIT, l'outil open source de Microsoft, pour une couverture en largeur, et manuelle pour les chaînes d'attaque propres au contexte – selon l'expérience du Microsoft AI Red Team, l'automatisation étend la couverture mais ne remplace pas l'expertise humaine. Une grille d'évaluation classe les constats selon la gravité, la reproductibilité et les objectifs de sécurité affectés. Le reporting documente chaque constat avec des preuves traçables (prompts et réponses du modèle) et en déduit des mesures de durcissement, par exemple des autorisations d'outils plus restrictives, des filtres d'entrée et de sortie ou des prompts système révisés.
05Ancrage réglementaire : le règlement sur l'IA
Le règlement sur l'IA (règlement (UE) 2024/1689) fait pour la première fois de l'adversarial testing une obligation légale explicite : selon l'art. 55(1)(a), les fournisseurs de modèles d'IA à usage général présentant un risque systémique doivent réaliser des évaluations de modèles selon des protocoles et des outils normalisés à l'état de l'art – y compris la conduite et la documentation d'adversarial testing afin d'identifier et d'atténuer les risques systémiques. Ces obligations s'appliquent depuis le 2 août 2025. Elles ne concernent directement qu'un petit nombre de fournisseurs de modèles, mais fixent la référence pour toute la chaîne d'approvisionnement. Pour les systèmes d'IA à haut risque, l'art. 15(5) exige en outre une résilience face aux attaques spécifiques à l'IA – sont cités entre autres le data poisoning, le model poisoning, les adversarial examples ou model evasion et les attaques contre la confidentialité. L'AI Red Teaming est une voie naturelle pour démontrer l'efficacité de telles mesures.
06Ponctuel ou continu ?
Une évaluation ponctuelle – par exemple avant la mise en production ou comme base d'une décision de validation – fournit un instantané fiable. Elle ne reste valable que tant que le système ne change pas : les mises à jour du modèle par le fournisseur, les prompts système ajustés, les nouveaux outils et sources de données ou les nouvelles techniques d'attaque déplacent en permanence le niveau de risque. Le Microsoft AI Red Team en tire la leçon que la sécurisation des systèmes d'IA n'est jamais achevée. Pour les applications d'IA en production et en évolution constante, une approche continue s'impose donc – avec des tests de régression automatisés à chaque changement pertinent, des tests approfondis manuels périodiques et un ancrage solide dans le processus de gouvernance et de développement de l'IA.
