On présente souvent les bridges comme de simples smart contracts permettant de déplacer des actifs entre blockchains.
Cette description est trop réductrice.
Un bridge est avant tout un système de vérification distribué. Il doit déterminer si un événement observé dans un premier domaine de sécurité peut être considéré comme suffisamment fiable pour produire un effet dans un second.
Les incidents récents montrent à quel point cette décision peut échouer de manières différentes.
Trois incidents, trois couches de défaillance
L’actualité d’octobre permet une comparaison instructive.
L’incident NEAR Intents concernait une vulnérabilité dans les interactions entre un système de dépôt et de retrait cross-chain et son infrastructure de smart contracts.
L’exploitation de Mezo veBTC résultait de l’interaction entre la résolution de l’identité de l’émetteur d’une meta-transaction et des bibliothèques Solidity externes. L’attaquant a ensuite transféré les actifs détournés vers une autre chaîne.
L’incident SKALE IMA Bridge a mis en évidence la compromission d’infrastructures de validation dont certains services internes étaient accessibles depuis l’extérieur, faute d’isolation réseau suffisante.
Il ne s’agit pas de la même vulnérabilité.
C’est précisément ce qui les rend intéressants à comparer.
Les architectures cross-chain peuvent échouer aux frontières du code, de l’identité, des machines et des procédures opérationnelles.
Une étude récente souligne les difficultés de vérification
Une étude académique publiée en octobre 2026 a analysé 588 rapports d’audit, portant sur 36 projets de bridges cross-chain réellement déployés.
Les auteurs y ont recensé 830 occurrences de vulnérabilités de vérification cross-chain, regroupées en 11 schémas au sein de cinq grandes catégories.
Ils ont également constaté une couverture limitée de ces catégories par plusieurs méthodes automatisées de détection. Dans leur évaluation, le meilleur résultat obtenu par un modèle de langage atteignait environ 51,2 % de Macro-F1 sur la taxonomie proposée.
Une étude isolée ne permet pas de conclure que tous les bridges sont vulnérables. Les scores d’un benchmark ne doivent pas non plus être extrapolés hors de son protocole expérimental.
Mais ce jeu de données soutient une observation importante : la vérification entre blockchains constitue un problème de sécurité à part entière, pas seulement un audit classique de smart contracts réalisé sur plusieurs réseaux.
Que doit réellement vérifier un bridge ?
À un niveau général, un système cross-chain doit répondre correctement à plusieurs questions.
L’événement sur la chaîne source a-t-il réellement eu lieu ?
La réponse peut s’appuyer sur des preuves cryptographiques, des signatures, des relayers, des guardians ou des validateurs.
La bonne personne a-t-elle autorisé l’opération ?
L’identité de l’émetteur devient délicate lorsque les forwarders, l’account abstraction, les proxies ou les exécutions déléguées entrent en jeu.
Le message est-il récent et utilisable une seule fois ?
Les protections contre le rejeu doivent empêcher qu’un message pourtant valide soit accepté plusieurs fois ou dans un contexte non prévu.
L’effet sur la destination correspond-il à l’intention d’origine ?
Le montant, le type d’actif, le destinataire, la blockchain et les données d’appel doivent rester liés de manière non ambiguë.
Les systèmes produisant les preuves sont-ils dignes de confiance ?
Une signature mathématiquement valide démontre qu’un signataire a signé. Elle ne démontre pas que son infrastructure était saine ni que le message soumis à sa signature était légitime.
C’est à cette frontière que la sécurité des bridges rejoint celle des validateurs.
Validité cryptographique et validité du sens ne sont pas identiques
Cette distinction revient régulièrement dans les incidents réels.
Un message signé peut être cryptographiquement valide tout en n’étant pas autorisé du point de vue du protocole.
Une transaction peut s’exécuter exactement comme le code le prévoit et violer malgré tout les règles de propriété attendues.
Un validateur peut être en ligne et signer correctement alors que sa machine est compromise.
Les audits doivent donc poser deux questions complémentaires :
« Cette preuve est-elle valide ? »
et
« Cette preuve signifie-t-elle réellement ce que le système croit qu’elle signifie ? »
Concevoir des limites au périmètre des dommages
Aucun dispositif de vérification ne devrait supposer que ses contrôles seront toujours parfaits.
Plusieurs mécanismes peuvent contribuer à limiter les pertes :
- limites de débit et de fréquence ;
- plafonds de retrait ;
- coupe-circuits propres à chaque chaîne ;
- surveillance indépendante des anomalies ;
- délais sur les transferts de forte valeur ;
- diversification des guardians ou des validateurs ;
- séparation des domaines d’infrastructure ;
- procédures de suspension d’urgence ;
- gouvernance explicite pour la récupération.
Ces mesures peuvent limiter les dommages pendant que la cause profonde reste inconnue.
Elles créent aussi un risque de gouvernance : les pouvoirs d’urgence peuvent être mal utilisés. La réponse n’est pas nécessairement de les supprimer, mais de définir qui peut les exercer, dans quelles circonstances et sous quel contrôle.
Un audit de bridge doit suivre le message d’un bout à l’autre
Une revue de bridge ne devrait pas s’arrêter au dépôt Git d’un seul contrat.
Il faut aussi examiner :
- les contrats de la chaîne source ;
- les contrats de la chaîne destination ;
- les logiciels de relayer et de guardian ;
- les infrastructures hébergeant les signataires ;
- les fournisseurs RPC ;
- la sérialisation des messages ;
- les droits de mise à jour ;
- les procédures d’exploitation et de crise.
L’hypothèse la plus dangereuse peut se trouver entre deux dépôts logiciels, et non dans une fonction isolée.
Pourquoi ce sujet dépasse les seuls bridges
On retrouve les mêmes questions dans les réseaux d’intents, les systèmes d’abstraction blockchain et les architectures associant agents logiciels et signatures.
Plus les utilisateurs voient une interface simplifiée, plus l’infrastructure doit prendre des décisions complexes pour leur compte.
Il devient alors encore plus important de documenter les frontières de confiance.
Pour les projets qui conçoivent ou intègrent une infrastructure cross-chain, GLOV Consulting peut accompagner la cartographie des dépendances. Les audits GLOV Secure peuvent examiner les garanties de sécurité entre contrats, opérateurs et infrastructure.