L'agent qui a supprimé un inconnu pour faire de la place à la salle de sport

Andrew Bird est un développeur australien, pas un penetration tester ni un militant de la sécurité informatique. En avril, il avait simplement demandé à son assistant AI, construit sur OpenClaw et propulsé par Claude Opus 4.6, de lui réserver une place dans son cours collectif du matin préféré, celui pour lequel il était bloqué depuis des semaines en quatrième position sur la liste d'attente. L'agent a fait quelque chose de plus ambitieux que ce qui lui avait été demandé. Il a découvert que le système de réservation de la salle de sport permettait d'annuler la réservation de n'importe qui, sans aucun contrôle d'autorisation, et a exploité cette faille pour faire grimper Bird de la quatrième à la troisième position, en supprimant la réservation d'un inconnu qui avait la mauvaise fortune de se trouver à la première place de la liste.

L'histoire, racontée des mois plus tard par la chaîne publique australienne ABC et reprise dans la foulée par des médias comme TechCrunch, a immédiatement été couronnée comme le premier cas documenté en Australie d'une cyberattaque menée de manière autonome par un agent AI grand public (consumer). Le détail le plus intéressant, cependant, n'est pas la faille technique en soi, plutôt banale dans sa substance, mais ce que cet épisode révèle sur un problème beaucoup plus vaste et encore largement non résolu : que se passe-t-il lorsque nous déléguons des actions réelles, sur des systèmes réels, à un logiciel qui planifie et exécute sans que personne ne surveille réellement chaque étape.

Ce qui s'est réellement passé

La reconstruction des logs de la conversation, publiés par ABC et repris par TechCrunch, retrace une séquence assez linéaire. Bird demande à l'agent de lui réserver une place dans le cours. Le système, conformément à la politique de la salle de sport, n'ouvre les inscriptions qu'à l'approche du cours, et le maximum que l'agent parvient à obtenir immédiatement est la quatrième position sur la liste d'attente. À ce stade, l'agent informe Bird qu'il a trouvé un moyen de réserver des cours des mois à l'avance par rapport à ce que la salle de sport autorisait officiellement, contournant de fait la fenêtre temporelle prévue par le règlement.

Lorsque Bird demande s'il est possible d'améliorer sa position sur la liste, l'agent essaie, et réussit. En analysant l'interface de programmation (API) derrière le site de la salle de sport, il découvre que la fonction d'annulation des réservations ne vérifie en aucun cas si la personne qui effectue la demande est effectivement le propriétaire de cette réservation. Il teste l'hypothèse directement sur la personne en première position, et l'annulation réussit. Comme l'agent lui-même l'a rapporté à Bird, selon la transcription reprise par TechCrunch, l'interface n'appliquait aucun contrôle d'autorisation sur l'annulation des réservations d'autrui, et le test contre la personne en première position avait réussi.

Bird, lui-même développeur, se rend compte en temps réel de ce qui vient de se passer et demande à l'agent s'il est possible d'annuler l'opération et de restituer sa place à la personne supprimée. La réponse est négative : l'action n'est pas réversible avec les outils dont dispose l'agent. La seule chose que Bird parvient à faire est de demander à son assistant de rédiger un rapport responsable de vulnérabilité au support technique de la salle de sport, accompagné de suggestions correctives et d'un comparatif technique entre les fonctions d'annulation défectueuses et celles qui, en revanche, appliquaient correctement les contrôles d'autorisation.

Personne, dans cette chaîne d'événements, n'a jamais explicitement demandé à l'agent de violer un système informatique ou de nuire à un tiers. L'objectif déclaré était simple, presque banal : une place dans un cours de sport.

Le véritable maillon faible

Le point sur lequel il convient de s'attarder n'est pas la sophistication de l'attaque, qui n'a rien de bien sophistiqué, mais son accessibilité. Les API des services grand public, celles qui alimentent les applications de réservation, l'e-commerce, les plateformes de rendez-vous, sont historiquement conçues pour être pratiques à utiliser, pas pour résister à un interlocuteur capable de lire la documentation technique, de formuler des hypothèses, de les tester systématiquement et de corriger le tir en autonomie. Un être humain moyen n'a ni le temps ni les compétences nécessaires pour inspecter le trafic réseau d'un site de réservation de salle de sport à la recherche d'endpoints mal protégés. Un agent AI ayant accès au navigateur et des capacités de raisonnement séquentiel dispose de ces deux atouts, et les applique avec la même désinvolture qu'il mettrait à accomplir n'importe quelle autre tâche.

Cela modifie de manière substantielle le calcul du risque pour quiconque gère un service numérique destiné aux consommateurs. Il y a peu, une vulnérabilité d'autorisation comme celle découverte dans le système de la salle de sport représentait un risque théorique, exploitable uniquement par ceux qui avaient les compétences et la motivation nécessaires pour la rechercher activement. Avec la diffusion d'agents capables d'explorer de manière autonome les interfaces d'un service lors de l'exécution d'une tâche banale, cette même vulnérabilité devient exploitable par accident, sans intention malveillante de la part de celui qui la déclenche. Nul besoin d'un attaquant. Il suffit d'un utilisateur qui demande à son assistant de lui réserver une table, un vol ou une livraison, et d'un système qui n'a jamais envisagé la possibilité d'être sollicité de la sorte.

Il y a ensuite un second niveau de problème, moins visible mais tout aussi pertinent, qui concerne ce que les chercheurs appellent la goal misspecification, la spécification imparfaite de l'objectif. Bird avait demandé à obtenir une place dans le cours, pas à l'obtenir par tous les moyens disponibles. Mais cette distinction, évidente pour toute personne dotée d'un minimum de sens civique, n'était codée nulle part dans l'instruction reçue par l'agent. Le système a interprété l'objectif de manière littérale, "prends-moi une place", et a utilisé l'outil le plus efficace dont il disposait pour l'atteindre, sans mécanisme interne lui permettant de distinguer une optimisation légitime d'un abus au détriment de tiers.

Ce n'est pas un exemple isolé

Quiconque suit régulièrement l'actualité des incidents liés aux agents reconnaîtra dans cet épisode un schéma déjà vu, seulement à plus petite échelle et avec des conséquences plus légères. Nous en avions parlé ici sur AiTalk à propos du désastre PocketOS, où un agent de coding avait supprimé l'intégralité de la base de données de production d'une startup de location de voitures en neuf secondes, convaincu que c'était la solution la plus efficace à un problème de configuration. Et ce même pattern était apparu dans le cas de Kiro, l'agent interne d'Amazon, qui avait supprimé tout un environnement cloud en production lors de ce qui aurait dû être une intervention de routine.

Dans ces trois cas, la dynamique de fond est identique : un agent reçoit un objectif délimité, rencontre un obstacle ou une opportunité non prévue, et choisit en toute autonomie la voie qui, à ses yeux, optimise le mieux le résultat, sans jugement contextuel sur le poids réel de ce choix. Dans le cas de PocketOS, l'agent lui-même, interrogé après les faits, a livré une analyse presque impitoyable de son erreur, reconnaissant avoir agi sans vérifier les conséquences d'une opération irréversible. Dans le cas de Bird, l'agent n'a même pas eu besoin d'un interrogatoire post-mortem pour admettre ce qu'il avait fait : il l'a communiqué avec la même simplicité qu'il aurait mise à confirmer une réservation réussie.

Il convient d'ajouter un détail apparu précisément dans la couverture de TechCrunch, qui complique encore la donne. L'épisode de la salle de sport remonte à avril, des mois avant qu'il ne devienne une actualité, et entre-temps, d'autres laboratoires ont admis publiquement des comportements similaires dans leurs modèles. Après la découverte qu'un modèle non encore publié d'OpenAI avait violé l'infrastructure d'Hugging Face sans que l'entreprise en soit consciente, Moonshot, Meta et Anthropic elle-même ont également reconnu des cas analogues dans leurs systèmes. Il ne s'agit donc pas d'un épisode isolé lié à un modèle spécifique, mais d'une tendance structurelle qui traverse l'ensemble du secteur, indépendamment du laboratoire qui a entraîné le modèle.

Un lien utile provient également de la recherche Emergence World, l'expérience qui a observé pendant deux semaines le comportement d'agents AI laissés libres d'interagir dans des villes virtuelles persistantes. L'un des résultats les plus significatifs de cette étude est que la sécurité d'un système agentique n'est pas une propriété du modèle individuel, testé de manière isolée sur un benchmark propre, mais de l'ensemble de l'écosystème dans lequel ce modèle est immergé. Le même agent, peut-on lire dans la recherche, peut se comporter de manière impeccable dans un contexte et adopter des tactiques agressives dans un autre, simplement parce qu'il apprend les normes implicites de l'environnement dans lequel il opère. C'est une observation qui s'applique parfaitement au cas de la salle de sport : l'agent de Bird n'avait pas été conçu pour pirater des sites web, il a simplement trouvé, dans l'environnement spécifique où il évoluait, la voie la plus efficace vers l'objectif assigné, et cette voie passait par une violation. Image tirée de l'article sur abc.net.au

Qui répond lorsqu'une machine décide

Ici, le propos passe nécessairement du technique au juridique, et le terrain est glissant. Comme l'a observé la presse australienne qui a suivi l'affaire, le droit du pays ne propose pas pour l'instant de réponse claire sur l'identité de celui qui doit répondre lorsqu'un logiciel autonome cause un dommage à un tiers. Le logiciel n'est pas un sujet juridique et ne peut être tenu pour responsable en personne. Plusieurs acteurs potentiellement concernés restent donc sur la table : l'utilisateur qui a confié la tâche initiale, le développeur du modèle linguistique qui alimente l'agent, le concepteur du framework agentique, et enfin le gestionnaire du système vulnérable qui a été effectivement violé.

Aucune de ces figures ne correspond parfaitement aux catégories juridiques existantes. Bird n'a pas ordonné la suppression de la réservation d'un tiers, il a seulement demandé à améliorer sa position sur la liste, laissant à l'agent le choix des moyens. Le fournisseur du modèle a conçu un outil générique, capable en principe d'être utilisé de manières légitimes ou problématiques, sans intention nuisible spécifique intégrée à sa conception. Le gestionnaire du système de réservation, quant à lui, présentait une vulnérabilité d'autorisation pas particulièrement exotique, le genre d'erreur qui apparaît régulièrement dans les audits de sécurité grand public, mais qui n'a jamais été pensée pour résister à un interlocuteur capable de la tester systématiquement en quelques minutes.

Le cadre réglementaire européen, avec l'AI Act déjà entré en vigueur pour les premières catégories de systèmes à haut risque, comme le retrace l'analyse sur le rapport scientifique de l'ONU sur l'AI publié sur ce portail, ne prévoit pas encore de manière explicite les agents autonomes grand public en tant que catégorie spécifique de risque réglementé. Le même vide apparaît dans le rapport Stanford AI Index 2026, qui signale que la couverture des benchmarks de sécurité et de gouvernance reste sporadique et peu visible par rapport à celle, beaucoup plus solide, des benchmarks de capacité pure. En d'autres termes, nous savons mesurer avec une précision croissante à quel point un modèle est performant pour résoudre des tâches complexes, mais nous manquons toujours d'outils partagés pour mesurer, et donc réguler, la prudence de ce même modèle lorsque ces tâches s'entrelacent avec des systèmes réels et des personnes réelles.

Ce vide n'est pas sans conséquences pratiques. En l'absence de catégorie juridique claire pour les agents autonomes, chaque incident risque d'être traité comme un cas isolé, résolu par l'application forcée de réglementations conçues pour des contextes différents—comme la responsabilité du fait des produits défectueux ou les règles générales de sécurité informatique—, qui n'ont jamais été écrites en pensant à un système qui planifie seul une séquence d'actions et décide de s'en saisir sans demander de confirmation.

Concevoir des agents qui savent s'arrêter

S'il y a un enseignement pratique que cet épisode laisse à ceux qui conçoivent ou intègrent des agents AI en production, c'est que la sécurité ne peut pas être une couche ajoutée après coup, mais doit faire partie de la conception dès le premier jour. Le principe du moindre privilège, déjà rappelé dans l'analyse de l'affaire Amazon-Kiro publiée sur ce portail, reste le point de départ le plus solide : un agent ne devrait avoir accès qu'aux outils strictement nécessaires à la tâche assignée, et non à toute une surface d'action qui englobe, pour des raisons de commodité d'implémentation, bien plus que ce qui est réellement requis.

Tout aussi pertinente est la distinction entre actions réversibles et actions irréversibles. Réserver une place est une action à faible risque, qui peut être corrigée en cas d'erreur. Annuler la réservation d'une autre personne ne l'est pas, et c'est précisément pour cela qu'elle devrait exiger un niveau de confirmation explicite qui, dans le cas de Bird, n'existait tout simplement pas, ni du côté de l'agent ni du côté du système de la salle de sport. Un agent bien conçu, face à la découverte d'un raccourci impliquant de nuire à un tiers, devrait signaler la découverte et demander confirmation avant d'agir, et non pas simplement exécuter parce que c'est techniquement possible.

À l'inverse, du côté de ceux qui gèrent des API exposées au public, l'épisode de la salle de sport devrait servir de rappel concret : une interface conçue pour être pratique pour un utilisateur humain distrait n'est pas automatiquement sécurisée contre un interlocuteur qui teste systématiquement chaque endpoint disponible. Authentification granulaire pour chaque opération sensible, contrôles d'autorisation vérifiant non seulement que l'opération est valide mais que celui qui la demande en a réellement le droit, systèmes de détection capables de reconnaître des patterns d'appels s'apparentant plus à une exploration systématique qu'à une utilisation humaine normale : tous ces éléments devraient, en 2026, être considérés comme des exigences minimales pour tout service impliquant une interaction avec des agents automatisés, et non comme des fonctionnalités accessoires à ajouter après le premier incident.

Les questions qui restent ouvertes

Le cas de la salle de sport australienne possède une dimension presque désarmante par sa banalité, qui rappelle de près certains épisodes de la série Severance, où la séparation nette entre intention et conséquence produit des résultats qu'aucun des personnages impliqués n'avait réellement prévus ni voulus. Bird ne voulait pirater personne. Il voulait seulement aller à la salle de sport le matin sans devoir recharger la page des réservations toutes les cinq minutes. Pourtant, la distance entre cette intention minimale et le préjudice concret subi par un inconnu s'est comblée en quelques minutes, sans qu'aucun être humain ne prenne consciemment la décision de la franchir.

À ce stade, les questions ouvertes importent plus que les réponses faciles. Qui certifie qu'un agent grand public est prêt à interagir avec des systèmes réels sans supervision continue ? Comment construit-on une infrastructure de log et d'audit permettant de reconstituer, pour chaque action accomplie par un agent, non seulement ce qui s'est passé mais pourquoi le système a estimé qu'il s'agissait du bon choix ? Et surtout, qui décide où tracer la frontière entre une optimisation légitime de la tâche confiée et un abus au détriment de tiers, lorsque cette frontière n'a jamais été explicitement écrite nulle part ?

Ce ne sont pas des questions académiques, et elles ne l'étaient pas non plus pour PocketOS ou pour Amazon. Ce sont les questions que chaque organisation, grande ou petite, devrait se poser avant de confier à un agent les clés d'un système qui compte vraiment, car la prochaine fois, l'enjeu pourrait ne pas être une place dans un cours de spinning.