Le red teaming IA consiste à jouer le rôle de l’attaquant contre votre propre assistant, de façon structurée, avant qu’un utilisateur malveillant ou simplement curieux ne le fasse à votre place. Nul besoin d’une équipe de sécurité dédiée : un périmètre clair, une liste d’attaques, une politique écrite et un rejeu régulier suffisent pour démarrer.
Un assistant déployé en entreprise répond à des inconnus, lit des documents que personne n’a vérifiés et agit parfois sur des outils internes. Chacun de ces points est une surface d’attaque. Il est donc acquis que quelqu’un tentera de détourner votre assistant : reste à savoir ce qu’il obtiendra en essayant.
Qu’est-ce que le red teaming appliqué à l’IA ?
Le terme vient de la sécurité informatique : une équipe « rouge » attaque un système avec l’accord de son propriétaire pour en révéler les faiblesses. Appliqué à l’IA, le principe est le même, mais la cible change. On n’attaque plus seulement un serveur ou une application, on attaque un comportement : ce que le modèle accepte de dire, de révéler ou de faire.
Cette différence compte. Un logiciel classique plante ou ne plante pas. Un modèle de langage (LLM) répond différemment d’une fois sur l’autre, et une même consigne peut passer un jour et échouer le lendemain. Le test ponctuel ne prouve donc presque rien : il faut des batteries d’attaques, répétées, avec un taux de réussite mesuré.
Le guide OWASP GenAI Red Teaming Guide (OWASP pour Open Worldwide Application Security Project), publié en version 1.0 le 22 janvier 2025, structure la pratique autour de quatre axes : l’évaluation du modèle, les tests d’implémentation, l’infrastructure et le comportement à l’exécution. Ce découpage est utile pour une raison simple : un modèle robuste peut être mal intégré, et une intégration soignée peut reposer sur une infrastructure fragile. Tester seulement le modèle, c’est regarder un quart du problème.
Quelles attaques tester sur un assistant ?
Les attaques se regroupent en familles. Pour un premier tour, il n’est pas nécessaire d’inventer : on part des familles connues et on les adapte à son cas d’usage.
- Le prompt injection direct : l’utilisateur écrit des instructions qui tentent d’écraser celles du système (« ignore tes consignes précédentes »).
- Le prompt injection indirect : l’instruction malveillante se cache dans un contenu que l’assistant lit lui-même, comme une page web, un e-mail, un PDF ou une fiche produit. L’utilisateur n’a rien tapé de suspect, le piège était dans la source.
- Le jailbreak : contourner les garde-fous par un jeu de rôle, un scénario fictif, un encodage ou une série de messages qui avancent par petites étapes.
- La fuite d’informations : faire révéler le prompt système, des données d’autres utilisateurs, des documents internes indexés dans une base de type RAG (génération augmentée par récupération) ou des identifiants.
- L’abus d’outils : quand l’assistant peut envoyer un e-mail, lancer une requête ou modifier un enregistrement, tester ce qui arrive s’il le fait sur ordre d’un tiers.
- Les sorties dangereuses ou hors périmètre : conseils juridiques ou médicaux inventés, engagements commerciaux que l’entreprise ne prendrait jamais, propos qui engagent sa réputation.
L’ordre de priorité dépend de ce que l’assistant peut faire. Un assistant qui ne fait que répondre à partir d’une FAQ publique risque peu. Celui qui lit des documents internes et dispose d’outils concentre l’essentiel du danger.
Comment monter un protocole de test, étape par étape ?
La méthode qui suit ne dépend d’aucun outil. Elle tient en cinq étapes, et chacune produit un livrable écrit.
1. Fixer le périmètre
Listez ce que l’assistant peut lire, écrire et déclencher. Notez les données auxquelles il accède, les outils qu’il appelle, les utilisateurs qui lui parlent et ce qu’il n’a surtout pas le droit de faire. Ce document sert aussi à décider ce qui est hors test : on n’attaque pas la production d’un fournisseur sans son accord.
2. Construire un modèle de menace
Posez trois questions. Qui pourrait attaquer : un client mécontent, un concurrent, un employé, un contenu piégé trouvé sur le web ? Que voudrait-il obtenir : des données, une action, une capture d’écran embarrassante ? Quel serait l’impact : fuite, fraude, atteinte à l’image, simple gêne ? Un tableau de dix lignes suffit, l’important est de classer les risques pour ne pas tout tester avec la même intensité.
3. Écrire une politique avant d’écrire des attaques
C’est l’étape que l’on saute le plus souvent, et c’est celle qui rend les résultats lisibles. Une politique dit, en phrases simples, ce que l’assistant doit refuser, ce qu’il doit accepter et ce qu’il doit faire dans les cas ambigus. Sans elle, impossible de dire si une réponse est un échec : on discute au cas par cas, et chacun juge selon son humeur.
4. Constituer une batterie d’attaques et l’exécuter
Pour chaque risque du modèle de menace, préparez plusieurs variantes : formulation directe, reformulation, autre langue, jeu de rôle, message découpé en plusieurs tours, instruction cachée dans un document. Exécutez chaque variante plusieurs fois, car un seul passage ne dit rien d’un système non déterministe. Gardez les traces complètes : consigne, contexte, réponse, outils appelés.
Une partie du travail est manuelle, surtout au début : lire de vraies conversations, repérer les manières dont les gens poussent l’assistant, et imiter leur créativité. Une autre partie s’automatise, notamment la génération de variantes et la notation des réponses.
5. Évaluer contre la politique
Chaque réponse est classée : conforme, non conforme, ambiguë. Ce classement peut être fait par une personne, par un autre modèle chargé de juger, ou par les deux. Un modèle juge fait gagner du temps mais se trompe lui aussi : faites relire à la main un échantillon, surtout les cas classés conformes, car les faux négatifs s’y cachent. Le résultat à suivre est un taux de réussite d’attaque par famille, comparé d’une version à l’autre.
Quels outils open source pour automatiser ?
Plusieurs projets open source couvrent tout ou partie de la démarche. Ils servent à illustrer la méthode, pas à la remplacer.
- PyRIT, le cadre de Microsoft pour orchestrer des attaques contre des systèmes d’IA générative.
- garak, un scanner de vulnérabilités pour modèles de langage qui lance des batteries de sondes et rapporte ce qui passe.
- Promptfoo, un outil d’évaluation en ligne de commande, pratique pour décrire des cas de test dans un fichier et les rejouer.
Le choix compte moins que la discipline. Quel que soit l’outil, vérifiez qu’il permet de décrire vos propres cas, d’évaluer contre votre politique et de produire un rapport comparable d’un passage à l’autre. Et rappelez-vous que les outils évoluent vite : regardez l’activité du dépôt et la date de la dernière publication avant de bâtir un processus dessus.
Un outil automatique trouve surtout ce que ses auteurs avaient prévu. Les failles propres à votre contexte, comme un outil interne mal protégé ou un document sensible indexé par erreur, se trouvent en réfléchissant à votre système. Les deux approches se complètent.
Que faire des failles trouvées ?
Une faille découverte n’est utile que si elle est corrigée, puis vérifiée. Le réflexe courant consiste à ajouter une phrase au prompt système (« ne fais jamais X »). C’est rapide, c’est souvent contourné, et cela ne doit jamais être la seule défense.
On classe les corrections par solidité, de la plus fiable à la moins fiable :
- Réduire les droits : si l’assistant n’a pas accès à une donnée ou à un outil, aucune attaque ne peut le lui faire utiliser. C’est la correction la plus efficace.
- Ajouter des contrôles hors du modèle : validation des paramètres avant un appel d’outil, confirmation humaine pour les actions sensibles, filtrage des sorties.
- Séparer les contenus de confiance et les contenus extérieurs, afin qu’un document lu ne puisse pas se faire passer pour une consigne.
- Renforcer les consignes et les exemples du modèle, en dernier, comme une couche de plus et non comme une garantie.
Chaque faille corrigée devient ensuite un cas de test permanent. Intégrez la batterie à votre intégration continue (CI), de façon qu’un changement de modèle, de prompt, de base documentaire ou d’outil déclenche automatiquement les mêmes attaques. Une régression apparaît alors le jour où elle est introduite, pas le jour où un utilisateur la découvre.
Gardez enfin un registre simple : date, version testée, attaque, résultat, correction, responsable. Il sert de mémoire à l’équipe et de preuve en cas d’audit ou de question d’un client.
Par où commencer cette semaine ?
Prenez l’assistant le plus exposé de votre organisation. Écrivez sa politique en une page, listez ses accès, puis préparez vingt attaques réparties sur les familles ci-dessus et jouez-les cinq fois chacune. Vous obtiendrez un premier taux de réussite, des exemples concrets et, très probablement, une ou deux corrections de droits à faire tout de suite.
Le red teaming IA ne se termine jamais : les modèles changent, les usages aussi, et les attaquants s’adaptent. Le mois prochain, votre assistant passera à une nouvelle version. Saurez-vous en une heure si sa résistance a baissé ?
Sources
Questions fréquentes
Qu’est-ce que le red teaming IA ?
C’est la pratique qui consiste à attaquer volontairement un système d’IA, avec l’accord de son propriétaire, pour révéler ses faiblesses avant qu’elles ne soient exploitées. Elle cible le comportement du modèle et de son intégration : fuites de données, contournement des règles, actions non autorisées.
Faut-il une équipe de sécurité pour faire du red teaming IA ?
Non, une petite équipe peut démarrer avec un périmètre écrit, une politique de ce que l’assistant doit refuser, une batterie d’attaques et un rejeu régulier. Une expertise en sécurité aide pour les cas avancés, mais un premier tour utile ne l’exige pas.
Quelle différence entre prompt injection direct et indirect ?
Dans le cas direct, l’utilisateur écrit lui-même la consigne malveillante. Dans le cas indirect, elle est cachée dans un contenu que l’assistant lit, comme un e-mail, une page web ou un document, sans que l’utilisateur ait rien tapé de suspect.
À quelle fréquence faut-il refaire les tests ?
À chaque changement de modèle, de prompt système, de base documentaire ou d’outil, idéalement de façon automatique dans la chaîne d’intégration continue. Un passage complet plus approfondi, avec relecture manuelle, se prévoit en plus à intervalle régulier.
Quels outils open source utiliser pour tester un assistant IA ?
PyRIT (github.com/microsoft/PyRIT), garak et Promptfoo sont des options actives qui couvrent l’orchestration d’attaques, le scan de vulnérabilités et l’évaluation rejouable. Le choix importe moins que la capacité à décrire ses propres cas et à les évaluer contre sa politique.
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
