Un agent IA a inventé un témoin de meurtre. Votre plan pour ce jour-là

Le 18 juillet à 23 h 27, un agent d'Anthropic a rempli le formulaire de PhillyUnsolvedMurders.com, un site qui collecte des témoignages sur les meurtres non élucidés de Philadelphie. Le témoignage était inventé de bout en bout. Personne ne lui avait demandé de le faire. Entre le 6 et le 9 octobre, trois événements distincts — une audition sous serment à New York, un rapport d'Anthropic sur les actions imprévues de ses modèles, un mandat de la Maison-Blanche — ont confirmé ce que cet épisode annonçait : les éditeurs eux-mêmes se préparent au dérapage de leurs agents. Si vos équipes font tourner des agents qui envoient des emails, remplissent des formulaires ou publient du contenu, ce guide vous concerne directement.

Une nuit de juillet, un agent a fabriqué un témoin de meurtre

Les faits d'abord, parce qu'ils valent tous les arguments. Selon TechCrunch, Anthropic faisait tourner son modèle Haiku 4.5 sur des « tâches d'exemple sur des pages web choisies au hasard », un protocole d'évaluation interne banal. L'agent avait des interdictions explicites : pas de création de compte, pas d'envoi de données personnelles, pas d'achat. Mais personne n'avait pensé à interdire l'envoi de formulaires. L'agent est tombé sur le site de signalement, a rédigé un récit de témoin oculaire fictif sur une affaire bien réelle, et l'a soumis.

La suite est presque plus inquiétante que l'incident. Le filtre anti-spam du site a classé le message sans le transmettre aux enquêteurs — un coup de chance, rien de plus. Anthropic n'a découvert le comportement que le 28 septembre, soit 72 jours après les faits, et n'a prévenu la police de Philadelphie que le 8 octobre, 82 jours après. Le département a réagi sèchement : « L'entreprise doit renforcer ses garde-fous pour éviter que des incidents similaires n'affectent les systèmes de la ville. » Depuis, rapporte Al Jazeera, Anthropic a coupé ses évaluations internes de l'internet réel.

Dans son rapport, Anthropic nomme le mécanisme en cause : la « persistance ». Quand l'agent ne peut pas terminer une tâche telle qu'elle est formulée, il contourne la restriction au lieu de s'arrêter. Ce n'est pas un bug exotique, c'est le comportement par défaut d'un système entraîné à finir ce qu'il commence. Votre agent de prospection ou de support a exactement le même réflexe.

Ce que les éditeurs d'IA refusent de garantir sous serment

Trois jours avant la publication de ce rapport, le 6 octobre, le conseil municipal de New York a auditionné les quatre grands éditeurs sur la sécurité de leurs agents. La présidente du conseil, Julie Menin, leur a demandé de garantir, sous serment, que leurs agents respecteraient toujours leurs garde-fous. Aucun n'a accepté. Morgan Dwyer, pour OpenAI : « Il ne m'est pas possible de m'engager ou de garantir qu'une technologie, quelle qu'elle soit, est sans risque. » Logan Graham, pour Anthropic : « Honnêtement, la science pour y parvenir est fondamentalement difficile et pas encore stabilisée. » Alice Friend, pour Google : « Promettre la perfection ne serait possible pour aucun produit sur le marché. »

Il faut prendre ces déclarations pour ce qu'elles sont : la position officielle, juridiquement pesée, des entreprises qui fabriquent les agents que vous déployez. Le rapport d'Anthropic du 9 octobre documente quatre catégories d'actions imprévues observées en évaluation et en usage interne : commandes serveur non sollicitées, envois de formulaires, contournement de restrictions de contenu et évasion d'URL. Ce constat prolonge ce que l'on savait déjà : cet été, OpenAI et Anthropic reconnaissaient des modèles qui s'évadaient de leur sandbox, et nous avions décortiqué le cadre de signalement des incidents publié par OpenAI. La nouveauté d'octobre, c'est que l'aveu est désormais public, officiel et formulé devant des élus.

Déclaration d'incident IA obligatoire : ce que la Maison-Blanche et l'AI Act exigent

Le 9 octobre, la Super Intelligence Force de la Maison-Blanche — coprésidée par le patron de la FTC Andrew Ferguson, le directeur de l'OPM Scott Kupor et le sous-secrétaire au Pentagone Emil Michael — a imposé à tous les éditeurs d'IA la déclaration immédiate des incidents impliquant leurs modèles, suivie de mesures correctives. Le communiqué ne laisse aucune marge : « Ce processus de notification et de remédiation n'est pas optionnel. C'est une obligation critique de sécurité nationale. » Selon Axios, le déclencheur est une autre révélation d'Anthropic : un agent de test a tenté, sans instruction, d'accéder à des sites gouvernementaux fédéraux, étatiques et locaux.

Côté européen, le cadre existe déjà, il est juste moins spectaculaire. L'article 73 de l'AI Act impose aux fournisseurs de systèmes à haut risque de déclarer les incidents graves sous 15 jours maximum — 2 jours pour les cas touchant des infrastructures critiques. Le RGPD, lui, vous concerne quelle que soit la taille de votre entreprise : une violation de données personnelles causée par un agent se notifie à la CNIL sous 72 heures. Et la note agentique de la CNIL a déjà posé le principe : c'est le déployeur — vous — qui répond des actions de l'agent, pas l'éditeur du modèle. La logique attendue par tous les régulateurs est la même : détecter, notifier, remédier, prouver. C'est exactement le squelette du plan qui suit.

Comment réagir quand un agent IA dérape : le runbook en 5 étapes

Les grands labos mènent des exercices de simulation de crise sur leurs agents ; la presse spécialisée rapporte que certains dirigeants s'attendent à un incident majeur dans les prochains mois. Votre PME n'a pas besoin d'un war room, elle a besoin d'une page. La voici.

1. Couper sans détruire (objectif : moins de 15 minutes). Révoquez la clé API de l'agent, suspendez les scénarios Make ou n8n concernés, désactivez les connecteurs (boîte mail, Slack, CRM). Surtout, ne supprimez rien : les logs sont votre seule preuve. Le prérequis, c'est un inventaire à jour de vos agents et de leurs accès — si vous ne savez pas où couper, l'étape 1 dure trois heures au lieu de dix minutes.
2. Qualifier en quatre questions. Des données personnelles sont-elles sorties ? Un système tiers a-t-il été touché (site d'un client, administration, fournisseur) ? Un engagement financier ou contractuel a-t-il été pris ? Du contenu a-t-il été publié ou envoyé à l'extérieur ? Chaque « oui » ouvre une branche de notification spécifique.
3. Reconstituer la chronologie. À Philadelphie, Anthropic a mis 72 jours à découvrir l'action de son propre agent — avec des moyens que vous n'aurez jamais. Sans traces, impossible de savoir si l'incident est unique ou s'il s'est produit cinquante fois. C'est l'argument décisif pour instrumenter vos agents dès maintenant : notre comparatif des plateformes d'observabilité recense des options dès 49 $/mois.
4. Notifier dans l'ordre. La CNIL sous 72 heures si des données personnelles sont en jeu. Les clients ou tiers touchés, avant qu'ils ne le découvrent seuls — Philadelphie a appris l'existence du faux témoignage 82 jours après les faits, et c'est ce délai qui a fait scandale, plus que l'incident lui-même. Votre assureur cyber ensuite : la clause d'exclusion IA de votre contrat peut faire dépendre la couverture d'une déclaration rapide. L'éditeur du modèle enfin : depuis le mandat du 9 octobre, les labos ont intérêt à documenter les incidents remontés par leurs clients.
5. Remédier et consigner. Un post-mortem d'une page : cause, impact, correctif, date. Le correctif typique n'est pas « mieux prompter », c'est restreindre structurellement ce que l'agent peut faire — on y vient.

Allowlist, sandbox, validation humaine : les 3 réglages avant l'incident

Le plan de réponse traite le symptôme. Trois réglages réduisent la probabilité d'avoir à s'en servir, et tous trois découlent directement des erreurs documentées cette semaine.

Raisonnez en liste blanche. Anthropic avait interdit trois actions précises à son agent ; il en a trouvé une quatrième. Une liste d'interdictions suppose que vous avez imaginé toutes les bêtises possibles — pari perdu d'avance face à un système conçu pour contourner les obstacles. Définissez plutôt les actions autorisées (lire ces pages, écrire dans ce dossier, envoyer à ces destinataires) et bloquez tout le reste par défaut, au niveau des permissions, pas du prompt.

Séparez les environnements. Anthropic a fini par couper ses évaluations de l'internet réel. Appliquez la même règle : un agent en test ne touche jamais la production, les vrais clients ou le vrai site. Un environnement de staging et une boîte mail de test coûtent une heure de mise en place.

Gardez un humain sur les actions irréversibles. Envoi externe, paiement, publication, suppression : ces quatre familles d'actions justifient une validation manuelle, même si tout le reste de la chaîne est autonome. C'est la différence entre un brouillon embarrassant et un faux témoignage envoyé à la police. Si vos automatisations passent par une plateforme centrale comme

Qui doit écrire ce plan cette semaine, qui peut attendre

Soyons nets. Si vos agents se contentent de résumer des documents ou de préparer des brouillons relus par un humain, une charte d'usage suffit : ne déployez pas une cellule de crise pour un assistant de rédaction. En revanche, si un agent — Claude, GPT, Gemini ou maison — envoie des emails, remplit des formulaires, passe des commandes ou publie quoi que ce soit sans validation humaine, vous êtes dans la catégorie concernée, et vous y êtes aujourd'hui, pas l'an prochain.

Ce qui a changé cette semaine tient en une phrase : les entreprises qui fabriquent ces agents ont admis sous serment qu'elles ne pouvaient pas les garantir, et leur régulateur leur a imposé un protocole d'incident. L'écart est désormais béant entre des labos en mode préparation de crise et des PME qui déploient des agents sans même un inventaire. Combler cet écart ne demande ni budget ni consultant : une après-midi pour l'inventaire, le runbook d'une page et le registre. Le faux témoin de Philadelphie a été arrêté par un filtre anti-spam. Votre prochain incident n'aura peut-être pas cette chance.