Les rapports de sécurité du troisième trimestre 2026 racontent une histoire plus intéressante qu’un simple montant de pertes.
Selon Hacken, environ 1,18 milliard de dollars auraient été dérobés lors de 107 incidents entre juillet et septembre, soit une progression de 55 % par rapport au trimestre précédent. Le rapport attribue 48 % des pertes aux failles de smart contracts et 40 % aux défaillances de contrôle d’accès et aux problèmes opérationnels.
CertiK utilise une méthodologie différente et présente un total d’environ 1,28 milliard de dollars de pertes brutes sur le trimestre, en recensant davantage de catégories d’incidents.
Les écarts entre ces chiffres proviennent notamment des méthodes de classification : récupération des fonds, phishing, compromission de wallets et pertes directement subies par les protocoles ne sont pas forcément comptabilisés de la même manière.
Au-delà du chiffre, une tendance se dégage : les défaillances de sécurité Web3 ne se concentrent plus dans une seule couche technique.
Les smart contracts ne représentent qu’une partie du système
Pendant des années, le secteur a appris à ses équipes qu’un smart contract non audité constituait un risque majeur.
Cette leçon demeure valable.
Le problème apparaît lorsque certaines organisations transforment « obtenir un audit » en programme de sécurité complet.
Un système crypto moderne dépend également :
- des pipelines CI/CD ;
- des registres de dépendances et de paquets ;
- des comptes cloud ;
- des infrastructures de validation ;
- des interactions entre navigateurs et wallets ;
- des clés d’administration privilégiées ;
- des fournisseurs RPC ;
- des systèmes de signature ;
- de solutions tierces de sécurité ;
- de bridges et de relayers.
Un audit de smart contracts peut être excellent sans apporter la moindre garantie sur un identifiant de déploiement volé ou un service de validateur exposé sur Internet.
Le risque traverse les couches techniques
La répartition des incidents du T3 établie par Hacken est notable parce que les exploits de smart contracts et les défaillances opérationnelles représentent tous deux des catégories importantes.
Les équipes doivent donc traiter au moins deux familles de risques très différentes.
La première pose la question :
« Un attaquant peut-il amener le code à réaliser une opération que le protocole n’avait pas prévue ? »
La seconde demande :
« Un attaquant peut-il devenir, imiter ou contrôler une personne ou un système déjà autorisé par le protocole ? »
Ces risques nécessitent des mesures distinctes.
La vérification formelle ne sécurise pas à elle seule un compte administrateur dont le mot de passe a été divulgué. Une signature matérielle ne corrige pas une erreur logique dans le vérificateur d’un bridge.
Une architecture de sécurité doit couvrir les deux.
Une correction publiée mais non déployée laisse la faille ouverte
Hacken a relevé que, dans plusieurs incidents significatifs du trimestre, des correctifs publics existaient avant l’exploitation.
Cela rappelle que la divulgation d’une correction et son déploiement effectif sont deux événements différents.
Dès qu’un correctif devient public, un attaquant peut s’en servir pour identifier les installations n’ayant pas encore été mises à niveau.
Les organisations doivent donc disposer d’une procédure de gestion des correctifs :
- suivre les avis de sécurité des dépendances utilisées ;
- déterminer précisément quelles versions sont déployées et concernées ;
- tester la correction ;
- planifier la mise à jour selon la possibilité réelle d’exploitation et non uniquement selon la commodité ;
- vérifier que la production utilise effectivement la version corrigée.
La gestion des mises à jour est une composante à part entière de la sécurité crypto.
Les audits ponctuels présentent une faiblesse structurelle
Un audit apporte une réponse encadrée sur un périmètre et une version donnés, à une date donnée.
Or la production évolue sans cesse.
De nouvelles fonctionnalités arrivent. Les dépendances sont mises à jour. L’infrastructure est déplacée. Les rôles changent. Des intégrations sont ajoutées. Des exceptions temporaires finissent parfois par devenir permanentes.
Un modèle de sécurité mature doit donc compléter l’audit initial par une assurance continue adaptée aux changements.
Cette assurance peut inclure :
- des revues à chaque mise en production importante ;
- des tests automatisés de non-régression ;
- la surveillance des dépendances ;
- des scans externes de surface d’attaque ;
- des revues périodiques des clés et rôles ;
- la détection des dérives de configuration ;
- le suivi d’invariants on-chain ;
- des exercices de simulation d’incident.
Le but n’est pas d’auditer intégralement chaque système chaque jour. Il est de déclencher des vérifications proportionnées lorsque le risque change réellement.
Mesurer la qualité des contrôles, pas seulement le nombre d’incidents
Un protocole peut n’avoir subi aucun incident tout en restant fragile.
Des indicateurs plus utiles comprennent :
- la part des comptes privilégiés protégés par une authentification forte ;
- le délai entre un avis critique et le déploiement du correctif ;
- la proportion d’infrastructures de production couvertes par une surveillance extérieure ;
- l’ancienneté des clés administratives inutilisées ;
- le nombre de modifications non revues touchant aux signatures ou aux retraits ;
- le temps de restauration d’un validateur ou d’un signataire ;
- la proportion de secrets disposant d’une procédure de renouvellement documentée.
Ces mesures évaluent la capacité de défense avant qu’une perte ne survienne.
Ce que GLOV retient du troisième trimestre
Ce bilan conforte un principe commun à GLOV Secure et Snow-Fall : la sécurité est une propriété de l’ensemble du système.
Pour la custody, elle inclut la seed, le matériel, la sauvegarde, les approbations et les procédures de transmission.
Pour les validateurs, elle inclut les clés, les machines, les interfaces réseau, la surveillance et la réponse aux incidents.
Pour les produits Web3, elle inclut les contrats, l’infrastructure, les dépendances, les opérateurs et la gouvernance.
Une architecture robuste ne suppose pas qu’un contrôle restera infaillible. Elle cherche à limiter les conséquences lorsqu’il échoue.
GLOV Secure accompagne la réflexion sur les architectures de sécurité et de custody. GLOV Consulting aide les projets à structurer leurs contrôles opérationnels avant qu’ils ne deviennent des urgences.
Note méthodologique
Les fournisseurs de renseignement de sécurité n’utilisent pas tous les mêmes définitions d’incident ni les mêmes règles comptables.
Hacken annonce environ 1,18 milliard de dollars pour 107 incidents. Le tableau de bord de CertiK indique environ 1,28 milliard selon sa propre méthodologie.
Ces séries peuvent être utiles pour identifier des tendances, mais il ne faut pas les additionner ni prétendre qu’elles constituent un recensement exhaustif de toutes les pertes crypto.