Un assistant doit résumer un contrat. Mais le document contient une instruction cachée lui demandant de transmettre tout le dossier à un tiers. Si l’agent obéit, des données peuvent sortir de l’entreprise sans qu’un serveur ait été piraté. Le red teaming IA sert à provoquer ces défaillances dans un cadre autorisé, puis à vérifier leurs conséquences réelles.
L’exercice dépasse pourtant les attaques informatiques : il teste aussi les contenus dangereux, les biais et la résistance des systèmes aux usages imprévus. Encore faut-il distinguer un texte inquiétant d’une action effectivement réalisée, et ne pas prendre un score automatique pour une garantie de sécurité.
Trois points clés
- Le red teaming IA teste les modèles, les applications et les agents, côté cybersécurité et sûreté.
- Un échec n’est démontré qu’en vérifiant les autorisations, les appels d’outils et leurs effets.
- Les outils automatisés accélèrent les essais, sans remplacer les spécialistes ni les contrôles techniques.
Le red teaming IA va bien au-delà du chatbot
En cybersécurité, une red team simule un adversaire pour éprouver les protections et la détection. Le pentest recherche plutôt des failles techniques dans un périmètre défini : les deux pratiques se complètent, sans être synonymes, explique Fortinet. Appliqué à l’IA, le red teaming examine également des défaillances qui ne supposent aucune intrusion : réponse dangereuse, instruction détournée ou divulgation d’informations.
Microsoft distingue les tests du modèle de ceux de l’application. Un assistant comporte souvent des instructions, une recherche documentaire, des API et des permissions. Un modèle prudent peut donc piloter un agent vulnérable. L’OWASP invite à examiner le système complet, et pas seulement les réponses affichées à l’écran. Le red teaming peut donc concerner aussi bien l’éditeur d’un modèle qu’une entreprise qui l’intègre dans son service client.
Jailbreak, injection de prompt et fuites de données
Le jailbreak tente de contourner les règles de comportement d’un modèle. L’injection de prompt glisse une instruction hostile dans une entrée qu’il doit analyser : message direct, mais aussi page web, e-mail ou document. Dans ce second cas, l’IA risque de prendre une information extérieure pour un ordre légitime. Les agents connectés aux mails et aux fichiers constituent une cible particulièrement sensible.
Les testeurs traquent également les fuites entre comptes, les permissions excessives et les actions interdites. Une IA peut affirmer avoir envoyé un fichier sans l’avoir fait. Inversement, un banal appel d’outil peut produire un effet sérieux. Il faut donc comparer les réponses du modèle avec les traces serveur et les contrôles d’accès. Des protections applicatives peuvent bloquer une opération, même quand le modèle semble accepter la demande.
La sûreté dépasse la cybersécurité. Les campagnes examinent aussi les contenus dangereux, la discrimination et les réponses trompeuses. IBM Research insiste sur la diversité des profils capables de révéler des angles morts. La red team n’incarne pas toujours un pirate : elle cherche toutes les situations où le système s’écarte d’un comportement acceptable. Un refus excessif face à une demande médicale anodine ou une différence de traitement selon la langue peuvent aussi révéler un problème de sûreté.
Les étapes pour tester une IA sans prendre de risques
Une campagne utile part des conséquences à éviter, pas d’un catalogue de prompts spectaculaires. Voici un déroulement applicable à un assistant connecté à des outils métier.
Définir la cible. L’équipe précise le résultat interdit : divulguer un dossier, déclencher un paiement ou produire une réponse dangereuse. Elle fixe le périmètre, les autorisations, les données fictives et les conditions d’arrêt des essais. Cette préparation évite de transformer un audit en incident réel.
Cartographier les accès. Prompts système, bases RAG, connecteurs, comptes techniques et droits d’écriture doivent être recensés. MITRE ATLAS aide à identifier des techniques, sans remplacer cette cartographie. Les frontières de confiance entre utilisateur, documents consultés et services externes sont particulièrement importantes.
De l’attaque simulée au correctif
Construire les scénarios. Chaque test associe une entrée hostile, un résultat interdit et un critère de réussite. Il doit être répété : le comportement d’un modèle peut varier d’un essai à l’autre. Les langues et les formats de documents doivent aussi varier pour éviter un test trop étroit.
Vérifier les effets. En préproduction, des outils simulés permettent de distinguer une réponse, un appel tenté et une opération réellement exécutée. Les journaux constituent la preuve, non la formulation du chatbot.
Corriger et rejouer. Permissions minimales, séparation des données, validation humaine et contrôles côté serveur limitent les dégâts. Chaque scénario confirmé devient un test de régression après les mises à jour. Le rapport doit désigner un responsable du correctif et préciser comment vérifier son efficacité.
Infographie générée par IA / LeBigData.fr.
Comment un contrat piégé peut détourner un agent
Prenons un exemple fictif. Une entreprise demande à un assistant RAG de résumer un contrat. Le fichier contient une fausse note administrative ordonnant d’expédier l’intégralité du dossier vers un service externe. Si l’agent suit cette note, une information provenant d’un document acquiert une autorité qu’elle ne devrait jamais avoir.
Le test s’effectue dans un environnement isolé, avec un faux connecteur d’envoi. Il distingue trois niveaux : le modèle propose la transmission, il appelle l’outil, puis le serveur autorise ou non l’opération. Seul le dernier niveau démontre un envoi effectif. La défense doit donc contrôler les destinataires, les droits et les confirmations, plutôt que s’en remettre à une simple instruction de prudence donnée au modèle. Si le compte technique n’a aucun droit d’envoi, l’erreur de raisonnement de l’assistant n’aboutit pas à une fuite. Cet exemple montre pourquoi les permissions réelles comptent autant que les consignes de sécurité.
PyRIT et Foundry automatisent les tests, pas le jugement
PyRIT, développé par Microsoft, orchestre des essais adversariaux, y compris sur plusieurs échanges. L’AI Red Teaming Agent de Microsoft Foundry permet de générer des scénarios et d’évaluer leurs résultats. Sa documentation décrit notamment les injections indirectes et les actions non autorisées. Certaines évaluations restent toutefois limitées à des configurations précises, à un seul échange ou à l’anglais : leur couverture n’est pas universelle.
La documentation OpenAI évoque également Promptfoo et distingue les tests adversariaux des évaluations ordinaires de qualité. Son offre de red teaming gérée ne concerne pas tous les utilisateurs. Quant à Check Point et F5, leurs présentations décrivent des solutions commerciales, non des comparatifs indépendants. Un outil doit être évalué sur son aptitude à reproduire des erreurs utiles aux équipes, pas sur le seul volume de prompts générés.
Une automatisation peut manquer une attaque nouvelle ou confondre une formulation alarmante avec une fuite réelle. L’analyse humaine reste nécessaire pour qualifier les preuves, la gravité et les effets métier. Cette conférence francophone approfondit les failles des applications utilisant les LLM.
Cisco et Claude Mythos misent sur des attaques adaptatives
Le 9 novembre 2026, Cisco a annoncé vouloir intégrer Claude Mythos d’Anthropic à sa plateforme AI Defense. Le but : adapter les attaques simulées aux réponses d’une application ou d’un agent. L’annonce concerne d’abord des entreprises sélectionnées ; elle ne signifie ni accès public au modèle ni disponibilité générale de la fonction.
Cisco évoque des cibles autorisées, des opérateurs identifiés et une journalisation. Ces garde-fous sont essentiels lorsque les tests deviennent autonomes. Mais aucune annonce commerciale ne dispense de vérifier, sur le terrain, si la méthode découvre davantage de risques et réduit effectivement leur gravité. Une campagne plus agressive peut augmenter le nombre de problèmes signalés sans améliorer la précision du diagnostic. Les annonces de performances réclament donc des résultats reproductibles et des scénarios clairement décrits.
Un bon score ne signifie pas qu’une IA est sûre
Un taux de réussite des attaques dépend des scénarios choisis, du nombre d’essais et de la définition du succès. Contourner un refus, tenter un appel d’API et transmettre réellement des données ne constituent pas des échecs équivalents. Un rapport sérieux documente la reproductibilité, les traces, la portée des accès et les faux positifs. Une attaque réussie une fois sur dix mérite toujours une analyse. Dans un outil de paiement ou de santé, sa rareté ne suffit pas à rendre son impact acceptable. Il faut aussi hiérarchiser la gravité et la facilité de reproduction.
L’évaluation doit aussi mesurer les dommages collatéraux : un filtrage trop strict peut bloquer des demandes légitimes. Le red teaming complète les audits de code, les tests de qualité et les contrôles d’accès ; il ne les remplace pas. Akamai recommande de répéter les campagnes, car le comportement d’un système évolue avec ses composants. Une version du modèle plus robuste face aux jailbreaks peut tout de même exposer de nouveaux risques lors d’une intégration avec une API.
L’AI Act encadre certains tests, mais la vigilance concerne tous les agents
L’article 55 de l’AI Act impose aux fournisseurs de modèles d’IA à usage général présentant un risque systémique des évaluations comprenant des tests adversariaux documentés. Cette obligation particulière ne s’applique pas à toute entreprise utilisant un chatbot. Les dispositions relatives aux modèles d’IA à usage général s’appliquent depuis le 2 août 2025, selon le calendrier prévu par le règlement. Le statut du fournisseur, la qualification du modèle et les obligations qui lui sont effectivement applicables doivent donc être distingués. Les exigences générales de cybersécurité ou de gestion des risques peuvent suivre d’autres dispositions.
Pour les entreprises qui déploient des agents, l’intérêt dépasse néanmoins la conformité. Un nouveau connecteur, des droits étendus ou un changement de modèle peuvent rouvrir une faille. Il faut tester après ces évolutions, conserver les preuves et vérifier l’efficacité des correctifs. Le suivi gagne à inclure les attaques bloquées, les tentatives partiellement réussies et les autorisations retirées. Un tableau de bord réduit à un pourcentage masquerait ces distinctions. La vraie question n’est pas seulement ce que l’IA accepte de dire, mais ce qu’elle peut faire lorsqu’elle se trompe.
- Partager l'article :
