Leanstral 1.5 : l’agent open source de Mistral qui résout 87 % du PutnamBench et trouve de vrais bogues dans le Rust

Mistral AI a publié, le 3 juillet 2026, Leanstral 1.5, un modèle agent open-source sous licence Apache-2.0, conçu pour raisonner et produire des preuves formelles en Lean 4. Le modèle ne fait pas que s’améliorer sur les benchmarks : il sature miniF2F (100 % en validation et en test), résout 587 des 672 problèmes de PutnamBench, atteint 87 % sur FATE-H et 34 % sur FATE-X — un nouveau plafond sur ces références — et, dans une étude de cas rendue publique, identifie cinq bogues jusque-là non signalés sur GitHub dans des bibliothèques Rust largement utilisées. Pour le monde francophone et européen de l’IA, le signal est autant technique que politique : un laboratoire basé à Paris propose un agent de vérification formelle libre, performant, et utilisable sans dépendre d’une API américaine.

Derrière le titre, l’enjeu est concret. La vérification formelle est la discipline qui consiste à démontrer mathématiquement qu’un programme fait exactement ce qu’il est censé faire. Elle est cruciale pour les bibliothèques cryptographiques, les logiciels critiques (aéronautique, médical, ferroviaire), les compilateurs et tout code dont la fiabilité ne peut pas se mesurer par des tests statistiques. Jusqu’ici, les modèles qui s’en sortent le mieux étaient pour l’essentiel fermés, chers à l’inférence, et difficiles à auditer. Leanstral 1.5 change la donne sur les trois plans en même temps — et c’est ce triptyque qui mérite l’attention.

Ce que mesure Leanstral 1.5, et pourquoi ces benchmarks ne sont pas décoratifs

Trois noms reviennent systématiquement dans les publications sur la preuve automatique : miniF2F, PutnamBench et la famille FATE. Tous formalisent des problèmes mathématiques en Lean 4 (parfois aussi en Isabelle) : il ne suffit donc pas au modèle de « trouver la bonne idée » — il doit produire une suite d’étapes qu’un vérificateur mécanique accepte comme valide.

miniF2F rassemble 488 problèmes tirés de compétitions pour étudiants (AMC, AIME, Olympiades internationales de mathématiques). « Saturer » miniF2F, comme le fait Leanstral 1.5 avec 100 % en validation et en test, signifie que le modèle prouve effectivement tous les énoncés — un seuil qui était jusqu’ici hors de portée des modèles généralistes.

PutnamBench formalise les problèmes du Putnam Mathematical Competition, concours nord-américain considéré comme l’une des épreuves de mathématiques undergrad les plus exigeantes au monde (les scores médians historiques y sont proches de zéro). Sur les 672 énoncés formalisés, Leanstral 1.5 en résout 587, soit environ 87 %. C’est, d’après les chiffres publiés par Mistral, sept problèmes de plus que Seed-Prover 1.5 en mode high — pour un coût par problème inférieur d’environ deux ordres de grandeur.

FATE-H et FATE-X sont des benchmarks d’algèbre abstraite de niveau graduate et doctorat. Leanstral 1.5 y pousse l’état de l’art à 87 % et 34 % respectivement, au-dessus des modèles comparables (Goedel-Architect sans guidage en langage naturel, Seed-Prover 1.5, AxProverBase). Mistral signale aussi qu’Aleph Prover, plus performant sur certaines configurations, tourne à environ 54–68 dollars par problème, contre environ 4 dollars pour Leanstral.

FLTEval, enfin, est particulier : il est dérivé de pull requests réelles sur le dépôt « Fermat’s Last Theorem » et mesure la capacité à compléter ou corriger des preuves de recherche. Mistral a publié FLTEval en open source en même temps que le modèle. Leanstral 1.5 passe le pass@1 de 21,9 à 28,9 et le pass@8 de 31,9 à 43,2 — au-dessus des 39,6 d’Opus 4.6, et ce à environ un septième du coût. Le modèle distance aussi des modèles open source trois à dix fois plus grands en paramètres.

Tableau comparatif des principaux modèles

Les chiffres suivants proviennent des billets techniques publiés par Mistral, MarkTechPost et de la carte modèle Hugging Face. pass@k = le modèle a droit à k tentatives par problème ; Seed-Prover 1.5 high est exécuté avec un budget de 10 jours-H20 par problème, ce qui explique son coût élevé.

• Leanstral 1.5 — miniF2F 100 % · PutnamBench 587/672 · FATE-H 87 % · FATE-X 34 % · FLTEval pass@8 43,2 · ~4 $ par problème.
• Seed-Prover 1.5 (high) — sur PutnamBench, environ 7 problèmes de moins que Leanstral 1.5 · ~300 $ ou plus par problème (budget 10 H20-jours).
• Aleph Prover — configuration plus performante sur certains sous-ensembles · ~54–68 $ par problème.
• Goedel-Architect (sans guidance NL) — référence comparée par Mistral, derrière Leanstral 1.5 sur FATE et PutnamBench.
• AxProverBase — autre référence publique, derrière Leanstral 1.5.
• Opus 4.6 (Anthropic) — FLTEval pass@8 39,6 ; surpassé par Leanstral 1.5 (43,2) à environ 1/7 du coût.

Une architecture MoE 119B / 6B pensée pour le self-hosting

Leanstral 1.5 est construit sur une architecture Mixture-of-Experts : 119 milliards de paramètres au total, mais seulement 6,5 milliards activés par token (128 experts, 4 actifs à chaque passage). La fenêtre de contexte est de 256 000 tokens, l’entrée accepte texte et image, la sortie reste textuelle. Le modèle appartient à la famille Mistral Small 4 et succède à Leanstral-2603.

Ce choix n’est pas anodin. Pour un agent qui doit appeler un compilateur Lean, lire des erreurs de type et manipuler un dépôt complet, le contexte long est crucial : il faut pouvoir conserver la trace d’une preuve partielle, les définitions auxiliaires, l’état de la session. Le format MoE, lui, permet de limiter le coût d’inférence par token à un niveau compatible avec une exécution on-prem — ce qui n’est pas le cas d’un modèle dense de 100+ milliards.

Côté matériel, la carte Hugging Face recommande vLLM 0.24 ou plus récent, avec backend FLASH_ATTN_MLA, taille de tenseur parallèle à 4 et max-model-len à 200 000 tokens. Ces contraintes reflètent une volonté assumée d’hébergement souverain : l’équipe a explicitement comparé l’empreinte aux flux d’API fermés et l’a trouvée viable pour des infrastructures internes de taille moyenne.

Trois étapes d’entraînement et deux environnements RL

L’entraînement est en trois étapes : mid-training, supervised fine-tuning, puis reinforcement learning avec CISPO (une variante d’optimisation de politique que l’on retrouve dans plusieurs pipelines agentiques modernes). Le modèle a été confronté à deux environnements RL distincts qui expliquent en grande partie son comportement final.

Dans le premier, dit multiturn, l’agent reçoit un énoncé de théorème. Il doit le prouver ou le réfuter : il soumet une preuve, reçoit le verdict du compilateur Lean (qui retourne des erreurs de type ou de logique), puis itère jusqu’à ce que la preuve compile ou qu’il épuise son budget de tokens.

Dans le second, dit code agent, l’agent travaille dans un système de fichiers brut. Il édite des fichiers, exécute des commandes bash, interagit avec le serveur de langage Lean pour inspecter des goals, lire des erreurs et examiner des types en temps réel. Cette configuration lui permet d’absorber des tâches de très longue portée — par exemple terminer une preuve partielle dans un dépôt, construire des lemmes auxiliaires, persister à travers plusieurs compressions de contexte. À la fin, chaque preuve candidate est vérifiée par un fork maison de SafeVerify (github.com/mistralai/LeanstralSafeVerify) pour garantir qu’elle correspond bien à la liste de théorèmes ciblés.

Le test-time scaling : la vraie signature du modèle

La caractéristique la plus remarquable de Leanstral 1.5 n’est pas un score absolu, mais la régularité avec laquelle il continue à progresser quand on lui donne plus de temps de calcul. Sur PutnamBench, le pass@8 grimpe de façon monotone avec le budget de tokens par tentative :

• 44 problèmes résolus à 50 000 tokens.
• 244 problèmes à 200 000 tokens.
• 493 problèmes à 1 000 000 tokens.
• 587 problèmes à 4 000 000 tokens.

Ce comportement, que les chercheurs appellent test-time scaling, est plus informatif qu’un score isolé. Il montre que le modèle ne « craque » pas quand la preuve devient longue — au contraire, il exploite chaque token supplémentaire pour réviser, éditer, recompiler. La preuve du cas d’étude sur les arbres AVL illustre concrètement cette discipline : elle s’étend sur 2,7 millions de tokens et 22 compressions de contexte, et établit pour une vraie implémentation que l’insertion et la suppression sont bien en O(log n), avec une borne presque serrée de 48 étapes par unité de hauteur plus une constante. Ce type de résultat n’a, à ce jour, été documenté par aucun autre fournisseur pour un modèle libre.

Trouver de vrais bogues dans du Rust : la preuve que la vérification formelle devient industrialisable

La partie la plus inattendue du billet de Mistral concerne la capacité du modèle à inspecter du code Rust réel. Le pipeline combine Aeneas, un traducteur Rust vers Lean, et Leanstral, qui infère l’intention de l’utilisateur, génère des propriétés de correction, puis tente de les prouver en quatre essais — et, en cas d’échec, tente la négation en quatre essais supplémentaires.

Sur 57 dépôts testés, ce pipeline a signalé 47 propriétés violées, dont 11 bogues véritables — et cinq d’entre eux n’avaient jamais été signalés sur GitHub. L’un deux, particulièrement parlant, se trouvait dans la fonction de décodage zigzag de la bibliothèque datrs/varinteger. Sur l’entrée Std.U64.MAX, l’expression (value + 1) overflowait, provoquant un crash en mode debug et une corruption silencieuse en mode release — un cas-limite que les tests et le fuzzing classiques laissent typiquement passer.

Pour les équipes qui développent des bibliothèques cryptographiques, des compilateurs ou des logiciels critiques, ce résultat a une signification simple : la vérification formelle industrielle, c’est-à-dire la possibilité de prouver mécaniquement qu’une fonction fait ce qu’elle est censée faire, n’est plus un domaine réservé à quelques équipes spécialisées. Un agent open-source, installable et auditable, commence à savoir pointer du doigt des bogues réels sur du code open source largement utilisé.

Souveraineté, licence et déploiement : ce que change vraiment le choix d’Apache-2.0

Le choix de la licence Apache-2.0 n’est pas un détail juridique : il autorise l’utilisation commerciale, la modification et la redistribution sans restriction. Pour les organisations européennes qui veulent héberger elles-mêmes un agent de preuve formelle, sans dépendre d’une API américaine dont les conditions générales peuvent changer, ce point est aussi important que les chiffres de benchmark.

Trois voies d’accès coexistent :

• Poids open source sur Hugging Face, à exécuter sur une infrastructure maîtrisée (vLLM 0.24+, GPU de taille suffisante pour le tensor-parallel).
• API gratuite leanstral-1-5, accessible depuis le plan gratuit de Mistral, sans obligation de souscription Mistral Pro.
• CLI Mistral Vibe avec l’agent Lean : vibe --agent lean, à installer via uv tool install mistral-vibe. L’option --yolo active l’approbation automatique des modifications (à utiliser avec précaution).

Mistral recommande temperature = 1.0, un reasoning_effort à high pour les énoncés complexes, et une fenêtre effective ≤ 200 000 tokens. Le contexte maximal annoncé (256 000) reste utilisable, mais avec une marge de sécurité pour absorber les mécanismes internes de l’agent.

Ce que cela change pour la recherche, l’industrie et la souveraineté européenne

Trois implications concrètes se dessinent à court terme.

D’abord, pour la recherche en mathématiques, Leanstral 1.5 rapproche les assistants de preuve d’un usage quotidien par les mathématiciens eux-mêmes. Saturation de miniF2F, 87 % de PutnamBench, et 87 % sur FATE-H ne signifient pas que le modèle remplace un chercheur, mais qu’il devient capable de proposer des étapes exploitables, de signaler des chemins qui ne tiennent pas, et de générer des lemmes auxiliaires. Pour des projets longs comme les formalisations de théorèmes de pointe, ce gain de productivité peut être décisif.

Ensuite, pour l’industrie du logiciel, la perspective d’un agent open-source capable de pointer des bogues d’overflow dans du code Rust de production rebat les cartes de la vérification logicielle. Les outils classiques (linters, fuzzers, tests unitaires) couvrent certains cas, mais pas ceux où la logique de la fonction est correcte en intention et fausse en arithmétique — exactement le profil du bug varinteger.

Enfin, pour la souveraineté numérique européenne, le fait que cette pile — Mistral Small 4, licence Apache-2.0, hébergement on-prem, conformité RGPD par construction — vienne de Paris plutôt que de la Silicon Valley a une portée pratique. Les organisations publiques, les laboratoires et les entreprises de secteurs régulés (santé, énergie, transport, défense) qui hésitaient à intégrer un agent de preuve dans leur chaîne de production disposent désormais d’une option libre, vérifiable et conforme aux exigences européennes.

Leanstral 1.5 n’est pas la fin de la vérification formelle, et il reste des limites : la traduction Rust → Lean via Aeneas est partielle, les bogues « logiques » (pas arithmétiques) restent plus difficiles à attraper, et un seul bug raté dans une preuve formelle peut invalider une chaîne complète. Mais l’écart entre « démo de recherche » et « outil utilisable en production » se réduit rapidement, et c’est précisément ce mouvement qu’il vaut la peine de suivre de près.

Sources

• Mistral AI — Leanstral 1.5 : Proof Abundance for All (3 juillet 2026)
• Hugging Face — mistralai/Leanstral-1.5-119B-A6B (carte modèle officielle, 3 juillet 2026)
• MarkTechPost — Mistral AI Releases Leanstral 1.5 (3 juillet 2026)
• European Purpose — Mistral AI’s Open-Source Leanstral 1.5 Sets New Bar for Formal Verification AI (3 juillet 2026)
• ExplainX — Leanstral 1.5 : Mistral Open-Source Formal Verification (3 juillet 2026)