Je n’ai lu à aujourd’hui que des éloges sur ce que ce nouvel outil saurait nous apporter.
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 » à 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 donc 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é.
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. 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, 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’’.
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 ? ».
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 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. 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
En dépit de l’esprit de ses concepteurs « Code is law », le code ne fera pas loi, les conseils et intermédiaires cités plus haut comme pouvant être remplacés devraient voir leurs prérogatives confirmées, voire renforcées.
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. 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.
L’ordonnance n°2016-131 du 10 février 2016 introduit des dispositions qui modifient de manière substantielle les prérogatives du juge face au contrat. Le juge est désormais autorisé dans certaines circonstances à modifier le contrat, et non plus seulement à veiller à son respect ou à l’anéantir en cas d’inexécution. 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
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).
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é ?
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 :
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 (donc 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 !
