Red teaming IA : de l’exercice à la preuve réglementaire

L’essentiel

• Le red teaming a cessé d’être facultatif en Europe le 2 août 2025, date à laquelle l’article 55 du règlement sur l’IA s’est appliqué aux fournisseurs de modèles à usage général présentant un risque systémique.
• La sanction est désormais réelle : le Bureau de l’IA dispose de ses pouvoirs répressifs depuis le 2 août 2026, avec des amendes pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial.
• Le régime des systèmes à haut risque, lui, a reculé. L’omnibus numérique approuvé le 16 juin 2026 reporte les obligations de l’annexe III au 2 décembre 2027.
• La plupart des organisations ne sont pas fournisseurs de modèles à usage général : leur exposition passe par le contrat, via les questionnaires d’achat et les demandes d’assurance client.
• Un exercice non documenté ne prouve rien. Ce que lit un évaluateur, c’est le dossier : périmètre, modèle de menace, journal de tests, criticité, responsables de remédiation et contre-test.

Ce qu’est vraiment le red teaming, et ce qu’il n’est pas

Le red teaming consiste à soumettre un système d’IA à une attaque structurée, conduite par des personnes dont la mission, le temps de l’exercice, est de le faire échouer. L’équipe rédige des invites conçues pour contourner les garde-fous, corrompt un index de recherche documentaire, enchaîne des appels d’outils que le concepteur n’avait pas anticipés, et consigne le comportement obtenu. L’objectif n’est pas un score. L’objectif est la liste des comportements que personne n’avait prévus.

À lire la première page de résultats sur ce sujet, on en conclurait qu’il s’agit d’une discipline de sécurité, et de rien d’autre. Chaque page bien classée décrit des vecteurs d’attaque, des phases de méthode et de l’outillage. La description est exacte mais incomplète, car elle omet ce qui décide aujourd’hui du budget : dans l’Union européenne, cette activité constitue une obligation légale documentée pour une catégorie de fournisseurs, et une attente documentée pour plusieurs autres.

Deux distinctions méritent d’être posées avant d’aller plus loin.

Red teaming, tests de performance et évaluations : trois choses distinctes

Les tests de performance mesurent des capacités connues sur un jeu de questions figé. Les évaluations notent un système au regard de critères définis à l’avance. Les uns comme les autres répondent à la question « le système fait-il bien ce que nous lui avons demandé ». Aucun ne répond à la question « que fait-il d’autre ».

Le red teaming existe pour cette seconde question. La recherche d’IBM le formule sans détour : l’exercice sert à traiter ce que l’on ne sait pas que l’on ignore. Une batterie de tests de performance ne peut pas révéler un mode de défaillance auquel personne n’a songé, et c’est précisément cette catégorie qui produit les incidents.

Conséquence pratique : ces approches se complètent, elles ne se substituent pas. Mesurer une capacité ne revient pas à sonder un préjudice.

Ce n’est pas davantage un test d’intrusion rebaptisé

Un test d’intrusion vise l’infrastructure : le réseau, la passerelle d’API, la couche d’identité. Ces travaux restent nécessaires. Le red teaming vise le modèle et son comportement, qui échoue autrement. Il n’existe pas de correctif pour un modèle que l’on parvient à convaincre. La remédiation prend la forme d’un réapprentissage, d’un filtrage, d’une politique de refus, d’une réduction de privilèges ou d’une surveillance, jamais d’une montée de version.

L’obligation dont les résultats de recherche ne parlent pas

L’article 55(1)(a) du règlement sur l’IA impose aux fournisseurs de modèles d’IA à usage général présentant un risque systémique de procéder à l’évaluation du modèle selon des protocoles et des outils normalisés reflétant l’état de l’art, ce qui comprend la réalisation et la documentation de tests contradictoires visant à identifier et à atténuer les risques systémiques. Le texte ajoute que ces tests doivent être proportionnés au niveau de risque et à l’état de l’art, et qu’ils peuvent associer des experts externes indépendants.

Trois termes portent toute la charge. « Réalisation » rend l’exercice obligatoire. « Documentation » rend la trace obligatoire. « Proportionné » signifie qu’un fournisseur modeste ne sera pas jugé à l’aune du programme d’un laboratoire de pointe, et symétriquement qu’un laboratoire de pointe ne s’acquitte pas de son obligation avec un week-end de tests d’invites.

Un modèle bascule dans la catégorie du risque systémique lorsque sa puissance de calcul cumulée d’entraînement dépasse 10^25 FLOPs, ou lorsque le Bureau de l’IA le désigne sur d’autres critères. Le seuil est délibérément élevé : il vise les développeurs de modèles de frontière, pas l’entreprise médiane.

Les dates sont l’élément le plus mal compris. Les obligations relatives aux modèles à usage général s’appliquent depuis le 2 août 2025 pour les modèles mis sur le marché après cette date. Les modèles déjà commercialisés disposent d’un délai courant jusqu’au 2 août 2027. Et depuis le 2 août 2026, le Bureau de l’IA de la Commission détient ses pouvoirs de sanction, avec des amendes plafonnées à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

Pendant ce temps, le régime que tout le monde préparait depuis deux ans a reculé. Le Parlement européen a approuvé le 16 juin 2026 les amendements de l’omnibus numérique, reportant les obligations des systèmes à haut risque autonomes de l’annexe III du 2 août 2026 au 2 décembre 2027, et celles des systèmes intégrés à des produits au 2 août 2028. L’omnibus n’a pas touché aux échéances applicables aux modèles à usage général.

La situation est donc exactement l’inverse de ce que supposent la plupart des calendriers de conformité. L’obligation de test du règlement qui est opposable aujourd’hui est celle qui vise les modèles à usage général, et les tests contradictoires en constituent le cœur.

La voie opérationnelle passe par le code de bonnes pratiques pour les modèles à usage général. Son chapitre Sûreté et sécurité, publié le 10 juillet 2025, définit le dispositif attendu : évaluations de modèles, red teaming, surveillance après mise sur le marché, mesures de cybersécurité, notification des incidents et responsabilité sur le modèle. La signature reste volontaire, mais le Bureau de l’IA a indiqué que les signataires sont présumés de bonne foi et que leurs engagements pèsent dans le calcul d’une sanction. C’est l’abri le plus proche d’une protection que le règlement propose, et il repose sur des preuves de test.

Qui doit réellement pratiquer le red teaming

Pour la majorité des lecteurs, la réponse honnête est « pas vous, directement ». Il faut le dire clairement, car les contenus éditoriaux publiés par les éditeurs de sécurité sur cette requête laissent entendre une obligation universelle.

Les fournisseurs de modèles à usage général à risque systémique. Soumis à l’article 55, opposable dès maintenant, sanction à la clé. La liste est courte et les intéressés se reconnaissent.

Les fournisseurs de systèmes à haut risque. L’article 9 impose un système de gestion des risques comportant des tests tout au long du cycle de vie, et l’article 15 exige des systèmes qu’ils fonctionnent de manière fiable et résistent aux erreurs, aux défaillances et aux tentatives d’altération de leur usage ou de leurs performances. Ni l’un ni l’autre n’emploie l’expression « red teaming ». Tous deux imposent des tests dans des conditions qui mettent en tension le fonctionnement prévu, avec méthode et résultats documentés. Applicable au 2 décembre 2027 pour les systèmes autonomes de l’annexe III.

Les déployeurs. Aucune obligation légale directe de test. L’obligation arrive par le contrat : questionnaires d’achat, annexes d’assurance, droits d’audit, clauses de garantie. C’est en pratique par cette voie que le red teaming atteint la majorité des organisations, et il se présente le plus souvent sous la forme d’une question à laquelle il faut répondre en trente jours. Structurer cette réponse relève d’abord de la gouvernance, ensuite de la technique, comme le montre notre analyse des défis de la gouvernance de l’IA.

Tous les autres. Le red teaming y reste volontaire, et de plus en plus attendu. Les assureurs posent la question. Les acheteurs grands comptes aussi. Les conseils d’administration s’y intéressent après le premier incident public de leur secteur.

Un dernier groupe mérite d’être nommé : les organisations dont le parc d’IA n’est pas connu. On ne pratique pas le red teaming sur ce que l’on n’a pas inventorié, et les usages non déclarés expliquent que bien des programmes ne couvrent qu’une fraction de la surface réelle. Le secteur du recrutement en donne une illustration nette, comme le montre notre analyse de l’IA dans le recrutement.

Ce que chaque référentiel exige réellement

Les référentiels convergent sur l’activité et divergent nettement sur sa force contraignante.

Référentiel	Ce qui est exigé	Terme employé	Contraignant ?
Règlement IA art. 55(1)(a)	Évaluation du modèle incluant des tests contradictoires, documentés, proportionnés au risque	Tests contradictoires	Oui, pour les modèles à usage général à risque systémique, opposable depuis le 2 août 2026
Règlement IA art. 9 et art. 15	Tests sur le cycle de vie dans des conditions exigeantes, méthode et résultats documentés	Tests	Oui, pour le haut risque, à compter du 2 décembre 2027
Code de bonnes pratiques, chapitre Sûreté et sécurité	Évaluations de modèles, red teaming, surveillance après commercialisation, notification d’incidents	Red teaming	Volontaire, mais pris en compte en cas de sanction
NIST AI RMF, Measure 1.1	Équipes adverses et tests contradictoires pour révéler capacités dangereuses et propriétés émergentes	Red teaming	Volontaire
NIST AI 600-1, profil IA générative	Red teaming avant et après déploiement, sur douze catégories de risque	Red teaming	Volontaire
ISO/IEC 42001	Aucune clause nommée ; les enregistrements de test alimentent le système de management	Test et évaluation	Certifiable
Guide OWASP GenAI Red Teaming	Tests par phases : modèle, implémentation, système, exécution	Red teaming	Standard de praticiens
Guide CSA et OWASP sur l’IA agentique	Douze catégories de menaces agentiques sur le modèle MAESTRO	Red teaming	Standard de praticiens

Deux remarques découlent de ce tableau.

D’abord, ISO/IEC 42001 ne prononce jamais le mot, ce qui surprend ceux qui arrivent en cherchant une clause. Ce que la norme réclame, c’est la preuve que les risques ont été identifiés, que les traitements ont été testés et que les résultats ont été revus. Un rapport de red teaming assorti d’un suivi de remédiation satisfait cette exigence là où un simple test de performance échoue.

Ensuite, les instruments américains et européens décrivent la même pratique avec une force différente. Le profil de Berkeley pour les modèles à usage général place le red teaming sous Measure 1.1 du NIST AI RMF, afin de révéler capacités dangereuses, vulnérabilités et propriétés émergentes, et le reprend comme contrôle de cycle de vie sous Manage 1.3, 2.3 et 2.4. Le NIST AI 600-1 recommande de le pratiquer avant et après déploiement sur douze catégories de risque. Aucun de ces textes ne prévoit d’amende. Tous deux constituent ce qu’un évaluateur européen acceptera comme « état de l’art » lorsque l’article 55 demandera au regard de quel standard les tests ont été conduits.

Sur le terrain français, les publications de l’ANSSI sur la sécurité des systèmes d’IA générative et les recommandations de la CNIL sur le développement des systèmes d’IA jouent le même rôle d’ancrage : elles ne créent pas d’obligation nouvelle, mais elles fixent le niveau de diligence qu’un contrôleur considérera comme raisonnable.

Cadrer l’exercice pour que les constats tiennent

La plupart des rapports de red teaming échouent au cadrage, pas au test. L’exercice identifie de vrais problèmes, puis plus personne n’est capable de dire à quelle version du système ils se rapportaient.

Désigner la cible avec précision. Modèle de base, variante spécialisée, couche de recherche documentaire, surface d’outils et d’agents, application déployée. Indiquer ce qui entre dans le périmètre, ce qui en sort, et pourquoi. Tester le modèle de base ne couvre pas le produit construit par-dessus.

Figer les versions. Version du modèle, version de l’invite système, instantané de l’index documentaire, configuration des garde-fous, permissions des outils. Un constat rattaché à une version non identifiée ne peut pas être contre-testé, et un constat non testable n’est pas une preuve.

Définir les préjudices à partir de sa propre taxonomie. Les listes génériques produisent des constats génériques. Si le registre des risques désigne l’engagement financier non autorisé et la divulgation de données clients comme les expositions majeures, ce sont elles qui entrent d’abord dans le périmètre, et le rapport doit expliquer pourquoi les autres ont été différées. Ce raisonnement rend visible votre appétence au risque aux yeux d’un évaluateur.

Trancher la question de l’indépendance. L’article 55 envisage explicitement le recours à des experts externes indépendants. Les équipes internes connaissent mieux le système et coûtent moins cher. Les équipes externes sont plus difficiles à récuser et pèsent davantage sur le plan probatoire. Le choix doit être écrit et motivé, car il sera discuté.

Étendre le périmètre aux systèmes agentiques. Les tests d’invite en un seul tour deviennent insuffisants dès qu’un système dispose d’autonomie, de mémoire et d’outils. Le guide de la Cloud Security Alliance et d’OWASP organise ce travail autour du modèle de menace MAESTRO et de douze catégories, parmi lesquelles le détournement des autorisations et du contrôle de l’agent, le contournement du point de contrôle humain, la manipulation d’objectif, la manipulation de la mémoire et du contexte, l’exploitation multi-agents, le rayon d’impact et la traçabilité de l’agent. Ce dernier point compte plus qu’il n’y paraît : si les actions d’un agent ne peuvent pas être imputées après coup, la défaillance est d’abord une défaillance de responsabilité, avant d’être une défaillance de sécurité.

Les preuves que le red teaming doit laisser derrière lui

C’est la partie que les résultats de recherche ignorent entièrement, et c’est elle qui détermine si la dépense était justifiée. Imaginez le dossier qu’un évaluateur ouvrira dans dix-huit mois.

La note de cadrage. Datée, versionnée, avec les exclusions et leur justification.

Le modèle de menace. Le référentiel de rattachement du red teaming nommé explicitement : MITRE ATLAS, MAESTRO, la taxonomie OWASP GenAI, ou le vôtre, mis en correspondance avec l’un d’eux.

Le journal de tests. Ce qui a été tenté, par qui, avec quel outillage, à quelle date, contre quelle version. Les campagnes automatisées voient leur configuration consignée, et pas seulement leur sortie.

Les constats, avec criticité et motivation. La motivation compte davantage que la note. Un évaluateur peut contester un « élevé » et accepter tout de même le dossier si le raisonnement est lisible.

Les décisions de remédiation, avec responsable et échéance. Chaque constat reçoit un statut : corrigé, atténué, accepté, ou différé avec date de revue.

Le risque résiduel accepté au bon niveau. Une personne disposant de l’autorité nécessaire signe que l’exposition restante est tolérable, au regard d’un seuil écrit.

La preuve du contre-test. La démonstration que le correctif fonctionne, sur le même test, contre la version nommée. Sans cela, la colonne remédiation reste une affirmation.

Deux situations méritent d’être nommées. Un red teaming non documenté ne prouve rien, quelle que soit la qualité des tests. Et un rapport comportant des constats sans suivi de remédiation est pire que pas de rapport du tout, parce qu’il établit durablement que vous saviez. Les autorités et les demandeurs le lisent de la même façon.

Où le red teaming s’insère dans le dossier de gouvernance

Un red teaming qui se termine par un PDF a échoué, quels qu’aient été ses constats. Quatre raccordements le rendent opérationnel.

Le registre des risques. Les constats deviennent des entrées dotées d’un responsable et d’une date de revue, dans le même outil que les autres risques. Si les constats vivent dans un suivi de sécurité séparé, le dossier de gouvernance présente un trou à l’endroit du lien.

La notification des incidents. Un constat qui se matérialise ensuite en production devient une question au titre de l’article 73, et la première chose que l’on demandera est si vous saviez.

La surveillance après commercialisation. Le red teaming est une sonde ponctuelle. La surveillance en est la moitié continue, et le code de bonnes pratiques nomme les deux. Un programme qui n’en comporte qu’une est un demi-programme.

Le reporting de transparence. Le profil de Berkeley oriente les résultats vers les fiches de modèle et de système, en omettant de manière responsable les détails susceptibles d’accroître le potentiel de détournement. Cette réserve n’est pas optionnelle : publier un contournement fonctionnel relève de la faille de divulgation, pas de la transparence.

Cinq défauts qui annulent la preuve

Tester une version et livrer l’autre. Le défaut le plus courant. Le rapport décrit un système qui n’existe plus.

Limiter le périmètre à l’injection d’invite. L’injection d’invite est le mode de défaillance célèbre, pas le plus coûteux. Ce sont les permissions d’outils et l’autonomie des agents qui produisent les incidents à conséquence financière.

Ne pas disposer d’échelle de criticité. Quand tout est « moyen », rien n’est priorisé, et la motivation qu’un évaluateur veut lire n’existe pas.

Des constats sans responsable. Un constat non attribué est une note. Il sera encore ouvert à la revue suivante, et les dates le prouveront.

Aucun contre-test. Le correctif est affirmé et non démontré. C’est la lacune la plus fréquente dans des programmes de red teaming par ailleurs sérieux, et la moins coûteuse à combler.

Questions fréquentes

Le red teaming est-il obligatoire ?

Dans l’Union européenne, oui, pour une catégorie précise. L’article 55(1)(a) du règlement sur l’IA impose aux fournisseurs de modèles à usage général à risque systémique de réaliser et de documenter des tests contradictoires, obligations opposables depuis le 2 août 2026. Pour les fournisseurs de systèmes à haut risque, les articles 9 et 15 imposent des tests documentés dans des conditions exigeantes à compter du 2 décembre 2027, sans employer le terme. Pour tous les autres, l’obligation est contractuelle plutôt que légale.

Qui est visé par cette obligation au titre du règlement sur l’IA ?

Les fournisseurs de modèles à usage général dont la puissance de calcul cumulée d’entraînement dépasse 10^25 FLOPs, ou que le Bureau de l’IA désigne comme porteurs d’un risque systémique. Cela représente une population restreinte de développeurs de modèles de frontière. Les déployeurs de ces modèles héritent des attentes par le contrat, ce qui est la voie par laquelle l’exigence atteint la plupart des organisations.

Quelle différence avec un test d’intrusion ?

Un test d’intrusion attaque l’infrastructure et produit des vulnérabilités assorties de correctifs. Le red teaming attaque le comportement du modèle et produit des modes de défaillance sans correctif. La remédiation consiste en un réapprentissage, un filtrage, une politique de refus, une réduction de privilèges ou une surveillance. Les deux démarches sont nécessaires, aucune ne remplace l’autre.

À quelle fréquence faut-il conduire l’exercice ?

Indexez la cadence sur le changement plutôt que sur le calendrier. Un nouveau modèle de base, une spécialisation, un nouvel outil ou une nouvelle intégration, une modification substantielle de l’invite système, un nouveau contexte de déploiement : chacun justifie un exercice. Ajoutez une base de référence périodique, annuelle pour la plupart des systèmes, et traitez les tests postérieurs au déploiement séparément de ceux qui le précèdent.

Peut-on automatiser le red teaming ?

En partie, et la répartition compte pour la preuve. Les sondes automatisées apportent la couverture, la répétabilité et le mécanisme de contre-test, précisément ce dont la documentation a besoin. Les opérateurs humains trouvent le chemin inédit qu’aucune bibliothèque de sondes ne contient. Un programme entièrement automatisé produira un dossier propre assorti d’un angle mort prévisible.

Que demande un auditeur après l’exercice ?

La note de cadrage avec les versions, le modèle de menace et son référentiel, le journal de tests, les constats avec criticité et motivation, les responsables et échéances de remédiation, l’acceptation du risque résiduel et sa signature, ainsi que la preuve du contre-test. L’auditeur évalue la piste documentaire, pas l’exercice, parce que c’est la seule partie qui survit.

Conclusion

Les résultats de recherche traitent le red teaming comme une prestation de sécurité ; dans cette lecture, la décision se réduit à une ligne budgétaire portée par une équipe technique. La position réglementaire dit autre chose. Les tests contradictoires constituent l’obligation du règlement sur l’IA qui est opposable aujourd’hui, alors que le régime du haut risque que tout le monde préparait se situe désormais à plus d’un an, et ce qui acquitte l’obligation n’est pas l’exercice mais la trace qu’il laisse.

Ce déplacement change le propriétaire du sujet. Les tests restent entre les mains de ceux qui savent casser des systèmes. La note de cadrage, la motivation des criticités, le registre de remédiation et la signature du risque résiduel relèvent de la gouvernance, car ce sont les seuls documents que quiconque lira. Commencez par le dossier que vous devriez produire, puis commandez les tests qui le remplissent. Notre plateforme de gouvernance de l’IA montre comment ces pièces se rangent au même endroit.