Audit crypto : qui paie vraiment quand le piratage a lieu ?

Le 18 avril 2026, quand les premiers chercheurs en sécurité se penchent sur le piratage de KelpDAO, ils cherchent d’abord la faille dans le code. Ils ne la trouvent pas. Le protocole de liquid restaking venait de perdre 292 millions de dollars (environ 253 millions d’euros au taux de change actuel), l’un des plus gros vols DeFi de l’année, et ses smart contracts n’avaient rien d’anormal. OpenZeppelin le résume sans détour dans son analyse post-mortem : « The contracts performed exactly as written » (les contrats ont fonctionné exactement comme ils avaient été écrits).

KelpDAO avait été audité. Comme Balancer, comme Bunni, comme Cetus, comme la quasi-totalité des protocoles qui perdent chaque année plusieurs centaines de millions de dollars malgré un ou plusieurs rapports d’audit publiés en amont. La question posée par ce dossier n’est donc pas de savoir quel cabinet produit les meilleurs rapports, ni combien de vulnérabilités il a trouvées cette année. Elle est plus simple, et plus inconfortable : quand un protocole audité se fait quand même vider, qui répond financièrement de la perte, et que reste-t-il de la promesse implicite d’un badge « audité par » ?

Un audit, zéro bug, 292 millions de dollars envolés

KelpDAO est un protocole de liquid restaking : les utilisateurs déposent de l’ETH restaké et reçoivent en échange du rsETH, un jeton liquide utilisable ailleurs dans la DeFi, y compris sur d’autres chaînes via le protocole de messagerie cross-chain LayerZero. C’est précisément cette brique cross-chain qui a cédé. Selon l’analyse technique de Halborn, KelpDAO faisait vérifier ses messages entrants par une configuration dite « 1-sur-1 » : un seul nœud vérificateur (DVN) avait la charge de valider un message cross-chain avant que les fonds ne soient débloqués.

Le 18 avril 2026, des attaquants ont compromis une partie des nœuds RPC dont dépendait ce vérificateur unique et ont saturé les autres par déni de service, forçant le système à s’appuyer sur des sources de données qu’ils contrôlaient. Un message cross-chain frauduleux a suffi à faire libérer 116 500 rsETH de l’escrow du pont. L’attaque a été attribuée au groupe Lazarus, lié à la Corée du Nord. Aucune ligne du contrat n’a été modifiée, contournée ou exploitée au sens classique du terme : le système a simplement fait ce qu’on lui avait dit de faire.

La suite a pris la forme d’une panique de liquidité éclair. Environ 89 567 des rsETH volés ont été déposés en collatéral sur Aave pour emprunter près de 190 millions de dollars en WETH, déclenchant des retraits massifs qui ont fait sortir près de 8,45 milliards de dollars d’Aave et plus de 13 milliards de dollars de l’ensemble de la DeFi en 48 heures à peine. Une faille de configuration d’infrastructure, invisible à un audit de code, a donc eu un effet de contagion largement supérieur à sa taille initiale.

OpenZeppelin a profité du post-mortem pour lister explicitement ce qu’un audit de smart contract classique n’examine généralement pas : la manière dont les intégrations avec des protocoles tiers sont configurées au déploiement, si des composants d’infrastructure créent un point de défaillance unique, si les réglages par défaut recommandés dans la documentation ont été suivis, et comment un système se comporte quand ses dépendances off-chain sont compromises. KelpDAO coche les quatre cases. C’est le point de départ de tout ce dossier.

Ce qu’un rapport d’audit promet vraiment

Un audit de smart contract est, concrètement, une revue manuelle et automatisée (analyse statique, fuzzing) d’un dépôt de code défini, arrêté à un commit précis, réalisée sur une fenêtre de temps fixe, le plus souvent entre une et six semaines selon le périmètre et le budget. Le livrable est un rapport qui classe chaque finding par sévérité (critical, high, medium, low, informational) et recommande des corrections. C’est tout ce qu’un audit promet contractuellement : une opinion d’expert, à un instant donné, sur un périmètre donné.

Ce qu’il ne peut structurellement pas promettre : l’exhaustivité (aucun cabinet sérieux ne prétend avoir trouvé tous les bugs possibles), la permanence (un code modifié après l’audit redevient, par définition, non audité dans sa nouvelle version), ou une couverture au-delà du périmètre convenu. Le classement 2026 de Sherlock le formule sans détour : ses propres services « does not constitute a guarantee against all security incidents or losses » (ne constituent pas une garantie contre tous les incidents de sécurité ou toutes les pertes).

Rien de tout cela n’est propre à un cabinet en particulier ou à la crypto : c’est une limite structurelle de la revue de code manuelle en tant que discipline. Ce qui change en DeFi, c’est l’enjeu. Un finding manqué dans la revue d’un logiciel d’entreprise coûte des frais de correction. Un finding manqué dans un protocole DeFi peut être drainé, de façon irréversible, par n’importe qui dans le monde, en quelques minutes, dès que la faille devient visible on-chain.

La clause qui protège l’auditeur, pas l’utilisateur

Les contrats d’engagement d’un audit incluent presque toujours de larges clauses de limitation de responsabilité : prestation fournie « as is » et « as available », aucune garantie de qualité marchande ni d’adéquation à un usage particulier, client tenu d’indemniser le cabinet, responsabilité totale du cabinet plafonnée aux honoraires perçus et non aux dommages subis par les utilisateurs du protocole. Cette rédaction n’a rien de spécifique à la crypto ; elle reprend le langage classique des contrats de conseil en logiciel. Elle prend simplement un tout autre poids quand le logiciel en question sécurise des sommes à neuf chiffres.

Conséquence pratique : même dans un cas comme Cetus, où trois cabinets distincts ont successivement validé un code qui s’est révélé fatal (voir plus bas), aucun recours contractuel du protocole contre ces cabinets ne couvre les 223 millions de dollars perdus par les utilisateurs. Au mieux, un cabinet peut consentir un remboursement partiel d’honoraires, des excuses publiques, ou un arrangement négocié à l’amiable ; rien dans le droit des contrats actuel ne l’oblige à indemniser les victimes.

Ce point mérite d’être posé clairement parce qu’il va à l’encontre d’une hypothèse répandue chez les utilisateurs : un badge « audité » est souvent lu comme une garantie implicite, proche d’une assurance ou d’un label de conformité. Contractuellement, c’est presque l’inverse : le document qui accompagne l’audit sert avant tout à décliner ce type précis de garantie.

Quand la faille est hors périmètre : ponts, clés et votes

KelpDAO illustre une catégorie entière de pertes structurellement hors du champ d’un audit de smart contract classique, indépendamment de la qualité de cet audit. Les ponts cross-chain en sont l’exemple le plus documenté : la vulnérabilité y vit dans les hypothèses de confiance entre deux chaînes, pas dans le code d’une seule d’entre elles, un sujet que nous avions détaillé dans notre enquête sur les piratages de ponts crypto et la raison pour laquelle ce vecteur revient sans cesse.

La garde des clés et les interfaces de signature forment une deuxième catégorie. Le piratage de Bybit en février 2025, environ 1,5 milliard de dollars (près de 1,3 milliard d’euros), reste le plus gros de l’histoire de la crypto : le smart contract Safe utilisé pour le multisig n’a jamais été touché, la compromission a eu lieu dans l’interface JavaScript de signature qu’un humain regardait avant de valider la transaction. Aucun audit du contrat Safe, aussi rigoureux soit-il, n’aurait intercepté ce vecteur.

La gouvernance on-chain forme la troisième. Là, un attaquant n’a même pas besoin de casser une ligne de code : il lui suffit de réunir assez de pouvoir de vote pour faire adopter une proposition malveillante par des mécanismes parfaitement légitimes. C’est ce qui est arrivé à BonkDAO en juillet 2026, où 20 millions de dollars ont été siphonnés via un vote acheté plutôt qu’un exploit technique. Aucune de ces trois catégories, ponts, clés, gouvernance, ne serait détectée par la revue la plus minutieuse d’un dépôt Solidity.

Cetus, Balancer, Bunni : quand la faille est dans le périmètre, et qu’on la manque quand même

Le 22 mai 2025, la plateforme d’échange Cetus, bâtie sur Sui, perd environ 223 millions de dollars (193 millions d’euros) à cause d’un dépassement arithmétique dans sa fonction de calcul de liquidité get_delta_a, via une opération checked_shlw défaillante qui ne rejetait pas certaines valeurs dépassant une limite de 192 bits. Un attaquant a utilisé un flash loan pour ouvrir une position dans une fourchette de prix étroite et faire frapper une quantité de liquidité largement disproportionnée. Ce qui distingue ce cas pour notre sujet : la fonction fautive avait été examinée séparément par trois cabinets, OtterSec, MoveBit et Zellic, le dernier audit s’étant clos à peine un mois avant l’exploit sans rien remonter au-delà de findings informationnels, selon l’explication technique publiée par Halborn.

Le 3 novembre 2025, Balancer V2 perd environ 128 millions de dollars (111 millions d’euros) sur Ethereum, Base, Polygon et Arbitrum en moins de trente minutes, via une erreur d’arrondi dans le chemin de swap batchSwap EXACT_OUT. Trail of Bits, l’un des plus de dix cabinets à avoir examiné le code de Balancer depuis 2021, avait pourtant repéré le mécanisme en cause dès sa revue initiale (finding TOB-BALANCER-004), mais avait classé sa sévérité comme « indéterminée » faute de pouvoir confirmer son exploitabilité dans la configuration réelle des pools à l’époque.

Le 2 septembre 2025, Bunni perd environ 8,4 millions de dollars (7,3 millions d’euros) sur Ethereum et Unichain selon un schéma presque identique en plus petit : 44 retraits successifs de faible montant ont accumulé une erreur d’arrondi jusqu’à vider 85,7 % du solde actif du pool. Trail of Bits avait signalé le risque général (finding TOB-BUNNI-13), Bunni avait livré un correctif, mais ce correctif ne couvrait pas le cas particulier finalement exploité. L’équipe a fermé définitivement quelques mois plus tard, invoquant l’impossibilité de financer un nouveau programme de sécurité à six ou sept chiffres.

Le fil conducteur : dans ces trois cas, le risque en cause se situait, sous une forme ou une autre, dans le périmètre déclaré de l’audit. Il a été examiné par des cabinets reconnus et compétents. Et il a quand même été manqué, sous-estimé, ou corrigé de façon incomplète. C’est sans doute le constat le plus inconfortable des deux catégories présentées dans ce dossier, car « votre audit ne couvrait pas l’infrastructure » a une réponse évidente (faire auditer l’infrastructure aussi), tandis que « trois cabinets ont examiné cette fonction précise et l’ont validée » n’en a pas.

Ce tableau ne doit pas se lire comme un palmarès des pires cabinets : les six incidents impliquent des équipes d’audit différentes, sur des chaînes différentes, avec des causes techniques qui n’ont rien en commun sinon leur ampleur. C’est justement ce qui en fait une preuve solide : la faille n’est pas propre à un cabinet, un langage ou une chaîne, elle est structurelle à la manière dont l’industrie définit, aujourd’hui, ce qu’un audit couvre.

La réputation, seule vraie sanction ?

Puisque les contrats d’audit déclinent toute responsabilité financière et qu’aucun régulateur ne contrôle la qualité des audits, le seul mécanisme de sanction qui reste est la réputation de marché : un client qui refuse de rembaucher un cabinet après une erreur. L’épisode CertiK-Kraken de juin 2024 permet de tester si ce mécanisme fonctionne réellement. CertiK, agissant selon son propre récit comme un « chercheur en sécurité » non identifié, a découvert et exploité un bug d’inflation de solde sur le système de dépôt de Kraken, retiré près de 3 millions de dollars, puis, selon Kraken, conservé les fonds en exigeant une estimation des pertes potentielles avant de les restituer.

Le directeur de la sécurité de Kraken, Nick Percoco, l’a résumé sans ambiguïté sur X, cité par CoinDesk : « This is not white-hat hacking, it is extortion » (ce n’est pas du white-hat hacking, c’est de l’extorsion). D’autres figures reconnues de la sécurité ont réagi dans le même sens : l’ancien CISO de ShapeShift, Michael Perklin, a déclaré « I’d never hire a security company that did this. Extortion is a bad look » (je n’engagerais jamais une société de sécurité qui a fait ça, l’extorsion, ça fait mauvais genre), et le CTO de Casa, Jameson Lopp, a jugé la situation « pretty fishy » (assez louche), les deux propos rapportés par The Defiant. CertiK a fini par restituer les fonds.

Pourtant, l’épisode n’a pas visiblement entamé la position de marché de CertiK, qui reste l’un des noms les plus cités de l’industrie selon le classement 2026 de Sherlock cité plus haut. Dans le même article de The Defiant, le fondateur de Nexus Mutual, Hugh Karp, a livré une observation qui va dans le même sens depuis l’angle de la tarification du risque : selon lui, les capitaux mis en jeu par les stakers de Nexus Mutual ne baissaient pas nécessairement le risque perçu d’un protocole du simple fait qu’il ait été audité par CertiK plutôt que pas audité du tout, un aveu frappant venant d’un acteur dont le métier consiste précisément à chiffrer ce risque.

La réputation est donc un mécanisme lent, bruyant, et appliqué de façon inégale. Elle peut produire une controverse virale sans faire bouger significativement les parts de marché, en grande partie parce qu’il n’existe aucun organisme de notation centralisé et indépendant, équivalent d’une agence de notation de crédit, capable de traduire « ce cabinet a manqué un bug critique » en un chiffre qu’un fondateur de protocole pourrait réellement peser au moment d’embaucher.

Ce qui protège vraiment : bug bounties et couverture on-chain

Deux mécanismes de la pile de sécurité DeFi portent, eux, une véritable obligation contractuelle de versement plutôt qu’une clause de non-garantie. D’abord les plateformes de bug bounty : Immunefi, la plus grande, gère des programmes dont les plafonds atteignent environ 15 millions de dollars pour la catégorie de finding la plus critique sur les protocoles les mieux financés, versés directement au chercheur qui divulgue la faille de façon responsable plutôt que de l’exploiter.

Ensuite la couverture on-chain. Sherlock exploite ce qu’il appelle un pool de couverture, qui « pays out to protocols when in-scope bugs are exploited » (verse une indemnité aux protocoles quand un bug dans le périmètre couvert est exploité), une structure que le cabinet présente comme unique parmi les grands acteurs du secteur. Nexus Mutual, plus ancien et plus important, propose un produit comparable et s’est directement associé à Sherlock via « Sherlock Excess Cover », qui protège une partie supplémentaire de la capacité de couverture de Sherlock, selon l’annonce publiée sur Medium par Nexus Mutual. Un produit conjoint, Bug Bounty Cover, associant Immunefi, Cantina et Sherlock, permet à un protocole de ne payer que 20 % d’une prime critique de sa poche, Nexus Mutual couvrant le reste jusqu’au plafond de la police.

Ces produits ont, au moins ponctuellement, réellement payé : une réclamation Sherlock Excess Cover liée à l’exploit d’Euler Finance en 2023 a été approuvée pour un million de dollars. C’est modeste face aux 292 millions de KelpDAO, mais c’est de l’argent réel qui change de mains précisément parce qu’un bug défini et couvert a été exploité, ce qui va catégoriquement plus loin que ce qu’un contrat d’audit promet à lui seul. Pour un aperçu plus large de la manière dont ce marché de la couverture se construit ailleurs dans la DeFi, voir notre enquête sur le slashing en cascade et la course à l’assurance dans le restaking.

L’assurance a, elle aussi, ses petites lignes

Le piège : ces produits de couverture reproduisent le même problème de périmètre que les audits auxquels ils s’ajoutent. Sherlock précise explicitement que son produit Shield « is not free » (n’est pas gratuit) et demande à l’acheteur d’examiner attentivement les termes du périmètre couvert ; la couverture ne verse que pour les findings que la police définit comme couverts, exactement la même frontière qui a laissé passer la panne d’infrastructure de KelpDAO ou la compromission d’interface de Bybit à travers un audit de smart contract classique.

Les plafonds restent, en outre, minuscules face aux pertes les plus médiatisées : la couverture post-audit de Sherlock culmine autour de 10 millions de dollars par police, les plus gros plafonds de bounty d’Immunefi tournent autour de 15 millions ; aucun des deux n’aurait sérieusement entamé le trou de 292 millions de dollars de KelpDAO, même intégralement couvert. Et parce que ces produits sont des options payantes qui s’ajoutent à une facture d’audit déjà à cinq ou six chiffres, la plupart des protocoles, en particulier les plus jeunes ou les plus petits, ne les souscrivent tout simplement pas.

En pratique, l’écrasante majorité des pertes liées aux piratages DeFi est absorbée directement par les utilisateurs, ou partiellement compensée de façon discrétionnaire et non contractuelle : après Cetus, la Sui Foundation a engagé 10 millions de dollars et organisé un prêt spécifiquement pour aider à indemniser les utilisateurs, un geste de bonne volonté sans aucune obligation d’audit ou d’assurance derrière lui.

Ce que la France impose déjà à ses auditeurs financiers classiques

Le contraste devient plus net une fois comparé à un régime d’audit qui existe juste à côté, en droit français : celui du commissaire aux comptes, chargé de certifier les comptes d’une entreprise. En vertu de l’article L822-17 du Code de commerce, qui prolonge la règle générale de responsabilité civile de l’article 1240 du Code civil, un commissaire aux comptes est personnellement responsable, envers la société comme envers les tiers, des conséquences dommageables des fautes et négligences commises dans l’exercice de ses fonctions.

Cette responsabilité civile s’accompagne d’une exposition pénale (un commissaire aux comptes qui tait des faits délictueux dont il a connaissance au procureur de la République s’expose à des conséquences directes), et les cabinets sont légalement tenus de souscrire une assurance responsabilité civile professionnelle dont le montant minimal est indexé sur leur chiffre d’affaires. Depuis le 1er janvier 2024, l’ensemble de la profession est supervisé par la Haute Autorité de l’Audit (H2A), qui a succédé à l’ancien H3C en vertu de l’ordonnance du 6 décembre 2023.

Rien de comparable n’existe où que ce soit dans l’industrie de l’audit de smart contracts, en France ou ailleurs. Aucun organisme d’accréditation ne décide qui a le droit de se présenter comme auditeur blockchain. Aucun texte n’impose de responsabilité civile ou pénale personnelle à un individu nommément désigné pour un finding manqué. Aucune obligation d’assurance n’est indexée sur le chiffre d’affaires de l’auditeur. Les comptes d’une entreprise française sont protégés par un régime de responsabilité vieux de plusieurs décennies auquel un protocole DeFi sécurisant une somme comparable, voire supérieure, en argent d’utilisateurs n’a tout simplement pas accès.

AMF, MiCA, DORA : la régulation qui ne dit rien sur l’audit

Ce n’est pourtant pas faute d’un cadre réglementaire crypto qui fonctionne en France. L’AMF a passé les deux dernières années à accompagner les PSAN enregistrés vers l’agrément complet MiCA en tant que prestataires de services sur crypto-actifs (PSCA/CASP) ; cette fenêtre transitoire s’est officiellement refermée le 1er juillet 2026, comme le rappelle l’AMF elle-même, ce qui signifie que toute plateforme servant encore des utilisateurs français doit désormais détenir un agrément CASP complet plutôt que l’ancien enregistrement national allégé.

DORA, en vigueur pour les entités financières régulées, CASP compris, depuis le 17 janvier 2025, impose bien des obligations de résilience informatique, y compris des audits des systèmes IT internes. Mais DORA comme MiCA régulent la plateforme (la bourse, le dépositaire, l’émetteur), pas le code du protocole sous-jacent ; une application DeFi entièrement décentralisée, sans CASP identifiable derrière elle, échappe totalement aux deux cadres, ce qui signifie qu’il n’existe, très littéralement, aucun régulateur vers qui se tourner quand les choses tournent mal.

Même pour les plateformes qui entrent dans le champ de la régulation, aucun des deux textes n’impose que les smart contracts sur lesquels elles s’appuient soient audités par un organisme accrédité, pour la simple raison qu’une telle accréditation n’existe pas. L’écart identifié dans la section précédente n’est pas un oubli propre à la France ; c’est un vide réglementaire réel que le cadre européen actuel, malgré son ampleur, ne tente pas de combler.

Comparatif : qui répond de quoi

Pour rendre cet écart de responsabilité concret, le tableau ci-dessous met côte à côte les quatre mécanismes évoqués dans ce dossier, avec, pour chacun, ce qu’il couvre réellement et ce qu’il laisse de côté.

En lisant la dernière colonne de haut en bas, un motif se dégage : plus un mécanisme se rapproche du monde on-chain (audit, bounty, couverture), plus la notion de « périmètre » revient comme frontière de sa responsabilité. Seul le régime hérité du droit des sociétés classique, pensé sans périmètre technique, engage une personne de façon inconditionnelle.

Combien coûte un audit, et ce que ce prix achète vraiment

En euros, les engagements haut de gamme pour un protocole DeFi majeur tournent grossièrement entre 70 000 et 300 000 euros ; les cabinets de milieu de gamme, entre 22 000 et 70 000 euros environ ; les boutiques démarrent près de 7 000 euros pour des périmètres restreints. Ces ordres de grandeur, cohérents avec plusieurs synthèses sectorielles 2026, sont confirmés par le propre guide de tarification de marché publié par Sherlock.

Ce que ce budget achète précisément : du temps d’ingénieur, une expertise appliquée dans un périmètre et une durée convenus, et une opinion écrite. Il n’achète ni garantie, ni police d’assurance, ni service continu, sauf si ces éléments sont explicitement achetés en plus (voir les produits de couverture évoqués plus haut).

L’illustration la plus nette de ce à quoi ressemble un budget réellement conséquent : le programme « Security by Design » d’Aave avant le lancement de sa version 4, mené de mars 2025 à février 2026, a associé Trail of Bits, ChainSecurity et Blackthorn sur plus de 345 jours-revue cumulés, une suite de tests d’invariants et un concours de code public de six semaines, pour un budget total d’environ 1,5 million de dollars, avec zéro finding critique ou élevé recensé à l’issue du programme selon The Block. Pour un aperçu plus large de la manière dont ce lancement s’est déroulé, voir notre article sur Aave V4 et l’attente de Babylon.

Ce type de budget multi-cabinets et multi-méthodes reste rare, réservé aux protocoles les mieux capitalisés. La plupart des équipes, en particulier au lancement, travaillent avec une fraction de cette somme, ce qui explique en partie pourquoi le seul mot « audité » renseigne si peu un utilisateur : une revue à cinq chiffres d’une semaine et un programme à sept chiffres étalé sur un an sont, techniquement, tous deux « un audit ».

Ce que cela change pour les équipes et pour les utilisateurs

Pour une équipe de protocole, la réponse pratique à un vide de responsabilité qu’aucun contrat ni aucun régulateur ne comble consiste à cesser de traiter un audit unique comme une ligne d’arrivée. Quelques principes reviennent, projet après projet, chez les équipes qui prennent ce vide au sérieux :

• Faire réviser le code par plusieurs cabinets indépendants, à des étapes différentes du développement, plutôt qu’une seule fois juste avant le lancement.
• Mettre en place un bug bounty avec un plafond réellement dissuasif, pas symbolique.
• Négocier explicitement une couverture on-chain et vérifier ce qu’elle exclut avant d’annoncer publiquement être « couvert ».
• Documenter et surveiller en continu (fuzzing, monitoring on-chain) plutôt que de traiter le rapport d’audit comme un état final.
• Publier à l’avance un plan de réponse aux incidents, plutôt que de l’improviser après coup.

Même quand la justice s’en mêle, elle vise rarement l’auditeur. Le procès en cours autour de Pump.fun cible une fraude ou une présentation trompeuse imputée aux fondateurs, pas une négligence d’un cabinet d’audit ; la responsabilité d’un auditeur, comme les sections précédentes l’ont montré, n’atteint pratiquement jamais un tribunal.

Pour les utilisateurs et les investisseurs, le changement pratique consiste à traiter un badge « audité par X » comme un signal faible parmi d’autres plutôt que comme un feu vert. Quelques questions simples permettent de le pondérer plus justement :

• Le rapport est-il public et daté, avec un commit hash vérifiable, ou seulement une mention marketing sur le site du projet ?
• Les findings « critical » et « high » ont-ils été corrigés et re-vérifiés, ou seulement marqués « acknowledged » ?
• Le protocole dispose-t-il d’un bug bounty actif, et avec quel plafond réel ?
• Existe-t-il une couverture on-chain, et que couvre-t-elle précisément ?
• Le protocole a-t-il été audité une seule fois avant le lancement, ou fait-il l’objet d’une revue continue ?

Rien de tout cela ne rend un audit inutile : l’expertise appliquée dans le périmètre exact de Cetus, Balancer ou Bunni continue de repérer l’écrasante majorité des erreurs de code courantes avant qu’elles ne coûtent quoi que ce soit à personne. Cela signifie simplement que le mot « audité » n’a jamais été un synonyme de « sûr », et que les plus grosses pertes de 2026, KelpDAO en tête, continuent de le prouver.

Questions fréquentes

Un audit de smart contract garantit-il la sécurité d’un protocole crypto ?

Non. Un audit est une revue ponctuelle du code à un instant et un périmètre donnés ; il réduit le risque de bugs de logique mais ne garantit ni l’absence totale de faille, ni la sécurité de l’infrastructure, des clés ou de la gouvernance qui l’entourent. Le cas KelpDAO, 292 millions de dollars perdus en avril 2026 malgré un code jugé irréprochable, illustre cette limite.

Qui est responsable financièrement si un protocole audité se fait pirater ?

En général, personne d’autre que le protocole lui-même et, indirectement, ses utilisateurs. Les contrats d’audit incluent presque toujours des clauses limitant la responsabilité du cabinet aux honoraires perçus, sans garantie sur les pertes réelles. Seuls les bug bounties et les produits de couverture on-chain comme Sherlock ou Nexus Mutual prévoient un versement contractuel, et seulement dans leur périmètre défini.

Comment fonctionne l’assurance DeFi comme Sherlock ou Nexus Mutual ?

Ce sont des produits optionnels et payants qui indemnisent un protocole si une faille explicitement couverte est exploitée, avec des plafonds contractuels pouvant atteindre environ 10 millions de dollars chez Sherlock après un audit. Ils ne remplacent pas une assurance générale et n’interviennent pas pour les failles situées hors du périmètre convenu à l’avance.

Combien coûte un audit de smart contract en 2026 ?

Les tarifs varient fortement selon le cabinet et l’ampleur du projet : de moins de 10 000 euros pour une petite revue en cabinet boutique à plus de 250 000 euros pour un programme complet multi-cabinets sur un protocole DeFi majeur, comme celui déployé par Aave pour sa version 4.

Les cabinets d’audit crypto sont-ils régulés par l’AMF ou par MiCA ?

Non. L’AMF supervise les prestataires de services sur crypto-actifs (anciens PSAN devenus CASP) au titre de MiCA depuis la fin de la période transitoire le 1er juillet 2026, mais ni MiCA ni DORA n’imposent ou n’accréditent l’audit des smart contracts eux-mêmes. Un protocole entièrement décentralisé échappe même totalement à ce cadre réglementaire.

Rédigé par l’équipe sécurité de HOGE Wire.