Balancer tient sur GitHub la liste de ses audits, et au-dessus du tableau figure un avertissement : « Les audits ne garantissent pas l’exactitude du code. Certains contrats ont été modifiés après leur audit. » (page des audits de Balancer, en anglais). Le 3 novembre 2025, ses pools stables V2 ont pourtant été vidés, pour plus de 120 millions de dollars selon le décompte d’OpenZeppelin, en anglais, qui inclut les forks du code. Les rapports étaient publics depuis des années, et lus avec attention, ils disaient ce que leurs auteurs n’avaient pas regardé.
Dix minutes suffisent pour retrouver cette information soi-même dans un audit blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract, à condition de savoir où chercher : le commit, le périmètre, les constats, leur statut, et l’écart entre le code audité et le code qui tourne aujourd’hui. L’exemple détaillé repose sur deux rapports réels portant sur le même code d’Aave V3. pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il est suivi d’un exercice de traçage du contrat Aave en production jusqu’à ses audits, puis de cas où un audit n’a pas empêché une perte. Les citations de rapports et de pages en anglais sont traduites ici, et les sources concernées sont signalées « en anglais ».
Un smart contract ne se corrige pas aussi facilement qu’un site web, et il détient de l’argent dès sa première minute. C’est la raison pour laquelle les protocoles paient des relectures externes. La leçon précédente, sur la MEV et la protection d’une transaction, a montré qu’un contrat qui fonctionne comme prévu peut tout de même coûter de l’argent à son utilisateur. L’audit traite un autre problème : un code qui ne fait pas ce que ses auteurs voulaient.
Un audit de smart contract : une relecture limitée dans le temps, sur une version du code
Oubliez le mot « certifié ». Un audit, c’est une quantité fixe de temps d’experts consacrée à un instantané du code. Trail of Bits a passé 12 semaines-personnes sur Aave V3, avec trois ingénieurs, du 25 octobre au 24 novembre 2021, à partir du commit 14f6148 (rapport de Trail of Bits, en anglais). OpenZeppelin indique que trois de ses auditeurs ont travaillé sur le même commit pendant sept semaines (rapport d’OpenZeppelin, en anglais). Quand le temps imparti est écoulé, la relecture s’arrête, que tous les bogues aient été trouvés ou non.
Le commit est la partie que la plupart des lecteurs sautent. Un hash de commit est l’empreinte d’un état précis du code dans le dépôt. Si une seule ligne change, l’empreinte change, et à strictement parler l’audit ne décrit plus ce code.
Le client paie et le rapport lui est adressé, ce qui oriente la lecture. Les constats sont réels et le cabinet les signe, mais le périmètre a été fixé avec l’équipe qui règle la facture, et c’est elle qui choisit de publier ou non, et quand. Aucun des rapports utilisés ici n’indique de prix : le chiffre lisible est l’effort fourni, et les semaines-personnes en disent plus qu’un logo.
Trois types de documents circulent. Un audit manuel est rédigé par une équipe nommée de relecteurs. Un rapport de vérification formelle confronte le code à des règles mathématiques. Un rapport de concours rassemble ce que de nombreux chercheurs en compétition ont soumis et que des juges ont validé. Chacun a ses limites, présentées plus bas. Les bogues de contrat ne sont qu’une famille parmi celles que recense notre cartographie des risques de la DeFi : un audit ne dit rien de la plupart des autres.
Anatomie d’un audit smart contract, étape par étape
Étape 1 : la couverture et le tableau de bord
Tout rapport d’audit de smart contract s’ouvre sur les éléments qui l’identifient. Relevez quatre choses sur les premières pages : la date, le dépôt, le hash du commit et les dates de la mission. Les rapports de Trail of Bits ajoutent un tableau de bord avec l’effort et le nombre de constats par gravité. Regardez aussi l’historique des versions. Le rapport sur Aave porte deux dates, un rapport initial du 29 novembre 2021 et un journal de correctifs ajouté le 21 janvier 2022, ce qui indique que le cabinet est revenu vérifier.
Un rapport sans hash de commit est presque inutilisable pour vous, puisque vous ne pouvez pas savoir ce qu’il décrit.
Étape 2 : le périmètre et ce qui a été laissé de côté
Passez ensuite à la section intitulée périmètre (scope), ou « limites de couverture », et lisez-la lentement. C’est là que le cabinet se protège, et c’est là qu’il vous renseigne. Le rapport d’OpenZeppelin sur Aave déclare : « Nous supposons que tous les oracles de prix fonctionnent comme prévu, car ils sont hors du périmètre de cet audit. » L’affirmation est honnête, et elle porte sur beaucoup de choses, car l’oracle est une voie fréquente vers une perte (notre leçon sur la conception et la manipulation des oracles explique pourquoi).
En 2022, Trail of Bits a été tout aussi clair sur le Composable Stable Pool de Balancer (rapport, en anglais). Le cabinet écrit qu’il n’a « pas cherché d’occasions de mener des attaques économiques de haut niveau » et qu’il n’a pas couvert les bibliothèques StableMath et WordCodec, « explicitement marquées comme hors périmètre ». Ces lignes comptent pour la suite.
Étape 3 : le tableau des constats
Vient le résumé : un tableau de constats avec la gravité et, dans la version finale, le statut. Comptez les constats élevés et critiques, puis passez directement à leur statut. Une longue liste de remarques informatives est souvent le signe d’un relecteur minutieux, pas d’un mauvais code : le total brut dit donc peu de chose.
Étape 4 : les échelles de gravité diffèrent d’un cabinet à l’autre
Il n’existe pas d’échelle commune. Chaque cabinet définit ses propres termes, le plus souvent dans une annexe. Ce qui est « High » chez l’un peut être « Critical » chez l’autre, comme le montre l’exemple d’Aave plus bas. Les libellés de gravité restent ici dans leur forme d’origine, car ce sont ceux que vous trouverez dans les rapports.
| Qui | Niveaux | Définition du niveau le plus haut | Source (lue le 1er novembre 2026) |
|---|---|---|---|
| Trail of Bits | Informational, Undetermined, Low, Medium, High, plus une note de difficulté distincte | High : le problème peut toucher de nombreux utilisateurs, avec de graves conséquences en termes de réputation, de droit ou de finances pour le client | Rapport Aave V3, annexe A, 2021 |
| OpenZeppelin | Critical, High, Medium, Low, Notes | Intitulés seuls dans le rapport Aave : aucune définition imprimée | Rapport Aave V3, 2021 |
| Sherlock (concours et jugement des audits) | High, Medium | High : « perte directe de fonds sans limitation (importante) liée à des conditions externes » | Règles de jugement, en anglais |
| Programmes de bug bounty | Fixés par programme | Lire le tableau de gravité de la page du programme | Page de chaque programme |
La difficulté, elle, est notée à part chez Trail of Bits. Un constat High avec une difficulté Low est une plus mauvaise nouvelle qu’un High qui exige un enchaînement de conditions rares. Et méfiez-vous de « Undetermined » : selon la définition du cabinet, cela signifie que l’étendue du risque n’a pas été déterminée pendant la mission. C’est une question laissée ouverte, pas un constat bénin.
Étape 5 : les mots du statut
La gravité dit à quel point un problème était sérieux. Le statut dit ce qu’il est devenu. Le vocabulaire varie, mais voici les mots que vous rencontrerez :
- Fixed signifie que l’équipe a modifié le code, et le rapport renvoie en général vers la pull request. Vérifiez si l’auditeur a relu le correctif.
- Partially fixed signifie qu’une partie du problème demeure. Lisez laquelle.
- Acknowledged signifie que l’équipe a pris connaissance du constat. Cela n’indique aucune modification du code.
- Risk accepted by client signifie que l’équipe a décidé de vivre avec le problème, souvent en donnant ses raisons par écrit.
- Not fixed veut dire ce que ça dit, et il faut chercher la raison.
- Intended behaviour signifie que l’équipe conteste qu’il s’agisse d’un bogue.
« Acknowledged » est le mot qui piège les lecteurs. Dans le rapport d’OpenZeppelin sur Aave, le constat H03 signale que le protocole frappe des aTokens à hauteur du montant demandé sans vérifier ce qu’il a reçu, ce qui pose problème pour tout jeton qui prélève des frais sur les transferts. Son statut est Acknowledged, et la raison de l’équipe Aave est citée : « C’est un choix de conception de ne prévoir aucune implémentation pour gérer les comportements non standard dans le code par défaut ». Le choix peut se défendre. C’est pourtant une propriété bien réelle du code, et vous la connaissez désormais.
Étape 6 : le journal de correctifs et la seconde relecture
Un constat que l’équipe déclare corrigé reste une affirmation, et un correctif relu par l’auditeur est plus solide. Le journal de correctifs de Trail of Bits décrit la propre relecture des corrections par le cabinet après l’évaluation. La conclusion d’OpenZeppelin sur Aave ajoute : « nous recommandons toujours de soumettre le code à un nouveau tour d’audit une fois tous les correctifs appliqués ». Un correctif est du code neuf, et du code neuf peut contenir de nouveaux bogues.
Exemple détaillé : deux cabinets, un seul commit d’Aave
Aave V3 est un bon cas d’école, car deux cabinets ont audité le même commit et publié le même type de document. Aave sert ici d’exemple pédagogique : le protocole n’a pas été piraté dans les cas évoqués plus loin.
| Rapport sur le commit 14f6148 | Effort | Critical | High | Medium | Low | Informational ou notes | Total |
|---|---|---|---|---|---|---|---|
| Trail of Bits, 29 novembre 2021 (journal de correctifs du 21 janvier 2022) | 12 semaines-personnes, 3 ingénieurs | n/a | 5 | 1 | 2 | 7 | 15 |
| OpenZeppelin (fichier daté du 1er novembre 2021 dans le dépôt) | 3 auditeurs, 7 semaines | 2 | 3 | 1 | 7 | 14 | 27 |
Le journal de correctifs de Trail of Bits boucle la boucle : 11 constats corrigés, 4 risques acceptés par le client, tous les quatre classés Informational. Les statuts d’OpenZeppelin sont écrits constat par constat, et il faut donc lire chaque ligne « Update ».
Un bogue expliqué simplement
Aave permet à un utilisateur d’emprunter grâce à un crédit délégué par un autre. Le constat TOB-AAVE-007 de Trail of Bits indique que la fonction d’emprunt « récupère à tort la catégorie eMode de msg.sender au lieu de celle de onBehalfOf ». Autrement dit, le code consultait les réglages de la personne qui appelle la fonction, pas ceux de la personne dont la garantie soutient le prêt.
Le rapport donne des chiffres. Supposons que le DAI ait un ratio prêt/valeur de 80 % et un seuil de liquidation de 85 %, alors que l’eMode des stablecoins (un réglage à haute efficacité pour les actifs corrélés) autorise 97 % et 98 %. Alice, sans eMode, délègue du crédit adossé à ses 100 DAI à Eve, qui a activé l’eMode. Eve emprunte 97 USDC. Alice peut désormais être liquidée, parce qu’un prêt dimensionné pour la règle des 97 % repose sur une position soumise à celle des 85 %. La gravité est High, et la difficulté Low.
Le constat C02 d’OpenZeppelin, « la catégorie eMode est ignorée lors des emprunts », décrit le même défaut, et les rapports permettent de le démontrer. Les deux renvoient au même correctif, la pull request 204 d’aave-v3-core, qui change un seul argument dans Pool.sol, de _usersEModeCategory[msg.sender] à _usersEModeCategory[onBehalfOf]. Trail of Bits classe le bogue High. OpenZeppelin le classe Critical. C’est le meilleur argument contre la comparaison des totaux de gravité d’un cabinet à l’autre.
Ce que deux audits apportent
Les rapports se recoupent et se distinguent. Tous deux signalent une dette en mode d’isolation mal mise à jour (constat 11 chez Trail of Bits, H01 chez OpenZeppelin). OpenZeppelin relève aussi C01, sur la création de jetons de dette avec l’état du mauvais utilisateur. Côté Trail of Bits, le constat 2 est l’absence de contrôle de l’identifiant de chaîne, qui permettrait de rejouer des signatures d’un fork à l’autre, classé High et corrigé. Deux équipes distinctes sur un même commit ont trouvé des choses communes et des choses propres à chacune : c’est l’argument pour payer deux fois.
À quoi ressemble un « risque accepté » dans la pratique
Lisez les justifications, car elles montrent comment une équipe raisonne. Sur les optimisations du compilateur (constat 1), l’équipe d’Aave a répondu que les bénéfices l’emportent sur les risques et que sa communauté surveillerait le compilateur. Sur une interface Chainlink obsolète (constat 13), le rapport note que l’interface recommandée coûte plus de gaz et que le changement a été laissé à la communauté Aave. On peut être d’accord ou non. L’essentiel est de pouvoir lire la décision et de la dater.
Périmètre audité et code déployé
Un rapport décrit un commit. Votre argent se trouve dans un contrat, à une adresse. L’écart entre les deux porte un nom, utilisé par le cabinet de sécurité Zellic : l’audit drift, ou dérive d’audit, en anglais. Combler cet écart est la compétence la plus utile de cette leçon, et n’importe qui peut le faire avec un explorateur de blocs.
Remonter du Pool Aave en production jusqu’à ses audits
Voici la marche à suivre, avec les résultats relevés le 1er novembre 2026.
- Prenez l’adresse dans la documentation ou le carnet d’adresses du projet, jamais dans une publicité de moteur de recherche ni dans une publication sur les réseaux sociaux. Pour Aave, le carnet d’adresses donne le Pool Ethereum : 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2.
- Ouvrez cette adresse sur Etherscan et allez dans l’onglet Contract. Cherchez la mention « verified ». La page affiche un code source vérifié avec correspondance exacte, et le contrat est un proxy.
- Repérez l’implémentation. Un proxy détient les fonds et transmet les appels à une logique stockée ailleurs, à un emplacement normalisé par ERC-1967. Etherscan l’affiche directement : 0x728a138A4823392C2EFA55e028d434F526fE03CF, nommée PoolInstance, elle aussi vérifiée. Une lecture directe de l’emplacement de stockage renvoie la même adresse.
- Identifiez la version. Dans « Read as Proxy », la fonction POOL_REVISION renvoie 11.
- Retrouvez cette version dans le dépôt. Le tag v3.7.0 fixe POOL_REVISION à 11 : le numéro de révision correspond donc à cette version.
- Listez les audits de cette version, pas ceux du protocole en général. Le dossier des audits contient six rapports sur la v3.7, datés du 26 au 31 mars 2026 : MixBytes, Sherlock, Pashov, Certora, Savant et Enigma.
- Ouvrez ces rapports et comparez leur commit avec le tag. GitHub date la version v3.7.0 du 5 août 2026, des mois après les rapports. Un écart de dates n’est pas une faute en soi. C’est le signal qu’il faut vérifier quel commit chaque cabinet a relu et ce qui a changé ensuite.
Voyez maintenant ce que vaut le premier audit dans ce cas. Les rapports de 2021 étudiés plus haut décrivent un code antérieur de nombreuses versions au Pool actuel. Un protocole qui cite son premier audit vous parle du passé. Comptez les audits par version, pas au total : le dossier d’Aave contient 49 fichiers au 1er novembre 2026, soit 47 rapports une fois mis de côté deux documents présents à la fois en PDF et en Markdown. Ils s’étalent sur plus de quatre ans et sur de nombreuses versions, et quelques-uns portent sur des contrats annexes plutôt que sur le Pool.
Un numéro de révision est un indice solide, pas une preuve. Pour la preuve, un développeur compile le code du tag et compare le résultat au bytecode en chaîne. Et la mention « verified » d’Etherscan ne prouve qu’une seule chose précise : que le code source publié se compile en bytecode identique à celui qui est déployé. Comme le dit la page elle-même, « la vérification du code source n’implique pas que le contrat soit sans danger à utiliser ».
Mises à niveau et clés d’administration
Les contrats évolutifs ajoutent un second écart. Celui qui contrôle le proxy peut remplacer l’implémentation, et le nouveau code n’a aucun audit tant que personne n’en commande un. Demandez donc qui détient ce pouvoir : une clé unique, un multisig, ou un vote de gouvernance assorti d’un délai. Un proxy ERC-1967 émet un événement Upgraded à chaque changement, et le journal d’événements du contrat montre donc la fréquence d’usage de ce pouvoir. Un contrat modifié la semaine dernière et un audit de l’an dernier ne décrivent pas la même chose.
Ce qui reste d’ordinaire hors du périmètre
Attendez-vous à trouver hors périmètre, sauf mention contraire du rapport : les oracles de prix, les composants tiers comme les rate providers, les contrats de base partagés, le site sur lequel vous cliquez réellement, les clés des opérateurs et les autres protocoles branchés plus tard. Trail of Bits note dans son rapport Balancer de 2022 qu’il n’a couvert que partiellement des composants de base comme BasePool.
Plusieurs audits : les couches d’assurance
Les équipes sérieuses empilent les méthodes, car chacune attrape des choses différentes. Uniswap v4 en est l’exemple classique : son équipe a annoncé, en anglais le 26 novembre 2024 neuf audits indépendants, avec six cabinets nommés, puis un concours de sécurité doté de 2,35 millions de dollars et suivi par plus de 500 chercheurs, au terme duquel « aucune vulnérabilité critique n’a été trouvée », et enfin un bug bounty de 15,5 millions de dollars sur la plateforme Cantina.
Vérification formelle : la preuve des règles que quelqu’un a écrites
Des outils comme le Certora Prover vérifient le code par rapport à des règles écrites dans tous les états possibles, là où un test n’en essaie que quelques-uns. C’est une méthode plus forte et plus étroite. Le résultat ne vaut que pour les règles écrites et le modèle utilisé. Le rapport de Certora sur Balancer le dit lui-même : « les garanties du Certora Prover sont limitées à la spécification fournie » (rapport de 2022, en anglais). Pour que le problème reste soluble, ce même travail a remplacé la bibliothèque StableMath par un substitut renvoyant des « valeurs arbitraires, mais cohérentes », et réglé _upscaleArray() et les fonctions voisines pour qu’elles renvoient des valeurs non déterministes. Quand vous lisez un tel rapport, allez aux hypothèses et à la liste des fonctions simplifiées avant la liste des règles prouvées.
Concours : beaucoup d’yeux, et un marché qui a bougé
Dans un concours, un sponsor publie du code et une cagnotte, des chercheurs rivalisent pendant une durée limitée, et des juges décident de ce qui est valide et de sa gravité. Vous obtenez de la largeur de couverture pour une période donnée. Les règles de Sherlock définissent un High comme une perte directe de fonds sans fortes limitations liées à des conditions externes, et un Medium comme une perte qui exige certaines conditions ou qui reste très contrainte.
Ce marché a changé. Code4rena, le nom le plus associé à ce format, a annoncé le 13 mai 2026, en anglais qu’il mettait fin à son activité, Immunefi devant reprendre ses clients de bug bounty. Son site affiche toujours son bilan au 1er novembre 2026 : 512 audits et 1 607 vulnérabilités de haute gravité uniques. Ses rapports passés restent utiles. La documentation de Sherlock met désormais en avant les audits collaboratifs, un « Audit Engine » qui associe IA et chercheurs humains, et les bug bounties. Quand un projet cite un concours, vérifiez donc la plateforme, la date et le rapport final.
Bug bounties : l’audit qui ne s’arrête jamais
Un bug bounty rémunère des tiers pour les bogues trouvés dans du code en production, ce qui couvre la période après le départ des auditeurs. L’étude d’Immunefi, en anglais sur 593 programmes, publiée le 20 avril 2026 et couvrant de janvier 2021 à février 2026, donne les chiffres ci-dessous. Immunefi vend ce service et les données ne couvrent que ses propres programmes : il faut les lire comme une étude de fournisseur.
| Ancienneté du programme | Part des programmes ayant eu au moins un bogue critique confirmé et payé |
|---|---|
| 1 an ou plus | 61,4 % |
| 2 ans ou plus | 73,9 % |
| 3 ans ou plus | 87,2 % |
| 4 ans ou plus | 92,9 % |
| 5 ans ou plus | 93,9 % |
Lisez ces chiffres face à toute mention « entièrement audité » : plus un programme dure, plus il a de chances de révéler un bogue critique. La même étude place la prime critique médiane à 20 000 dollars et la moyenne à 114 355 dollars, avec 107,3 millions de dollars versés pour des bogues critiques. Le maximum affiché sur la page d’un programme est un plafond, pas un paiement. Le paiement le plus connu est celui de Wormhole, en anglais, un record à l’époque : 10 millions de dollars à un chercheur connu sous le nom de satya0x, qui avait signalé le 24 février 2022 une implémentation de proxy non initialisée. Le correctif a été appliqué le jour même, et aucun fonds d’utilisateur n’a été perdu, selon Immunefi. Plus tôt ce mois-là, le pont avait subi une attaque que The Block, en anglais chiffrait à près de 323 millions de dollars ; l’avis du FBI cité plus bas parle d’environ 320 millions.
| Couche | Ce qu’elle fait | Ce qu’elle ne peut pas faire |
|---|---|---|
| Audit manuel | Des experts raisonnent sur un commit pendant une durée fixe | Couvrir les changements ultérieurs ou ce qui est hors périmètre |
| Vérification formelle | Prouve des règles écrites dans tous les états modélisés | Contrôler des règles que personne n’a écrites, ou des parties simplifiées |
| Concours | De nombreux relecteurs rivalisent sur une période limitée | Couvrir les changements ultérieurs ; la qualité varie selon la cagnotte et la date |
| Bug bounty | Rémunère les bogues du code en production, sans date de fin | Arrêter un attaquant qui préfère exploiter plutôt que signaler |
| Surveillance et exploitation | Observe les contrats et les clés en production | Remplacer l’un des éléments ci-dessus ou empêcher qu’un signataire soit trompé |
Pourquoi un audit ne garantit rien : des cas réels
Des protocoles audités continuent de perdre de l’argent. Les non audités aussi, et plus souvent selon un décompte : Zellic écrivait en novembre 2022 que 15 des 20 plus gros piratages du classement de Rekt n’avaient pas été audités, un décompte qui inclut Nomad, et Zellic vend des audits. Personne ne publie de ratio propre entre échecs de protocoles audités et non audités, et il faut donc se méfier de qui en cite un. Les cas qui suivent montrent comment une perte se produit autour d’un audit, et aucun n’est un verdict sur le cabinet nommé.
Balancer, novembre 2025 : les avertissements contenus dans les rapports
Le 3 novembre 2025, un attaquant a vidé les pools stables de Balancer V2 et les forks de ce code. Le rapport préliminaire pointait une erreur d’arrondi dans l’étape de mise à l’échelle (upscale) des swaps à sortie exacte à l’intérieur de batchSwap, comme l’a résumé The Block, en anglais. De minuscules erreurs d’arrondi, répétées dans une chaîne d’échanges au sein d’une même transaction contre des pools poussés vers de faibles soldes, se sont additionnées. OpenZeppelin en donne un compte rendu détaillé. Les chiffres de pertes varient selon la méthode : environ 116 millions de dollars pour Cointelegraph, en anglais le 5 novembre, plus de 120 millions avec les forks pour OpenZeppelin, et 128,64 millions de dollars selon le compteur de PeckShield. Balancer précisait alors que ces chiffres n’étaient pas confirmés.
| Date | Document | Ce qu’il dit, dans ses propres termes |
|---|---|---|
| 22 décembre 2021 | Trail of Bits, Linear and Phantom Pools | Constat TOB-BALANCER-004 sur les arrondis, gravité Undetermined, difficulté Low : aucun risque significatif identifié, mais « un attaquant pourrait s’en servir pour dégager un profit » |
| 22 septembre 2022 | Trail of Bits, Composable Stable Pool | Six constats. StableMath et WordCodec hors périmètre ; pas de recherche d’attaques économiques de haut niveau ; BasePool couvert en partie |
| 23 septembre 2022 | Certora, Stable Pool | Trois problèmes, aucun au-dessus de Low. StableMath remplacé par un substitut ; _upscaleArray() réglée sur des valeurs non déterministes |
| 3 novembre 2025 | Attaque | Arrondi dans l’étape de mise à l’échelle des swaps à sortie exacte |
Une précaution s’impose. Le constat de 2021 porte sur les arrondis dans LinearMath et LinearPool, et il note que _upscaleArray est utilisée de façon similaire dans tous les pools Balancer. Il relève de la même famille de préoccupations que l’attaque de 2025 : ce n’est pas une description de cette attaque, et le cabinet disait n’avoir trouvé aucun risque significatif. Le tableau montre qu’un lecteur attentif pouvait voir en 2022 trois choses : les arrondis avaient été signalés puis laissés indéterminés, la bibliothèque de calcul était hors périmètre d’un audit, et l’étape de mise à l’échelle était simplifiée dans les preuves. C’est un constat sur ce que les documents couvraient. Il ne prouve pas qu’un cabinet aurait dû repérer l’attaque.
OpenZeppelin, qui a audité le code Balancer V2 antérieur en 2021, date la première surcharge de la mise à l’échelle du 16 juillet 2021 et affirme que les pools porteurs du vecteur d’attaque ont été ajoutés après la fin de son second audit, de sorte que ses rapports ne les couvraient pas. C’est le récit du cabinet sur son propre travail, et le même article n’impute de faute à aucun auditeur. Il ne parle d’ailleurs que pour OpenZeppelin : la page de Balancer liste les deux rapports de septembre 2022 ci-dessus sur le Composable Stable Pool, chacun avec les limites indiquées dans le tableau.
Euler, mars 2023 : un changement ultérieur
Euler a perdu environ 197 millions de dollars le 13 mars 2023, selon le décompte de Rekt, en anglais. Le chemin passait par donateToReserves, qui, d’après Rekt, est entrée dans Euler via une mise à jour de contrat appelée EIP-14, et qui n’avait pas le contrôle de liquidité appliqué aux transferts ordinaires (analyse de Zellic, en anglais). Rekt comptait six auditeurs. Le média rapportait aussi que Sherlock, qu’il décrivait comme un protocole d’assurance de smart contracts, avait reconnu sa responsabilité pour avoir manqué la faille dans sa relecture d’EIP-14. The Block, en anglais a rapporté le 14 mars que Sherlock acceptait de régler une réclamation de 4,5 millions de dollars. Les récits divergent sur le détail de cette relecture, et mieux vaut s’en tenir là. Le dénouement fut inhabituel : Euler a indiqué le 3 avril 2023 que l’attaquant avait restitué tous les « fonds récupérables » (CoinDesk, en anglais).
L’attaque a utilisé un prêt flash, expliqué dans notre leçon sur les prêts flash. La leçon de lecture est plus simple : le nombre d’auditeurs ne dit pas qui a relu telle fonction.
Nomad, août 2022 : code audité et code déployé
Le pont Nomad a perdu environ 190 millions de dollars en août 2022. Zellic, en anglais écrit que, selon Quantstamp, l’auditeur, « le code défectueux responsable du piratage a été introduit après le début de l’audit », et que son outil de suivi n’affichait que 18,6 % du code en chaîne de Replica.sol comme audité. Cointelegraph, en anglais a rapporté le 3 août 2022 que la faille avait été signalée dans le rapport de juin de Quantstamp, puis ajouté la position de Nomad, selon laquelle la vulnérabilité mise en avant par Quantstamp différait de la cause de l’attaque. Ce sont les déclarations des parties telles que relayées par d’autres, sans prise de parti ici. Seule une comparaison commit par commit établit ce qui a été relu.
2026 : signataires et couches de messagerie
Drift a perdu 285 millions de dollars le 1er avril 2026. Le rapport d’incident de Nexus Mutual, en anglais y voit « le résultat d’une défaillance de sécurité opérationnelle, pas d’une attaque contre les smart contracts de Drift », et décrit des logiciels malveillants sur les appareils de contributeurs ainsi que des approbations présignées par deux des cinq membres du Security Council. Le 18 avril 2026, le pont de Kelp DAO a libéré 116 500 rsETH, soit environ 292 millions de dollars, après qu’un attaquant a obtenu que la couche de messagerie de LayerZero accepte une fausse instruction comme valide, selon CoinDesk, en anglais, qui notait que Kelp n’avait pas encore expliqué comment la validation avait été contournée. Un rapport sur un contrat dit peu de chose de ses signataires, ou de la couche de messagerie à laquelle il fait confiance.
Ce que le FBI a dit aux investisseurs
L’avis du FBI du 29 août 2022, en anglais recommandait aux investisseurs : « Assurez-vous que la plateforme d’investissement DeFi a fait réaliser un ou plusieurs audits de code par des auditeurs indépendants ». Le même avis citait une attaque par prêt flash d’environ 3 millions de dollars, une faille de signature de pont qui a coûté environ 320 millions et une manipulation d’oracle de prix d’environ 35 millions. L’avis ne dit pas si ces plateformes avaient été auditées : la ligne sur l’audit se lit donc comme une précaution parmi d’autres, pas comme une promesse.
Faux badges d’audit et mentions trompeuses
Un logo sur une page d’accueil ne coûte rien. CertiK a averti, en anglais le 17 janvier 2024 que des sites frauduleux utilisaient de fausses certifications d’audit à son nom, et a cité Lymex, une arnaque de sortie d’environ 300 000 dollars qui désignait CertiK comme auditeur alors que, selon CertiK, le projet n’avait jamais reçu la prestation. C’est un prestataire qui défend sa marque et qui ne parle donc que de son propre cas, mais la méthode est générale. Nos guides sur le rug pull et sur les moyens d’éviter les arnaques crypto montrent où ces badges apparaissent.
Six vérifications sur un rapport d’audit de smart contract prennent quelques minutes :
- Cherchez le rapport sur le site du cabinet d’audit ou sur son GitHub officiel. Un PDF hébergé sur le site du projet ne prouve rien à lui seul.
- Vérifiez que la date et le hash du commit existent et que le commit figure dans le dépôt public du projet.
- Un vrai rapport nomme ses relecteurs, précise son périmètre et dit ce qui n’a pas été couvert.
- Les constats portent des identifiants et des statuts, et un rapport fait uniquement de compliments est suspect.
- Comparez l’adresse du contrat ou le commit du rapport avec ce qui est déployé.
- Ignorez tout lien de « vérification » reçu en message privé, et rejoignez le site du cabinet par votre propre signet.
Un score sur une page de notation de sécurité n’est pas non plus un audit. Lisez ce que le score mesure avant de vous y appuyer. Et un vrai rapport sur un autre contrat, une ancienne version ou une petite partie du système est la ruse la plus subtile : « audité par » sur un site peut être exact et ne rien dire du code qui détient votre argent.
La liste de contrôle des dix minutes pour lire un rapport d’audit
- Notez la date, le dépôt et le commit.
- Lisez le périmètre et les limites de couverture avant tout constat.
- Comptez les constats Critical et High, avec les définitions de ce cabinet.
- Vérifiez le statut de chacun : fixed, acknowledged, risk accepted ou not fixed.
- Lisez chaque « Undetermined » et les raisons de chaque risque accepté.
- Vérifiez que l’auditeur a relu les correctifs.
- Relevez ce qui est supposé : oracles, administrateurs, jetons externes, fonctions simplifiées.
- Remontez de l’adresse en production jusqu’à l’implémentation et à la version.
- Listez les audits de cette version, et notez toute mise à niveau depuis.
- Cherchez un bug bounty actif, et ce que paierait un signalement réussi.
Comment peser ce que vous avez trouvé
Après ces dix minutes, vous tenez des faits, pas un verdict. Un rapport d’audit de smart contract propre, portant sur le code en usage, avec des correctifs relus, plusieurs cabinets et un bug bounty actif, réduit un seul type de risque. Il ne fait rien contre les pannes d’oracle, les signataires, la gouvernance ou les ponts. Des constats ouverts sur les gravités les plus hautes, un périmètre qui écarte la partie dont vous dépendez ou une mise à niveau postérieure au dernier audit sont des questions à creuser, et la réponse publique d’un protocole à ces questions en dit long.
La leçon suivante de ce parcours démonte les attaques elles-mêmes, famille par famille, avec la réentrance, les prêts flash et les oracles manipulés, ainsi qu’une liste datée des plus gros cas.
