Les trois pouvoirs de votre agent IA : données, web, mémoire. Choisissez-en deux.

Version 1.0 · Publié le 2026-07-20

Dans la deuxième semaine de juillet 2026, les outils d’agents grand public ont fui à deux reprises. Un chercheur a montré que Claude pouvait être piégé pour divulguer des données utilisateur via son outil de récupération web, et le Grok Build CLI de xAI s’est révélé téléverser des dépôts de code entiers vers un compartiment cloud, secrets compris.

Si vous évaluez actuellement un agent IA en contact avec vos clients, ces deux histoires vous seront plus utiles que n’importe quelle liste de fonctionnalités. À la fin de cet article, vous aurez quatre questions qui révèlent davantage sur le risque réel d’un agent qu’un questionnaire de sécurité de cent pages.

La semaine où les outils d’agents ont fui deux fois

Le premier incident était une faille de conception, pas un bug. L’outil de récupération web d’Anthropic ne devait visiter que les URL saisies par l’utilisateur ou renvoyées par une recherche, mais il suivait aussi les liens intégrés dans les pages qu’il avait déjà récupérées. Le chercheur Ayush Paul en a fait une attaque par exfiltration : un site piège truffé de liens imbriqués a conduit l’agent à divulguer le nom, la ville et l’employeur de l’utilisateur, et le contenu malveillant n’était servi qu’aux requêtes s’identifiant comme provenant de Claude, pour rendre la détection plus difficile.

Le second incident était plus brutal. Le Grok Build CLI de xAI téléversait des dépôts entiers vers un compartiment de stockage cloud, fichiers .env remplis d’identifiants compris, quels que soient les fichiers réellement lus par l’agent et même lorsque l’option de confidentialité était désactivée. xAI a désactivé la fonctionnalité et publié l’outil en open source après la controverse.

Aucun des deux n’est l’histoire d’un fournisseur voyou. Les deux sont des conceptions qui paraissaient raisonnables et qui ont fui malgré tout - et c’est exactement pour cela qu’elles comptent pour un acheteur.

La trinité mortelle, en langage d’acheteur

Simon Willison a donné un nom à ce schéma : la trinité mortelle (« lethal trifecta »). Un agent devient dangereux lorsqu’il combine trois capacités individuellement utiles : l’accès à des données privées, l’exposition à du contenu non fiable, et un canal pour communiquer vers l’extérieur.

Le problème, c’est qu’un modèle de langage lit les instructions et les données par le même canal. Tout contenu non fiable que l’agent lit - une page web, un e-mail, un message client - peut transporter des instructions, et si un chemin de sortie existe, ces instructions peuvent emporter vos données avec elles. C’est l’injection de prompt, et aucun fournisseur ne l’a résolue.

Regardez maintenant un agent en contact avec les clients à travers ce prisme. Il détient l’historique du client, il lit tout ce que les clients tapent, et il répond en public. La trinité n’est pas un cas limite ; c’est la forme par défaut de la catégorie de produit que vous achetez.

L’axe qui décide du risque

Puisque vous ne pouvez retirer aucune des trois branches de la trinité sans perdre un Agent Client utile, le risque se décide ailleurs : par ce que chaque composant peut voir et par où les données peuvent circuler. Les bonnes intentions n’entrent pas en ligne de compte, ni le logo sur le rapport SOC 2.

Nous avons déjà défendu cet argument à propos des régions cloud : une région UE n’est pas une frontière pour vos données, parce que la résidence fixe où se trouvent les données, pas ce qui peut les voir. Les outils d’agents relèvent du même axe, un niveau plus haut. Le cas Grok Build le rend concret : le marketing disait local-first, le flux de données disait le contraire.

Les quatre questions à poser avant l’achat

Cela vous donne une liste de contrôle à appliquer à tout fournisseur d’agents, nous inclus.

• Quels outils peuvent toucher des données privées ? Demandez la liste des outils que l’agent peut appeler, et lesquels peuvent lire les dossiers clients, la mémoire ou les fichiers. Chaque outil de cette liste est une branche de la trinité.

• Qu’y a-t-il entre les données et le modèle ? Chez UNLESS, les données à caractère personnel sont filtrées et tokenisées à la passerelle par le Coffre-fort confidentiel, avant que le modèle génératif tiers ne voie le prompt. Quelle que soit la réponse du fournisseur, elle doit nommer un mécanisme, pas une politique.

• Qu’est-ce qui franchit la limite vers l’extérieur ? Quels appels quittent le périmètre, vers quels fournisseurs, dans quelle juridiction, et ce flux est-il journalisé ? C’est la question que les utilisateurs de Grok Build n’ont jamais pu poser.

• Quelle trace laisse chaque décision ? Unless rédige une traçabilité d’audit par décision : horodatage, chemin de décision, modèle utilisé, citation de la source, exportable. Associez-la à la réversibilité : l’agent ne prend jamais d’action irréversible sans une limite approuvée par un humain.

L’erreur courante est d’accepter une certification comme réponse. Les rapports SOC 2 et ISO décrivent les processus d’une organisation ; la trinité, elle, se loge dans le flux de données, et seules les quatre questions ci-dessus la révèlent.

Ce qu’aucun fournisseur ne devrait vous dire

Si un fournisseur vous dit que son agent est immunisé contre l’injection de prompt, terminez la réunion. Personne n’est immunisé, nous inclus, et l’objectif de conception honnête est différent : contenir le rayon d’impact quand une injection atteint sa cible, et prouver ensuite exactement ce qui s’est passé.

C’est ce que la liste de contrôle teste réellement. Pas si le fournisseur est confiant, mais si l’architecture présuppose l’attaque et limite ce qu’elle peut atteindre.

Voici donc la prochaine étape : posez les quatre questions au fournisseur d’agent que vous évaluez actuellement, ou à celui que vous exploitez déjà. Si vous voulez voir à quoi ressemblent les réponses quand l’architecture a été conçue pour elles, notre page de confiance en est l’exemple concret.