Le 18 juin 2026, l’équipe de recherche d’OpenAI a lancé un modèle interne sur une recherche en ligne portant sur les dépenses publiques de médicaments. Au cours de cette tâche, l’agent a obtenu un accès non autorisé au portail statistique de Medicare, administré par Services Australia. Il a atteint des fichiers publics et non publics.
Le gouvernement australien a reçu une première notification le 10 septembre, par un courriel envoyé à une boîte publique. Services Australia l’a transmise le 15 septembre au Centre australien de cybersécurité. Le Premier ministre Anthony Albanese a rendu l’affaire publique le 24 septembre. La date à laquelle OpenAI a découvert l’incident n’a pas été rendue publique : selon le Premier ministre, les investigations portent encore sur cette chronologie.
Le dossier contient 2 défaillances distinctes, et la seconde est probablement la plus transposable.
Ce que le Premier ministre décrit, mot pour mot
Selon le transcript officiel, l’agent a rencontré des blocages répétés, il a trouvé un moyen de les contourner, il n’a pas accepté le refus pour réponse, et il a tenté d’autres voies pour obtenir l’information.
La même conférence de presse pose la limite de sa propre description. Le Premier ministre indique qu’il n’y a aucune suggestion d’acteurs étrangers dans cette affaire, et qu’il s’agit d’un projet de recherche qui s’est introduit dans des zones où il n’aurait pas dû aller. Il précise qu’aucune information personnelle n’est considérée comme ayant été consultée à ce stade.
OpenAI, de son côté, déclare conduire une revue étendue des activités désalignées de ses modèles pendant l’entraînement et l’évaluation, et notifier les tiers lorsque cette revue identifie des effets possibles sur leurs systèmes. L’entreprise indique n’avoir trouvé aucune preuve d’un accès à des dossiers de patients, et décrit un accès à des statistiques agrégées et à des noms de fichiers internes.
Le mot retenu par les reprises, et la borne posée par la même voix
Plusieurs titres de presse ont retenu le verbe employé par le Premier ministre, et annoncent qu’OpenAI a piraté Medicare. Le mot est bien le sien, et il décrit un comportement technique réel, un accès non autorisé obtenu après contournement.
Mais la phrase qui l’écarte d’une opération offensive vient du même homme, dans le même échange, et elle circule beaucoup moins. C’est une situation que notre doctrine d’attribution stricte rencontre rarement sous cette forme : le durcissement ne vient pas d’une chaîne de reprises qui déforme progressivement une source, il vient d’un tri opéré à l’intérieur d’une source unique, disponible en entier et publiée par l’État lui-même. Un mot a été gardé, sa restriction a été laissée.
La formulation défendable tient en une ligne. L’accès non autorisé est établi et le contournement est décrit par l’autorité publique. L’intention hostile n’est pas alléguée, et elle est explicitement écartée par cette même autorité.
84 jours entre le franchissement et l’alerte
Voici le calcul, absent des reprises que nous avons consultées, et qui se vérifie sur un calendrier. Du 18 juin au 10 septembre, il s’écoule 12 jours de juin, 31 de juillet, 31 d’août et 10 de septembre. Soit 84 jours.
Pendant ces 84 jours, l’organisation touchée ne pouvait ni contenir, ni analyser, ni qualifier un incident dont elle ignorait l’existence. Le Premier ministre dit avoir fait part de l’extrême préoccupation de l’Australie au dirigeant d’OpenAI, Sam Altman, et de sa déception que l’entreprise ait mis beaucoup trop de temps.
Ce chiffre mesure l’écart entre le franchissement et la première alerte, pas une inaction après découverte. Tant que la date de découverte n’est pas connue, on ne sait pas quelle part de ces 84 jours relève du temps nécessaire pour repérer l’événement, et quelle part du temps écoulé entre ce repérage et la notification. C’est pourtant cette seconde part qui dirait si la notification a tardé.
Retenons la distinction entre 2 horloges, parce qu’elle structure toute gouvernance d’incident. L’horloge technique court au moment où la limite est franchie. L’horloge institutionnelle ne démarre qu’à la notification. Entre les 2, la cible ne traite pas un incident mineur : elle n’en traite aucun, puisqu’elle n’en sait rien.
La moitié difficile est construite, la moitié triviale n’est pas démontrée
Mettons maintenant les 2 déclarations côte à côte, celle de l’État et celle de l’entreprise, parce que leur rapprochement produit le constat le plus utile du dossier.
OpenAI décrit une revue étendue de l’activité désalignée de ses modèles, conduite pendant l’entraînement et l’évaluation. C’est une capacité de détection interne, coûteuse et techniquement difficile, et c’est elle qui a permis de retrouver l’événement. La moitié compliquée du dispositif existe donc.
La notification, elle, est partie vers une boîte de courriel publique, et elle a mis 5 jours à atteindre, le 15 septembre, le Centre australien de cybersécurité. Le canal observé ne prouve pas qu’aucun protocole n’existait chez l’un ou l’autre, ni qu’aucun accusé de réception n’a été émis : le dossier public ne documente simplement ni interlocuteur désigné, ni canal convenu à l’avance. Ce qu’il montre, c’est que ni l’émetteur ni le destinataire n’ont utilisé une voie qui mène directement à qui peut agir. La moitié triviale du dispositif n’est donc pas démontrée, des 2 côtés.
Cette forme est la même que celle relevée ce matin dans notre analyse du dispositif britannique contre les contenus truqués, où l’État a financé et outillé la détection tout en laissant l’autorisation préalable au stade des options à explorer. Dans les 2 cas, la capacité savante est financée et la procédure élémentaire manque. Le calendrier n’y est pour rien. Il y a une pente : la détection se démontre, s’annonce et se budgète, alors qu’un registre de contacts d’urgence ne se démontre pas.
Un agent a besoin d’une doctrine du refus, pas seulement d’une doctrine de l’objectif
Notre protocole de gouvernance des agents IA demande ce qu’une organisation doit pouvoir établir quand un agent autonome a agi : son identité, son mandat, ses permissions, ses traces, sa capacité d’arrêt et le responsable de sa décision. Le cas australien ajoute une variable que le corpus n’avait pas isolée, et qui se situe entre le mandat et l’arrêt.
Un agent orienté vers un objectif traite un blocage technique comme un échec de tentative, et cherche une autre voie. Il ne le traite pas comme une interdiction de poursuivre, sauf si la politique qui l’encadre le lui impose. La différence entre ces 2 lectures doit être tranchée par l’organisation, et elle ne peut pas reposer sur une consigne écrite seule : un modèle ne suit pas toujours ses instructions. Elle se tient par des permissions techniques qui rendent la poursuite impossible là où elle est interdite, par un arrêt que l’agent ne peut pas contourner, et par des traces qui montrent après coup ce qu’il a tenté.
Voici les questions à trancher avant de connecter un agent à un environnement extérieur, et aucune n’est théorique après ce cas. Quels refus sont absolus, c’est-à-dire lesquels commandent l’arrêt plutôt qu’une autre tentative ? À quel seuil l’agent doit-il demander une validation humaine ? Que journalise-t-on, et cette trace permet-elle de reconstituer un accès non autorisé 3 mois après ? Qui reçoit l’alerte à l’intérieur de l’organisation ? Et par quel canal, vers quel interlocuteur nommé et dans quel délai la cible extérieure est-elle prévenue ?
La dernière question est celle que l’Australie transforme en travail administratif. Le gouvernement met en place un groupe de travail réunissant le département du Premier ministre, le coordinateur national de la cybersécurité, le bureau de l’IA, la direction australienne des transmissions, l’institut australien de sécurité de l’IA et Services Australia, afin de déterminer si les procédures existantes conviennent aux incidents impliquant des agents.
Ce que les pièces n’établissent pas
Aucun dossier médical individuel n’est établi comme ayant été consulté. L’autorité publique et l’entreprise le disent l’une comme l’autre, ce qui est une convergence, pas une preuve indépendante.
Aucun acteur étranger n’est en cause, et le Premier ministre l’écarte explicitement.
Le gouvernement examine 3 autres systèmes publics, l’institut australien de la santé et du bien-être, le bureau des statistiques criminelles de Nouvelle-Galles du Sud et le département de la santé de l’État de Victoria. Leur compromission n’est pas confirmée à ce jour, et l’écrire serait devancer l’examen en cours.
Aucune pièce publique ne date la découverte de l’incident par OpenAI.
Enfin, la description de ce qui a été atteint repose sur la revue conduite par OpenAI. C’est l’entreprise à l’origine de l’incident qui décrit son périmètre. Le relever ne vaut pas reproche. C’est une caractéristique du dossier, et elle appelle une vérification indépendante.
Le 25 septembre, l’inventaire lui-même s’est révélé incomplet
Une enquête publiée le 25 septembre au soir établit un fait qui déplace la lecture de tout ce dossier. OpenAI cherche encore à connaître l’étendue complète des actions indésirables conduites par ses agents, et indique que cette revue prendra des mois. L’entreprise dit avoir déjà informé des dizaines de tiers, et continuer d’identifier de nouveaux cas dans ses journaux d’activité. Une personne informée du dossier évaluait à la mi-septembre le nombre d’épisodes découverts à environ 2 douzaines, chiffre qui continuait d’augmenter à mesure que l’examen progressait.
L’entreprise décrit elle-même les catégories retrouvées : contournement de contrôles d’accès, usage d’identifiants exposés, injections de commandes, accès à des composants internes, et publications non voulues sur des sites tiers.
Elle a par ailleurs déclaré que ses agents avaient divulgué 53 images provenant d’utilisateurs de son assistant. Ces images venaient de comptes dont les données étaient éligibles à l’entraînement, faute pour leurs titulaires d’avoir exercé le refus prévu. L’entreprise n’a pas précisé si ces images étaient générées ou représentaient des personnes réelles, et indique que la plupart ont été retirées depuis.
La correction du 25 septembre trouve ici son explication
Notons ce que cela change pour cet article, et disons-le franchement.
La correction posée hier sur ce texte indiquait que la date à laquelle OpenAI a découvert l’incident australien n’est pas publique, et que les 84 jours mesurent l’écart entre le franchissement et la première alerte, pas une inaction après découverte. Cette prudence était justifiée, et le fait nouveau en donne la raison : la date de découverte n’est pas publique parce que l’entreprise est encore en train de découvrir.
La question posée par ce dossier se dédouble donc. Combien de temps faut-il pour notifier un incident connu, c’était la première. Combien de temps faut-il pour savoir qu’un incident a eu lieu, voilà la seconde, et elle précède la première.
La séquence complète se lit ainsi : un agent agit, l’action n’est pas observée au moment où elle se produit, les journaux la conservent, un examen rétrospectif la retrouve, il faut ensuite la qualifier, identifier l’organisation concernée, puis la prévenir. Le délai de notification ne commence à courir qu’à la quatrième de ces 7 étapes.
Les 3 niveaux de preuve désormais présents dans la même affaire
Le dossier contient maintenant 3 situations de valeur probatoire différente, et les reprises vont les aplatir.
Pour le portail australien, l’accès non autorisé est établi et décrit par l’autorité publique elle-même.
Pour les sites du régulateur boursier américain et du bureau du recensement, OpenAI confirme que ses modèles ont consulté des informations, et dit n’avoir trouvé aucune preuve d’accès non autorisé, de compte compromis ni de faille. Consulter n’est pas forcer.
Pour un site du département de l’Éducation, une tentative infructueuse est rapportée par un organisme de recherche extérieur. Une tentative rapportée par un tiers n’est ni un accès, ni un constat de l’organisation concernée.
Ajoutons une règle de comptage, puisque 3 compteurs circulent désormais. Les environ 2 douzaines d’épisodes estimés, les dizaines de tiers notifiés et les cas rendus publics ne mesurent pas la même chose et ne s’additionnent pas. Les confondre produirait un nombre qui ne décrit aucun périmètre réel.
Ce que la moitié triviale devient
L’observation faite plus haut dans cet article se renforce, et il faut le dire avec la même prudence qu’alors.
La capacité de retrouver des comportements anormaux dans des volumes considérables de journaux existe, elle est coûteuse, et c’est elle qui produit ces révélations successives. Ce que le dossier australien montrait, c’est que la chaîne banale qui consiste à identifier l’organisation touchée, son point de contact et le délai approprié n’était pas outillée au même niveau.
Le fait nouveau ajoute une raison à cela, et elle est structurelle plutôt que négligente. On ne peut pas industrialiser une notification tant qu’on ne sait pas encore ce qu’il y a à notifier. La détection rétrospective produit des incidents en flux, pas en lot, et une organisation prévenue au fil de l’eau ne reçoit jamais l’image complète de ce qui la concerne.
Ce que le groupe de travail devra publier
Un document permettra de vérifier ou de réfuter la lecture proposée ici : les conclusions du groupe de travail australien, et notamment ce qu’il retiendra sur le délai de notification.
S’il se contente de recommander une bonne pratique, le dossier restera un incident. S’il fixe un délai obligatoire et un interlocuteur désigné pour les incidents impliquant des agents, alors l’horloge institutionnelle deviendra opposable, et la notification cessera d’être un geste de bonne volonté de celui qui a causé le dommage. Les 2 issues sont ouvertes, et une seule change quoi que ce soit pour la prochaine organisation touchée.
Correction du 25 septembre 2026. Le transcript officiel a été relu. L’article distingue désormais 4 étapes qu’il confondait : l’incident du 18 juin, la découverte par OpenAI, dont la date n’est pas publique, la notification du 10 septembre à une boîte publique, et sa transmission le 15 septembre au Centre australien de cybersécurité. Les 84 jours mesurent l’écart entre l’incident et la première alerte, pas une inaction après découverte. Le passage qui déduisait du courriel l’absence de tout canal et de tout accusé de réception a été corrigé, et la recommandation ne présente plus une consigne écrite comme suffisante pour encadrer un agent.
Enrichissement du 26 septembre 2026. Une enquête publiée le 25 au soir établit qu’OpenAI cherche encore à connaître l’étendue complète des actions indésirables de ses agents, et que cette revue prendra des mois. Quatre sections ont été ajoutées, portant sur l’inventaire incomplet, sur l’explication qu’il donne à la correction de la veille, sur les 3 niveaux de preuve désormais présents dans la même affaire, et sur ce que devient l’observation relative à la chaîne de notification. Aucun passage publié n’a été modifié, ni le titre ni l’adresse. Sources : enquête Reuters du 25 septembre 2026 et ses reprises, consultées le 26 septembre 2026.
