67,2 %.
Ce chiffre pourrait laisser croire que Claude vient de rĂ©soudre l’un des problĂšmes les plus cĂ©lĂšbres des mathĂ©matiques.
Ce n’est pas le cas.
En aoĂ»t 2026, Anthropic a annoncĂ© qu’une version de recherche non publiĂ©e de Claude avait amĂ©liorĂ© une borne infĂ©rieure concernant la proportion de zĂ©ros de la fonction zĂȘta de Riemann situĂ©s sur la droite critique, en la faisant passer d’environ 41,6 % Ă 67,2 %. L’hypothĂšse de Riemann elle-mĂȘme reste ouverte.
Mais le vĂ©ritable intĂ©rĂȘt de cette expĂ©rience n’est peut-ĂȘtre pas le chiffre.
C’est la maniĂšre dont le rĂ©sultat a Ă©tĂ© obtenu.
Claude n’a pas simplement reçu un problĂšme et retournĂ© une rĂ©ponse. Il a orchestrĂ© une recherche impliquant environ 60 sous-agents, des milliers d’exĂ©cutions, des centaines d’hypothĂšses abandonnĂ©es, puis une formalisation de la preuve avec Lean, un assistant de preuve formelle.
On commence alors Ă entrevoir quelque chose de diffĂ©rent d’un simple chatbot : une architecture capable d'organiser une exploration scientifique.
1. D'abord, une précision essentielle : Claude n'a pas prouvé l'hypothÚse de Riemann
L'hypothĂšse de Riemann, formulĂ©e en 1859, affirme que les zĂ©ros non triviaux de la fonction zĂȘta de Riemann ont tous une partie rĂ©elle Ă©gale Ă 1/2.
Elle reste non démontrée.
L'expérience d'Anthropic porte sur une question plus restreinte :
Quelle proportion des zĂ©ros peut-on dĂ©montrer rigoureusement ĂȘtre situĂ©e sur cette droite critique ?
Avant ce travail, la borne inférieure connue était d'environ 41,6 %, issue notamment des travaux de Pratt, Robles, Zaharescu et Zeindler publiés en 2020. Anthropic rapporte désormais une borne de 67,2 %.
Il faut donc distinguer trois propositions :
| Proposition | Statut |
|---|---|
| L'hypothĂšse de Riemann est dĂ©montrĂ©e | ❌ Non |
| Une nouvelle borne infĂ©rieure a Ă©tĂ© obtenue | ✅ Oui, selon Anthropic |
| La preuve est formalisĂ©e en Lean | ✅ Oui, selon Anthropic |
Cette distinction est fondamentale.
Le résultat est intéressant précisément parce qu'il ne repose pas simplement sur une réponse générée par un modÚle de langage.
2. Le chiffre impressionnant n'est pas seulement 67,2 %
Le résultat attire naturellement l'attention parce que la borne passe de 41,6 % à 67,2 %.
Cela représente 25,6 points de pourcentage.
Mais il faut regarder la temporalité.
Le précédent résultat majeur sur cette borne datait de 2020. Anthropic indique que son systÚme a réalisé cette nouvelle avancée au cours d'une exécution d'environ 36 heures.
Ce rapprochement doit cependant ĂȘtre interprĂ©tĂ© avec prudence.
Claude ne repartait évidemment pas de zéro.
Il s'appuyait sur plus d'un siÚcle de travaux mathématiques, notamment sur des résultats de Hardy, Selberg, Levinson, Conrey, Pratt, Robles, Zaharescu, Zeindler, ainsi que sur des travaux plus récents utilisés dans la construction de la nouvelle approche. Anthropic indique notamment que le résultat combine des travaux récents sur les techniques de corrélation des zéros avec un travail de Bombieri datant de 2000.
L'IA n'a donc pas remplacé les mathématiciens qui ont construit le domaine.
Elle a exploré l'espace des combinaisons possibles beaucoup plus rapidement.
C'est une différence majeure.
3. Le véritable changement : passer du modÚle unique à l'essaim d'agents
L'expérience devient particuliÚrement intéressante lorsqu'on regarde son architecture.
Selon Anthropic, environ 60 sous-agents Claude ont été coordonnés pendant l'exécution.
Le systÚme aurait généré environ :
31 millions de tokens de sortie ;
2 400 commandes shell ;
environ 650 pistes initiales abandonnées ;
des centaines de scripts et vérifications numériques ;
plusieurs agents dédiés à la validation plutÎt qu'à la génération d'idées.
Le point important est lĂ :
Le systÚme n'attend pas qu'un modÚle trouve immédiatement la bonne réponse. Il accepte explicitement l'échec comme composante du processus de recherche.
C'est trÚs différent du paradigme classique du chatbot.
Un chatbot fonctionne généralement ainsi :
Question
↓
LLM
↓
RĂ©ponse
L'architecture de recherche ressemble davantage Ă :
┌── Agent A ──┐
├── Agent B ──┤
├── Agent C ──┤
ProblĂšme ────────┼── Agent D ──┼──→ HypothĂšses
├── Agent E ──┤
└── Agent N ──┘
│
▼
Orchestrateur
│
┌──────────┴──────────┐
▼ ▼
Vérification Rejet / itération
│
▼
Formalisation
│
▼
RĂ©sultat
Le modÚle n'est donc plus uniquement un générateur de texte.
Il devient une unité de recherche dans un systÚme distribué.
4. Les 650 échecs sont presque aussi importants que le résultat
Dans beaucoup de démonstrations d'IA, on montre uniquement la réponse finale.
C'est trompeur pour comprendre la recherche.
Une découverte scientifique implique généralement :
des hypothĂšses ;
des impasses ;
des contre-exemples ;
des variantes ;
des expérimentations ;
des vérifications ;
des abandons.
Dans cette expérience, Anthropic rapporte environ 650 idées explorées avant que l'approche gagnante n'émerge.
Cela donne une nouvelle maniĂšre de regarder les agents IA.
Leur valeur ne réside pas uniquement dans leur taux de réussite individuel.
Elle peut aussi venir de leur capacité à explorer collectivement un espace immense de possibilités.
Un agent peut Ă©chouer.
Dix peuvent Ă©chouer.
Trente peuvent Ă©chouer.
Si un autre agent trouve une piste exploitable et qu'un systĂšme de validation permet de distinguer cette piste des autres, l'ensemble peut tout de mĂȘme produire un rĂ©sultat utile.
C'est une logique beaucoup plus proche d'un laboratoire de recherche automatisé que d'un assistant conversationnel.
5. Mais une hypothĂšse plausible n'est pas une preuve
C'est probablement le point le plus important de toute l'histoire.
Un LLM peut produire une dĂ©monstration extrĂȘmement convaincante… et fausse.
La fluidité du langage n'est pas une garantie de validité.
C'est pourquoi la formalisation en Lean est particuliÚrement intéressante.
Lean permet de représenter une preuve dans un langage formel puis de demander à un vérificateur informatique de contrÎler les étapes logiques.
L'approche devient alors :
Idée générée par l'IA
↓
Argument mathématique
↓
Formalisation Lean
↓
VĂ©rification automatique
↓
Preuve acceptée ou rejetée
Ce mĂ©canisme ne signifie pas que Lean « comprend » nĂ©cessairement la dĂ©couverte comme un mathĂ©maticien humain.
Il apporte quelque chose de différent :
une vérification mécanique des rÚgles formelles de la preuve.
Anthropic indique également que le résultat a été examiné par ses mathématiciens Levent Alpoge et Ralph Furman, et que les mathématiciens Brian Conrey et Dan Goldston ont examiné le travail.
Des travaux de vérification indépendants ont par ailleurs ensuite été publiés autour de la formalisation Lean.
6. Le vrai pattern architectural : Generate → Verify → Iterate
Ce qui me paraĂźt le plus intĂ©ressant pour l'IA appliquĂ©e n'est donc pas « Claude est meilleur en mathĂ©matiques ».
C'est plutĂŽt ce pattern :
┌─────────────────┐
│ PROBLĂME │
└────────┬────────┘
│
▼
┌─────────────────┐
│ ORCHESTRATEUR │
└────────┬────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Agent 1 Agent 2 Agent N
│ │ │
└──────────────┼──────────────┘
▼
CANDIDATS / IDĂES
│
▼
┌─────────────────┐
│ VERIFIER │
└────────┬────────┘
│
┌───────┴───────┐
▼ ▼
REJETĂ VALIDĂ
│ │
└───────┐ │
▼ ▼
ITERATION
│
▼
RESULTAT
C'est une architecture que l'on peut transposer bien au-delà des mathématiques.
7. Et c'est ici que le sujet devient intéressant pour les entreprises
Prenons un systĂšme d'information classique.
Un agent IA pourrait analyser un ticket, proposer une correction, modifier une configuration et déployer.
Le problĂšme est Ă©vident :
Qui vérifie que la décision de l'agent est correcte ?
Un modÚle supplémentaire peut donner une deuxiÚme opinion.
Mais deux LLM qui se valident mutuellement ne constituent pas nécessairement une garantie forte.
Le modÚle plus robuste consiste à introduire un oracle ou vérificateur indépendant du générateur.
Par exemple :
Ticket
↓
Agent de diagnostic
↓
Agent de proposition
↓
Analyse de sécurité
↓
Tests automatisés
↓
Policy Engine
↓
Validation
↓
Human approval si nécessaire
↓
DĂ©ploiement
Dans une architecture DevSecOps, cela peut donner :
AI Agent
│
▼
Génération
│
┌──────┼────────┐
▼ ▼ ▼
Tests SAST Trivy
│ │ │
└──────┼────────┘
▼
Policy Engine
│
┌─────┴─────┐
▼ ▼
Reject Accept
│
▼
Deploy
L'IA propose.
Le systÚme vérifie.
8. C'est probablement l'une des architectures clés des futurs systÚmes agentiques
On parle énormément d'AI Agents.
Mais un agent autonome sans mécanisme de vérification reste essentiellement un systÚme qui peut produire des actions plus rapidement.
Le passage intéressant est :
Agent + outils + mémoire + orchestration + vérification + gouvernance
C'est cette combinaison qui permet d'envisager une automatisation progressive.
Dans un environnement d'entreprise, on peut imaginer plusieurs niveaux :
Niveau 1 — Observation
L'agent analyse mais ne modifie rien.
Agent → recommandation → humain
Niveau 2 — Action rĂ©versible
L'agent peut effectuer certaines opérations à faible risque.
Agent → action → validation automatique → rollback possible
Niveau 3 — Action contrĂŽlĂ©e
L'action passe par des politiques et des contrĂŽles.
Agent
↓
Policy Engine
↓
Security checks
↓
Tests
↓
Approval
↓
Action
Niveau 4 — Autonomie bornĂ©e
L'agent peut agir seul dans un domaine précisément défini.
Agent
↓
Policy
↓
Verifier
↓
Execution
↓
Monitoring
↓
Rollback
La question n'est donc plus seulement :
« Quel est le meilleur modĂšle ? »
Mais aussi :
« Quelle architecture permet de faire confiance Ă ce que produit le modĂšle ? »
9. La limite fondamentale : toutes les industries n'ont pas un Lean
C'est ici qu'il faut éviter de surinterpréter l'expérience.
Les mathématiques formelles disposent d'un avantage extraordinaire : la possibilité de formaliser certaines propositions et de vérifier mécaniquement leurs preuves.
Dans une entreprise industrielle, pharmaceutique ou scientifique, le monde réel est beaucoup plus difficile à vérifier.
Un modÚle peut proposer une molécule.
Il faut ensuite :
simuler ;
expérimenter ;
mesurer ;
reproduire ;
contrĂŽler les contraintes ;
analyser les effets secondaires.
Pour un circuit électronique, on dispose d'outils de vérification formelle, de simulation et de tests.
Pour un systĂšme logiciel, on dispose de :
tests unitaires ;
tests d'intégration ;
SAST ;
DAST ;
analyse de dépendances ;
scan de conteneurs ;
tests de charge ;
politiques de sécurité ;
observabilité ;
rollback.
Mais aucun de ces mécanismes ne garantit à lui seul que le systÚme répond au besoin métier réel.
La vĂ©rification doit donc ĂȘtre adaptĂ©e au domaine.
10. Le véritable changement : le coût de l'exploration intellectuelle
Pendant longtemps, l'IA générative a principalement été utilisée pour réduire le coût de production :
Ă©crire du code ;
produire de la documentation ;
générer des tests ;
résumer des informations ;
produire du contenu.
L'expérience Riemann suggÚre une autre direction :
réduire le coût de l'exploration.
C'est différent.
Imaginez un problĂšme technique sur lequel une Ă©quipe humaine pourrait tester dix architectures.
Un systĂšme multi-agent pourrait explorer :
Architecture A
Architecture B
Architecture C
...
Architecture N
Puis lancer automatiquement :
tests
benchmarks
security scans
simulation
cost analysis
failure analysis
Les mauvaises branches sont éliminées.
Les meilleures sont approfondies.
L'humain intervient ensuite lĂ oĂč son expertise apporte le plus de valeur.
L'IA ne remplace donc pas nécessairement le chercheur.
Elle peut devenir un multiplicateur de capacité d'exploration.
11. Une nouvelle unité de mesure : le coût de recherche par hypothÚse validée
Cela pourrait mĂȘme changer la maniĂšre dont nous Ă©valuons les systĂšmes IA.
Aujourd'hui, on mesure beaucoup :
tokens/seconde ;
benchmark ;
coût par million de tokens ;
latence ;
taux de réussite.
Mais pour la R&D, une métrique potentiellement plus intéressante serait :
Combien coûte l'exploration d'une hypothÚse jusqu'à sa validation ?
Par exemple :
100 hypothĂšses
↓
80 rejetées rapidement
↓
15 testées davantage
↓
4 retenues
↓
1 validée
Le systÚme devient alors un moteur de recherche expérimentale automatisée.
Et la métrique pertinente n'est plus uniquement la qualité du modÚle.
Elle devient :
modĂšle × orchestration × outils × vĂ©rification × compute × donnĂ©es.
12. Ce que cette expérience change dans notre maniÚre de concevoir l'IA
Le récit classique est :
« Un modĂšle plus puissant donne de meilleures rĂ©ponses. »
Le récit qui apparaßt ici est différent :
« Un modĂšle suffisamment capable, correctement orchestrĂ©, disposant d'outils et soumis Ă des mĂ©canismes de vĂ©rification peut explorer des espaces de recherche beaucoup plus larges. »
Cela déplace le centre de gravité.
Le modĂšle reste important.
Mais l'architecture autour du modÚle devient tout aussi déterminante.
On peut alors considérer un systÚme IA moderne comme :
┌───────────────────┐
│ HUMAN │
│ STRATEGY │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ ORCHESTRATOR │
└─────────┬─────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└────────────┼────────────┘
▼
TOOL / COMPUTE
│
▼
VERIFICATION
│
┌──────┴──────┐
▼ ▼
FAIL PASS
│ │
└──────┐ │
▼ ▼
ITERATE
│
▼
RESULT
C'est probablement cette architecture qui mérite le plus d'attention.
Le sujet n'est pas Riemann, c'est la boucle de vérification
Le rĂ©sultat annoncĂ© par Anthropic est spectaculaire : une version de recherche non publiĂ©e de Claude a amĂ©liorĂ© une borne infĂ©rieure sur les zĂ©ros de la fonction zĂȘta de Riemann, de 41,6 % Ă 67,2 %, sans pour autant rĂ©soudre l'hypothĂšse de Riemann.
Mais le véritable enseignement dépasse largement les mathématiques.
Ce qui mĂ©rite d'ĂȘtre observĂ© est le systĂšme :
des dizaines d'agents → des centaines d'hypothĂšses → des milliers d'exĂ©cutions → sĂ©lection → vĂ©rification → formalisation → validation humaine.
Autrement dit :
Generate → Explore → Verify → Iterate.
Pour les architectures IA d'entreprise, c'est probablement l'une des Ă©volutions les plus importantes Ă surveiller.
L'enjeu des prochaines annĂ©es ne sera peut-ĂȘtre pas simplement de construire des modĂšles capables de produire de meilleures rĂ©ponses.
Il sera de construire des systÚmes capables de produire des hypothÚses, de les tester, d'éliminer automatiquement les mauvaises et de ne laisser passer que celles qui satisfont des critÚres de vérification explicites.
Et dans cette architecture, le modĂšle n'est qu'une brique.
L'orchestrateur, les outils, les garde-fous et surtout le mécanisme de vérification deviennent le véritable systÚme.
Par Aghilas AZZOUG