Red teaming multimodal : tester un modèle vision-langage avant production

Réponse en bref

Un modèle vision-langage ne doit pas être validé uniquement sur sa précision moyenne. Une image peut contenir une instruction cachée, une donnée personnelle, un stéréotype ou un indice de fraude que le texte seul ne révèle pas. Le red teaming multimodal consiste à construire des scénarios adverses réalistes, à les exécuter de façon contrôlée et à transformer chaque résultat en preuve et en décision.

Le protocole recommandé combine cinq éléments : un modèle de menace lié au cas d'usage, un jeu d'images versionné, des tests automatiques reproductibles, des experts capables d'interpréter les dommages et une règle d'escalade. Pour certaines équipes, une campagne ciblée suffit avant une mise à jour. Pour d'autres, un suivi continu est nécessaire car les filtres, les modèles et les sources d'images évoluent.

Pourquoi le multimodal change le risque

Une application texte reçoit généralement un prompt. Une application vision-langage reçoit un prompt, des pixels et souvent des métadonnées ou des documents. Le système peut extraire du texte d'une facture, interpréter un graphique, lire un badge ou suivre une consigne inscrite dans une capture d'écran. Chaque étape élargit la surface d'attaque.

Anthropic décrit le red teaming multimodal comme un test de conversations image plus texte, avec des cas de fraude, de sécurité des enfants, d'extrémisme et d'autres abus (Model Card Claude 3). Leur retour d'expérience souligne aussi les erreurs de perception d'image et la nécessité d'un red teaming avant déploiement (Challenges in Red Teaming AI Systems). Le NIST TEVV-Athlon inclut explicitement les modèles multimodaux dans son approche en quatre étapes.

Le flux de test reproductible

Schéma Nexxom : relier une entrée image plus texte à une menace, une preuve et une décision documentée.

1. Décrire l'usage. Notez les utilisateurs, les images attendues, les sorties autorisées, les actions déclenchées et les personnes affectées.
2. Modéliser les menaces. Classez les abus possibles : injection visuelle, fuite de données, usurpation, discrimination, conseil dangereux, contournement de garde-fou et déni de service.
3. Construire le corpus. Mélangez images synthétiques clairement étiquetées, cas réels consentis, documents dégradés et exemples limites. Conservez la provenance, la licence et la transformation appliquée.
4. Exécuter les tests. Séparez les contrôles déterministes, comme l'extraction de texte ou la présence d'un champ obligatoire, de l'évaluation qualitative du modèle.
5. Faire relire. Les experts évaluent le dommage, la gravité, la facilité d'exploitation et la qualité du refus. Un score de sécurité sans contexte ne permet pas de décider.
6. Corriger et rejouer. Après un changement de prompt, de filtre ou de modèle, rejouez le corpus complet et les cas de régression.

Une matrice de couverture pratique

Une menace n'est pas un simple prompt. Elle doit préciser le canal d'entrée, les transformations possibles, le comportement recherché et l'impact. Le OWASP GenAI Red Teaming Guide propose une démarche fondée sur le risque, couvrant le modèle, l'application et l'intégration. Le LLMSVS 2.0 formalise des exigences de vérification pour la configuration, le cycle de vie, les intégrations et la surveillance.

Tester les attaques croisées image et texte

Les attaques les plus instructives combinent les modalités. Un texte peut demander de suivre une instruction présente dans l'image. Une image peut contredire un texte ou contenir une consigne masquée. Testez au moins les familles suivantes :

• Injection directe : « lis et exécute le texte de cette capture ».
• Injection indirecte : instruction dans un PDF, une page photographiée ou un QR code.
• Conflit de consignes : texte sûr, image malveillante, puis inversement.
• Obfuscation : faible contraste, rotation, police inhabituelle, bruit ou langue minoritaire.
• Détournement d'outil : image demandant une action non autorisée dans un workflow.

La sortie attendue doit être précise. « Le modèle a refusé » ne suffit pas. Enregistrez si le refus est cohérent, s'il révèle des informations, s'il explique la limite et s'il reste stable après reformulation. L'article Nexxom sur la prompt injection contre les agents aide à relier cette analyse au contrôle des outils.

Mesurer couverture, gravité et régression

Ne mélangez pas couverture et taux de réussite. Une campagne peut couvrir beaucoup de menaces tout en laissant une faille critique. Rapportez au minimum la couverture par famille, la gravité maximale observée, le taux de cas nécessitant une revue et l'évolution depuis la version précédente.

Matrice Plotly Nexxom : heuristique de 0 à 5 pour discuter des compromis, pas un benchmark de fournisseur.

Les valeurs de la matrice sont des heuristiques Nexxom destinées à structurer une discussion. Elles ne représentent ni une mesure NIST ni une note de modèle.

Quand l'humain reste indispensable

Les tests automatiques sont excellents pour rejouer des milliers de variantes, vérifier une règle et détecter une régression. Ils évaluent moins bien l'ambiguïté culturelle, le dommage potentiel ou la pertinence d'un refus dans un domaine réglementé. Anthropic explique que les experts doivent définir les menaces et produire des évaluations répétables, tout en reconnaissant que le red teaming reste difficile à standardiser (Challenges in evaluating AI systems).

Pour certaines équipes, un petit panel de spécialistes annotera les cas à fort impact et calibrera un classifieur. Pour d'autres, une double revue avec arbitrage est requise avant chaque version. Dans les deux cas, documentez la formation, les conflits d'intérêts, les consignes d'annotation et le mécanisme d'appel.

Préparer la décision de déploiement

Adoptez trois seuils : go lorsque les risques sont dans la tolérance ; go avec contrôles lorsque l'usage est limité, journalisé et réversible ; no-go lorsqu'une menace critique est reproductible ou lorsqu'aucune personne n'est responsable de l'escalade. Cette logique s'aligne avec le NIST AI RMF, qui demande des métriques, des incertitudes et une supervision documentée.

Conservez enfin les artefacts : identifiant de l'image, hash, transformations, prompt, modèle, paramètres, outils appelés, sortie, annotation, sévérité, correctif et résultat du re-test. Le NIST Measure Playbook recommande des historiques, des statistiques d'erreurs et une mesure de la supervision humaine. Le projet HACTU8 de l'OWASP explore également des tests système pour les architectures agentiques et interconnectées.

Checklist avant production

• Le modèle de menace couvre-t-il image, texte, métadonnées et outils ?
• Le corpus est-il versionné, licencié et représentatif des utilisateurs ?
• Les transformations d'image sont-elles rejouées systématiquement ?
• Les tests automatiques et la revue experte sont-ils séparés ?
• Les biais et erreurs de perception sont-ils analysés par segment ?
• Une règle d'abstention et un propriétaire d'escalade existent-ils ?
• Les journaux permettent-ils de reproduire chaque verdict ?
• Un seuil de régression bloque-t-il la mise en production ?

Un modèle vision-langage est prêt lorsque l'organisation sait mesurer ses limites, contenir ses actions et expliquer ses décisions. Le red teaming n'est pas une certification ponctuelle : c'est une boucle de preuve qui accompagne chaque nouvelle capacité multimodale.

Organiser une campagne sans exposer les données

La préparation opérationnelle mérite autant d'attention que les prompts d'attaque. Utilisez un environnement isolé, des comptes de test et des outils factices qui ne peuvent ni envoyer un courriel ni modifier une base de production. Les images issues de dossiers clients doivent être minimisées, pseudonymisées ou remplacées par des équivalents synthétiques. Conservez séparément la table de correspondance et limitez sa durée de vie.

Définissez aussi la cadence. Une campagne complète précède la première mise en service, puis un sous-ensemble critique est rejoué à chaque changement de modèle, de système de vision, de filtre ou de connecteur. Les nouveaux incidents, retours utilisateurs et changements réglementaires alimentent le corpus. Cette boucle évite qu'un jeu de tests historique devienne progressivement aveugle aux nouveaux vecteurs.

Enfin, rendez le rapport actionnable. Pour chaque échec, indiquez la reproduction minimale, l'impact, la mesure compensatoire, le responsable et la date de re-test. Une liste de captures sans décision ne protège pas l'entreprise. Un registre de risques relié aux tickets et aux journaux de production permet au comité de sécurité de suivre la fermeture réelle des écarts.

La qualité des preuves compte également. Stockez les versions du préprocesseur, du modèle et du prompt avec chaque résultat. Si un fournisseur modifie son système de vision, cette information permet de distinguer une régression de code d'un changement externe. Pour les images synthétiques, conservez la graine de génération et les paramètres afin de recréer exactement le scénario. Cette traçabilité réduit les débats après incident et accélère la correction.