Du présent et de l’avenir des smart-contract

Contenu sponsorisé

Share on twitter
Twitter
Share on linkedin
LinkedIn

Je n’ai lu à aujourd’hui que des éloges sur ce que ce nouvel outil saurait nous apporter. Il ne se passe pas une semaine sans qu’un client me demande pourquoi nous ne proposons pas ce service.

D’un point de vue technique, juridique et contextuel, essayons d’approfondir le sujet :

Smart = intelligent, Contract = Contrat. Tout en corrigeant ce qualificatif infondé (ça n’est pas un contrat et il n’est pas intelligent), voyons de quoi il s’agit :

Les smart-contract sont des programmes informatiques irrévocables, déployés sur une blockchain, et qui exécutent des instructions prédéfinies. Ils intègrent des fonctions « si/alors » (si telle condition est remplie, alors la conséquence est exécutée) à l’image d’un automate : si je mets une pièce dans la machine, alors elle me servira un café. En théorie, il n’y a donc plus besoin de bar, de serveur et de caisse enregistreuse.

C’est un simple programme qui vient au soutien d’un contrat légalement conclu, capable d’assurer sa force obligatoire par l’automatisme de son exécution.

Prenons un exemple simple :

  • Si le passager a souscrit une assurance retard auprès de la compagnie aérienne
  • Si la tour de contrôle a bien enregistré un retard supérieur au seuil du contrat
  • Alors le passager est indemnisé avant même sa descente de l’avion

Dit ainsi, et en comparaison de ce que nous vivons dans ces situations (déclaration/justificatif/envoi/contestation…), on entrevoit tous les avantages du procédé. Il automatise ce qui était traité manuellement, exclut l’interprétation. Il n’en demeure pas moins que derrière ce concept se cache pour ses concepteurs le fait de garantir la force obligatoire des contrats non plus par le droit, mais par le code informatique : « Code is law » pour reprendre la célèbre formule de Lawrence Lessig. Nous y reviendrons.

Sont-ils sécures, à quoi sont-ils applicables ? Faisons ensemble un état des lieux de la techno, du droit et des usages.

Quels en sont les avantages ?

Dans les faits, le rédacteur d’un smart-contract écrit le code sur la blockchain. Le smart-contract devient ainsi impossible à modifier. Sur une blockchain publique, son contenu peut être consulté par tout détenteur du contrat, en toute transparence. C’est cette accessibilité qui créé la confiance entre les acteurs, et qui fait que les smart-contract ont attendu cette technologie pour exister.

Les avantages des smart-contract sont donc réels. Ces derniers permettent de :

  • sécuriser un accord grâce à la transparence et l’immutabilité de la blockchain (la blockchain, une machine vertueuse)
  • automatiser une relation de cause à effet, éliminer les risques d’interprétation
  • diminuer les coûts intermédiaires dans l’élaboration, le suivi et la passation d’un contrat (pour autant qu’ils ne soient pas conservés, renforcés ou remplacés par d’autres – CQFD, voir ci-dessous).

Tout ça donne envie, n’est-ce pas ? Continuons

Quels sont les risques technologiques ?

Ce qui fait la force des smart-contract, c’est-à-dire leur immuabilité, peut aussi être leur plus grande faiblesse. Si un programmeur ayant créé le smart-contract y a introduit une faille ou une faiblesse (même involontaire), il est impossible de le réparer une fois le contrat ancré sur une blockchain. Si des hackers réussissent à l’exploiter, le pire peut arriver, comme lors du  piratage du projet ‘’The DAO’’. A la suite de ce hack célèbre, la communauté Ethereum avait fait le choix douloureux (parce que contraire au protocole) de ré-écrire a posteriori  l’historique des transactions inscrit dans la blockchain afin de déposséder le hacker de son butin et de le restituer aux victimes. Ils ont ainsi mis à mal les grands principes d’immuabilité des données.

Pour pallier à cet inconvénient, et parce que le code informatique est nécessairement écrit par un spécialiste qui n’a pas autorité pour le valider, alors le code pourrait être établi (et/ou validé) par un tiers qui fait autorité d’un point de vue technologique et contractuel. Il devra répondre (et s’engager sur ses conséquences ?) à la question « le code est-il sans faille, retranscrit-il parfaitement la volonté des parties et la complétude des accords ?». Quand on sait la rigueur qu’il faut avoir pour traduire avec le même sens contractuel une langue en une autre, on imagine déjà quelques difficultés.

Quels sont les risques fonctionnels ?

En matière contractuelle, il est possible, voire fréquent, que la rédaction d’une ou plusieurs stipulations apparaisse incomplète, maladroite ou sibylline , faisant en sorte que la compréhension du contenu s’en trouve incertain ou interprétable. Ce contenu, dès lors qu’il sera automatisé, s’avère alors plus dangereux qu’il n’y parait: le code informatique ne connait pas l’imprécision : il dit oui, non, et jamais peut-être. Les rédacteurs du texte (puis du code) doivent donc imaginer toutes les hypothèses et leurs réponses, fussent-elles en cascade.

Dans un code, ce qui n’est pas écrit n’existe pas.

Prenons un exemple, à priori des plus simple : dans mon ancienne vie d’entrepreneur dans le BTP, j’ai toujours signé des contrats qui prévoyaient des pénalités en cas de retard (1/3000e par jour calendaire, par exemple). Tout s’écrivait en quelques lignes. Heureusement que dans la vie du contrat elles n’ont pas toujours été appliquées ! En effet, étais-je à l’origine de ce retard, étais-je le seul à l’avoir généré, n’y avait-il pas de cause extérieures ? Si, souvent d’ailleurs. Ces sujets étaient alors négociés, toujours, et jugés parfois.

Or, on ne négocie pas avec un code.

Quels sont les risques juridiques ?

L’Article 1365 du Code Civil définit l’écrit comme étant  « une suite de lettres, de caractères, de chiffres ou de tous autres signes ou symboles dotés d’une signification intelligible, quel que soit leur support ». Pour autant que l’autorité citée ci-dessus garantisse la bonne retranscription des clauses en un code et que celui-ci soit jugé intelligible, alors on pourra passer au sujet suivant. Je suis désolé de ma non réponse, mais le terrain, faute d’être glissant, n’est pas le mien.

il n’en demeure pas moins que la solidité juridique de la blockchain a gagné cette dernière année en crédibilité : la blockchain et le droit de la preuve

L’Article 1356 du Code Civil précise que « les contrats ne peuvent contredire les présomptions irréfragables établies par la loi, ni modifier la foi attachée à l’aveu ou au serment. Ils ne peuvent davantage établir au profit de l’une des parties une présomption irréfragable».

Il faut comprendre qu’en dépit de l’esprit de ses concepteurs, le code ne fera pas loi et que les conseils et intermédiaires cités plus haut comme pouvant être remplacés devraient voir leurs prérogatives confirmées, voire renforcées.

La loi, son esprit et son application

En droit français, on distingue le droit et le fait. La Cour de cassation n’est juge que du droit et les juges du fond (juridictions du premier degré et cours d’appel). La loi attribue ainsi aux juges le pouvoir souverain d’appréciation, c’est-à-dire le pouvoir qui permet d’apprécier un élément de fait. Ce pouvoir est dit souverain dans le sens où il échappe au contrôle de la Cour de cassation.

L’ordonnance n°2016-131 du 10 février 2016 portant réforme du droit des obligations introduit des dispositions qui modifient de manière substantielle les prérogatives du juge face au contrat. Le juge est désormais autorisé à modifier le contrat dans certaines circonstances, et non plus seulement à veiller à son respect ou à l’anéantir en cas d’inexécution. On pense bien sûr à la théorie de l’imprévision, consacrée par le nouvel article 1195 du Code civil. Ainsi, en cas de « changement de circonstances imprévisible lors de la conclusion du contrat [qui] rend l’exécution excessivement onéreuse pour une partie », le juge pourra « réviser le contrat ou y mettre fin, à la date et aux conditions qu’il fixe ». Même si les cas d’application de ce texte devraient rester limités, le contenu du contrat peut échapper à la volonté des parties et être soumis à l’immixtion du juge. Aussi, le juge se devra d’interpréter le contrat, soit pour en élucider le sens, soit pour en combler les lacunes :

  • Dans le premier cas, il s’agira d’une interprétation explicative : la recherche de la signification du contrat devra être effectuée dans le respect de la volonté des parties
  • Dans le second cas, il s’agira de combler les lacunes du contrat : l’interprétation du juge deviendra alors créatrice, de sorte qu’il pourra  interpréter le contrat à la lumière de la loi, de l’équité et des usages

En synthèse, pour reprendre l’exemple cité en préambule, on saurait pousser le raisonnement ainsi :

  • Si le passager a souscrit une assurance retard auprès de la compagnie aérienne,
  • Si la tour de contrôle a bien enregistré un retard supérieur au seuil du contrat,
  • Alors le passager est indemnisé avant même sa descente de l’avion,
  • Et si je juge le pense autrement, alors on recommence du début, mais on ne sait pas arrêter la machine.

Evidemment, dans cet exemple, et parce qu’il reste simple, l’immixtion du juge ne tient pas. Le juge n’interprètera qu’en dernier recours, et recherchera d’abord la commune intention des parties. Si elle est claire, le juge n’aura pas à interpréter. Si elle ne l’est pas, le juge pourra être saisi et fera son métier.

La question de la validité du consentement des parties pourrait aussi se poser : comment être certain qu’un code ait été accepté de manière libre et éclairée alors qu’on est en présence d’un algorithme qu’on peut considérer comme inintelligible par les signataires ? La théorie des vices du consentement pourrait trouver dans l’usage des smart-contract une terre fertile.

Quels sont les sujets que les smart-contract ne résolvent pas?

Si on convient qu’il est possible, avec de grandes précautions, de s’assurer de la fidélité et de la solidité du contenu informatique d’un smart-contract, il est plus incertain de valider un événement ayant eu lieu hors Blockchain. Les causes étant toujours extérieures à la blockchain (ce sont les conséquences qui sont automatisées), il faudra toujours la présence d’un tiers (ou oracle) qui permettra d’affirmer que l’origine qui déclenche la conséquence est avérée. Ce tiers, situé hors Blockchain, pose le même sujet qui existe hors smart-contract : peut-on faire confiance à cet intermédiaire ? C’est pour cette raison que des oracles et tiers de confiance existent, que leur rôle et leurs prérogatives devraient être inchangées.

Les projets qui ont vu le jour

En 2017, AXA a lancé la 1ère application française dénommée FIZZI, dont le cas d’usage (retard d’un avion) est celui que nous avons pris en exemple. Ce service a depuis été stoppé. Ca n’est pas tant pour des raisons techniques, mais pour des sujets liés à une commercialisation trop faible (clap de fin pour fizzy)

Plusieurs protocoles permettent aujourd’hui d’exécuter des smart-contract complexes. Ils sont souvent utilisés pour des applications de dérivés financiers dénommés « DeFi ». Ce nouveau cas d’usage attire autant les investisseurs que les amateurs et arnaqueurs. Vitalik Buterin, fondateur d’Ethereum et défenseur des smart-contract, est l’un des premiers à avertir des dangers et dérives qui restent possibles avec des projets fantaisistes (dangers liés à la finance décentralisée). Le point de vue est partagé par Simon Poiraud, président de d’ADAN « en attendant, c’est le far-west » cf l’article explosion de la finance décentralisée

Pour rester dans l’exotisme, on peut citer le projet Kleros qui va jusqu’à proposer une application de tribunal décentralisé. Ben voyons !

Et c’est tout…

Synthèse

Il ne nous parait pas risqué d’affirmer que, pour des contrats simples, si le cas d’usage sait trouver son attractivité, et donc sa clientèle, les avantages primeront sur les inconvénients.

Qu’en est-il des contrats complexes. Faut-il les écarter d’emblée, parce que la vie des contrats est faite d’aléas, parce-que la retranscription d’un texte en un code est aléatoire, parce que le choix d’une blockchain solide n’est pas si simple et parce qu’un juge saurait interpréter ce qui a été écrit et codé ?

Parce que les conflits proviennent toujours de clauses mal rédigées ou d’interprétations erronées ou abusives, parce qu’un contrat bien écrit et bien compris protégera toujours les signataires, parce qu’il est parfois trop aisé de ne pas faire ou de ne pas payer (pensons aussi au commerce international et donc aux diverses juridictions), parce qu’une rédaction imprécise (ou la mauvaise foi) sous-tend l’interprétation, alors la rigueur imposée par les smart-contract est une vertu dont on voudrait ne pas se passer.

Imaginons un contrat complexe, avec et sans smart-contract : il est en cours d’exécution, l’une des parties interprète une clause, manifeste son désaccord :

https://www.contractchain.io/wp-content/uploads/Avec-et-sans-smart-contract-5.jpg

Quelle synthèse peut-on faire de cette situation si elle intègre un smart-contract ?

  • que le temps de mise au point et de codage sera nécessairement plus long que ce qui se fait dans la vie d’aujourd’hui
  • que l’automatisation simplifiera ce qui est bien compris, écrit et codé
  • que cette automatisation complexifiera ce qui n’a pas été imaginé, ce qui est mal écrit ou mal codé
  • qu’en cas de désaccord, elle oblige à la continuité des clauses du contrat (pas de l’exécution qui reste du ressort d’une décision humaine), et qu’elle se fera donc toujours au détriment de celui qui aura manifesté un désaccord (l’incitant à rester sage ?)
  • que cette continuité forcée d’une partie du contrat créera sans doute des situations plus tendues

Et donc que dans l’absolu, on ne sait si on a simplifié ou complexifié la situation.

Et si on insérait des Clauses de référé ou d’arbitrage dans le code ?

Et si on cherchait à n’automatiser que ce qui mérite de l’être (c’est à dire avec un programme simple qui remplace une action énergivore), rendant ainsi le contrat moins smart, plus hybride, plus simple, et donc plus adapté à la réalité ?

Le smart-contract exige donc une forte capacité à imaginer tout ce qui pourrait arriver, une grande rigueur contractuelle et de codage informatique, ainsi que le choix d’une blockchain solide et mature.

Je ne sais si c’est possible, mais si on s’est préalablement assuré qu’un smart-contract ne créera pas plus de blocages que de fluidité, que sa pertinence en terme de temps et d’argent est avérée, alors je suis sûr que nous nous porterions tous mieux si ça l’était.

Par ailleurs, le sujet de l’intérêt du procédé me parait être le plus essentiel. Sur les sujets d’innovation, il faut d’abord comprendre ce que peut vous apporter la techno, et ensuite l’oublier pour se concentrer sur l’intérêt apporté à l’utilisateur et à son environnement. Il faut s’extraire du « je peux le faire, donc je le fais ». A défaut, vous vous exposeriez à un échec assuré (pas de marché) ou à fabriquer un besoin en construisant des voitures électriques de plus de 2 tonnes sans s’être préoccupé de l’origine de l’énergie et de son impact (pardon de ce point de vue).

Si je ne me suis pas trompé dans mon analyse, on comprend qu’avec les smart-contract, les barrières ne sont ni technologiques ni juridique, mais relèvent exclusivement de l’homme, de ce qu’il peut ou veut en faire.

Et c’est heureux !

Share on twitter
Twitter
Share on linkedin
LinkedIn

La newsletter

Abonnez-vous à notre newsletter, pour ne rien rater des grandes tendances et des transformations du secteur !