Les contrats intelligents et leurs limites

Des programmes dont les résultats deviennent l’état du registre

Un contrat intelligent est un code déployé dans un environnement blockchain, qui s’exécute conformément aux règles de cet environnement. Malgré son nom, un contrat intelligent n’est pas nécessairement un contrat juridiquement contraignant. Il peut simplement mettre en œuvre une instruction automatisée telle que « enregistrer une modification de solde lorsque les conditions requises sont remplies ». Ses résultats peuvent mettre à jour des soldes, émettre des enregistrements ou appeler d’autres applications. La blockchain fournit un environnement répliqué dans lequel les nœuds participants peuvent vérifier si l’exécution a respecté les règles convenues.

Un registre de billets constitue un exemple de départ utile. Un contrat intelligent peut enregistrer que l’identifiant de billet 417 appartient à un compte blockchain donné. Lorsqu’il reçoit une demande de transfert autorisée, il vérifie la propriété et toute restriction éventuelle avant de mettre à jour cet enregistrement. Le code ne sait pas, à lui seul, si l’événement sous-jacent aura lieu, si le détenteur est une personne réelle en particulier ou si le droit local de la consommation autorise une restriction. Ces questions relèvent d’autres systèmes et dispositifs juridiques. Les contrats intelligents rendent exécutables les règles spécifiées ; ils ne rendent pas accessibles tous les faits pertinents du monde réel.

Transactions, état et exécution déterministe

Une transaction est une instruction soumise qui demande une modification de l’état d’une blockchain. L’état correspond aux informations actuellement enregistrées, telles que les soldes, les autorisations de compte ou les variables stockées par un contrat. Une exécution déterministe signifie que les nœuds qui appliquent les mêmes instructions valides au même état antérieur devraient obtenir le même résultat. C’est pourquoi un contrat classique ne peut pas simplement ouvrir un site Web quelconque et utiliser la page actuelle comme donnée d’entrée fiable. Les différents nœuds pourraient consulter des informations différentes ou rencontrer des défaillances différentes.

Les réseaux diffèrent par leurs modèles d’exécution. Certains prennent en charge des contrats programmables à usage général ; d’autres fournissent des scripts volontairement limités. Même lorsque deux réseaux offrent des fonctionnalités similaires, ils peuvent utiliser des machines virtuelles, des frais, des structures de comptes et des sémantiques de transaction différents. Cette leçon explique la logique commune sans obliger les étudiants à programmer sur une chaîne en particulier.

L’automatisation est conditionnelle, pas magique

Un contrat peut comporter des conditions, des autorisations et des événements. Une condition évalue les faits accessibles à son environnement, par exemple si un compte détient suffisamment de jetons. Une autorisation précise quel acteur peut appeler une fonction. Un événement est un enregistrement structuré émis pour aider les applications à observer ce qui s’est produit. Tous les événements ne garantissent pas un mouvement d’actifs correspondant, et toutes les interfaces utilisateur n’interprètent pas correctement la transaction sous-jacente. Les personnes chargées de l’examen devraient vérifier les modifications d’état réussies plutôt que de considérer une notification affichée comme une preuve décisive.

Les contrats consomment également des ressources d’exécution. De nombreux réseaux mesurent le travail de calcul et facturent des frais de transaction, parfois appelés gaz. Si un contrat exige trop de calcul ou si la transaction ne fournit pas suffisamment de ressources, l’opération peut échouer. Les frais contribuent à décourager les calculs sans limites. Ils ne garantissent pas que tous les contrats sont économiques à utiliser ni qu’un chemin d’exécution est exempt d’erreurs. La complexité accroît le besoin de tests et d’examen.

Les oracles relient la chaîne aux faits externes

Un oracle est un mécanisme qui fournit à un contrat des informations provenant de l’extérieur de sa blockchain. Il peut s’agir, par exemple, d’un taux de référence officiel, d’une confirmation de livraison ou d’un dossier d’admissibilité vérifié. Un oracle n’élimine pas la confiance ; il la déplace vers les fournisseurs d’informations, les processus de validation des données et les canaux de transmission. Des données erronées, tardives, manipulées ou indisponibles peuvent amener un contrat à se comporter exactement comme prévu dans le code tout en produisant un résultat commercialement inapproprié. La documentation Ethereum sur les oracles décrit cette séparation entre le code sur la chaîne et les informations externes.

Dans le secteur public, un oracle alimenté par des dossiers administratifs soulève des questions supplémentaires : le pouvoir de publier des données, la protection de la vie privée, les procédures de correction et la vérifiabilité. Il peut être inapproprié d’inscrire des renseignements personnels de façon permanente dans un registre largement répliqué. Les systèmes peuvent souvent ne stocker sur la chaîne qu’une preuve ou une référence limitée, tout en conservant les dossiers sensibles dans des bases de données gérées. La conception appropriée dépend des règles de conservation, de l’accessibilité et de la finalité probatoire du système.

Quatre limites que toute personne décisionnaire devrait connaître

Premièrement, le risque lié au code demeure. Un défaut de programmation, une norme mal comprise ou une interaction non sécurisée entre applications peut entraîner des résultats involontaires. La publication du code source facilite son examen, mais ne prouve pas qu’il est correct. Deuxièmement, le risque lié à la gouvernance demeure. Certains contrats ont des administrateurs qui peuvent suspendre des fonctions ou mettre à niveau le code. Une interface qui semble immuable peut dissimuler des dépendances modifiables. Troisièmement, le risque lié aux données demeure lorsque le contrat dépend d’oracles, de flux de données ou de référentiels de documents. Quatrièmement, la force exécutoire juridique reste une question distincte : l’exécution sur la blockchain peut avoir lieu même en cas de litige concernant l’autorité, le consentement ou la propriété.

Un utilisateur devrait distinguer l’immutabilité des anciens enregistrements du registre de l’immutabilité du comportement de l’application. Une transaction historique peut rester visible même si un contrat proxy pointe ultérieurement vers un nouveau code d’implémentation. Un système peut également prévoir des mécanismes légitimes de récupération ou d’urgence, qui comportent leurs propres risques. La description binaire « entièrement décentralisé ou centralisé » masque généralement des questions plus utiles : qui contrôle les mises à jour, quelles signatures sont requises, que peut-on geler et qui peut résoudre les litiges ?

Vérifier une affirmation d’exécution automatique

Imaginez un contrat présenté comme libérant automatiquement un paiement lorsque du matériel arrive dans un entrepôt gouvernemental. Les inspecteurs devraient demander comment l’arrivée est mesurée, qui la certifie, que se passe-t-il en cas de défaillance d’un capteur et comment les corrections sont enregistrées. Si le système accepte la confirmation d’un employé autorisé comme déclencheur, le contrat applique la présence de cette confirmation — et non l’arrivée physique elle-même. Cette distinction est cruciale pour déterminer si les enregistrements prouvent un fait, une déclaration ou les deux.

Dans les orientations du GAFI de 2021 sur les actifs virtuels, l’analyse réglementaire dépend également de la fonction et du contrôle, notamment de la question de savoir si des personnes exploitent ou contrôlent des services visés. Il ne faut pas supposer qu’une application qui se décrit comme « autonome » est exemptée de toutes les obligations juridiques. Les lois nationales et régionales peuvent également s’appliquer selon l’activité ; il est inexact de supposer que le simple déploiement de code répond à la question réglementaire.

Une séquence pratique d’examen

Pour une personne qui ne programme pas, l’examen le plus simple consiste à déterminer la fonction prévue, puis à cartographier les entrées, l’autorité, l’exécution et les sorties. Ensuite, il faut examiner si un acteur peut modifier les règles. Enfin, il faut déterminer quels faits et quels droits sont établis en dehors de la blockchain. Selon les enjeux, un avis juridique, un audit de sécurité ou un examen comptable peut être nécessaire. Cela ne signifie pas que les contrats intelligents ont échoué : toute technologie fonctionne au sein d’institutions et de politiques. Leur contribution utile consiste à exécuter de façon cohérente des règles clairement spécifiées et vérifiables lorsque les hypothèses sont respectées.

Remarque sur les preuves et la responsabilité

L’enregistrement technique d’un appel de contrat peut répondre aux questions « quel compte a soumis cette instruction ? » et « qu’a enregistré le logiciel ? ». En général, il ne peut pas répondre à la question « qui était autorisé en vertu de la politique de l’organisation ? » sans référence aux dossiers d’identité et d’approbation. Les journaux, l’historique des déploiements, les versions des contrats et les inventaires des contrôles d’accès devraient donc être conservés ensemble. Pour les marchés publics ou les opérations réglementées, l’automatisation ne peut renforcer la cohérence que si une personne reste responsable des entrées erronées, des résultats exceptionnels et des modifications des règles.

Normes et références juridiques

La documentation Ethereum, Introduction aux contrats intelligents et Oracles, décrit l’exécution et les dépendances hors chaîne. Le document du GAFI Orientations actualisées pour une approche fondée sur les risques à l’égard des actifs virtuels et des prestataires de services sur actifs virtuels (octobre 2021) présente des considérations pertinentes fondées sur les activités.

Point à retenir pour l’examen : Expliquez ce qu’exécute un contrat intelligent, distinguez les faits déterministes sur la chaîne des faits externes fournis par des oracles, et reconnaissez que l’exécution technique ne règle pas, à elle seule, la question de la force exécutoire juridique.