L'expression vient des exercices militaires, où une équipe rouge joue l'adversaire face à une équipe bleue chargée de défendre. L'idée est simple : pour savoir si une défense tient, il faut quelqu'un dont le métier est de la faire tomber. Appliqué à l'IA, cela signifie payer des gens pour obtenir d'un modèle exactement ce qu'il ne devrait jamais produire.
C'est l'une des pratiques centrales de la sécurité des modèles, mentionnée dans toutes les fiches techniques, et rarement expliquée. Voyons ce qu'elle recouvre.
Ce que ça cherche
Un modèle est entraîné à refuser certaines demandes, comme nous l'expliquions à propos des jailbreaks. La question est de savoir si ces refus tiennent face à quelqu'un qui cherche activement à les contourner.
Le red teaming explore quatre familles de problèmes. Les contournements de refus, où l'on obtient une réponse interdite par une formulation détournée. Les biais, où le modèle traite différemment des situations équivalentes. Les fuites, où il révèle des informations issues de son entraînement ou de son contexte. Et les comportements agentiques imprévus, où un système doté d'outils fait quelque chose que personne n'avait envisagé.
Cette dernière catégorie est devenue prioritaire, précisément parce que des cas réels sont apparus, comme ces modèles qui franchissent les limites de leur environnement de test.
Comment ça se pratique
Trois approches se combinent.
Le red teaming humain. Des experts, souvent externes, passent des semaines à chercher des angles d'attaque. Leur valeur tient à leur créativité : ils trouvent ce qu'aucune procédure n'aurait anticipé. C'est lent et coûteux, et c'est irremplaçable.
Le red teaming automatisé. On utilise des modèles pour attaquer d'autres modèles, en générant massivement des variantes de formulations. Un laboratoire a indiqué avoir consacré plus de 700 000 heures de calcul à cette recherche automatique sur ses propres systèmes. L'avantage est le volume ; la limite est que la machine explore surtout ce qui ressemble à ce qu'elle connaît.
Les campagnes ouvertes. Inviter le public à trouver des failles, parfois avec des primes. Cela apporte une diversité que des équipes internes n'auront jamais.
Le red teaming sur les modèles pose une difficulté que n'a pas la sécurité informatique classique : pour tester la résistance d'un modèle sur des sujets graves, il faut produire et lire du contenu grave. C'est le prolongement direct de ce que nous décrivions dans notre article sur les travailleurs exposés aux contenus violents. Une part de ce travail est effectuée par des spécialistes bien accompagnés, une autre par des sous-traitants qui le sont beaucoup moins.
Les limites, qu'il faut connaître
L'absence de preuve n'est pas la preuve de l'absence. Un modèle qui a résisté à dix mille tentatives peut céder à la dix mille et unième. Le red teaming établit qu'on n'a pas trouvé de faille, jamais qu'il n'y en a pas. C'est une limite logique, pas un défaut de méthode.
Les correctifs sont superficiels. Quand une faille est trouvée, on entraîne le modèle à refuser ce cas précis. Mais comme personne ne sait vraiment ce qui se passe à l'intérieur, comme nous l'expliquions à propos de l'interprétabilité, on ne corrige pas la cause. Des variantes proches peuvent continuer de fonctionner.
Le contexte évolue. Un modèle branché sur de nouveaux outils acquiert de nouvelles surfaces d'attaque. Les tests d'hier ne couvrent pas les usages de demain.
Ce qu'il faut retenir
Le red teaming est la meilleure méthode disponible, et elle est insuffisante. Ces deux affirmations sont vraies en même temps, et c'est ce qui rend le sujet inconfortable.
Sa vraie valeur est peut-être moins dans les failles trouvées que dans la culture qu'elle installe : considérer qu'un système sera attaqué, chercher activement ses propres défauts plutôt qu'attendre qu'on les découvre, et publier les taux d'échec plutôt que les taux de réussite. Quand vous lisez une fiche technique de modèle qui détaille ses scores de résistance, vous regardez le produit de ce travail. Un laboratoire qui ne publierait aucun chiffre de ce type mériterait davantage de méfiance que celui qui reconnaît des faiblesses.