Vérification formelle vs audits : pourquoi « nous avons vérifié le code

Je dormais profondément après les audits. Je ne le fais plus. La première fois que j’ai vu un protocole post-audit perdre 30 millions de dollars à cause d’une interaction avec l’État que les auditeurs avaient manquée, je me suis dit qu’il s’agissait d’un cas limite. La deuxième fois, j'ai blâmé la portée. La troisième fois – vers la cinquième autopsie que j’avais lue cette semaine-là – j’ai réalisé que le problème ne venait pas des auditeurs. C'était la méthodologie. Les audits sont des êtres humains qui lisent du code et écrivent des tests. Les humains manquent des choses. Les tests manquent des chemins. Et dans un contrat intelligent gérant du capital réel, « nous avons probablement tout obtenu » n’est pas un modèle de sécurité. C'est un souhait. Table des matières La tendance est devenue sinistrement prévisible. Un protocole lève des capitaux, commande un audit auprès d'un cabinet respecté, reçoit un rapport, corrige les problèmes signalés, se déploie et annonce « audité » à sa communauté. Des mois plus tard, parfois des semaines, l’argent a disparu. Team Finance a perdu 14,5 millions de dollars en octobre 2022. Deux cabinets d'audit distincts avaient examiné la base de code. L'un d'entre eux avait signalé la fonction de migration vulnérable. Le contrat a quand même été exploité. Le 18 avril 2026, le pont alimenté par LayerZero de Kelp DAO a été vidé de 116 500 rsETH, soit environ 292 millions de dollars et environ 18 % de l'offre totale du jeton en circulation. C’est devenu le plus grand exploit DeFi de 2026. La conclusion post-mortem : aucun contrat intelligent n’a été rompu. Aucune primitive cryptographique n'a été compromise. Les contrats ont été exécutés exactement comme écrit. L'échec résidait dans l'infrastructure du vérificateur hors chaîne – une configuration DVN unique qui permettait à un attaquant de forger un message inter-chaîne. Le rapport d’audit n’aurait pas pu détecter cela car il n’y avait rien de mal avec le code des contrats. En 2025, les pertes totales sur le Web3 ont atteint 3,375 milliards de dollars suite à 313 incidents de sécurité majeurs. Lorsqu’un audit devient une case à cocher – une chose qu’un projet fait pour signaler la diligence plutôt qu’un processus qui réduit de manière significative les risques – l’industrie est confrontée à un problème structurel. Et c’est le cas. Permettez-moi d'être précis sur ce qu'apporte un audit de contrat intelligent, car l'industrie a tendance à passer sous silence cela. Un audit implique qu'une équipe de chercheurs en sécurité lise votre code, exécute des analyseurs statiques, rédige des cas de test personnalisés et documente ce qu'ils trouvent. Les meilleures entreprises détectent les vulnérabilités de réentrée, les dépassements d’entiers, les problèmes de contrôle d’accès, les erreurs logiques et les cas économiques dangereux. Leurs rapports sont détaillés et véritablement précieux. Mais un audit est limité par l’attention humaine et par l’ensemble des scénarios envisagés par les auditeurs. Aucun audit n’explore de manière exhaustive toutes les voies d’exécution possibles à travers un contrat. L’espace d’état d’un contrat intelligent non trivial – toutes les combinaisons possibles d’entrées, d’états de stockage, de contextes d’appelant et de séquences d’exécution – est trop vaste pour qu’un humain ou un fuzzer puisse le couvrir de manière exhaustive. Le fuzzing détecte environ 80 % des problèmes grâce à la génération d'entrées aléatoires. Les 20 % restants se cachent dans des cas mathématiques extrêmes que les entrées aléatoires n’atteignent jamais. Un auditeur testant un scénario de premier dépôt pourrait ne jamais construire l'état exact où totalSupply est 1 et totalAssets est type(uint256).max, créant ainsi une attaque d'inflation. Un audit répond : « Avons-nous trouvé des bugs ? Il ne répond pas, et ne peut structurellement pas répondre : « Aucun bug n’existe ». Il ne s’agit pas d’une critique des auditeurs. C'est une limitation mathématique de la méthode. La vérification formelle est une catégorie d’assurance fondamentalement différente. Au lieu de demander aux humains de lire le code et de rechercher les problèmes, la vérification formelle traduit les contrats intelligents en spécifications mathématiques, puis utilise un prouveur automatisé pour rechercher de manière exhaustive tout chemin d'exécution qui viole ces spécifications. Le prouveur ne se lasse pas. Il ne manque pas les cas extrêmes parce qu’il a manqué de temps. Il ne manque pas d’envisager un scénario car il paraissait improbable. Il explore systématiquement l’ensemble de l’espace d’état défini par la spécification. Si le prouveur constate une violation – une transition d’état qui, selon la spécification, devrait être impossible mais que le code l’autorise – le contrat échoue à la vérification. L'équipe le corrige et vérifie à nouveau. Si le prouveur ne constate aucune violation, il a produit une preuve mathématique. Pas une probabilité. Pas un niveau de confiance élevé. Une preuve qu'à l'intérieur des propriétés spécifiées, le code ne peut pas se comporter d'une manière quelconque. La phrase clé : dans les propriétés spécifiées. La vérification formelle prouve ce que vous spécifiez. Si vous spécifiez les mauvaises choses ou si vous omettez de spécifier une propriété importante, la preuve ne la couvre pas. C'est pourquoi l'écriture de spécifications précises – les invariants, les règles de transition d'état, les propriétés de contrôle d'accès – est aussi importante que l'exécution du prouveur. L’argument le plus fort en faveur de la vérification formelle n’est pas théorique. Ce sont les bogues concrets que le code d’expédition – examiné par plusieurs experts humains – contenait encore. Le DAI de MakerDAO, l'une des bases de code les plus scrutées de DeFi, contenait une violation de son propre invariant de base depuis son premier lancement en novembre 2019 jusqu'en mai 2022. Il s'agissait d'une erreur mathématique dans le compte rendu fondamental du protocole.