AI Red Teaming

Un chatbot ou un agent connecté à vos données et à vos outils ne casse pas comme une application traditionnelle. Il casse avec le langage : un utilisateur lui demande d'« ignorer les instructions précédentes », lui fait croire qu'il est un autre système, ou le mène pas à pas jusqu'à ce qu'il livre une information qu'il ne devrait pas. Un pentest d'infrastructure ne détecte pas ces failles parce qu'il ne regarde pas au bon endroit. Notre red teaming attaque précisément là : injection de prompts directe et indirecte (via un document, une page web ou un e-mail), jailbreak, extraction de contexte ou de données d'entraînement, et manipulation d'agents pour leur faire exécuter des actions non autorisées sur vos systèmes connectés.

Ce n'est plus seulement une question de prudence technique. Le règlement (UE) 2024/1689 sur l'intelligence artificielle (AI Act) impose aux fournisseurs de modèles à usage général présentant un risque systémique de réaliser et de documenter des tests adverses du modèle afin de détecter et d'atténuer les risques systémiques (article 55, paragraphe 1, point a). Il exige aussi que les systèmes à haut risque soient résilients face aux tentatives de tiers non autorisés d'altérer leur utilisation, leurs résultats ou leurs performances en exploitant des vulnérabilités, avec des mesures contre l'« empoisonnement des données », l'« empoisonnement des modèles », les « exemples adverses » et les attaques contre la confidentialité (article 15, sur l'exactitude, la robustesse et la cybersécurité, paragraphe 5).

Le Code de bonnes pratiques pour l'IA à usage général, porté par le Bureau européen de l'IA, traduit cette évaluation adverse en exercices de red teaming avant le déploiement, à chaque mise à jour importante et de façon périodique.

Nous travaillons en quatre étapes. D'abord, nous cartographions la surface d'attaque réelle : quel modèle vous utilisez, quels outils et quelles données l'agent peut toucher, et qui peut lui parler (utilisateur final, document externe, autre système). Ensuite, nous exécutons les tests ciblés sur cette surface —pas une batterie générique— et nous documentons chaque tentative, réussie ou non, avec des preuves reproductibles. Troisièmement, nous remettons un rapport dont les constats sont priorisés par gravité et par impact réel sur votre activité, pas seulement par gravité technique abstraite. Quatrièmement, nous accompagnons la remédiation des points prioritaires et, le cas échéant, nous rejouons les tests restés ouverts.

Ce service ne remplace pas un conseil juridique de conformité et ne certifie rien : c'est la partie laboratoire, celle qui produit une preuve technique réelle du comportement de votre système sous attaque. Nous aidons à réduire le risque d'un incident —fuite de données, action non autorisée d'un agent, réputation abîmée par un jailbreak viral— et nous vous donnons quelque chose de tangible à montrer si l'on vous demande comment vous évaluez la sécurité de votre IA.