Claude vérification formelle : Anthropic et Theorem démontrent qu’un modèle de langage peut mathématiquement certifier des logiciels critiques et éliminer des failles historiques. En quelques semaines, l’intelligence artificielle a généré 180 millions de lignes de preuve formelle pour 123 bibliothèques open source, repérant des vulnérabilités enfouies depuis dix ans.
- 180 millions de lignes de preuve générées en Rocq pour 123 bibliothèques open source majeures.
- 239 points d’entrée certifiés sans aucun crash possible pour toute entrée inférieure à 64 Mo sur RISC-V.
- Des failles critiques débusquées, dont des bugs logiques vieux de dix ans ignorés par le fuzzing classique.
- Opus 5.5 en nette progression : 40 % de jetons en moins nécessaires pour résoudre les théorèmes.
- Mise à disposition publique des sémantiques et des preuves pour les développeurs.
Sommaire
- Du test aléatoire à la certitude mathématique
- Comment fonctionne Claude vérification formelle en pratique
- Des failles vieilles de dix ans débusquées
- Claude vérification formelle : limites et coût réel
- Fuzzing traditionnel vs vérification par IA
- Mon avis : l’impossible promesse du zéro bug enfin mathématisée
- Foire aux questions
- Sources officielles
Du test aléatoire à la certitude mathématique
Pendant des décennies, prouver qu’un programme informatique ne plantera jamais relevait du luxe réservé à l’aérospatiale. Vérifier formellement le micro-noyau seL4 avait exigé vingt années-homme d’experts. En pratique, l’industrie logicielle s’est toujours contentée du test par saturation brute, le fuzzing, qui injecte des milliards de données aléatoires pour tenter de faire crasher une application.
Mais le fuzzing a un défaut majeur : il ne garantit jamais l’absence de bugs, seulement qu’il n’en a pas encore trouvé. Avec la prolifération des cyberattaques automatisées, cette approche montre ses limites. L’équipe Frontier Red Team d’Anthropic, en partenariat avec la jeune pousse Theorem, vient de franchir un cap avec Claude vérification formelle, automatisant la preuve à une échelle industrielle.
Au lieu de confier la rédaction des théorèmes à des mathématiciens, les chercheurs ont missionné leur modèle pour traduire le code machine et les suites de tests en spécifications mathématiques vérifiées mécaniquement.
Comment fonctionne Claude vérification formelle en pratique
Le pipeline mis au point pour Claude vérification formelle s’attaque directement aux binaires compilés, et non à du code abstrait. Les chercheurs ont sélectionné des composants issus d’OSS-Fuzz, le banc d’épreuve de Google qui surveille les bibliothèques open source critiques du web.
Chaque programme et sa suite de tests sont compilés en instructions assembleur RISC-V pour Linux. Theorem fournit ensuite le modèle formel décrivant le processeur et les appels système. La cible est nette : démontrer que pour toute entrée inférieure à 64 Mo, le programme se termine normalement sans violer la mémoire et sans déclencher d’assertion.
Face à ce cahier des charges, le grand modèle de langage produit le code de preuve dans le langage Rocq. Un vérificateur mécanique indépendant examine ensuite chaque étape de la démonstration mathématique. Si la preuve est validée par Rocq, la certitude est absolue dans le cadre du modèle posé : aucun humain n’a besoin de relire les 600 000 lignes de calcul générées par binaire.
Le dispositif Claude vérification formelle ne se contente pas de prouver le code existant. Lorsqu’une démonstration achoppe sur un bug réel, l’assistant rédige un correctif, met à jour la spécification et relance la démonstration jusqu’à obtenir un certificat irréfutable.
Des failles vieilles de dix ans débusquées
La démarche a été éprouvée sur 123 bibliothèques logicielles open source et 239 points d’entrée distincts. Au fil des semaines, le système a produit environ 180 millions de lignes de preuve formelle en Rocq. Mais l’expérience s’est surtout révélée être une redoutable machine à débusquer les vulnérabilités.
En cherchant à construire ses preuves mathématiques, le système a mis au jour des centaines d’anomalies que des milliers d’heures de fuzzing classique n’avaient jamais fait remonter :
- Un sous-dépassement de compteur mémoire dans un décompresseur, menant à une écriture hors limites uniquement sur des fichiers de 20 Mo dotés d’une structure très spécifique.
- Une lecture hors limites dans un décodeur d’image nécessitant un fichier de 64 Mo et plus de 2 Go d’allocation mémoire.
- Une faille logique vieille de plus de dix ans dans une bibliothèque système, où les restrictions d’accès aux fichiers locaux n’étaient pas appliquées dans certains cas particuliers sans provoquer de crash.
- Une hécatombe de failles dans un lecteur PDF : en une seule semaine, l’analyse formelle a recensé autant de failles de sécurité que le total annuel habituellement constaté sur ce composant.
Claude vérification formelle : limites et coût réel
Le déploiement de Claude vérification formelle ne signifie pas pour autant la disparition instantanée des failles logicielles. Anthropic et Theorem soulignent plusieurs contraintes techniques de taille.
D’abord, le périmètre des hypothèses reste strict. Les preuves actuelles reposent sur des binaires statiques mono-threadés exécutés sur une architecture RISC-V virtuelle, avec un plafond de mémoire fixé et des entrées limitées à 64 Mo. Transposer Claude vérification formelle à des applications multi-thread complexes exploitant des pilotes propriétaires exigera des modèles sémantiques plus lourds.
Ensuite, le coût en ressources computationnelles demeure élevé. La génération d’une seule preuve complète pour un binaire moyen consomme fréquemment des centaines de millions de jetons d’inférence. Le projet montre toutefois des gains rapides : le modèle Claude Opus 5.5 résout désormais les théorèmes avec 40 % de calcul en moins que son prédécesseur, surpassant largement Claude Sonnet 5.5 sur ces tâches.
Fuzzing traditionnel vs vérification par IA
Pour mieux cerner la rupture méthodologique, voici la comparaison des approches de sécurisation logicielle :
| Critère | Fuzzing classique (OSS-Fuzz) | Preuve formelle humaine | Claude vérification formelle |
|---|---|---|---|
| Principe | Génération massive d’entrées aléatoires | Démonstration manuelle par des experts | Génération de preuves Rocq par modèle de langage |
| Garantie | Statistique (aucun crash observé) | Absolue dans le modèle spécifié | Absolue dans le modèle spécifié (RISC-V/Linux) |
| Temps par composant | Continu (semaines de calcul) | Plusieurs années-homme | Quelques heures de calcul |
| Bugs trouvés | Crashs reproductibles simples | Bugs conceptuels débusqués à la main | Failles rares, logiques et cas limites complexes |
| Volume de preuve | Aucun | Dizaines de milliers de lignes relues | 180 millions de lignes vérifiées par machine |
À lire aussi dans le dossier Agents IA : découvrez notre guide complet et comparatif des agents IA pour automatiser vos flux de travail.
Mon avis : l’impossible promesse du zéro bug enfin mathématisée
Éditorial : cette section exprime mon opinion.
Voilà quarante ans que l’informatique nous vend le mythe du code parfait, pendant que nos systèmes d’exploitation continuent d’aligner des milliers de correctifs par an. Jusqu’ici, la preuve formelle ressemblait à un sport d’élite : formidable pour piloter une fusée ou un réacteur nucléaire, totalement impensable pour la moindre bibliothèque graphique ou le pilote de ton imprimante.
L’avancée concrétisée par Claude vérification formelle tranche par son pragmatisme. Plutôt que de rêver d’une réécriture totale en Rust ou de former des armées d’ingénieurs à Coq, Anthropic et Theorem ont branché un modèle sur l’assembleur brut pour certifier la sécurité sans sourciller. 180 millions de lignes de preuve mathématique en quelques semaines, c’est vertigineux.
Mais gardons les pieds sur terre : brûler des centaines de millions de jetons pour certifier un décodeur d’image reste un privilège de géant de la tech. Si ton budget d’inférence s’évapore avant d’avoir audité le quart de tes dépôts, l’intérêt direct pour une PME reste théorique.
Je peux me tromper, mais la méthodologie Claude vérification formelle constitue un tournant où l’automatisation apporte une valeur indiscutable. Si tu gères des paquets open source sensibles, surveille ces outils : c’est sans doute le début de la fin pour les failles mémoire ancestrales.
Foire aux questions
Qu’est-ce que Claude vérification formelle apporte de nouveau ?
Cette approche permet d’automatiser entièrement la production de preuves mathématiques de sécurité au niveau du code binaire, une tâche qui exigeait auparavant des années de travail humain qualifié.
Quels types de failles ont été découverts lors de l’expérience ?
Le système a mis au jour des sous-dépassements de compteurs mémoire, des lectures hors limites sur de gros volumes de données et des erreurs logiques de contrôle d’accès vieilles de dix ans.
Le code vérifié mathématiquement est-il totalement infaillible ?
Non, la garantie ne vaut que dans les limites du modèle formel posé, ici un binaire RISC-V statique mono-thread sous Linux avec des entrées de moins de 64 Mo.
Les outils et preuves générés sont-ils accessibles publiquement ?
Oui, Anthropic et Theorem publient un sous-ensemble des preuves Rocq, les sémantiques RISC-V et proposent un pipeline ouvert pour les projets de la communauté open source.