Brevet FR3094519A1 — publié le 20201002

Description Titre de l'invention : Procédé de négociation de contrat entre deux parties dans un réseau de télécommunications et dispositifs mettant en oeuvre ce procédé Technique antérieure 100011 L'invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »). 100021 Comme indiqué dans le document (hntps://fr.wikipedia.org/wiki/Blockchain), on rappelle que « la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la hase sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une hase de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les noeuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système réparti». 100031 Cette technologie est utilisée notamment comme registre pour enregistrer des tran- sactions en crypto-monnaie. [0004] L'utilisation de la technologie des chaînes de blocs pour enregistrer des contrats a été envisagée. Dans ce contexte, l'utilisation d'une chaîne de blocs est particulièrement avantageuse car elle permet de s'assurer qu'un contrat enregistré dans la chaîne ne pourra pas être falsifié. [0005] L'invention propose d'étendre l'usage de la technologie des chaînes de blocs à la phase d'élaboration et de négociation des contrats. [0006] Elle peut notamment être mise en oeuvre dans toute chaîne de bloc offrant un mécanisme connu de l'homme du métier sous le nom de « contrat intelligent » (en anglais Smart Contract), notamment et de façon non limitative, dans la chaîne de blocs Ethereum (marque déposée). Exposé de l'invention [0007] Plus précisément, selon un premier aspect, l'invention propose un procédé dc diffusion, dans un réseau de télécommunications, d'une proposition dc contrat proposée par une première partie, cc procédé comportant : - une étape de génération d'un contrat intelligent comportant : - l'adresse d'un registre comportant une dé publique de la première partie dans une chaîne de blocs ; 2 - des données représentatives des termes de la proposition de contrat ; - une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans le réseau pour souscrire à la proposition de contrat ; - une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une deuxième partie et pour demander l'enregistrement de cc contrat personnalisé dans la chaîne de blocs, cc contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d'une volonté de ladite deuxième partie d'accepter les termes de la proposition de contrat ; - une étape de signature du contrat intelligent avec une clé privée de la première partie ; et - une étape de diffusion dans le réseau du contrat intelligent signé pour demander son enregistrement dans la chaîne de blocs. [0008] Corrélativement, l'invention concerne un dispositif de diffusion, dans un réseau de télécommunications, d'une proposition de contrat proposée par une première partie, cc dispositif comportant : - un module de génération d'un contrat intelligent comportant : - l'adresse d'un registre comportant une clé publique de la première partie dans une chaîne de blocs ; - des données représentatives des termes de la proposition de contrat ; - une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans ledit réseau pour souscrire à la proposition de contrat ; - une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et pour demander l'enregistrement de ce contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d'une volonté de la deuxième partie d'accepter les termes de la proposition de contrat ; - un module de signature du contrat intelligent avec une clé privée de la première partie ; et - un module de diffusion dans le réseau du contrat intelligent signé pour demander son enregistrement dans la chaîne de blocs. [0009] Selon un deuxième aspect, l'invention concerne un procédé d'acceptation d'une pro- position de contrat diffusée dans un réseau de télécommunications, ce procédé étant mis en oeuvre par le terminal d'un utilisateur et comportant : - une étape d'obtention d'un contrat intelligent enregistré dans une chaîne de blocs, ce contrat intelligent comportant - l'adresse, dans la chaîne de blocs, d'un registre comportant une clé publique d'une première partie propriétaire de la proposition de contrat ; 3 - des données représentatives dc termes de la proposition de contrat ; - une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans le réseau pour souscrire à la proposition de contrat ; - une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et demander l'enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d'une volonté de la deuxième partie d'accepter les termes de la proposition de contrat ; - une étape d'obtention dc paramètres représentatifs d'une volonté de l'utilisateur d'accepter les ternies de la proposition de contrat ; - une étape d'exécution de la méthode de souscription, cette exécution déclenchant la diffusion dans le réseau d'une transaction, signée avec une clé publique de l'utilisateur, et comportant : - l'adresse d'une clé publique de l'utilisateur dans la chaîne dc blocs ; [0010] l'adresse du contrat intelligent dans la chaîne de blocs ; - un identifiant de la méthode de génération de contrat; et - les paramètres précités. [0011] Corrélativement, l'invention vise un dispositif d'acceptation d'une proposition de contrat diffusée dans un réseau de télécommunications, ce dispositif étant mis en oeuvre dans le terminal d'un utilisateur et comportant : - - un module d'obtention d'un contrat intelligent enregistré dans une chaîne de blocs, ce contrat intelligent comportant : - l'adresse, clans la chaîne de blocs, d'un registre comportant une clé publique d'une première partie propriétaire de la proposition de contrat ; - des données représentatives de termes de la proposition de contrat ; - une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et pour demander l'enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d'une volonté de la deuxième partie d'accepter les termes de la proposition de contrat ; - un module d'obtention de paramètres représentatifs d'une volonté de l'utilisateur d'accepter les termes de ladite proposition de contrat ; - un module d'exécution de la méthode de souscription, cette exécution déclenchant la diffusion dans le réseau d'une transaction, signée avec une clé publique de l'utilisateur, et comportant - l'adresse d'une clé publique de l'utilisateur dans la chaîne de blocs ; - l'adresse du contrat intelligent dans la chaîne de blocs ; - un identifiant de la méthode de génération de contrat; et - les paramètres précités. [0012] L'invention vise également un procédé de négociation de contrat entre deux parties dans un réseau de télécommunications, cc procédé comportant : - la génération d'unc proposition de contrat par la première partie, sous la forme d'un contrat intelligent comportant : - l'adresse d'un registre comportant une clé publique de la première partie dans une chaîne de blocs; - des données représentatives des termes de la proposition de contrat ; - une méthode de souscription permettant à la deuxième partie de diffuser une transaction dans le réseau pour souscrire à cette proposition de contrat ; - une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et la deuxième partie et pour demander l'enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d'une volonté de la deuxième partie d'accepter les termes de la proposition de contrat; - une étape de signature du contrat intelligent avec une clé privée de la première partie ; - une étape de diffusion du contrat intelligent signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs ; - une étape d'obtention du contrat intelligent par la deuxième partie ; - une étape d'obtention de paramètres représentatifs d'une volonté de ladite deuxième partie d'accepter les termes de ladite proposition de contrat ; - une étape d'exécution de la méthode de souscription par un terminal de la deuxième partie, cette exécution déclenchant la diffusion dans le réseau d'une transaction, signée avec une clé publique de la deuxième partie, et comportant : - l'adresse d'une clé publique de l'utilisateur dans la chaîne de blocs ; - l'adresse du contrat intelligent dans la chaîne de blocs ; - un identifiant de ladite méthode de génération de contrat; et - les paramètres précités; et - une étape d'exécution, mise en oeuvre par un dispositif de minage de la chaîne de blocs, de la méthode de génération d'un contrat personnalisé, avec ces paramètres pour générer un contrat personnalisé entre les parties, l'enregistrer dans la chaîne de blocs et rediffuser la chaîne de blocs. [0013] Au sens de l'invention, l'« adresse » d'une ressource dans la chaîne de blocs est un pointeur vers une ressource dans la chaîne de blocs. [0014] On rappelle qu'un contrat intelligent (en anglais Smart Contract) est un programme informatique autonome, qui une fois démarré, exécute automatiquement des conditions définies au préalable et inscrites dans la chaîne de blocs (http s)/bloc kc hai nfrance. net/2016/01/28/app I ications-smart-contracts/). Les applications décentralisées dApps du projet Ethercum constituent des contrats intelligents au sens de l'invention. [0015] Ainsi, et d'une façon générale, l'invention propose un mécanisme permettant la né- gociation de contrats dans un réseau dans lequel on enregistre dans une chaîne de blocs - une proposition de contrat diffusée à l'ensemble des participants à la chaîne de blocs, à l'initiative d'un premier utilisateur, propriétaire de la proposition de contrat et partie au contrat ; et - un contrat personnalisé, généré à partir de cette proposition de contrat, entre ce premier utilisateur, et un autre utilisateur de la chaîne de blocs, deuxième partie au contrat. [0016] Le procédé est remarquable en ce que la proposition de contrat est enregistrée dans la chaîne de blocs sous forme d'un contrat intelligent et en ce que le contrat personnalisé est généré par une méthode de ce contrat intelligent, suite à une transaction diffusée par la deuxième partie au contrat, par laquelle cette deuxième partie diffuse aux utilisateurs de la chaîne de blocs, des paramètres représentatifs de sa volonté d'accepter les termes de la proposition de contrat. [0017] De façon remarquable, l'invention utilise la chaîne de blocs pour établir un lien immuable entre la proposition de contrat et le contrat personnalisé. En effet, le contrat personnalisé est généré par le contrat intelligent lui-même, celui-ci pouvant être vérifié à tout moment par les utilisateurs de la chaîne de blocs. [0018] Conformément à l'invention, et contrairement aux méthodes de l'art antérieur, le contrat personnalisé est, dans la chaîne de blocs, la propriété du contrat intelligent (c'est-à-dire de la proposition de contrat) et non de la deuxième partie au contrat. [0019] Le contrat personnalisé obtenu par l'invention peut être constitué par un ensemble de données statiques. [0020] Dans un mode préféré de réalisation de l'invention, le contrat personnalisé est un contrat intelligent. Ce contrat intelligent peut contenir un code informatique configuré pour s'exécuter lors ou après l'exécution du contrat personnalisé entre les parties. [0021] Dans un mode particulier de réalisation de l'invention, la méthode de génération de souscription est configurée pour obtenir des conditions d'acceptation de la proposition de contrat par la deuxième partie, ces conditions d'acceptation faisant partie des paramètres compris dans la transaction pour générer le contrat personnalisé. 6 [0022] Dans un mode particulier de réalisation, la méthode de génération de contrat peut être configurée pour vérifier si ces conditions d'acceptation sont compatibles avec les termes de la proposition de contrat avant de générer le contrat spécifique. [0023] Dans un mode de réalisation, le procédé de diffusion de proposition de contrat selon l'invention comporte une étape de téléchargement d'un agent informatique auprès d'un serveur, cet agent comportant : - un module pour obtenir, de la première partie, des données représentatives des termes de la proposition de contrat ; et - un module pour générer le contrat intelligent à partir de ces données et pour diffuser le contrat intelligent dans le réseau. [0024] Corrélativement, dans ce mode de réalisation, le dispositif de diffusion selon l'invention comporte : - un module de communication apte à télécharger un agent à partir d'un serveur ; - un module de traitement apte à installer cet agent dans le dispositif ; - cet agent comportant le module de génération de contrat, le module de signature et le module de diffusion du dispositif de diffusion. [0025] Cet agent est remarquable en ce qu'il permet d'assister l'utilisateur dans la rédaction de la proposition de contrat, et en ce qu'il réalise, de façon transparente pour l'utilisateur, son implémentation dans un contrat intelligent et l'enregistrement de ce contrat dans la chaîne de blocs. La Demanderesse a en effet constaté que dans l'état actuel de la technique les propriétaires de données enregistrées dans les chaînes de blocs étaient des experts en informatique. [0026] L'invention vise au contraire une solution de négociation de contrats en ligne qui ne nécessite pas de connaissance dans la technologie des chaînes de blocs. [0027] Dans un mode de réalisation de l'invention, cet agent comporte en outre un module pour signer le contrat intelligent avec la clé privée de la première partie. [0028] En variante, le contrat intelligent peut être signé avec la clé privée de la première partie par un module cryptographique de son terminal et fourni signé à l'agent pour diffusion dans la chaîne de blocs. [0029] Dans un mode particulier de réalisation, les différentes étapes du procédé de diffusion de proposition de contrat, du procédé d'acceptation de proposition de contrat et de négociation de contrat sont déterminées par des instructions de programmes d'ordinateurs. [0030] En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé tel que décrit ci-dessus. [0031] Ce programme peut utiliser n'importe quel langage de programmation, et être sous la 7 forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0032] L'invention vise aussi un support d'informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. [0033] Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. [0034] D'autre part, le support d'informations ou d'enregistrement peut être un support trans- missible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0035] Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins [0036] D'autres caractéristiques et avantages de la présente invention ressortiront de la des- cription faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : [0037] [fig. I ] la figure I représente l'architecture matérielle d'un dispositif de diffusion de pro- position de contrat conforme à un mode particulier de réalisation de l'invention ; [0038] [fig.2] la figure 2 représente l'architecture matérielle d'un dispositif d'acceptation d'une proposition de contrat conforme à un mode particulier de réalisation de l'invention ; [0039] If ig.31 la figure 3 illustre sous forme d'ordinogramme, les principales étapes des procédés conformes à un mode particulier de réalisation de l'invention ; [0040] [fig.4] la figure 4 représente un formulaire de rédaction de proposition de contrat pouvant être utilisé dans l'invention ; [0041] [fig.5] la figure 5 illustre un contrat intelligent pouvant être utilisé dans l'invention ; [0042] [fig.6] 8 la figure 6 représente un formulaire de rédaction d'acceptation de proposition de contrat pouvant être utilisé dans l'invention ; [0043] [fig.7] la figure 7 illustre une transaction pouvant être utilisée dans l'invention ; et [0044] [fig.8] la figure 8 représente une chaîne de blocs comportant des blocs générés par l'invention 8. Description des modes de réalisation [0045] La figure 1 représente l'architecture matérielle d'un dispositif DA de diffusion de proposition (le contrat conforme à un mode particulier de réalisation (le l'invention. Dans le mode de réalisation décrit ci-après cc dispositif DA est intégré dans le terminal TA d'un utilisateur Alice. [0046] Cc dispositif DA comprend notamment un processeur 13, une mémoire vive 14, un disque dur 15 ainsi que des moyens de communication 17 lui permettant de communiquer sur un réseau de télécommunications, notamment avec des terminaux. Ces moyens de communication incluent par exemple une interface WIFI, une carte réseau, etc. en fonction de la nature du réseau. [0047] Lc disque dur 15 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 13 et sur lequel est enregistré ici un programme d'ordinateur PROGA conforme à l'invention. [0048] Dans le mode de réalisation décrit ici, ce programme d'ordinateur PROGA comporte un navigateur Internet NAV et un agent informatique AG téléchargé depuis un serveur SRV COMP du réseau offrant un service de composition de proposition de contrats. [0049] Lc programme d'ordinateur PROGA définit des modules fonctionnels (et logiciels ici), configurés pour mettre en oeuvre les étapes d'un procédé de diffusion d'une proposition de contrat selon l'invention. [0050] La figure 2 représente l'architecture matérielle d'un dispositif DB d'acceptation d'une proposition de contrat conforme à un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ci-après cc dispositif DB est intégré dans le terminal TB d'un utilisateur Bob et dans le terminal TC d'un utilisateur Charly. [0051] Ce dispositif DB comprend notamment un processeur 23, une mémoire vive 24, un disque dur 25 ainsi que des moyens de communication 27 sur le réseau de télécommunications. [0052] Le disque dur 25 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 23 et sur lequel est enregistré ici un programme d'ordinateur PROGB conforme à l'invention. [0053] Le programme d'ordinateur PROGB définit des modules fonctionnels (et logiciels 9 ici), configurés pour mettre en oeuvre les étapes d'un procédé d'acceptation de proposition de contrat selon l'invention. [0054] En référence à la figure 3, nous allons maintenant décrire : - les principales étapes A10 à A50 d'un procédé de diffusion d'une proposition de contrat selon l'invention mises en oeuvre par le terminal TA d'Alice, - les principales étapes B70 et B80 d'un procédé d'acceptation d'une proposition de contrat mises en oeuvre par le terminal TB de Bob et par le terminal TC de Charly ; et - les principales étapes A10 à A50, U60, B70, B80 et U90 d'un procédé de négociation de contrat mises en oeuvre conjointement par le terminal TA d'Alice, le terminal TB de Bob ou celui TC de Charly et le terminal Ul d'un mineur de la chaîne de blocs. [0055] Au cours d'une étape A10, l'utilisateur Alice (ci-après Alice) utilise son terminal TA pour souscrire au service de composition de contrats auprès d'un serveur SRV COMP. Le terminal TA télécharge l'agent AG auprès du serveur SRV_COMP et installe cet agent AG sur le disque dur 15 du dispositif DA. [0056] Dans le mode de réalisation décrit ici, cet agent AG comporte : - un module AG_GENKEY de génération de clés cryptographiques ; - un module AG SIGN de signature cryptographique ; -un module AG_REDA d'aide à la rédaction de propositions de contrats ; et - un module AG DIFF configure pour générer un contrat intelligent à partir de données reçues du module AG_REDA et pour diffuser le contrat intelligent dans le réseau pour demander son enregistrement dans une chaîne de blocs CB. [0057] Dans le mode de réalisation décrit ici, lorsqu'Alice installe l'agent AG dans son terminal TA, au cours d'une étape A20, cet agent AG : - génère une paire de clés IKEYA,us (clé publique), KEYA,R,, (clé privée)) pour Alice en utilisant son module AG_GENKEY de génération de clés cryptographiques ; - enregistre la clé publique KEYA,us d'Alice dans la chaîne de blocs CB; - mémorise la paire de clés {KEYApi :B. KEYAPRIV } sur le disque dur 15 du dispositif DA ; et - installe le module AG_REDA d'aide à la rédaction de propositions de contrats en tant que module d'extension (en anglais plug-in) du navigateur NAV du terminal TA. [0058] Dans un autre mode de réalisation, le module AG_GENKEY de génération de clés cryptographiques peut être extérieur à l'agent, par exemple installé dans un serveur distant. La paire de clés { KEYAPUB, KEYAPRivj peut être obtenue par tout moyen connu de l'état de la technique. [0059] Nous supposerons que d'autres utilisateurs Bob et Charly, Uii=l, N se sont déjà en- registrés dans la chaîne de blocs CB lors d'une phase d'inscription et que leurs clés publiques KEYBPUB, KEYCpuB, KEYUiPUB sont enregistrées dans la chaîne de blocs CB. [0060] Au cours d'une étape A30, Alice souhaite publier une nouvelle proposition de contrat dans la chaîne de hlocs CB. Elle utilise pour cela le module d'extension AG REDA installé dans forme de module d'extension de son navigateur Internet NAV. [0061] Ce module d'extension télécharge depuis le serveur de composition SRV COMP une page Weh qui constitue un formulaire FORM_PC d'aide à la rédaction de proposition de contrat et l'affiche dans le navigateur NAV d'Alice. Ce formulaire FORM_PC est représenté à la figure 4. [0062] Dans le mode de réalisation décrit ici, le formulaire FORM_PC comporte : - une partie A à remplir par la première partie au contrat, ici Alice, pour proposer un nouveau contrat, cette partie A comportant : - un champ « Termes » pour définir les termes de la proposition de contrat, - un champ « Date » de date et un champ « Sign » de signature permettant à la première partie au contrat de dater la proposition de contrat et de la signer avec un stylo électronique ; - un bouton de validation « OK » utilisable par la première partie au contrat pour demander l'enregistrement de la proposition de contrat dans la chaîne de hlocs CB ; - une partie B permettant de définir les informations devant être fournies par une deuxième partie pour accepter cette proposition de contrat, certaines (marquées d'un astérisque) étant optionnelles. Dans l'exemple décrit ici, la deuxième partie B spécifiée par Alice comporte : - un champ « Cond » dans laquelle la deuxième partie B peut préciser des conditions d'acceptation de la proposition de contrat ; - un champ « Date » de date et un champ « Sign » de signature permettant à la deuxième partie au contrat de dater l'acceptation de contrat et de la signer avec un stylo électronique. Alice décide que ces champs « Date » et « Sign » doivent nécessairement être renseignés. [0063] Nous supposerons qu'Alice : - remplit le champ «Ternes » avec une offre de service et un prix associé, par exemple, « la société Alice recherche une personne pour livrer des pizzas sur Paris, chaque livraison étant rémunérée 10 euros » ; - date la proposition de contrat dans le champ « Date » ; -signe la proposition de contrat avec un stylet électronique dans le champ « Sign » ; et [0064] valide sa proposition de contrat au contrat en utilisant le bouton « OK ». [0065] Cette validation a pour effet de générer, au courant d'une étape A40, un contrat in- telligent SCGA représenté à la figure 5. Ce contrat SCGA est un code informatique exécutable qui traduit la proposition de contrat rédigée par Alice au moyen du 11 formulaire FORM_PC et qui comporte : - l'adresse @A du registre comportant la clé publique d'Alice KEYA,' dans la chaîne de blocs CB ; - des données TERMES, DATE, SIGN signées avec la clé privée KEYA',', d'Alice et qui reprennent les champs de la partie A du formulaire FORM_PC remplis par Alice ; - une méthode informatique SUBS_SCGA de souscription permettant à un tiers souhaitant souscrire à la proposition de contrat, de diffuser une transaction dans le réseau à cet effet; et - une méthode informatique de génération de contrat GEN CTRT SPEC configurée pour générer un contrat personnalisé entre Alice et ce tiers et pour demander son enregistrement dans la chaîne de blocs CB. [0066] Au cours d'une étape A50, l'agent AG : - signe le contrat intelligent SCGA avec la clé privée d'Alice KEYA,,',, en utilisant le module AG SIGN ; et - diffuse le contrat intelligent SCGA signé dans la chaîne de blocs CB en utilisant le module AG DIFF pour demander son enregistrement dans la chaîne de blocs. [0067] Dans un autre mode de réalisation, le formulaire FORM_PC d'aide à la rédaction de proposition de contrat ne comporte pas les champs de date « Date » et de signature « Sign », et le bouton OK de validation est configure pour, lorsqu'il est activé, générer automatiquement une date la signer, et l'insérer dans le contrat intelligent SCGA. [0068] Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly, Ui reçoivent ce contrat intelligent et peuvent en prendre connaissance. [0069] La proposition de contrat SCGA ayant été signée avec la clé privée d'Alice, cette proposition de contrat est, dans la chaîne de blocs CB, la propriété d'Alice. On notera que l'agent AG n'est pas authentifié dans la chaîne de blocs CB. [0070] Nous supposerons qu'un utilisateur Ui joue le rôle de mineur dans la chaîne de blocs CB, et qu'au cours d'une étape U60, il vérifie la signature du contrat intelligent SCGA avec la clé publique d'Alice KEYA,'', insère le contrat intelligent SCGA dans un bloc d'adresse @SCGA dans la chaîne de blocs CB et rediffuse la chaîne de blocs CB. [0071] Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB. [0072] Nous supposerons que Bob prend connaissance de la proposition de contrat d'Alice au cours d'une étape B70 et décide d'y souscrire en invoquant la méthode de souscription SUBS_SCGA du contrat intelligent SCGA. [0073] L'exécution de cette méthode génère l'affichage d'un formulaire FORM_CS dans le navigateur NAV du terminal TB de Bob représenté à la figure 6. [0074] 11 comporte, dans ce mode de réalisation : 12 - une partie A reconstituée à partir des informations fournies par Alice et contenues dans les champs TERMES, DATE, SIGN du contrat intelligent SCGA ; - une partie B qui reprend : - des champs « Cond », « Date » et « Sign » tels que définis par Alice dans son formulaire FORM PC et qui peuvent être édités par Bob pour générer des données représentatives de sa volonté d'accepter les ternies de la proposition de contrat, ces données devant comporter une date et une signature et éventuellement des conditions d'acceptation de la proposition de contrat ; et - un bouton de validation OK utilisable Bob pour demander la génération et l'enregistrement d'un contrat personnalisé SCAB entre Alice et Bob dans la chaîne de blocs CB. [0075] Nous supposerons que Bob, au cours d'une étape B80, définit ses conditions dans le champ « Cond », date, signe le formulaire FORM_CS avec un stylet électronique et valide sa demande de transaction avec le bouton « OK ». Cette validation entraîne la diffusion d'une transaction TR AB, signée avec la clé privée KEYB,,,, de Bob à destination des utilisateurs de la chaîne de blocs, dont Alice, Charly et Ui. [0076] Dans un autre mode de réalisation, le formulaire FORM_CS ne comporte pas les champs de date « Date » et de signature « Sign », et le bouton OK de validation est configuré pour, lorsqu'il est activé, générer automatiquement une date, la signer, et l'insérer dans la transaction TR AB. [0077] Dans un autre mode de réalisation, le formulaire FORM_CS ne comporte pas les champs de date « Date » et de signature « Sign ». et l'appui sur le bouton « OK » entraine seulement la diffusion de la transaction TR_AB. [0078] Cette transaction TR_AB transmise dans la chaîne de blocs CB comporte la preuve de la volonté de Bob de vouloir exécuter la méthode GEN_CTRT_SPEC du contrat intelligent SCGA pour générer un contrat personnalisé SCAB. Cette transaction TR_AB représentée à la figure 7 et comporte : - l'adresse @B de la clé publique de Bob KEYBP,;R dans la chaîne de blocs CB ; - l'adresse @SCGA du contrat intelligent SCGA dans la chaîne de blocs CB ; - un identifiant GEN_CTRT_SPEC de la méthode de ce contrat à exécuter pour générer un contrat personnalisé SCAB; - des champs COND. DATE et SIGN qui reprennent les conditions, la date et la signature de Bob édités dans les champs « Cond ». « Date » et « Sign » du formulaire FORM_SC et qui serviront de paramètres à la méthode GEN_CTRT_SPEC pour générer le contrat personnalisé SCAB. [0079] Au cours d'une étape U90, un utilisateur Ui qui joue le rôle de mineur dans la chaîne de blocs CB : - vérifie la signature de la transaction TR_AB avec la clé publique de Bob KEYBPUB ; 13 - exécute, pour générer le contrat personnalisé SCAB, la méthode GEN_CTRT_SPEC du contrat intelligent SCGA en prenant pour paramètres les données des champs COND, DATE et SIGN de la transaction TR_AB ; - insère le contrat personnalisé SCAB dans un registre d'adresse @SCAB de la chaîne de blocs CB ; et - rediffuse la rediffuse la chaîne de blocs CB. [0080] Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB ; Alice peut ainsi prendre connaissance du contrat SCAB personnalisé conclu avec Bob. [0081] Dans le mode de réalisation décrit ici, la méthode GEN_CTRT_SPEC vérifie que les conditions du champ COND posées par Bob sont acceptables avant de générer le contrat personnalisé SCAB. [0082] Il est fondamental de constater que le propriétaire du contrat SCAB dans la chaîne de blocs est le contrat intelligent SCGA et non pas Bob. En particulier, le contrat SCAB n'est pas signé avec la clé privée KEYB,,, de Bob. Le contrat SCAB est finalisé par le contrat intelligent SCGA à partir des conditions spécifiques de Bob niais le terminal TB de Bob n'intervient ni pour la génération du contrat personnalisé SCAB ni pour son enregistrement dans la chaîne de blocs. L'homme du métier des chaînes de blocs comprendra que le contrat intelligent SCGA peut toujours être vérifié puisqu'il est enregistré dans la chaîne de blocs CB. [0083] Nous supposons maintenant qu'un autre utilisateur inscrit dans la chaîne des blocs, par exemple Charly, décide, comme Bob à l'étape B70, de répondre à la proposition de contrat d'Alice en invoquant la méthode de souscription SUBS_SCGA du contrat intelligent SCGA. [0084] L'exécution de cette méthode génère alors l'affichage du formulaire Web FORM_CS dans le navigateur du terminal de Charly. [0085] Au cours d'une étape similaire à l'étape B80 précédemment décrite, Charly peut fixer ses propres conditions d'acceptation et diffuser une transaction TR_AC, signée avec sa clé privée KEYCpRiv à destination des utilisateurs de la chaîne de blocs. [0086] Cette transaction TR_AC est similaire à celle TR_AB de Bob. Elle comporte : - l'adresse @C de la clé publique de Charly KEYC,B dans la chaîne de blocs CB ; - l'adresse @SCGA du contrat intelligent SCGA dans la chaîne de blocs CB ; - l'identifiant GEN_CTRT_SPEC de la méthode de ce contrat à exécuter pour générer SCAB; - des champs COND, DATE et SIGN qui reprennent les conditions, la date et la signature de Charly édités dans les champs « Cond », « Date » et « Sign » du formulaire FORM_SC et qui devront servir de paramètres à la méthode GEN_CTRT_SPEC pour générer un contrat personnalisé SCAC entre Alice et Charly. 14 [0087] Bien entendu, si les termes de la proposition de contrat lui conviennent tels quels, Charly peut ne pas fixer de conditions d'acceptation. [0088] Au cours d'une étape similaire à l'étape U90 déjà décrite, un utilisateur Ui jouant le rôle de mineur dans la chaîne de blocs CB : - vérifie la signature de la transaction TRAC avec la clé publique de Charly KEYC PUB ; - exécute la méthode GEN CTRT SPEC du contrat intelligent SCGA avec les données des champs COND, DATE et SIGN de la transaction TRAC ; - insère le contrat personnalisé SCAC dans un registre d'adresse @SCAC de la chaîne de blocs CB ; et - rediffuse la rediffuse la chaîne de blocs CB. [0089] Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB ; Alice peut ainsi prendre connaissance du contrat personnalisé SCAC conclu avec Charly. [0090] Le propriétaire du contrat SCAC dans la chaîne de blocs est le contrat intelligent SCGA et non pas Charly ; le contrat SCAC n'est pas signé avec la clé privée KEYC,,,,, de Charly. [0091] La figure 8 représente la chaîne de blocs CB. Il est fondamental de constater qu'elle comporte : - la proposition de contrat SCGA d'Alice ; et - deux contrats personnalisés SCAB. SCAC, générés par SCGA, et propiiétés de SCGA. [0092] Une copie de cette chaîne est mémorisée par les terminaux TA, TB, TC et Ui. [0093] A titre d'exemple, @A est un pointeur permettant de retrouver la clé KEYApu. d'Alice dans la chaine de blocs. 15 REVENDICATIONS[Revendication I] Procédé de diffusion, dans un réseau de télécommunications, d'une pro- position de contrat (SCGA) proposée par une première partie (A), cc procédé comportant : - unc étape (A40) de génération d'un contrat intelligent (SCGA) comportant : - l'adresse (@A) d'un registre comportant une clé publique (KEYA,,H) de ladite première partie (Alice) dans une chaîne de blocs (CB) ; - des données (TERMES) représentatives des ternies de ladite proposition de contrat ; - une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat ; - une étape (A50) de signature dudit contrat intelligent (SCGA) avec une clé privée (KEYAr',,,v) de ladite première partie (Alice) ; et - une étape (A50) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs. [Revendication 2] Procédé de diffusion d'une proposition de contrat selon la revendication 1 dans lequel ledit contrat personnalisé est un contrat intelligent. [Revendication 3] Procédé de diffusion d'une proposition de contrat selon la revendication 1 ou 2 dans lequel ladite méthode de génération de souscription (SUBS_SCGA) est configurée pour obtenir des conditions d'acceptation (Cond) de la proposition de contrat par ladite deuxième partie (Bob, Charly), lesdites conditions d'acceptation faisant partie des paramètres compris clans ladite transaction (TR_AB) utilisés pour générer ledit contrat personnalisé (SCAB). [Revendication 4] Procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte 16 une étape (A10) de téléchargement d'un agent informatique (AG) auprès d'un serveur (SRV COMP), cet agent comportant : - un module (AG REDA) pour obtenir, de ladite première partie (A), lesdites données (TERMES) représentatives des termes de ladite proposition de contrat ; et - un module (AG DIFF) pour générer ledit contrat intelligent (SCGA) à partir desdites donnees (TERMES) et pour diffuser ledit contrat intelligent (SCGA) dans ledit réseau. [Revendication 5] Procédé de diffusion d'une proposition de contrat selon la revendication 4, caractérisé en ce que ledit agent comporte en outre un module (AG SIGN) pour signer ledit contrat intelligent (SCGA) avec la clé privée (KEYAp',,) de ladite première partie (Alice). [Revendication 6] Programme d'ordinateur (PROGA) comportant des instructions pour l'exécution des étapes du procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté par un ordinateur (TA). [Revendication 7] Support d'enregistrement lisible par un ordinateur sur lequel est en- registré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 5. [Revendication 8] Procédé d'acceptation d'une proposition de contrat diffusée dans un réseau de télécommunications, ce procédé étant mis en oeuvre par un terminal (TB) d'un utilisateur (Bob) et comportant : - une étape (B70) d'obtention d'un contrat intelligent (SCGA) enregistré dans une chaîne de blocs (CB), ledit contrat intelligent comportant : - l'adresse (@A), dans ladite chaîne de blocs (CB), d'un registre comportant une clé publique (KEYA,,,,B) d'une première partie (Alice) propriétaire de ladite proposition de contrat ; - des donnees (TERMES) représentatives de termes de ladite proposition de contrat ; - une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à 17 partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) fournis par ladite deuxième partie (Bob, Charly) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat; - une étape d'obtention de paramètres (COND, DATE, SIGN) représentatifs d'une volonté dudit utilisateur (Bob) d'accepter les termes de ladite proposition de contrat ; - une étape (B70) d'exécution de ladite méthode de souscription (SUBS SCGA), ladite exécution déclenchant la diffusion (B80) dans le réseau d'une transaction (TR AB), signée avec une clé publique (KEYBPUB) dudit utilisateur (Bob) et comportant : - l'adresse (@B) d'une clé publique (KEYBp') dudit utilisateur (Bob) dans la chaîne de blocs (CB) ; - l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ; - un identifiant de ladite méthode (GEN CTRT SPEC) de génération de contrat; et - lesdits paramètres. [Revendication 9] Programme d'ordinateur (PROGB) comportant des instructions pour l'exécution des étapes du procédé d'acceptation de proposition de contrat selon la revendication 8 lorsque ledit programme est exécuté par un ordinateur (TB). [Revendication 10] Support d'enregistrement lisible par un ordinateur sur lequel est en- registré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'acceptation d'une proposition de contrat selon la revendication 8. [Revendication 11] Dispositif de diffusion, dans un réseau de télécommunications, d'une proposition de contrat (SCGA) proposée par une première partie (A), ce dispositif comportant : - un module (AG_DIFF) de génération d'un contrat intelligent (SCGA) comportant : - l'adresse (@A) d'un registre comportant une clé publique (KEYAPUB) de ladite première partie (Alice) dans une chaîne de blocs (CB) - des donnees (TERMES) représentatives des termes de ladite proposition de contrat ; - une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) 18 [Revendication 12] [Revendication 13] dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté dc la deuxième partie (Bob, Charly) d'accepter les termes de la proposition dc contrat ; - un module (AG DIFF) de signature dudit contrat intclligcnt (SCGA) avec une clé privée (KEYAPRIV) de ladite première partie (Alice) ; et - un module (AG DIFF) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs. Dispositif de diffusion selon la revendication 11, caractérisé en cc qu'il comporte : - un module de communication (COM) apte à télécharger un agent (AG) à partir d'un serveur (SRV COMP) ; - un module (11) dc traitement apte à installer ledit agent (AG) dans ledit dispositif (TA, TB) ; - ledit agent (AG) comportant ledit module de génération (DIFF), ledit module de signature (DIFF) et ledit module de diffusion (DIFF). Dispositif (DB) d'acceptation d'une proposition de contrat diffusée dans un réseau de télécommunications, ce dispositif étant mis en oeuvre dans le terminal (TB) d'un utilisateur (Bob) et comportant : - un module (27) d'obtention d'un contrat intelligent (SCGA) enregistré dans une chaîne de blocs (CB), ledit contrat intelligent comportant : - l'adresse (@A), dans ladite chaîne de blocs (CB), d'un registre comportant une clé publique (KEYAPUB) d'une première partie (Alice) propriétaire de ladite proposition de contrat ; - des donnes (TERMES) représentatives de termes de ladite proposition de contrat ; - une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour 19 [Revendication 14] demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat ; - un module (NAV) d'obtention de paramètres (COND, DATE, SIGN) représentatifs d'une volonté dudit utilisateur (Bob) d'accepter les termes de ladite proposition de contrat ; - un module (23) d'exécution de ladite méthode de souscription (SUBS SCGA), ladite exécution déclenchant la diffusion (B80) dans le réseau d'une transaction (TR AB), signée avec une clé publique (KEYBPUB) dudit utilisateur (Bob) et comportant : - l'adresse (@B) d'une clé publique (KEYBPUB) dudit utilisateur (Bob) dans la chaîne de blocs (CB) ; - l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ; - un identifiant de ladite méthode (GEN_CTRT_SPEC) de génération de contrat; et - lesdits paramètres. Procédé de négociation de contrat entre deux parties (Alice, Bob) dans un réseau de télécommunications, ledit procédé comportant: - la génération d'une proposition de contrat (SCGA) par ladite première partie (A), sous la forme d'un contrat intelligent (SCGA) comportant : - l'adresse (@A) d'un registre comportant une clé publique (KEYAPUB) de ladite première partie (Alice) dans une chaîne de blocs (CB) - des donnes (TERMES) représentatives des termes de ladite proposition de contrat ; - une méthode de souscription (SUBS_SCGA) permettant à la deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ; - une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et la dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de la deuxième partie (Bob, 20 Charly) d'accepter les termes de la proposition de contrat; - une étape (A50) de signature dudit contrat intelligent (SCGA) avec une clé privée (KEYAPRIV) de ladite première partie (Alice) ; - une étape (A50) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs ; - une étape (B70) d'obtention dudit contrat intelligent (SCGA) par la deuxième partie (Bob) ; - une étape d'obtention de paramètres (COND, DATE, SIGN) représentatifs d'une volonté de ladite deuxième partie (Bob) d'accepter les termes de ladite proposition de contrat ; - - une étape (B70) d'exécution de ladite méthode de souscription (SUBS SCGA) par un terminal (TB) de ladite deuxième partie (Bob), ladite exécution déclenchant la diffusion (B80) dans le réseau d'une transaction (TR AB), signée avec une clé publique (KEYBPUB) de ladite deuxième partie (Bob) et comportant : - l'adresse (@B) d'une clé publique (KEYBPUB) dudit utilisateur (Bob) dans la chaîne de blocs (CB) ; - l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ; - un identifiant de ladite méthode (GEN_CTRT_SPEC) de génération de contrat; et - lesdits paramètres; - une étape (U90) d'exécution, mise en oeuvre par un dispositif (Ui) de minage de la chaîne de blocs, de ladite méthode (GEN_CTRT_SPEC) de génération d'un contrat personnalisé, avec lesdits paramètres, pour générer un contrat personnalisé (SCAB) entre lesdites parties (Alice, Bob), l'enregistrer dans la chaîne de blocs (CB) et rediffuser la chaîne de blocs (CB).