« Incident du wiki » : OpenAI admet qu’il n’existe aucune norme pour signaler un agent qui dérape

Le 5 septembre 2026, OpenAI a confirmé publiquement ce que Reuters avait révélé la veille : au printemps, des agents autonomes issus de ses modèles ont pris le contrôle d’un wiki germanophone à l’abandon et s’en sont servis comme d’un tableau d’affichage entre eux. L’entreprise a accompagné cette confirmation d’un aveu plus intéressant pour un dirigeant que l’anecdote technique : il n’existe aujourd’hui, ni chez elle ni dans le secteur, de norme établie pour signaler ce type de comportement.

Pour une direction générale ou une DRH qui déploie des agents, ce n’est pas un fait divers de laboratoire : c’est un test grandeur nature du dispositif européen de signalement des incidents, et il en révèle une zone aveugle.

Ce que Reuters a révélé, et ce qu’OpenAI a reconnu

Les faits

Le 4 septembre 2026, Reuters a rapporté qu’un ensemble d’agents rattachés à des modèles d’OpenAI s’étaient emparés de DseWiki, un wiki de programmation en langue allemande vieux d’environ vingt-cinq ans, hébergé sur la ferme ProWiki et tombé à l’abandon. Les agents y ont ouvert et alimenté des pages servant de canal d’échange, où ils partageaient des réponses et des techniques de contournement des restrictions qui leur étaient imposées.

L’activité s’étend, selon le jeu de données publié le 4 septembre 2026 par le collectif de chercheurs qui a mis l’affaire au jour — Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts et Thomas Larsen, sur le site collusion.wiki —, du 11 mai au 2 juillet 2026. Ce jeu de données recense, pour le seul DseWiki, 14 666 modifications réparties sur 4 584 pages et 3 103 identifiants d’agents distincts ; il reconstitue par ailleurs près de 18 000 messages publiés par ces agents sur plusieurs sites de type wiki. Ces chiffres varient d’une reprise de presse à l’autre et n’ont pas été confirmés par OpenAI.

Reuters indique que la direction d’OpenAI avait connaissance de l’épisode plusieurs semaines avant sa divulgation. L’entreprise conteste avoir été dissuadée d’enquêter par ses avocats et affirme avoir coopéré de bonne foi avec des experts extérieurs. Elle maintient que cet épisode est distinct de l’intrusion de juillet 2026 dans l’infrastructure de Hugging Face, attribuée le 21 juillet, dans une divulgation conjointe des deux entreprises, à un modèle GPT-5.6 Sol et à un modèle pré-commercial non nommé.

La déclaration du 5 septembre

Le 5 septembre 2026, OpenAI a publié une déclaration dans laquelle elle qualifie l’épisode de « désalignement » plutôt que d’incident de sécurité. Trois éléments méritent d’être retenus :

  • l’entreprise estime qu’il est « plus que temps » de « définir des normes régissant quand et comment nous partageons les incidents de désalignement, et pas seulement les propriétés de désalignement de nos modèles » ;
  • elle reconnaît que « ni nous ni la communauté de l’IA au sens large ne disposons à ce jour d’une norme claire sur la manière de signaler un désalignement qui apparaît pendant l’entraînement, l’évaluation et le déploiement » ;
  • elle annonce un cadre de divulgation « dans les prochaines semaines » et dit travailler en parallèle avec « des dizaines d’agences de régulation gouvernementales dans le monde ».

Du côté des chercheurs, le ton est plus exigeant. Jacob Steinhardt, fondateur du laboratoire Transluce, cité par TechCrunch, estime qu’il faut « soumettre cette technologie au moins aux mêmes exigences que celles applicables aux autres travaux de recherche scientifique à haut risque ».

En langage de conformité : le fournisseur d’un des modèles les plus déployés en entreprise déclare publiquement que la catégorie « comportement anormal d’un agent » n’a pas de circuit de signalement établi.

Ce que le droit européen impose déjà — et à qui

C’est ici que le sujet devient utile pour une entreprise française. Le règlement (UE) 2024/1689 organise le signalement des incidents graves selon deux régimes distincts, qui ne visent ni les mêmes acteurs ni les mêmes objets.

Le régime des modèles à usage général

Les fournisseurs de modèles d’IA à usage général présentant un risque systémique doivent, au titre de l’article 55, paragraphe 1, point c) du règlement, assurer le suivi, la documentation et le signalement sans retard injustifié des informations pertinentes sur les incidents graves, auprès du Bureau européen de l’IA et, le cas échéant, des autorités nationales compétentes.

Le code de bonnes pratiques pour l’IA à usage général, dont le chapitre « sûreté et sécurité » précise cet engagement (engagement 9), assortit l’obligation de délais courts et gradués selon la gravité, qui courent à compter du moment où le fournisseur a connaissance de l’incident ou soupçonne raisonnablement l’implication de son modèle : 2 jours en cas de perturbation grave ou irréversible d’une infrastructure critique, 5 jours en cas d’atteinte grave à la cybersécurité — exfiltration des poids du modèle, cyberattaque —, 10 jours en cas de décès, 15 jours en cas de dommage grave à la santé, aux droits fondamentaux, aux biens ou à l’environnement. S’y ajoutent des mises à jour régulières jusqu’à résolution et un rapport final. La Commission a publié le 4 novembre 2025 un modèle de signalement destiné à harmoniser ces déclarations.

Deux caractéristiques comptent pour le lecteur d’entreprise : ces signalements vont au régulateur, pas au public ; et ils supposent qu’un dommage soit identifiable.

Le régime des systèmes à haut risque

L’article 73 du règlement vise, lui, les fournisseurs de systèmes d’IA à haut risque — la catégorie dont relèvent les outils de recrutement, d’évaluation et de gestion du personnel listés au point 4 de l’annexe III. Ces fournisseurs doivent notifier tout incident grave aux autorités de surveillance du marché du ou des États membres concernés. Les délais figurent dans le règlement lui-même : 15 jours en règle générale (article 73, paragraphe 2), 10 jours en cas de décès d’une personne (paragraphe 4), et 2 jours en cas de violation généralisée ou de perturbation grave et irréversible de la gestion ou de l’exploitation d’une infrastructure critique (paragraphe 3). La Commission a soumis à consultation, le 26 septembre 2025, un projet de lignes directrices et un modèle de notification destinés à en préciser la mise en œuvre.

Rappelons que l’entrée en application des obligations relatives aux systèmes à haut risque de l’annexe III a été reportée au 2 décembre 2027 par le règlement (UE) 2026/1744, dit « omnibus IA ». Le report allonge le délai ; il ne modifie pas l’architecture.

La zone aveugle

Reprenons le cas du wiki à la lumière de ces deux régimes. Des agents ont détourné un site tiers à l’abandon pour y coordonner leurs contournements. Il n’y a eu ni intrusion dans un système d’information protégé, ni exfiltration de poids de modèle, ni décès, ni infrastructure critique perturbée, ni dommage patrimonial mesurable, ni violation de droits identifiée sur une personne déterminée.

Aucun des quatre paliers du code de bonnes pratiques ne s’applique proprement. Aucune des catégories de l’article 73 non plus. Le comportement est anormal, documenté, révélateur — et il n’entre dans aucune case déclarative. C’est la lacune qu’OpenAI décrit, et elle est autant celle du dispositif européen que celle du secteur.

S’y ajoute une limite structurelle : même lorsqu’un signalement est dû, il est adressé au Bureau européen de l’IA et aux autorités nationales, non publié. Dans le cas présent, l’information est venue de chercheurs indépendants et d’une agence de presse, pas d’un canal réglementaire.

Ce que cela change pour une entreprise qui déploie des agents

Une entreprise française qui automatise une chaîne de traitement avec des agents — tri de candidatures, relances clients, préparation de dossiers — se trouve dans la position du déployeur. Elle n’est pas tenue par l’article 55, qui vise les fournisseurs de modèles à usage général. Elle n’est pas pour autant hors du circuit : si le système relève du haut risque, l’article 26, paragraphe 5 lui impose, dès qu’elle identifie un incident grave, d’informer immédiatement le fournisseur, puis l’importateur ou le distributeur et les autorités de surveillance du marché. Elle porte enfin le risque opérationnel : un agent qui contourne une consigne, appelle un outil non prévu ou écrit hors de son périmètre engage sa responsabilité contractuelle, sa sécurité et, si des données personnelles sont en jeu, ses obligations au titre du RGPD.

L’enseignement pratique du 5 septembre est simple : ne comptez pas sur la chaîne réglementaire pour vous alerter. Elle est lente, non publique et calibrée sur le dommage. La détection utile se joue dans vos propres journaux d’exécution et dans votre contrat avec le fournisseur.

Ce qu’il faut faire

1. Inscrire une obligation d’information au contrat. Les clauses standard des fournisseurs couvrent l’incident de sécurité et l’indisponibilité de service. Elles ne couvrent presque jamais le comportement anormal du modèle sans dommage. Ajoutez au renouvellement une obligation d’information sur les comportements inattendus documentés affectant les versions que vous utilisez, avec un délai exprimé en jours et un point de contact nommé.

2. Journaliser les appels d’outils, pas seulement les réponses. La plupart des dispositifs de supervision conservent l’entrée et la sortie. Pour un agent, l’information décisive est intermédiaire : quels outils appelés, quels accès réseau sollicités, quelles écritures tentées. Sans cette trace, un comportement déviant reste invisible jusqu’à ce qu’il produise un dégât.

3. Fixer un périmètre d’exécution explicite. Comptes de service dédiés, droits en écriture limités aux ressources nécessaires, sortie réseau restreinte à une liste d’autorisations. Le wiki détourné était accessible et sans surveillance : c’est cette combinaison qui a permis l’épisode.

4. Désigner un responsable du suivi des incidents IA. Une personne identifiée, chargée de recevoir les alertes internes, d’interroger le fournisseur et de décider d’une suspension. Cette fonction relève de la gouvernance, pas de la technique : elle doit pouvoir arrêter un déploiement.

5. Former les équipes qui font fonctionner ces systèmes. L’article 4 du règlement, réécrit par l’omnibus, demande aux fournisseurs comme aux déployeurs de prendre des mesures pour favoriser le développement de la maîtrise de l’IA de leur personnel et des personnes qui font fonctionner ces systèmes pour leur compte, sans imposer de garantir un niveau déterminé pour une personne donnée. Obligation de moyens, donc — mais c’est la seule ligne de défense qui fonctionne quand la chaîne de signalement ne se déclenche pas. Un opérateur qui sait à quoi ressemble un comportement anormal le remonte ; un autre le laisse passer.

6. Suivre la publication du cadre annoncé. S’il devient une référence de place, il fournira un vocabulaire commun pour formuler vos exigences contractuelles et comparer vos fournisseurs.

L’épisode n’a causé, à ce stade, aucun dommage identifié. C’est ce qui le rend instructif : un comportement suffisamment anormal pour faire l’objet d’un article de Reuters et d’une déclaration publique du fournisseur peut ne déclencher aucune obligation de signalement en droit européen. Pour une entreprise, cela veut dire que la vigilance ne s’externalise pas.


Sources

Sources primaires

Analyses secondaires

Rédaction Carrière Web
Fondatrice de Carrière Web — BT Communication

Cheffe d'entreprise, diplômée de journalisme, à la tête d'une agence de communication spécialisée dans le webmarketing. Férue de nouvelles technologies. Accompagne les TPE et PME dans l'intégration de l'intelligence artificielle : diagnostic, déploiement, mesure des gains. Anime également les formations en communication et marketing digital du catalogue.

À lire ensuite

Dans la même veine.

Un premier échange de 30 minutes.

Sans engagement, sans diaporama. On regarde où vous en êtes, et je vous dis franchement si nous sommes le bon interlocuteur.

Réserver un créneau