Claude génère 180 millions de lignes de preuves formelles : 123 librairies open-source vérifiées au niveau assembleur RISC-V

Claude génère 180 millions de lignes de preuves formelles : 123 librairies open-source vérifiées au niveau assembleur RISC-V

🔎 Pourquoi ça change la donne

Anthropic et Theorem viennent de franchir un cap que l'industrie attend depuis des décennies : la vérification formelle à l'échelle industrielle, pilotée par IA, sur du code réel en production. Publiée le 22 octobre, l'expérience porte sur 123 librairies open-source, 239 points d'entrée issus d'OSS-Fuzz, et produit environ 180 millions de lignes de preuves Rocq (Coq) — soit l'équivalent de plusieurs noyaux Linux en volume de spécifications mécaniquement vérifiées. Le noyau Rocq re-vérifie chaque preuve automatiquement. Quasi aucun relecteur humain n'intervient. En chemin, Claude a corrigé des bugs que des trillions de runs de fuzzing n'avaient pas attrapés, puis a prouvé l'absence de crash sur toute entrée jusqu'à 64 Mo. C'est la première fois que la vérification formelle sort du laboratoire pour toucher du logiciel livré, compilé vers RISC-V, avec un niveau d'automatisation qui rend le coût marginal.

L'essentiel

• 180 millions de lignes de preuves Rocq générées en quelques semaines pour 123 librairies OSS-Fuzz, vérifiées au niveau assembleur RISC-V.
• 239 points d'entrée couverts, propriété prouvée : crash-freedom (absence de plantage) pour toute entrée ≤ 64 Mo.
• Bugs découverts et patchés par Claude alors que le fuzzing massif (trillions d'exécutions) les avait manqués.
• Noyau Rocq comme tiers de confiance : chaque preuve est re-vérifiée mécaniquement, sans relecture humaine significative.
• Limites assumées : périmètre crash-freedom uniquement (pas de correction fonctionnelle), compilation RISC-V, indépendance de la vérification à questionner.

Outils recommandés

L'expérience Anthropic × Theorem : ce qui s'est passé

Anthropic a collaboré avec Theorem, startup spécialisée dans la vérification formelle automatisée, pour appliquer Claude à 123 librairies C/C++ issues d'OSS-Fuzz — le programme de fuzzing continu de Google qui tourne sur des milliers de cœurs depuis des années. Le résultat : 239 points d'entrée (API publiques, parseurs, decodeurs) couverts par des preuves de crash-freedom au niveau assembleur RISC-V, soit la garantie que aucune entrée de 64 Mo ou moins ne peut déclencher de plantage (déréférencement nul, débordement de buffer, division par zéro, assertion échouée).

Le volume est sans précédent : ~180 millions de lignes de code Rocq générées. Pour donner un ordre de grandeur, une preuve type représente ~600 000 lignes de spécifications et lemmes. Le tout en « quelques semaines » selon Anthropic, avec une intervention humaine réduite à la validation de la chaîne de compilation et à l'audit d'échantillons. Le noyau Rocq — le trusted computing base minimal de l'assistant de preuve — re-vérifie mécaniquement chaque certificat. Si le noyau dit « valide », la preuve tient. Point.

Et Claude ne se contente pas de produire les preuves : il identifie et corrige des bugs en cours de route. Des bugs que des trillions d'exécutions de fuzzing n'avaient pas découverts. Une fois patchés, les preuves passent. C'est un changement de paradigme : l'IA ne vérifie pas seulement, elle répare pour pouvoir prouver.

Pourquoi le niveau assembleur RISC-V change tout

La plupart des travaux de vérification formelle (CompCert, seL4, IronFleet) ciblent le code source ou un langage intermédiaire. Ici, la preuve porte sur l'assembleur RISC-V généré par le compilateur. Cela élimine une classe entière de failles : les bugs d'optimisation du compilateur, les comportements indéfinis C/C++ que le compilateur « exploite » silencieusement, les transformations de boucles qui cassent des invariants.

Concrètement, la chaîne de confiance est : code source → compilation GCC/Clang → binaire RISC-V → spécification assembleur → preuve Rocq. Si la preuve passe, le binaire exact qui s'exécutera est couvert. C'est ce qu'Anthropic qualifie de « première du genre » à cette échelle.

Le choix de RISC-V n'est pas anodin : ISA ouverte, spécification formelle existante (riscv-isa-formal), et adoption croissante dans l'embarqué et le cloud. Mais cela pose aussi une limite : la preuve ne vaut que pour cette cible de compilation. Recompiler pour x86-64 ou ARM64 invalide le certificat — sauf à refaire la preuve sur l'assembleur cible.

Ce que « crash-freedom » garantit (et ne garantit pas)

La propriété prouvée est l'absence de crash pour toute entrée ≤ 64 Mo. Cela couvre :
- Accès mémoire invalide (déréférencement nul, out-of-bounds, use-after-free)
- Débordements arithmétiques non gérés
- Divisions par zéro
- Assertions abort() atteintes
- Comportements indéfinis C/C++ qui mènent à un trap matériel

Ce que cela ne garantit pas :
- Correction fonctionnelle : le parseur JSON peut ne pas planter mais retourner une structure incorrecte.
- Absence de fuites mémoire : malloc sans free ne fait pas planter.
- Propriétés temporelles : pas de preuve de terminaison (boucles infinies possibles).
- Sécurité métier : bypass d'authentification, escalade de privilèges, corruption logique.

Anthropic le dit explicitement : c'est une preuve de sûreté (safety), pas de correction (correctness). La distinction est cruciale. Un validateur XML crash-free peut accepter du XML malformed et corrompre l'état de l'application en aval. La vérification formelle complète (ex: seL4, CompCert) demande des spécifications fonctionnelles — ce qui multiplie l'effort par 10 à 100.

Le rôle de Claude : générateur de preuves, pas oracle

Claude ne « sait » pas si le code est correct. Il reçoit : (1) le binaire RISC-V, (2) la spécification de crash-freedom en Rocq, (3) l'API de Theorem pour interagir avec l'assistant de preuve. Il propose des lemmes, construit des invariants de boucle, tente des tactiques lia, omega, auto, itère jusqu'à ce que le noyau Rocq valide.

C'est de la recherche de preuve guidée par LLM. Theorem fournit l'environnement (extraction CFG, génération de VCs, interface Rocq), Claude fait l'ingénierie de preuve. Le taux de réussite n'est pas public, mais le volume (180 M lignes) suggère une automatisation massive avec peu d'échecs bloquants.

Cela rappelle le rapport Anthropic sur Codex où 53-58% de bugs étaient trouvés mais avec des échecs significatifs — ici, l'itération preuve/réparation semble converger plus fiablement grâce au retour binaire du noyau Rocq. Voir le rapport Anthropic sur Codex pour la comparaison.

Les bugs que le fuzzing a manqués

C'est le point le plus frappant. OSS-Fuzz exécute des trillions d'entrées sur ces librairies depuis des années. Pourtant, Claude a trouvé des bugs accessibles seulement via des chemins complexes que le fuzzing n'explore pas assez profondément : conditions de bord sur des boucles imbriquées, interactions entre plusieurs parsers, cas limites de la spécification RISC-V (ex: instructions non alignées, registres réservés).

Exemple concret cité par AI Weekly : un decodeur d'images où une boucle while avec condition ptr < end passait en assembleur à une comparaison non signée que le fuzzing n'avait jamais fait déborder. Claude a produit l'invariant de boucle, Rocq a vérifié, le bug a été patché, la preuve a passé.

Ce n'est pas de la magie : le fuzzing explore aléatoirement, la preuve explore systématiquement l'espace d'états via les invariants. Les deux sont complémentaires. Mais l'IA rend la preuve assez bon marché pour la déployer là où le fuzzing sature.

La chaîne de confiance : Rocq comme tiers impartial

Tout repose sur le noyau de Rocq (~2000 lignes OCaml). Ce noyau vérifie chaque certificat de preuve indépendamment de Theorem, d'Anthropic, de Claude. Si le noyau accepte, la preuve est valide — peu importe qui l'a générée. C'est la différence fondamentale avec « l'IA dit que c'est bon ».

En pratique, la chaîne est :
1. Theorem extrait le graphe de flot de contrôle (CFR) du binaire RISC-V
2. Génère les conditions de vérification (VCs) pour crash-freedom
3. Claude propose une preuve (suite de tactiques Rocq)
4. Rocq kernel re-vérifie le certificat final
5. Si OK → artefact signé (hash du binaire + preuve)

Aucun humain ne relit les 180M lignes. Des échantillons sont audités. La confiance est déléguée au noyau. C'est la même architecture que CompCert ou seL4, mais à une échelle 1000x supérieure grâce à l'automatisation LLM.

Limites honnêtes : ce qu'Anthropic ne résout pas

1. Indépendance de la vérification

Theorem est partenaire d'Anthropic. Claude est le modèle d'Anthropic. La preuve est générée par l'acteur qui fournit le modèle. Aucune tierce partie indépendante n'a re-vérifié l'ensemble. Le noyau Rocq est impartial, mais la construction de la preuve (choix des invariants, lemmes, abstractions) est faite par Claude. Un invariant trop faible passe le noyau mais ne prouve pas la propriété voulue — sauf que ici la propriété (crash-freedom) est encodée dans les VCs générées avant l'intervention de Claude. Donc le risque est faible, mais non nul.

2. Compilation non vérifiée

La preuve porte sur l'assembleur RISC-V produit par GCC/Clang. Le compilateur n'est pas vérifié (Contrairement à CompCert). Un bug de compilateur pourrait introduire un crash dans le binaire qui n'existe pas dans la preuve. Probabilité faible, impact potentiellement élevé.

3. Spécification incomplète

Crash-freedom ≠ sécurité. Une librairie de parsing prouvée crash-free peut encore être vulnérable à des attaques logiques (ex: billion laughs, hash flooding, confusion de type). La preuve ne couvre pas la sémantique métier.

4. Modèle de menace matériel

La preuve assume un modèle RISC-V standard. Pas de canaux cachés, pas de Spectre/Meltdown, pas de Rowhammer. C'est du logiciel, pas du matériel.

5. Évolutivité maintenance

Quand la librairie change (nouvelle version, patch), la preuve doit être régénérée. Anthropic n'a pas publié de pipeline CI/CD pour maintenir les preuves en continu. C'est une preuve ponctuelle, pas un processus continu.

Comparatif : où ça se situe par rapport à l'existant

L'innovation n'est pas la vérification formelle — elle existe depuis 40 ans. L'innovation est l'automatisation de l'ingénierie de preuve par LLM qui abaisse le coût sous le seuil de rentabilité pour du code « ordinaire » (pas safety-critical).

Implications pour l'industrie du logiciel

Court terme (6-18 mois)

• Adoption dans la supply chain : preuves de crash-freedom pour dépendances critiques (zlib, libpng, openssl, sqlite).
• CI/CD avec preuves : génération de certificats Rocq en artefact de build, vérification en pipeline.
• Assurance logicielle : primes réduites pour composants prouvés crash-free.

Moyen terme (2-5 ans)

• Spécifications fonctionnelles assistées par LLM : au-delà du crash-freedom, pré/post-conditions métier.
• Compilateurs vérifiés par défaut : pression pour adopter CompCert ou formellement vérifier GCC/Clang.
• Régulation : exigences de preuves formelles pour logiciels critiques (médical, auto, finance).

Long terme

• Fin du « test comme unique filet » : les tests deviennent des exemples ; les preuves deviennent la garantie.
• IA qui écrit + prouve + maintient : boucle fermée spécification → code → preuve → déploiement.

Écosystème open source : la riposte commence

Pendant qu'Anthropic/Theorem ferment le code (Theorem est propriétaire, Claude est fermé), l'open source s'organise. OpenCode (8M devs, 172K ⭐) explore l'agent de codage local. Qwen3-Coder-Next (80B MoE, 3B actifs) rivalise avec Claude Sonnet sur le code. Odysseus de PewDiePie propose un workspace IA auto-hébergé.

Pour la vérification formelle, des projets comme Lean 4 + Mathlib, F* (Fstar), Dafny intègrent déjà des backends LLM. La course est lancée : qui aura le premier pipeline entièrement open (modèle + outil preuve + CI) pour crash-freedom à l'échelle OSS-Fuzz ?

❌ Erreurs courantes

Erreur 1 : Confondre crash-freedom et correction

Ce qui ne va pas : Dire « cette librairie est prouvée correcte ». Elle est prouvée ne pas planter. Un parseur JSON qui retourne null au lieu d'une erreur sur entrée invalide est crash-free mais incorrect.
Solution : Toujours préciser la propriété prouvée. Demander le certificat Rocq et l'inspecter (ou faire auditer).

Erreur 2 : Croire que la preuve couvre le code source

Ce qui ne va pas : Appliquer la preuve au repo GitHub. La preuve couvre le binaire RISC-V compilé avec des flags précis. Recompiler différemment invalide la garantie.
Solution : Distribuer le binaire prouvé + sa preuve, ou verrouiller la toolchain (Docker image reproductible).

Erreur 3 : Négliger le TCB étendu

Ce qui ne va pas : Penser que seul le noyau Rocq compte. La chaîne inclut : extracteur CFG (Theorem), générateur VCs, compilateur, spécification RISC-V, modèle mémoire.
Solution : Auditer chaque maillon ou exiger des preuves de bout en bout (ex: CompCert + VST).

Erreur 4 : Sous-estimer le coût de maintenance

Ce qui ne va pas : Intégrer une preuve ponctuelle sans budget pour la mettre à jour à chaque release.
Solution : Négocier un SLA de régénération de preuves avec le fournisseur, ou internaliser la compétence.

❓ Questions fréquentes

Cette technologie remplacera-t-elle les tests unitaires ?

Non. Les tests restent indispensables pour la correction fonctionnelle, la régression métier, la performance. La preuve de crash-freedom complète les tests en couvrant l'infini des entrées là où les tests échantillonnent.

Puis-je l'appliquer à mon code Rust/Go/Python ?

Pas directement. L'expérience cible du C/C++ compilé vers RISC-V. Rust a des garanties mémoire au niveau source (borrow checker) mais pas de preuve assembleur automatisée à cette échelle. Go/Python ont un runtime (GC) qui complique la preuve au niveau machine. C'est une piste de recherche active.

Le noyau Rocq peut-il avoir des bugs ?

Théoriquement oui. Pratiquement, le noyau est minuscule (~2000 lignes), formellement spécifié, et utilisé en production critique depuis 20 ans (CompCert, seL4, CertiKOS). La probabilité d'un bug noyau qui valide une fausse preuve de crash-freedom est négligeable face au risque de bug dans le code non vérifié.

Combien ça coûte ?

Anthropic ne publie pas de grille. Theorem facture au projet. Estimation ordre de grandeur : 10k-100k $ par librairie selon complexité, vs 1M+ $ pour vérification manuelle équivalente. Le ROI s'atteint sur composants critiques à forte exposition.

Est-ce utilisable en production aujourd'hui ?

Oui, pour des composants C/C++ critiques (parseurs, codecs, crypto) compilés pour RISC-V. La chaîne Theorem + Claude est opérationnelle. Pour d'autres cibles ou langages : pas encore packagé.

✅ Conclusion

Anthropic et Theorem viennent de démontrer que la vérification formelle à l'échelle industrielle est devenue économique grâce aux LLM. 180 millions de lignes de preuves Rocq, 123 librairies, 239 points d'entrée, niveau assembleur RISC-V, en quelques semaines. Ce n'est plus de la recherche — c'est un service.

La limite est claire : crash-freedom seulement, compilation RISC-V, confiance dans la chaîne Theorem/Claude. Mais le seuil est franchi. Dorénavant, ne pas prouver les composants critiques exposés aux entrées non fiables devient une décision de risque assumée, plus une fatalité technique.

Pour les équipes qui veulent explorer l'auto-hébergement d'agents de codage et de preuve, les agents IA avec Ollama offrent un point de départ local. Pour comparer les modèles sur la génération de code et de preuves, voir notre comparatif des meilleurs LLM pour coder et Claude vs ChatGPT.