Il y a un chiffre, dans les bilans de sécurité du premier semestre 2026, que je n’arrive pas à sortir de la tête : près de 44 % des pertes proviennent d’incidents exploitant des failles opérationnelles et d’infrastructure, et non des bugs de smart contracts. Le vecteur le plus coûteux de l’année n’est ni la réentrance, ni le débordement d’entier, ni la manipulation d’oracle. C’est la compromission de portefeuille.
Sur l’ensemble de 2026, le total dépasse désormais 1,2 milliard de dollars répartis sur 276 incidents. Et quand on regarde les épisodes marquants de l’été, le déplacement saute aux yeux : l’exploitation du micrologiciel Coldcard, qui a permis de drainer environ 1 816 BTC — près de 116 millions de dollars — depuis plus de 5 200 adresses à partir du 30 juillet ; et l’arrêt de la production de blocs de MANTRA le 21 août 2026, après l’exploitation d’une vulnérabilité dans une dépendance externe en amont.
Dans aucun de ces deux cas le code du protocole n’était en cause. Dans les deux cas, un rapport d’audit Solidity impeccable aurait été délivré la veille.
C’est ce constat qui m’a fait changer la façon dont nous cadrons nos missions. Non pas parce que l’audit de code aurait perdu son intérêt — il reste indispensable —, mais parce que continuer à le vendre seul revient à certifier la serrure d’une porte dont la fenêtre est ouverte.
Pourquoi l’attaque s’est déplacée
Ce déplacement n’a rien de mystérieux : c’est une conséquence directe du progrès de la profession. Depuis cinq ans, les audits de smart contracts se sont industrialisés, les bibliothèques standards ont été durcies, les outils d’analyse statique se sont banalisés et les schémas d’attaque classiques sont connus de tous les développeurs sérieux. Exploiter une réentrance dans un protocole audité par une équipe compétente est devenu difficile.
Un attaquant rationnel fait alors ce que fait n’importe quel attaquant rationnel : il change de porte. Et la porte d’à côté — les clés, les accès, les postes de travail des signataires, les dépendances, les outils de déploiement — n’a bénéficié d’aucune industrialisation équivalente. Elle est souvent gérée par deux ou trois personnes, sans procédure écrite, avec des habitudes héritées de la période où le projet ne gérait encore rien de significatif.
Notre avis d’expert (1/3)
La question que nous posons désormais en premier rendez-vous n’est plus « qui a audité vos contrats ? » mais « où sont vos clés, physiquement, en ce moment ? ». La différence de qualité entre les deux réponses est saisissante. La première est documentée, datée, accompagnée d’un PDF. La seconde produit dans la moitié des cas un silence, puis une réponse qui commence par « je crois que ». Ce silence, c’est 44 % du risque.
Les 4 contrôles à ajouter à toute mission
Aucun de ces contrôles ne demande de compétence cryptographique avancée. Ils demandent seulement d’être inscrits au périmètre, ce qui est précisément ce que personne ne fait.
1. Cartographier les clés et leurs détenteurs. Où est chaque clé disposant de droits sur le protocole, sous quelle forme, qui y a accès, comment elle a été générée, où se trouve sa sauvegarde. Le résultat le plus fréquent de cet exercice n’est pas de découvrir une mauvaise pratique connue mais d’identifier une clé que plus personne ne savait active — typiquement un compte de déploiement conservé après la mise en production, avec des droits d’administration intacts.
2. Vérifier que le multi-signature en est réellement un. Un dispositif à trois signataires sur cinq ne protège que si les signataires constituent des cibles indépendantes. Lorsqu’ils travaillent dans le même bureau, sur des machines administrées de la même façon, avec la même messagerie et les mêmes habitudes, une compromission unique de poste peut en atteindre plusieurs. La séparation affichée est alors une illusion comptable.
3. Inventorier les dépendances, en incluant l’infrastructure hors chaîne. Bibliothèques, oracles, services d’indexation, nœuds fournis par un tiers, outils de déploiement. Pour chacun, trois questions : peut-il se mettre à jour automatiquement sans notre intervention ? Que se passe-t-il s’il devient indisponible ou renvoie des données fausses ? Qui, chez le fournisseur, peut modifier ce que nous exécutons ? L’arrêt de MANTRA le 21 août est exactement le scénario que cette question doit rendre visible avant qu’il ne survienne.
4. Écrire la procédure de réaction. Qui décide d’une mise en pause du protocole, en combien de temps, avec quelles clés, et par quel canal de communication si les canaux habituels sont compromis. C’est le volet le plus systématiquement absent et le moins coûteux à produire : une page suffit. Les équipes de WebGuard Agency font la même observation hors du champ crypto — le facteur décisif pendant un incident n’est presque jamais l’outillage, mais l’existence d’une décision déjà déléguée à l’avance.
Votre audit couvre-t-il là où l’argent part réellement ?
Nous mettons en relation les projets français avec des agences Web3 qui couvrent les quatre volets, pas seulement le code.
Discutons-enNotre avis d’expert (2/3)
Le contrôle numéro 2 est celui qui provoque le plus de résistance, parce qu’il remet en cause un dispositif dans lequel l’équipe a déjà investi et qu’elle présente à ses investisseurs comme une garantie. Dire à un fondateur que son multi-signature 3/5 protège en réalité comme un 1/1 est une conversation désagréable. Mais l’asymétrie est trop forte pour l’éviter : le coût de la corriger est de quelques centaines d’euros de matériel et une réorganisation des rôles ; le coût de ne pas la corriger est l’intégralité des fonds.
Ce que cela change pour le marché français
Pour les agences Web3 françaises, ce déplacement est une nouvelle plutôt favorable, à condition de l’anticiper. Les quatre contrôles ci-dessus ne relèvent pas de la recherche en cryptographie ; ils relèvent de la sécurité opérationnelle classique, un domaine où les compétences existent en France en abondance, y compris hors du secteur crypto.
Concrètement, une agence capable de proposer une mission couvrant les quatre volets se différencie immédiatement d’un cabinet d’audit de code, sur un périmètre où la demande va mécaniquement croître à mesure que ces chiffres se diffusent. Et pour les projets soumis au cadre MiCA, l’articulation est directe : les exigences en matière de dispositifs de sécurité et de continuité portent précisément sur cette zone opérationnelle, pas sur la qualité du code.
Le côté moins confortable, c’est que cela suppose d’élargir une compétence commerciale autant que technique. Vendre un audit de smart contract est simple : le livrable est connu, le prix est comparable, l’acheteur sait ce qu’il achète. Vendre une revue de gestion des clés demande d’expliquer d’abord pourquoi elle est nécessaire — et c’est exactement à cela que sert le chiffre de 44 %.
Notre avis d’expert (3/3)
Notre recommandation la plus concrète tient en un exercice d’une heure, réalisable dès cette semaine et sans prestataire : réunissez les personnes qui détiennent des droits sur le protocole et faites la liste, au tableau, de toutes les clés actives et de leurs détenteurs. Ne cherchez pas à corriger quoi que ce soit pendant la séance. Contentez-vous d’établir la liste. Dans la majorité des équipes que nous accompagnons, cette heure fait apparaître au moins un accès dont personne ne se souvenait — et c’est très exactement le type d’accès par lequel sont partis les 44 %.
En résumé
Les chiffres du premier semestre 2026 ne disent pas que l’audit de smart contract est inutile. Ils disent qu’il est devenu nécessaire et très insuffisant : la profession a si bien sécurisé le code que l’attaque est allée chercher ailleurs, et « ailleurs » représente désormais près de la moitié des pertes, avec la compromission de portefeuille comme vecteur le plus coûteux.
Si vous ne retenez qu’une action de cette lecture, faites la liste de vos clés actives et de leurs détenteurs. Une heure, un tableau, aucune compétence particulière. C’est le contrôle le moins cher de tous ceux qui existent, et c’est celui qui couvre le périmètre par lequel l’argent est réellement parti cette année.
Questions fréquentes
Faut-il arrêter de faire auditer ses smart contracts ?
Non, et ce serait la mauvaise conclusion à tirer de ces chiffres. L’audit de code reste indispensable : les bugs de contrats continuent d’exister, ils sont irréversibles une fois exploités, et leur correction après déploiement est souvent impossible sans migration. Ce que disent les données du premier semestre 2026, c’est que l’audit de code est devenu une condition nécessaire mais très insuffisante. La profession a beaucoup progressé sur la vérification du code, au point que les attaquants ont rationnellement déplacé leur effort vers ce qui n’était pas vérifié : les clés, les accès, les dépendances et les procédures. Le bon réflexe n’est donc pas de remplacer l’audit, mais d’élargir le périmètre de la mission à ce qui entoure le contrat.
Qu’est-ce qu’une faille « opérationnelle » dans un projet Web3 ?
C’est une défaillance qui ne se trouve dans aucune ligne de code du protocole. Les cas les plus fréquents : une clé privée stockée sur un poste de travail ordinaire ou dans un gestionnaire de mots de passe partagé ; un multi-signature dont les signataires travaillent tous dans le même bureau, sur les mêmes machines, ce qui annule la séparation qu’il est censé apporter ; un compte de déploiement conservé après la mise en production alors qu’il détient encore des droits d’administration ; une dépendance externe intégrée sans vérification et mise à jour automatiquement ; ou un ancien collaborateur dont les accès n’ont jamais été révoqués. Aucun de ces points n’apparaît dans un rapport d’audit Solidity, et chacun a suffi, en 2026, à vider un protocole dont le code était pourtant sain.
Comment vérifier la sécurité des dépendances d’un projet blockchain ?
En commençant par un inventaire, ce qui paraît trivial et se révèle presque toujours instructif : la liste complète des bibliothèques et services externes dont dépend le fonctionnement du protocole, y compris les briques d’infrastructure hors chaîne comme les nœuds fournis par un tiers, les oracles, les services d’indexation et les outils de déploiement. Pour chaque élément, trois questions suffisent à faire apparaître l’essentiel du risque : cette dépendance peut-elle se mettre à jour automatiquement sans intervention de notre part ; que se passe-t-il fonctionnellement si elle devient indisponible ou renvoie des données fausses ; et qui, chez le fournisseur, peut modifier ce que nous exécutons. L’épisode MANTRA du 21 août 2026, où la production de blocs a été arrêtée après l’exploitation d’une vulnérabilité dans une dépendance externe en amont, illustre exactement ce que cet inventaire cherche à rendre visible.
Que doit contenir une mission de sécurité Web3 complète en 2026 ?
Quatre volets, dont un seul est habituellement vendu aujourd’hui. Le premier est l’audit de code des contrats, qui reste le socle. Le deuxième est la revue de la gestion des clés et des accès : où sont les clés, qui les détient, comment sont-elles générées et sauvegardées, quelle est la procédure de révocation. Le troisième est l’inventaire des dépendances et de l’infrastructure hors chaîne, avec la question de la mise à jour automatique. Le quatrième, le plus souvent absent, est la procédure de réaction : qui décide d’une mise en pause, en combien de temps, et avec quels moyens de communication si les canaux habituels sont compromis. Une mission qui couvre les quatre coûte davantage qu’un audit seul, mais elle couvre le périmètre où sont parties 44 % des pertes du semestre.