Sécurité des ponts cross-chain : vérifier plutôt que croire

Un pont cross-chain ne détient jamais très longtemps l’argent qu’on lui confie, et c’est précisément le problème. Chaque mois, plus de 10 milliards de dollars transitent par les grands corridors inter-chaînes, selon une analyse de Yellow, le temps qu’un actif quitte une blockchain pour en rejoindre une autre. Ce passage, en apparence anodin, est devenu le point le plus attaqué de toute la finance décentralisée.

Les chiffres sont têtus. En mai 2026, les ponts ont représenté environ 42 % des pertes du mois liées aux exploits, rapporte la même étude, alors qu’ils n’immobilisent qu’une petite fraction de la valeur totale verrouillée en DeFi. Un ratio resté obstinément élevé depuis 2022. Et le hack le plus coûteux de l’année, les 252 millions d’euros (292 M$) envolés du pont de KelpDAO en avril, n’a impliqué aucun bug de code.

C’est tout le paradoxe de la sécurité des ponts en 2026 : le danger ne vient presque jamais de la ligne de Solidity qu’un auditeur aurait manquée, mais de la confiance accordée à un petit groupe de signataires, de serveurs ou de clés. Cet article explique comment un pont établit (ou non) cette confiance, pourquoi elle casse, et pourquoi les capitaux migrent aujourd’hui, à hauteur de près de 15 milliards de dollars, vers des systèmes conçus pour vérifier au lieu de croire sur parole.

Pourquoi un pont existe (et pourquoi c’est un problème)

Chaque blockchain est un registre souverain et isolé. Ethereum ne sait pas, nativement, ce qui se passe sur Solana, Arbitrum ou Bitcoin ; un smart contract sur une chaîne ne peut pas lire l’état d’une autre. Or les utilisateurs veulent déplacer leurs actifs partout : mettre de l’ETH au travail sur un layer 2, apporter des stablecoins à un protocole sur une autre chaîne, faire circuler du Bitcoin dans la DeFi. Le pont est la pièce d’infrastructure qui promet de rendre cela possible.

Dans sa forme la plus répandue, un pont fonctionne par verrouillage et émission (lock-and-mint). Vous déposez 10 ETH dans un contrat sur la chaîne de départ ; le pont les verrouille, puis émet 10 ETH enveloppés sur la chaîne d’arrivée. Ces jetons enveloppés ne sont que des reconnaissances de dette : ils valent quelque chose uniquement parce que l’on croit que les 10 ETH d’origine restent bien verrouillés, et qu’on pourra les récupérer. Certaines architectures brûlent et réémettent l’actif (burn-and-mint), d’autres n’émettent rien du tout et s’appuient sur des réserves de liquidité approvisionnées des deux côtés.

Le point commun de toutes ces variantes est une faille conceptuelle : la chaîne d’arrivée ne peut pas constater elle-même le dépôt effectué sur la chaîne de départ. Quelqu’un, ou quelque chose, doit le lui affirmer. Ce «quelqu’un» est le cœur du problème de sécurité. Tout ce qui suit dans cet article découle de cette question simple : à qui, ou à quoi, le pont demande-t-il de garantir qu’un événement a bien eu lieu sur une autre chaîne ?

Le vrai risque n’est pas le code, ce sont les clés

L’intuition commune veut qu’un hack soit une faille de code : une fonction mal écrite, un débordement, une vérification oubliée. La réalité de 2026 est différente. Dans son bilan du premier semestre, TRM Labs a recensé 207 hacks pour environ 972 millions de dollars (840 M€) dérobés, un nombre d’incidents qui a plus que doublé par rapport au premier semestre 2025, mais un montant en baisse de plus de moitié. Surtout, la répartition est éloquente : les exploits de smart contracts représentent la majorité des incidents (125 sur 207), mais une petite part de la valeur ; les compromissions d’infrastructure, de clés privées et de failles opérationnelles ne pèsent qu’environ 15 % des incidents, mais captent près de 76 % des sommes volées.

Ce déséquilibre décrit parfaitement les ponts. Presque aucun des grands piratages inter-chaînes n’a été un pur bug de Solidity. Ronin, c’est un vol de clés de validateurs. KelpDAO, c’est une infrastructure de noeuds compromise. Multichain, c’est l’effondrement d’un opérateur qui contrôlait seul les clés. Là où un contrat mal codé fait perdre quelques dizaines de milliers d’euros à un petit protocole, la compromission de la poignée de signataires qui gardent un pont fait perdre des centaines de millions. C’est le même phénomène que celui décrit dans notre analyse sur le vol de clés privées et le facteur humain : les attaquants les plus efficaces ne cassent pas la cryptographie, ils ciblent les humains et les serveurs qui la manipulent.

Pour évaluer la sécurité d’un pont, il faut donc arrêter de se demander seulement «le code est-il audité ?» et commencer par «qui peut, concrètement, autoriser un retrait, et que faudrait-il compromettre pour forger cette autorisation ?». La réponse tient dans le modèle de confiance du pont.

Les cinq modèles de confiance d’un pont

Malgré une profusion de marques et de jetons, la quasi-totalité des ponts se ramène à cinq grandes familles, selon la manière dont ils prouvent qu’un événement s’est produit sur une autre chaîne. Comprendre ces familles est le meilleur raccourci pour juger un pont en quelques minutes.

Le multisig fédéré confie l’approbation des transferts à un petit comité de signataires : compromettez assez de clés, et vous videz le pont. Le réseau d’attestation externe élargit ce comité à des dizaines de validateurs ou d’oracles qui attestent l’événement, mais la logique reste la même. Le modèle optimiste présume qu’un transfert est valide sauf contestation dans un délai imparti. Le client léger, ou la validité par preuve à divulgation nulle (ZK), fait vérifier à la chaîne cible une preuve cryptographique de l’état source : c’est le plus proche d’une vérification réelle, et le plus difficile à construire. Enfin, le réseau de liquidité n’émet aucun actif enveloppé et s’appuie sur des solveurs qui avancent la liquidité.

Aucun de ces modèles n’est intrinsèquement sûr ou dangereux dans l’absolu. Ce qui compte, c’est la distance entre la promesse marketing («décentralisé», «sans confiance») et la réalité : combien d’entités indépendantes faudrait-il réellement corrompre pour forger un transfert frauduleux ? Souvent, la réponse est bien plus petite que ce que le nom du produit laisse croire.

Ce qu’un pont vérifie vraiment (ou pas)

La formule la plus juste sur le sujet vient de Ben Fisch, PDG d’Espresso Systems, à propos de l’affaire KelpDAO. Interrogé par CoinDesk, il résume : «La plupart des ponts ne vérifient pas complètement ce qui s’est passé sur une autre chaîne. Ils s’appuient plutôt sur un système plus restreint pour le leur rapporter.» Et de conclure, sur le hack lui-même : «Le pont a fonctionné comme prévu. Il a simplement cru la mauvaise information.»

Cette phrase capture la différence entre attester et vérifier. Un réseau d’attestation dit «nous, les validateurs, affirmons que le dépôt a eu lieu» ; il faut lui faire confiance. Un client léger ou une preuve ZK dit «voici la preuve mathématique, vérifiable par n’importe qui, que le dépôt a eu lieu» ; il n’y a plus rien à croire. Les ponts qui attestent sont plus simples et moins chers à construire, ce qui explique leur domination ; ils reportent simplement le risque sur la qualité et l’indépendance de leur comité.

On peut décomposer la surface d’attaque d’un pont en trois couches. La couche de consensus concerne la manière dont les validateurs se mettent d’accord sur un message : c’est là que se logent les compromissions de clés et les collusions. La couche de transport concerne l’acheminement du message entre les chaînes : c’est là qu’on falsifie une signature ou qu’on injecte un faux message. La couche applicative concerne le contrat qui reçoit et exécute : c’est là que vivent les bugs de code classiques. Les hacks les plus coûteux frappent les deux premières couches, celles où l’audit de code ne va pas.

Anatomie des grandes défaillances

L’histoire des ponts est une bibliothèque de cas d’école, et presque tous confirment la thèse des clés plutôt que du code. En 2022, Chainalysis avait chiffré à environ 2 milliards de dollars les vols liés aux ponts sur la seule année, soit près de 69 % de toute la crypto volée cette année-là. La tendance ne s’est pas démentie : les données Immunefi pour 2024 attribuaient encore 1,19 milliard de dollars de pertes aux ponts et aux protocoles de messagerie inter-chaînes, rappelle Yellow.

Regroupés par cause racine, les grands incidents dessinent un schéma clair. Côté multisig : Ronin, le plus gros vol crypto de l’histoire (environ 540 M€, soit 625 M$), où le groupe Lazarus a compromis les clés de validateurs via une fausse offre d’emploi piégée, selon CoinDesk ; et Harmony, dont le seuil de 2 signatures sur 5 rendait le pont trivial à vider. Côté attestation : Wormhole, où une fonction de vérification obsolète a permis de forger une fausse approbation de garde et de dérober environ 281 M€ (325 M$), documenté par Halborn. Côté code : Nomad, dont la racine de confiance initialisée à zéro a transformé le pont en pillage collectif où des centaines d’inconnus recopiaient la transaction de l’attaquant, un épisode que Mandiant a qualifié de vol décentralisé ; et Poly Network, où des droits d’appel privilégiés détournés ont permis de vider plus de 527 M€ (610 M$), disséqué par Kraken. Côté opérateur : Multichain, qui n’était pas un exploit mais un effondrement, l’équipe ayant perdu l’accès à une infrastructure MPC contrôlée par un seul homme.

Un cas fait figure d’exception instructive : le BNB Bridge, en octobre 2022, où une preuve forgée a permis d’émettre des jetons pour environ 489 M€ de valeur faciale (566 M$). Le petit ensemble de validateurs de la chaîne a pu la stopper en quelques heures, gelant la majeure partie du butin ; seuls quelque 100 M$ ont vraiment quitté le réseau. La même centralisation qui faisait de ce pont une cible est aussi ce qui a permis d’endiguer les dégâts. La sécurité des ponts est faite de ces arbitrages inconfortables.

KelpDAO : le hack qui a fait basculer 2026

Le 18 avril 2026, un attaquant a détourné 116 500 rsETH, soit environ 252 M€ (292 M$), sur le déploiement de KelpDAO adossé à LayerZero. C’est le plus gros exploit DeFi de l’année, et le cas le plus important à comprendre, parce qu’il ne ressemble en rien à un piratage classique. Aucun contrat n’a été cassé. Les attaquants ont compromis l’infrastructure RPC interne qui alimentait le vérificateur (DVN) de LayerZero pour ce déploiement, tout en saturant de trafic les fournisseurs RPC externes, puis ont usurpé un message inter-chaînes. La configuration en cause, un DVN unique (1-de-1), suffisait à valider le transfert dès lors qu’on contrôlait ce seul vérificateur.

S’en est suivie une bataille d’imputation instructive, rapportée par CoinDesk : LayerZero affirme que Kelp avait manuellement rétrogradé sa sécurité vers un vérificateur unique, hors du périmètre de son programme de primes ; Kelp répond que cette configuration était de fait validée par LayerZero au moment du déploiement. Ce désaccord illustre un angle mort récurrent : la sécurité d’un pont dépend d’un paramétrage que peu d’utilisateurs voient, et dont la responsabilité, une fois le vol commis, n’est claire pour personne. Sergej Kunz, cofondateur de 1inch, le formule sans détour dans le même dossier : «La sécurité n’est souvent pas la priorité. Les équipes se concentrent sur un lancement rapide.»

L’affaire n’a pas fini de résonner pour deux raisons. D’abord, l’attribution : TRM Labs relie environ 643 M$ (555 M€) de vols du semestre à des acteurs liés à la Corée du Nord, dont deux opérations d’avril, Drift et KelpDAO, pour près de 577 M$ (499 M€) à elles seules. Ensuite, le dénouement, rare bonne nouvelle : une coalition d’acteurs DeFi a reconstitué l’adossement du rsETH en quelques semaines, en deux tranches, selon Incrypted, de sorte qu’aucune perte n’a été répercutée sur les utilisateurs finaux. Le marché rsETH d’Aave a absorbé une dette douteuse chiffrée de façon variable selon les sources, entre 177 et 190 M$, preuve que la contagion d’un actif enveloppé peut se propager bien au-delà du pont d’origine.

La fuite vers la vérification : près de 15 milliards vers CCIP

La conséquence la plus lourde de KelpDAO n’est pas le montant, c’est le déplacement de capitaux qu’il a déclenché. LayerZero a relevé ses minimums de vérificateurs, écartant les configurations 1-de-1 en production. Puis les grands émetteurs ont commencé à voter avec leurs actifs. Dès la mi-mai, environ 4 milliards de dollars d’actifs (Lombard, Solv, le kBTC de Kraken) avaient basculé de LayerZero vers le protocole d’interopérabilité de Chainlink, le CCIP.

Le mouvement s’est amplifié tout l’été. Le 4 août 2026, BitGo a annoncé faire du CCIP son unique fournisseur d’interopérabilité pour environ 7,3 milliards de dollars de Wrapped Bitcoin (WBTC), portant à près de 15 milliards de dollars (environ 13 milliards d’euros) le total des actifs annoncés en migration vers Chainlink, en comptant Mantle, Kelp, Lombard, Solv, Virtuals, Re et Kraken. En quelques mois, la valeur en jeu a plus que triplé.

Que cherchent ces émetteurs ? De la redondance. Le CCIP sécurise chaque corridor avec un réseau de plus de seize opérateurs de noeuds indépendants et un réseau distinct de gestion du risque (Risk Management Network) qui surveille les transferts en parallèle. La philosophie est résumée par le cofondateur de Chainlink, Sergey Nazarov, dans les documents de conception du CCIP : une défense en profondeur, pas une confiance aveugle. La leçon de KelpDAO tient en une phrase : un seul vérificateur, aussi réputé soit-il, est un point de défaillance unique, et les capitaux institutionnels ne veulent plus en dépendre. Cet appétit de sécurité est parlant : l’argent institutionnel arbitre d’abord le risque de garde et d’infrastructure, avant le rendement.

Multi-DVN, réseaux de validation et le coût de la sécurité

La réponse technique à KelpDAO porte un nom : la multiplication et l’indépendance des vérificateurs. L’architecture V2 de LayerZero permet désormais de configurer un schéma dit «X de Y sur N» : sur N vérificateurs disponibles, il faut Y attestations dont X obligatoires pour valider un message. La documentation de LayerZero illustre l’écart : une configuration légère de 1/1/1 peut convenir à un NFT de faible valeur, mais un trésor de DAO devrait exiger un schéma du type 5/20/25, c’est-à-dire vingt attestations parmi vingt-cinq vérificateurs, dont cinq imposées.

Cette gradation révèle la vraie contrainte de la sécurité des ponts : elle a un coût, en argent et en latence. Chaque vérificateur supplémentaire ajoute des frais et allonge le délai de finalisation d’un transfert. Un pont sûr est donc plus lent et plus cher qu’un pont laxiste, et c’est exactement pour cela que tant d’équipes choisissent, par défaut, la configuration minimale : elle offre la meilleure expérience utilisateur apparente, jusqu’au jour où elle est exploitée. Le paramétrage 1-de-1 de KelpDAO n’était pas une négligence isolée, c’était l’optimum local d’un marché qui récompensait la vitesse.

Pour l’utilisateur, la conséquence pratique est qu’un pont ne se juge pas au nombre de validateurs annoncés, mais au nombre de validateurs réellement indépendants et au seuil réellement exigé. Vingt validateurs qui partagent la même infrastructure cloud ou le même opérateur ne valent pas beaucoup mieux qu’un seul. L’indépendance, pas le nombre brut, est la variable qui compte.

Vérifier avec des maths : light clients, ZK et transferts natifs

La direction de long terme est claire, même si elle avance lentement : remplacer la confiance par la vérification cryptographique. Un client léger fait exécuter, sur la chaîne cible, une version allégée de la vérification de consensus de la chaîne source, de sorte que la cible constate elle-même la validité d’un événement. Les preuves à divulgation nulle de connaissance (ZK) poussent l’idée plus loin en compressant cette vérification en une preuve courte et bon marché à vérifier. C’est l’approche de systèmes comme l’IBC dans l’écosystème Cosmos ou des zkBridges. Le coût de mise en oeuvre reste élevé, et l’implémentation d’un vérificateur ZK est elle-même une surface d’attaque, mais la propriété visée, ne plus rien avoir à croire, est la seule qui coupe le problème à la racine.

Une autre voie consiste à supprimer l’actif enveloppé. Le protocole CCTP de Circle brûle l’USDC natif d’un côté et le réémet nativement de l’autre, sans jamais créer de reconnaissance de dette enveloppée : il n’y a pas d’USDC verrouillé à voler, donc pas de trésor de pont à piller. Les réseaux d’intentions et de solveurs, comme Across, réduisent quant à eux la confiance à un cautionnement économique : un solveur avance les fonds et se fait rembourser après coup, en prenant lui-même le risque de finalité.

Reste la question de fond, posée dès janvier 2022 par Vitalik Buterin. Dans un fil resté célèbre, le cofondateur d’Ethereum soutenait qu’«il existe des limites fondamentales à la sécurité des ponts» qui franchissent plusieurs «zones de souveraineté». Sa thèse : un avenir multi-chaînes, oui, mais pas cross-chain, parce qu’un actif natif d’une chaîne est toujours plus sûr sur cette chaîne que sa version enveloppée ailleurs. Quatre ans plus tard, la migration vers des vérificateurs redondants et des transferts natifs ressemble moins à une réfutation de Buterin qu’à une capitulation partielle devant sa mise en garde. La même exigence de vérification irrigue d’ailleurs le hors-EVM, comme le montre notre passage en revue des auditeurs Solana et Move.

Blanchiment : où vont les fonds après le vol

Un hack de pont ne s’arrête pas au moment du vol ; il se prolonge dans le blanchiment, et cette phase est devenue un terrain d’analyse on-chain à part entière. Historiquement, la route de sortie passait par Tornado Cash. Le Trésor américain a d’ailleurs sanctionné le mélangeur en août 2022 en citant nommément plus de 7 milliards de dollars blanchis, dont des fonds issus de Ronin, Harmony et Nomad. Les mêmes techniques de traçage servent à détecter d’autres fraudes DeFi, comme le détaille notre guide sur la détection d’un rug pull par la forensique on-chain.

L’histoire réglementaire de Tornado Cash offre un enseignement plus large. En novembre 2024, une cour d’appel a jugé que l’Office de contrôle des avoirs étrangers avait outrepassé son autorité en sanctionnant des contrats immuables que personne ne contrôle une fois déployés ; le Trésor a retiré Tornado Cash de sa liste noire en mars 2025, rapporte Forbes. La propriété même qui rend un pont difficile à sécuriser, l’absence d’opérateur une fois le code déployé, le rend aussi difficile à sanctionner après coup. En 2026, les blanchisseurs se sont d’ailleurs déplacés vers d’autres rails, notamment NEAR Intents et Zcash, forçant les enquêteurs à courir derrière une cible mouvante.

Ce que dit la régulation : AMF, MiCA, DORA

Côté français et européen, le cadre s’est durci en 2026, mais il touche les prestataires plus que les protocoles. La période transitoire permettant aux prestataires de services sur actifs numériques (PSAN) enregistrés d’opérer avant l’agrément MiCA complet a pris fin le 1er juillet 2026. Depuis, l’AMF rappelle que fournir un service non conforme est une infraction pénale, passible de deux ans d’emprisonnement et de 30 000 euros d’amende. Au niveau prudentiel, l’article 75 de MiCA fixe un régime de responsabilité pour les prestataires, et le règlement DORA impose des exigences de résilience opérationnelle sur les systèmes informatiques.

Le hic, pour les ponts, est que beaucoup d’entre eux n’ont pas de prestataire clairement identifiable à agréer. Un pont réellement décentralisé, sans opérateur qui contrôle les clés, échappe largement à la logique d’un régime pensé pour des intermédiaires. Les autorités l’ont compris et concentrent leur action sur ce qu’elles peuvent atteindre : les points de garde centralisés, les plateformes d’échange, et les individus. Sur ce dernier point, la justice a d’ailleurs été plus efficace que les sanctions contre des protocoles, avec par exemple l’extradition vers les États-Unis d’un suspect clé du hack de Nomad. Pour suivre l’agenda des échéances qui pèsent sur le secteur, notre compte à rebours réglementaire récapitule les dates à surveiller.

Comment évaluer un pont avant de l’utiliser

Toute cette analyse se ramène à une grille de lecture pratique. Avant de faire transiter des fonds par un pont, qu’on soit un particulier ou un protocole qui intègre l’actif enveloppé dans ses propres marchés, quelques questions séparent un système robuste d’un pari.

• Le modèle de confiance : qui peut, techniquement, déplacer les fonds ? Un comité, un réseau d’attestation, ou une preuve mathématique ?
• La taille ET l’indépendance de l’ensemble de vérificateurs : une configuration 1-de-1 est un signal d’alarme ; cherchez plusieurs vérificateurs qui ne partagent ni infrastructure ni opérateur.
• Les clés d’administration : existe-t-il un timelock, un multisig, un délai avant qu’une mise à jour de contrat prenne effet, ou une clé unique peut-elle tout changer d’un coup ?
• L’historique d’audits ET d’incidents : un audit ne couvre que le code ; observez comment le protocole a réellement réagi à un incident passé.
• Natif contre enveloppé : un transfert natif (burn-and-mint façon CCTP) supprime le risque de la reconnaissance de dette enveloppée.
• La valeur en transit : ne laissez pas dormir de gros montants sur un pont ; c’est un lieu de passage, pas un coffre.
• Le plan de secours : en cas de hack, qui rembourse ? Un bilan solide, une prime white-hat, une coalition, ou personne ?

La quatrième question mérite une insistance particulière. Un audit réussi ne dit rien des clés, de l’infrastructure ou de la configuration des validateurs, précisément les angles morts qui concentrent l’essentiel des pertes. Nous détaillons les limites de cette assurance dans notre décryptage de CertiK et de ce qu’un audit ne couvre pas. La règle finale est peut-être la plus simple : traitez tout actif enveloppé comme une créance sur un tiers, pas comme du cash, et dimensionnez votre exposition en conséquence.

Foire aux questions

Qu’est-ce qu’un pont cross-chain et pourquoi présente-t-il un risque ?

Un pont cross-chain relie deux blockchains qui ne peuvent pas se lire nativement. Il verrouille des actifs d’un côté et en émet une version enveloppée de l’autre. Le risque vient du fait que la sécurité repose sur un petit groupe de validateurs ou de clés, pas sur la blockchain elle-même ; compromettez ce groupe, et vous compromettez tous les fonds en transit.

Pourquoi les ponts cross-chain se font-ils autant pirater ?

Parce que la valeur y est concentrée et que la sécurité dépend souvent de quelques signatures. En 2026, environ 76 % des montants volés proviennent de compromissions de clés ou d’infrastructure, pas de bugs de code, selon TRM Labs. Les ponts cumulent une forte valeur en transit et un modèle de confiance réduit à une poignée d’acteurs.

Quel a été le plus gros hack de pont en 2026 ?

Le vol de 116 500 rsETH sur le pont de KelpDAO, le 18 avril 2026, soit environ 252 millions d’euros (292 M$). L’attaquant n’a pas exploité un bug de contrat : il a falsifié un message inter-chaînes en compromettant l’infrastructure d’un unique vérificateur (une configuration 1-de-1).

Un pont audité est-il sûr ?

Pas nécessairement. Un audit réduit le risque de bug de code, mais ne couvre ni les clés, ni l’infrastructure, ni la configuration des validateurs. La plupart des grands hacks de ponts visaient justement ces angles morts, pas le code audité. L’audit est une condition nécessaire, jamais suffisante.

Comment réduire le risque quand on utilise un pont ?

Privilégiez les ponts à plusieurs vérificateurs indépendants, les transferts natifs (comme le CCTP de Circle) plutôt que les actifs enveloppés, vérifiez les clés d’administration et le passif d’incidents, et ne laissez pas dormir de gros montants en transit. Un pont est un lieu de passage, pas un lieu de stockage.

Par Élodie Rambaud, rédaction sécurité on-chain, HOGE Wire.