Ce que c'est

L'AI red teaming est le test adverse d'un système à base d'IA : tenter délibérément de le manipuler comme le ferait un attaquant, pour voir ce qu'on peut le pousser à faire. Le mot qui compte est système. La cible n'est pas seulement le modèle de langage, c'est tout ce qui l'entoure — la couche de récupération, la chaîne de prompts, les outils qu'il peut appeler, la mémoire qu'il garde et les permissions avec lesquelles il agit.

Voir ce qu'on peut lui faire faire : test adverse pour systèmes IA

C'est un autre exercice qu'une évaluation de sûreté du modèle, qui demande si le modèle produit du texte dangereux. L'AI red teaming pose une question plus tranchante : dans cet environnement réel, avec ces intégrations et ces permissions, qu'est-ce que le système peut être manipulé à réellement faire ?

Pourquoi l'AppSec traditionnelle échoue

La sécurité applicative classique suppose des frontières relativement prévisibles : une entrée arrive, le code la traite, une sortie repart. Même complexe, le logiciel restait assez borné pour être raisonné avec des contrôles familiers — revue de code, analyse, test manuel, application de politiques.

Les applications à base d'IA brisent ce modèle, car le comportement dépend désormais d'outils, de récupération, de mémoire et de permissions déléguées :

Un chatbot peut tirer des informations d'une base de connaissances.
Un copilote peut synthétiser des données de plusieurs systèmes internes.
Une appli LLM peut interpréter des instructions, appeler des API et déclencher un workflow en aval.
Un agent peut faire tout cela en gardant de la mémoire et en agissant avec un accès délégué.

Voilà pourquoi des cadres comme les listes OWASP pour applications LLM et agentiques existent : ces systèmes portent des risques — mésusage d'outils, abus d'identité et de privilèges, empoisonnement de mémoire — que la pensée AppSec plus ancienne ne capte pas pleinement.

Pas seulement le modèle

Ce n'est pas le modèle, c'est le système : l'AI red teaming vise tout l'empilement autour du modèle

L'idée que les responsables sécurité doivent le plus intégrer : un attaquant n'a en général pas à vaincre le modèle. Souvent, il n'a même pas besoin qu'il se comporte mal de façon visible. Il lui suffit d'abuser du système autour — la couche de récupération, la chaîne de prompts, le chemin d'exécution, le modèle de permissions, la mémoire, ou la logique applicative qui transforme une sortie en action.

Les systèmes IA deviennent une partie de la surface d'attaque précisément parce qu'ils siègent à l'intersection des données, de la confiance, de l'automatisation et de l'action. Un scanner peut trouver un bug de code. Un red-team du modèle peut attraper une sortie dangereuse. Ni l'un ni l'autre ne vous dit ce qu'un attaquant peut faire de bout en bout dans l'environnement en marche, et c'est dans cet écart que vit l'exposition réelle.

De la mauvaise sortie au mauvais résultat

Réduire le risque IA à l'« injection de prompt » n'en saisit qu'une partie. En entreprise, un contexte manipulé mène à un comportement manipulé, qui mène à l'exposition de données, à l'autorisation cassée, à l'usage dangereux d'outils et à l'abus de workflow. Le problème cesse d'être une mauvaise sortie et devient un mauvais résultat.

Ce sont des schémas d'échec reconnaissables et récurrents dans les systèmes IA en production :

Injection de prompt directe contre un copilote.
Injection indirecte via du contenu embarqué ou tiers que le système lit.
Fuite du prompt système ou d'instructions sensibles.
Exposition de données inter-locataires entre clients d'une appli IA partagée.
Élévation de privilèges via des chaînes d'exécution d'outils.
Autorisation cassée dans une logique métier générée par IA, et API internes exposées lors d'un développement assisté par IA.

Aucun de ces cas n'exige que le modèle soit « jailbreaké » au sens caricatural. Ce sont des défaillances de sécurité ordinaires, revêtues d'une nouvelle surface.

Ce qu'exige réellement le test

Un AI red teaming utile est continu et couvre tout le chemin d'exécution — traitement des entrées, récupération, mémoire, outils, permissions, logique métier et workflows en aval — car c'est le seul moyen de dire si une faiblesse est simplement intéressante ou réellement exploitable.

Cela veut dire tracer toute la chaîne : une manipulation de prompt peut-elle changer le comportement ; le comportement changé peut-il déclencher un outil ; cet usage d'outil franchit-il une frontière ; et le résultat crée-t-il un vrai risque métier. C'est du test d'exploitabilité, pas de l'analyse statique ni un score d'évaluation de modèle. Et comme prompts, modèles, intégrations et workflows changent chaque jour, une évaluation ponctuelle se périme presque aussitôt — le test doit suivre le rythme.

Les questions qui valent la peine

La question utile pour un responsable sécurité n'est donc pas de savoir si un système IA est « sûr » dans l'abstrait. Elle est opérationnelle, et c'est la même série qu'un attaquant testera en premier :

Un chatbot peut-il être manipulé pour révéler des informations restreintes ?
Un copilote peut-il franchir une frontière de locataire ?
Un agent peut-il être poussé à une action que l'organisation n'a jamais voulue ?

Le cadrage honnête est modeste : l'IA est une couche opérationnelle vivante — en partie logiciel, en partie moteur de décision, en partie opérateur. Les équipes les mieux placées ne seront ni celles qui ralentissent l'adoption, ni celles qui la traitent comme « une fonctionnalité de plus » ; ce seront celles qui voient assez clairement dans cette couche pour savoir ce qu'on peut lui faire faire, et qui la vérifient en continu à mesure qu'elle change.

CyberStrike est une plateforme de tests d'intrusion augmentés par l'IA, actuellement en accès anticipé. Voir l'AI red teaming sur la plateforme ou rejoignez la liste d'attente.