Vérification formelle : l’audit crypto qui prouve le code

Balancer V2 avait été audité onze fois par quatre cabinets, dont Certora, le spécialiste mondial de la preuve mathématique appliquée au code. Le 3 novembre 2025, un attaquant a quand même vidé ses pools de plus de 116 millions de dollars (près de 100 millions d’euros), certaines estimations montant jusqu’à 128 millions de dollars (environ 111 millions d’euros), en exploitant une erreur d’arrondi présente dans le code depuis 2021. Le plus troublant n’est pas que des auditeurs aient laissé passer le bug. C’est que Certora avait bel et bien prouvé, formellement, que le contrat était correct. Correct au regard des propriétés qu’on lui avait demandé de vérifier. Or l’arrondi fautif n’en faisait pas partie.

Cette nuance résume tout ce qu’il faut comprendre de la vérification formelle en 2026 : la méthode d’audit la plus rigoureuse qui existe, et la plus mal comprise. Là où un audit manuel relit le code et où un fuzzer le bombarde d’entrées aléatoires, la vérification formelle produit une preuve mathématique qu’un programme respecte une spécification sur la totalité de ses exécutions possibles. Pas un échantillon : toutes. C’est le seul outil du secteur qui promet une garantie plutôt qu’une opinion. Et c’est aussi celui dont la limite est la plus contre-intuitive : il ne prouve que ce qu’on prend la peine de spécifier.

Ce dossier passe la vérification formelle au banc d’essai : comment elle fonctionne, ce que le Certora Prover attrape vraiment, pourquoi il a manqué Balancer, comment il se compare à Runtime Verification, Veridise ou Halmos, et pourquoi, en pleine vague de code généré par intelligence artificielle, elle redevient le sujet le plus stratégique de la sécurité on-chain.

Prouver n’est pas tester : ce que change la vérification formelle

La vérification formelle est une technique héritée de l’informatique académique, où elle sert depuis des décennies à certifier des logiciels critiques : avionique, noyaux de systèmes d’exploitation, circuits électroniques. Appliquée aux smart contracts, elle produit, selon la présentation qu’en fait Certora, une preuve mathématique que le programme se comporte conformément à sa spécification sur l’ensemble de ses exécutions. La formulation exacte compte : sur toutes les exécutions, pas sur celles qu’un testeur a imaginées.

La différence avec les autres méthodes est de nature, pas de degré. Le test unitaire vérifie une poignée de scénarios choisis à la main. Le fuzzing en génère des millions au hasard, mais reste un échantillonnage : il peut passer à côté du seul cas pathologique qui compte. L’audit manuel augmente la confiance, mais ne fournit aucune garantie de correction. La vérification formelle, elle, offre une couverture complète des chemins pour une propriété donnée : soit la règle tient sur toutes les entrées et tous les chemins, soit l’outil recrache un contre-exemple, c’est-à-dire une entrée concrète qui la viole. Il n’y a pas de zone grise.

L’image la plus juste est celle de la serrure. Tester un cadenas, c’est essayer beaucoup de clés et conclure qu’aucune ne l’ouvre. Le prouver formellement, c’est démontrer qu’aucune clé, existante ou non, ne peut l’ouvrir ; et si l’une le peut, l’outil vous la tend. Cette promesse fait toute la valeur de la méthode, et explique pourquoi elle coûte cher et pourquoi elle est réservée, en pratique, aux protocoles qui gardent des milliards.

Certora : le cabinet qui a fait de la preuve un produit

Certora n’est pas un auditeur qui aurait ajouté la vérification formelle à son catalogue : c’est une entreprise construite autour d’elle. Fondée en 2018, elle est dirigée par Mooly Sagiv, chercheur reconnu en méthodes formelles et titulaire de la chaire de systèmes logiciels à l’université de Tel-Aviv, et par Shelly Grossman au poste de directrice technique. L’équipe dirigeante aligne les doctorats en vérification de programmes, ce qui, dans un secteur où beaucoup de cabinets recrutent des développeurs autodidactes, constitue un positionnement à part.

Le modèle a convaincu les investisseurs : Certora a levé 36 millions de dollars en série B (environ 31 millions d’euros) en mai 2022, dans un tour mené par Jump Crypto, avec Tiger Global, Galaxy Digital et des investisseurs de la série A comme Coinbase, Framework Ventures et Electric Capital. La Fondation Ethereum figure aussi parmi les soutiens de la maison, ce qui n’a rien d’anodin pour un fournisseur de sécurité qui se veut infrastructure neutre plutôt que prestataire parmi d’autres.

Les chiffres d’usage donnent la mesure de son emprise. Certora avance que son moteur a sécurisé plus de 100 milliards de dollars (environ 86 milliards d’euros) de valeur verrouillée, à travers des protocoles comme Aave, MakerDAO, Uniswap, Lido, EigenLayer, ether.fi, Morpho, Safe ou la Fondation Solana, et que les développeurs ont écrit plus de 70 000 règles de vérification à ce jour. Aave, dont on a détaillé ailleurs le duel avec Morpho sur le crédit on-chain, est le client vitrine : chacune de ses versions majeures passe par la preuve avant déploiement.

Sous le capot du Certora Prover : CVL, solveurs SMT et explosion des chemins

Le coeur de l’offre s’appelle le Certora Prover. Son fonctionnement tient en trois temps. D’abord, l’ingénieur écrit des règles dans un langage maison, le CVL (Certora Verification Language), proche de Solidity dans sa syntaxe mais conçu pour exprimer des propriétés : par exemple qu’aucune séquence d’opérations ne peut faire apparaître des fonds, ou que la somme des soldes reste toujours égale au total émis. Ces règles sont la spécification.

Un exemple rend la mécanique tangible. Pour un token classique, on écrira une règle imposant que la somme de tous les soldes reste en permanence égale à l’offre totale : si une seule séquence de transferts, de frappes ou de brûlages parvenait à casser cette égalité, le Prover la remonterait sous forme de transaction précise. Pour un coffre, on exigera qu’aucun appelant autre que le rôle autorisé ne puisse modifier un paramètre sensible. Ces invariants paraissent évidents une fois écrits ; toute la difficulté, et tout le métier, consiste à penser à les écrire, et à les formuler assez fort pour qu’ils ferment vraiment la porte.

Ensuite, le Prover traduit le contrat et sa spécification en un jeu de contraintes logiques, puis les confie à des solveurs SMT de référence, Z3 (développé par Microsoft) et CVC5 (issu des universités de Stanford et de l’Iowa). Le solveur cherche s’il existe une seule entrée capable de violer la règle. S’il n’en trouve aucune, la propriété est prouvée. S’il en trouve une, il la restitue sous forme de contre-exemple exploitable. Une couche d’analyse statique vient dégrossir le problème, car la résolution brute est vite intraitable.

C’est là qu’intervient la limite technique la plus importante à comprendre. L’espace des exécutions possibles d’un contrat est gigantesque, et les solveurs peuvent buter dessus : boucles non bornées, arithmétique complexe, ce que les spécialistes appellent l’explosion des chemins. Quand le solveur cale ou dépasse son temps imparti, la propriété n’est ni prouvée ni réfutée : elle reste indéterminée. Un rapport de vérification formelle honnête distingue toujours ce qui a été prouvé de ce qui n’a pas pu l’être. Depuis février 2025, n’importe qui peut d’ailleurs inspecter cette mécanique : le dépôt public du Prover est ouvert.

Février 2025 : le Prover passe en open source

Pendant des années, la vérification formelle s’est vendue comme une boîte noire : on livrait le code au cabinet, on récupérait un rapport et un label. Le 24 février 2025, Certora a fait sauter ce verrou en ouvrant le code source du Prover. Le moteur, qui couvre désormais l’EVM mais aussi Solana et Stellar, peut être lu, exécuté et amélioré par n’importe qui.

La décision est stratégique autant que technique. Pour un outil de sécurité, l’ouverture est un argument de confiance : on ne demande plus aux utilisateurs de croire sur parole que le prouveur prouve ce qu’il prétend, on les invite à le vérifier. Elle change aussi le rapport de force économique. Un protocole n’est plus obligé de payer une prestation complète pour toucher à la preuve ; une équipe technique peut écrire ses propres règles, les faire tourner, et ne recourir au cabinet que pour les invariants les plus délicats. Certora pari que la valeur se déplace de la vente d’un rapport vers l’expertise de spécification, la partie que l’open source ne commoditise pas.

Pour le reste du marché, l’ouverture rebat les cartes. Elle rapproche la vérification formelle du statut d’infrastructure partagée, au même titre que les bibliothèques de contrats standard, et met la pression sur les concurrents pour justifier leurs propres approches, souvent restées fermées.

Balancer, cas d’école : la preuve ne couvre que ce qu’on spécifie

Revenons au 3 novembre 2025, parce que ce hack est le meilleur professeur de tout le dossier. La faille venait d’un arrondi dans la fonction d’upscaling des montants lors des swaps : le code arrondissait vers le bas un montant qui aurait dû être arrondi vers le haut pour favoriser le protocole. Dans les pools composables, cet écart minuscule devenait exploitable en le répétant, jusqu’à déformer la liquidité et siphonner les fonds. Le défaut dormait dans le code depuis 2021.

Ce qui rend le cas exemplaire, c’est la franchise du post-mortem de Certora. Le cabinet reconnaît noir sur blanc que son audit de 2022 ne contraignait pas la relation entre swaps individuels ni le comportement d’arrondi, et que les propriétés vérifiées n’étaient pas assez fortes pour détecter l’erreur. Autrement dit, la preuve était valide : le contrat respectait bien les règles écrites. Mais aucune de ces règles ne disait que l’arrondi devait toujours pencher du côté du protocole. La spécification avait un trou, et le trou a coûté cher.

La suite est le contrepoint instructif. Sur Balancer V3, Certora a précisément spécifié ce qui manquait : toutes les opérations se font en précision à 18 décimales gérée par le vault, les directions d’arrondi sont explicites et imposées pour chaque calcul, les pools composables cèdent la place à des tampons ERC4626 plus simples à vérifier, et une règle nommée swappingBackAndForth garantit qu’un aller-retour d’un token vers un autre puis retour ne peut jamais produire de gain. Certora a vérifié que la faille de V2 n’existe pas dans V3. Résultat : le 3 novembre, V3 est resté intact. La leçon n’est pas que la vérification formelle a échoué, c’est qu’elle ne prouve que ce qu’on lui demande de prouver.

Suhail Kakar, responsable des relations développeurs chez TAC Blockchain, a tiré la morale la plus citée de l’affaire. Rappelant que Balancer avait subi plus de dix audits, il écrit que le secteur doit accepter qu’être audité par tel ou tel cabinet ne veut presque rien dire : le code est difficile, la DeFi l’est encore plus. La preuve formelle ne dispense pas de cette humilité ; elle la rend seulement plus précise.

Ce qu’une preuve attrape vraiment : Maker, Sushi et l’équation du DAI

Insister sur Balancer sans montrer les prises serait injuste, car le palmarès de la méthode est réel et souvent spectaculaire. Le cas le plus célèbre concerne MakerDAO. En passant le code au Prover, Certora a mis au jour une violation de ce que le protocole appelle l’équation fondamentale du DAI, une erreur mathématique restée invisible depuis 2018. Certora chiffre à environ 10 milliards de dollars (près de 9 milliards d’euros) la valeur qui était potentiellement exposée. Aucun audit humain, aucune campagne de fuzzing n’avait déniché ce défaut en plusieurs années.

Le même moteur a signalé, toujours selon la documentation de Certora, un bug d’insolvabilité dans Balancer V2 et une vulnérabilité de vidage de pool dans le Trident de Sushi. Ce sont exactement les bugs rares, difficiles à trouver par le test, que la vérification formelle est faite pour dénicher : ceux qui ne se déclenchent que sur une combinaison d’entrées si improbable qu’aucun testeur ne l’aurait imaginée, mais qu’un solveur, lui, énumère.

La conclusion à retenir est double. La vérification formelle attrape des classes entières de bugs invisibles aux autres méthodes, surtout les erreurs d’arithmétique, de précision et d’invariants comptables. Et elle ne les attrape que là où une règle a été écrite pour les chercher. Le talent d’un cabinet de preuve ne se mesure pas à la puissance de son solveur, mais à la qualité des propriétés qu’il sait formuler.

Audit manuel, fuzzing, preuve, IA : le tableau des méthodes

Aucune méthode ne suffit seule, et les meilleures équipes de sécurité les empilent. Le programme de sécurité en couches d’Aave V4, qui a combiné plusieurs cabinets, un concours public et une suite d’invariants, en est l’illustration : la vérification formelle y joue le rôle de dernier filet sur les propriétés critiques, pas de solution unique. Le tableau ci-dessous résume ce que chaque approche apporte et ce qu’elle laisse filer.

La lecture correcte de ce tableau n’est pas de couronner un vainqueur, mais de comprendre la complémentarité : le fuzzing pour la largeur bon marché, l’audit manuel pour l’intention et le design, la preuve pour blinder les invariants qui gardent la caisse, l’IA pour trier et accélérer. Retirer une colonne, c’est ouvrir une porte.

Au-delà de Certora : Runtime Verification, Veridise, Halmos

Certora domine, mais ne règne pas seul. La vérification formelle est un petit monde d’acteurs très spécialisés, souvent issus des mêmes laboratoires universitaires. Runtime Verification, cofondée par le professeur Grigore Rosu, mise sur le framework K et sa sémantique formelle de l’EVM, la KEVM ; son outil Kontrol marie cette KEVM à Foundry pour que les développeurs prouvent leurs propriétés à partir des tests qu’ils écrivent déjà, une approche pensée pour réduire la barrière d’entrée.

Veridise occupe un créneau différent et de plus en plus stratégique : les circuits à divulgation nulle de connaissance. Cofondée par la professeure Isil Dillig, la maison a fait de la sécurité des systèmes ZK sa spécialité, avec des outils comme Picus, qui vérifie formellement le déterminisme des contraintes et débusque les circuits sous-contraints, cette faille typique des preuves ZK où une variable mal bornée laisse passer des sorties invalides. Des infrastructures comme RISC Zero, Linea ou Succinct s’appuient sur cette expertise, et la plateforme AuditHub, lancée fin 2025, regroupe la boîte à outils de Veridise. Du côté d’a16z, l’outil open source Halmos pousse la même logique que Kontrol : réutiliser les tests Foundry comme spécifications, avec une garantie dite bornée, honnêtement présentée comme limitée par le nombre d’itérations exploré.

Pour un protocole, le choix se joue moins sur la marque que sur la nature du risque : une brique DeFi arithmétique appelle Certora ou Runtime Verification, un rollup ou une application ZK oriente vers Veridise, une petite équipe qui veut un premier filet part de Halmos ou du SMTChecker intégré à Solidity, gratuit et souvent ignoré.

D’autres acteurs abordent la preuve par des angles voisins. ChainSecurity, né d’un essaimage de l’ETH Zurich, marie analyse automatisée et revue humaine sur les protocoles EVM. Trail of Bits, plus connu pour ses fuzzers Echidna et Medusa, maintient aussi Manticore, un moteur d’exécution symbolique cousin de la vérification formelle. Et la discipline garde ses racines académiques : les mêmes familles de techniques qui ont permis de certifier un micronoyau comme seL4 ou un compilateur comme CompCert irriguent aujourd’hui la sécurité on-chain. Le marché reste petit, pointu, et dominé par une poignée d’équipes capables de traduire un protocole en théorèmes.

Le point aveugle : la preuve prouve le code, pas l’intention

Voici la partie que les argumentaires commerciaux escamotent. La vérification formelle prouve que le code respecte une spécification. Elle ne prouve pas que la spécification est la bonne, ni que le design économique tient debout. Certora l’admet d’ailleurs sans détour : si la spécification n’encode pas correctement le comportement voulu, on ne peut pas se fier au résultat ; et si elle ne couvre pas une propriété, la preuve ne dit rien à son sujet. C’est le principe du garbage in, garbage out appliqué à la sécurité.

Cette frontière laisse dehors des classes entières d’attaques. La manipulation d’oracle, les attaques par incitation, le MEV, les mauvais paramètres de risque : rien de tout cela n’est un bug de code au sens où un solveur l’entendrait. Un protocole de prêt peut être formellement correct et se faire vider parce que son modèle de collatéral était mal calibré, exactement le genre de défaillance disséquée dans l’autopsie des créances douteuses des curateurs DeFi. La preuve valide la mécanique, pas la sagesse des règles du jeu.

Alexander Urbelis, responsable de la sécurité des systèmes chez ENS Labs, l’a résumé pour CoinDesk : les bugs qui vident les trésoreries se jouent souvent sur l’intention et les incitations adverses. Or l’intention ne se met pas en équation : elle se débat, se modélise, s’attaque en conditions réelles. C’est précisément le domaine des exercices offensifs, comme le red teaming pratiqué par Halborn, qui complète la preuve au lieu de s’y substituer.

Le vecteur le plus cher échappe à la preuve

Les chiffres du premier semestre 2026 enfoncent le clou. Selon le rapport Hack3d de CertiK, les pertes ont atteint environ 1,31 milliard de dollars (près de 1,13 milliard d’euros) sur le semestre, et la ventilation par vecteur est le vrai enseignement : les bugs de code sont le vecteur le plus fréquent, avec 204 incidents, mais le moins coûteux, à environ 152 millions de dollars (environ 131 millions d’euros) au total. L’argent, lui, est parti ailleurs.

La compromission de portefeuilles et de clés a coûté en moyenne près de 13 millions de dollars par incident, de loin le vecteur le plus cher à l’unité, tandis que les défaillances d’infrastructure et d’opérations concentrent l’essentiel de la valeur volée pour une minorité d’incidents. À l’échelle du secteur, plus de 972 millions de dollars (près de 840 millions d’euros) ont été dérobés sur le semestre selon le décompte relayé par The Block, un record en nombre d’attaques. Or la vérification formelle ne peut rien contre une clé volée, un validateur de pont corrompu ou un signataire piégé par ingénierie sociale.

C’est la limite structurelle à garder en tête : la preuve durcit le vecteur le plus commun, le code, et reste muette sur le vecteur le plus coûteux. Une clé compromise, comme dans le hack Coldcard qui a rendu certaines baleines illisibles, ou un pont vidé, comme dans la traque de l’argent volé des ponts en 2026, se produisent hors du périmètre de tout solveur. Un protocole formellement prouvé mais mal gardé côté clés reste une caisse ouverte.

Code généré par IA : pourquoi Certora a bâti AI Composer

La raison pour laquelle la vérification formelle redevient brûlante en 2026 tient en deux mots : code génératif. Les développeurs produisent désormais des contrats à coups de modèles de langage, souvent plus vite qu’ils ne peuvent les relire. Or la recherche est accablante. Une étude parue début 2026 montre que les grands modèles testés produisent des contrats truffés de failles critiques tout en étant syntaxiquement corrects ; et une évaluation d’OpenAI a vu des agents atteindre un taux de réussite de 72,2 % en mode exploitation sur un jeu de contrats. La machine écrit du code vulnérable, et d’autres machines savent l’attaquer.

La réponse de Certora est arrivée le 21 novembre 2025 avec AI Composer, présenté comme la première plateforme de codage assisté par IA sécurisée pour smart contracts. L’idée est d’insérer le Prover dans la boucle de génération : le code produit par le modèle est confronté à des règles de sûreté mathématiques avant même d’être proposé, de sorte que la vitesse de l’IA ne se paie pas en dette de sécurité. Mooly Sagiv, fondateur de Certora, le formule ainsi : utiliser l’IA ne devrait jamais signifier renoncer à la sécurité, et AI Composer prouve que l’IA et la vérification formelle peuvent travailler ensemble pour rendre les smart contracts dignes de confiance par défaut.

Le contrepoint vient de David Schwed, directeur des opérations de SVRN, qui met en garde contre la tentation inverse, celle de croire qu’un modèle se suffit à lui-même. Lancer à une IA Claude, audite mon smart contract, ne fais aucune erreur n’est pas un programme de sécurité, résume-t-il. La leçon de fond est la même que celle de Balancer : la valeur ne se déplace pas de l’humain vers l’outil, elle se déplace vers celui qui sait formuler les bonnes propriétés à prouver.

Combien coûte une preuve, et pour qui

La vérification formelle est la méthode la plus chère du marché, et pour de bonnes raisons. Écrire une spécification CVL correcte demande une compétence rare, à la croisée de la théorie et de l’ingénierie ; le travail se compte en semaines d’ingénieur senior, pas en heures. Elle n’a de sens que là où un invariant unique garde des sommes considérables : un protocole de prêt à plusieurs milliards, une brique d’infrastructure réutilisée par des dizaines d’autres, un pont. Pour une application modeste, le rapport coût-bénéfice bascule vite en faveur d’un audit manuel et d’un fuzzing sérieux.

Le secteur cherche néanmoins à démocratiser l’accès. La Fondation Ethereum a lancé en avril 2026 un programme de subvention à l’audit doté d’environ un million de dollars, ouvert à une vingtaine de cabinets dont Certora, qui prend en charge jusqu’à 30 % du coût d’une revue, versés seulement une fois les correctifs appliqués. L’ouverture du Prover en open source va dans le même sens : elle permet aux équipes de faire tourner elles-mêmes des preuves simples et de réserver le budget cabinet aux invariants les plus retors.

En pratique, une prestation de vérification formelle sérieuse se chiffre en dizaines de milliers d’euros, et grimpe vite quand le périmètre s’élargit ou que les invariants sont ardus. C’est un multiple d’un audit manuel équivalent, justifié par la rareté des ingénieurs capables de l’exécuter et par le temps que réclame l’écriture des spécifications. Beaucoup de protocoles réservent donc la preuve à leur coeur critique, le module qui détient les fonds ou fixe les prix, et laissent le reste à l’audit et au fuzzing. C’est une allocation de budget, pas un label à cocher.

La bonne question pour un projet n’est donc pas de savoir si la preuve formelle est trop chère, mais quelles propriétés méritent d’être prouvées. Sur un périmètre bien choisi, quelques invariants critiques bien spécifiés, elle offre le meilleur rapport assurance sur euro dépensé de toute la panoplie. Étalée sans discernement sur tout un codebase, elle ruine un budget sans rien garantir de plus.

Lire une preuve sans se faire avoir : la spec, pas le badge

Un label vérifié formellement ne signifie qu’une chose : ce code satisfait ces règles précises. Rien de plus. Le réflexe de l’investisseur ou de l’utilisateur averti doit donc être de regarder au-delà du badge et de poser trois questions. Quelles propriétés ont réellement été prouvées ? Qu’est-ce qui a été supposé ou déclaré hors périmètre ? Et les invariants qui comptent vraiment, absence de gain de fonds, solvabilité, contrôle d’accès, figuraient-ils bien dans la spécification ?

Le désastre de Balancer est né précisément d’un écart entre le badge et la spec : une preuve verte posée sur une spécification incomplète crée un faux sentiment de sécurité, parfois plus dangereux que l’absence de preuve, car il endort la vigilance. La discipline de lecture est la même que pour n’importe quel rapport d’audit : le badge est du marketing, la substance est dans le détail des règles et des hypothèses.

Concrètement, un lecteur exigeant traque les mentions de propriétés indéterminées, celles que le solveur n’a pas pu trancher, et il note ce que le rapport ne dit pas. Une revue qui prouve dix propriétés secondaires mais reste muette sur l’invariant central n’est pas une revue rassurante, c’est une revue à interroger. La sécurité n’est jamais un tampon ; c’est un raisonnement qu’on doit pouvoir suivre.

France : aucun régulateur ne certifie une preuve

Il faut enfin dissiper un malentendu réglementaire. Aucun régulateur, ni en France ni au niveau européen, n’accrédite les auditeurs de smart contracts ni n’impose la vérification formelle. Le règlement MiCA et le règlement DORA encadrent les prestataires de services sur crypto-actifs et leurs systèmes informatiques, pas la logique Solidity d’un protocole. Et un protocole pleinement décentralisé sort du périmètre de MiCA : il n’existe alors aucun recours de type prestataire, et l’audit ou la preuve constitue la seule garantie disponible.

Le contraste avec l’audit financier classique est saisissant. Un commissaire aux comptes engage en France une vraie responsabilité civile et pénale, sous la supervision de la Haute Autorité de l’audit (H2A), qui a succédé au H3C le 1er janvier 2024. Rien de tel n’existe pour l’ingénieur en vérification formelle qui appose son nom sur une preuve : sa seule sanction est réputationnelle, et le marché en est le juge unique. Une preuve mathématiquement valide n’est pas une garantie juridique de remboursement.

Le calendrier local ajoute une dernière strate. La période transitoire qui permettait aux anciens PSAN d’opérer sous enregistrement s’est refermée le 1er juillet 2026, l’AMF ayant rappelé que les acteurs non conformes doivent organiser une sortie ordonnée. Mais cet agrément porte sur le prestataire, sa gouvernance et sa résilience informatique, jamais sur la correction du code déployé. Entre la conformité MiCA et la sécurité on-chain, l’écart reste entier, et c’est exactement l’espace que la vérification formelle occupe, sans mandat officiel mais avec la seule promesse qui vaille encore quelque chose ici : une preuve qu’on peut vérifier soi-même.

Foire aux questions

Qu’est-ce que la vérification formelle d’un smart contract ?

C’est une technique qui produit une preuve mathématique qu’un contrat respecte une spécification donnée sur la totalité de ses exécutions possibles, et non sur un échantillon comme le fait le test. Un outil comme le Certora Prover traduit le code et les règles en contraintes logiques, puis un solveur démontre qu’aucune entrée ne viole la règle, ou en exhibe une qui la viole. La garantie est réelle, mais strictement bornée aux propriétés qu’on a pris la peine d’écrire.

La vérification formelle rend-elle un smart contract impossible à pirater ?

Non. Elle prouve que le code se conforme à sa spécification, pas que la spécification est complète. Balancer V2 était formellement vérifié par Certora et a tout de même été vidé de plus de 116 millions de dollars en novembre 2025, parce que la règle d’arrondi exploitée ne figurait dans aucune propriété prouvée. La preuve ne couvre ni la manipulation d’oracle, ni les failles économiques, ni les clés volées, ni l’infrastructure.

Qui est Certora et que fait le Certora Prover ?

Certora est une entreprise de sécurité fondée en 2018 par des spécialistes des méthodes formelles, dirigée par Mooly Sagiv et Shelly Grossman, et financée notamment par Jump Crypto. Son produit phare, le Certora Prover, vérifie formellement des smart contracts à partir de règles écrites en langage CVL et de solveurs SMT. Il est passé en open source le 24 février 2025 et couvre l’EVM, Solana et Stellar.

Quelle est la différence entre vérification formelle, audit et fuzzing ?

L’audit manuel est une relecture experte qui donne un avis, sans garantie de couverture. Le fuzzing bombarde le code d’entrées aléatoires et reste un échantillonnage, si vaste soit-il. La vérification formelle, elle, prouve une propriété sur tous les chemins et toutes les entrées, ou fournit un contre-exemple. Les trois sont complémentaires et les meilleures équipes les empilent plutôt que d’en choisir une seule.

La vérification formelle peut-elle sécuriser le code généré par IA ?

C’est le pari de Certora avec AI Composer, lancé le 21 novembre 2025, qui insère le Prover dans la boucle de génération pour confronter le code produit par un modèle à des règles de sûreté avant qu’il ne soit accepté. C’est une piste sérieuse face à des études montrant que les modèles produisent souvent du code vulnérable. Mais elle ne fonctionne que si les bonnes propriétés sont spécifiées : demander à une IA d’auditer sans erreur ne remplace pas un vrai programme de sécurité.

Par Anneke de Vries, rédactrice sécurité chez HOGE Wire.