Le co-fondateur d’Ethereum, Vitalik Buterin, place la vérification formelle assistée par intelligence artificielle au centre d’une thèse de sécurité de long terme. Le contexte : plus de 6 milliards de dollars dérobés à ce jour par les groupes nord-coréens, et 292 millions encore drainés en avril sur l’infrastructure de Kelp DAO via les RPC internes de LayerZero Labs. La question n’est plus rhétorique — trois axes techniques le démontrent.
Points clés 1. Buterin défend la vérification formelle « end-to-end » assistée par IA comme « forme finale du développement logiciel » applicable aux contrats intelligents et à la cryptographie d’Ethereum. 2. En avril, les attaquants du Lazarus Group ont drainé 292 millions de dollars depuis l’infrastructure Kelp DAO en empoisonnant les RPC internes utilisés par LayerZero Labs (Decrypt, 18 mai 2026). 3. Le cumul attribué aux hackers d’État nord-coréens dépasse 6 milliards de dollars de cryptomonnaies dérobées à date (Decrypt, 18 mai 2026). 4. La vérification formelle prouve mathématiquement qu’un code respecte une spécification — Buterin la juge décisive pour les signatures résistantes au quantique, les STARKs, les algorithmes de consensus et les ZK-EVMs. 5. L’IA est arme à double tranchant : elle découvre les vulnérabilités plus vite — elle peut aussi industrialiser la preuve défensive si la communauté l’oriente vers la vérification plutôt que vers l’exploitation.
Avril 2026 : l’attaque qui change la conversation
En avril 2026, les opérateurs nord-coréens du Lazarus Group ont vidé 292 millions de dollars de tokens depuis l’infrastructure de Kelp DAO, en empoisonnant les Remote Procedure Calls (RPC, points d’appel réseau) internes utilisés par LayerZero Labs. L’attaque ne visait pas un contrat intelligent défaillant, ni une faille connue d’un protocole de prêt. Elle exploitait la couche d’intermédiation entre le code on-chain et les opérateurs off-chain — un angle mort que la littérature de sécurité traditionnelle décrit comme une « interaction bug », bug d’interaction situé à la jonction de deux sous-systèmes pourtant audités séparément.
C’est précisément ce type d’incident qui sert de toile de fond au billet publié par Vitalik Buterin, co-fondateur d’Ethereum, et relayé le 18 mai 2026 par le média spécialisé Decrypt. Le cumul attribué aux hackers d’État nord-coréens dépasse désormais 6 milliards de dollars dérobés en cryptomonnaies à date. Aucun acteur sérieux du secteur ne peut traiter cet ordre de grandeur comme un coût acceptable de l’innovation. D’où la sortie, à la fois théorique et programmatique, de Buterin sur la vérification formelle augmentée par l’intelligence artificielle.
Thèse : la preuve mathématique, pas l’audit humain
La thèse de Buterin tient en une formule. « Si vous vérifiez formellement de bout en bout, vous prouvez non pas qu’une description du protocole est sûre en théorie, mais que le morceau de code spécifique que l’utilisateur exécute est sûr en pratique. » Autrement dit, la sécurité ne s’arrête plus à la spécification — elle descend jusqu’à l’implémentation, ligne à ligne, exécutée par l’utilisateur final. L’IA n’est pas l’oracle ; elle est l’accélérateur d’un travail mathématique trop lent pour passer à l’échelle d’un écosystème Ethereum complet.
D’où l’on vient : trente ans de vérification formelle
La vérification formelle n’est pas une nouveauté de la décennie crypto. Le champ remonte aux travaux de Tony Hoare et Edsger Dijkstra à la fin des années 1960, et trouve ses premières applications industrielles dans l’aéronautique militaire des années 1980 puis dans les processeurs Intel à la suite du bug Pentium FDIV de 1994. Coq, Isabelle, Lean, TLA+, et plus récemment K Framework forment la généalogie des assistants de preuve sur lesquels les théoriciens du logiciel critique s’appuient depuis trois décennies.
Le monde crypto s’y est intéressé tardivement, mais sans détour. La Fondation Ethereum finance depuis plusieurs cycles des projets de spécification formelle du protocole — Runtime Verification a écrit la sémantique formelle de l’EVM en K dès 2017. Les équipes derrière Tezos ont bâti une partie du protocole en OCaml pour faciliter l’analyse, et la communauté Cardano a fait du « peer-reviewed development » son argument de positionnement initial. La méthode existe, son coût aussi : vérifier formellement un module non trivial demande historiquement des centaines d’heures de travail d’un docteur en informatique théorique pour quelques milliers de lignes de code.
C’est ce ratio que l’IA générative est venue percuter. Depuis la sortie des premiers assistants de code spécialisés en preuve — Lean Copilot, Coq-LSP intégré, agents Sonnet et Opus capables de produire et de réviser des tactiques — la barre du « vérifier ce qui n’était pas vérifiable » s’abaisse. Buterin la situe assez explicitement dans son texte : la vérification formelle a longtemps été un produit de luxe ; elle pourrait devenir un produit de masse pour le code critique.
Le contexte historique se referme sur un constat brutal. Les pertes cumulées du secteur crypto liées aux hacks, exploits, rug pulls et failles de pont (« bridges ») se chiffrent par dizaines de milliards de dollars depuis 2016, avec un pic atteint sur la période 2021-2022 selon les rapports publics de Chainalysis et de PeckShield repris par CoinDesk, The Block et Reuters. À ce stade, l’audit traditionnel — quelques semaines, quelques auditeurs, un rapport — montre des limites systémiques.
Analyse technique : ce que la vérification IA change concrètement
Pour comprendre la promesse, il faut distinguer trois couches que l’industrie confond trop souvent. La couche spécification décrit ce que le système doit faire — par exemple, « un transfert ERC-20 décrémente exactement le solde de l’émetteur ». La couche implémentation est le code Solidity, Rust, ou C qui prétend réaliser cette spécification. La couche exécution est ce qui tourne effectivement sur la machine de l’utilisateur — binaire, runtime, RPC, dépendances système.
Buterin insiste sur le « end-to-end ». « Une grande partie de la valeur ajoutée vient du fait que les preuves sont véritablement de bout en bout. » Pourquoi ? « Souvent, les bugs les plus vicieux sont des bugs d’interaction qui se logent au bord de deux sous-systèmes considérés séparément. » L’attaque Kelp DAO d’avril 2026 en est une illustration manuelle.
Le tableau ci-dessous compare les trois grandes familles de garanties qu’un protocole crypto peut aujourd’hui prétendre offrir.
| Méthode | Couverture | Coût relatif | Limites |
|---|---|---|---|
| Audit humain classique | Échantillonnage de code, revue par paires | Faible à moyen | Manque les bugs d’interaction, dépend de l’auditeur |
| Tests + fuzzing | Couverture statistique d’états | Moyen | Ne prouve pas l’absence de bug, biais d’oracle |
| Spec formelle isolée | Propriétés mathématiques sur description | Élevé | Décorrélé de l’implémentation réelle |
| Vérification end-to-end assistée IA | Spec → code → exécution | Très élevé sans IA, moyen avec IA | Suppose une spec correcte et complète |
La métrique on-chain qui éclaire l’enjeu n’est pas un ratio classique de marché — MVRV-Z, NUPL, funding rates — mais un agrégat de sécurité : la valeur totale verrouillée (Total Value Locked, TVL) exposée à du code non formellement vérifié. Les tableaux de bord DefiLlama publient une TVL multi-chaînes qui se compte en dizaines de milliards de dollars, dont une fraction écrasante repose sur des contrats audités mais non prouvés formellement. C’est cette surface d’attaque que Buterin cible.
Le co-fondateur d’Ethereum applique ensuite la grille à quatre chantiers techniques de l’écosystème. « C’est particulièrement vrai pour certaines des pièces technologiques les plus diaboliquement difficiles que nous devrons déployer dans la prochaine itération majeure d’Ethereum : signatures résistantes au quantique, STARKs, algorithmes de consensus, et ZK-EVMs. » Chacun de ces blocs partage une caractéristique commune : un objectif relativement simple à énoncer mathématiquement, une implémentation extrêmement complexe à écrire correctement.
« La vérification formelle n’est pas une panacée. Mais elle est particulièrement bien adaptée aux situations où l’objectif est beaucoup plus simple que l’implémentation. »
C’est, selon Buterin, le profil exact des primitives cryptographiques modernes. La distance entre le théorème (« cette signature est inforgeable sous hypothèse de difficulté du problème X ») et le code (quelques milliers de lignes de C optimisé) est précisément l’espace où l’IA, couplée à un assistant de preuve, prend tout son sens.
Du point de vue utilisateur, Buterin pousse la logique jusqu’au bout. « Du point de vue de l’utilisateur, cela améliore considérablement la confiance sans confiance : pour faire pleinement confiance au code, vous n’avez pas besoin de relire tout le code, vous devez simplement relire les énoncés qui sont prouvés à son sujet. » La promesse est moins technique que politique : redonner à l’utilisateur final un point d’ancrage vérifiable, qui ne demande ni de lire le code ni de faire confiance à un auditeur.
Impact terrain : protocoles, développeurs, ETF infrastructure
Les conséquences se déclinent par segment d’acteur. Pour les protocoles DeFi déjà matures — Aave, Compound, Lido, Uniswap, EigenLayer — l’enjeu est rétrofit. Réécrire ou re-spécifier un protocole vivant avec des milliards en TVL pour le rendre formellement vérifiable est un chantier industriel, pas un sprint. Les équipes qui s’y attèlent — Certora sur Aave, Runtime Verification sur Ethereum, ConsenSys Diligence sur l’écosystème — facturent déjà des contrats d’audit formel à plusieurs centaines de milliers de dollars. L’IA promet de comprimer ces délais et ces coûts d’un ordre de grandeur, sans les annuler.
Pour les développeurs de nouveaux protocoles, le calcul change. Si la vérification formelle assistée par IA devient un standard de facto, partir d’une feuille blanche en Solidity sans tooling de preuve revient à publier un audit de sécurité incomplet. Buterin va plus loin dans son billet : « Si c’est fait correctement, cela a le potentiel à la fois de produire du code extrêmement efficace, et d’être beaucoup plus sûr que la manière dont la programmation a été faite jusqu’à présent. » Il qualifie cette approche de « forme finale du développement logiciel ». La formule est forte ; elle indique une direction normative, pas une prédiction de calendrier.
Pour les utilisateurs, ETF spot inclus, l’effet est indirect mais réel. Les véhicules institutionnels qui détiennent du Bitcoin et de l’Ether mandatent des prestataires de garde — Coinbase Custody, Anchorage Digital, BitGo — dont les systèmes reposent sur des piles logicielles que les comités de risque doivent auditer. Une infrastructure crypto dont les composants critiques sont formellement vérifiés réduit la prime de risque opérationnel exigée par les compliance officers, donc le coût d’entrée du capital institutionnel.
« Les bugs dans le code informatique font peur », rappelle Buterin de manière laconique. Le rappel n’est pas anecdotique : dans la finance traditionnelle, un bug se traduit par un correctif et une remédiation comptable ; sur une blockchain publique, il se traduit par une perte irréversible. C’est ce différentiel d’irréversibilité qui justifie un seuil de sécurité supérieur à celui exigé du logiciel d’entreprise classique.
Reste un effet collatéral, peu commenté. La vérification formelle assistée par IA réduit la dépendance aux auditeurs humains, ce qui redistribue la chaîne de valeur de la sécurité crypto. Les cabinets d’audit qui n’intègreront pas d’outillage de preuve assistée perdront en pertinence ; ceux qui en feront leur cœur de métier deviendront des fournisseurs d’infrastructure critique. Cas Wieland, head of research chez Glassnode, rappelle régulièrement dans ses notes que les métriques de sécurité on-chain sont, à terme, des métriques d’adoption institutionnelle.
Perspectives contradictoires : le double tranchant de l’IA
La thèse de Buterin n’élude pas le contre-argument central. L’IA n’est pas neutre dans la guerre cyber ; elle accélère aussi l’offensive. Les chercheurs en cybersécurité et plusieurs agences gouvernementales — citées dans le billet relayé par Decrypt — alertent depuis plusieurs trimestres sur le fait que les modèles d’IA avancés améliorent rapidement la capacité à découvrir et exploiter des vulnérabilités logicielles. L’asymétrie attaque/défense pourrait pencher dans n’importe quelle direction selon la vitesse relative des deux camps.
« Ce serait un avenir sombre pour la cybersécurité. C’est particulièrement un avenir extrêmement sombre pour ceux d’entre nous qui se soucient de la décentralisation et de la liberté sur internet », écrit Buterin lorsqu’il évoque le scénario d’une IA offensive qui distancerait l’IA défensive. La phrase pèse, parce qu’elle ne vient pas d’un commentateur extérieur mais d’un acteur dont la légitimité technique sur Ethereum n’est plus à établir.
Trois objections sérieuses méritent d’être posées. La première : une spécification formelle elle-même peut être incorrecte. Vérifier qu’un code respecte une spec qui ne décrit pas vraiment l’intention humaine ne protège de rien — c’est le problème classique de l’oracle. La deuxième : la vérification ne couvre pas la couche sociale et opérationnelle, où se logent les compromissions de clés, les attaques de gouvernance, les ingénieries sociales sur les multisigs. L’attaque Kelp DAO d’avril 2026 a d’ailleurs ciblé une couche RPC, pas un théorème. La troisième : l’IA générative actuelle hallucine encore sur les preuves longues, et l’usage naïf d’un assistant de code peut introduire des faux positifs de vérification — un code qui passe la vérification parce que l’outil a complaisamment ajusté la spec.
Aucune de ces objections n’invalide la direction posée par Buterin. Elles posent un cahier des charges : l’IA de vérification doit être auditable, ses preuves doivent être rejouables, et l’humain doit rester dans la boucle pour valider la pertinence des spécifications. La promesse n’est pas une boîte noire qui rendrait la crypto inviolable — c’est un outillage qui change le rapport coût/couverture.
Prospective : trois scénarios à 24 mois
Le premier scénario, et le plus probable à court terme, est celui de l’adoption sectorielle. Les protocoles critiques d’Ethereum — couche de consensus, ZK-EVMs, ponts inter-chaînes — intègrent progressivement des preuves formelles partielles, avec une accélération significative dès qu’un acteur majeur publie un framework open source mature. Les nouveaux contrats déployés sur les rollups L2 leaders incluent une couche de spec exécutable, sans que l’utilisateur final ait conscience de la mécanique sous-jacente.
Le deuxième scénario est plus nuancé. La vérification formelle assistée par IA reste cantonnée aux primitives cryptographiques — signatures, STARKs, algorithmes de consensus — précisément les chantiers cités par Buterin. La DeFi applicative, plus volatile en spécification, continue de reposer sur audit humain et bug bounties, faute de pouvoir figer une spec formelle qui suive les itérations produit. Dans ce monde, les pertes par exploit baissent sur les bridges et les primitives, restent élevées sur les applications.
Le troisième scénario est le pessimiste. L’IA offensive prend l’avantage avant que l’IA défensive ne s’industrialise, et la fenêtre 2026-2028 voit une vague d’exploits zero-day sur du code crypto non couvert par la vérification formelle. L’industrie réagit par un repli défensif — moins d’innovation, plus d’auditabilité — et la promesse d’Ethereum comme « ordinateur mondial » programmable subit un choc de confiance. Ce scénario n’est ni le plus probable ni le moins crédible ; il est mentionné parce que Buterin lui-même l’évoque comme « avenir sombre ».
La question n’est pas binaire. Elle est celle de la vitesse relative entre l’industrialisation de la preuve assistée et celle de l’exploit assisté. C’est cette course-là, et pas le prix de l’ether, qui décidera de la trajectoire de sécurité du secteur sur la décennie à venir.
FAQ
Qu’est-ce que la vérification formelle exactement ?
La vérification formelle est une technique qui utilise des preuves mathématiques pour démontrer qu’un programme respecte une spécification donnée. Au lieu de tester un échantillon de cas, on prouve que le code se comporte correctement pour tous les états possibles. Coq, Lean, Isabelle et K Framework sont les outils historiques du domaine.
Comment l’IA accélère-t-elle cette vérification ?
Les assistants d’IA aident à générer des tactiques de preuve, à proposer des invariants, à compléter des sous-buts, et à navigationner les milliers d’étapes intermédiaires qui composent une preuve complexe. Le travail reste mathématiquement rigoureux ; l’IA fait gagner du temps sur la partie laborieuse, pas sur le raisonnement central.
Cela rend-il les contrats intelligents totalement sûrs ?
Non. Buterin lui-même précise que « la vérification formelle n’est pas une panacée ». Elle protège contre les bugs d’implémentation par rapport à une spécification, mais ne couvre ni les erreurs de spécification, ni les compromissions de clés, ni les attaques sur les couches RPC ou de gouvernance. C’est une couche de défense, pas un bouclier absolu.
En quoi cela change-t-il quelque chose pour un utilisateur Ethereum ?
Selon Buterin, l’utilisateur n’aura plus à relire l’intégralité du code pour lui faire confiance : il lui suffira de relire les énoncés prouvés à son propos. À terme, cela peut réduire la dépendance aux audits externes et améliorer la « trustlessness » — la capacité d’utiliser un protocole sans avoir à faire confiance à un tiers humain.
Sources – Decrypt, Ethereum Founder Vitalik Buterin Says AI Verification Could Help Secure Crypto Networks, 18 mai 2026 — https://decrypt.co/368226/ethereum-founder-vitalik-buterin-ai-verification-secure-crypto-networks – Billet et citations originales de Vitalik Buterin relayés par Decrypt (18 mai 2026) – Incident Kelp DAO / LayerZero Labs, avril 2026 — montant 292 M$ — relayé par Decrypt – Cumul Lazarus Group : >6 Md$ de cryptomonnaies dérobées à date — relayé par Decrypt – Référentiel public DefiLlama pour la TVL multi-chaînes (consultable en open data) – Référentiel public Glassnode pour les métriques on-chain Ethereum (consultable sur abonnement)
Mohamed Meguedmi
