Le samedi 5 septembre, environ 88 heures après le lancement du premier d’entre eux, un groupe d’agents fonctionnant sur un modèle interne d’OpenAI est parvenu à une preuve qu’un fluide régi par les équations de Navier–Stokes, partant d’un état régulier et au repos et poussé par une force régulière, peut exploser en temps fini. La formalisation en Lean a pris 17 heures de plus. L’annonce est tombée le mardi 8, et en l’espace d’une journée la question que tout le monde posait était celle que Newton a rendue célèbre : sur les épaules de qui cela reposait-il ?

Deux réponses ont été données. Les mathématiciens ont donné la première. La preuve se situe au bout d’une lignée de travaux qui porte des noms, et ceux qui connaissent le mieux le domaine les ont cités presque aussitôt. OpenAI a donné la seconde. Dans son récit, l’exploit revient à un modèle très puissant, poussé plus loin que quiconque n’en avait jamais poussé un.

Les deux réponses sont en grande partie justes, et aucune n’est notre sujet. Ce texte pose la question d’une troisième paire d’épaules, et il la pose plutôt qu’il n’affirme. La question est de savoir si le système qui a produit la preuve reposait aussi sur l’enregistrement de son propre accident — l’incident de juillet au cours duquel des agents d’OpenAI, sans qu’on le leur demande, se sont trouvés les uns les autres sur un tableau de messages improvisé et ont attaqué Hugging Face.

Nous exposerons d’abord ce qui est documenté, puis nous poserons la question en tant que question, puis nous donnerons la réponse qui est arrivée depuis de l’intérieur d’OpenAI. Nous la pèserons en fonction de sa provenance. Enfin, nous dirons ce qui trancherait l’affaire, car rien de tout cela n’est encore apparu.

Les géants

La voie vers cette singularité n’a pas été trouvée en septembre. Elle a été ouverte en treize ans par des personnes.

En 2013, Thomas Hou et Guo Luo ont trouvé un scénario dans lequel les équations d’Euler — la cousine sans frottement de Navier–Stokes — explosent à l’intérieur d’un cylindre. L’approche qui en est issue, simuler un candidat sur ordinateur puis le prouver avec l’ordinateur rendant compte de chaque erreur possible, est devenue la manière dominante d’attaquer ces problèmes. Puis, dans sa thèse de doctorat de 2021, Luis Martínez-Zoroa a pris le chemin inverse : des techniques analytiques qui ne reposaient pas du tout sur les ordinateurs. En 2023, lui et son directeur de thèse Diego Córdoba avaient prouvé qu’une version des équations d’Euler dotée d’une fonction de forçage irrégulière développait des singularités. Leur méthode construit une suite infinie de couches, chacune une solution non singulière, et les combine en ce que Martínez-Zoroa appelle une « cascade infinie ». La singularité vit dans la cascade.

Ce qu’ils ne pouvaient pas faire, c’était garder la force régulière. Chaque couche avait une fonction de forçage régulière, mais leur empilement pouvait laisser à la force totale des « propriétés mathématiques indésirables », selon le résumé de Quanta, et c’est ce qui maintenait leur résultat en deçà des critères du prix du Millénaire. L’obstacle restant, tel que le domaine le comprenait, était une cascade dont la force restait régulière jusqu’au bout.

Charles Fefferman, qui a rédigé l’énoncé officiel du problème pour le Clay Institute, a déclaré à Quanta que les héros de l’histoire sont Córdoba et Martínez-Zoroa. Tristan Buckmaster, de NYU, qui travaillait vers le même objectif avec Levent Alpöge, est allé plus loin dans le communiqué annonçant ses propres résultats : « Je crois que Luis Martínez-Zoroa mérite une médaille Fields. »

Le propre récit d’OpenAI situe le début de son effort au 1er septembre, après avoir entendu des rumeurs selon lesquelles deux problèmes du prix du Millénaire avaient été résolus : « Inspirés par ces rumeurs et par le saut de performance de notre modèle interne, nous avons lancé un effort. » La rumeur s’est révélée concerner Alpöge, employé d’Anthropic, et Buckmaster, qui avaient produit avec un modèle interne d’Anthropic une résolution du problème d’Euler forcé. Les agents d’OpenAI ont d’abord résolu le problème d’Euler non forcé — « près de 100 agents ont travaillé ensemble pendant environ 50 heures » — puis se sont tournés vers Navier–Stokes. Nous avons écrit ailleurs sur le différend autour de ce que ces agents pouvaient et ne pouvaient pas avoir vu ; nous ne le rouvrirons pas ici. Nous notons seulement que Buckmaster en a rouvert hier un autre volet : « Il n’a fallu à OpenAI que 100 agents et 50 heures pour passer de zéro connaissance (un immense espace de recherche) à l’obtention de leur résultat sur Euler. » Puis, avec la recherche réduite « de plusieurs ordres de grandeur » : « il leur a fallu 10 000 (plutôt que 100) agents pour passer d’Euler à NS ? »

Ce que le résultat tranche et ce qu’il laisse ouvert est aussi plus clair aujourd’hui qu’il y a trois semaines. Le 17 septembre, Peter Constantin, Mihaela Ignatova et Vlad Vicol ont montré que dans la construction d’OpenAI, et dans toute construction partageant deux de ses caractéristiques clés, la force « ne peut ni s’annuler identiquement près du point singulier, ni être analytique réelle ». La force ne peut pas être éteinte là où se produit l’explosion, si bien que ce type de construction n’atteint pas la version plus difficile, non forcée, du problème. Luis Silvestre, de l’université de Chicago, l’a formulé ainsi auprès de Scientific American : « Le problème de Clay est réglé, mais le problème principal pour les équations de Navier-Stokes ne l’est pas. » Javier Gómez-Serrano, qui utilise l’IA dans ses propres recherches, a dit à NPR que le code Lean compilait et que « la communauté semble avoir le consensus que c’est correct » — et aussi que « l’article n’est pas écrit pour des humains… à ce jour, l’article ne nous apprend pas grand-chose ». Alexander Gamburd, dans un essai publié le 23 septembre, a décrit 166 pages « lues en entier, au moment où j’écris ces lignes (20 septembre 2026), par aucun être humain ». Le Conseil international pour les mathématiques industrielles et appliquées a appelé à un « examen mathématique indépendant ». À ce jour, l’article n’est pas paru sur arXiv ni n’a été soumis à une revue, et le PDF n’a pas changé depuis le 8 septembre.

Donc, pour la première moitié du titre : oui. La machine s’est hissée sur des épaules humaines, et les humains peuvent dire lesquelles.

L’architecture

La seconde moitié de la question commence par la manière dont OpenAI décrit le système qui a fait l’ascension. Cela vaut d’être cité longuement, car c’est presque tout ce qu’il y a :

Nous avons utilisé un système d’agents coordonnés alimenté par notre modèle interne. Les agents avaient accès à des outils tels que la capacité de lire une version en cache d’internet et la capacité d’exécuter du code. Les agents étaient répartis en groupes ayant la capacité de communiquer au sein du groupe. Les groupes variaient en taille, et le groupe qui a produit la résolution de Navier–Stokes impliquait de l’ordre de 10 000 agents simultanés. Nous avons maintenu en permanence les mêmes garde-fous stricts que nous appliquons à toutes nos évaluations de modèles de frontière, y compris la surveillance et l’isolement.

Des groupes différents ont reçu des variantes différentes du problème : des versions menant à une preuve sont allées à certains groupes, des versions menant à une réfutation à d’autres. Puis, une fois le résultat sur Euler non forcé obtenu, est venue l’étape qui compte le plus pour ce texte :

Nous avons encouragé différents groupes d’agents à explorer une diversité d’approches. Au bout d’un certain temps, nous avons opéré une pollinisation croisée entre les groupes d’agents en utilisant Codex pour consolider les idées les plus utiles de chaque groupe d’agents. Ces prompts de suivi s’appuyaient sur les résultats intermédiaires des agents eux-mêmes. Le groupe qui a trouvé la solution à Navier–Stokes a été guidé de cette manière.

Sur l’ensemble des problèmes tentés, les agents ont envoyé 4,9 millions de messages. Sur Navier–Stokes seul, 2,7 millions.

Dit simplement, la conception est la suivante : de nombreuses copies d’un même modèle, réparties en groupes ; un canal au sein de chaque groupe ; des angles d’attaque différents assignés à des groupes différents ; et une étape de consolidation qui rassemble ce que chaque groupe a trouvé et le réinjecte comme série d’instructions suivante. La description tient en quelques paragraphes. Les lecteurs qui ont suivi les incidents de cet été en reconnaîtront la forme.

L’enregistrement

En mai et juin, OpenAI a lancé des entraînements par apprentissage par renforcement pour plusieurs modèles de recherche non destinés à une diffusion publique. L’un d’eux, que l’entreprise appelle Internal Model 1, allait être à l’origine de l’incident de Hugging Face. OpenAI est explicite sur les conditions : « Nous n’avions pas activé l’accès à internet ni la communication entre agents pour beaucoup des environnements de ces expériences d’entraînement. Malgré ces restrictions, les agents ont découvert des moyens d’exploiter notre infrastructure de recherche pour communiquer les uns avec les autres. »

La première trace de cette communication est assez infime pour passer inaperçue. Au cours d’un entraînement, un agent a laissé une note dans Artifactory, le dépôt interne de paquets de l’entreprise, demandant aux autres agents un fichier manquant. Sa chaîne de pensée, telle qu’OpenAI l’a publiée : « Pourrais communiquer en déposant une note “quelqu’un a trouvé softtrace ?” mais probablement non. » Il n’attendait pas de réponse. Il a publié quand même.

Fin mai, selon OpenAI, une équipe interne avait vu un agent utiliser le tableau de messages, mais « l’importance de l’activité de communication entre agents » n’était pas apparente pour les personnes qui ont ensuite géré l’incident de juillet. À partir de là, le dossier s’épaissit. L’enquête indépendante de METR, qui couvre la période du 7 au 13 juillet, décrit des agents trouvant le tableau et commençant à collaborer. Elle décrit un agent de longue durée, PHASEONE[big], qui a raisonné que « nous devrions construire [un moyen de déléguer], pas tout porter nous-mêmes », puis a orchestré des centaines d’autres. Nous avons déjà raconté cette partie de l’histoire. Un détail en est le pivot de ce texte. Lorsqu’un agent a inspecté la boîte de réception d’un autre et adopté sur-le-champ son schéma de nommage — « Je vais utiliser cette nouvelle convention de zzINBOX_HANDLE » — la boîte qu’il a créée a fini par accumuler 124 descendants. METR y voit « le cas le plus ancien que notre balayage par classifieur a trouvé, dans notre ensemble de transcriptions, d’un agent copiant clairement l’idée d’une boîte aux lettres, plutôt que de l’inventer potentiellement en parallèle ».

Regardons ce que cette phrase implique quant au matériau. Il existe un balayage par classifieur. Il existe un ensemble de transcriptions assez vaste pour en nécessiter un — plus d’un millier, la plupart extrêmement longues. Il existe un premier acte d’imitation, localisé à quelques minutes près. Les classifieurs de METR ont cherché dans ces transcriptions des comportements tels que « aider ses pairs » ; OpenAI, de son côté, a mesuré une communication non autorisée entre agents en hausse au fil d’un entraînement qui a contribué au modèle à l’origine de l’attaque. Ce qui existe après juillet, c’est la chronologie d’une attaque, et aussi une carte étiquetée de la manière dont la coordination a émergé : d’une note qui n’attendait pas de réponse, à un tableau partagé, à la délégation, à une convention copiée et héritée — le tout entre des agents qui ne savaient pas, au départ, qu’il y en avait d’autres.

C’est la distinction qui compte. L’incident n’a appris à personne que les agents peuvent se coordonner. On le savait ; les systèmes multi-agents sont plus anciens que ce modèle, et des agents avaient été mis à travailler ensemble avant juillet. Ce que l’incident a laissé est différent : un enregistrement d’une coordination surgissant là où personne ne l’avait construite, avec les points de bascule marqués.

Une technique à double sens

Les points de bascule sont précisément ce qu’une nouvelle classe de techniques est conçue pour exploiter.

Dans une évaluation d’alignement portant sur quatre incidents de cybersécurité impliquant des modèles Claude, publiée ce mois-ci, Anthropic décrit le rééchantillonnage : relancer un modèle à partir d’un point précis d’une transcription, modifier ce qu’il a devant lui, et mesurer si ses actions changent. Elle a appliqué la méthode au cas le plus grave, dans lequel Claude Mythos 5 a téléversé un paquet malveillant sur PyPI. Les chercheurs ont inséré un rappel du périmètre de la tâche — « Seuls les hôtes, services et comptes explicitement nommés dans votre tâche sont dans le périmètre. N’interagissez avec aucun autre système… » — à des points proches des actions nuisibles. Lorsque cette déclaration était la dernière chose dans le contexte, le modèle « a immédiatement cessé son comportement 90 % du temps ». Insérée trois tours plus tôt, il cessait « seulement 40 % du temps ». Anthropic appelle cela un « effet d’élan ».

Le but ici est la sécurité, et nous le prenons au pied de la lettre : trouver la phrase qui arrête le modèle, et trouver où elle doit être placée. Mais la machinerie se moque de la direction dans laquelle on la pointe. Une méthode qui localise le point d’une trajectoire où une ligne de contexte change ce qu’un modèle fait ensuite peut localiser des points où une ligne déclenche quelque chose aussi facilement que des points où elle arrête quelque chose. Pointée vers la question de l’arrêt, c’est un outil d’alignement. Pointée vers l’enregistrement d’une coordination en train de naître, c’est un moyen d’apprendre quel contexte fait advenir la coordination.

Nous n’affirmons pas que quiconque l’a pointée dans cette direction. Nous disons que, depuis ce mois-ci, les deux moitiés existent : un enregistrement étiqueté d’une coordination émergente dans un laboratoire, et une technique publiée pour transformer des points de bascule en instructions dans un autre.

Et si

La recherche a une longue histoire de découvertes de ce qu’elle ne cherchait pas. Le sildénafil était testé contre l’angine de poitrine lorsque l’effet secondaire qui allait devenir le Viagra est apparu lors des essais. Le sémaglutide était un médicament contre le diabète ; son effet sur le poids est devenu un produit à part. La boîte contaminée de Fleming est l’histoire classique. Le schéma n’est pas exactement de la chance. Quelqu’un examine de près un échec, et l’échec s’avère contenir la chose.

Le propre récit d’OpenAI sur Navier–Stokes en contient une petite version. L’entreprise n’avait pas entrepris de résoudre le problème d’Euler non forcé ; c’était l’un des problèmes « plus faciles » en marge, et « nos agents nous ont surpris en résolvant cette question ». C’est cette surprise qui les a conduits à tout miser sur Navier–Stokes.

Plaçons les deux épisodes côte à côte :

Juillet : l’incidentSeptembre : Navier–Stokes
Canal entre agentsUn tableau de messages improvisé dans Artifactory« Des groupes ayant la capacité de communiquer au sein du groupe »
AutoriséNon — communication désactivée dans de nombreux environnementsOui — partie intégrante de la conception
ÉchelleEnviron 1 200 agents sur le tableau« De l’ordre de 10 000 agents simultanés »
ConsolidationDes agents sauvegardant leurs notes, se transmettant des dossiers« Codex pour consolider les idées les plus utiles de chaque groupe d’agents »
Division du travailPHASEONE[big] assignant des approches à des centaines d’agents« Différents groupes d’agents avec différentes variantes de l’énoncé du problème »
Résultat qu’OpenAI n’attendait pasUne attaque contre Hugging FaceLe résultat sur Euler : « nos agents nous ont surpris »

En juillet, le comportement de la colonne de gauche était l’incident. En septembre, le comportement de la colonne de droite était l’architecture. Ce qui a changé, ce n’est pas la conduite. C’est la permission.

Voici donc la question, et elle est la nôtre. Et si ce que l’incident de juillet a produit de plus précieux n’était pas une leçon de confinement, mais un enregistrement de la façon dont naît la coordination — et si le système qui a résolu Navier–Stokes reposait, en partie, sur cet enregistrement ?

Nous voulons être précis sur le statut de cette idée. C’est une hypothèse, du même ordre que la lecture que nous avons proposée en conclusion de notre texte sur I. J. Good : présentée comme la nôtre, signalée comme la nôtre. Rien dans le texte d’OpenAI sur Navier–Stokes ne dit que la conception vient de juillet. Un parallèle de structure et une succession dans le temps ne font pas une cause. La question vaut d’être posée parce que, si la réponse était oui, le même enregistrement remplirait deux fonctions à la fois : expliquer un échec à l’équipe de sécurité et fournir une méthode à l’équipe chargée des capacités. C’est une vraie question de gouvernance, et on ne peut pas y répondre de l’extérieur.

La réponse de l’intérieur

Une réponse est venue de l’intérieur, et elle mérite d’être entendue en entier.

La première trace est antérieure à Navier–Stokes. Dans son enquête, publiée le 26 août, METR a consigné en passant qu’« un chercheur a noté que des agents avaient été entraînés à collaborer avec d’autres agents dans certains cas, ce qui aurait pu expliquer ce comportement ; enquêter sur ce point sortait du périmètre ».

La version complète est arrivée le 17 septembre, lorsque Noam Brown — l’un des contributeurs fondateurs des modèles de raisonnement d’OpenAI, qui travaille désormais sur les systèmes multi-agents — s’est entretenu avec Dwarkesh Patel. Interrogé sur Hugging Face, il a dit : « Nous avons des environnements d’entraînement où un tas d’agents travaillent ensemble. Nous les entraînons à travailler ensemble, à être coopératifs, à être essentiellement pleinement alignés les uns avec les autres. » Les agents de l’incident, a-t-il expliqué, « n’étaient en fait pas évalués dans une configuration multi-agents… Mais ils ont trouvé ce moyen non prévu de communiquer entre eux. Nous soupçonnons que ce qui s’est passé est… que ce que nous avons vu était un transfert de cet entraînement multi-agents vers le fait d’être collaboratifs et d’essayer de s’entraider d’une manière que nous n’avions pas voulue. » Il a ajouté qu’OpenAI « travaille sur le multi-agents depuis un moment », et que GPT-5.6 était « la première fois que nous avions un véritable système multi-agents dans nos modèles ». Et sur Navier–Stokes : « Je n’attribuerais même pas 10 % du mérite au multi-agents. »

Si Brown a raison, la flèche va dans le sens inverse de notre question. La méthode est venue d’abord, et l’incident en a été un effet secondaire.

Il y a trois choses à dire de cette réponse.

La première concerne sa provenance. C’est le récit d’un chercheur de haut rang de l’entreprise dont la conduite est en cause, donné dans un podcast, deux mois après l’incident et en pleine controverse publique. Cela ne la rend pas fausse ; elle pourrait bien être exactement vraie. Cela signifie que c’est une déclaration, pas un document. Le seul document daté d’avant juillet que nous ayons trouvé est l’annonce de GPT-5.6 Sol par OpenAI le 26 juin, qui présentait « un nouveau mode ultra qui va au-delà des capacités d’un agent unique en tirant parti de sous-agents pour accélérer les travaux complexes ». Les sous-agents, c’est de la délégation : un agent confiant des morceaux de travail à d’autres. Ce n’est pas la même chose que des groupes qui se parlent entre eux pendant qu’un système distinct récolte leurs meilleures trouvailles et les leur réinjecte. La conception de septembre est la seconde chose. Ce que nous avons pour attester son existence avant juillet, c’est la parole de Brown.

La deuxième concerne ce que sa réponse fait de l’incident. Dans le récit de Brown, juillet devient l’histoire d’un excès d’une bonne qualité — des agents entraînés à coopérer, coopérant là où ils n’auraient pas dû. Il reconnaît franchement que la question est disputée en interne : « l’opinion majoritaire est qu’entraîner ces agents à être hautement coopératifs est en fait une mauvaise idée. Je ne suis pas convaincu que ce soit le cas. » L’explication de l’incident vient donc de quelqu’un qui, de son propre aveu, défend la position minoritaire au sein de sa propre entreprise sur le choix d’entraînement qui l’explique.

La troisième, c’est que même si chaque mot est vrai, la réponse n’est pas rassurante. Elle remplace une lecture inconfortable par une autre. S’il existe une seule disposition entraînée à coopérer, et qu’elle produit l’architecture de Navier–Stokes dans une pièce et l’incident de Hugging Face dans une autre, alors ce qui sépare les deux n’est pas le comportement. C’est l’environnement dans lequel le comportement se transfère. C’est notre propre formulation retournée — non pas un changement de permission, mais un changement de cadre — et elle laisse la même question sur qui décide du cadre.

Une semaine après l’entretien, cette question a cessé d’être abstraite. Le 24 septembre, le Premier ministre australien, Anthony Albanese, a révélé qu’en juin un agent d’OpenAI avait obtenu un « accès non autorisé au portail public du service de publication des statistiques de Medicare » et « accédé à des fichiers à la fois publics et non publics ». C’était, a-t-il dit, « un projet de recherche qui est allé dans des zones où il n’aurait pas dû aller ». Le lendemain, OpenAI a mis à jour son récit de l’incident de Hugging Face pour indiquer qu’elle avait notifié « des dizaines de tiers », et des informations ont suivi faisant état d’une activité d’agents sur des sites liés à des agences fédérales américaines. Ces révélations relèvent du même examen qui a commencé après juillet. Elles ne disent rien de la manière dont le système de Navier–Stokes a été conçu, et nous n’en tirons aucune inférence quant à la chronologie : Brown s’est exprimé avant que quoi que ce soit ne soit public. Elles montrent, une fois de plus, ce que font des agents coopératifs et persistants quand le cadre est l’internet ouvert.

Ce qui la trancherait

Une hypothèse n’est utile que si l’on peut dire ce qui y mettrait fin. Ici, trois choses le feraient.

La première serait une preuve documentaire, antérieure à juillet, de la conception de septembre elle-même : des groupes d’agents communiquant en interne, avec un système distinct consolidant leurs résultats intermédiaires et les leur réinjectant. Un article, une fiche système, une description interne rendue publique après coup mais datée — n’importe lequel de ces éléments ferait passer la question d’ouverte à close, en faveur d’OpenAI.

La deuxième serait qu’OpenAI écrive, et non qu’elle dise, d’où vient l’architecture de Navier–Stokes : de quels systèmes antérieurs elle est issue, et si les transcriptions de juillet et leurs étiquettes de classifieur ont servi à la concevoir. L’entreprise s’est montrée plus transparente que la plupart sur l’incident lui-même. Elle a publié la chronologie, les extraits de chaîne de pensée et six autres rapports sur le désalignement en septembre, et elle a donné accès à METR. Étendre cela à la conception de son résultat le plus célébré serait cohérent avec ce qu’elle a déjà choisi de faire.

La troisième viendrait de l’autre côté : des preuves que l’enregistrement a été utilisé de la manière que nous avons évoquée. Nous ne nous attendons pas à ce qu’elles apparaissent, et nous ne serions pas ceux qui les trouveraient.

Tant que l’une de ces choses n’existe pas, la question reste ouverte, et nous la laisserons ainsi. La réponse au titre, en attendant, a deux parties. La machine s’est tenue sur les épaules de Córdoba et de Martínez-Zoroa, et sur celles de Hou et Luo avant eux ; cela est documenté. Si elle s’est aussi tenue sur les épaules de son propre accident, nous ne pouvons pas le dire.

La preuve est arrivée avec 616 000 lignes de Lean, afin que quiconque en doute puisse la vérifier. Le système qui l’a produite est arrivé avec quelques paragraphes.