Smart contract d’une clause pénale
Les smart contract permettent d’automatiser l’exécution de certaines clauses ou contrats. Ils peuvent aussi servir à automatiser les sanctions de l’inexécution d’obligations contractuelles.
A travers un exemple pas si fictif, nous allons voir dans cet article comment les smart contract étendent le champ contractuel à des espaces jusqu’ici ignorés par les juristes.
Imaginons la situation suivante :
Un restaurateur vient de s’engager avec un grossiste. Ce dernier lui fournit de la viande hachée et s’occupe aussi de son transport. Le restaurateur est soucieux de la qualité de sa viande hachée et particulièrement des conditions dans lesquelles elle sera transportée.
A cet égard, il sait qu’un règlement européen impose que la viande hachée soit transportée dans un camion frigorifié dont la température maximale ne dépasse pas 2° C.
Bien porté sur l’innovation, il décide de contractualiser cette obligation sous la forme d’une clause pénale, et de s’aider de la technologie des smart contract et des objets connectés.
Il imagine le scénario suivant: pendant l’acheminement de la viande hachée, des thermomètres installés à l’intérieur du camion du grossiste envoient toutes les 30 secondes la température à un smart contract ; si la température envoyée est au dessus de 2 degrés, le smart contract reconnaît une inexécution de l’obligation du grossiste et déclenche automatiquement une indemnisation au bénéfice du restaurateur.
La clause pénale ressemblerait à ceci:
« Conformément au règlement européen n°853/2004 du 29 avril 2004 fixant des règles spécifiques d’hygiène applicables aux denrées alimentaires d’origine animale, le grossiste s’engage à acheminer la viande hachée au restaurateur dans un camion frigorifié dont la température intérieure ne dépasse pas 2 degrés Celsius.
Si la température de l’intérieur du camion frigorifié du grossiste venait à dépasser 2 degrés Celsius, le grossiste indemnise le restaurateur d’un ether, unité de monnaie virtuelle de la blockchain Ethereum. »
Comment mettre en place le smart contract d’une telle clause ?
En premier lieu, il convient de décentraliser la source d’information (la température) afin de s’assurer que l’exécution du programme ne dépende pas que d’une seule partie : le grossiste et le restaurateur auront chacun fait installer leur propre thermomètre connecté dans le camion (pour les familiers du jargon, il y aurait donc deux oracles).
Une fois le camion en route, les deux thermomètres connectés envoient, toutes les 30 secondes, la température du frigo à leurs propriétaires respectifs ; ces derniers renvoient chacun la température de leur thermomètre et un ether à l’adresse du smart contract. Ce processus étant entièrement automatisé.
Enfin, après avoir vérifié que les deux températures reçues soient égales, le smart contract détermine si la condition du déclenchement de l’indemnisation est remplie ou non :
- si la température est au dessus de 2°C, la condition est remplie (= la clause pénale est activée), le restaurateur récupère l’ether qu’il a envoyé au smart contract et celui du grossiste.
- si la température est en dessous de 2°C, la clause pénale n’est pas activée, chacun récupère les ethers qu’ils ont mis en jeu.
Ces trois étapes se répètent aussi longtemps que les thermomètres envoient la température de l’intérieur du camion pendant l’acheminement de la viande.
La mise en jeu de l’ether
Dans ce scénario, le grossiste et le restaurateur mettent à chaque « tour » un ether en jeu.
Cela est nécessaire pour le grossiste car il est le débiteur de l’indemnisation : si la température grimpe au-dessus de 2°, il « perd sa mise », tandis que si elle reste en dessous, il retrouve systématiquement l’ether qu’il a mis en jeu.
Le restaurateur est requis d’envoyer un ether pour le décourager à agir malhonnêtement : s’il trafique les résultats de son thermomètre, il n’y aura pas de consensus et sa mise ainsi que celle du grossiste seront retenus par le smart contract. Un mécanisme pourra ensuite être codé pour déterminer le devenir de ces fonds gelés.
Paiement en cryptomonnaie
Par commodité de démonstration, nous avons utilisé l’ether comme monnaie de paiement (monnaie native de la blockchain Ethereum) qui est très volatile. Nous aurions pu préférer une monnaie virtuelle stable, comme le dai, dont la valeur est toujours égale à un dollar.
Mais l’utilisation d’une monnaie virtuelle peut faire perdre sa qualification à notre clause pénale. En effet, la formulation de l’article 1231–5 du code civil semble exclure tout autre chose que l’argent (donc l’euro en principe; article 1343–3 du code civil) pouvant constituer l’objet d’une clause pénale.
Cet inconvénient pourrait être contourné en n’utilisant le smart contract que pour implémenter une partie de la logique opérationnelle de la clause: tout le processus serait smart contractualisé sauf le paiement qui se ferait en euros, en dehors de la blockchain.
Ou alors il pourrait être convenu une obligation facultative au bénéfice du débiteur (article 1308 du code civil): le restaurateur créancier accepterait d’être réglé en euros au principal ou en cryptomonnaie accessoirement.
Ici le code commenté, écrit en solidity, du smart contract :
contract clausePenale {
address public restaurateur;
address public grossiste;// Ci- dessus les adresses identifiant les deux parties au contratbool public restaurateurPosted = false;
bool public grossistePosted = false;// Ci- dessus les "booléens" renseignant si les parties ont bien envoyé leur température (vrai ou faux). Par défaut, ils sont sur faux.uint public restaurateurDepot = 0;
uint public grossisteDepot = 0;// Ci-dessus les mises des parties au contrat, par défaut égales à 0.uint public restaurateurTemperature;
uint public grossisteTemperature;// Ci-dessus les températures du restaurateur et du grossisteuint public temperatureMax = 2;// Ci - dessus la température maximale autorisée par le règlement européenfunction envoiTemperature (uint x) public payable {
// la logique du programme se trouve sous cette fonction "envoiTemperature"
require(msg.sender == restaurateur || msg.sender == grossiste);
// Ci-dessus cette fonction impose que la fonction "envoiTemperature" ne puisse être utilisée que par les parties.
if (msg.sender == restaurateur) {
restaurateurPosted = true;
restaurateurDepot =+ msg.value;
restaurateurTemperature = x;
}// Si l'envoyeur est le fournisseur, le booléen est défini sur "true"; on enregistre sa somme mis en jeu et la température de son thermomètreif (msg.sender == grossiste) {
grossistePosted = true;
grossisteDepot =+ msg.value;
grossisteTemperature = x;
}// même opération pour le grossisteif (grossistePosted && restaurateurPosted) {// si les deux parties ont bien envoyé leur température...if ( grossisteTemperature == restaurateurTemperature ) {//...et que celles-ci sont bien égales...if ( grossisteTemperature > temperatureMax ) {
restaurateur.transfer(restaurateurDepot+grossisteDepot);
restaurateurDepot = 0;
grossisteDepot = 0;//...et que la température est supérieure à la température max; On transfère les dépôts} else {// sinon chacun récupère sa miserestaurateur.transfer(restaurateurDepot);
grossiste.transfer(grossisteDepot);
restaurateurDepot= 0;
grossisteDepot = 0;
}
}
}
}
}
Crédits : cet article est inspiré d’un réel cas d’application sur lequel travaille IBM et du code de smart contract de SLA du brillant institut espagnol i2CAT Foundation.
