Red teaming : définition et tests d’attaque des systèmes d’IA

Comment se déroule un red teaming d’IA ?

Un red teaming d’IA se déroule en quatre temps : fixer le périmètre, imaginer les attaques, attaquer, puis corriger et tester de nouveau.

1. Le périmètre. L’équipe part de ce que le système sait faire et de son usage réel. Microsoft en fait la première des huit leçons tirées de ses tests sur plus de 100 produits d’IA générative (janvier 2025).

2. Les scénarios. Contourner les consignes, glisser des instructions dans un document (prompt injection), extraire des données, obtenir un contenu interdit, déclencher une action non voulue d’un agent IA.

3. L’attaque. Des personnes attaquent à la main ; des outils automatisent les variantes. Microsoft diffuse ainsi PyRIT, un outil ouvert, depuis février 2024, et précise qu’il ne remplace pas le test manuel.

4. La correction. L’équipe documente chaque faille ; le responsable du système corrige, puis l’équipe rejoue les attaques.

Le guide de red teaming de l’OWASP (janvier 2025) couvre quatre couches : le modèle, sa mise en œuvre, l’infrastructure et le comportement en production.

Red teaming, test d’intrusion ou benchmark : quelle différence ?

Le red teaming d’IA ajoute les failles de comportement aux failles techniques ; le test d’intrusion cherche les failles techniques ; le benchmark mesure la performance.

• La red team de cybersécurité imite un attaquant contre la sécurité de l’entreprise, selon la définition que reprend le NIST. Avec les LLM, le terme s’étend à toutes sortes de tests des systèmes d’IA, note Microsoft. Les deux se complètent : l’ANSSI recommande des tests d’intrusion sur les composants techniques et des tests propres aux modèles d’IA (R23).

• Le test de qualité vérifie les réponses dans un usage normal ; l’ANSSI lui consacre une autre recommandation (R24). Le red teaming observe l’outil face à un usage hostile.

• Le benchmark compare des modèles sur un même jeu de questions. Selon Microsoft, le red teaming demande plus d’effort humain, mais il peut découvrir des dommages d’un type nouveau.

Qui pratique le red teaming, et que demande l’AI Act ?

Éditeurs, prestataires et équipes internes pratiquent le red teaming ; l’AI Act l’impose aux fournisseurs des modèles les plus puissants.

OpenAI a lancé en septembre 2023 un réseau d’experts externes, le Red Teaming Network. Microsoft a créé en 2018 son équipe rouge consacrée à l’IA. Pour auditer un système d’IA générative, l’ANSSI cite les prestataires d’audit de sécurité qu’elle qualifie (PASSI, R23).

L’AI Act impose aux fournisseurs de modèles d’IA à usage général présentant un risque systémique de réaliser et de documenter des essais contradictoires (article 55). L’article 51 présume ce risque au-delà de 10²⁵ opérations en virgule flottante pour l’entraînement. Ces règles s’appliquent depuis le 2 août 2025, et au plus tard le 2 août 2027 pour les modèles mis sur le marché avant cette date. L’article 15 exige aussi qu’un système à haut risque résiste aux attaques propres à l’IA. Cette règle s’applique à partir du 2 décembre 2027 ou du 2 août 2028. Une ETI qui déploie un outil n’est en général ni l’un ni l’autre.

Que change le red teaming pour votre décision ?

• Le test de l’éditeur ne couvre pas votre usage. Vous branchez le modèle sur vos documents, vos droits d’accès et vos outils. Microsoft conseille de tester le modèle avec ses protections, puis l’application, avant et après correction. Demandez à l’éditeur le périmètre et la date de ses tests, puis testez votre configuration.

• Un agent multiplie les points d’attaque. Du 8 mars au 6 avril 2025, l’AI Security Institute britannique a soutenu un concours public d’attaque contre 22 agents IA. Les participants ont soumis 1,8 million d’attaques par prompt injection ; plus de 60 000 ont réussi. Selon les auteurs, presque tous les agents cèdent en 10 à 100 requêtes sur la plupart des comportements visés.

• Un test vieillit avec le système. Selon OpenAI, les systèmes changent souvent en production, et un test ponctuel peut sous-estimer les risques. Pour Microsoft, la sécurisation d’un système d’IA n’est jamais terminée. Testez de nouveau après chaque changement de modèle, de consignes ou d’outil.

• Trouver une faille ne suffit pas. Les guardrails, les droits d’accès et la validation humaine en limitent les effets. Désignez avant le test qui corrige, et dans quel délai.

• Vous pouvez commencer à votre échelle. Selon Microsoft, des techniques simples marchent souvent aussi bien que des méthodes mathématiques sophistiquées. Un expert métier et un expert sécurité peuvent écrire des scénarios propres à votre usage et les rejouer à chaque version. Vérifiez d’abord ce que le contrat autorise sur un service que le fournisseur héberge.

Exemple illustratif

Ce cas est fictif. Une ETI prépare un assistant RH qui répond aux salariés à partir des documents internes. Avant l’ouverture, une juriste, un responsable RH et l’équipe sécurité l’attaquent pendant deux jours. Ils demandent le salaire d’un collègue et déposent un document qui contient une instruction cachée. L’assistant révèle une grille de rémunération rangée dans un dossier mal protégé. L’entreprise corrige les droits du dossier, ajoute un filtre de sortie et rejoue tous les scénarios. Elle les rejoue ensuite à chaque changement de modèle.