Red teaming d'un LLM : tester votre IA comme un attaquant, étape par étape

Une conformité IA qui n'a jamais été attaquée n'est qu'une promesse sur le papier : le seul moyen de savoir si votre modèle tient vraiment est de le tester comme le ferait un attaquant, avant que l'attaquant ne le fasse pour vous. Le red teaming d'un LLM est cette démarche offensive. Dans cet article, je vous montre comment le mener pas à pas, du cadrage du périmètre au livrable, pour transformer une intuition de risque en preuve de robustesse.

Le problème : vous déployez une IA que personne n'a jamais essayé de casser

Le scénario que je vois revenir : une équipe branche un assistant IA sur ses documents internes, valide qu'il répond bien aux questions prévues, et le met en production. Personne n'a vérifié ce qui se passe quand un utilisateur mal intentionné détourne les instructions, tente d'extraire les données d'un autre service, ou pousse le modèle à exécuter une action qu'il ne devrait jamais faire. La recette fonctionne pour l'usage attendu, mais reste aveugle à l'usage détourné.

Un test fonctionnel classique vérifie que le système fait ce qu'on attend de lui. Un test offensif vérifie qu'il refuse de faire ce qu'on ne veut pas. Ce sont deux questions différentes, et la seconde est celle qui vous expose à une fuite de données, à une décision manipulée ou à une sanction.

Le red teaming d'un LLM, c'est quoi exactement ?

Le red teaming consiste à adopter la posture de l'attaquant pour éprouver un système avant sa mise en production, puis à chaque évolution. Appliqué à un modèle de langage, il ne se limite pas à un test technique isolé : c'est une boucle. On cadre le périmètre, on construit des scénarios d'attaque, on les exécute, on relie chaque faille à un contrôle, puis on rejoue le test après chaque correction. C'est cette répétition qui transforme un coup de sonde en preuve durable.

Cette démarche est le premier maillon d'une chaîne plus large qui relie le test à la preuve réglementaire. Si vous voulez la vue d'ensemble, je la détaille dans la chaîne qui relie le test à la preuve. Ici, on se concentre sur le premier mouvement : attaquer.

Étape 1 : cadrer le périmètre et les surfaces d'attaque

On ne teste pas dans le vide. La première étape définit ce qu'on attaque et jusqu'où. Vous listez les surfaces exposées de votre système : l'interface utilisateur, les données que le modèle peut atteindre, les outils qu'il peut déclencher, les autres systèmes branchés en aval. Chacune est une porte d'entrée potentielle.

Vous fixez aussi les règles du jeu : quels comptes de test, quelles données factices, quelles limites à ne pas franchir pour ne pas perturber la production. Cette étape produit un périmètre écrit et des objectifs clairs, par exemple « prouver qu'un utilisateur externe ne peut pas lire les données d'un autre client ». Un red teaming sans objectif mesurable ne produit qu'une liste d'impressions.

Pour identifier méthodiquement ces surfaces, la démarche complète est décrite dans l'audit de sécurité d'une application IA, qui en fait l'inventaire avant même de passer à l'attaque.

Étape 2 : construire le plan de test avec OWASP LLM et MITRE ATLAS

Improviser des attaques laisse forcément des trous. Pour couvrir le terrain, on s'appuie sur deux référentiels. L'OWASP LLM Top 10 nomme les risques propres aux modèles de langage et sert de checklist de départ. La taxonomie MITRE ATLASdécrit, elle, des techniques d'attaque observées sur des systèmes d'IA réels, et sert à enchaîner les scénarios comme le ferait un vrai adversaire. Le premier dit quoi tester, le second dit comment.

Si le vocabulaire des risques ne vous est pas familier, commencez par le panorama que je détaille dans OWASP LLM Top 10. Voici comment traduire quelques risques en scénarios d'attaque concrets :

Ce plan de test est votre feuille de match. Il garantit que vous ne testez pas seulement ce à quoi vous pensez, mais l'ensemble des familles de risque reconnues.

Étape 3 : exécuter les attaques et mesurer ce qui cède

Vient l'exécution. Vous jouez chaque scénario, en variant les formulations, en enchaînant les tentatives, en combinant plusieurs techniques comme le ferait un attaquant patient. Un modèle qui résiste à une injection directe cède parfois à la même attaque enrobée dans un texte anodin, ou répétée sous dix angles différents. La robustesse ne se déclare pas, elle se constate.

Ce qui compte ici, c'est la mesure, pas l'impression. Pour chaque scénario, vous notez s'il a réussi, dans quelles conditions, avec quel impact concret, et ce qui a tenu. Un résultat exploitable ressemble à « tel scénario extrait telle donnée dans telles conditions, voici la trace » et non à « le modèle semble un peu vulnérable ». Cette précision est ce qui rend la suite possible.

La question n'est jamais « le modèle est-il sûr ? » mais « quel scénario le fait céder, et avec quelle conséquence ? ». La première question n'a pas de réponse utile, la seconde se corrige.

Étape 4 : le livrable qui relie chaque faille à un contrôle vérifiable

Un test offensif qui se termine par un rapport rangé dans un dossier ne vous protège pas. La dernière étape transforme les mesures en plan d'action. Chaque faille est reliée à un contrôle précis : filtrer les sorties avant exécution, cloisonner les accès aux données, retirer tout secret du system prompt, borner ce qu'un agent peut déclencher. Et chaque contrôle est formulé de façon vérifiable, c'est à dire qu'on peut le rejouer pour prouver qu'il tient.

C'est ce qui referme la boucle. Après correction, vous rejouez les scénarios qui avaient réussi. S'ils échouent désormais, vous avez une preuve, pas une promesse. Cette preuve est aussi le matériau de votre conformité : elle nourrit directement la documentation exigée par un régulateur, comme je le montre dans la chaîne qui relie le test à la preuve.

Questions fréquentes

Faut-il une équipe de sécurité interne pour mener un red teaming ?

Non. Le travail technique peut être délégué à un tiers. Le rôle du dirigeant, du DPO ou du RSSI est de s'assurer que le périmètre est clair, que le plan couvre les familles de risque reconnues, et que chaque faille débouche sur un contrôle vérifiable. C'est ce cadrage qui fait la valeur du test, pas la seule prouesse technique.

En quoi est-ce différent d'un test d'intrusion classique ?

Un test d'intrusion classique vise l'infrastructure : serveurs, réseaux, comptes. Le red teaming d'un LLM vise le comportement du modèle: sa capacité à être manipulé par le langage, à fuiter des données ou à déclencher des actions non prévues. Les deux sont complémentaires, mais le second exige des scénarios propres à l'IA que l'approche classique ne couvre pas.

À quelle fréquence faut-il recommencer ?

À chaque évolution qui change la surface d'attaque : nouveau modèle, nouvelles données branchées, nouvel outil accessible. C'est tout le sens de la boucle. Un test valable aujourd'hui ne dit rien de la robustesse d'un système modifié depuis, car chaque ajout ouvre potentiellement une nouvelle porte.

Le red teaming suffit-il à être conforme ?

Il en est le socle, pas le tout. Il prouve la robustesse ; la conformité exige en plus de documenter cette preuve et de l'organiser en démarche continue. La bonne nouvelle : un red teaming bien mené produit exactement la matière dont votre dossier de conformité a besoin.

C'est précisément l'objet de mon audit Sécurité & Conformité IA : je teste votre IA comme un attaquant, puis je relie chaque faille à un contrôle et à la preuve attendue. Pour situer votre usage le plus exposé, un premier échange suffit à identifier par où commencer.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.