Un exploit draine 4 M$ sur Solana : le développeur Rust est-il responsable ?

Le schéma se répète à chaque cycle de marché. Un protocole de staking déployé sur Solana détient 4 millions de dollars d'actifs déposés par ses utilisateurs. Un attaquant repère qu'une instruction de retrait ne vérifie pas que le compte signataire est bien le propriétaire du dépôt. Il forge une transaction, substitue son propre compte à celui de la victime, et déclenche le retrait. En moins d'une minute, la trésorerie est vidée et les fonds transitent vers un mixeur. Sur une blockchain, il n'y a pas de retour arrière : pas de chargeback, pas de gel bancaire, pas de service fraude à appeler.

Pour le studio Web3 client, le coupable technique est vite identifié. L'analyse de la transaction malveillante révèle qu'une ligne de validation manquait dans le programme Anchor. Et cette ligne, c'est vous qui auriez dû l'écrire. La question n'est plus « que s'est-il passé » mais « qui paie ».

La particularité du Web3, c'est la transparence radicale. Contrairement à un bug dans un back-office d'entreprise qui reste enfoui dans des logs privés, une faille on-chain est publiquement et définitivement traçable. N'importe quel expert peut rejouer la transaction, lire le programme déployé et démontrer la cause racine.

Les fautes les plus fréquemment retenues contre un développeur Rust Web3 sont identifiables et nommées :

• Signer check manquant : l'instruction ne vérifie pas is_signer, permettant à n'importe qui d'agir au nom d'un autre compte.
• Owner check absent : le programme ne contrôle pas que le compte appartient au bon program ID, ouvrant la porte à un account substitution.
• Validation Anchor incomplète : les contraintes has_one, constraint ou seeds mal posées dans la structure Accounts.
• Arithmétique non vérifiée : un overflow non géré qui fausse un calcul de récompenses ou de collatéral.

Quand l'expert mandaté par l'adversaire pointe l'une de ces erreurs, il ne s'agit pas d'une opinion : c'est une démonstration reproductible. C'est ce qui rend le risque juridique du développeur Web3 si singulier par rapport à d'autres métiers du développement.

En droit français, votre responsabilité de prestataire s'apprécie d'abord à l'aune de votre obligation. La distinction est décisive :

Obligation de moyens : vous vous engagez à mettre en œuvre les bonnes pratiques de l'art (revues, tests, conformité aux standards Anchor/Substrate). Obligation de résultat : vous garantissez un code exempt de toute faille — un engagement que peu de développeurs raisonnables acceptent.

La plupart des prestations de développement relèvent de l'obligation de moyens. Mais attention : si votre devis ou vos échanges promettent un code « sécurisé », « audité » ou « production-ready », vous risquez de glisser vers une obligation de résultat que vous ne pourrez pas tenir face à un exploit.

Le juge — ou l'arbitre, fréquent dans le Web3 — examinera ensuite si la faille relevait de l'état de l'art au moment de la livraison. Un signer check oublié est une faute caractérisée : c'est une règle de base documentée partout. À l'inverse, l'exploitation d'une vulnérabilité inconnue d'un compilateur ou d'une primitive cryptographique nouvelle sera bien plus difficile à vous imputer.

Une erreur récurrente détruit la défense des développeurs : la confusion entre développer et auditer. Ce sont deux missions distinctes, avec deux niveaux de responsabilité radicalement différents.

Si votre contrat porte sur l'écriture du programme, vous devez livrer un code conforme à l'art mais le client reste responsable de faire auditer son protocole avant le déploiement mainnet — c'est la norme du secteur. Si en revanche vous avez signé une mission d'audit de sécurité, vous garantissez avoir cherché les failles, et en laisser passer une engage lourdement votre responsabilité.

D'où trois réflexes contractuels indispensables :

1. Délimiter le périmètre par écrit : « développement du programme » ≠ « audit de sécurité ». Précisez ce que vous ne couvrez pas.
2. Recommander explicitement un audit tiers avant tout déploiement mainnet, et tracer cette recommandation par écrit.
3. Plafonner votre responsabilité contractuellement, dans la limite de ce que le droit autorise face à une faute lourde.

Sans ces garde-fous, vous endossez par défaut une présomption de faute que l'analyse on-chain rendra très difficile à renverser.

Face à un exploit chiffré en millions, la première vague de coûts n'est pas la restitution des fonds : ce sont les frais de défense. Avocats spécialisés, experts blockchain pour le contre-rapport technique, frais de procédure ou d'arbitrage : la facture peut atteindre des dizaines de milliers d'euros avant même qu'une responsabilité soit tranchée.

L'assurance RC Pro adaptée au développement Rust Web3 prend en charge ces frais de défense ainsi que l'indemnisation due au titre de votre faute professionnelle, dans la limite du plafond souscrit. Pour ce métier, les plafonds usuels vont de 500 K€ à 2 M€ selon le chiffre d'affaires et la criticité des protocoles développés.

En revanche, il faut être lucide sur les limites :

• La restitution intégrale des fonds drainés appartenant aux utilisateurs reste plafonnée et conditionnée — aucune RC Pro ne transforme un dommage de 4 M$ en chèque automatique.
• La faute intentionnelle (porte dérobée, rug pull) est exclue de toute couverture.
• Le code et l'environnement de développement, eux, relèvent d'autres garanties : la fuite de code propriétaire ou la compromission de votre poste se traitent côté assurance cyber.

La logique est simple : la RC Pro vous protège contre les conséquences de vos fautes professionnelles vis-à-vis du client, pas contre l'irréversibilité de la blockchain. C'est précisément pour cela que le cadrage contractuel et l'assurance fonctionnent en binôme.

Le développeur Rust Web3 évolue dans un environnement où la moindre erreur est publique, irréversible et chiffrée. Trois réflexes réduisent drastiquement votre exposition :

1. Documenter votre processus qualité : revues de code, suite de tests, fuzzing, conformité aux audits Anchor/Substrate. En cas de litige, prouver que vous avez respecté l'état de l'art renverse la présomption de faute.
2. Cadrer chaque mission par écrit : périmètre, obligation de moyens, recommandation d'audit tiers, plafond de responsabilité.
3. S'assurer avant la première signature : la plupart des studios Web3 et des programmes de grants exigent désormais une attestation RC Pro comme prérequis contractuel.

Dans un secteur où un signer check oublié peut coûter quatre millions, l'assurance n'est pas une formalité administrative : c'est le filet qui sépare une erreur de code d'une faillite personnelle.