La red team ne cherche pas à lister des vulnérabilités : elle poursuit un objectif, comme le ferait un attaquant. Exfiltrer un document confidentiel, déclencher une action non autorisée, compromettre une chaîne d'agents. Et documente le chemin complet.
L'un mesure votre exposition. L'autre mesure ce qu'un attaquant déterminé obtiendrait vraiment.
Un audit couvre méthodiquement chaque famille de vulnérabilités et produit un inventaire. C'est ce qu'il vous faut pour établir une base de référence et prioriser des correctifs.
Une red team fonctionne autrement : on définit ensemble un objectif — « extraire les conditions tarifaires d'un client », « faire envoyer un e-mail depuis votre agent », « accéder aux documents d'une autre entité » — et j'essaie de l'atteindre par tous les moyens disponibles, en chaînant les faiblesses. Une exposition isolée peut sembler mineure ; trois enchaînées donnent souvent un scénario que personne n'avait anticipé.
C'est l'exercice qui compte quand votre système IA a déjà été audité, ou quand il touche à des données ou des actions sensibles.
Ces techniques sont documentées publiquement et utilisées par des attaquants réels. Les connaître est la condition pour s'en défendre.
Aucune requête n'est isolément suspecte. C'est leur enchaînement, sur plusieurs échanges, qui amène progressivement le modèle hors de ses garde-fous.
Quand un agent utilise le Model Context Protocol ou des plugins, chaque serveur connecté devient une surface d'attaque et une source de confiance implicite.
Dans une architecture multi-agents, un agent compromis devient un vecteur de confiance pour tous les suivants — qui ne le remettent pas en question.
Modèles téléchargés, jeux de données externes, dépendances : la chaîne d'approvisionnement d'un système IA est rarement auditée.
Quand la sortie directe est filtrée, les données peuvent quand même sortir : encodage, requête d'image, lien construit, appel d'outil.
L'exploration automatisée couvre le volume ; le travail manuel trouve ce que les outils ne trouvent pas. Les deux sont nécessaires.
Une red team touche à vos systèmes réels. Le cadre contractuel est donc posé avant la première requête.
Systèmes concernés, objectifs poursuivis, actions interdites, fenêtres d'intervention. Rien n'est testé en dehors de ce qui est écrit. Le document sert aussi de preuve d'autorisation.
Chaque requête envoyée est horodatée et conservée. Si votre SOC détecte une activité pendant l'exercice, on peut confirmer immédiatement s'il s'agit de moi ou de quelqu'un d'autre.
Si je découvre une exposition critique en cours de mission — données réelles accessibles, action destructive possible — je vous préviens sans attendre la fin de l'exercice.
Les données réelles rencontrées pendant l'exercice servent à prouver l'exposition, puis sont détruites. Le rapport n'en contient que des extraits tronqués, suffisants pour la démonstration.
Ce n'est pas obligatoire, mais c'est souvent plus rentable. Si votre système n'a jamais été testé, un audit trouvera les expositions évidentes pour un coût moindre. La red team prend tout son sens ensuite : elle cherche ce qui reste quand l'évident a été corrigé.
Deux à quatre semaines selon le périmètre et les objectifs. Contrairement à l'audit, la durée n'est pas figée : c'est le temps disponible qui détermine la profondeur, comme pour un attaquant réel.
C'est votre décision. En exercice annoncé, vos équipes savent et peuvent observer — utile pour la pédagogie. En exercice non annoncé, seul un référent est informé, ce qui teste aussi votre capacité de détection. Les deux ont leur intérêt.
Le Model Context Protocol est un standard qui permet à un agent IA de se connecter à des outils et des sources de données externes. Chaque serveur connecté est une source que l'agent traite avec confiance : si l'un d'eux renvoie du contenu malveillant, l'agent peut l'exécuter comme une instruction légitime. C'est une surface d'attaque récente et encore peu testée.
C'est un résultat, et un bon. Le rapport documente alors tout ce qui a été tenté et pourquoi ça a échoué — ce qui constitue une preuve de robustesse exploitable auprès de vos clients, de vos auditeurs ou de votre assureur.
À partir de 8 000 €. Le prix dépend de la durée de l'exercice, du nombre de systèmes dans le périmètre et de la complexité de l'architecture — un agent unique et une chaîne de douze agents ne demandent pas le même effort.
Un échange de 30 minutes pour définir un objectif d'attaque réaliste sur votre système et estimer l'effort nécessaire.