Le Red Teaming en IA expliqué : ce qu’une Red Team teste, et ce qu’elle laisse derrière elle

La plupart des missions de red teaming d’IA sont jugées sur le mauvais artefact. Une semaine de travail produit un jeu de diapositives, le jeu de diapositives dit qu’on peut amener l’assistant à rédiger un courriel d’hameçonnage, et personne ne peut dire ensuite si le comportement était reproductible, à quel point il était grave, ni quelle mesure de contrôle l’aurait empêché. La discipline a un véritable livrable, et ce n’est pas une présentation : c’est un ensemble de constats qui survivent à une réexécution, chacun étant rattaché à une frontière qui a été franchie et aux preuves qui l’ont franchie. C’est aussi la forme du registre que l’archive des incidents d’IA tient — 400 entrées couvrant de décembre 2024 à octobre 2026, issues de 743 sources distinctes, et un verdict sur chacune indiquant si quelqu’un a réellement été lésé.

La confusion est compréhensible, car « red teaming » désigne deux activités qui partagent un vocabulaire et peu de choses d’autre. Voici un guide des deux, des preuves que chacune devrait produire, et des quatre points sur lesquels le red teaming en IA s’écarte véritablement de la version réseau que la plupart des équipes de sécurité savent déjà mettre en œuvre.

La question du cadre : à qui appartient le test ?

Avant même le périmètre, se pose la question de savoir qui mène l’exercice et contre quoi. Microsoft publie l’une des positions publiques les plus complètes à ce sujet, et cela vaut la peine de la lire comme une carte plutôt que comme une page produit. Son hub AI Red Team sépare le concept du red teaming de l’IA de la mise en œuvre, puis classe la pratique dans un ordre qui est en soi un argument : une vue d’ensemble, puis un guide pour constituer une équipe de red teaming pour un LLM, puis les documents de référence — un seuil de gravité des bogues pour le tri des attaques contre les systèmes d’apprentissage automatique, une taxonomie des défaillances de l’apprentissage automatique, un modèle de responsabilité partagée et des recommandations de modélisation des menaces pour les développeurs.

Lisez la séquence, et la méthodologie en découle. Une taxonomie décide de ce qui compte comme une défaillance. Un seuil de gravité des bugs décide lesquelles de ces défaillances valent la peine d’être corrigées. Un modèle de responsabilité partagée décide qui doit rendre des comptes une fois qu’elle est détectée. La modélisation des menaces décide où chercher ensuite. Sans ces quatre éléments, une équipe red team produit des anecdotes avec une colonne de gravité greffée dessus, et cette colonne de gravité n’est que le ressenti du testeur cet après-midi-là.

Le cadre d'automatisation open source de Microsoft, PyRIT, est rangé sur la même étagère, et c'est précisément ce positionnement qui est utile. Une boîte à outils d'orchestration n'est pas une méthodologie ; c'est ce que l'on braque sur une cible une fois que la taxonomie et le seuil de gravité des bugs existent. Les équipes qui commencent par le framework finissent généralement avec un vaste corpus de prompts et aucun moyen de classer les résultats.

Deux équipes rouges, deux questions différentes

La distinction la plus utile dans ce domaine est celle que presque personne ne consigne par écrit : une équipe red team testant un modèle et une équipe red team testant un système répondent à des questions différentes, avec des unités testées, des résultats et des responsables différents. Les confondre, c'est ainsi qu'un jailbreak est signalé comme une découverte de sécurité, et qu'un véritable bug d'élévation de privilèges est classé comme une plainte sur la qualité du modèle.

L’évaluation de la sécurité au niveau du modèle est un problème de mesure. Vous cherchez à savoir si un modèle produira une catégorie de contenu, et la manière honnête d’y répondre est un échantillon suffisamment grand pour se prononcer sur un taux. L’unité testée est le modèle derrière une API légère, la méthode consiste à utiliser des prompts adversariaux — jailbreaks, attaques par persona, pression sur plusieurs tours — et ce qui en ressort est une transcription accompagnée d’un jugement de nocivité. Lorsque les poids changent ou que la couche de sécurité du fournisseur évolue, l’ensemble du résultat devient obsolète. C’est pourquoi ce type de test est généralement réalisé par le constructeur du modèle ou par un évaluateur indépendant, et pourquoi ses conclusions correspondent rarement à une correction spécifique dans votre application.

L'émulation d'adversaire au niveau système est un problème d'ingénierie. Vous cherchez à déterminer si un attaquant peut amener le système déployé à agir — lire un fichier qu'il ne devrait pas, appeler un outil qu'il ne devrait pas, dépenser de l'argent qu'il ne devrait pas. L'unité testée est l'agent avec ses outils, sa récupération et ses identifiants attachés. Les méthodes sont les habituelles, réorientées : injection via le contenu récupéré plutôt que via le tour de l'utilisateur, abus d'outils, chaînes de privilèges assemblées à partir de permissions individuellement raisonnables, chemins de données qui fuient au-delà d'une frontière de locataire. Le résultat est une conclusion accompagnée d'une reproduction, d'une frontière franchie et d'un propriétaire qui peut modifier la configuration dès demain.

Les deux produisent des artefacts incompatibles, et cette incompatibilité est diagnostique plutôt qu’ennuyeuse. Un résultat au niveau du modèle ne peut pas être « corrigé » par votre équipe, sauf en changeant de modèle. Un résultat au niveau du système ne peut pas être corrigé du tout par le fournisseur. Si un rapport ne précise pas lequel des deux il s’agit, vous ne pouvez attribuer aucun de ses éléments.

Ce que devient la surface d’attaque une fois que le modèle dispose d’outils

La surface que la plupart des équipes testent encore est le prompt. C’est aussi la moins intéressante, car c’est celle sur laquelle le fournisseur du modèle a investi le plus d’efforts de durcissement et celle sur laquelle un attaquant a le moins de prise. Les surfaces qui rapportent réellement sont celles ajoutées par l’application : les outils que l’agent peut appeler, l’index de récupération qu’il consulte, la mémoire qu’il conserve entre les tours et le canal de sortie lui-même.

Les outils sont le lieu où un modèle de langage devient un acteur, et la question intéressante n'est jamais « peut-il appeler l'outil » mais « quel est le moindre privilège que cet outil aurait pu avoir ». Un outil de recherche de tickets qui accepte une requête en texte libre peut généralement être convaincu d'accepter l'identifiant d'un autre client. La récupération est un canal de contenu vers le contexte du modèle, ce qui signifie que quiconque peut écrire dans le corpus — un espace partagé, une macro d'assistance, une page web à laquelle le récupérateur accède — écrit dans le prompt. La mémoire transforme un seul tour en persistance : une instruction implantée au deuxième tour est toujours là au quarantième tour. La sortie est l'endroit où le texte du modèle atterrit dans un environnement qui l'interprète, et le rendu, le markdown, les aperçus de liens et les pipelines proches du shell interprètent tous du texte.

Une mission qui ne teste que le prompt signalera un résultat impeccable et aura raison sur la mauvaise chose.

Pourquoi une transcription n'est pas un constat

Une découverte doit présenter trois propriétés qu'une capture d'écran d'une fenêtre de chat ne possède pas. La première est la reproductibilité : relancez-la depuis un état propre et elle se reproduit. Les modèles étant non déterministes, la reproductibilité est un taux plutôt qu'un booléen — « neuf tentatives sur dix » est une découverte, « c'est arrivé une fois » est une rumeur. La deuxième est un franchissement de frontière : nommez ce qui n'aurait pas dû se produire dans les termes propres à l'application, et non ceux du modèle. Non pas « le modèle a été grossier », mais « l'agent a lu un document appartenant au locataire B ». La troisième est une gravité qui découle de l'impact plutôt que de l'intuition du testeur, ce à quoi sert une barre de bogues.

Tout le reste — la transcription, le prompt, le raisonnement du modèle — constitue des éléments de preuve à l’appui de ces trois points. Ce n’est pas la conclusion elle-même, et c’est pourquoi un corpus de deux mille prompts de jailbreak vaut moins que cinq constats système reproductibles assortis de contrôles nommés.

Quatre points où le red teaming de l'IA diverge du red teaming réseau

Les équipes issues de la sécurité réseau ou applicative apportent de bons réflexes et quatre fausses hypothèses.

• Il n’y a pas de périmètre à tenir. Un engagement réseau dispose d’une liste de cibles ; un engagement d’agent dispose d’une fenêtre de contexte assemblée au moment de la requête à partir de sources que vous n’avez peut-être pas inventoriées. La portée doit être exprimée en sources de données et autorisations d’outils, et non en noms d’hôtes.

• La cible est non déterministe. La même entrée peut réussir le mardi et échouer le mercredi. Cela rompt la norme de preuve de la « reproduction propre unique » et vous oblige à rapporter des taux.

• L'exploit, c'est le langage, et le langage n'a pas de correctif. On peut corriger une vérification d'autorisation manquante. On ne peut pas corriger « le modèle peut être persuadé ». L'atténuation d'une faiblesse au niveau du langage passe par un contrôle situé ailleurs — un filtre, une limite de portée, une frontière de permissions —, et c'est pourquoi les constats doivent nommer le contrôle, et pas seulement le comportement.

• Le fournisseur est dans la boucle. Votre cible change lorsque quelqu'un d'autre publie une version. Un résultat au niveau du modèle n'est valide que pour le build que vous avez testé, et si vous n'avez pas enregistré la version et la date, vous n'avez pas de résultat.

Comment définir le périmètre d'une première mission

Les missions qui tournent mal sont presque toujours cadrées comme « tester l'IA ». Un périmètre qui survit au contact d'un planning ressemble davantage à ceci : un seul agent, dans un environnement de préproduction, avec des données et des autorisations calquées sur la production ; une liste des cinq limites qui comptent (isolation des locataires, accès aux identifiants, dépenses, sortie de données, périmètre des outils) ; des règles d'engagement qui nomment ce qui est hors limites ; des conditions d'arrêt qui indiquent qui peut interrompre l'exécution ; et un format de preuves défini et convenu avant la première tentative, afin que le rapport soit assemblé à partir d'artefacts plutôt que reconstitué de mémoire.

L'autorisation mérite sa propre phrase, car c'est l'élément que les équipes négligent lorsque la cible est leur propre produit et que les outils appartiennent à d'autres. Tester un modèle que l'on n'exploite pas, sur une infrastructure que l'on ne possède pas, avec des invites conçues pour contourner une couche de sécurité, est une activité différente du test de son propre déploiement — et c'est le périmètre écrit qui distingue les deux. Le contrôle de vérification auquel est soumis notre propre palier cyber existe pour la même raison : un travail de sécurité autorisé au niveau du modèle exige une partie nommée et redevable des deux côtés.

Ce que le registre d’incident ajoute

Un exercice red team vous dit ce que fait votre cible. Il ne peut pas vous dire ce qui se passe sur le terrain, et c’est sur le terrain que l’argument en faveur d’un contrôle se construit réellement. C’est le vide que comble un registre d’incidents — et la discipline qu’il impose est la partie utile : un enregistrement sans au moins une source n’existe pas, et un enregistrement sans verdict de préjudice n’est pas un incident.

Lisez les deux artefacts ensemble et la boucle est bouclée. L’équipe red team produit un constat reproductible et nomme le contrôle qui l’aurait bloqué. Le registre vous indique si quelqu’un sur le terrain a déjà rencontré cette limite, quel a été le préjudice et si le contrôle a tenu ailleurs. Un constat sans précédent terrain est une hypothèse qu’il vaut la peine de corriger ; un incident terrain sans constat reproductible est un bogue que vous ne pouvez pas encore clore. Les équipes qui réussissent cessent de considérer « nous avons fait du red teaming sur le modèle » comme un livrable et commencent à le considérer comme une donnée parmi d’autres dans un registre qui leur est propre.

Ce qui laisse place à une conclusion honnête. Le red teaming de l’IA ne produit pas de garantie de sécurité, et toute mission vendue comme telle vend la mauvaise chose. Il produit un ensemble de limites que vous savez désormais franchies, avec des preuves que vous pouvez rejouer, classées selon ce qui se produit lorsqu’elles le sont. C’est suffisant pour prendre des décisions — et bien plus qu’une présentation.