Au cours des six premiers mois de 2026, l’industrie crypto a perdu $939.86 million à travers 135 incidents de sécurité vérifiés. À première vue, l’explication peut sembler simple : les projets continuent de déployer du code non vérifié sur le mainnet, exposant les trésoreries des protocoles à des exploits bien connus.

Les données dressent toutefois un tableau beaucoup plus préoccupant.

Plus de la moitié des projets exploités, représentant plus de $721 million de pertes, avaient déjà obtenu un audit de sécurité. Pourtant, dans 94.4% de ces cas, l’exploit ne provenait pas d’une erreur de reentrancy manquée dans un smart contract examiné. Les attaquants ont plutôt emprunté des voies que les auditeurs n’avaient pas étudiées :

• Clés privées compromises
• Scripts front-end détournés
• Infrastructure cloud vulnérable
• Relayers hors chaîne non examinés

Ces conclusions proviennent d’un rapport de sécurité H1 2026 complet publié par ack3, une société de cybersécurité native IA anciennement connue sous le nom d’Ackee Blockchain Security. Depuis 2021, ack3 affirme avoir réalisé 237 revues de protocoles et avoir observé l’extension de la frontière de sécurité au-delà des fichiers Solidity isolés vers des architectures de protocole complètes. En réponse, l’entreprise combine revue manuelle, fuzzing basé sur Wake, modélisation des menaces hors chaîne et analyses IA propriétaires conçues pour cartographier les dépendances entre composants.

Le rapport met en lumière une faiblesse structurelle dans la manière dont Web3 évalue le risque : le secteur traite souvent « audité » comme un statut binaire et permanent, tandis que les attaquants considèrent les architectures de protocoles comme des services web interconnectés et en constante évolution.

« Un audit est un horodatage et une limite, pas une garantie à vie », déclare Josef Gattermayer, Founder chez ack3. « L’ancienne question était : “A-t-il été audité ?” Les questions utiles sont : “Qu’est-ce qui a exactement été audité, quand, et qu’est-ce qui a changé depuis ?” Un rapport de contrat ne peut pas protéger une clé de signature divulguée, un front-end compromis ou un déploiement hérité qui ne correspond plus au code examiné. »

Le paysage des pertes au S1 2026

Au cours du premier semestre 2026, l’écosystème de sécurité Web3 a enregistré 135 incidents de sécurité vérifiés, retirant $939.86 million aux protocoles décentralisés et à leurs utilisateurs. Chaque exploit retenu dans l’ensemble de données d’ack3 répondait à une exigence stricte de vérification par deux sources, couvrant à la fois les compromissions on-chain et off-chain.

Lorsqu’on classe ces incidents selon leur historique d’audit, la répartition initiale paraît presque équilibrée :

• Victimes auditées : 68 incidents (50.4%) visaient des projets ayant fait l’objet d’au moins une revue de sécurité terminée et publiquement vérifiable avant l’attaque.
• Victimes non auditées : 35 incidents (25.9%) ont touché des protocoles n’ayant pas subi de revue de sécurité tierce formelle.
• Statut d’audit inconnu : 32 incidents (23.7%) concernaient des projets dont l’historique d’audit n’a pas pu être confirmé à la date de clôture de l’ensemble de données.

L’illusion de l’audit

À première vue, ces chiffres pourraient laisser penser que les revues de sécurité n’offrent qu’une protection limitée. Mais lorsqu’on mesure les incidents selon les dommages financiers et non selon leur nombre, l’ampleur du problème devient plus claire.

Les protocoles audités ont représenté $721.24 million des $939.86 million perdus au S1 2026, soit 76.7% de tout le capital volé. Les projets non audités et ceux dont l’historique d’audit est inconnu ont ensemble représenté $218.62 million.

Cet écart met en évidence ce qu’ack3 appelle l’Illusion de l’audit. Le capital tend à affluer vers les projets qui affichent des badges de sécurité. Les allocateurs institutionnels, les yield farmers et les traders particuliers considèrent souvent un rapport d’audit comme un feu vert, ce qui dirige la liquidité vers des protocoles au positionnement de sécurité soigné.

Cette dynamique crée un paradoxe : les audits attirent le capital, et le capital transforme les protocoles audités en cibles de plus grande valeur. Si une revue de code rigoureuse peut décourager les attaquants opportunistes à la recherche de vulnérabilités Solidity évidentes, les acteurs sophistiqués ne s’arrêtent pas au badge d’audit. Ils déplacent leur attention des smart contracts examinés vers l’infrastructure environnante qui reste non surveillée.

Comme l’a montré le S1 2026, les attaquants n’essaient plus de forcer la porte d’entrée du code audité. Ils passent par les portes latérales qui n’ont jamais été examinées.

Le fossé de périmètre : là où $680 million ont disparu

L’une des idées reçues les plus dangereuses en matière de sécurité Web3 consiste à assimiler l’audit d’un smart contract à une protection de l’ensemble du système. En pratique, un audit couvre généralement un hash de commit précis et un ensemble défini de fichiers Solidity ou Rust. Il ne couvre pas l’environnement de déploiement, les postes de travail des développeurs, l’infrastructure cloud, les enregistrements DNS ni les clés privées utilisées pour gérer les paramètres du protocole.

Les recherches d’ack3 montrent que c’est dans cet écart — le « scope gap » — que disparaît presque tout le capital volé. Sur 68 protocoles audités compromis au S1 2026, 46 ont été touchés via des vecteurs d’attaque entièrement hors du périmètre de leurs audits publiés. Ces 46 incidents ont causé $680.97 million de pertes, soit 94.4% des dommages financiers subis par les victimes auditées.

L’écart entre le nombre et la valeur

L’écart devient encore plus net lorsqu’on compare le nombre d’incidents aux pertes financières réelles.

Les incidents dont le chemin d’exploitation se situait dans le code audité représentaient 20 des 68 compromissions auditées, soit environ 29.4% en nombre. Mais ces 20 exploits dans le périmètre n’ont rapporté aux attaquants que $35.21 million, soit seulement 4.9% de l’ensemble des pertes des victimes auditées.

L’implication est nette. Les audits de code traditionnels semblent faire un travail raisonnable pour détecter les bugs catastrophiques de smart contracts, en maintenant les pertes dans le périmètre à moins de 5% du total. Mais les équipes de protocoles laissent la porte arrière grande ouverte et perdent les 94.4% restants à cause de compromissions d’infrastructure et d’exploitation opérationnelle.

Anatomie de la surface d’attaque moderne

Les attaquants ont compris que les smart contracts sont souvent le maillon le plus solide de la chaîne, et ciblent donc de plus en plus la surface opérationnelle autour du code.

ack3 a identifié quatre vecteurs opérationnels récurrents à l’origine des drains hors périmètre :

Clés privées et autorités de signature compromises : Les clés d’administration, les signataires multisig et les hot wallets opérationnels restent la voie la plus rapide vers un drainage total. Une fois qu’une autorité de signature est compromise par phishing ou par une mauvaise gestion des clés, l’attaquant peut mettre à niveau les contrats, modifier les paramètres ou déclencher des mints d’urgence via les fonctions légitimes du protocole, en contournant totalement les contrôles logiques on-chain.

Injections de scripts front-end et détournement DNS : Plutôt que de casser la logique on-chain, les attaquants compromettent l’interface à laquelle les utilisateurs font confiance. En prenant le contrôle d’enregistrements DNS ou en injectant du JavaScript malveillant via des dépendances web tierces, ils peuvent remplacer les adresses cibles ou pousser les utilisateurs à approuver des spenders malveillants tout en interagissant avec une interface apparemment légitime.

Pipelines CI/CD et identifiants d’infrastructure cloud : Les chemins d’attaque passent de plus en plus par GitHub Actions, les variables d’environnement cloud et les pipelines de build. Des secrets codés en dur ou des clés API divulguées peuvent permettre aux attaquants de modifier les artefacts de build ou d’accéder aux actifs d’infrastructure avant même que le code n’atteigne la blockchain.

Provers, relayers et infrastructures cross-chain hors chaîne non examinés : Les protocoles DeFi modernes dépendent fortement de composants hors chaîne, notamment les provers, les relayers d’oracle, les séquenceurs zero-knowledge et les passerelles de messagerie cross-chain. Ces services complexes se situent en dehors des audits de contrats standard, alors même qu’ils déterminent les entrées qui déclenchent l’exécution on-chain. Lorsqu’un relayer ou un prover échoue, le contrat on-chain traite simplement la mauvaise mise à jour d’état comme demandé.

Assurance ponctuelle et problème d’usure

Même lorsqu’un exploit touche du code qui faisait explicitement partie du périmètre d’un audit, les données d’ack3 indiquent une autre faiblesse des pratiques de sécurité Web3 : la dégradation de l’assurance.

Un rapport d’audit n’est pas un bouclier continu ; c’est une capture statique d’un système à un moment donné. Pourtant, les protocoles présentent régulièrement des rapports PDF vieux de deux ans comme s’ils constituaient une preuve de sécurité actuelle. Les recherches d’ack3 montrent qu’avec le temps, la valeur protectrice d’une revue historique diminue progressivement, même si la logique sous-jacente du smart contract n’a pas changé.

Le taux de dégradation de la sécurité

Parmi les 20 incidents où le chemin d’attaque se situait directement dans le périmètre audité d’un protocole, 17 se sont produits au moins six mois après l’audit le plus pertinent. Le délai médian entre la date d’audit et l’exploit était de 18 mois, avec des écarts allant de trois mois à 56 mois.

Seuls trois protocoles ont subi des exploits dans le périmètre dans les six mois suivant la réception d’un rapport d’audit. La grande majorité des défaillances dans le périmètre sont survenues longtemps après la revue initiale :

• Moins de 6 mois : 3 incidents (15% des cas dans le périmètre)
• 6 à 24 mois : 9 incidents (45%)
• 24 mois ou plus : 8 incidents (40%)

Cette répartition souligne une conclusion évidente : la pertinence d’un rapport d’audit se dégrade rapidement dans un écosystème en mouvement rapide. L’ancienneté seule ne crée pas un bug de smart contract, mais elle mesure la durée pendant laquelle le code reste exposé tandis que tout ce qui l’entoure évolue. C’est pourquoi il est important que les protocoles crypto fassent réaliser plusieurs audits régulièrement et ne s’appuient pas sur un audit vieux de 2 ans.

L’IA comme multiplicateur d’attaque et le passage à une assurance vivante

Les outils d’IA spécialisés ont durablement modifié la vitesse et l’échelle de la recherche en sécurité. Même si l’ensemble de données H1 2026 d’ack3 n’attribue aucun incident spécifique à des agents IA autonomes, il met en évidence un changement du paysage des menaces : les attaquants utilisent l’IA comme multiplicateur opérationnel.

La nouvelle réalité de la menace

Trouver un bug de reentrancy complexe dans un contrat Solidity largement examiné demande encore beaucoup de temps et d’expertise. En revanche, repérer une clé d’enclave exposée dans un dépôt hors chaîne non indexé ou identifier un script tiers non épinglé dans un pipeline de build front-end nécessitait autrefois une reconnaissance manuelle fastidieuse.

Les modèles d’IA ont réduit ce coût temporel à presque zéro.

Les attaquants utilisent désormais des outils IA pour ingérer rapidement des écosystèmes de protocoles entiers, cartographier les relations entre dépôts, suivre les flux de paramètres hors chaîne vers on-chain et sonder les zones de jonction entre l’infrastructure cloud, les réseaux de distribution front-end et les smart contracts.

Avec des benchmarks comme EVMbench qui mesurent activement les agents IA sur la détection de vulnérabilités, le correctif automatisé et la synthèse d’exploits, l’avantage asymétrique revient à celui qui scanne le plus vite la surface la plus large. Si les défenseurs limitent leur vision à un répertoire de smart contracts, les attaquants assistés par IA trouveront souvent les vulnérabilités opérationnelles environnantes en premier.

Remplacer l’artefact PDF

L’habitude du secteur de considérer un rapport d’audit PDF statique comme une accréditation de sécurité permanente constitue désormais, selon ack3, un risque existentiel. Un document statique ne peut pas avertir une équipe lorsqu’un développeur commite un secret API dans un dépôt public, ni évaluer le comportement d’un smart contract après qu’un pool de liquidité amont a modifié sa structure de frais.

Pour survivre dans un écosystème où les vecteurs d’attaque traversent les frontières entre composants à une vitesse pilotée par l’IA, les protocoles doivent passer des revues ponctuelles à une assurance vivante. ack3 décrit trois piliers essentiels pour cette transition :

Les défenseurs doivent remplacer les listes statiques de contrats par un registre actif, en temps réel, de l’ensemble de la surface système. Cela implique de consigner en continu :

• Les déploiements de smart contracts on-chain et les adresses de proxy
• L’infrastructure hors chaîne, les relayers, les provers et les pipelines d’oracle
• Les rôles administratifs, les signataires multisig et les schémas de gestion des clés
• Les dépendances web, les CDN et les pipelines de build front-end

L’assurance ne doit pas être renouvelée selon un calendrier annuel rigide, ni être considérée comme permanente. Les protocoles ont besoin de déclencheurs opérationnels explicites qui signalent immédiatement un code ou une infrastructure pour une révision ciblée, notamment :

• Le déploiement de nouvelles implémentations de proxy ou des mises à jour de paramètres
• Les rotations de clés, les transferts de rôles administratifs ou les changements de seuil multisig
• L’intégration de nouvelles passerelles cross-chain, de nouveaux flux d’oracle ou de protocoles de liquidité amont
• La découverte de nouvelles classes d’attaque ou de nouveaux vecteurs d’exploitation dans des protocoles pairs

L’analyse automatisée et l’expertise humaine doivent fonctionner de concert avant et après le déploiement sur le mainnet. Les scanners IA automatisés et les moteurs de fuzzing basés sur Wake sont bien adaptés à la recherche large, à l’analyse des dépendances entre composants, à la détection des dérives logiques et à la surveillance de l’infrastructure en production pour repérer des changements d’état inattendus. Les ingénieurs en sécurité interviennent ensuite pour vérifier l’exploitabilité, évaluer les modèles de menace économiques de haut niveau et valider la logique métier.

L’objectif n’est pas d’éliminer les audits, mais de faire en sorte que l’assurance suive le rythme des changements du système. Dans ce modèle, l’étiquette binaire « audité » devient ce qu’elle aurait toujours dû être : un processus continu plutôt qu’un badge statique.

Conclusion : repenser la posture de sécurité dans Web3

Les $940 million perdus au S1 2026 rendent une chose indéniablement claire : considérer un audit historique ponctuel comme un feu vert permanent relève de la négligence opérationnelle. Les smart contracts n’existent pas en vase clos. Un audit qui couvre les fichiers Solidity tout en ignorant les dépendances front-end, les clés de signature administratives, l’infrastructure cloud et les provers hors chaîne n’est pas une garantie de sécurité complète.

À mesure que l’allocation de capital dans Web3 mûrit, les mécanismes d’évaluation du risque évoluent des revues ponctuelles vers une surveillance de l’ensemble du système. L’avenir de la sécurité Web3 appartient aux équipes qui traitent l’assurance comme une discipline opérationnelle active. Celles qui continueront de se cacher derrière des rapports PDF statiques resteront simplement les cibles de plus grande valeur sur le tableau.