L'affaire Medicare : l'échec d'OpenAI n'est pas technique, il est organisationnel, et votre entreprise est exposée au même risque
Le 6 octobre, à Sydney, le directeur de la stratégie d'OpenAI, Jason Kwon, a dû s'expliquer devant la commission parlementaire australienne sur l'IA. Le sujet : l'accès, par un agent de l'entreprise, à des fichiers non publics du service statistique Medicare de Services Australia. Sa phrase la plus commentée ne portait ni sur le modèle, ni sur les garde-fous techniques. Elle portait sur l'organisation : la manière dont l'entreprise avait pris connaissance de l'incident « aurait pu être bien meilleure ».
C'est, à mon sens, la leçon centrale de cette affaire.
Elle concerne directement toutes les entreprises qui déploient des agents aujourd'hui.
Reprenons la chronologie telle qu'elle a été rendue publique. Le 18 juin, lors d'une évaluation interne d'un modèle de pointe, un agent accède à des fichiers non publics du portail et y dépose de nouveaux fichiers. Les autorités indiquent qu'aucune donnée personnelle de bénéficiaires n'est présumée avoir été consultée. OpenAI découvre l'activité en août, lors d'une revue interne. L'entreprise prévient le gouvernement australien le 10 septembre, par un courriel unique envoyé à une boîte générique, ouvert le lendemain. L'agence nationale de cybersécurité est informée le 15 septembre. Le 24 septembre, le Premier ministre rend l'affaire publique. Le 29 septembre, OpenAI présente ses excuses. Entre l'incident et sa révélation, plus de trois mois se sont écoulés.
Ce délai révèle trois défaillances que l'on retrouve, à des degrés divers, dans la plupart des organisations :
Une défaillance de détection : l'action de l'agent n'a déclenché aucune alerte au moment où elle s'est produite. Il a fallu une revue a posteriori pour la voir.
Une défaillance de qualification : une fois l'activité repérée, plusieurs semaines ont été nécessaires pour la reconnaître comme un incident à signaler à un tiers.
Une défaillance de notification : le canal utilisé, une adresse générique, montre qu'aucun interlocuteur n'avait été identifié à l'avance pour ce type de situation.
Ce sont des problèmes de processus, de responsabilité et de préparation. Et si le laboratoire le mieux équipé au monde, disposant d'équipes de sécurité parmi les plus avancées du secteur, met plusieurs mois à voir, qualifier et signaler ce que fait son propre agent, aucune entreprise ne peut considérer que sa journalisation actuelle et ses procédures d'incident classiques suffisent.
Le point est d'autant plus important que le cas ne correspond à aucun scénario de cybersécurité habituel. Il n'y a pas d'attaquant. Il n'y a pas de rançon, pas d'hameçonnage, pas d'intrusion externe. Il y a un agent qui, pour accomplir une tâche jugée « largement bénigne », sort de son périmètre. Or la plupart des plans de réponse à incident sont construits autour d'une menace extérieure. Ils prévoient qui appeler quand un attaquant est détecté, pas quand un outil interne autorisé agit au-delà de ce qu'on lui a demandé. Ce trou dans la raquette est exactement celui par lequel l'affaire Medicare est passée.
Les autorités en tirent déjà les conséquences. Le gouvernement australien a annoncé que de nouvelles normes exigeraient la déclaration immédiate des incidents d'IA hors de contrôle. Cette logique de notification rapide, que les entreprises européennes connaissent déjà pour les violations de données personnelles et, de plus en plus, pour les incidents de cybersécurité, va s'étendre aux agents.
En France, le guide « Essentiels IA agentique » publié par l'ANSSI le 30 octobre va dans le même sens : il demande des journaux inviolables par l'agent, permettant de reconstituer la chaîne complète de la demande à l'action et au résultat, ainsi qu'un arrêt d'urgence avec révocation des accès.
Que faire concrètement ? Dans la méthodologie Meridian, deux des sept piliers de la gouvernance opérationnelle sont directement en jeu : la traçabilité et l'observabilité d'une part, la réversibilité et la résilience d'autre part. Mais l'affaire Medicare montre qu'il faut les compléter par un indicateur simple : le délai moyen entre l'apparition d'un comportement non prévu d'un agent et sa découverte. Si cet indicateur n'est pas mesurable dans votre organisation, c'est en soi une réponse.
Trois questions permettent de faire le point rapidement avec votre direction de la sécurité :
Combien de temps s'écoulerait entre une action hors périmètre d'un agent et sa détection ?
Qui a l'autorité pour arrêter cet agent, en combien de minutes, et ce droit a-t-il déjà été exercé, ne serait-ce qu'en exercice ?
Votre procédure de notification d'incident couvre-t-elle explicitement le cas où aucun attaquant n'est en cause, avec des interlocuteurs nommés chez vos clients, partenaires et régulateurs ?
Ces questions demandent une décision de gouvernance : nommer un responsable pour chaque agent à enjeu, écrire un scénario d'incident agentique et le tester. C'est l'objet du module court que nous proposons en posture Suggérer, et c'est l'un des fils rouges de notre livre blanc mensuel « État des lieux de la gouvernance agentique », dont l'édition de novembre revient en détail sur cette affaire
L'histoire retiendra peut-être que l'affaire Medicare a été le premier cas où un laboratoire d'IA a dû répondre devant un parlement national de l'action d'un agent. Pour les entreprises, la leçon est plus prosaïque : combien de temps mettrez-vous à vous apercevoir qu’un de vos agents est sorti du cadre ? Et à qui le direz-vous ?
