Qu’est-ce qu’un contrat intelligent, et qu’est-ce qui peut mal tourner ?

Le contrat intelligent est l’un des termes les plus trompeurs de la crypto, car il emprunte un mot juridique pour désigner quelque chose qui n’est pas, à proprement parler, un contrat. C’est un programme stocké sur une blockchain qui s’exécute automatiquement lorsque certaines conditions sont remplies, sans qu’une banque, un courtier, ou un tribunal n’intervienne. Cette automatisation constitue l’attrait, et c’est aussi la source de la majeure partie du risque. Ce guide explique ce que fait réellement un contrat intelligent, où cette idée est utilisée en pratique, et les principales catégories de choses qui tournent mal lorsque le code ne se comporte pas comme ses auteurs l’avaient prévu.

Ce qu’est réellement un contrat intelligent

Une fois le nom mis de côté, un contrat intelligent est un logiciel déployé sur une blockchain, le plus souvent Ethereum ou un réseau programmable similaire. Une fois déployé, son code se trouve à une adresse fixe et ne peut généralement pas être modifié, à moins que les développeurs n’aient intégré à l’avance un mécanisme de mise à niveau spécifique. N’importe qui peut lui envoyer une transaction, et le réseau de validateurs exécute le code exactement comme il est écrit, mettant à jour en conséquence l’état partagé de la blockchain. Il n’y a pas de service client et, dans la plupart des cas, aucun moyen d’annuler un résultat une fois qu’il a été confirmé.

Cela diffère fondamentalement d’un accord traditionnel. Un contrat papier décrit une intention en langage naturel, et un tribunal ou un arbitre interprète cette intention en cas de litige. Un contrat intelligent n’a pas d’interprète. Il fait exactement ce que dit son code, même lorsque cela diverge fortement de ce que les parties pensaient qu’il se passerait. L’expression « le code fait loi », populaire aux débuts d’Ethereum, capture cela littéralement : le résultat est ce que le programme calcule, pas ce que quiconque estime être juste. En pratique, cette idée a de vraies limites, que les sections suivantes de ce guide abordent.

Où les contrats intelligents sont réellement utilisés

Le concept paraît abstrait tant qu’il n’est pas relié à des exemples concrets. Trois cas d’usage représentent l’essentiel de l’activité sur les blockchains programmables aujourd’hui.

• Échanges sur plateformes décentralisées. Les protocoles construits sur des modèles de teneur de marché automatisé permettent aux utilisateurs d’échanger un token contre un autre directement face à une réserve mise en commun, le taux de change étant fixé par une formule plutôt que par un carnet d’ordres. Le contrat intelligent détient les fonds et exécute l’échange en une seule transaction.
• Prêt et emprunt. Les protocoles de prêt DeFi utilisent des contrats intelligents pour accepter du collatéral, émettre des prêts, suivre les intérêts, et, si la valeur du collatéral chute trop, déclencher une liquidation automatisée, le tout sans qu’un agent de crédit n’examine la demande.
• Émission de tokens. La plupart des tokens au-delà de l’actif natif d’une blockchain, y compris la majorité des actifs construits sur Ethereum, sont eux-mêmes des contrats intelligents qui définissent l’offre, les règles de transfert, et les registres de propriété.

Dans chaque cas, l’attrait est le même : les transactions se règlent automatiquement, selon des règles publiques que chacun peut examiner à l’avance, sans exiger des participants qu’ils fassent confiance à une institution spécifique.

Les limites pratiques du « code fait loi »

Traiter le code comme la parole finale paraît net en théorie, mais se heurte à des frictions dès que le code diverge de ce que les gens avaient prévu. Un exemple largement cité est l’effondrement en 2016 d’un projet appelé The DAO, où un attaquant a exploité une faille dans la logique du contrat pour retirer une large part des fonds mis en commun en utilisant des fonctions qui, techniquement, fonctionnaient exactement comme écrites. La réponse de la communauté Ethereum, une scission de réseau controversée qui a produit Ethereum et Ethereum Classic, demeure une illustration vivante que « le code fait loi » est une philosophie de conception, pas une loi de la physique. Lorsque le résultat est suffisamment perturbateur, les participants peuvent tout de même choisir d’intervenir au niveau du réseau sous-jacent.

En dehors de tels cas extrêmes, la tension la plus courante est plus discrète. Un contrat peut s’exécuter sans faille et tout de même produire un résultat que personne ne souhaitait, parce que le code n’avait pas anticipé une séquence particulière de transactions, une condition de marché particulière, ou une combinaison particulière d’entrées. Il n’existe généralement aucune procédure d’appel intégrée pour cela.

Ce qui peut mal tourner : les principales catégories

Les signalements de défaillances de contrats intelligents tendent à se répartir en une poignée de catégories récurrentes, et les distinguer compte, car elles appellent différents types de vigilance avant de s’appuyer sur un protocole.

• Bugs et exploits. Des erreurs dans le code lui-même, comme des contrôles d’accès défaillants, des dépassements de capacité entière, ou une logique permettant d’appeler une fonction dans un ordre non prévu (un schéma à l’origine de nombreux exploits par réentrance), peuvent permettre à un attaquant de vider des fonds ou de frapper des tokens sans autorisation. Ce sont des erreurs de programmation, et une fois qu’un contrat est en ligne et immuable, elles sont souvent difficiles ou impossibles à corriger.
• Manipulation d’oracle. Les contrats intelligents ne peuvent pas voir en dehors de leur propre blockchain. Lorsqu’un contrat a besoin de données externes, comme le prix d’un actif, il s’appuie sur un service « oracle » pour lui fournir cette information. Si un attaquant peut fausser le prix rapporté par un oracle, même brièvement, il peut tromper un contrat de prêt ou de trading en lui faisant agir sur de fausses informations, une technique à l’origine de plusieurs pertes DeFi très médiatisées.
• Risque lié à la clé d’administration et aux mises à niveau. De nombreux contrats intègrent une porte dérobée par conception : une clé d’administrateur ou un portefeuille multisig capable de mettre le contrat en pause, de modifier des paramètres, ou de mettre à niveau le code. Cette flexibilité aide les équipes à corriger rapidement des bugs, mais elle signifie aussi que le système n’est pas entièrement autonome. Si cette clé est compromise, ou si l’équipe qui la détient agit avec malveillance, les utilisateurs font face à des pertes qui n’ont rien à voir avec une faille dans la logique centrale.
• Défauts de conception économique. Toute défaillance n’est pas une erreur de code. Un contrat peut être mis en œuvre exactement comme prévu et tout de même échouer parce que ses hypothèses économiques étaient erronées, par exemple une structure d’incitation qui fonctionne dans des conditions normales mais s’effondre lors d’une volatilité extrême ou d’une crise de liquidité. Cette catégorie est plus difficile à auditer, car le code n’est pas « buggé » au sens technique ; le modèle sous-jacent du comportement attendu des participants était simplement incomplet.

Audits, primes aux bugs, et leurs limites

Compte tenu de ces risques, la plupart des projets sérieux commandent un audit de sécurité tiers avant le lancement, et beaucoup font tourner des programmes continus de primes aux bugs qui rémunèrent des chercheurs indépendants pour signaler des vulnérabilités. Les deux pratiques réduisent significativement le risque. Un audit réalisé par un cabinet expérimenté détecte généralement les schémas de bugs courants, et une prime aux bugs bien financée donne aux chercheurs éthiques une incitation financière à trouver des failles avant les attaquants.

Aucune des deux ne constitue une garantie. Un audit est un examen du code tel qu’il existait à un moment précis, mené sous contraintes de temps et de budget, et il ne peut prouver l’absence de toute faille possible, seulement l’absence des failles que les examinateurs ont pensé à chercher. Des contrats ayant passé plusieurs audits ont tout de même été exploités, parfois via une vulnérabilité hors du périmètre audité, parfois via une attaque économique plutôt qu’un bug au niveau du code. Traiter un badge d’audit comme un certificat de sécurité, plutôt que comme une donnée parmi d’autres, est une erreur courante et coûteuse.

Pour quiconque utilise un protocole construit sur des contrats intelligents, une base raisonnable consiste à vérifier si le contrat a été audité, par qui, il y a combien de temps, si une clé d’administration existe et qui la contrôle, et comment le protocole a géré les périodes de tension par le passé. Rien de tout cela n’élimine le risque, mais cela remplace la confiance aveugle par un jugement informé, ce qui constitue la norme la plus réaliste que les contrats intelligents aient jamais pu offrir. Les lecteurs souhaitant développer cette habitude à l’échelle d’un portefeuille pourront trouver utile un cadre de risque plus large, comme celui exposé dans la méthodologie de roo2ya, en complément de pratiques de recherche générales comme le DYOR.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier.