Livrer une application LLM signifie livrer un système dont les modes de défaillance ne sont pas des exceptions ou des stack traces mais des sorties — un chatbot qui fuite son prompt système, un agent qu'on peut convaincre d'appeler un outil qu'il ne devrait pas, un assistant d'assistance qui invente confiante une politique de remboursement. Aucun de ces éléments ne lève une erreur. Le test traditionnel, qui affirme qu'une fonction retourne une valeur attendue, ne peut pas exprimer la plupart d'entre eux. La discipline qui a émergé pour combler ce fossé est le red teaming LLM : attaquer délibérément votre propre modèle et application pour trouver les entrées qui produisent un comportement inacceptable, avant quelqu'un d'autre.
En 2026, cela s'est transformé d'expériences de prompt ad hoc en un paysage d'outils avec des couches distinctes. Ce guide cartographie ce paysage — garak et PyRIT au niveau du modèle, DeepTeam et promptfoo au niveau de l'application, Agentic Security pour le fuzzing black-box, et Giskard et Inspect pour le scan et l'évaluation rigoureuse. Le fil directeur est que ces outils ne sont pas en concurrence : ils attrapent différentes classes de défaillances, et exécuter un seul laisse des lacunes prévisibles.
Ce que vous testez réellement
Avant les outils, il aide de nommer les classes de défaillance, parce qu'elles exigent différents tests. Les jailbreaks et injections de prompt sont les gros titres : faire ignorer ses instructions au modèle, soit par manipulation directe (« ignore les instructions précédentes »), soit indirectement via le contenu qu'il récupère — un document empoisonné qui porte des instructions que le modèle suit ensuite. L'injection indirecte est la variante la plus grave dans les systèmes RAG et agentiques, parce que l'attaquant ne touche jamais la boîte de prompt.
La fuite de données couvre l'extraction du prompt système, de la PII que le modèle a vu en contexte, ou de données d'entraînement. L'agentivité excessive est la classe de défaillance qui devient la plus dangereuse à mesure que les agents gagnent des outils : le modèle effectuant une action qu'il aurait dû refuser, ou enchaînant des outils d'une manière qui dépasse son autorité prévue. Le contenu nuisible est une conformité directe aux demandes que l'application devrait refuser. Et l'hallucination — la fabrication confiante — est souvent le risque commercial de la plus haute fréquence même si elle est la moins dramatique.
Chacun de ces éléments vit à une couche différente. La susceptibilité aux jailbreaks est largement une propriété du modèle. L'agentivité excessive et la fuite de prompt sont des propriétés de l'application — son prompt système, ses outils, ses garde-fous. L'hallucination est une propriété du pipeline, en particulier la qualité de la récupération. Ce regroupement en couches est exactement pourquoi les outils se divisent comme ils le font.
Scanners au niveau du modèle : garak et PyRIT
garak (de NVIDIA) est le plus proche d'nmap pour les LLM. Il exécute une grande bibliothèque de sondes contre un modèle — familles de jailbreak, injection de prompt, toxicité, fuite de données, attaques de codage — et rapporte lesquelles ont réussi. Vous le pointez sur un modèle (un modèle HuggingFace, un endpoint OpenAI, un serveur local) et il travaille à travers son catalogue. Sa valeur est l'étendue et le faible effort : vous apprenez rapidement quelles familles d'attaques connues votre modèle est susceptible de réussir, sans concevoir quoi que ce soit vous-même.
PyRIT (de Microsoft) cible un problème plus difficile : les attaques multi-turn et multi-modal. De nombreux vrais jailbreaks ne fonctionnent pas en un seul message ; ils fonctionnent en établissant le contexte sur plusieurs tours et en escaladant progressivement. PyRIT fournit l'orchestration pour cela — des stratégies d'attaque comme crescendo (escalade lente) et TAP (arbre d'attaques avec élagage) qui s'adaptent en fonction des réponses du modèle. C'est plus un SDK qu'un scanner : vous composez des orchestrateurs, des cibles, des convertisseurs, et des scoreurs. Cela rend plus de travail pour commencer et plus puissant pour la recherche dans les attaques qu'une simple sonde.
La limitation partagée est que les deux testent principalement le modèle, et non votre application. Un modèle qui résiste aux sondes de garak en isolation peut toujours être trivalement compromis à l'intérieur de votre application, parce que votre prompt système, votre récupération, et vos outils créent une surface d'attaque que le scan au niveau du modèle n'a jamais vus.
Suites au niveau de l'application : DeepTeam et promptfoo
C'est là que DeepTeam et promptfoo s'ajustent. Les deux testent votre application tel que déployée, enrobant ce que votre app est réellement — prompt, récupération, outils, garde-fous — et attaquant cet assemblage entier.
DeepTeam, de l'équipe DeepEval, exprime le red teaming en Python : vous fournissez un model_callback qui appelle votre application, déclarez lesquelles vulnérabilités sonder (fuite de PII, agentivité excessive, biais, fuite de prompt) et lesquelles attaques utiliser, et il génère et exécute les cas adverses. Ses améliorations d'attaque sont la partie intéressante — la même attaque de base réécrite comme base64, dans une autre langue, comme jeu de rôle, ou escaladée sur plusieurs tours, c'est comment les vrais attaquants évitent les filtres naïfs. Parce que c'est du code, c'est déposé dans une suite de test et s'exécute en CI.
promptfoo vient de l'évaluation : c'est une CLI conduite par config pour tester les sorties LLM qui a grandi en une capacité de red teaming substantielle, générant automatiquement les prompts adverses sur des dizaines de plugins d'attaque et mappant les découvertes aux cadres de conformité. Sa force est l'intégration CI et le fait que le même outil couvre à la fois les évals de qualité et les tests de sécurité, donc un seul harnais sert les deux objectifs.
Pour la plupart des équipes expédiant un produit LLM, cette couche est plus importante que la couche du modèle, parce qu'elle teste la chose que vous avez réellement déployée. Le problème est qu'elle nécessite que vous définissiez ce que « inacceptable » signifie pour votre application — les outils génèrent les attaques, mais vous fournissez le jugement sur lesquelles les sorties sont des défaillances.
Approches black-box et scanning
Deux autres formes valent le coup de connaître. Agentic Security traite votre endpoint comme une boîte noire et la teste agentiquement — générer des sondes, observer les réponses, s'adapter — avec l'ajout utile du test de stress API. Cette dernière partie est sous-estimée : une part significative des déploiements LLM échouent sur les limites de débit, l'épuisement des tokens, et l'abus de ressources avant d'échouer sur la sécurité du contenu, et la plupart des outils de red teaming ignorent cela entièrement.
Giskard inverse le flux de travail habituel. Au lieu de vous demander de spécifier ce qu'il faut tester, il scanne le modèle — en utilisant votre description de ce que l'application fait pour générer des sondes pertinentes au domaine — et produit un rapport des vulnérabilités détectées, qu'il peut ensuite convertir en une suite de test réutilisable. Ce modèle scan-puis-testifier est précieux exactement parce que la partie la plus difficile du red teaming est de savoir ce qu'il faut chercher. Giskard trouve les problèmes que vous n'aviez pas pensé à tester, puis les verrouille comme tests de régression.
Enfin, Inspect du UK AI Safety Institute se tient légèrement à part : c'est un framework rigoureux d'évaluation plutôt qu'un outil d'attaque, mais sa structure (ensembles de données, solutionneurs, scoreurs) et son excellent visionneuse de transcript en font le bon choix quand vous avez besoin de mesure défendable et reproductible — incluant du comportement agentique — plutôt qu'une liste de vulnérabilités.
Construire une pratique en couches
La conclusion pratique est que ces outils se composent. Une pratique raisonnable en 2026 ressemble à ceci.
Quand vous sélectionnez ou mettez à niveau un modèle de base, exécutez un scanner au niveau du modèle — garak pour l'étendue, PyRIT si la robustesse multi-turn est importante pour votre profil de risque. Cela informe le choix du modèle et vous dit ce que la fondation résiste par elle-même.
Pendant le développement, exécutez un outil de style scan comme Giskard contre votre application réelle pour découvrir les classes de défaillance que vous n'aviez pas anticipées, et convertir ses découvertes en tests.
En CI, à chaque changement de prompt, modèle, ou outil, exécutez une suite au niveau de l'application — DeepTeam ou promptfoo — comme portail. C'est l'automatisation de plus haut rendement, parce que les prompts et les définitions d'outils sont la surface de contrôle d'une application LLM et ils changent constamment. Une édition de prompt qui semble inoffensive peut supprimer la phrase qui empêchait un jailbreak.
Avant la sortie, ajoutez le fuzzing black-box contre l'endpoint déployé, incluant le test de stress, pour attraper les problèmes au niveau du déploiement que les tests au niveau du code manquent.
Et gardez les humains dedans. Chaque outil automatisé teste les familles d'attaques connues. Les attaques nouvelles — celles spécifiques à votre domaine, vos données, et vos outils — viennent d'une personne qui comprend la logique métier en pensant adversairement. L'automatisation élève le sol ; elle ne remplace pas le plafond.
Injection indirecte : l'attaque qui casse le modèle
Une classe d'attaque mérite un traitement séparé parce qu'elle défait l'intuition avec laquelle la plupart des équipes commencent. L'injection de prompt directe — un utilisateur tapant « ignore tes instructions » — est ce que tout le monde teste d'abord, et c'est la moitié la plus facile. L'injection de prompt indirecte c'est quand les instructions malveillantes arrivent via le contenu que le système récupère : un document dans votre base de connaissances, une page web que l'agent parcourt, un email qu'il résume, un commentaire de code qu'il lit. L'attaquant n'interagit jamais avec votre boîte de prompt du tout.
Cela est énormément important pour les systèmes RAG et les agents, parce que toute leur proposition de valeur est la consommation de contenu externe. Un assistant d'assistance qui répond à partir de votre documentation va suivre fidèlement les instructions intégrées dans un document si quelqu'un peut obtenir un document dans le corpus — via un wiki public, un ticket soumis par le client, ou une page grattée. Un agent qui lit un problème GitHub peut être instruit par ce problème. La limite de confiance que les gens imaginent (« les utilisateurs ne sont pas de confiance, nos données le sont ») ne tient pas une fois qu'une partie du corpus est influençable.
Tester ceci est plus difficile que de tester l'injection directe, parce qu'il nécessite de simuler le contenu empoisonné, pas les prompts empoisonnés — vous avez besoin de placer du texte adversaire où la récupération le trouvera et de vérifier que le modèle ne l'agit pas sur. Les outils au niveau de l'application gèrent cela mieux que les scanners au niveau du modèle, depuis le pipeline de récupération fait partie de ce qu'ils exercent, mais cela nécessite souvent que vous construisiez le scénario délibérément.
Les atténuations sont architecturales plutôt que basées sur des prompts. Traiter tout le contenu récupéré comme une entrée non approuvée, de la même façon que vous traitez l'entrée utilisateur. Ne pas laisser le texte récupéré atteindre une position où il peut être interprété comme des instructions si vous pouvez l'éviter structurellement. Contraindre quels outils un agent peut appeler en traitant le contenu non approuvé, et exiger la confirmation pour les actions conséquentes. Et garder la provenance : savoir quel document a produit une mauvaise réponse c'est ce qui transforme un incident en correction.
Ce que le red teaming ne fixe pas
Une mise en garde qui vaut la peine de déclarer clairement : trouver une vulnérabilité n'est pas la même que la fixer, et les vulnérabilités LLM ne sont fréquemment pas entièrement fixables. Vous ne pouvez pas corriger un modèle de la façon que vous corrigez un débordement de buffer. Les réponses réalistes sont l'atténuation plutôt que l'élimination : des prompts système plus serrés, des garde-fous d'entrée et de sortie comme LLM Guard, des permissions d'outils contraintes, une approbation humaine pour les actions conséquentes, et le monitoring du comportement anormal.
Cela change ce qu'un rapport de red team signifie. Dans la sécurité traditionnelle, une découverte implique une correction. Dans la sécurité LLM, une découverte implique souvent une décision de risque : cette attaque réussit à un certain taux, voici l'atténuation, voici le risque résiduel, est-ce acceptable pour ce cas d'usage ? Les équipes qui s'attendent à ce que le red teaming produise un bilan de santé propre seront perpétuellement déçues. Les équipes qui l'utilisent pour quantifier et consciemment accepter le risque obtiennent une valeur réelle.
Le corollaire est que l'architecture bat l'ingénierie de prompt pour les défaillances les plus importantes. Un agent qui ne peut pas être trompé en transférant de l'argent parce qu'il structurellement n'a pas cette permission est plus sûr que celui qui compte sur le modèle pour refuser. L'agentivité excessive s'adresse mieux en donnant moins d'agentivité. Le résultat le plus utile du red teaming est souvent la réalisation qu'une capacité n'aurait pas dû être exposée en premier lieu.
Le message clé
Le red teaming LLM est devenu une vraie discipline parce que les défaillances LLM sont des sorties plutôt que des erreurs, et le test ordinaire ne peut pas les exprimer. La division des outils en 2026 par couche, et cette division est la clé pour bien l'utiliser : garak et PyRIT testent le modèle, DeepTeam et promptfoo attaquent l'application que vous avez réellement déployée, Agentic Security teste l'endpoint incluant ses limites de ressources, et Giskard découvre les problèmes que vous ne saviez pas chercher. Exécutez plus d'un, contrôlez CI sur la couche de l'application où les prompts changent le plus, gardez la pensée adversaire humaine en boucle, et traitez les découvertes comme des décisions de risque plutôt que comme des bugs en attente d'une correctif — puis corrigez ce que vous pouvez dans l'architecture plutôt que dans le prompt.
Références et ressources
Outils
Contexte et analyse
- Best LLM Vulnerability Scanners 2026: Garak, PyRIT, Promptfoo
- LLM Red Teaming Guide 2026: Tools, Attacks & Methodology — AppSec Santa
- LLM Red Teaming Tools Compared — QAwerk
- awesome-ai-security-tools
Feuilles de triche 1337skills connexes