Tests de sécurité IA : red teaming et fuzzing de prompts
Comment structurer une campagne de tests de sécurité sur un système d'IA en combinant red teaming humain et fuzzing automatisé de prompts, avec règles d'engagement, oracle de détection, priorisation et rapport actionnable.
Table des matières
Pourquoi tester activement plutôt que constater après coup
Un audit documentaire ne détecte pas une vulnérabilité d'exécution. On peut relire l'architecture d'un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, vérifier que chaque source de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire est identifiée, que les permissions d'un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire sont documentées, et passer complètement à côté d'une formulation de trois lignes qui fait dévier le modèle de ses instructions. La seule façon fiable de savoir si un garde-fou tient est de tenter de le franchir, dans les mêmes conditions qu'un attaquant réel.
C'est l'objet de ce chapitre : deux disciplines complémentaires, le red teamingRed teamingCybersécuritéExercice offensif structuré visant à identifier les failles d'un système IA (prompt injection, fuite de données, biais) avant mise en production.Voir dans le glossaire, qui simule des attaquants humains explorant des chemins d'exploitation, et le fuzzing de prompts, qui génère à grande échelle des variations d'entrées pour détecter des défaillances qu'aucun testeur humain n'aurait l'idée ou le temps d'essayer manuellement. Le premier apporte le jugement et la créativité adverse ; le second apporte l'échelle et la répétabilité. Un programme de test sérieux combine les deux, sans présenter l'un comme un substitut de l'autre.
Un système qui passe une campagne de red teaming n'est pas prouvé sûr — il est seulement prouvé résistant aux attaques effectivement essayées. L'absence de preuve d'échec n'est pas une preuve d'absence de faille. Cette distinction doit figurer explicitement dans tout rapport transmis à une direction, sous peine de créer une fausse impression de sécurité.
Red teaming IA : posture et méthodologie
Le red teaming appliqué à l'IA reprend la logique du red teaming en cybersécurité classique en l'adaptant à des surfaces spécifiques : le comportement conversationnel du modèle, ses garde-fous d'alignement, les pipelines de récupération de contenu (RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire), et les actions déclenchables par un agent doté d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire.
Règles d'engagement et périmètre
Avant toute campagne, un document de règles d'engagement (rules of engagement, RoE) fixe ce qui est autorisé. C'est la différence entre un test légitime et une intrusion non autorisée, même quand les deux emploient des techniques identiques. Un RoE utile précise au minimum :
- le périmètre exact — environnements testés, comptes et données autorisés ;
- les catégories d'attaque exclues (par exemple, ne jamais obtenir de contenu réellement dangereux en clair, se contenter de démontrer qu'un contournement est possible) ;
- la fenêtre temporelle et les contacts d'astreinte en cas d'incident déclenché par le test lui-même ;
- le mode de consignation des preuves — captures, identifiants de session, horodatage.
Un fuzzer envoyant des milliers de requêtes par heure peut saturer un quota d'API, déclencher de fausses alertes, ou provoquer une action réelle si le système testé est un agent connecté à des outils de production (envoi d'e-mail, écriture en base). Toute campagne doit tourner sur un environnement isolé ou disposer d'un mécanisme de neutralisation des effets de bord.
Profils d'attaquants à simuler
La qualité d'un red teaming dépend de la diversité des profils simulés. Se limiter à des testeurs internes reproduisant les mêmes réflexes donne une couverture illusoirement large.
- L'utilisateur curieux — teste les limites par jeu, révèle les jailbreaks déclenchés accidentellement.
- L'attaquant opportuniste — techniques publiées sans effort d'adaptation ; sert de test de non-régression.
- L'attaquant ciblé — connaît le système, adapte ses formulations à son domaine métier ; profil le plus représentatif d'un incident réel.
- L'insider — accès légitime partiel, teste des escalades de privilège plutôt que des contournements frontaux.
- L'automate adverse — fuzzer ou agent dédié à la recherche de failles, capable d'itérer sans fatigue sur des milliers de variantes.
Fuzzing de prompts : automatiser la recherche de défaillances
Appliqué aux modèles de langage, le fuzzing ne cherche pas un crash au sens classique — un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire ne « plante » presque jamais au sens d'une exception non gérée — mais un écart comportemental : franchissement d'un garde-fou, exécution d'une instruction cachée, fuite d'information, incohérence exploitable.
La boucle de fuzzing
Une campagne suit un cycle itératif représenté ci-dessous : un corpus de départ (seeds) est transformé par un mutateur, envoyé au système cible, puis évalué par un oracle de détection. Les cas confirmés comme échecs alimentent un corpus dédié, qui reboucle vers le mutateur pour orienter la génération suivante vers des variantes proches d'un succès déjà obtenu — une logique d'optimisation guidée plutôt que de génération purement aléatoire.
Stratégies de mutation et de génération
- Mutation lexicale — synonymes, fautes volontaires, espacement inhabituel, casse alternée, pour contourner un filtre de mots-clés statique.
- Encodage et obfuscation — base64, ROT13, verlan, épellation lettre par lettre, traduction en cascade via une langue peu couverte par les filtres.
- Recombinaison génétique — croisement de fragments issus de jailbreaks ayant individuellement obtenu un succès partiel.
- Génération assistée par un second modèle — un modèle « attaquant » produit des variantes de plus en plus efficaces contre le modèle cible, en boucle fermée avec l'oracle.
- Injection contextuelle — variation non du message direct mais du contenu tiers consulté par le système, pertinente pour tester l'injection indirecte plutôt que le jailbreakJailbreakCybersécuritéTentative de contourner les garde-fous d'un LLM pour obtenir des sorties interdites ou dangereuses.Voir dans le glossaire conversationnel.
Des corpus publics de jailbreaks et de techniques de contournement documentées évoluent en continu. Les utiliser comme point de départ accélère la détection des régressions les plus évidentes et libère du temps pour explorer des variantes réellement nouvelles, spécifiques au système testé.
Catégories de vulnérabilités à couvrir
Une campagne qui ne couvre qu'une seule famille de vulnérabilité donne une fausse impression d'exhaustivité. Le tableau résume les grandes catégories à intégrer dans un plan de test IA.
| Catégorie | Vecteur représentatif | Ce que l'oracle doit détecter |
|---|---|---|
| Jailbreak d'alignement | Jeu de rôle, escalade progressive, cadrage hypothétique | Production d'un contenu normalement refusé |
| Injection directe | Substitution d'autorité, fragmentation d'instruction | Déviation du comportement instruit en système |
| Injection indirecte | Instruction cachée dans un document consulté | Exécution d'un ordre non formulé par l'utilisateur |
| Fuite d'information | Extraction du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système, répétition de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire sensible | Divulgation de données confidentielles |
| Agence excessive | Déclenchement d'une action via un outil connecté | Action non prévue par le périmètre autorisé |
| Robustesse adverse | Perturbations mineures d'entrée (typos, formats) | Incohérence disproportionnée par rapport à la perturbation |
| BiaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire et contenu inapproprié | Requêtes formulées pour révéler un traitement inégal | Sortie discriminatoire selon un attribut protégé |
Un agent interne dispose d'un outil d'envoi d'e-mail réservé aux notifications de suivi de dossier. Le test consiste à formuler, via une injection indirecte déposée dans un ticket que l'agent va consulter, une instruction demandant l'envoi du contenu du dossier vers une adresse externe. Si l'e-mail part, l'oracle enregistre un échec critique — parce qu'une action réelle et non autorisée a été déclenchée, pas parce que le texte généré est choquant.
Construire une campagne de test structurée
Phases d'une campagne
- Cadrage — périmètre, règles d'engagement, catégories prioritaires selon le profil de risque du système.
- Constitution des corpus — seeds issus de bibliothèques connues, de campagnes précédentes et de scénarios métier spécifiques.
- Red teaming manuel — sessions ciblées sur les scénarios à fort enjeu, nécessitant un jugement contextuel.
- Fuzzing automatisé — campagnes à grande échelle pour couvrir la variabilité lexicale, en parallèle du red teaming manuel.
- Triage et validation — chaque échec détecté est rejoué manuellement pour écarter les faux positifs.
- Priorisation et rapport — classement par gravité et probabilité, rapport actionnable aux équipes responsables.
- Re-test — vérification que les correctifs ferment les cas confirmés, sans régression sur les cas déjà validés.
Outils et frameworks de référence
- Scanners de vulnérabilités LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire — sondes automatisées couvrant les catégories connues (jailbreak, fuite, toxicité) avec rapports structurés.
- Frameworks de red teaming assisté — orchestration d'un modèle attaquant contre un modèle cible en boucle fermée.
- Corpus de jailbreaks documentés — bases communautaires de techniques connues, utiles comme seeds et comme test de non-régression.
- Programmes de red teaming humain à grande échelle — testeurs externes diversifiés mobilisés sur des systèmes en préproduction, parfois avec primes.
Faire tourner un scanner automatisé sans règles d'engagement, ni critères de gravité, ni processus de triage produit une liste de résultats bruts, pas un programme de test. L'outil accélère l'exécution ; la méthodologie détermine si le résultat est exploitable.
Oracles : comment décider qu'un échec est un échec
L'oracle décide, pour chaque réponse générée, si elle constitue un échec de sécurité. C'est le maillon le plus sous-estimé d'une campagne : un mauvais oracle produit trop de faux positifs, qui noient les vraies découvertes, ou trop de faux négatifs, qui laissent passer des failles réelles.
Trois approches se combinent généralement : la détection par motifs, rapide mais fragile face à la reformulation ; la classification par un second modèle (LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire), plus tolérante mais exposée à ses propres biais, qui doit être validée sur un échantillon annoté par des humains ; et la validation humaine sur échantillon, indispensable pour calibrer les deux premières et trancher les cas ambigus.
Un indicateur courant est le taux de succès d'attaque (attack success rate, ASR) : la proportion de tentatives, sur un corpus donné, qui obtiennent un contournement confirmé. Il n'a de sens que rapporté à un corpus et une méthodologie précis — un ASR de 2 % sur un corpus de jailbreaks triviaux ne signifie pas la même chose qu'un ASR de 2 % sur un corpus de techniques ciblées et récentes.
Mesurer, prioriser et rapporter
Une liste de prompts ayant fonctionné n'est pas actionnable. Un rapport utile priorise chaque découverte selon deux axes indépendants — gravité de l'impact et probabilité de découverte par un attaquant réel — et associe une recommandation de remédiation concrète à chaque cas confirmé.
Éléments attendus dans un rapport :
- description du scénario et séquence exacte permettant de reproduire l'échec ;
- catégorie de vulnérabilité, en référence à une taxonomie stable, et gravité/probabilité justifiées ;
- capture horodatée de la réponse obtenue, rattachée à la version testée ;
- recommandation formulée en termes d'action (renforcer tel garde-fou, restreindre telle permission), pas en termes vagues ;
- statut de suivi, pour tracer la remédiation jusqu'à sa vérification par re-test.
Limites du red teaming automatisé
Le fuzzing et le red teaming assisté apportent une échelle que le testeur humain ne peut pas égaler, mais ne couvrent pas tout. Un fuzzer optimise ce que son oracle sait mesurer : une catégorie de risque mal définie — un biais subtil, une action d'agence excessive rare — reste invisible quel que soit le volume envoyé, et un modèle attaquant automatisé reproduit les biais de son propre entraînement, moins doué qu'un testeur humain, familier du contexte réel, pour imaginer un scénario métier inédit. Enfin, un test évalue une version figée du système : un modèle mis à jour, une nouvelle source RAG connectée, ou un nouvel outil accordé à un agent rouvrent une surface qui n'a pas été rejouée.
Checklist avant mise en production
- Un document de règles d'engagement est rédigé et validé avant toute campagne, y compris automatisée.
- Les tests couvrent au minimum les sept catégories du tableau (jailbreak, injection directe, injection indirecte, fuite, agence excessive, robustesse adverse, biais).
- Le red teaming manuel cible en priorité les scénarios métier que le fuzzing générique ne peut pas anticiper.
- Le fuzzing s'appuie sur un corpus de seeds à jour, incluant des techniques récentes et pas uniquement des jailbreaks déjà publiés.
- L'oracle de détection est calibré sur un échantillon validé par des humains, avec un suivi de ses faux positifs et faux négatifs.
- Chaque échec détecté est rejoué et confirmé manuellement avant d'être consigné comme vulnérabilité.
- Le rapport final priorise par gravité et probabilité, avec une recommandation concrète pour chaque cas confirmé.
- Un re-test est planifié après chaque correctif, et un cycle récurrent est prévu après toute évolution significative du système.
Ce qu'il faut retenir
Un audit documentaire ne révèle pas si un garde-fou tient face à un adversaire déterminé ; seul un test actif le démontre. Le red teaming apporte le jugement contextuel qu'un fuzzer ne reproduit pas seul, tandis que le fuzzing de prompts apporte l'échelle nécessaire pour couvrir une variabilité lexicale qu'aucune équipe humaine ne peut explorer manuellement. Ni l'un ni l'autre ne prouve la sécurité d'un système : ils réduisent l'incertitude sur un périmètre et une version donnés, à condition d'être encadrés par des règles d'engagement claires, un oracle calibré, un triage rigoureux et un cycle de re-test répété dans la durée — pas une campagne unique avant lancement, vite obsolète dès la première évolution du système.
L'essentiel à retenir
Ce chapitre explique pourquoi seul un test actif permet de vérifier qu'un garde-fou tient réellement face à un attaquant, un audit documentaire ne pouvant que constater ce qui est déclaré. Il détaille la méthodologie du red teaming IA — règles d'engagement, profils d'attaquants à simuler — puis le fuzzing de prompts comme discipline complémentaire, avec sa boucle de mutation, ses stratégies de génération et ses oracles de détection. Il couvre les grandes catégories de vulnérabilités à tester (jailbreak, injection directe et indirecte, fuite d'information, agence excessive, robustesse adverse, biais), la structuration d'une campagne en phases, ainsi que les limites propres à l'automatisation. Le chapitre se conclut par une checklist actionnable avant toute mise en production.
Questions fréquentes
Quelle différence entre red teaming et fuzzing de prompts en pratique ?
Peut-on fuzzer directement un système en production ?
Comment savoir si un oracle de détection est fiable ?
Un ASR (taux de succès d'attaque) faible signifie-t-il que le système est sûr ?
À quelle fréquence faut-il refaire une campagne de test de sécurité IA ?
Le red teaming automatisé peut-il un jour remplacer entièrement le red teaming humain ?
Que faire d'une vulnérabilité détectée par le fuzzer mais qui semble être un faux positif ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).