9 principes d'ingénierie des systèmes décentralisés qui changent radicalement l'analyse juridique des smart contracts, de la blockchain et de la DeFi.
Les juristes (et les médias) traitent l'immutabilité de la blockchain comme un absolu. Les ingénieurs savent que c'est une décision de conception avec des compromis.
Les upgradeable proxy contracts (UUPS, Transparent Proxy) sont le standard de l'industrie en production. Le smart contract « immutable » pointe en réalité vers une implémentation qui peut être remplacée par l'administrateur. Cela réintroduit l'hypothèse de confiance que la blockchain était censée éliminer.
La question fondamentale : Qui détient les clés d'administration ? Un wallet multisig ? Un vote DAO ? Un seul développeur ? La réponse détermine si « code is law » s'applique réellement.
Pleinement immutable
Gouvernance DAO
Admin-upgradeable
Contrôle central
🟢 Bitcoin — Le protocole le plus immutable. Aucune entité ne peut modifier les règles sans consensus quasi-unanime des nœuds. Le code déployé est le code exécuté. C'est le seul cas où « code is law » s'approche de la réalité.
« Quand un juriste dit "le smart contract est immutable", un ingénieur demande "quelle couche ?" Le code peut être immutable, mais le proxy peut être mis à jour, l'oracle peut être manipulé, et la gouvernance peut être capturée. L'immutabilité est une propriété d'une couche technique spécifique, pas du système. »
L'industrie crypto vend des systèmes « trustless ». Les ingénieurs qui les construisent savent que la réalité est plus nuancée.
Les développeurs principaux proposent, les détenteurs de tokens votent, mais ce sont les opérateurs de nœuds qui décident in fine quel code exécuter. C'est un processus politique habillé en langage technique.
Les juristes comprennent la séparation des pouvoirs. En crypto, la séparation est entre les concepteurs du protocole (législatif), les validateurs (exécutif) et la résolution de litiges (judiciaire). Mais contrairement aux démocraties, la même entité contrôle souvent les trois.
Flash loan governance attack : Emprunter des millions en tokens de gouvernance, voter, les rendre — le tout en une seule transaction. Vous avez contrôlé la gouvernance « démocratique » pendant 12 secondes.
L'apathie des votants : La plupart des détenteurs de tokens ne votent pas. Un petit groupe coordonné peut faire passer n'importe quelle proposition.
Le cas Eisenberg/Kleros : L'attaque d'Eisenberg contre Kleros suivait exactement ce schéma — la capture économique d'un mécanisme de résolution de litiges « trustless ».
Beaucoup de protocoles « décentralisés » ont une équipe centrale qui peut mettre en pause les contrats, mettre à jour les implémentations, ou blacklister des adresses. C'est souvent nécessaire (pour la sécurité), mais ça contredit le discours « trustless ».
C'est comme une startup avec des étapes supplémentaires — pas de la décentralisation.
« Les juristes comprennent la séparation des pouvoirs. En crypto, la séparation est entre concepteurs (législatif), validateurs (exécutif), et résolution de litiges (judiciaire). Mais souvent, la même entité contrôle les trois. Ce n'est pas de la décentralisation — c'est une startup avec des étapes supplémentaires. »
Les juristes supposent que « code audité = code sûr ». Les ingénieurs savent que c'est loin d'être le cas.
❌ Les défauts de conception économique (l'attaque d'Eisenberg était économiquement rationnelle, pas un bug de code)
❌ Les vecteurs de manipulation d'oracle
❌ Les risques de composabilité inter-protocoles
❌ Les scénarios de marché extrêmes
✓ Les schémas de vulnérabilité connus
✓ Les erreurs logiques dans le code
✓ Le contrôle d'accès
✓ La conformité aux standards (ERC-20, etc.)
Tous avaient été audités par des cabinets de premier plan. Les audits sont un effort limité dans le temps par des humains qui lisent le code d'autres humains.
« Quand un juriste demande "le contrat a-t-il été audité ?", la question de suivi de l'ingénieur est : "par qui, pendant combien de temps, et par rapport à quelle spécification ?" Un audit n'est pas un certificat de conformité — c'est un best effort limité dans le temps. »
Le cycle de vie que les juristes ne voient jamais — et qui détermine si « code is law » s'applique véritablement.
Décrit le mécanisme — souvent idéalisé, parfois trompeur. C'est du marketing, pas de la spécification.
Formalise les règles — souvent incomplète. Les cas limites sont rarement documentés.
Le code réel — qui peut diverger de la spécification. Les développeurs font des choix que la spec ne prévoyait pas.
Tests unitaires, tests d'intégration, fuzzing. La couverture n'est jamais 100 %.
Revue par un tiers — garantie limitée (voir section précédente).
Le code va sur la blockchain. Sur quelle chaîne ? Quel réseau ? Testnet d'abord ?
Code publié sur Etherscan — mais qui vérifie qu'il correspond au bytecode déployé ?
Clés d'administration transférées au multisig/DAO — ou pas.
Watchtowers, circuit breakers, fonctions de pause d'urgence. La « loi » a un bouton d'arrêt d'urgence.
« Les juristes lisent le whitepaper et pensent comprendre le protocole. Les ingénieurs savent que le whitepaper est du marketing. La vérité est dans le bytecode déployé — et même celui-ci peut être derrière un proxy. »
Cette distinction technique entre bug applicatif et exploit de protocole est cruciale — et le droit actuel ne la fait pas.
Le code a un bug — il fait quelque chose que le développeur n'avait pas prévu.
Cas : L'attaque Platypus par flash loan — la fonction de retrait ne vérifiait pas correctement les soldes.
Analogie juridique : « accès non autorisé » — le système a dysfonctionné.
Le code fonctionne exactement comme prévu, mais la conception a une faille économique exploitable.
Cas : Mango Markets (Eisenberg) — il a manipulé le prix oracle, et le protocole a correctement exécuté sa logique basée sur le prix (manipulé).
Analogie juridique : « lacune législative » — la loi fonctionne comme écrite, mais le résultat n'est pas celui voulu par le législateur.
Les protocoles DeFi interagissent entre eux. Un exploit peut impliquer l'utilisation de la sortie du Protocole A comme entrée du Protocole B d'une manière que ni l'un ni l'autre n'avait anticipée. Aucun protocole individuel n'a de bug — c'est la composition qui crée la vulnérabilité. Qui est responsable ?
« Eisenberg n'a pas trouvé un bug. Il a trouvé une faille dans le design économique. Le code a fonctionné parfaitement. C'est comme trouver une lacune dans un texte de loi — la loi fonctionne telle qu'écrite, mais le résultat n'est pas celui voulu par le législateur. Les juristes devraient immédiatement reconnaître ce schéma. »
Le crypto a développé son propre cadre quasi-juridique pour gérer les vulnérabilités. Le droit n'a pas encore rattrapé cette réalité.
Signaler en privé, laisser le temps de corriger
Exploiter pour prouver, puis rendre les fonds
Exploiter d'abord pour protéger les fonds
Exploiter et garder les fonds
Mohamed M. a découvert une vulnérabilité, l'a exploitée pour prouver qu'elle était réelle (en prenant des fonds), puis a proposé de les rendre contre une récompense. Est-ce de la divulgation responsable avec preuve de concept, ou de l'extorsion ? Le tribunal l'a acquitté — mais la loi n'a pas encore formalisé cette distinction.
« Le système juridique voit un binaire : légal ou illégal. L'industrie crypto a développé un gradient : divulgation responsable → grey hat → exploit → attaque. Le tribunal Platypus a essentiellement reconnu ce gradient en acquittant — mais la loi n'a pas encore rattrapé pour le formaliser. »
Chaque action on-chain coûte du gas (frais de transaction). Cela crée un seuil économique minimum pour la résolution de litiges.
Déposer un litige, soumettre des preuves, voter en tant que juré, exécuter une décision — tout cela coûte de l'argent en gas. En dessous d'un certain montant, le coût de la résolution dépasse le montant en litige.
C'est fonctionnellement équivalent à un seuil de saisine — un montant minimum de compétence juridictionnelle.
Les solutions Layer 2 (Arbitrum, Optimism, Base) réduisent les coûts de 10 à 100 fois, rendant les petits litiges économiquement viables.
« En droit traditionnel, l'accès à la justice est un droit (Art. 6 CEDH). Dans les systèmes on-chain, l'accès à la justice a un coût en gas. Cela crée un déni de justice de facto pour les litiges de faible valeur si l'infrastructure ne devient pas moins chère. C'est un problème d'ingénierie avec des conséquences juridiques. »
Les premiers litiges Kleros ont révélé que ce qui est « évident » dépend du contexte culturel. Un litige de curation s'est divisé selon les lignes culturelles — différentes communautés avaient des standards implicites différents. Le point de Schelling ne fonctionne que s'il EXISTE un point focal partagé.
Quand Eisenberg a tenté de capturer les pools de jurés Kleros, l'équipe a dû regarder les mécanismes de défense du protocole fonctionner (ou échouer) en temps réel. Le système d'appel multi-tours a tenu — mais c'était un test de résistance qu'aucune simulation n'aurait pu reproduire.
Quand les jurés votent systématiquement « contre » la politique écrite d'un tribunal Kleros, est-ce la politique qui est mauvaise ou les jurés qui ont tort ? Ce débat de gouvernance reflète exactement la tension entre la lettre et l'esprit de la loi.
Plusieurs acteurs du crypto qui défendent publiquement « code is law » ont menacé ou engagé des poursuites judiciaires quand les résultats du code leur étaient défavorables. Eisenberg est l'exemple le plus célèbre, mais pas le seul. L'hypocrisie est systématique, pas anecdotique.
Deux professions qui posent fondamentalement la même question avec des outils différents.
| 🔧 L'ingénieur s'inquiète de... | ⚖️ Le juriste s'inquiète de... |
|---|---|
| Attaques par ré-entrance | Juridiction compétente |
| Manipulation d'oracle | Loi applicable |
| Optimisation du gas | Accès à la justice |
| Gestion des clés privées | Chaîne de responsabilité |
| Risques de composabilité | Conformité réglementaire |
| Sécurité des mises à jour | Protection du consommateur |
| MEV (valeur extractible par les mineurs) | Respect du contradictoire |
| Sécurité des bridges cross-chain | Exécution des décisions |
| 🤝 Préoccupation commune : « Le mécanisme incite-t-il au bon comportement ? » | |
Les deux professions font fondamentalement de la conception de mécanismes — créer des systèmes de règles et d'incitations qui produisent les résultats souhaités. La différence est le medium (code vs. langage naturel) et le mécanisme d'exécution (auto-exécution vs. pouvoir étatique).
« Je m'inquiète des attaques par ré-entrance. Vous vous inquiétez de la juridiction. Nous posons la même question : "Que se passe-t-il quand quelqu'un interagit avec notre système d'une manière que nous n'avions pas anticipée ?" Nous avons juste des outils différents. Vous avez des juges. J'ai des audits. Ni l'un ni l'autre ne suffit seul. »