Définition en une phrase
Evaluación intencional de fallos mediante entradas, escenarios o actores que intentan romper las garantías del sistema.
Définition : une évaluation intentionnelle des défaillances
Les tests adversariaux, souvent appelés red teaming dans le domaine de l’intelligence artificielle, consistent à mettre délibérément un système d’IA à l’épreuve dans des conditions hostiles afin de repérer ses vulnérabilités, ses biais ou ses comportements indésirables. Contrairement aux tests fonctionnels classiques, qui vérifient que le système respecte les spécifications, ils cherchent à découvrir comment un adversaire compétent pourrait le faire échouer, le manipuler ou le tromper.
Il faut distinguer la méthode d’évaluation — le test adversarial — de la propriété recherchée — la robustesse. Le test est une démarche active qui tente de provoquer une défaillance ; la robustesse désigne la capacité du système à résister à ces tentatives. Le red teaming de l’IA peut porter sur la cybersécurité de l’infrastructure qui héberge les modèles comme sur les vulnérabilités propres aux modèles, liées à leur apprentissage et à leur fonctionnement.
Méthode technique et cycle d’évaluation
Un exercice de tests adversariaux suit généralement une séquence structurée, qui commence par la planification et la modélisation des menaces. L’équipe précise les objectifs possibles d’un adversaire, les actifs à protéger et le périmètre autorisé. Elle prépare ensuite des entrées hostiles : prompts élaborés, images modifiées ou séquences de données conçues pour déclencher des défaillances précises.
Les entrées sont soumises au modèle, dans un environnement isolé ou en production si l’évaluation y est explicitement autorisée. Les réponses sont examinées au moyen de méthodes qui peuvent combiner règles lexicales, analyse sémantique et indices de comportement. Les résultats sont documentés, évalués selon leur gravité et associés à des mesures correctives. L’automatisation peut élargir le nombre de scénarios testés, mais l’expertise humaine reste utile pour repérer des voies d’attaque inattendues et juger de leur importance réelle.
Étapes d’un exercice adversarial
Séquence générale pour évaluer un système d’IA au moyen de tests adversariaux.
- 01Modéliser les menaces : déterminer les actifs concernés, les adversaires plausibles et leurs objectifs.
- 02Générer des attaques : préparer des entrées adversariales — prompts, images ou données — à partir de techniques connues ou d’une recherche automatisée.
- 03Exécuter les tests : soumettre les entrées au modèle cible et enregistrer ses réponses.
- 04Détecter et analyser : examiner les réponses à l’aide de critères lexicaux, sémantiques ou comportementaux.
- 05Rendre compte et atténuer : classer les constats par gravité et définir des mesures correctives.
Trois exemples dans des domaines différents
Les scénarios de test dépendent du modèle et de son contexte d’utilisation. Pour les grands modèles de langage (LLM), les évaluateurs peuvent chercher à contourner les consignes de sécurité ou à faire divulguer des informations. Un prompt peut, par exemple, tenter de supplanter les instructions du système. Les tests peuvent également vérifier si le modèle révèle des données sensibles auxquelles il a accès ou qu’il a mémorisées.
En vision par ordinateur, un test peut porter sur des modifications de l’image qui changent la classification d’un objet, parfois sans que ces changements soient faciles à percevoir. Pour un agent d’IA connecté à des outils, l’enjeu peut être de vérifier s’il suit des instructions malveillantes intégrées dans un document qu’il consulte, puis s’il déclenche une action non autorisée. Ces exemples concernent des surfaces d’attaque différentes ; ils ne se réduisent pas à des variantes d’un même test de prompt.
Exemples de vecteurs d’attaque selon le domaine
Comparaison de scénarios de test pour les LLM, les systèmes de vision et les agents d’IA.
| Domaine | Vecteur de test | Objectif de l’évaluation | Exemple de scénario |
|---|---|---|---|
| LLM | Injection de prompt ou tentative de contournement | Vérifier si les consignes de sécurité peuvent être contournées ou si des données sont divulguées | Une conversation en plusieurs tours cherche à amener le modèle à révéler ses instructions système. |
| Vision par ordinateur | Perturbation adversariale de l’image | Déterminer si une modification de l’entrée provoque une classification erronée | Modifier une image pour tester si le système reconnaît mal un panneau de signalisation. |
| Agents d’IA | Injection indirecte ou usage détourné d’outils | Vérifier si l’agent exécute des actions non autorisées après avoir traité un contenu hostile | Un document consulté par l’agent contient des instructions qui lui demandent d’envoyer un courriel. |
Confusions fréquentes et périmètre des tests
Les tests adversariaux sur l’IA ne se confondent pas avec un test d’intrusion classique. Le pentest cherche notamment des failles dans le code, la configuration ou l’infrastructure, telles qu’une erreur de contrôle d’accès ou une injection SQL. Le red teaming de l’IA peut examiner ces mêmes composants, mais s’intéresse aussi aux réactions du modèle face à des entrées hostiles et à son usage des données ou des outils. Une application peut être bien protégée sur le plan de l’infrastructure tout en restant vulnérable à une manipulation de son modèle.
Un autre raccourci consiste à prendre une attaque réussie pour la preuve que le système est globalement et toujours non sécurisé. Le résultat démontre une défaillance dans des conditions précises ; il ne caractérise pas à lui seul toutes les situations possibles. De même, les tests adversariaux sont une méthode d’évaluation, pas une mesure exhaustive de la sécurité ou de la robustesse. La portée de leurs conclusions dépend du périmètre, des scénarios testés et des critères de réussite retenus.
Limites : couverture, reproductibilité et interprétation
L’espace des entrées possibles est trop vaste pour être entièrement exploré. Il est impossible de tester toutes les formulations de prompts, toutes les images modifiées ou toutes les séquences d’actions. La couverture reste donc partielle : un modèle peut réussir les tests effectués et échouer face à une variante qui n’a pas été incluse. Les résultats décrivent les scénarios effectivement évalués, pas l’ensemble des scénarios concevables.
La reproductibilité peut également être difficile, notamment lorsque le modèle produit des réponses variables ou que la génération automatisée d’attaques comporte de l’aléatoire. Pour interpréter un constat, il est utile de conserver les entrées, les sorties, les paramètres et les conditions d’exécution, puis de vérifier si le comportement se reproduit. Enfin, un résultat favorable ne garantit pas la sécurité future : les modèles, leurs intégrations et les méthodes d’attaque peuvent évoluer. Une évaluation adversariale fournit des éléments de preuve délimités, et non une certification générale d’absence de vulnérabilité.