Rapport d’audit Trail of Bits : lire l’audit, pas le badge

Depuis dix-huit mois, la même scène se répète. Un protocole DeFi lève des fonds, déploie ses contrats, affiche sur sa page d’accueil un logo « audité par Trail of Bits », puis se fait vider quelques mois plus tard. Sur X comme sur les forums de gouvernance, la première réaction des victimes est presque toujours identique : « mais il avait été audité ». Comme si le mot suffisait à faire office de garantie.

Au premier semestre 2026, les attaquants ont emporté environ 1,32 milliard de dollars sur 344 incidents selon le décompte de CertiK, ou près de 972 millions sur 207 attaques selon TRM Labs, selon la méthode de comptage. Une part non négligeable de ces protocoles portait un badge d’audit. Le problème n’est pas que les audits ne servent à rien : c’est que presque personne ne lit le document qui se trouve derrière le badge. Un rapport Trail of Bits compte en moyenne une soixantaine de pages, et l’essentiel de sa valeur se loge dans des sections que la plupart des investisseurs n’ouvrent jamais. Ce guide explique comment lire l’un de ces rapports, section par section, et pourquoi le badge, seul, ne vous dit presque rien.

Le badge « audité » ne vaut presque rien

Commençons par le point qui dérange. L’affirmation « audité par un grand cabinet » n’est pas une preuve de sécurité, c’est une donnée de marketing. Suhail Kakar, responsable des relations développeurs chez TAC Blockchain, l’a résumé sans détour après l’un des plus gros piratages de la dernière décennie : « Balancer a subi plus de dix audits. Le vault a été audité trois fois par des cabinets différents et s’est quand même fait pirater pour 110 millions de dollars. Cet écosystème doit accepter que la mention audité par X ne veut presque rien dire. Le code est difficile, la DeFi l’est encore plus. »

Cette phrase n’est pas du cynisme. C’est une invitation à changer d’objet d’attention : cesser de regarder le logo, et commencer à lire le rapport. Un audit n’est pas un label de conformité délivré par un régulateur; c’est un compte rendu daté, à périmètre limité, d’un travail d’ingénierie mené sur une version précise du code. Sa valeur dépend entièrement de ce qu’il contient, et de ce qu’il exclut explicitement. Pour l’investisseur, le fondateur ou le simple utilisateur, savoir lire ce document est devenu une compétence de survie.

Trail of Bits, l’auteur du rapport que vous allez lire

Avant d’ouvrir un rapport, il faut savoir qui l’écrit. Trail of Bits est un cabinet de recherche et de conseil en sécurité fondé en 2012 à New York par Dan Guido et Alexander Sotirov. La maison n’a jamais levé de gros tours de capital-risque : elle se finance par ses prestations payantes et par des contrats de recherche, notamment pour la DARPA, l’agence de recherche du Pentagone. Selon les sources, elle emploie entre 125 et 140 personnes, revendique plus de 945 publications de recherche et plus de 620 rapports d’audit publics, répartis sur six domaines : sécurité applicative, cryptographie, blockchain, intelligence artificielle, systèmes et chaîne d’approvisionnement logicielle.

Dans le monde crypto, le cabinet est surtout connu pour ses outils libres : Slither, un analyseur statique pour Solidity et Vyper; Echidna, un fuzzer à base de propriétés; et Medusa, son successeur écrit en Go. Ces outils tournent en amont de chaque mission humaine. Trail of Bits a par ailleurs reconstruit une bonne partie de son processus d’audit autour de l’IA en 2026, au point de faire remonter une partie de ses bugs via des agents automatisés, toujours vérifiés par un humain avant publication. Le cabinet n’est pas seul sur ce marché : d’autres maisons comme Halborn ou CertiK occupent le terrain, et choisir un cabinet est un exercice à part entière. Mais une fois le cabinet choisi et la mission terminée, tout se joue dans la lecture du livrable. Rien ne change la règle de base : le produit final n’est pas le badge, c’est le rapport.

L’anatomie d’un rapport : huit sections, pas une note globale

Trail of Bits publie un guide public, Anatomy of a Report, qui décrit la structure standard de ses livrables. Un rapport type s’organise en huit sections. Aucune ne donne une note globale sur cent : c’est un choix délibéré. La sécurité n’est pas un score unique, mais un ensemble de constats qu’il faut pondérer soi-même. Voici ce que chaque section vous apprend réellement.

La page de garde et le niveau d’effort : le premier chiffre à lire

La page de garde ressemble à une formalité administrative. C’est en réalité la section la plus sous-estimée. Elle indique la période d’engagement, le nombre d’ingénieurs mobilisés et, surtout, le niveau d’effort exprimé en semaines-personnes. Trail of Bits le dit lui-même : c’est le chiffre le plus important pour pondérer un finding.

Le raisonnement est simple. Un rapport qui annonce zéro finding critique après deux semaines-personnes sur une base de code de 15 000 lignes ne dit pas la même chose qu’un rapport zéro critique après douze semaines-personnes sur les mêmes 15 000 lignes. Dans le premier cas, l’absence de faille grave peut simplement signifier que personne n’a eu le temps de creuser. Le niveau d’effort est le dénominateur de tout le reste : sans lui, le nombre de findings n’a pas de sens. Un protocole qui met en avant « audité, aucune faille critique » sans jamais citer le niveau d’effort vous cache, volontairement ou non, la moitié de l’information.

Ce chiffre a aussi une traduction économique directe. Le tarif d’un cabinet haut de gamme tourne autour de 25 000 dollars par ingénieur et par semaine (de l’ordre de 23 000 euros), et une mission d’entreprise classique se situe entre 80 000 et 200 000 dollars. Multiplier les semaines-personnes coûte cher; c’est précisément pour cela qu’une équipe sérieuse budgète l’effort en conséquence, et qu’un audit bon marché est souvent un audit court. Quand un projet vous dit avoir fait auditer son code, la vraie question est : combien de semaines-personnes, et sur quelle version ?

La matrice sévérité par difficulté : un medium facile bat un critical difficile

Le résumé exécutif ne classe pas les findings sur une seule échelle. Il les positionne sur deux axes : la sévérité (l’impact si la faille est exploitée) et la difficulté (l’effort nécessaire pour l’exploiter). Cette matrice change tout dans la lecture. Trail of Bits résume la logique par une formule que tout lecteur devrait garder en tête : un medium facile peut l’emporter sur un critical difficile.

Autrement dit, une faille à impact moyen mais triviale à déclencher peut représenter un risque réel plus élevé qu’une faille catastrophique qui exige un alignement de conditions quasi impossible. Un lecteur pressé qui ne compte que les critiques passe à côté de cette nuance. Le tableau ci-dessous donne une grille de lecture pratique.

Une dernière catégorie mérite votre attention : la sévérité indéterminée. Trail of Bits l’utilise quand l’exploitabilité d’un problème ne peut pas être confirmée dans la configuration examinée au moment de l’audit. C’est un drapeau jaune, pas vert. Comme on va le voir avec Balancer, une faille marquée indéterminée en 2021 peut devenir une faille à plus de cent millions de dollars trois ans plus tard, quand la configuration change.

L’évaluation de maturité : six dimensions, notées faible à robuste

La section suivante est celle qui distingue un audit sérieux d’un simple scan. Trail of Bits note la maturité de la base de code sur six dimensions d’ingénierie, sans les agréger en une note unique. Chaque dimension reçoit une appréciation qualitative (typiquement de faible à robuste), jamais un chiffre. Pourquoi est-ce plus utile qu’une note globale ? Parce qu’un projet peut avoir un code élégant et des contrôles d’accès défaillants, ou une couverture de tests exemplaire et une documentation inexistante.

• Documentation : les spécifications correspondent-elles au code déployé ?
• Tests : couverture, tests d’invariants, fuzzing.
• Contrôles d’accès : qui peut appeler quoi, et avec quels privilèges.
• Chaîne d’approvisionnement : dépendances, bibliothèques tierces, intégrité du build.
• Gestion des erreurs : comportement en cas d’échec, revert, cas limites.
• Configuration : paramètres de déploiement, valeurs par défaut dangereuses.

Un « faible » sur les contrôles d’accès pèse infiniment plus qu’un « faible » sur la documentation. Lire ces six lignes vous donne, en trente secondes, le portrait d’ingénierie d’une équipe : est-ce une maison qui teste, qui documente, qui verrouille ses accès, ou un projet monté à la hâte qui a payé un audit pour cocher une case ?

Les fiches de findings : lire le déroulé d’attaque

Le cœur du rapport, ce sont les fiches de findings. Chaque vulnérabilité reçoit un identifiant normalisé (par exemple TOB-BALANCER-004), une sévérité, une difficulté, une description technique et, surtout, un scénario d’attaque pas à pas. Ce paragraphe raconte concrètement comment un attaquant abuserait de la faille : quelle transaction, dans quel ordre, avec quel résultat. C’est la partie que même un lecteur non technique peut suivre, et c’est souvent la plus instructive.

Chaque finding se termine par deux niveaux de recommandation, et la distinction est capitale. La recommandation à court terme est le correctif que vous livrez ce sprint. La recommandation à long terme est le changement structurel qui empêche la classe entière de bugs de réapparaître. Un projet qui n’applique que les correctifs court terme rebouche des trous sans revoir l’architecture qui les a créés. C’est exactement le schéma qui a coûté cher à Bunni, on y revient.

Cette obsession du structurel remonte à la philosophie du fondateur. Dan Guido la résume ainsi dans un entretien : « Je ne veux jamais retrouver deux fois le même bug. C’est ce qui a motivé la création d’un framework d’analyse statique et d’un outil de vérification. » Un bon rapport ne se contente pas de lister des trous; il vous dit comment ne plus jamais creuser le même.

L’annexe B, la section que personne ne lit : la revue des correctifs

Si vous ne deviez lire qu’une seule annexe, ce serait la B. Elle contient la revue de correctifs : pour chaque finding, un statut indiquant s’il a été corrigé, s’il reste ouvert, ou si le client a accepté le risque. C’est ici que se cache l’écart entre un rapport et la réalité déployée. Un protocole peut brandir un rapport truffé de findings corrigés, ou passer sous silence les trois findings marqués ouverts ou risque accepté que l’annexe B révèle noir sur blanc.

Attention à un piège subtil : corrigé ne veut pas dire bien corrigé. L’annexe B atteste qu’un correctif a été soumis et revu, pas qu’il couvre tous les cas limites de la faille d’origine. Le cas Bunni en est l’illustration parfaite. Trail of Bits avait signalé le finding TOB-BUNNI-13, une absence d’approche systématique des arrondis et de l’arithmétique. Bunni a livré un correctif, mais celui-ci ne couvrait pas le cas précis exploité plus tard. Le 2 septembre 2025, une attaque par flash loan a enchaîné 44 retraits minuscules pour accumuler une erreur d’arrondi, siphonnant environ 8,4 millions de dollars entre Ethereum et Unichain. L’équipe a fermé définitivement le protocole peu après, faute de pouvoir financer un nouveau programme de sécurité. Le finding était identifié. Le correctif était insuffisant. L’annexe B, lue attentivement, aurait au moins signalé la zone à risque.

Le piège du périmètre : ce que l’audit n’a jamais regardé

Voici la section la plus importante de tout ce guide, et la plus mal comprise. Un audit ne couvre que le code qui existait le jour où il a tourné, à un commit précis. Tout ce qui a été ajouté, modifié ou déployé après cette date se trouve, par définition, hors périmètre. Le badge « audité » ne dit jamais quelle version a été auditée. Le rapport, lui, le dit toujours.

Le hack de Balancer du 3 novembre 2025, qui a coûté plus de 120 millions de dollars à travers plusieurs chaînes, en est le cas d’école. Balancer v2 avait été audité une dizaine de fois par quatre cabinets différents, dont OpenZeppelin et Trail of Bits. Et pourtant. Dans sa rétrospective, OpenZeppelin explique que son deuxième audit s’est terminé le 10 septembre 2021, sur un commit précis. Le contrat finalement exploité, le ComposableStablePool, a été ajouté au dépôt le 20 septembre 2021, soit dix jours après la fin de la mission. Le verdict d’OpenZeppelin est limpide : « De nouveaux contrats ont été ajoutés au dépôt mais ne faisaient pas partie du périmètre de notre engagement. »

Relisez cette phrase. Le contrat qui a fait perdre plus de cent millions de dollars n’avait jamais été audité, parce qu’il n’existait pas encore le jour de l’audit. Le badge affiché par les forks et les intégrateurs disait « audité par des cabinets de premier plan ». C’était vrai, et parfaitement trompeur. La leçon pratique : avant de faire confiance à un audit, vérifiez la date, le commit et le périmètre. Un rapport de juin sur un protocole qui a redéployé ses contrats en septembre ne vous protège de rien. Nous avons consacré une analyse détaillée aux leçons du hack Balancer; l’essentiel tient en une idée : un audit est une photographie, pas une assurance permanente.

Balancer et Bunni : deux échecs de nature différente

Balancer et Bunni sont souvent cités ensemble, mais ils illustrent deux défaillances distinctes qu’un lecteur de rapports doit apprendre à distinguer. Dans le cas Balancer, une faiblesse arithmétique réelle avait été repérée dès 2021 (le finding TOB-BALANCER-004), mais sa sévérité avait été marquée indéterminée parce que son exploitabilité ne pouvait pas être confirmée dans la configuration de l’époque. Les modèles de menace de 2021 et 2022 étaient dominés par le vol de clés et les défauts de contrôle d’accès, pas par les erreurs d’arrondi. La sévérité a été sous-estimée. Dans le cas Bunni, la faille avait été correctement identifiée et classée, mais le correctif livré ne couvrait pas le cas exploité. Deux problèmes opposés : d’un côté une bonne détection mal pondérée, de l’autre un bon diagnostic mal réparé.

À son honneur, Trail of Bits a publié sa propre rétrospective après Balancer, en assumant la sous-évaluation. Le cabinet en tire un cadre de défense en quatre couches, utile à tout lecteur qui veut juger la robustesse d’un protocole : documenter chaque invariant d’arrondi comme une propriété prouvable et non comme un commentaire dans le code; viser une couverture de tests complète assortie de tests de mutation; mener des campagnes de fuzzing continues avec Echidna ou Medusa; et ajouter la vérification formelle comme quatrième filet. Un protocole qui coche ces quatre cases est mesurablement plus sûr qu’un protocole qui agite un simple badge.

Cette même famille d’erreurs d’arrondi reste la plus insidieuse de 2026, parce qu’elle ne ressemble pas à une faille : juste une division qui perd quelques unités, répétée des milliers de fois. Sur les hooks d’Uniswap v4, Trail of Bits a d’ailleurs recensé sept schémas de défaillance récurrents (rappels non protégés, fuites de valeur comptable, mauvais timing de hook, sorties utilisateur bloquées, entre autres), et rappelé que Cork et Bunni ont perdu à eux deux plus de 20 millions de dollars sur des bugs de niveau applicatif, pas dans le cœur d’Uniswap. Quand un rapport consacre une fiche entière aux invariants d’arrondi, ce n’est pas du zèle : c’est le signe d’un cabinet qui a retenu la leçon.

Le contre-exemple positif existe. Pour Aave v4, un programme Security by Design doté d’un budget de 1,5 million de dollars a réuni Trail of Bits, ChainSecurity et Blackthorn sur plus de 345 jours de revue cumulés, avec une suite de tests d’invariants et un concours public de six semaines. Résultat : aucune vulnérabilité critique ou élevée. Voilà à quoi ressemble un effort de sécurité sérieux, et c’est exactement le genre d’information qu’un badge n’affiche jamais mais qu’un rapport détaille.

Vérifier qu’un rapport correspond au code déployé

Un rapport authentique et bien lu ne sert à rien si le code déployé n’est pas celui qui a été audité. La vérification tient en trois gestes. D’abord, retrouver le rapport à sa source : Trail of Bits publie son catalogue sur trailofbits.com/reports et les PDF bruts sur son dépôt GitHub public. Un rapport qui n’existe que sous forme de capture d’écran sur le site du projet mérite la méfiance.

Ensuite, comparer le commit audité au code réellement déployé. Le rapport cite un hash de commit; un explorateur de blocs permet de vérifier que le bytecode en production correspond bien à cette version. Enfin, croiser les sources. L’agrégateur Solodit, édité par Cyfrin, rassemble des dizaines de milliers de findings issus de Trail of Bits, OpenZeppelin, Code4rena, Sherlock et d’autres, ce qui permet de voir si une même classe de bug a déjà touché des protocoles comparables. DeFiSafety propose de son côté un score de qualité de processus indépendant, sur une échelle de zéro à cent, qui évalue la démarche et pas seulement la présence d’un audit.

Ce qu’un rapport ne promet jamais

Même parfaitement lu, un rapport d’audit a des angles morts structurels. Il examine du code. Or une grande partie des pertes de 2026 n’a rien à voir avec du code défectueux. Au premier semestre, la compromission de portefeuilles a été le vecteur le plus coûteux, avec environ 444 millions de dollars dérobés sur seulement 33 incidents selon les chiffres de CertiK relayés par Forbes. Vol de clés privées, signatures aveugles, employés piégés par ingénierie sociale : aucun audit de smart contract ne couvre ces scénarios.

Alexander Urbelis, directeur de la sécurité chez ENS Labs, le formule bien : « Les bugs qui vident les trésoreries tournent souvent autour de l’intention et des incitations adverses », deux choses qu’un analyseur statique ne mesure pas. Un audit ne dira rien non plus d’une attaque de gouvernance, d’une manipulation d’oracle, d’une clé multisig mal gérée ou d’une mise à jour malveillante déployée après coup. Nous avons montré ailleurs que multiplier les signataires d’un multisig ne le rend pas plus sûr, et que le risque se déplace souvent vers la frontière entre le on-chain et le hors-chaîne.

Il y a enfin le mirage de l’IA. David Schwed, directeur des opérations chez SVRN, résume la dérive du moment : « Claude, audite mon smart contract, ne fais aucune erreur n’est pas un programme de sécurité ». Les outils, y compris les meilleurs modèles, produisent des sorties qu’il faut savoir interpréter. Le rapport reste un document écrit par des humains pour des humains, et sa lecture ne se délègue pas. Et si le pire arrive malgré tout, l’audit n’est pas une police d’assurance : la question de qui rembourse après un hack relève d’un tout autre dispositif (bug bounty, assurance on-chain, fonds de secours) que le rapport ne garantit en rien.

Ni l’AMF ni MiCA n’imposent d’auditer votre code

Un dernier point, souvent ignoré des lecteurs français : aucun régulateur n’impose ni n’accrédite l’audit de smart contracts. Ni l’Autorité des marchés financiers (AMF), ni le règlement européen MiCA, ni DORA ne rendent obligatoire une revue de code avant déploiement. MiCA encadre les prestataires de services sur crypto-actifs (le régime PSAN sous supervision de l’AMF, dont la période transitoire française s’est achevée le 1er juillet 2026), avec un régime de responsabilité à l’article 75 et des exigences de résilience opérationnelle via DORA. Mais rien de tout cela ne parle du code des protocoles eux-mêmes.

La conséquence est structurante. La qualité d’un audit n’est policée que par la réputation, jamais par un équivalent du commissariat aux comptes de la finance traditionnelle. Il n’existe pas de gendarme de la Solidity. Et pour les protocoles entièrement décentralisés, qui échappent au périmètre de MiCA, il n’y a tout simplement aucun recours réglementaire, quelle que soit la qualité (ou l’absence) d’audit. Dans ce vide, savoir lire un rapport n’est pas un luxe d’expert : c’est la seule diligence que l’utilisateur puisse exercer lui-même.

La méthode : lire un rapport en dix minutes

Résumons en une routine applicable à n’importe quel rapport, en moins de dix minutes.

1. La page de garde. Notez la date, le commit et le niveau d’effort en semaines-personnes. Peu d’effort, peu de confiance.
2. Le périmètre. Vérifiez quelle version a été auditée et comparez-la au code déployé. Tout ce qui a bougé après est hors couverture.
3. La matrice sévérité par difficulté. Ne comptez pas les critiques; repérez les medium faciles et les indéterminés.
4. La maturité du code. Cherchez les faibles sur les contrôles d’accès et les tests, pas sur la documentation.
5. L’annexe B. Lisez les statuts. Ouvert et risque accepté valent tous les communiqués rassurants.
6. La source. Récupérez le rapport chez l’auteur, pas sur le site du projet, et vérifiez le hash on-chain.

Cette routine ne fait pas de vous un auditeur. Elle fait de vous un lecteur averti, capable de distinguer un protocole qui a payé pour la sécurité d’un protocole qui a payé pour un logo. Dans un marché où le badge « audité » se colle sur n’importe quelle page d’accueil, c’est déjà une avance décisive. Le rapport existe. Il suffit de l’ouvrir.

Foire aux questions

Trail of Bits est-il fiable si un protocole qu’il a audité se fait quand même pirater ?

Un audit n’est pas une garantie : il photographie un code à une date et un périmètre précis. Les cas Balancer et Bunni montrent qu’une faille peut être sous-estimée, mal corrigée ou concerner du code ajouté après l’audit. La fiabilité d’un cabinet se juge à la qualité et à la transparence de ses rapports, pas à l’absence totale d’incidents chez ses clients.

Où trouver un vrai rapport d’audit Trail of Bits ?

Sur le catalogue officiel trailofbits.com/reports et sur le dépôt GitHub public trailofbits/publications, qui hébergent plus de 620 rapports. Méfiez-vous d’un rapport qui n’existe que sous forme d’image sur le site d’un projet : récupérez la source et vérifiez que le commit audité correspond au code déployé.

Que signifie le niveau d’effort dans un rapport d’audit ?

C’est le temps de travail investi, exprimé en semaines-personnes, affiché sur la page de garde. Trail of Bits le décrit comme le chiffre le plus important pour pondérer un finding : zéro faille critique après deux semaines-personnes ne vaut pas zéro faille critique après douze. Sans niveau d’effort, le nombre de findings n’a pas de sens.

L’AMF ou MiCA obligent-ils à faire auditer un smart contract ?

Non. Ni l’AMF, ni MiCA, ni DORA n’imposent ou n’accréditent l’audit de code. MiCA encadre les prestataires de services sur crypto-actifs, avec un régime de responsabilité à l’article 75, mais ne dit rien du code des protocoles. Pour les protocoles entièrement décentralisés, il n’existe aucun recours réglementaire.

Un audit protège-t-il contre le vol de clés ou le phishing ?

Non. Un audit examine du code. Il ne couvre ni le vol de clés privées, ni les signatures aveugles, ni l’ingénierie sociale, ni les attaques de gouvernance, ni la manipulation d’oracle. Au premier semestre 2026, la compromission de portefeuilles a été le vecteur le plus coûteux, loin devant les bugs de contrat, ce qu’aucun rapport ne peut empêcher.

Par la rédaction de HOGE Wire.