Le piratage de Garden Finance montre pourquoi le risque lié à la DeFi ne se limite plus au seul code

Lorsqu’un pont DeFi subit des pertes financières, on suppose généralement qu’un contrat intelligent a échoué. Une ligne de code était erronée, un contrôle de validation faisait défaut, un oracle a été manipulé, ou un attaquant a trouvé un moyen de transférer des actifs via le système que ses concepteurs n’avaient pas anticipé.

L'incident de Garden Finance met en lumière un problème plus complexe. Le pont inter-chaînes aurait perdu environ 11 millions de dollars après que l'un de ses « solvers » a été piraté. Garden a déclaré que les fonds des utilisateurs étaient en sécurité et que le « solver » concerné était distinct du protocole principal. L'équipe a temporairement suspendu son application et offert une prime de 10 % pour la restitution des fonds volés. Cet incident a été signalé en octobre 2025 et a refait surface dans des articles ultérieurs comme exemple de risque lié aux « solvers » dans le cadre des ponts inter-chaînes.

C'est généralement un élément important. Un “ bridge ” peut disposer de contrats audités, d'une interface utilisateur claire et d'un message décentralisé, tout en dépendant néanmoins de participants hors chaîne, de processus opérationnels et d'acteurs tiers que les utilisateurs comprennent à peine. Dans ce cas, le terme « solver » n'est pas une simple note de bas de page technique. C'est la question centrale.

Un « solver » est généralement un acteur qui contribue à l'exécution des transactions en fournissant des liquidités, en acheminant les ordres ou en faisant correspondre les intentions entre les différents systèmes. Dans une infrastructure basée sur les intentions et inter-chaînes, les « solvers » peuvent rendre l'expérience utilisateur plus rapide et plus fluide. L'utilisateur exprime ce qu'il souhaite voir se produire, et le système s'appuie sur des acteurs spécialisés pour y parvenir en arrière-plan.

Ce modèle est puissant. Il est également plus complexe que la simple promesse d'une finance sans tiers de confiance.

Le point faible pourrait se situer en dehors du contrat intelligent

La DeFi met souvent en avant son code. Les contrats intelligents sont transparents, vérifiables et, en théorie, prévisibles. Cela a favorisé l'idée selon laquelle le risque peut être évalué principalement en examinant la conception du protocole et la sécurité des contrats.

L'affaire Garden Finance nous rappelle que les systèmes DeFi modernes ne se résument pas à de simples contrats intelligents. Il s'agit de réseaux composés de contrats, de ponts, de relais, de solveurs, de teneurs de marché, de portefeuilles, d'interfaces, de processus de gouvernance, de services cloud, de clés privées, de signatures multiples, d'outils de surveillance et d'opérateurs humains. Une faille dans l'une de ces couches peut devenir le véritable point de défaillance.

C'est particulièrement vrai pour les ponts. Les infrastructures inter-chaînes ont toujours constitué l'un des domaines les plus complexes en matière de sécurité dans le monde des cryptomonnaies, car elles relient des écosystèmes distincts qui n'étaient pas initialement conçus pour se faire confiance mutuellement. Un pont doit vérifier qu'un événement s'est bien produit sur une chaîne, puis autoriser une action correspondante ailleurs. Cela crée une vaste surface d'attaque.

Les recherches universitaires consacrées aux piratages de ponts inter-chaînes ont maintes fois mis en évidence que ces ponts constituent des infrastructures essentielles mais vulnérables, les pertes étant liées à des failles de conception, à des défaillances de validation et à des contrôles opérationnels insuffisants. L'attaque du pont Ronin en 2022, qui a entraîné des pertes de près de 600 millions de dollars américains, reste l'un des exemples les plus marquants de l'ampleur du risque lié à ces ponts.

Mais tous les incidents liés aux ponts ne sont pas uniquement dus à une exploitation de contrats intelligents. De plus en plus, le risque est d'ordre opérationnel : clés compromises, contrôles d'accès insuffisants, surveillance défaillante, dépendance vis-à-vis d'acteurs privilégiés ou répartition floue des responsabilités entre le protocole et les entités qui l'entourent.

C'est pourquoi l'affirmation selon laquelle “ les fonds des utilisateurs sont en sécurité ” ne met pas fin au débat. Cela peut être vrai au sens strict, dans la mesure où les dépôts n'ont pas été directement ponctionnés. Mais les utilisateurs, fournisseurs de liquidité et les contreparties doivent encore comprendre quelles parties du système comportent des risques et qui en assume la responsabilité en cas de défaillance.

Les « solvers » simplifient la DeFi, mais la rendent plus difficile à cerner

Les systèmes basés sur l'intention et les réseaux de « solvers » s'inscrivent dans une démarche plus large visant à rendre la DeFi plus accessible. Au lieu de demander aux utilisateurs de comprendre chaque itinéraire, chaque pool, chaque pont, chaque frais de gaz et chaque étape d'exécution, les protocoles peuvent leur permettre de définir le résultat souhaité. Les « solvers » entrent alors en concurrence ou interviennent pour atteindre ce résultat.

Pour l'utilisateur, cela semble plus simple. Pour l'infrastructure, c'est tout sauf simple.

Plus le système masque la complexité, plus il devient important de savoir qui effectue le travail en coulisses. Les solveurs fonctionnent-ils sans autorisation préalable ou sur autorisation ? Sont-ils financièrement responsables ? Peuvent-ils être retirés rapidement ? Que se passe-t-il si l’un d’entre eux est compromis ? Existe-t-il des limites en matière d’exposition ? Existe-t-il une surveillance indépendante ? Le protocole est-il responsable du comportement des solveurs, ou les traite-t-il comme des participants externes ?

Ces questions ne sont pas toujours visibles depuis l'interface utilisateur d'une application DeFi. Un utilisateur peut avoir l'impression que la transaction via le pont se déroule sans heurts. En coulisses, le système peut toutefois s'appuyer sur des acteurs ayant des motivations différentes, des normes de sécurité différentes et des niveaux de transparence différents.

C'est là que réside le côté dérangeant de l'affaire Garden Finance. Elle montre que la DeFi peut éloigner le risque de l'interface utilisateur sans pour autant l'éliminer du système. L'expérience peut sembler irréprochable, mais la cartographie des risques sous-jacente est peut-être plus fragmentée que ne le pensent les utilisateurs.

La question de la réputation est également sérieuse

Garden Finance avait déjà fait l'objet d'une attention particulière avant l'incident lié au « solver ». En juin 2025, ZachXBT, enquêteur spécialisé dans la blockchain, avait accusé ce pont Bitcoin de faciliter des flux liés à des fonds volés, notamment des actifs qui seraient liés au groupe Lazarus. Garden a contesté ces allégations, mais cette accusation a soulevé des questions plus larges concernant la surveillance des ponts, les flux illicites et les responsabilités des infrastructures permettant les transferts inter-chaînes.

Ce contexte est important car les ponts se situent à la croisée de la liquidité, de la rapidité et de l'anonymat. Ils sont utiles aux utilisateurs légitimes qui ont besoin de transférer des actifs d'une chaîne à l'autre. Ils constituent également une cible attrayante pour les pirates qui souhaitent transférer des fonds volés, brouiller les pistes ou tirer parti de la fragmentation des normes de conformité.

Cela ne signifie pas pour autant que tous les ponts font l'objet de négligences. Cela signifie en revanche que les exploitants de ponts doivent considérer la surveillance, la gestion des incidents et la prévention des abus comme des éléments essentiels de l'infrastructure, et non comme des questions de relations publiques à traiter après coup.

Dans le domaine de la DeFi, la réputation va de pair avec la sécurité. Un protocole peut survivre à un incident technique si les utilisateurs estiment que la réponse apportée est rapide, transparente et crédible. En revanche, il risque de rencontrer des difficultés si l’incident met en évidence des ambiguïtés quant à l’identité des responsables des différentes opérations, à l’attribution des responsabilités et à l’étendue réelle du contrôle exercé par le protocole sur le système.

Les audits sont nécessaires, mais insuffisants

Après une faille de sécurité dans le domaine de la DeFi, on a souvent tendance à réclamer davantage d’audits. C’est compréhensible. Les examens des contrats intelligents, la vérification formelle et les évaluations de sécurité externes restent essentiels. Mais l’incident de Garden Finance montre pourquoi les audits ne peuvent pas constituer la seule solution.

Un audit permet d'évaluer le code. Il peut toutefois ne pas permettre d'évaluer pleinement le comportement opérationnel des solveurs, les modalités de conservation, la gestion des clés privées, la capacité de réaction aux incidents, l'infrastructure hors chaîne ou les incitations économiques des participants externes. Même lorsque ces aspects sont examinés, ils peuvent évoluer après le déploiement.

La sécurité de la DeFi doit donc passer d'une approche fondée sur des audits ponctuels à un modèle de gestion continue des risques. Cela implique de surveiller les transactions en temps réel, de fixer des limites, de tester les contrôles opérationnels, de s'entraîner à la gestion des incidents, d'examiner les accès privilégiés et de comprendre comment les dépendances se comportent en situation de stress.

Les recherches sur les attaques visant la DeFi ont montré que ces incidents ne se limitent pas à une seule catégorie technique. Ils comprennent notamment la manipulation d’oracles, les abus en matière de gouvernance, les attaques par « flash loan », les défaillances du contrôle d’accès, la compromission de ponts et les faiblesses opérationnelles. Une revue systématique des attaques contre la DeFi réalisée en 2022 a examiné 181 incidents réels et a révélé que les schémas d’attaque concrets s’écartaient souvent des thèmes sur lesquels les travaux universitaires s’étaient principalement concentrés.

Cet écart reste d'actualité. Le risque lié à la DeFi n'est pas statique. À mesure que l'architecture évolue, la surface d'attaque évolue elle aussi.

Les questions que les utilisateurs de Bridge devraient poser

La plupart des utilisateurs ne sont pas en mesure d'examiner l'architecture technique complète d'un pont. Ils peuvent toutefois poser des questions plus pertinentes avant d'y faire transiter des montants importants.

La première question est de savoir si le pont est de type « custody-light » ou « custody-heavy ». Qui contrôle les actifs pendant leur transit ? Les fonds sont-ils bloqués, émis, acheminés, échangés ou pris en charge par des fournisseurs de liquidité ? La réponse à cette question influe sur le niveau de risque.

La deuxième question concerne la manière dont le système gère les défaillances. Si un solveur disparaît, est compromis ou refuse de régler une transaction, que se passe-t-il ? Existe-t-il un plan de secours ? Existe-t-il un fonds d'assurance ? Les utilisateurs sont-ils indemnisés ? Le protocole est-il responsable sur le plan contractuel ou économique ?

La troisième question est de savoir si le protocole fait preuve de transparence quant à l'historique des incidents et à la communication à ce sujet. Un protocole qui explique clairement ses défaillances n'est pas automatiquement plus sûr, mais la transparence permet aux utilisateurs d'être mieux informés. Le silence, les mises à jour vagues et les démentis trop catégoriques doivent être considérés avec prudence.

La quatrième question est de savoir si le pont présente un risque de concentration. Si un petit nombre de solveurs, d'opérateurs ou de clés peut avoir une incidence sur des volumes importants, le système pourrait s'avérer plus fragile que ne le laisse entendre le terme “ décentralisé ”.

La cinquième question est de savoir si l'utilisateur a réellement besoin d'utiliser un pont. De nombreuses pertes dans le domaine des cryptomonnaies sont dues au fait que les utilisateurs transfèrent des actifs vers des systèmes qu'ils ne comprennent pas, pour un gain marginal. Si la raison d'utiliser un pont n'est pas claire, le risque n'en vaut peut-être pas la peine.

Quels protocoles faudrait-il modifier ?

En matière de protocoles, l'affaire Garden Finance met en évidence une norme plus stricte.

Les réseaux de solveurs doivent être dotés d'une gouvernance plus claire. Les protocoles devraient définir les modalités d'agrément, de surveillance, de limitation et de retrait des solveurs. Si les solveurs sont présentés comme indépendants, la frontière entre le solveur et le protocole devrait être suffisamment transparente pour que les utilisateurs puissent la comprendre.

Les limites d'exposition devraient être plus strictes. Un participant malveillant ne devrait pas pouvoir détourner une somme importante avant que le système ne réagisse. La mise en place de plafonds, de dispositifs de coupure automatique et de systèmes de détection des anomalies peut permettre de limiter l'ampleur des dommages.

Il convient de s'entraîner à la gestion des incidents. Dans le domaine de la DeFi, chaque minute compte. Les protocoles doivent disposer d'un plan permettant de suspendre les interfaces utilisateur, d'alerter les utilisateurs, de retracer les fonds, de coordonner leurs actions avec les plateformes d'échange et de faire appel à des sociétés de sécurité. Une réaction improvisée peut aggraver un incident déjà grave.

La communication publique doit être précise. Les utilisateurs n'ont pas besoin de paroles rassurantes grandiloquentes. Ils ont besoin de savoir ce qui s'est passé, quels fonds sont concernés, quels risques subsistent, quels systèmes ont été mis en pause et quelles sont les prochaines mesures prévues par l'équipe.

Enfin, les protocoles doivent considérer la sécurité opérationnelle comme un élément à part entière de la qualité du produit. L'infrastructure de résolution, la gestion des clés, l'accès au cloud, les autorisations internes et les systèmes de surveillance ne sont pas des aspects secondaires du protocole. Ils font partie intégrante de la sécurité concrète du protocole.

La leçon à retenir pour la DeFi

Le piratage de Garden Finance ne figure pas parmi les incidents les plus importants de l'histoire des cryptomonnaies. Son ampleur est bien moindre que celle de l'attaque contre Ronin Bridge, de l'exploitation de Poly Network ou du vol subi par Bybit. La base de données de DeFiLlama sur les piratages fait toujours état de pertes cumulées s'élevant à plusieurs milliards de dollars liées aux incidents touchant la DeFi et les ponts de transfert, ce qui souligne à quel point le problème reste persistant.

Son importance est plus spécifique. Elle montre qu’à mesure que la DeFi devient plus abstraite et plus conviviale, les risques deviennent plus difficiles à cerner. L'utilisateur n'interagit peut-être plus directement avec chaque étape technique, mais quelqu'un ou quelque chose continue d'exécuter ces étapes. Si cet acteur est compromis, sous-capitalisé, mal surveillé ou mal géré, le système peut tomber en panne même si l'expérience utilisateur semble irréprochable.

C'est là le prochain défi pour l'infrastructure DeFi. De meilleures interfaces ne suffiront pas. Des solveurs plus efficaces ne suffiront pas. Des ponts plus rapides ne suffiront pas. Le secteur a besoin d'une responsabilité plus clairement définie pour la couche opérationnelle qui se situe entre les utilisateurs et les protocoles.

La promesse de la DeFi a toujours été que les utilisateurs ne devraient pas avoir à dépendre d'intermédiaires opaques. Mais lorsque les ponts dépendent de « solvers », de « relayers » et d'opérateurs hors chaîne, le secteur doit reconnaître en toute honnêteté à quel moment la confiance est réintroduite dans le système.

L'incident de Garden Finance nous rappelle que la décentralisation n'est pas qu'une simple étiquette. Il s'agit d'une architecture de risque. Si cette architecture continue de dépendre d'acteurs privilégiés, le modèle de sécurité doit en tenir compte. Sinon, la DeFi continuera à tirer la même leçon après chaque exploitation : le point faible ne se trouve pas toujours dans le code. Parfois, il se situe dans la partie du système que tout le monde considérait comme une simple infrastructure.