En clair
Avant d’ouvrir une banque, on peut payer des spécialistes pour tenter de forcer le coffre. S’ils y parviennent, mieux vaut l’apprendre d’eux que d’un cambrioleur. Le red teaming applique cette logique à l’IA. Une équipe, dite équipe rouge, se met dans la peau d’un adversaire et essaie tout ce qui pourrait mal tourner.
Avec un modèle de langage, les attaques prennent la forme de conversations. L’équipe tente de lui faire dire ce qu’il doit refuser, par exemple en déguisant la demande en jeu de rôle. Elle essaie de lui faire révéler ses consignes internes ou des données d’autres clients, ou de lui faire accomplir une action interdite. Chaque réussite devient un cas à corriger, puis à rejouer après correction.
La différence avec un test classique tient à l’état d’esprit. Un test vérifie que le système fait ce qui est prévu. Le red teaming cherche ce que personne n’a prévu. Il ne se demande pas « est-ce que cela marche ? », mais « comment quelqu’un de malin, de pressé ou de malveillant pourrait-il s’en servir de travers ? ».
Un exemple
Une banque s’apprête à ouvrir à ses clients un assistant capable de consulter les comptes et de préparer des virements. Pendant deux semaines, une équipe mêlant experts en sécurité, juristes et conseillers de clientèle tente de le piéger : obtenir le solde d’un tiers, faire valider un virement en glissant une instruction dans le libellé d’une opération, lui faire donner un conseil fiscal erroné.
L’équipe consigne trente scénarios réussis. Certains sont corrigés dans les consignes, d’autres par des contrôles dans le code, et l’un conduit à retirer une fonction. Les trente scénarios rejoignent la série de tests rejouée à chaque mise à jour.
Comment ça marche
On distingue deux cibles. Le red teaming d’un modèle porte sur ses comportements propres : contenus dangereux, contournement des refus (jailbreak), biais, fuite de données d’entraînement. Le red teaming d’un système porte sur l’application complète : prompt système, outils, données connectées, permissions. C’est à ce niveau que se trouvent l’injection de prompt indirecte et l’exfiltration de données.
- CadrerDéfinir le périmètre, les risques visés et les règles de l’exercice.
- AttaquerChercher des failles, à la main et avec des outils automatiques.
- ConsignerDécrire chaque faille : scénario, gravité, facilité à la reproduire.
- CorrigerRenforcer le modèle, les consignes ou les contrôles autour.
- RejouerRetester après chaque correction et à chaque nouvelle version.
L’exercice se répète : chaque nouveau modèle, outil ou source de données rouvre des failles possibles.
L’exercice peut être manuel, mené par des experts de domaines variés, ou automatisé : un modèle génère des attaques en grand nombre et un classifieur juge les réponses de la cible. Cette méthode a été décrite dès 2022 3. Les deux approches se complètent. L’équipe de Microsoft, après avoir testé plus de 100 produits d’IA générative, souligne que l’automatisation élargit la couverture mais que le jugement humain reste central, que le red teaming n’est pas un test de performance standardisé et que le travail de sécurisation n’est jamais terminé 2.
La pratique entre dans les cadres de référence. Le profil du NIST consacré à l’IA générative, publié en juillet 2024, range le red teaming parmi les tests à conduire avant déploiement 1. Dans l’Union européenne, 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 tests adverses 4.
Ce que ça change pour une entreprise
Pour une entreprise qui déploie un assistant ou un agent, le red teaming est le moyen le plus direct de connaître ses risques réels avant ses clients, la presse ou un attaquant. Il est d’autant plus utile que le système a accès à des données sensibles ou peut agir. Un exercice sérieux mobilise des profils variés : sécurité, métier, juridique, et parfois des prestataires spécialisés.
Ses limites doivent être comprises. Un red teaming trouve des failles, il ne prouve pas leur absence : ne rien trouver signifie seulement que cette équipe, dans ce délai, n’a rien trouvé. Le résultat vieillit vite, puisque chaque changement de modèle, de prompt ou d’outil modifie la surface d’attaque. Il faut donc le prévoir comme une activité récurrente, avec un budget pour corriger ce qui est découvert.
Idées reçues
- « Le fournisseur du modèle a déjà fait le red teaming. »
Il a testé son modèle, pas votre application. Vos consignes, vos outils et vos données créent des failles que lui ne peut pas voir.
- « Le red teaming certifie qu’un système est sûr. »
Il révèle des problèmes, il ne garantit pas qu’il n’en reste aucun. C’est un sondage, pas une preuve.
- « C’est une affaire de pirates informatiques. »
Beaucoup de failles se trouvent en langage courant, sans compétence technique. Les experts du métier repèrent souvent les erreurs les plus coûteuses.
Sources
- NIST, « Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile » (NIST AI 600-1), 2024
- Bullwinkel et al., « Lessons From Red Teaming 100 Generative AI Products », 2025
- Perez et al., « Red Teaming Language Models with Language Models », 2022
- Règlement (UE) 2024/1689 sur l’intelligence artificielle, article 55, EUR-Lex