Le red teaming consiste à placer des testeurs dans la peau d'attaquants : ils cherchent délibérément à faire déraper une IA, à lui soutirer ce qu'elle devrait refuser ou à lui faire fuiter ce qu'elle devrait protéger, afin de colmater les brèches avant la sortie. Le terme vient de la cybersécurité, où une équipe rouge attaque et une équipe bleue défend. On ne mesure pas la performance en usage poli et normal, mais la tenue du système quand quelqu'un cherche activement à le casser.
Ce que les équipes rouges essaient concrètement
Les tentatives se rangent en quelques familles. L'une vise les contenus interdits : reformuler, découper, déguiser la demande pour voir si le modèle se laisse convaincre de produire ce qu'il devrait refuser. Une autre est l'injection de prompt : cacher des instructions dans des pages web, des documents ou des images pour vérifier si le modèle obéit à un texte planté par un inconnu comme s'il venait de son propriétaire. Une troisième vise la vie privée : combiner indices publics et ingénierie sociale pour extraire des données personnelles ou des documents internes. Une quatrième teste les biais et la factualité, avec des questions orientées qui poussent le modèle à inventer des arguments en faveur de l'utilisateur. Dans tous les cas, le testeur part hostile, et plus la question est retorse, mieux c'est.
Ni un test ordinaire, ni les garde-fous eux-mêmes
Un test ordinaire mesure la coopération : un jeu de questions fixe, noté sur la justesse et la rapidité, comme un examen blanc. Le red teaming mesure la résistance : il ignore le questionnaire et chasse dans les recoins qu'il ne couvre jamais, comme un chercheur de défauts professionnel. Les garde-fous viennent ensuite : chaque contournement réussi devient une règle, un filtre ou une correction d'entraînement, puis l'équipe rouge revient essayer. Les garde-fous sont le bouclier, l'équipe rouge est celle qu'on paie pour le frapper avec tout ce qui lui tombe sous la main. Un bouclier que personne n'a frappé n'arrête que les attaques que son concepteur avait imaginées.
Trois idées reçues
Première idée reçue : le red teaming serait une discussion au hasard, en comptant sur la chance. Le travail professionnel est l'inverse : les méthodes d'attaque sont cataloguées, les contournements réussis doivent être reproductibles et classables, et ils alimentent une suite de régression rejouée après chaque mise à jour du modèle. Deuxième idée reçue : réussir un exercice de red teaming rendrait un système sûr. Cela prouve seulement que les attaques connues ont été essayées ; les vrais attaquants continuent d'en inventer après la sortie, d'où des tests continus chez les équipes matures, parfois avec des prestataires externes et des primes aux bogues. Troisième idée reçue : cela ne concernerait que les chatbots. Dès qu'une IA peut appeler des outils, lire des sources externes et agir pour le compte d'un utilisateur, on teste aussi si un simple courriel d'hameçonnage peut la pousser à supprimer des fichiers ou à exfiltrer des documents, un risque bien plus grave qu'une phrase de travers.
Pour juger un produit d'IA, les démos et les classements ne racontent donc que la moitié de l'histoire. Il vaut la peine de regarder si le fournisseur parle ouvertement de son red teaming : qui teste, ce qui a été trouvé, et si les correctifs ont été retestés. Ceux qui acceptent de raconter les coups encaissés méritent en général plus de confiance que ceux qui n'affichent que des scores.
