TITRE : Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d'un réseau de chaîne de blocs et programme d'ordinateur correspondants.

Domaine technique

Le domaine de l’invention est celui des technologies mises en œuvre par ordinateur, et plus particulièrement, de l'échange de biens ou de services reposant sur une technologie de stockage décentralisé d'informations de type chaîne de blocs. Plus précisément, l’invention concerne un mécanisme, mis en œuvre par un contrat intelligent (en anglais « smart contract ») d'une chaîne de blocs, pour la sélection et la mise en relation décentralisée d'un fournisseur de service et d'un client.

Art antérieur

La « blockchain », ou en français chaîne de blocs, est une technologie de stockage et de transmission d'informations transparente, sécurisée, et fonctionnant sans organe central de contrôle. Plus précisément, une chaîne de blocs est une base de données distribuée, qui contient l'historique de tous les échanges effectués entre ses utilisateurs depuis sa création : les informations envoyées par les utilisateurs et les échanges internes à la base de données sont vérifiés et groupés à intervalles de temps réguliers en blocs, formant ainsi une chaîne. L'ensemble est sécurisé par cryptographie.

Plus précisément, les transactions effectuées entre les utilisateurs du réseau sont regroupées par blocs. Chaque bloc est validé par les nœuds du réseau, selon des techniques cryptographiques qui dépendent du type de blockchain. Une fois le bloc validé, il est horodaté et ajouté à la chaîne de blocs, à laquelle tous les utilisateurs ont accès. La transaction est alors visible pour le récepteur, ainsi que pour l'ensemble des nœuds du réseau. Une fois ajouté à la chaîne, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l'authenticité et la sécurité du réseau.

Il existe des chaînes de blocs publiques, ouvertes à tous, et des chaînes de blocs privées, ou de consortium, dont l'accès et l'utilisation sont limitées à un certain nombre d'acteurs définis à l'avance.

Les premières chaînes de blocs ont trouvé des applications dans le domaine de la monnaie numérique, telle que le bitcoin, qui est un exemple de monnaie programmable. Cependant, le caractère décentralisé de la chaîne de blocs, couplé avec sa sécurité et sa transparence, laisse entrevoir des applications bien plus larges que le seul domaine monétaire.

Les infrastructures de chaînes de blocs se sont ainsi récemment enrichies de contrats intelligents, ou « smart contracts », que l'on peut définir comme des programmes autonomes qui exécutent automatiquement les conditions et termes d'un contrat, sans nécessiter d'intervention humaine. En d'autres termes, un contrat intelligent est un programme informatique compilé qui porte un ensemble de caractéristiques lui permettant d'exécuter automatiquement et en autonomie au moins certaines des clauses spécifiques du contrat qu'il porte. L'émergence de ces contrats intelligents ouvre de nouvelles applications aux chaînes de blocs, notamment dans le domaine de l'échange de biens et de services.

En effet, le recours aux places de marché (i.e. aux plateformes de mise en relation entre un fournisseur de service et un demandeur de service) pour la sous-traitance de tâches rencontre à ce jour un certain nombre de problématiques techniques, auxquelles l'infrastructure de chaîne de blocs, couplée à l'utilisation de contrats intelligents, pourrait apporter des solutions efficaces : une numérisation hésitante : le panel d'utilisateurs de la plateforme peut être large et diversifié, ce qui implique souvent que la plateforme de mise en relation soit de préférence simple d'usage et accessible. Elle doit de plus permettre aux acteurs de s'assurer que standards et réglementation en vigueur soient respectés, pour la génération électronique de contrats par exemple. Elle doit par ailleurs prendre en compte l'hétérogénéité des systèmes d'information des systèmes en présence ; une problématique de manque de transparence dans la gestion des données : à ce jour, la mise en relation est le plus souvent effectuée par des plateformes tierces, centralisées. Ces dernières sont souvent enclines à un manque de transparence vis à vis du stockage des informations des acteurs. Elles peuvent également revendre à leur compte les informations extraites de l'agrégation de traces d'évènements. Cette asymétrie des relations peut ainsi favoriser certains monopoles, au détriment d'une gouvernance transparente ; des procédures longues et fastidieuses : le poids des procédures est souvent pointé du doigt. Certaines étapes peuvent être redondantes, peu appropriées, induisent une redondance d'information. Ce poids des procédures génère une lassitude et un coût en ressources monétaires et temporelles. Par ailleurs, les étapes de publication d'offre, de mise en relation, de contractualisation, et de mise en paye induisent un interfaçage en pointillé de chaque étape. Des délais d'exécution en découlent donc ; des processus peu flexibles : le traitement unitaire des tâches, la difficulté d'accès aux données des tâches en cours d'exécution, une qualité de traçage des connexions (en anglais « log ») variable, et l'aspect fastidieux de la génération des tâches, limitent l'optimisation des ressources, pour un re-routage par exemple. Dans ce contexte, une affectation flexible des tâches est donc difficilement envisageable.

Pour répondre à ces différentes problématiques, il a été envisagé, dans certains domaines particuliers tels que la gestion de l'énergie ou l'allocation de ressources informatiques, de concevoir des plateformes de mise en relation utilisant une infrastructure de chaîne de blocs. Ainsi, dans le domaine de la délégation de tâches de calcul, Wang et al. proposent, dans l'article « Permissioned blockchain for efficient and secure resource sharing in vehicular edge computing » (arXiv preprint arXiv:1906.06319), d'utiliser une technique de chaîne de blocs et de contrats intelligents pour un partage efficace et sécurisé de ressources dans le domaine de l'informatique en périphérie appliquée aux véhicules (en anglais « Vehicular Edge Computing »).

Yan et al., dans l'article "Nebula: A blockchain based decentralized sharing computing platform" (In: International Conférence on Blockchain and Trustworthy Systems, pp. 715-731. Springer (2019)), proposent quant à eux une plateforme décentralisée reposant sur une technologie de chaîne de blocs pour le partage de ressources informatiques.

Dans ces deux cas, l'affectation des tâches de calcul aux ressources disponibles se fait selon un algorithme de meilleure répartition. Notamment, Yan et al. proposent d'utiliser l'algorithme hongrois pour résoudre ce problème d'affectation.

Dans le domaine du partage d'énergie (en anglais « smart grids »), on peut citer les travaux de : Troncia et al. (2019), "Distributed ledger technologies for peer-to-peer local markets in distribution networks", Energies, 12(17), 3249 ;

Li, et al. (2017), "Consortium blockchain for secure energy trading in industrial internet of things", IEEE transactions on industrial informatics, 14(8), 3690-3700 ;

Myung, et al. "Ethereum smart contract-based automated power trading algorithm in a microgrid environment", The Journal of Supercomputing76(7), 4904-4914 (2020).

Ces plateformes de mise en relation reposent sur une affectation des ressources aux tâches selon un mécanisme de double enchère, qui met l'accent principal sur le prix lors des phases de négociation.

Si ces différentes solutions de l'art antérieur sont intéressantes en ce qu'elles montrent l'intérêt de l'utilisation des chaînes de blocs et de contrats intelligents dans un contexte de mise en relation de fournisseurs de services et de clients, elles ne permettent pas de répondre à l'ensemble des problématiques mentionnées ci-avant.

Notamment, ces plateformes de mise en relation sont toutes dédiées à des cas d'usage précis, et n'offrent donc pas ou peu de modularité. En outre, les algorithmes de sélection et de tri des ressources ne sont pas optimaux, en ce sens que la tâche ou la ressource est presque toujours affectée au premier offrant.

Il existe donc un besoin d’une technique de mise en relation de fournisseurs de services et de clients, ou de tâches et de ressources, qui ne présente pas l'ensemble des différents inconvénients de l'art antérieur, et qui vise à répondre à aux moins certaines de ces différentes problématiques. Notamment, il existe un besoin d'une telle technique qui aide par exemple à une mise en relation décentralisée, transparente et/ou objective d'une ressource à un besoin donné. Il existe également un besoin d'une telle technique qui aide par exemple à réduire les délais de contractualisation et de paiement par rapport aux plateformes de mise en relation de l'art antérieur. Il existe encore un besoin d'une telle technique qui s'appuie avantageusement sur une infrastructure de chaîne de blocs et de contrats intelligents. Il existe enfin un besoin d'une telle technique qui aide à améliorer la finesse de sélection et de tri des différentes offres de service à des fins de mise en relation optimisée des clients et des fournisseurs.

Exposé de l'invention

L'invention répond à ces différents besoins en proposant un procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs. Selon l'invention, un tel procédé comprend des étapes, mises en oeuvre par un contrat intelligent de la chaîne de blocs, de :

- réception d'une requête de service, la requête comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;

- identification d'au moins une offre de service satisfaisant ledit au moins un critère de sélection de service, dite offre de service candidate, parmi des offres de service enregistrées dans la chaîne de blocs ;

- envoi d'au moins une des offres de service candidates, ladite au moins une offre de service envoyée étant sélectionnée en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés aux offres de service candidates, et enregistrés dans la chaîne de blocs, d'autre part.

Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la mise en relation de donneurs d'ordre et de fournisseurs de service, reposant sur une technologie de chaîne de blocs. En effet, le procédé selon l'invention permet, dans un mode de réalisation, de mettre en relation, de manière transparente et objective, tâches et ressources. Contrairement aux techniques de l'art antérieur, la sélection d'offres de service candidates peut s'effectuer de façon objective et transparente, en fonction d'un historique enregistré de manière sécurisée et infalsifiable dans la chaîne de blocs, et sur la base de critères de sélection établis dans la requête de service. Dans au moins certains modes de réalisation, la mise en oeuvre d'une chaîne de blocs peut aider à garantir l'intégrité des données relatives à la qualité de service associée aux différentes offres de service, ce qui peut aider à sélectionner une offre de service candidate adaptée à la requête de service sur la base de critères de qualité de service fiables et objectifs (par exemple l'offre de service la plus adaptée à la requête de service).

De plus, l'utilisation de la technologie de contrat intelligent de la chaîne de blocs peut aider à réduire les délais de contractualisation et de mise en paiement, grâce à l'exécution autonome de ces règles à l'exécution du service. Dans certains modes de réalisation, ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services.

Dans certains modes de réalisation, ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services émises par une pluralité de dispositifs clients dudit réseau de communication.

Dans certains modes de réalisation, au moins un dispositif client émetteur de ladite au moins une requête de service et/ou au moins un dispositif fournisseur d'au moins une desdites offres de service enregistrées dans ladite chaîne de blocs interagit avec ledit contrat intelligent via au moins une requête de type API (pour « Application Programming Interface » selon la terminologie anglaise ou, en français, interface de programmation d'application) utilisant au moins une fonction implémentée par ledit contrat intelligent et appartenant au groupe suivant :

- une fonction d'enregistrement d'au moins une requête de services et/ou d'au moins une offre de service dans ladite chaîne de blocs;

- une fonction de filtrage d'offres de service enregistrées en fonction d'au moins un critère de sélection de service compris dans au moins une requête de service ;

- une fonction de tri d'offres de service répondant au au moins un critère de sélection compris dans au moins une requête de service ;

- une fonction d'établissement d'un contrat entre un dispositif fournisseur d'au moins une desdites offres de service et un dispositif éclient émetteur d'au moins une desdites requêtes de service;

- une fonction d'enregistrement dans ladite chaîne de blocs d'une qualité de service correspondant à un service fourni.

Dans certains modes de réalisation, lesdites fonctions dudit contrat intelligent mettent en oeuvre des règles de consensus.

Selon un premier aspect, les offres de service envoyées sont triées en fonction d'un score de qualité de service calculé pour une offre de service candidate, à partir de ladite au moins une règle de qualité de service d'une part, et de l'historique de services, associés à l'offre de service candidate. Il est ainsi très facile pour le client d'opérer une sélection avisée et objective de la meilleure offre de service, selon ses critères de choix.

En effet, selon un autre aspect, ladite au moins une règle de qualité de service est une combinaison pondérée de critères de sélection de service enregistrés dans la chaîne de blocs. Le client peut ainsi affecter des poids plus importants aux critères qui lui semblent les plus importants, et identifier facilement l'offre la plus susceptible de répondre à ses attentes. Selon encore un autre aspect, la requête de service comprend également une durée de validité de la requête de service. Ainsi, à expiration de cette durée, la prise en compte de la requête de service cesse automatiquement.

Selon un aspect complémentaire, l'identification d'offres de service candidates est itérée, selon un paramètre de périodicité de relance associé à la requête de service par exemple, et jusqu'à la fin de la durée de validité, tant qu'aucune offre de service candidate n'a été identifiée. Le paramètre de périodicité de relance peut avantageusement être défini, par le client ou directement au sein de la chaîne de blocs, pour optimiser la mise en relation entre donneur d'ordre et fournisseur de service. Dans un tel mode de réalisation, l'émetteur de la requête de service peut ainsi être assuré qu'une offre de service candidate soit recherchée, tant que son besoin n'a pas été satisfait.

Selon un mode de réalisation, un service de l'historique peut être enregistré dans la chaîne de blocs en association avec un ensemble de valeurs affectées aux critères de sélection de service pour le service. Ainsi, toutes les conditions d'exécution de services passés peuvent être enregistrées de façon sécurisée et infalsifiable dans la chaîne de blocs, ce qui constitue une assurance efficace, pour l'émetteur de la requête de service, de la fiabilité de l'évaluation des offres de service candidates.

Selon un mode de réalisation, le score de qualité de service est calculé par moyenne mobile pondérée ou exponentielle des valeurs des services de l'historique, en fonction de ladite au moins une règle de qualité de service.

Notamment, lors de l'évaluation des offres de service candidates, le score de qualité de service est par exemple calculé par moyenne pondérée des valeurs des critères de sélection entrant dans la règle de qualité de service. Après exécution du service, le score de qualité de service associé à l'offre de service sélectionnée est par exemple mis à jour par calcul d'une moyenne mobile pondérée ou exponentielle, de façon par exemple à donner plus d'importance aux services rendus les plus récemment, mais sans supprimer cependant l'effet des valeurs des services les plus anciens.

Selon une autre caractéristique, sur élection d'une des offres de service candidates envoyées, le procédé selon un mode de réalisation de l'invention met en oeuvre une étape de génération d'un contrat liant la requête de service et l'offre de service élue, et une étape d'enregistrement du contrat dans la chaîne de blocs. Ces étapes peuvent notamment être exécutées en autonomie par le contrat intelligent de la chaîne de blocs, ce qui peut aider à améliorer leur rapidité d'exécution, par rapport à certaines techniques de l'art antérieur.

Selon encore un autre aspect, après fourniture du service requis, le procédé comprend des étapes de : - réception et enregistrement, dans la chaîne de blocs, de valeurs affectées aux critères de sélection de service pour le service fourni ;

- mise à jour, dans la chaîne de blocs, d'un statut du service requis.

Ainsi, à chaque nouveau service fourni, ses conditions d'exécution sont enregistrées de façon infalsifiable dans la chaîne de blocs, ce qui permet une mémorisation intègre de la qualité de service associée à chaque offre de service, et constitue donc une assurance, pour un émetteur de requête de service, que la sélection d'une offre de service candidate est fondée sur des critères objectifs, en fonction notamment d'un historique effectif de service.

Selon un autre aspect, la requête de service comprend également au moins un paramètre contextuel d'incitation à la fourniture du service, et sur élection d'une des offres de service candidates envoyées, le procédé met en oeuvre une étape de mise sous séquestre de l'incitation à la fourniture du service, dans la chaîne de blocs. Une telle incitation peut consister par exemple en une caution ou une gratification, qui pousse avantageusement le fournisseur de service à offrir la meilleure qualité de service possible.

Selon encore un autre aspect, en fonction du statut du service mis à jour, il met en oeuvre une étape de paiement d'un fournisseur du service et, le cas échéant, de libération de l'incitation mise sous séquestre. A nouveau, ces étapes peuvent être par exemple mises en oeuvre de façon autonome et automatique par le contrat intelligent de la chaîne de blocs, ce qui aide à améliorer leur rapidité d'exécution par rapport à certaines techniques de l'art antérieur, et constitue donc une garantie incitative intéressante pour le fournisseur de service.

Selon encore une autre caractéristique, un tel procédé comprend également des étapes, mises en oeuvre par un contrat intelligent de la chaîne de blocs, de :

- réception d'une offre de service ;

- enregistrement de l'offre de service dans la chaîne de blocs.

Ainsi, l'émetteur d'une requête de service est assuré que les conditions associées à une offre de service ne puissent être modifiées après que l'offre ait été formulée, ce qui constitue une garantie supplémentaire.

L'invention concerne également un nœud appartenant à un réseau de chaîne de blocs, configuré pour exécuter un contrat intelligent de la chaîne de blocs. Un tel nœud comprend :

- au moins un processeur ; et

- au moins une mémoire lisible par ordinateur couplée audit au moins un processeur et dans laquelle sont enregistrées des instructions de code de programme exécutables par ledit au moins un processeur pour mettre en œuvre le procédé de fourniture de service tel que décrit précédemment. L'invention concerne encore un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur.

L'invention concerne encore un dispositif client d'un réseau de communication, qui comprend :

- un module d'émission d'une requête de service, la requête comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;

- un module de réception d'au moins une offre de service candidate, satisfaisant ledit au moins un critère de sélection de service, et sélectionnée, parmi des offres de service enregistrées dans une chaîne de blocs du réseau de communication, en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés aux offres de service candidates, et enregistrés dans la chaîne de blocs, d'autre part.

Selon un aspect d'un tel dispositif client, le module d'émission est également configuré pour émettre des valeurs affectées aux critères de sélection de service pour un service fourni, destinées à être enregistrées dans la chaîne de blocs.

L'invention vise encore un dispositif fournisseur d'un réseau de communication, qui comprend :

- un module d'émission d'une offre de service comprenant au moins un critère de sélection de service et destinée à être enregistrée dans une chaîne de blocs du réseau de communication ;

- un module de réception d'un contrat liant une requête de service enregistrée dans la chaîne de blocs et l'offre de service émise, sélectionnée, parmi des offres de service enregistrées dans la chaîne de blocs, en fonction d'au moins une règle de qualité de service contenue dans la requête de service d'une part, et d'un historique de services, associés au dispositif fournisseur, et enregistrés dans la chaîne de blocs, d'autre part.

L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de fourniture de service selon l'invention tel que décrit ci- dessus.

Un tel support 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 une clé USB ou un disque dur.

D’autre part, un tel support d’enregistrement peut être un support transmissible 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, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support 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é de fourniture de service précité.

Le dispositif client et le dispositif fournisseur, le nœud et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de fourniture de service selon la présente invention.

Présentation des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

La figure 1 présente sous forme de schéma synoptique une architecture du système de fourniture de service selon un mode de réalisation de l'invention ;

La figure 2 illustre sous forme synoptique une phase préliminaire d'instanciation de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention ;

La figure 3 décrit sous forme de schéma synoptique une phase d'enregistrement d'offres de service dans la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention ;

La figure 4 présente sous forme de schéma synoptique les étapes mises en œuvre au sein de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention, lorsqu'un terminal client émet une requête de service ;

La figure 5 présente sous forme de schéma synoptique les étapes mises en œuvre au sein de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention, après fourniture d'un service ;

La figure 6 propose un diagramme séquentiel des différentes interactions entre fournisseur de service, donneur d'ordre et plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention.

Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention repose sur l'utilisation d'une structure de chaînes de blocs, dans un réseau de communication, pour concevoir une plateforme de mise en relation de clients et de fournisseurs de service, aidant à une affectation décentralisée, transparente et/ou objective d'offres de service aux demandes de service formulées par les clients.

On présente désormais, en relation avec la figure 1, l'architecture d'un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l'invention. Un tel système comprend un réseau de chaînes de blocs 100, également appelé par la suite réseau blockchain 100, comprenant une pluralité de nœuds NI à N5 interconnectés les uns aux autres. La structure du nœud NI est illustrée plus en détail. Chaque nœud N2 à N5 présente une architecture similaire à celle du nœud NI, bien que cela n'ait pas été détaillé, par souci de simplification, sur la figure 1. Ainsi, dans certains modes de réalisation, le nœud NI peut comprendre :

- une machine virtuelle Ethereum EVM 10, qui est l'environnement d'exécution des contrats intelligents dans Ethereum. On rappelle qu'Ethereum est un protocole d'échanges décentralisés permettant la création, par les utilisateurs, de contrats intelligents grâce à un langage Turing- complet ;

- une zone de stockage de données STOR 12 ;

- le code à octets (en anglais « bytecode ») du contrat intelligent SC 11, i.e. le code déterministe exécutable sur le réseau blockchain 100, dont les variables peuvent être stockées sur le réseau 100, et dont les fonctions peuvent être appelées moyennant des fonds suffisants.

Le système dorsal (ou « backend ») de la plateforme de fourniture de service est ainsi décentralisé, et réside dans le contrat intelligent SC 11 implémentant un panel de fonctions nécessaires à la mise en relation de fournisseurs de service et de donneurs d'ordre. Comme on le verra plus en détail par la suite, ces fonctions qui peuvent être implémentées par le contrat intelligent SC 11 sont les suivantes :

Register(), pour l'enregistrement de requêtes de services ou d'offres de service dans le réseau blockchain 100 ;

Filter(), pour le filtrage des offres de service en fonction de critères de sélection de service listés dans une requête de service ;

Sort(), pour le tri des offres de service répondant aux critères stipulés dans la requête de service ; generateContract(), pour l'établissement d'un contrat entre un fournisseur de service et un donneur d'ordre ; updateQoSQ, pour l'enregistrement dans le réseau blockchain 100 d'une qualité de service correspondant à un service fourni.

Les utilisateurs de la plateforme sont par exemple les fournisseurs de service 101 et les donneurs d'ordre, ou clients, 102. Ils peuvent interagir avec la plateforme via leur interface, ou frontend.

Des requêtes API (pour « Application Programming Interface », en français, interface de programmation d'application) permettent l'interaction entre les utilisateurs 101, 102 d'une part, et le contrat intelligent SC 11 déployé sur le réseau blockchain 100 d'autre part.

Le dispositif client d'un donneur d'ordre 102 peut comprendre un module d'émission/réception RX/TX 1020, configuré pour émettre des requêtes de service à destination de la plateforme 100 ainsi qu'une évaluation d'un service fourni, et pour recevoir des offres de service candidates, sélectionnées par la plateforme 100. Un tel dispositif client peut comprendre notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l'émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).

Le dispositif fournisseur d'un fournisseur de service 101 comprend un module d'émission/réception RX/TX 1010, configuré pour émettre des offres de service à destination de la plateforme 100, et pour recevoir des contrats, établis par la plateforme 100 lorsqu'une offre de service a été élue pour répondre à une requête de service d'un dispositif client 102. Un tel dispositif fournisseur comprend notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l'émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).

Les transactions répertoriées et validées entre les fournisseurs de service 101 et les clients 102 peuvent être stockées sous forme de blocs dans les noeuds NI à N5 de la chaîne de blocs 100. Des règles de consensus peuvent aider à limiter les noeuds malveillants, et à repérer les transactions invalidées. Des règles cryptographiques peuvent aider à assurer un pseudo-anonymat des transactions et des utilisateurs, et l'authenticité de l'historique de services des fournisseurs 101.

Le terme nœud peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui- même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Plus généralement, un nœud Ni comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur, représentatif des instructions de code du contrat intelligent SC 11, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive avant d’être exécutées par le processeur de l’unité de traitement.

La figure 1 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un nœud Ni, afin qu'il effectue les étapes du procédé détaillé ci-après, en relation avec les figures 2 à 6 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le nœud Ni est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Selon un mode de réalisation de l'invention, la plateforme de mise en relation 100 se veut générique, en ce sens qu'elle ne s'inscrit pas dans un cas d'usage particulier, mais peut trouver des applications dans des domaines divers, tels que l'agriculture, la logistique maritime, la logistique de transport routier, les services à la personne, la production industrielle, l'énergie, etc. Comme illustré par la figure 2, il peut donc être nécessaire, avant que la plateforme 100 ne devienne pleinement opérationnelle, de prévoir un temps d'instanciation de la plateforme 100 pour l'adapter par exemple au domaine d'application souhaité par l'utilisateur. Notamment, l'ouverture du réseau 100 peut être réglable à l'instanciation (de la chaîne de blocs publique aux chaînes de blocs permissionnées, et aux chaînes de blocs privées). Ainsi, cet utilisateur peut être un acteur privé dans le cas d'une chaîne de blocs privée, ou un consortium d'acteurs, dans le cas d'une chaîne de blocs de consortium. Par exemple, l'instanciation de la plateforme 100 peut être réalisée par un consortium d'entreprises de transport, dans le cas d'une plateforme dédiée au transport de marchandises.

La figure 2 illustre ce temps d'instanciation par un utilisateur, qualifié d'utilisateur mère, que l'on pourrait noter en anglais « Field Authority » FA 20. Dans l'exemple donné ci-avant, cet utilisateur mère FA 20 est le consortium d'entreprises de transport, qui se sont préalablement mises d'accord sur les paramètres d'instanciation de la plateforme 100.

Ainsi, au cours d'une phase d'initialisation INIT 21 des règles de la plateforme 100, l'utilisateur mère FA 20 peut par exemple spécifier :

- le corps de contrat légal attendu CONT 22, par exemple une lettre de voiture dans le cas d'un transport de marchandise. Ce corps de contrat CONT 22 est stocké dans le contrat intelligent SC 11. Il s'agit d'un contrat type, correspondant au type de fourniture de service auquel la plateforme 100 va être dédiée, que l'on pourra noter par la suite C ;

- l'ensemble P des critères de sélection objectifs CSEL 23 pouvant être choisis par les donneurs d'ordre 102 pour formuler une requête de service adressée à la plateforme 100. Les fournisseurs de service 101 devront renseigner ces différents critères de sélection lors de la proposition d'une ressource, ou offre de service, sur la plateforme de mise en relation 100.

Par exemple, dans l'exemple d'une application logistique pour des entreprises de transport, les critères de sélection P peuvent comprendre : le poids du colis à livrer ; le volume du colis à livrer ; la zone géographique de prise en charge du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; la zone géographique de livraison du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; le type d'équipement utilisé pour la livraison ; le prix ; le temps qui s'écoule entre la prise en charge et la livraison du colis ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber

Identity »).

Dans le mode de réalisation illustré, après finalisation de cette phase d'instanciation, la plateforme 100 est opérationnelle pour procéder à un enregistrement des ressources proposées par différents fournisseurs de biens ou de services 101, comme illustré par le schéma synoptique de la figure 3.

En effet, les fournisseurs de service 101 intéressés et autorisés par l'utilisateur mère FA 20 peuvent proposer leurs services à la plateforme 100, pour qu'ils soient référencés dans un catalogue de services enregistré dans la chaîne de blocs. Cet enregistrement des offres de service dans la chaîne de blocs constitue une sécurisation forte pour les clients 102 potentiels, car elle leur garantit que les fournisseurs de service 101 ne puissent pas modifier les paramètres de l'offre de service qu'ils proposent (prix, délai, quantité, type d'équipement, etc.) après contractualisation.

Ainsi, au cours d'une étape Add_NR 31, le fournisseur de service 101-1 adresse à la plateforme de mise en relation 100 un descriptif de son offre de service, selon l'ensemble P des différents critères de sélection CSEL 23 définis lors de la phase d'instanciation de la plateforme ; de même, au cours d'une étape Add_NR 32, le fournisseur de service 101-2 adresse à la plateforme de mise en relation 100 un descriptif de son offre de service, selon l'ensemble P de critères de sélection. Par exemple, dans l'exemple précédent d'une application logistique pour des entreprises de transport, le fournisseur de service 101-1 peut, au cours de l'étape Add_NR 31, décrire une offre de service conforme aux critères de sélection P suivants : le poids du colis à livrer : inférieur ou égal à 150 kg ; le volume du colis à livrer : inférieur ou égal à 2 m ³ ; la zone géographique de prise en charge du colis : une zone de 30km de rayon autour d'une ville A ; la zone géographique de livraison du colis : une zone de 200km de rayon autour de la ville A ; le type d'équipement utilisé pour la livraison : un camion hybride ou 100 % électrique équipé pour le transport de produits frais, identifié par son modèle et sa référence constructeur ; le prix, exprimé par exemple en € par kilomètre ; le temps qui s'écoule entre la prise en charge et la livraison du colis, par exemple une garantie de livraison en 48h ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber Identity ») ; les certifications du livreur (e.g. transport de produits frais / produits chimiques / autorisation de livraison à l'international etc.).

A réception, le contrat intelligent SC 11 peut enregistrer les offres reçues des fournisseurs de service 101-1 et 102-2 dans la chaîne de blocs 100, au cours d'une étape Update_RC 33. Le catalogue de ressources enregistré dans la chaîne de blocs peut spécifier, pour au moins certaines d'entre elles (par exemple chacune), les valeurs de critères de sélection P spécifiés dans les offres transmises par les fournisseurs de service 101. En outre, dans certains modes de réalisation, un fournisseur de service 101 peut disposer d'une pseudo-identité sur la chaîne de blocs 100, qui est associée à un historique de services précédemment fournis par ses soins.

Dans certains modes de réalisation, la mise à jour du catalogue de ressources et d'offres de service illustrée par la figure 3 peut se faire en continu, tout au long de la durée d'opération de la plateforme de mise en relation 100 : de nouveaux fournisseurs de service peuvent proposer leurs ressources ; de même, des fournisseurs de service déjà enregistrés sur la plateforme 100 peuvent mettre à jour leurs offres de service, et notamment les valeurs affectées aux différents critères P de sélection (par exemple mise à jour du prix, du délai garanti, ou du type d'équipement). Lorsqu'un client (ou donneur d'ordre) 102 souhaite formuler une demande de service, il peut adresser une requête de service 40 à la plateforme 100, comme illustré par la figure 4.

Cette requête de service 40, que l'on peut noter Req[S,, T, dT, R, I], peut comprendre des critères de sélection [S,, T, dT], où :

- S, est un sous-ensemble des critères de sélection P définis lors de l'instanciation de la plateforme 100, correspondant aux critères de sélection retenus par le donneur d'ordre 102 pour répondre à son besoin,

- T est la durée de vie de la requête de service, et

- dT est la fréquence de relance en cas d'absence d'allocation d'un fournisseur de service à l'exécution de la requête de service 40.

On notera qu'en variante, la fréquence de relance dT peut être définie par l'utilisateur mère lors de l'instanciation de la plateforme. Par exemple, parmi l'ensemble des critères P permettant de définir les besoins du client 102, celui-ci peut ne s'intéresser, dans la formulation de sa requête, qu'à un sous-ensemble S,, à savoir : le poids du colis à livrer : 40 kg ; le volume du colis à livrer : 1 m ³ ; la zone géographique de prise en charge du colis : ville A ; la zone géographique de livraison du colis : ville B ; le prix, qui doit être inférieur à 100€ ; le type de camion, qui doit être électrique ; les certifications du livreur, qui doit être habilité pour le transport de produits frais.

En revanche, la durée de la livraison, et l'identifiant du livreur peuvent être secondaires pour le client 102, qui peut donc ne pas spécifier la valeur de certains de ces critères de sélection CSEL 23 dans sa requête de service 40.

En outre, dans certains modes de réalisation, le donneur d'ordre 102 peut spécifier, dans la requête de service 40, des règles de qualité de service, ou QoS, minimales souhaitées, notées R. Notons N le nombre de critères de sélection CSEL définissant l'ensemble P de critères de sélection instanciés sur la plateforme 100. Une règle de QoS R peut être par exemple une combinaison booléenne des critères de sélection de P où V j e | [0, N ] | , Pj peut être pondéré d'un facteur Xj e [0,1]. Par exemple, si le client 102 est attaché à ce que le délai de livraison soit respecté et que le coût reste maîtrisé, il peut spécifier une règle R de QoS, dans laquelle un poids de 1 sera affecté aux critères de sélection de P correspondant à la durée de livraison et au prix, et un poids nul sera affecté aux autres critères de sélection de l'ensemble P.

Dans un autre exemple, une règle R de QoS est construite à partir de deux métriques (N=2), à savoir l'expérience du livreur, et le respect des délais de livraison. Le client 102 affecte par exemple un poids pl=0,6 à la métrique Q1 relative au critère PI d'expérience du livreur et un poids p2=0,8 à la métrique Q2 relative au critère P2 de respect des délais (). Les valeurs des métriques du livreur peuvent toutes deux être normalisées entre 0 et 1. La règle R de QoS peut alors s'exprimer sous la forme : R = (pl.Ql + p2.Q2)/N

Si la métrique relative à l'expérience du livreur Q1 vaut 0,7 et que la métrique Q2 relative au respect des délais Q2 vaut 1 (il n'y a jamais eu de retard), alors le score de QoS du livreur pour la règle R sera :

QoS = (pl.Ql + p2.Q2)/N = (0,6 x 0,7 + 0,8xl)/2=0,61

Enfin, dans certains modes de réalisation, la requête de service 40 peut également contenir des incitations optionnelles I, proposées par le donneur d'ordre 102 pour inciter le fournisseur de services qui sera sélectionné à fournir la meilleure qualité de service possible. Ces incitations optionnelles I peuvent prendre la forme par exemple d'une gratification du fournisseur de service en cas de satisfaction du client (par exemple si le service est rendu à l'avance), d'un appel à un service d'audit en cas de litige, ou encore d'une caution demandée pour la prise en charge du service.

Un exemple d'incitation optionnelle est une caution du fournisseur de service lors de la prise en charge du service (par exemple, une caution de 0,3 fois la valeur de la marchandise prise en charge dans le camion). Elle peut être mise sous séquestre par exemple jusqu'à l'exécution du service demandé.

Si la livraison se passe sans encombre, la caution peut être reversée dans son intégralité au fournisseur de service. Sinon, dans l'hypothèse où le fournisseur de service disparaît avec la marchandise, celle-ci peut être versée automatiquement au donneur d'ordre. Une telle incitation encourage donc ainsi une exécution favorable du service.

Lors de ou après la réception de la requête de service 40, le contrat intelligent SC 11 peut procéder à un filtrage 41 des ressources disponibles dans le catalogue de ressources mis à jour lors de l'étape référencée 33, sur la base notamment des critères de sélection S, spécifiés dans la requête 40.

Dans certains modes de réalisation, si, lors d'une étape 42 d'identification des offres de service compatibles avec la requête de service 40, aucune offre de service répertoriée dans le catalogue enregistré sur la chaîne de blocs 100 ne correspond à l'ensemble des critères de sélection S, spécifiés par le client 102, le contrat intelligent SC 11 peut réitérer le filtrage 41 après un intervalle de temps dT, correspondant par exemple à la fréquence de la relance en cas d'échec de l'allocation de ressource au client 102. Selon les modes de réalisation, cette itération du filtrage 41 peut être répétée un nombre M de fois (M entier strictement positif) ou tant que la durée de vie T de la requête de service n'a pas expiré. On notera que dT peut être fixé à zéro, soit dans la requête de service 40, soit lors de l'instanciation de la plateforme. Dans ce cas, le filtrage n'est pas réitéré, et si aucune offre service candidate n'est identifiée lors de l'étape référencée 42, la demande de service est annulée, et le donneur d'ordre 102 en est notifié par la plateforme 100.

Si, en revanche, lors de l'étape 42 d'identification des offres de service compatibles avec la requête de service 40, le contrat intelligent SC 11 identifie plusieurs offres de service satisfaisant les critères de sélection S, spécifiés dans la requête de service 40, il peut procéder, au cours d'une étape référencée 43, à un tri multi-objectifs (SORTQ) pour obtenir un profil (par exemple obtenir le meilleur profil) parmi l'ensemble des offres de service identifiées.

Ce tri 43 peut être fondé par exemple sur au moins certaines des règles de QoS R fixées par le donneur d'ordre 102. Par exemple, pour chacune des offres candidates identifiées lors de l'étape référencée 42, les valeurs des critères de sélection entrant dans le calcul des règles R de QoS peuvent être extraites du journal des évènements enregistrés dans la chaîne de blocs 100 pour le fournisseur de service 101 ayant émis l'offre de service candidate. Le calcul du score de QoS affecté à des offres de service candidates se fait par exemple par calcul d'une moyenne pondérée, à partir des critères de sélection entrant dans la règle de QoS R. Par exemple, si dix services ont déjà été rendus par le fournisseur de service 101 et enregistrés dans un historique de services de ce fournisseur dans la chaîne de blocs 100, ils peuvent être tous dix pris en compte pour le calcul de la note de QoS qui lui est affectée.

Le tri 43 des scores de QoS des offres candidates peut s'obtenir par exemple avec la formule suivante :

SORT(Q) = DESCENDING_SORT([ åj pij Normj(Qij) V i e Offres de service])

Plus précisément, on normalise d'abord les paramètres de QoS pour chacune des offres candidates, par exemple pour chacun des livreurs (Normj(Qij)).

Une fois cette normalisation obtenue, on applique une moyenne pondérée (åj pij Normj(Qij)).

On vient effectuer un tri par ordre décroissant (DESCENDING_SORT) de la liste obtenue. On peut alors en extraire la note maximale.

On considère par exemple une règle de QoS R, dans laquelle entrent en compte trois métriques correspondant à trois critères de sélection PI, P2 et P3, et pour laquelle les critères de pondération associés sont les suivants : [pl=0,6, p2=0,4, p3=0,7].

On suppose que quatre livreurs répondent aux critères de sélection établis par le donneur d'ordre 102 pour une livraison de marchandise, et que, pour les trois critères de sélection PI, P2 et P3, chacun des livreurs est noté de la façon suivante :

Livreur 1 = [Qu=l, Q _I2 =2, Qis=3]

Livreur 2 = [Q _2i =2, Q ₂₂ =4, Q ₃ =2]

Livreur 3 = [Q _3i =16, Q ₃₂ =4, Q ₃₃ =4]

Livreur 4 = [Oii=6, Qi ₂ =4, Qi ₃ =4]

Après normalisation de ces paramètres de qualité de service, et pondération, on obtient, selon la formule ci-dessus, la liste des QoS suivante (en %), pour chacun des livreurs 1 à 4 : [QoSl=31, QoS2=26, QoS3=62, QoS4=10]

Le tri 43 par ordre décroissant donne donc [QoS3, QoSl, QoS2, QoS4]

On calcule ainsi, pour au moins certaines des offres de service candidates (par exemple toutes), un score de qualité de service (par exemple QoS3 pour le livreur 3), en fonction des valeurs qui ont été affectées aux différents critères de sélection P, par exemple à l'occasion de services précédemment rendus par les fournisseurs de service, et dont l'évaluation a été enregistrée dans la chaîne de blocs 100. Les offres de service peuvent être triées sur la base de ce score de qualité de service. Dans une première variante de réalisation, les offres de service candidates ainsi triées (Livreur 3 > Livreur 1 > Livreur 2 > Livreur 4) peuvent être envoyées par la plateforme 100 au donneur d'ordre 102, qui peut alors opérer un choix, et élire l'offre de service qu'il souhaite retenir.

Dans une deuxième variante de réalisation, l'élection de l'offre de service est autonome, et peut être effectuée directement par la plateforme 100, qui retient par exemple l'offre présentant le meilleur score de qualité de service (dans l'exemple précédent, le livreur 3).

Le choix de l'une ou l'autre de ces variantes dépend d'une règle qui peut être spécifiée dans le contrat intelligent.

Dans certains modes de réalisation, lorsqu'une offre de service candidate a été élue, le contrat intelligent 11 peut générer, au cours d'une étape GEN_CONT 44, un contrat C, liant l'offre de service élue au donneur d'ordre 102. Ce contrat C, peut être généré par exemple à partir du modèle de contrat CONT qui a été choisi lors de l'étape référencée 22 de la figure 2, pendant la phase d'instanciation de la plateforme. Ce contrat G est enregistré dans la chaîne de blocs 100. Dans certains modes de réalisation, si la requête de service 40 comprenait une ou plusieurs incitations optionnelles, elles peuvent être mises sous séquestre au cours d'une étape référencée 45.

A l'issue de cette phase d'élection et de contractualisation, le service demandé peut être rendu par le fournisseur de service 101. Dans certains modes de réalisation, lors ou après exécution du service, le donneur d'ordre 102 peut par exemple appeler la fonction feedback (en français, retour, réaction ou commentaire) FB du contrat intelligent SC 11, au cours d'une étape référencée 50, comme illustré par la figure 5.

Le donneur d'ordre 102 transmet ainsi à la plateforme 100 un certain nombre de paramètres relatifs à l'exécution du service rendu, correspondant à des valeurs affectées aux critères de sélection de service P : durée effective de la livraison, note de satisfaction du client, intégrité de la marchandise livrée, etc. Par exemple, le donneur d'ordre 102 peut indiquer si les emballages étaient abîmés, et, le cas échéant, fournir des photos attestant de leur état à la livraison.

Les données transmises par le donneur d'ordre 102 peuvent être normalisées avant enregistrement dans la chaîne de blocs 100. Notamment, cette remontée d'informations peut être effectuée par un certain nombre d'objets connectés (loT) associés au donneur d'ordre 102 ou au fournisseur de service 101, qui peuvent fournir à la plateforme 100 des informations sur le service effectué, telles que le temps d'exécution par exemple.

De tels objets connectés (loT) peuvent être par exemple un détecteur d'ouverture de porte, un capteur de température, un capteur d'humidité, ou encore un capteur de poids, qui permettent de fournir des informations sur l'intégrité et la qualité de la marchandise livrée (par exemple sur le respect de la chaîne de froid pour un transport de produits frais). Ainsi, les capteurs de température et d'humidité peuvent par exemple transmettre à la plateforme 100 des diagrammes de température et d'humidité correspondant aux informations qu'ils ont relevées pendant la durée de la livraison.

De tels objets connectés peuvent encore correspondre à des étiquettes de type RFI D ou 5G permettant une identification des lots de marchandise.

La fonction FB du contrat intelligent SC 11 peut opérer alors deux mises à jour dans la chaîne de blocs 100 : une mise à jour 51 du statut du service requis STAT ; et/ou une mise à jour 52 de la qualité de service QoS associée au service rendu par le fournisseur de service, par exemple par calcul de moyenne mobile exponentielle.

On notera que le statut de la tâche STAT correspond à son exécution dans le respect des règles spécifiées dans le contrat intelligent SC 11 (statut positif - e.g. livraison en temps et en heure, avec la bonne marchandise, et avec un ensemble de contraintes environnementales et contextuelles respectées) ou à son non-respect (statut négatif - e.g. dans le cas d'une température seuil dépassée par exemple). L'évaluation du statut STAT est donc dépendant de l'exécution des termes du contrat.

En fonction d'une évaluation 53 du statut, le contrat intelligent SC 11 peut mettre en oeuvre différentes actions.

Si le statut est positif, le contrat intelligent SC 11 peut par exemple procéder, au cours d'une étape PAY 54, au déblocage des fonds associés à l'exécution du contrat : le fournisseur de service 101 reçoit le paiement du service effectué, et éventuellement la gratification optionnelle I prévue dans la requête de service 40, si ces conditions d'obtention sont remplies.

Dans le cas contraire, le contrat intelligent SC 11 peut par exemple envoyer, au cours d'une étape REF référencée 55, la caution du fournisseur de service 101 au donneur d'ordre 102, à titre de dédommagement de l'inexécution du contrat.

Le déroulement du service est tracé, de manière immuable, sur la chaîne de blocs 100. Les informations contenues dans ces traces pourront être utilisées, à l'occasion d'une future requête de service, dans le mécanisme de sélection de fournisseur décrit précédemment en relation avec la figure 4.

La figure 6 illustre, sous forme d'un diagramme séquentiel, une mise en relation de bout en bout entre un donneur d'ordre 102 et un fournisseur de service 101, dans un mode de réalisation de la plateforme 100. Dans l'exemple de la figure 6, on considère que dT=0 , i.e. l'identification d'offres de service candidates répondant aux critères de sélection du donneur d'ordre s'effectue une seule fois : en cas d'absence de candidat, la demande est annulée. La figure 6 illustre les différentes séquences d'interaction entre le fournisseur de service 101, le donneur d'ordre 102, et le contrat intelligent SC 11.

Au cours d'une étape référencée 61, le fournisseur de service 101 enregistre son offre de service auprès de la plateforme 100, en spécifiant les valeurs qu'il a fixées pour les différents critères de sélection P instanciés sur la plateforme. Au cours d'une étape 61, le contrat intelligent SC 11 les enregistre dans la chaîne de blocs 100, et met ainsi à jour le catalogue de ressources associé à la plateforme 100. Il adresse, au cours d'une étape référencée 63, un accusé de réception au fournisseur de service 101, pour lui confirmer l'enregistrement de son offre de service.

Au cours d'une étape référencée 64, un donneur d'ordre 102 adresse une requête de service 40 à la plateforme 100, en spécifiant des critères de sélection, et des règles de qualité de service, comme décrit précédemment en relation avec la figure 4. Le contrat intelligent SC 11 trie alors, au cours d'une étape référencée 65, l'ensemble des offres de service enregistrées sur la plateforme pour identifier la ou les offres candidates, qui satisfont les critères de sélection spécifiés par le client 102. Pour chacune, il calcule un score de qualité de service, en tenant compte par exemple de l'historique des services enregistrés pour chaque fournisseur de service dans la chaîne de blocs 100. Il trie ainsi les offres candidates en fonction de leur score de QoS, et envoi cette liste triée d'offres candidates au donneur d'ordre 102, au cours d'une étape référencée 66.

On suppose ici qu'il existe une ou plusieurs offres candidates susceptibles de répondre au besoin du client 102. Dans le cas contraire, la demande de service est annulée, conformément à l'étape référencée 80.

Le donneur d'ordre 102 élit l'une de ces offres, au cours de l'étape référencée 67, et en informe le contrat intelligent SC 11. Comme indiqué précédemment, en variante, l'élection peut être effectuée de manière automatique, directement par le contrat intelligent SC 11, sans intervention du client 102.

Le contrat intelligent SC 11 génère alors, au cours d'une étape référencée 68, le contrat encadrant la fourniture du service requis, et informe 69 le fournisseur de service qu'il a été sélectionné pour répondre à la requête du client 102. Le fournisseur de service confirme au contrat intelligent SC11 qu'il accepte de rendre le service pour lequel son offre a été élue, au cours d'une étape référencée 70. A réception de cet accord, le contrat intelligent SC 11 initialise 71 le processus de fourniture du service, et adresse des accusés de réception 72 et 73 au donneur d'ordre 102 et au fournisseur de service 101.

Au cours d'une étape référencée 74, le fournisseur de service 101 exécute le service pour lequel il a été choisi. Il en notifie (75) le client 102. Ce dernier peut adresser alors son retour 76 au contrat intelligent SC 11, en donnant par exemple une indication relative à sa satisfaction (appréciation, note de satisfaction, etc.) sur le service rendu, et en spécifiant par exemple les valeurs affectées pour ce service aux différents critères de sélection P. Le retour 76 adressé par le client 102 peut encore consister en une classification effectuée par une brique d'intelligence artificielle (IA). Suivant les traces d’exécution d’un service donné, un réseau préalablement entraîné peut en effet attribuer un label au fournisseur de service 101 (eg: débutant / intermédiaire / expert ...)

Le contrat intelligent SC 11 met alors à jour, au cours d'une étape référencée 77 le statut du service, et la qualité de service QoS du fournisseur de service 101. En fonction du statut du service, comme exposé ci-avant en relation avec la figure 5, il débloque des fonds (étape 79) pour payer le fournisseur de service 101, si le statut du service est positif, ou il transmet (étape 78) au client 102 la caution du fournisseur de service 101, si le statut du service est négatif.

La logistique est un cas d'application de cette plateforme 100 de mise en relation par contrat intelligent SC 11. Prenons l'exemple d'une livraison de colis.

Le donneur d'ordre 102 est à la recherche d'un livreur 101 disponible pour une période T donnée, dont le camion est équipé pour le transport de produits frais. La commande est critique, il souhaite recruter un livreur 101 fiable, qui a eu un minimum de retard durant l'année écoulée. La caution exigée de la part du transporteur peut être spécifiée, ainsi qu'un pourboire si la livraison a de l'avance.

Le donneur d'ordre 102 peut donc poster une demande 40 de livraison avec cet ensemble de critères, pondéré à souhait.

Dans ce scénario de fret, S, serait [M le prix, W le poids disponible minimum, V le volume minimum, E l’équipement, ville A, ville B], R serait [retard minimum, distance minimum, empreinte carbone minimum]. Les incitations facultatives seraient [D le dépôt, t le pourboire]. L’algorithme de tri applique les critères de sélection [Si, T] à la base de ressources enregistrée. Si aucune ressource ne correspond au profil demandé, un rappel est effectué après une période dT. Ces paramètres sont envoyés à la fonction de filtrage du contrat intelligent SC 11. Le filtrage devient positif lorsqu'au moins une ressource, ici un transporteur, remplit les critères de filtrage.

Si ce n'est pas le cas, la demande est mise en attente et réinstanciée jusqu'à la date T à chaque période dT spécifiée par le donneur d'ordre 102. Le donneur d'ordre 102 a la possibilité d'annuler le processus de mise en relation à chaque instant.

Supposons le filtrage positif. Les ressources sont triées suivant leur score de qualité de service QoS. Deux possibilités sont à considérer :

- Le choix de la ressource peut être manuelle, effectuée par le donneur d'ordre

- Le choix de la ressource peut être autonome. La ressource possédant le meilleur score de QoS sera affectée à la demande. A scores de QoS égaux, l'affectation est effectuée de manière aléatoire. Un contrat type e-CMR (document légal pour le transport de marchandise sur route) est généré sur la chaîne de blocs 100. La caution et la gratification peuvent également être mis sous séquestre.

Une fois la livraison effectuée, le donneur d'ordre 102 donne son feedback sur la livraison. Le statut de la tâche est mis à jour, le score de QoS (ici la réputation) du livreur 101 est mis à jour. Si la livraison a été effectuée sans encombre, la caution, et tout ou partie de la gratification sont envoyées au livreur.