« Code is law » : qui paie quand votre smart contract immuable fait perdre des fonds ?

Depuis les premiers smart contracts Ethereum, une formule s'est imposée dans la culture web3 : « code is law ». L'idée est séduisante — ce qui est inscrit dans le code fait foi, l'exécution est automatique, neutre, indépassable. Beaucoup de développeurs en tirent une conclusion dangereuse : si le contrat s'est exécuté comme programmé, même en cas de bug, personne ne pourrait être tenu responsable.

C'est une erreur de raisonnement. Le « code is law » décrit une réalité technique (le code s'exécute sans intervention humaine), pas une réalité juridique. Devant un tribunal français, ce n'est pas la blockchain qui dit le droit, mais le Code civil. Et celui-ci ne reconnaît ni l'immuabilité, ni l'automatisation comme cause d'exonération de la responsabilité du prestataire.

Le smart contract est, juridiquement, un livrable comme un autre. Le fait qu'il soit écrit en Solidity plutôt qu'en Java ne change rien à votre obligation de le livrer exempt de défauts.

La nuance à garder en tête : un « smart contract » n'est généralement pas un contrat au sens juridique. C'est un programme. Le vrai contrat, celui qui vous lie à votre client, c'est votre devis, votre cahier des charges et vos CGV. C'est ce contrat-là qui sera lu en cas de litige.

Toute la question de votre responsabilité se joue sur une distinction du droit français : êtes-vous tenu d'une obligation de moyens ou d'une obligation de résultat ?

• Obligation de moyens : vous vous engagez à mettre en œuvre toute la diligence et le savoir-faire attendus d'un professionnel compétent. Si un dommage survient, c'est au client de prouver que vous avez commis une faute (négligence, code non audité, pattern vulnérable connu non corrigé).
• Obligation de résultat : vous garantissez un résultat précis. Si ce résultat n'est pas atteint, votre faute est présumée. Le client n'a rien à prouver : il lui suffit de constater l'échec.

Le développement informatique relève traditionnellement de l'obligation de moyens, souvent qualifiée de renforcée compte tenu de la technicité attendue. Mais attention : un contrat mal rédigé peut vous faire basculer en obligation de résultat sans que vous vous en rendiez compte. Une phrase comme « le smart contract sera sécurisé et exempt de toute vulnérabilité » dans une proposition commerciale est une promesse de résultat. En web3, où aucun code n'est garanti exempt de faille, c'est une promesse intenable.

La règle d'or : promettez du savoir-faire, des bonnes pratiques, un processus d'audit — jamais une sécurité absolue. Pour comprendre comment ces clauses interagissent avec votre couverture, voyez notre checklist d'audit avant déploiement.

Dans le développement web classique, un bug se corrige : on pousse un correctif, on redéploie, le préjudice est souvent contenu. En web3, un smart contract déployé sur une chaîne publique est, par construction, immuable. Le bug n'est pas « corrigeable » au sens habituel : il faut migrer, geler le contrat, déployer une nouvelle version et orchestrer une transition complexe — quand c'est techniquement possible.

Conséquence juridique majeure : le caractère irréversible transforme un défaut potentiellement rattrapable en préjudice définitif. Les fonds bloqués dans un contrat verrouillé ou siéphonnés par un attaquant ne reviennent pas. Le dommage est immédiatement liquide, chiffrable au centime, et souvent considérable.

C'est précisément ce qui distingue votre métier des autres profils de la Numérique & IT : l'erreur ne coûte pas un correctif, elle coûte la valeur gérée par le contrat. Un développeur web qui livre une faille XSS expose des données ; un développeur blockchain qui livre une faille de reentrancy expose une trésorerie entière, instantanément.

Le cadre réglementaire européen s'est durci avec le règlement MiCA (Markets in Crypto-Assets), entré en application progressive depuis 2024. S'il vise d'abord les émetteurs et prestataires de services sur crypto-actifs, il relève le niveau d'exigence attendu sur la sécurité et la robustesse technique des dispositifs sous-jacents — dont les smart contracts.

En France, le régime PSAN (Prestataire de Services sur Actifs Numériques) supervisé par l'AMF impose à vos clients prestataires des obligations de sécurité informatique. Lorsque vous développez pour un acteur régulé, ces obligations se répercutent contractuellement sur vous : votre client vous transmettra des exigences d'audit, de traçabilité et de gestion des clés. Un manquement à ces exigences devient une faute caractérisée, plus facile à démontrer pour celui qui vous attaque.

Le mouvement de fond est clair : la blockchain sort de la zone grise. Plus le secteur se régule, plus le standard du « professionnel diligent » monte, et plus l'amateurisme technique se requalifie facilement en faute professionnelle indemnisable.

Face à cette exposition particulière, la responsabilité civile professionnelle est votre socle. Elle intervient lorsqu'un client engage votre responsabilité pour un préjudice causé par votre prestation.

Un point essentiel souvent sous-estimé : même si vous êtes finalement reconnu non responsable, les frais de défense sont réels et immédiats. Une expertise technique sur un exploit de smart contract coûte cher, et la procédure peut durer. La RC Pro porte ce coût à votre place.

Pour les scénarios où la perte vient d'une intrusion ou d'une faille de sécurité exploitée plutôt que d'une erreur de conception pure, une garantie Cyber complète utilement le dispositif — nous détaillons cette articulation dans notre analyse d'un exploit chiffré.

Vous ne pouvez pas garantir un code parfait. Vous pouvez en revanche maîtriser votre exposition juridique :

1. Cadrez vos engagements par écrit. Un cahier des charges précis, des CGV qui plafonnent votre responsabilité et qualifient clairement une obligation de moyens : c'est votre première ligne de défense.
2. Documentez votre diligence. Conservez la trace de vos tests, de vos audits, des avertissements transmis au client. En obligation de moyens, c'est cette traçabilité qui démontre l'absence de faute.
3. Assurez ce que vous ne pouvez pas éliminer. Le risque résiduel — le bug que personne n'a vu, la faille zéro-day — ne disparaît jamais. La RC Pro est là pour absorber le choc financier quand la prévention n'a pas suffi.

Le « code is law » restera un bon slogan d'ingénieur. Mais votre véritable filet de sécurité, c'est un contrat bien rédigé et une couverture adaptée — pas une formule.