Faux audits crypto : l’arnaque du label sécurité en 2026

« Audité par un cabinet de renom. » En 2026, cette formule s’affiche sur la page d’accueil de presque chaque nouveau protocole, chaque memecoin et chaque plateforme de prêt. Elle rassure, elle fait vendre, et elle est devenue l’un des objets les plus falsifiés de tout l’écosystème. D’après le rapport 2026 de Chainalysis sur la criminalité crypto, les arnaques par usurpation (se faire passer pour une marque, une institution ou un service de confiance) ont bondi de 1 400 % sur un an, sur un total d’environ 17 milliards de dollars (près de 15 milliards d’euros) soutirés aux victimes d’escroqueries en 2025. Le paiement moyen d’une victime est passé d’environ 782 à 2 764 dollars en un an, signe d’un basculement vers des cibles moins nombreuses mais bien plus lucratives. Le label « audité » appartient à la même famille de signaux : facile à copier, difficile à vérifier, et presque jamais remis en cause par ceux qu’il rassure.

En 2026, « audité » est devenu un argument marketing

Un audit de smart contract est un service : une équipe d’ingénieurs relit un code précis, dans un périmètre défini, pendant un temps borné, puis publie un rapport qui détaille ce qu’elle a trouvé et, tout aussi important, ce qu’elle n’a pas regardé. Le badge « audité par X », lui, est un actif marketing. Les deux ne disent pas la même chose. Le rapport parle d’un instant et d’un périmètre ; le badge, une fois collé sur un site, suggère une qualité permanente et globale que personne n’a jamais promise.

Ce glissement n’a rien d’anodin. Il transforme un document technique, nuancé et daté, en un tampon binaire : audité ou pas. Or la vraie question n’est jamais « est-ce audité ? » mais « qu’a couvert l’audit, sur quelle version du code, et qu’en a fait l’équipe ensuite ? ». La thèse que HOGE Wire répète depuis des mois tient en une phrase : un audit est nécessaire, mais très loin d’être suffisant. Le problème propre à 2026, c’est que le marché a appris à vendre le tampon sans forcément payer le travail qui va derrière. Pour comprendre le piège, il faut d’abord accepter qu’il existe trois façons très différentes de mentir avec un audit.

Trois façons de mentir avec un audit

Toutes les tromperies autour d’un audit ne se valent pas. On peut les ranger en trois catégories, de la plus grossière à la plus subtile. La première est le faux pur : aucun audit n’a eu lieu, le rapport et le logo sont fabriqués de toutes pièces. La deuxième est le vrai détourné : un audit a bien existé, mais il ne couvre pas ce que le projet fait croire (mauvaise version, mauvais périmètre, mauvaise adresse de contrat). La troisième est la plus honnête, et de loin la plus fréquente : un vrai audit, sérieux, sur le bon code, suivi malgré tout d’un piratage, parce qu’un audit ne couvre presque jamais l’ensemble du risque. Les trois aboutissent au même résultat pour l’utilisateur (des fonds perdus), mais elles n’appellent pas les mêmes parades.

Le faux pur : logos volés, faux PDF, comptes piratés

La forme la plus brutale ne demande aucune compétence technique. Un projet copie le logo d’un cabinet connu, génère un PDF à son en-tête, et affiche un badge cliquable qui ne mène nulle part de vérifiable. CertiK, la marque la plus visible du secteur, consacre une page entière à ce phénomène et rappelle qu’elle doit régulièrement démentir des audits qu’elle n’a jamais réalisés, ses logos étant apposés sur des sites frauduleux (voir la mise en garde de CertiK sur l’usurpation de sa marque). Le calcul des escrocs est simple : un badge coûte quelques minutes de retouche graphique, et il exploite un réflexe universel, on regarde le tampon, pas le rapport.

L’usurpation ne s’arrête pas au logo. Dans un cas resté célèbre, le compte X officiel de CertiK lui-même a été piraté : un attaquant se faisant passer pour un journaliste a obtenu des identifiants, puis a publié une fausse alerte de vulnérabilité visant Uniswap V3, renvoyant les internautes vers un faux site Revoke.cash conçu pour vider les portefeuilles. Le lien a été retiré en quatorze minutes et Uniswap n’était pas concerné, mais l’épisode donne le vertige : même le mégaphone de l’auditeur peut être retourné contre le public (récit chez BleepingComputer). Quand la source de confiance elle-même peut être détournée, se fier au canal plutôt qu’à la vérification est une erreur de méthode.

Cette catégorie prospère parce qu’elle ne coûte presque rien à produire et qu’elle surfe sur la vague plus large de l’usurpation. La parade est pourtant élémentaire, et on y revient plus bas : ne jamais faire confiance à un document hébergé par le projet lui-même.

Ce marché du faux s’industrialise. Générer un rapport crédible, avec mise en page, niveaux de sévérité et pseudo-recommandations, ne demande plus qu’une poignée de minutes à un modèle de langage, et les outils d’IA rendent ces contrefaçons à la fois plus rapides à produire et, selon Chainalysis, nettement plus rentables. La mécanique type est le honeypot : un token affiche un audit rassurant, autorise les achats, puis bloque les ventes via une fonction cachée ou une liste noire modifiable. Le badge sert alors d’appât, pas de garantie ; il joue exactement le rôle que la culture du « coche la case audit » lui a assigné, rassurer assez vite pour que personne ne lise le contrat.

Le vrai détourné : Swaprum et le code changé après l’audit

La catégorie intermédiaire est plus retorse, car le rapport, lui, est authentique. Le cas d’école est Swaprum, un DEX déployé sur Arbitrum qui arborait fièrement un badge « audité par CertiK ». En mai 2023, l’équipe a disparu avec environ 3 millions de dollars (près de 2,7 millions d’euros), soit à peu près 1 628 ETH (voir Cointelegraph). Le détail qui change tout : d’après la société de sécurité PeckShield, les fondateurs avaient remplacé le contrat MasterChef audité par un contrat malveillant non audité, ajoutant une porte dérobée pour siphonner la liquidité (analyse relayée par Decrypt). Le badge était vrai ; le code déployé ne l’était plus.

Interrogé, CertiK a résumé la limite de son métier sans détour : « En tant qu’auditeur, nous ne pouvons pas forcer les projets à appliquer nos recommandations » (propos rapportés par DL News). C’est exact, et c’est précisément le point aveugle : un audit valide un instantané du code, il ne garantit ni que l’équipe corrigera les failles, ni que le code audité sera celui mis en production. Un contrat évolutif (upgradeable) contrôlé par une clé unique suffit à rendre le badge caduc dès le lendemain de sa publication. Les mécaniques d’un tel effondrement, et surtout la question de savoir qui touche l’argent et qui s’en sort, sont détaillées dans notre enquête sur l’économie des rug pulls DeFi. La leçon pratique est simple : un audit sans vérification que le code en production correspond au code audité ne prouve rien.

Le vrai honnête, mais insuffisant : l’audit est une photo

La troisième catégorie est la plus inconfortable, parce qu’elle ne met en cause ni fraude ni négligence. Un audit peut être sérieux, mené par un bon cabinet, sur exactement le bon code, et le protocole se faire piller quand même. Ronghui Gu, cofondateur et directeur général de CertiK, le formule ainsi : « La fenêtre de danger ne se referme pas après le lancement. » Il ajoute qu’« un projet est audité une fois avant le déploiement, il passe, puis ne revient jamais sur ce code » (propos recueillis par Forbes). Le rapport vieillit ; le badge, lui, reste affiché des années.

Surtout, un audit de code ne couvre par construction qu’une partie du risque. Le rapport Hack3d du premier semestre 2026 de CertiK chiffre plus de 1,31 milliard de dollars (environ 1,17 milliard d’euros) de pertes sur 344 incidents, et la répartition par vecteur est éloquente (voir la page du rapport Hack3d de CertiK).

Le message de ce tableau est brutal pour le label : le seul vecteur véritablement « auditable », les failles de code, est le plus fréquent mais le moins coûteux. L’argent part ailleurs, vers la compromission de clés et le phishing, là où aucun rapport de smart contract ne va regarder. Et les exemples de code pourtant très audité ne manquent pas : Balancer a été passé au crible plus de dix fois par quatre cabinets différents avant d’être vidé de plus de 100 millions de dollars en novembre 2025, et Cetus, sur Sui, a perdu environ 223 millions de dollars (près de 200 millions d’euros) en mai 2025 malgré trois audits distincts (voir l’analyse de Halborn sur le hack de Cetus). Un badge honnête reste un badge partiel.

Il y a une raison structurelle à cela. Un audit examine un contrat à un instant donné, mais un protocole DeFi vit dans un environnement mouvant : il dépend d’oracles de prix, s’imbrique avec d’autres protocoles, et se fait attaquer par des combinaisons que personne n’avait modélisées le jour de la revue. Les failles économiques (manipulation d’oracle, prêt flash, jeux d’incitations) tombent le plus souvent hors du périmètre d’un audit de code, tout comme la compromission d’une clé d’administration. Le badge, lui, ne porte aucune de ces réserves : il fige une confiance là où le risque, lui, continue de bouger.

Ce qu’un badge ne dit pas : périmètre, version, effort

Un rapport d’audit sérieux est un document nuancé. Il précise la période d’engagement, le nombre d’ingénieurs mobilisés, le « niveau d’effort » en semaines-personne, la version exacte du code passée au crible, et surtout ce qui était hors périmètre. Le badge écrase toute cette information. Il ne dit pas si l’audit a duré trois jours ou six semaines, s’il portait sur le cœur du protocole ou sur un module secondaire, ni si des failles de gravité élevée sont restées « acknowledged » sans jamais être corrigées. Deux projets peuvent afficher le même logo alors que l’un a payé une revue de plusieurs semaines et l’autre une relecture expédiée.

Un bon rapport hiérarchise ses conclusions par gravité et par difficulté d’exploitation, et sépare les failles corrigées de celles laissées ouvertes. Une faille moyenne facile à déclencher peut être plus dangereuse qu’une faille critique quasi impossible à exploiter ; le badge, binaire, efface cette nuance. Il ne dit pas non plus combien de recommandations l’équipe a réellement suivies : un projet peut accumuler les findings « acknowledged » (reconnus mais non corrigés) tout en affichant le même logo qu’un projet qui a tout repris. Sans le rapport, l’utilisateur n’a aucun moyen de faire la différence.

Suhail Kakar, responsable des relations développeurs chez TAC Blockchain, résume le désenchantement du secteur après une série de piratages sur des protocoles pourtant très audités : « Ce secteur doit accepter qu’être ‹ audité par X › ne veut presque rien dire. Le code est difficile, la DeFi l’est encore plus » (cité par Cointelegraph). La formule est volontairement provocante, mais elle vise juste : sorti de son rapport, le badge ne transporte aucune de ces réserves. Lire l’audit plutôt que le badge n’est pas un slogan, c’est la seule façon de récupérer l’information que le tampon a effacée.

Vérifier qu’un audit existe vraiment

La première vérification est la plus importante et la plus négligée : ne jamais faire confiance au rapport hébergé par le projet. Un PDF se fabrique, un lien se maquille. Il faut ouvrir le site officiel du cabinet cité et y chercher le rapport. CertiK recommande de passer par sa base Skynet, qui liste les projets réellement audités ; les grands cabinets publient des catalogues équivalents. Une fois le rapport original retrouvé, on compare point par point : nom du projet, réseau, adresse du contrat, version du code, périmètre et date. Si l’un de ces éléments ne colle pas, ou si le rapport est tout simplement introuvable chez le cabinet, le badge est purement décoratif.

Ce réflexe désamorce le faux pur comme le vrai détourné. Le paradoxe de 2026, c’est que les cabinets investissent massivement dans la surveillance continue (le pari de CertiK d’opposer l’IA à l’IA en est l’illustration) pendant qu’une partie du public s’arrête encore au logo. La technologie de détection progresse plus vite que l’hygiène de vérification des utilisateurs. Le tableau ci-dessous résume la routine minimale à appliquer avant de confier des fonds à un protocole qui se dit audité.

Vérifier que le code audité est bien le code déployé

Retrouver un vrai rapport ne suffit pas : encore faut-il qu’il décrive le code réellement en production. C’est toute la leçon de Swaprum. La vérification tient en deux gestes. D’abord, récupérer dans le rapport l’adresse du contrat et le commit (ou le hash) référencés. Ensuite, ouvrir un explorateur de blocs et confirmer que le code source « vérifié » du contrat correspond bien à cette version, et non à un binaire opaque déployé après coup. Un contrat dont le code source n’est même pas vérifié publiquement devrait, à lui seul, faire fuir.

Concrètement, la comparaison passe par le bytecode. Un explorateur de blocs indique si le code source d’un contrat a été « vérifié », c’est-à-dire recompilé puis confronté au bytecode réellement déployé à l’adresse. Un rapport d’audit sérieux mentionne le hash du commit examiné ; il suffit alors de contrôler que ce commit correspond bien au code source publié. Si le projet ne fournit ni adresse, ni commit, ni code vérifié, l’audit devient invérifiable, et un audit invérifiable ne vaut pas mieux qu’un faux.

Le drapeau rouge central est le contrat évolutif sans garde-fou. Un proxy upgradeable contrôlé par une clé unique permet de remplacer la logique du contrat en une seule transaction, réduisant à néant n’importe quel audit. Un timelock et un multisig ne suppriment pas le risque, mais ils laissent au public le temps de voir venir un changement suspect ; sans eux, le code peut muter en silence. Surveiller les mouvements on-chain d’un protocole, comme le font les traqueurs de baleines et de flux suspects, relève de la même hygiène : un badge ne remplace pas l’observation continue de ce qui se passe réellement à l’adresse du contrat.

Où lire les vrais rapports : Solodit, DeFiSafety, dépôts publics

Vérifier un badge suppose de savoir où trouver la vérité. Plusieurs ressources indépendantes existent. Solodit, propriété de Cyfrin, agrège des dizaines de milliers de findings issus de cabinets et de plateformes de concours (Trail of Bits, OpenZeppelin, Sherlock et bien d’autres), ce qui permet de recouper le sérieux d’un audit et l’historique d’un cabinet. DeFiSafety publie un score de qualité de processus, indépendant des cabinets, noté sur des critères de documentation, de tests et de contrôles d’administration. Les cabinets eux-mêmes tiennent des catalogues publics de leurs rapports, souvent accompagnés des dépôts de code correspondants.

L’idée directrice : on juge un auditeur sur son historique de findings, pas sur son logo. Un cabinet qui publie des rapports détaillés, qui documente ses ratés (les meilleurs le font, sous forme de post-mortem, après un piratage) et dont les findings se retrouvent dans les agrégateurs inspire davantage confiance qu’un badge orphelin renvoyant vers un fichier hébergé par le projet. Cette démarche de recoupement est la même que celle qu’un investisseur applique au rendement d’un protocole : derrière un chiffre affiché, il faut savoir auditer soi-même le cash-flow réel plutôt que de croire la vitrine. Le badge de sécurité et le rendement annoncé obéissent à la même règle : ce qui n’est pas vérifiable ne doit pas être cru.

Les drapeaux rouges d’un audit-alibi

Certains signaux trahissent un audit décoratif, invoqué pour rassurer sans protéger. Aucun n’est une preuve à lui seul, mais leur accumulation doit faire reculer :

• Un seul audit, réalisé sur un fork ou sur une version ancienne du code
• La mention « audit en cours » sans rapport publié, parfois entretenue pendant des mois
• Un badge cliquable qui ne renvoie vers aucun rapport hébergé par le cabinet lui-même
• Un contrat évolutif (upgradeable) sans timelock ni multisig, qui autorise un changement de code après l’audit
• Une équipe anonyme couplée à des pouvoirs dangereux (émission illimitée, liste noire, taxes modifiables)
• Des findings « acknowledged » ou « won’t fix » qui ne sont jamais corrigés dans la version déployée

À l’inverse, un projet qui affiche plusieurs audits récents, sur le code déployé, avec des correctifs documentés et une gouvernance protégée par timelock, ne garantit rien d’absolu, mais coche les cases qui distinguent une vraie démarche de sécurité d’un simple habillage marketing.

Aucun régulateur ne certifie les auditeurs

Pourquoi cet écosystème tolère-t-il un signal aussi peu fiable ? Parce que rien ne l’encadre. Aucun régulateur, ni l’AMF en France, ni MiCA au niveau européen, ni DORA, n’accrédite les auditeurs de smart contracts ni n’impose un audit de code. MiCA encadre les prestataires de services sur actifs numériques (les CASP) et les émetteurs, pas le code lui-même ; la DeFi entièrement décentralisée sort même de son périmètre. DORA, applicable aux CASP depuis le 17 janvier 2025, impose une résilience informatique et des tests, mais n’exige pas de relecture du code Solidity ni ne délivre d’agrément d’auditeur. La transition du régime PSAN vers l’agrément CASP s’est achevée le 1er juillet 2026, et l’AMF a rappelé aux acteurs non conformes l’obligation d’un arrêt ordonné (voir la note de l’AMF sur la fin de la période transitoire), mais rien de tout cela ne touche la fiabilité d’un badge « audité ».

Le contraste avec la finance traditionnelle est saisissant. Un commissaire aux comptes français engage sa responsabilité civile et pénale, souscrit une assurance professionnelle obligatoire, et est supervisé depuis le 1er janvier 2024 par la Haute Autorité de l’Audit (H2A), qui a succédé au H3C. Il n’existe aucun équivalent pour l’auditeur de smart contracts : pas d’agrément, pas de responsabilité automatique (les contrats d’audit plafonnent presque toujours les dommages au montant des honoraires), pas d’autorité de tutelle. La seule sanction est réputationnelle, et elle mord peu : un cabinet dont un client s’est fait pirater continue le plus souvent de signer d’autres audits la semaine suivante. Dans ce vide, le badge n’engage personne, ce qui explique qu’on puisse le brandir sans le mériter.

Cette absence de recours pèse plus lourd qu’il n’y paraît. Quand un CASP régulé fait défaut, un utilisateur européen dispose au moins d’un interlocuteur et d’un cadre (MiCA, DORA, et à terme les procédures de l’AMF). Face à un protocole entièrement décentralisé, il n’y a personne à poursuivre : ni émetteur, ni prestataire, ni auditeur juridiquement engagé. L’audit et le post-mortem deviennent alors les seules « garanties » disponibles, et ce sont des garanties morales, pas contractuelles. La réputation devrait discipliner le marché ; tant qu’un badge se vend plus vite qu’il ne se vérifie, l’incitation à surpromettre reste intacte.

Ce que l’industrie tente, et ce qu’elle ne peut pas régler

Les cabinets ne restent pas les bras croisés. La tendance de fond est le passage de l’audit ponctuel à la surveillance continue : monitoring on-chain, scoring en temps réel, détection assistée par IA. CertiK pousse ses outils d’IA, d’autres misent sur la vérification formelle (prouver mathématiquement qu’un code respecte une spécification) ou sur les concours et bug bounties qui exposent le code à des centaines de regards. Ces approches déplacent la frontière de ce que l’audit couvre, et c’est un progrès réel.

L’automatisation a toutefois un revers : elle sert aussi les attaquants. Les recherches de Trail of Bits montrent que des agents autonomes savent désormais s’échapper seuls d’une machine virtuelle et industrialiser la recherche de failles ; la même IA qui accélère l’audit accélère l’exploit. Et aucune de ces avancées ne règle le problème du signal. Un meilleur audit ne rend pas le badge plus vérifiable pour l’utilisateur final ; il ne ferme jamais complètement le périmètre. Gu lui-même observe que les attaquants « obtiennent aujourd’hui plus en s’attaquant à la gestion des clés, à la gouvernance et à l’infrastructure qu’en cherchant des bugs dans le code ». Tant que la valeur fuit par des vecteurs hors périmètre, le badge le mieux mérité restera une garantie partielle.

Les bug bounties illustrent cette logique de complément plutôt que de remplacement : rémunérer des chercheurs pour trouver des failles en continu prolonge l’audit au-delà de sa date, mais ne couvre toujours pas la clé volée sur l’ordinateur d’un développeur ni l’employé piégé par une fausse offre d’emploi. La sécurité d’un protocole en 2026 se joue sur toute une chaîne, du code à l’humain, et le badge ne rend compte que du premier maillon. C’est pourquoi aucun outil, aussi puissant soit-il, ne dispense de lire ce que l’audit a réellement couvert.

Comment lire le signal « audité » en 2026

Le badge « audité » n’est pas inutile : son absence totale reste un signal négatif fort, et un projet qui refuse toute revue extérieure se disqualifie de lui-même. Mais il ne se lit pas comme un label de conformité, plutôt comme une invitation à poser des questions. Un audit sérieux, retrouvé sur le site du cabinet, portant sur le code déployé, mené par une équipe à l’historique vérifiable, avec des findings corrigés, vaut infiniment plus qu’un logo cliquable menant à un PDF hébergé par le projet. La différence entre les deux ne se voit pas sur la page d’accueil ; elle se trouve dans le rapport, dans l’explorateur de blocs et dans les agrégateurs indépendants.

La discipline tient en une phrase : traiter « audité » comme le début d’une vérification, jamais comme sa conclusion. Dans un marché où l’usurpation a bondi de 1 400 % et où les pertes les plus lourdes contournent le code, c’est le seul réflexe qui protège vraiment. Le tampon rassure ; c’est le rapport, et lui seul, qui informe.

Questions fréquentes

Comment savoir si un audit de smart contract est authentique ou falsifié ?

Ne faites jamais confiance au PDF ni au badge hébergés par le projet lui-même. Ouvrez le site officiel du cabinet cité et cherchez-y le rapport ; chez CertiK, la base Skynet liste les projets réellement audités. Comparez ensuite le nom du projet, le réseau, l’adresse du contrat, la version du code, le périmètre et la date. Si le rapport est introuvable chez le cabinet, ou si l’adresse ne correspond pas, le badge ne vaut rien.

Un token « audité par CertiK » est-il fiable ?

Pas automatiquement. Un audit est une revue ponctuelle d’un code précis à une date donnée ; il ne certifie ni l’équipe, ni le comportement futur, ni le code réellement mis en production. Des projets audités par CertiK, comme Swaprum, ont disparu avec les fonds après avoir remplacé le contrat audité par du code malveillant. Le label indique qu’une revue a eu lieu, pas que le projet est sûr.

Pourquoi un projet audité peut-il quand même être un rug pull ou se faire pirater ?

Parce qu’un audit couvre le code, et rarement le reste. En 2026, les pertes les plus lourdes viennent de la compromission de clés, du phishing et de l’infrastructure, pas de bugs de code. Un contrat peut aussi être modifié après l’audit via un proxy évolutif, ou l’équipe peut simplement ignorer les recommandations. L’audit réduit une catégorie de risque, il ne les élimine pas tous.

Comment vérifier que le code audité est bien le code déployé ?

Récupérez l’adresse du contrat dans le rapport d’audit, puis vérifiez sur un explorateur de blocs que le code source vérifié correspond au commit référencé dans le rapport. Méfiez-vous des contrats évolutifs sans timelock : ils permettent de changer le code après la publication du rapport. Des agrégateurs comme Solodit aident à recouper la réputation d’un cabinet et l’historique de ses findings.

L’AMF ou MiCA certifient-ils les cabinets d’audit de smart contracts ?

Non. Aucun régulateur, ni l’AMF, ni MiCA, ni DORA, n’accrédite les auditeurs de smart contracts ni n’impose un audit de code. MiCA encadre les prestataires (CASP) et les émetteurs, pas le code, et la DeFi entièrement décentralisée sort de son périmètre. C’est une différence majeure avec les commissaires aux comptes, supervisés en France par la H2A et engageant leur responsabilité civile et pénale.

Par la rédaction de HOGE Wire, desk sécurité.