Dimanche soir, une formule et une finale de coupe du monde
Tard dans la soirée du dimanche 19 juillet 2026, le mathématicien Levent Alpoge a publié une seule application polynomiale et remercié deux amis: l'un pour avoir posé la question, l'autre, écrit-il, pour avoir travaillé pendant la finale de la coupe du monde. Ce second ami était Claude Fable 5. Le message porte l'horodatage 02:19 UTC du 20 juillet. La formule qu'il contenait était un contre-exemple à la conjecture jacobienne, ouverte depuis 1939.
L'application envoie trois variables complexes sur trois sorties complexes. Son déterminant jacobien vaut -2, une constante non nulle, soit exactement la condition qui, selon la conjecture, devait garantir l'existence d'une réciproque polynomiale. Cette réciproque n'existe pas, car trois entrées distinctes aboutissent au même point: (0, 0, -1/4), (1, -3/2, 13/2) et (-1, 3/2, 13/2) ont toutes pour image (-1/4, 0, 0).
Alpoge travaille chez Anthropic et attribue la découverte au modèle. C'est ce point que le secteur citera pendant un mois. Ce n'est pas celui qui compte le plus pour quiconque dirige une entreprise.
Ce que Keller a écrit en 1939
La conjecture était une promesse de reconstitution. Le mathématicien allemand Ott-Heinrich Keller a demandé si une application polynomiale dont le déterminant jacobien est une constante non nulle possède nécessairement une réciproque qui soit elle-même polynomiale. En termes plus simples: si une transformation ne détruit localement d'information nulle part, peut-on toujours reconstituer l'entrée à partir de la sortie avec le même type d'arithmétique qu'à l'aller.
Pendant 87 ans, on a tenu la réponse pour oui et personne n'a su le démontrer. La question est restée en géométrie algébrique comme l'un de ces problèmes qui attirent des résultats partiels, des cas particuliers et, de loin en loin, des démonstrations qu'il a fallu retirer.
Le contre-exemple tranche la question en dimension trois et au-delà. Le cas à deux variables reste ouvert, et la pull request qui a formalisé la réfutation le dit noir sur blanc. Le résultat est plus étroit que ne le laisse entendre le titre, et un compte rendu honnête doit le signaler.
La vérification a pris quelques heures parce que quelqu'un avait écrit la question avant
En l'espace d'une journée, Paul Lezeau avait formalisé le contre-exemple dans l'assistant de preuve Lean et ouvert la pull request 4474 sur le dépôt formal-conjectures de Google DeepMind, intitulée feat: add Jacobian disproof. Les relecteurs l'ont approuvée. Un audit indépendant publié dans le même fil a confirmé que la preuve ne contient ni sorry, ni native_decide, ni axiome ajouté, ce qui est la façon dont la communauté Lean dit que rien n'a été supposé et que rien n'est passé sans contrôle.
La rapidité vient de la préparation, pas du modèle. Le dépôt contenait déjà un énoncé formel de la conjecture jacobienne, validé par des humains et rédigé avant que quiconque ait un contre-exemple à lui opposer. Comme l'écrit le blog du Xena Project, dès lors que les humains s'accordent sur le fait que l'énoncé formel rend fidèlement la conjecture, vérifier qu'un code Lean éventuellement produit par une IA constitue bien une preuve ou une réfutation de la conjecture relève de la trivialité.
Relisez cette phrase. La partie difficile, lente et humaine s'est jouée des années plus tôt, quand quelqu'un a traduit une phrase de 1939 sous une forme vérifiable par machine. L'affirmation est arrivée un dimanche soir et l'affaire était réglée le lundi parce que le test d'acceptation existait déjà.
Vérifié ne veut pas dire compris
Le même blog est franc sur la limite. L'étape suivante, écrit-il, est que des humains comprennent exactement ce qui se passe dans cet exemple. Une machine peut certifier que les trois points se confondent. Elle ne peut pas encore expliquer pourquoi cette application-là, parmi toutes les autres, est celle qui a fait tomber une hypothèse vieille de 87 ans. La relecture par les pairs en revue scientifique n'est pas achevée non plus, et un préprint de vérification n'est pas une revue.
Ce n'est pas non plus un événement isolé. Le même blog compte trois contre-exemples en trois mois: la conjecture d'Erdos sur les distances unité en mai, une question de Grothendieck sur les schémas en groupes en juillet, et maintenant celle de Keller. Timothy Gowers a décrit celui-ci comme la première fois qu'un modèle de langage résolvait un problème connu dont il avait entendu parler en dehors de son propre domaine. Trois points de données, cela fait un motif qui se dessine, pas un motif démontré.
Écrivez le test d'acceptation avant d'acheter le modèle
La leçon transposable est procédurale, pas mathématique. Presque toutes les affirmations de capacité d'IA soumises cette année à un dirigeant sont arrivées sous la forme d'un score de benchmark publié par la partie qui vend le modèle. Celle-ci est arrivée sous la forme d'un objet qu'un inconnu pouvait vérifier en un après-midi, face à un critère rédigé avant que l'affirmation existe, avec un outil qui ne rend de comptes ni au laboratoire ni à l'auteur de l'affirmation.
C'est une spécification que vous pouvez copier. Avant le prochain achat d'IA, rédigez le critère d'acceptation sous une forme évaluable sans la coopération du fournisseur: un jeu de tests fixe que vous détenez vous-même, une règle de notation convenue à l'avance, un format de sortie qu'un script sous votre contrôle peut noter. Si la seule preuve de performance est un chiffre calculé par le fournisseur, vous avez acheté un communiqué de presse.
Gardez la seconde leçon à côté de la première. Le contre-exemple est certifié et toujours pas expliqué, ce qui est exactement la forme de la plupart des productions d'une IA dans une entreprise: exact d'une manière que vous pouvez tester, opaque d'une manière que vous ne pouvez pas auditer. Concevez pour la première et recrutez pour la seconde.
À lire ensuite: Des tests indépendants classent Kimi K3 devant Fable 5 | Le modèle phare de Google est en retard, et sans nouvelle date
