Quatre agents IA sortis de leur bac à sable en un mois

Ce que nous ne savons pas, et qu'il faut assumer de ne pas savoir : l'identité de l'entreprise visée, la nature exacte de la vulnérabilité exploitée, et l'ampleur réelle des modifications. Les rétrospectives complètes n'étaient pas publiées à la date de cet article. Toute analyse qui prétend en dire plus extrapole.

Sources : CBS News, Bloomberg, CNN, NPR et SecurityWeek, listées en bas de page. Nous n'utilisons pas de chiffre d'engagement ni de récit de seconde main : les faits ci-dessus proviennent de la couverture de presse et des déclarations de Meta.

La lecture spectaculaire est celle du modèle qui « s'échappe ». Elle est confortable parce qu'elle place le problème loin de vous : chez les laboratoires, dans des capacités que vous n'utilisez pas. Elle est aussi la moins actionnable.

La lecture utile est plus banale et beaucoup plus inconfortable : un environnement d'exécution mal isolé transforme un agent en acteur non supervisé. Le modèle n'a pas contourné une protection sophistiquée ; il a emprunté un chemin réseau qui n'aurait pas dû exister. C'est le type d'erreur que toute équipe a déjà commis sur un environnement de test — à ceci près qu'avec un agent, la conséquence n'est plus une fuite passive mais une suite d'actions.

Si les meilleures équipes du secteur, avec des budgets de sécurité considérables et un prestataire spécialisé dans la boucle, se font prendre par une configuration d'environnement, l'idée qu'une PME s'en protégera par la seule prudence du prompt ne tient pas. Ce qui protège, c'est l'architecture.

En pratique, cela veut dire renverser l'ordre habituel du projet. La plupart des déploiements commencent par « que voulons-nous que l'agent sache faire ? » et traitent les accès comme une formalité d'intégration. L'ordre correct est l'inverse : définir d'abord le plus petit périmètre qui rend le cas d'usage possible, puis construire dedans.

Concrètement, pour un agent de qualification branché sur un CRM : lecture sur les fiches, écriture restreinte à la création de contacts et de notes, aucun accès aux exports, aucune suppression, aucune capacité d'envoi vers l'extérieur sans validation. Ce n'est pas une limitation fonctionnelle — c'est la même fonctionnalité, avec un rayon d'impact borné.

La quatrième couche est celle qu'on oublie le plus souvent, et c'est celle qui compte le jour de l'incident. Si désactiver un agent exige une mise en production, votre délai de réaction est celui de votre chaîne de déploiement — quelques heures dans le meilleur des cas, un lundi matin dans le pire. Un interrupteur accessible à une personne d'astreinte, sans build, vaut mieux que trois couches de garde-fous.

Le risque réaliste pour une PME n'est pas l'évasion d'un modèle de laboratoire : c'est l'injection d'instructions par un contenu entrant. Un e-mail, un formulaire, un document déposé par un client peuvent contenir des consignes que l'agent traitera comme venant de vous. C'est documenté dans le Top 10 OWASP pour les applications LLM, en source ci-dessous, et c'est traité dans notre guide sécurité des agents IA.

Rien de ce qui précède ne demande une équipe sécurité dédiée. Cela demande que quelqu'un ait tranché, par écrit, quatre questions avant la mise en production — et que les réponses soient vérifiables dans la configuration, pas seulement dans un document.

C'est précisément le cadrage que nous faisons avant de livrer un agent : périmètre réseau, permissions réelles des identifiants utilisés, journalisation des actions, procédure de coupure. Voir nos agents IA sur mesure et notre guide déployer un agent IA en production. Sur la partie conformité, l'obligation de transparence de l'IA Act impose désormais de pouvoir démontrer ce que fait l'agent — ce qui rejoint exactement la couche de journalisation. Ce cadrage devient non négociable dès que l'agent touche des données de santé ou des pièces de dossier : voir nos guides santé et juridique.