OpenAI Dit Avoir Résolu Navier-Stokes: 10 000 Agents, 88 Heures et la Bataille pour le Crédit du Problème du Millénaire

Salut HaWkers, le mardi 8 septembre 2026, OpenAI a publié ce qu'elle appelle la résolution du problème d'existence et de régularité de Navier-Stokes, l'un des sept problèmes du millénaire du Clay Mathematics Institute, chacun doté d'un prix d'un million de dollars. Selon l'entreprise, un modèle interne encore non publié, fonctionnant comme un essaim d'environ 10 000 agents, est arrivé au résultat en 88 heures, et la preuve a été vérifiée formellement en Lean. Douze heures plus tôt, le mathématicien Tristan Buckmaster, de NYU, avait publié une note de quatre pages accusant OpenAI d'avoir couru après le même chemin après avoir eu connaissance de son travail avec Levent Alpöge, mathématicien chez Anthropic.

La question mérite d'être posée directement: qu'est-ce qui a exactement été prouvé, qu'est-ce que cela a à voir avec ceux qui écrivent du logiciel, et pourquoi la communauté mathématique est-elle plus préoccupée par la forme que par le résultat? Dans cet article, vous allez comprendre le problème en langage d'ingénieur, ce que signifie une preuve vérifiée en Lean, les chiffres réels publiés jusqu'ici, la chronologie du conflit et ce qu'il manque encore pour que quelqu'un touche le prix.

Qu'est-ce Que le Problème de Navier-Stokes

Les équations de Navier-Stokes décrivent le mouvement des fluides: l'eau dans un tuyau, l'air autour d'une aile, la fumée qui monte d'une cheminée. Les ingénieurs les résolvent numériquement tous les jours dans des simulations de CFD. Le problème du Clay Institute, formulé en 2000 par Charles Fefferman, de Princeton, est différent: il demande si, en trois dimensions, une solution qui commence régulière peut développer une singularité en temps fini, ce que les mathématiciens appellent un blowup. En termes pratiques, si la vitesse ou la vorticité du fluide peut partir à l'infini en un point, à un instant précis, même avec une énergie totale bornée.

Pendant près de 90 ans, personne n'a réussi à prouver ni que cela arrive ni que cela n'arrive pas. L'énoncé officiel de Fefferman propose quatre variantes, identifiées (a), (b), (c) et (d). Les deux premières traitent du fluide sans force extérieure; les deux dernières, (c) et (d), autorisent une force extérieure régulière agissant sur le fluide. Prouver le blowup dans n'importe laquelle d'entre elles résout le problème. Le résultat d'OpenAI, selon l'entreprise, est justement un blowup en temps fini avec forçage régulier, dans l'espace tridimensionnel entier et sur le tore, autrement dit les options (c) et (d).

Pourquoi "Forçage Régulier" Est le Mot-Clé

Voici le détail qui explique tout le conflit. Il existe un programme de recherche, ouvert par les Espagnols Diego Córdoba, de l'ICMAT à Madrid, et Luis Martínez-Zoroa, de la CUNEF, qui construit des singularités en empilant des couches de solutions non singulières dans une cascade infinie. Vers 2023, ils avaient déjà le blowup pour Euler avec un forçage irrégulier. Ce qui manquait, c'était de faire produire à la même cascade une singularité tout en gardant la force extérieure régulière. C'était le dernier obstacle, et presque personne au monde ne travaillait dessus. Fefferman, auteur de l'énoncé du prix, a qualifié les deux de "héros" de l'histoire en parlant à Quanta Magazine.

Ce Qu'OpenAI Affirme Avoir Fait

Le billet d'OpenAI décrit un processus en deux phases. D'abord, environ 100 agents ont travaillé pendant 50 heures sur les équations d'Euler, la version sans viscosité du problème. Ensuite, à peu près 10 000 agents ont passé 88 heures à attaquer Navier-Stokes proprement dit, avec le résultat atteint le samedi 5 septembre. Selon le billet lui-même, cela représente environ 130 milliards de tokens de sortie rien que pour la partie Navier-Stokes et 2,7 millions de messages échangés entre agents, atteignant 4,9 millions en comptant les autres problèmes. Ensuite, 17 heures supplémentaires avec le modèle GPT-6 Astra ont produit la formalisation en Lean.

Les chiffres de coût varient selon la source. Sébastien Bubeck, chercheur chez OpenAI, a parlé de "plusieurs millions de dollars" à Quanta; Fortune a estimé autour de 2 millions de dollars à partir d'une comparaison avec des défis antérieurs; TechCrunch a cité un montant bien plus élevé. Il n'y a pas de chiffre officiel, donc le plus honnête est de dire que ce fut un effort de plusieurs millions de dollars en calcul concentré sur moins de deux semaines. Le délai est lui aussi confirmé par l'entreprise: le travail a commencé le 1er septembre, motivé par des rumeurs selon lesquelles Anthropic serait proche de résoudre le problème.

Un point rarement mis en avant dans les titres: OpenAI a affirmé dans le billet qu'elle n'a pas l'intention de réclamer le prix d'un million de dollars. L'objectif déclaré est de démontrer la capacité du modèle, que l'entreprise décrit comme un système interne aux performances inédites sur les benchmarks de mathématiques.

Preuve Vérifiée en Lean: Ce Que Cela Signifie Pour Vous

Ceux qui programment comprennent Lean mieux que la plupart des journalistes. Lean est un langage de programmation dont le système de types est si expressif qu'une proposition mathématique devient un type, et une preuve devient un terme de ce type. Si le code compile, la preuve est correcte par rapport aux axiomes et aux définitions utilisées. C'est le même principe qui fait qu'un compilateur refuse un string là où on attendait un number, sauf qu'il est appliqué aux théorèmes.

-- Lean 4: une proposition est un type, une preuve est une valeur de ce type.
-- Si ce fichier compile, le théorème est prouvé.
theorem soma_comutativa (a b : Nat) : a + b = b + a := by
  -- 'omega' résout l'arithmétique linéaire sur les entiers naturels et relatifs
  omega

-- Des définitions fausses compilent aussi: la vérification garantit
-- la cohérence avec l'énoncé écrit, pas avec l'intention de l'auteur.
theorem exemplo_de_alerta (n : Nat) : n + 0 = n := by
  rfl

La réserve du second bloc compte. Une preuve en Lean garantit que l'énoncé formalisé découle des axiomes. Elle ne garantit pas que l'énoncé formalisé est le même que celui du prix Clay. C'est pour cela que la communauté veut lire la centaine de pages de la preuve en langage humain: quelqu'un doit vérifier que les définitions de "solution régulière", "forçage régulier" et "énergie bornée" correspondent à celles de Fefferman. Buckmaster a écrit dans sa note qu'il a refusé de publier seulement un certificat Lean accompagné d'un preprint sans finition, parce que "la première chose que quelqu'un lit devrait être un argument mathématique présenté de la manière normale".

Visualiser un Blowup en Code

On ne peut pas simuler Navier-Stokes 3D dans un article, mais on peut voir le phénomène en une dimension avec l'équation de Burgers sans viscosité, l'exemple classique de singularité en temps fini. La vitesse se transporte elle-même, les parties rapides rattrapent les lentes et le gradient part à l'infini en un temps prévisible.

# Équation de Burgers non visqueuse: u_t + u * u_x = 0
# Solution par la méthode des caractéristiques: chaque point avance à la vitesse u.
# Le gradient diverge en t* = -1 / min(u0'(x)), le "blowup" en temps fini.
import numpy as np

x0 = np.linspace(-np.pi, np.pi, 2001)
u0 = -np.sin(x0)                      # profil initial régulier
du0 = -np.cos(x0)                     # dérivée analytique du profil
t_star = -1.0 / du0.min()             # instant théorique de la singularité

for t in [0.0, 0.5 * t_star, 0.9 * t_star, 0.99 * t_star]:
    x = x0 + u0 * t                   # caractéristiques: x(t) = x0 + u0 * t
    # gradient le long des caractéristiques: u_x = u0' / (1 + u0' * t)
    grad = du0 / (1.0 + du0 * t)
    print(f"t = {t:.3f}  |u_x| maximum = {np.abs(grad).max():.1f}")

print(f"blowup prévu en t* = {t_star:.3f}")

Lancez ça et le gradient maximum passe de 1 à des dizaines, puis des centaines, et explose en s'approchant de t* = 1. Avec Burgers c'est facile parce que l'équation est scalaire et sans pression. Dans Navier-Stokes 3D la pression est non locale, la viscosité lisse le tout et l'incompressibilité couple les trois composantes. C'est pour cela que le problème a résisté pendant des décennies, et pourquoi la route du forçage régulier, qui donne au mathématicien un degré de contrôle supplémentaire, est celle qui a ouvert la voie.

La Chronologie du Conflit

Les faits ci-dessous viennent de la note publique de Buckmaster, des reportages de Quanta, TechCrunch, Fortune et Axios, et de la réponse d'OpenAI. Là où il y a contradiction, je l'ai signalé.

Il y a environ un an: Buckmaster et Alpöge commencent une collaboration personnelle, sans accord institutionnel. Ils utilisent Claude, d'Anthropic, et Codex, d'OpenAI, avec les modèles GPT-5.6 Sol et, plus tard, Astra. Buckmaster paie la facture avec son propre budget de recherche.
15 août 2026: les deux obtiennent un blowup avec forçage régulier pour Boussinesq et pour Euler 3D. Buckmaster décrit la première preuve générée par le modèle comme "la plus horrible que j'aie jamais lue".
22 août: la preuve d'Euler est vérifiée en Lean.
1er septembre: selon OpenAI elle-même, l'effort interne commence, motivé par des rumeurs selon lesquelles Anthropic était proche d'un résultat.
3 septembre: Buckmaster écrit à un mathématicien d'OpenAI pour prévenir que le travail existe et sera publié bientôt. La réponse offre du calcul et demande des détails "pour éviter de concourir".
6 septembre: lors de deux appels avec Bubeck, Buckmaster apprend qu'un modèle interne a prouvé le blowup forcé pour Navier-Stokes. Selon lui, deux propositions lui ont été faites, toutes deux conditionnées au retrait d'Alpöge de la liste des auteurs parce qu'il travaille chez Anthropic. Il a refusé. La note attribue à Bubeck les phrases "Pourquoi ruineriez-vous votre carrière?" et "Si vous ne voulez pas que je sois sympa, je n'ai pas besoin d'être sympa".
7 septembre, minuit: Buckmaster publie la note et trois articles: blowup avec forçage régulier pour les milieux poreux incompressibles, Boussinesq et Euler 3D incompressible.
8 septembre, matin: OpenAI publie la preuve de Navier-Stokes.

La réponse d'OpenAI tient en deux phrases centrales. La première: "Nous (les chercheurs et les agents) n'avons vu aucun de leurs travaux, par quelque moyen que ce soit, avant qu'ils soient rendus publics". La seconde, sur les données d'usage: "Bien que peu probable, nous ne pouvons pas exclure que des données désidentifiées issues de leur utilisation de nos produits aient contribué à améliorer nos modèles". Bubeck a également affirmé que le résultat sur Euler a été obtenu par une méthode totalement différente de celle de Buckmaster et Alpöge, tout en reconnaissant que le chemin vers Navier-Stokes a suivi la même route.

Ce Qui Est en Jeu Pour Ceux Qui Utilisent des Outils d'IA

Laissez les mathématiques de côté une minute. Buckmaster et Alpöge ont fait tout le travail à l'intérieur de sessions de Codex, brouillons compris. Quand il a demandé si le modèle avait été entraîné sur ces sessions, la réponse a été que le modèle "ne consulte pas les données des utilisateurs". Sur l'entraînement, il dit n'avoir reçu aucune réponse. Si vous utilisez un assistant de code sur un projet qui n'est pas encore public, la question est la même: que signifie en pratique "utilisé pour améliorer le modèle", et qui garantit que le résultat de votre travail ne réapparaît pas de l'autre côté?

Ce n'est pas de la paranoïa d'universitaire. C'est la même discussion qui est apparue quand OpenAI a lancé un espace de travail pour scientifiques, que j'ai couvert dans OpenAI lance un espace de travail pour scientifiques avec Deep Research. Plus la recherche de pointe tourne à l'intérieur des outils d'une entreprise qui est aussi en compétition pour la découverte, plus les politiques de rétention et d'entraînement pèsent lourd. Ça vaut le coup de vérifier, dans votre offre, si les sessions sont exclues de l'entraînement par défaut et s'il existe un mode de rétention zéro.

Un motif d'ingénierie que cette histoire enseigne, peu importe qui a raison, est celui du vérificateur indépendant. L'essaim d'OpenAI produit des candidats; Lean rejette ce qui ne ferme pas. C'est une porte déterministe devant un générateur probabiliste, et ça sert pour n'importe quel pipeline avec des agents.

// Motif générateur + vérificateur: les agents proposent, un contrôleur
// déterministe décide. Aucune proposition ne passe sans approbation.
type Proposta = { id: string; conteudo: string };
type Veredito = { ok: boolean; motivo?: string };

async function enxame(
  gerar: (semente: number) => Promise<Proposta>,
  verificar: (p: Proposta) => Promise<Veredito>,
  tentativas: number,
): Promise<Proposta | null> {
  // lance les générateurs en parallèle; chacun reçoit une graine différente
  const propostas = await Promise.all(
    Array.from({ length: tentativas }, (_, i) => gerar(i)),
  );

  for (const p of propostas) {
    const v = await verificar(p); // ici entrent Lean, un test runner, un linter
    if (v.ok) return p;           // la première proposition approuvée gagne
    console.warn(`proposition ${p.id} rejetée: ${v.motivo}`);
  }
  return null; // aucune n'est passée: mieux vaut échouer qu'accepter sans preuve
}

Remplacez verificar par tsc --noEmit, par une suite de tests ou par un validateur de schéma et vous avez la version de production de ce qui s'est passé avec Navier-Stokes. La différence, c'est l'échelle: 10 000 générateurs, 88 heures et un vérificateur qui n'accepte pas le "presque sûr".

Ce Que Terence Tao et la Communauté Disent

Terence Tao, de UCLA, n'est pas entré dans la dispute de crédit. Sa préoccupation, citée par Fortune, est systémique: le "minage indiscriminé de problèmes ouverts à la recherche de solutions" pourrait "détruire l'écosystème à partir duquel la prochaine génération de techniques, de problèmes et de praticiens mathématiques se serait développée". Les problèmes ouverts sont la matière première de la formation des doctorants. Si chacun d'eux devient la cible d'un essaim d'agents dès qu'une rumeur circule, que reste-t-il pour former la génération suivante?

Buckmaster fait un point comparable dans sa note. Il dit qu'il comptait annoncer ses résultats en précisant que "les résultats ne sont pas la chose importante"; l'important serait qu'un mathématicien et un modèle arrivent maintenant à faire tout cela en un mois, un "moment Deep Blue contre Kasparov" pour le domaine. Au lieu de ça, il s'est retrouvé à écrire sur qui a appelé qui. Il assume aussi que ses articles sont sortis mal écrits à cause de la précipitation, allant jusqu'à qualifier le texte sur Euler de "AI slop", et il s'en excuse.

Quanta a qualifié le résultat d'OpenAI de "de loin la preuve mathématique la plus importante jamais obtenue par un modèle d'intelligence artificielle à ce jour". Les deux choses sont vraies en même temps: ça peut être le plus grand exploit de l'IA en mathématiques pures et, malgré tout, avoir été annoncé d'une manière que la communauté juge inacceptable.

Ce Qu'il Manque Pour Que Quelqu'un Gagne le Prix

Les règles du Clay Mathematics Institute sont publiques et lentes exprès. Une solution doit être publiée dans un support qualifié, rester disponible pendant au moins deux ans et atteindre une acceptation générale dans la communauté mathématique avant que le comité n'envisage seulement la remise du prix. À la clôture de cet article, l'institut continue de lister Navier-Stokes comme un problème ouvert. Même si la preuve est correcte, le calendrier minimum repousse toute décision à après 2028.

Il y a encore trois vérifications indépendantes en cours. La première est mathématique: des spécialistes des équations aux dérivées partielles doivent lire les 100 pages et confirmer que la formalisation en Lean correspond au problème de Fefferman. La deuxième est une question de priorité: les dates de Buckmaster et Alpöge pour Euler (15 et 22 août) sont antérieures au début de l'effort d'OpenAI (1er septembre), et OpenAI elle-même crédite le duo pour le résultat sur Euler; la question ouverte est le saut d'Euler à Navier-Stokes. La troisième est une question de conduite: OpenAI n'a toujours pas donné de réponse directe sur le fait de savoir si les sessions de Codex sont entrées dans l'entraînement.

Pour ceux qui construisent du logiciel, les leçons sont moins glamour et plus utiles. Un vérificateur déterministe devant des agents probabilistes, c'est ce qui transforme la force brute en résultat fiable. Les politiques de rétention de données de l'outil que vous utilisez font partie de votre architecture, pas du juridique. Et le crédit, en science comme en open source, c'est ce qui soutient la contribution suivante; le traiter comme un détail de négociation coûte cher à tout le monde.

Allez, on y va! 🦅

📚 Vous Voulez Suivre Ce Qui Arrive?

Cet article a couvert la résolution de Navier-Stokes annoncée par OpenAI et le conflit de crédit avec Buckmaster et Alpöge, mais l'écosystème change chaque semaine et tout ne devient pas un article ici.

Sur X, je partage ce que je teste, les coulisses des projets et les nouveautés qui apparaissent avant de devenir des posts.

Suivez-Moi La-Bas

👉 Suivre @jeffbruchado sur X

💡 Du contenu quotidien sur le développement, la carrière et les outils que j'utilise vraiment