FR 3074322 A1 20190531 FR 1761423 A 20171130 Plate-forme de traçabilité sécurisée de données DOMAINE DE L'INVENTION La présente invention concerne le domaine de la gestion des données, et plus précisément une plate-forme de sécurisation et de suivi de l'échange de données. CONTEXTE DE L'INVENTION La prolifération intensive de la technologie numérique engendre la 10 création d'une énorme quantité de données. Chaque donnée possède une certaine valeur inhérente, ce qui fait des données un bien qui fait l'objet de transactions. Les publicités personnalisées sur la base de profils d'utilisateurs constituent un exemple. Par exemple, sur une plate-forme commerciale 15 d'analyse de données, des « fournisseurs » peuvent proposer des modèles de calcul d'apprentissage machine (ML), des ensembles de données d' apprentissage et des modèles d'apprentissage machine « prêts à utiliser », et les « consommateurs » achètent ces données à des fins personnelles. Les modèles d'apprentissage machine et les données d'apprentisssage 20 présentent une certaine valeur inhérente. Les modèles d'apprentissage machine entraînés créent une certaine valeur en combinant les données existantes d'autres fournisseurs, c'est-à-dire en appliquant des ensembles de données d'apprentissage pendant une durée significative. Par exemple, les fournisseurs de données doivent être récompensés si 25 leurs données ont été utilisées pour créer un nouvel ensemble de données qui est vendu sur la plate-forme, comme les modèles d'apprentissage machine formés. Cependant, la simple réutilisation des données constitue une menace pour la propriété intellectuelle. Un utilisateur malhonnête peut, par exemple, légèrement modifier l'ensemble de données (contournant ainsi 2 les contrôles d'intégrité classiques) et proposer le « nouvel » ensemble de données par lui-même. DESCRIPTION GENERALE DE L'INVENTION 5 La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant un moyen de sécurisation et de gestion de l'échange de données. Cet but est atteint par une infrastructure technique distribuée destinée à un système de plate-forme de traçabilité de données basé sur des agents (DTP) comprenant au moins un serveur de base de métadonnées à architecture en couches et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d'approvisionnement en données (DPS), et une machine d'interrogation automatique, caractérisée en ce que la base de données est utilisée pour stocker des données et conserver des preuves sécurisées de l'échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur d'accéder à des ensembles de données (D01, ,DON) fournis par d'autres utilisateurs, et de proposer un ensemble de données accessible par un autre utilisateur, et dans laquelle la plate-forme de traçabilité de données adapte la technologie de chaîne de blocs pour le suivi sécurisé de la propriété d'un ensemble de données (DO) à stocker dans la base de données, et met en place un processus de consensus par fédération (FC), au cours duquel un module de vote décide de la validité d'un bloc afin de stocker le bloc dans la base de données. Selon une autre particularité, le module de vote de chaque agent de la plate-forme de traçabilité de données d'une « fédération DTP », pendant le consensus par fédération (FC), propose un vote individuel sur la validité, et le total cumulé des votes détermine la validité du bloc, au moins la taille et les participants à la fédération DTP, et le seuil de validité étant paramétrables. 3 Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les assertions d'une approche d'accès et de contrôle (AC) dans le cadre 5 d'une transaction, contenant ainsi des informations purement prospectives sur le calcul qui spécifie la logique réelle exécutée. Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle rétrospectif en tirant profit de la fonctionnalité de stockage et de consignation des données afin de maintenir 10 les informations de traitement. Selon une autre particularité, la technologie de chaîne de blocs est adaptée pour comprendre un modèle pro-/rétrospectif mixte avec la fonctionnalité d'un système de gestion de processus distribué (WMS), les informations pro- et rétrospectives étant combinées afin de permettre le suivi 15 du calcul et d'évaluer la fiabilité du résultat du calcul. Selon une autre particularité, l'infrastructure technique distribuée comprend au moins une infrastructure de clés publiques (PKI) qui permet d'utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d'un ensemble de données ou d'objets de données (DO) et 20 suivre la propriété d'un ensemble de données. Selon une autre particularité, une clé publique et privée unique est générée pour la création d'un compte d'agent, afin de permettre audit agent d'utiliser au moins un outil cryptographique asymétrique de l'infrastructure de clés publiques. 25 Selon une autre particularité, ladite clé publique et privée unique permet également audit agent d'agir comme une entité DTP active, qui est active dans une machine qui exécute une instance DTP et qui est responsable des actions de l'instance à l'aide des signatures numériques de toutes les communications qui utilisent ladite clé privée. 30 Selon une autre particularité, l'infrastructure technique distribuée comprend au moins un système d'accès et de contrôle (AC) qui maintient l'accès aux services disponibles et/ou qui contrôlent la création de services 4 frauduleux au sein de la plate-forme, tandis que les droits d'accès sont spécifiés par chaque prestataire de service qui crée une preuve de droit d'accès pour l'utilisateur concerné à l'aide des fonctionnalités de gestion des données de la chaîne de blocs. 5 Selon une autre particularité, le système AC permet une traçabilité inter- et intra-service si des assertions appropriées sont fournies par un prestataire de service. Selon une autre particularité, le prestataire de service spécifie, pour un service numérique consommable, à l'aide d'une interface interactive 10 basée sur un navigateur Web, des métadonnées de provenance qui permettent une traçabilité inter-service et intra-service, et au moins des détails à propos du calcul effectué et des objets de données (DO)de sortie prévus. Selon une autre particularité, la base de données est distribuée avec 15 des performances de correction linéaire, optimisées pour les opérations d'écriture et conçues pour gérer les charges de travail élevées et les fonctionnalités en parallèle. Selon une autre particularité, la base de données est Apache Cassandra. 20 Selon une autre particularité, la base de données comprend au moins une couche de stockage comprenant au moins un stockage de groupes de transactions, un stockage de file d'attente de blocs, un stockage de chaîne de blocs, un stockage de blocs invalides, et un lac de données. Selon une autre particularité, ladite couche de stockage comprend au 25 moins un ensemble de modules : un module de groupe de transactions destiné à traiter les transactions qui entrent dans le stockage de groupes de transactions et vont être stockées dans les blocs de la file d'attente de blocs, un module de file d'attente de blocs destiné à traiter les blocs qui ne sont pas encore validés et qui sont soumis au consensus pour la validation des blocs 30 distribués, un module de chaîne à blocs destiné à traiter les blocs validés, un module de dépôt de blocs invalides destiné à traiter les blocs qui ont été validés comme étant invalides pendant la validation de blocs par consensus 5 par un module de vote de blocs, un module de gestion de stockage destiné à stocker et à traiter des entités supplémentaires qui font partie des blocs et des transactions, notamment les votes qui sont requis pour le vote de blocs, des statuts de blocs utilisés pour persister le résultat d'un vote de validité de 5 blocs, et d'éléments de lac de données (DLE)extraits pour améliorer les performances en raison de leur taille de données variable. Selon une autre particularité, l'exécution du module de gestion du stockage permet au stockage de groupes de transactions au moins de recevoir les transactions brutes entrantes, de vérifier les transactions à l'aide 10 d'un algorithme de validation approfondie, d'affecter les transactions entrantes à un agent DTP par le biais d'une stratégie de sélection, et d'ajouter lesdites transactions vérifiées au stockage de groupes de transactions. Selon une autre particularité, la validation approfondie (DV) permet de 15 valider par la suite des données arbitraires par toutes les couches architecturales DTP, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée optimisée pour une exécution simultanée. 20 Selon une autre particularité, le module de groupes de transactions identifie les transactions vérifiées avec une marge importante à l'aide de l'agent DTP assigné qui est responsable de l'exécution du module de groupes de transactions, crée des blocs en utilisant l'autorisation des transactions, transmet les blocs à stocker dans la file d'attente de blocs, et 25 supprime les transactions utilisées du stockage de groupes de transactions. Selon une autre particularité, l'exécution du module de vote permet au moins de vérifier si l'« ID » d'un agent se trouve dans une liste de votants stockée dans la couche de stockage de la base de données, d'exécuter un processus de validation approfondie pour déterminer la validité d'un bloc, 30 d'ajouter un vote au bloc correspondant au résultat de la validation, et de déclencher ou non une minuterie pour chaque vote manquant. 6 Selon une autre particularité, la couche de stockage comprend au moins : - une liste des agents et des services qui existent sur la plate-forme. Lesdits agents et services ont été créés et stockés dans 5 un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés. - Une mémoire cache de blocs de chaîne à blocs (BBC), qui est une mémoire cache d'un certain nombre de blocs, pour lesquels une décision a été prise (stockés dans la chaîne de 10 blocs ou dans le dépôt de blocs invalides), qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme une file d'attente limitée en taille (paramètre de configuration) qui utilise des HashMaps sous-jacents pour une recherche efficace d'au moins tous les ID de 15 blocs (identités de blocs), ID de transactions ; - une mémoire cache de blocs de consensus (CBC), qui est analogue à la mémoire cache de chaîne de blocs et qui est utilisée pour les blocs pour lesquels aucune décision n'a été prise; 20 - une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par l'agent correspondant, c'est-à-dire lorsque l'ID de l'agent a été ajouté à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu'aucun vote n'a encore été 25 fourni ; - une mémoire cache de transactions (PTC), qui conserve les transactions issues du groupe de transactions ; - une liste d'autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si 30 une transaction peut être ajoutée à un bloc destiné à être stocké : 7 une transaction précédente (le cas échéant) est stockée dans un bloc validé un agent émetteur d'une transaction n'est pas placé sur liste noire 5 toutes les données (DLE, agent, etc.) sont disponibles dans le système afin de procéder à leur vérification. Selon une autre particularité, la couche de traçabilité comprend au moins un module « agents » destiné à stocker le modèle de données d'agent de traçabilité, un module d'objets de données (DO) destiné à stocker le Io modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche de traçabilité. Selon une autre particularité, les entités de traçabilité sont également 15 identifiées par un « ID statique » qui ne change pas pendant une mise à jour et comprend au moins : - Propriétaire de l'agent (AgentOwner) : « agent_owner_id » (ID unique) - Agent : « agent_id » (clé publique) 20 - Service : « service_id » (ID unique) + « service_version » Selon une autre particularité, dans la couche de stockage, au moins l'une des requêtes suivantes est prise en considération pour garantir le traitement efficace des informations liées à un bloc : - Obtention des blocs par ID; 25 - Obtention de l'heure de création des blocs ; - Obtention des transactions du stockage par ID de bloc ; - Obtention des informations de statut par ID de bloc ; - Obtention des votes par ID de bloc ; - Obtention du DLE par ID de transaction du stockage 30 Selon une autre particularité, au moins l'une des requêtes suivantes est prise en considération pour la traçabilité des données dans la couche de 8 traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes : - Obtention de la transaction à tracer par ID d'objet de donnée ; - Obtention de la transaction à tracer par ID de service ; 5 - Obtention des agents par ID de transaction à tracer ; - Obtention des services par ID de transaction à tracer ; - Obtention des agents par ID de propriétaire d'agent ; - Obtention des services par ID de service. Selon une autre particularité, le module de vote ayant des 10 performances élevées et une fonctionnalité de paramétrabilité, permet : - d'ajuster le vote selon une taille de fédération réduite, avec un temps-système de vote réduit et des latences de stockage correspondantes réduites, - de stocker instantanément le vote sans que la conception 15 architecturale exige une durée de stockage minimale. Selon une autre particularité, la technologie de couche de stockage de la base de données se met à l'échelle par sa conception pour obtenir un débit de stockage total élevé. Selon une autre particularité, la fonctionnalité de paramétrabilité de 20 l'infrastructure technique distribuée est assurée par un programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure étant apte à fournir des configurations individuelles. Selon une autre particularité, le service d'approvisionnement en données (DPS) conserve des preuves d'activité de manière transparente 25 pour l'utilisateur. Selon une autre particularité, le service d'approvisionnement en données (DPS) maintient l'activité de fourniture de données, qui requiert d'indiquer les métadonnées connexes, comme les références aux ensembles de données utilisés des autres. 30 Selon une autre particularité, le service d'approvisionnement en données (DPS) conserve l'historique complet d'un ensemble de données en 9 analysant les preuves et en suivant les références au sein des métadonnées afin de permettre le suivi de l'historique complet d'un ensemble de données, et d'identifier tous les utilisateurs qui peuvent contribuer à sa création. Selon une autre particularité, le service d'approvisionnement en 5 données (DPS) étend la fonctionnalité de propriété pure avec des opérations destinées à maintenir les ensembles de données sur la plate-forme. Selon une autre particularité, la plate-forme reçoit une requête en provenance d'un service d'analyse de données complexes utilisant des modèles d'apprentissage machine (ML) et des ensembles de données 10 d'apprentissage disponibles sur la plate-forme afin d'offrir un service d'analyse par apprentissage machine. Selon une autre particularité, le système comprend : - une chaîne de blocs ; et - une ressource de calcul prévue pour exécuter une boucle de 15 sorte que l'exécution de la boucle soit influencée par l'état de la chaîne à blocs, la boucle étant mise en oeuvre à l'aide d'un script, afin de conserver un décompte d'un ou plusieurs votes pour la validation des blocs liée au consensus, ou pour les décisions de validité des blocs, et un statut de bloc 20 correspondant généré pour ou associé au bloc extrait de la file d'attente de blocs ; et un ensemble de conditions d'invalidité définies par la fédération afin de déterminer la validité des blocs, et validées par chaque agent qui participe à un vote sont évaluées et au moins une action est menée sur la base du 25 résultat de l'évaluation ; ladite action comprenant au moins : - faire qu'au moins une transaction soit écrite dans le volume de chaîne de blocs de la base de données ; et/ou - faire qu'une action hors chaîne de blocs soit exécutée. 30 Selon une autre particularité, pour chaque itération de la boucle, un hachage cryptographique du script est généré, et les informations relatives à 10 au moins une itération de la boucle sont stockées dans une transaction sur la chaîne de blocs ; les informations étant stockées sous la forme de métadonnées dans la transaction. Selon une autre particularité, les conditions concernent les données 5 reçues, et les changements de propriété détectés ou générés par la ressource de calcul ; ou l'état de la chaîne de blocs. Selon une autre particularité, la base de données offre un moyen d'identification des processus liés au stockage du groupe de transactions, à la file d'attente de blocs, à la chaîne de blocs et au dépôt des blocs invalides, 10 à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions. Selon une autre particularité, les processus de stockage de la base de données et de consensus par chaîne à blocs constituent chacun une couche de l'architecture qui peut être supprimée, remplacée ou étendue avec 15 d'autres caractéristiques. Selon une autre particularité, la plate-forme de traçabilité des données comprend au moins un module d'estimation, ledit module comprenant au moins un ensemble de modèles et de programmes destinés à estimer la contribution de différents ensembles de données pour la création d'un nouvel zo ensemble et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l'ensemble de données. Selon une autre particularité, l'ensemble de modèles et de programmes comprend au moins un modèle d'estimation de valeur de Shapley, ladite valeur de Shapley estimant la valeur d'un ensemble de 25 données et/ou la contribution relative d'ensembles de données d'entrée à la valeur de l'ensemble de données résultant. Selon une autre particularité, le module d'estimation est utilisé pour la rémunération de chaque utilisateur qui a participé à la création du nouvel ensemble de données selon le montant de la participation. 30 11 BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels : 5 - La figure 1 est une représentation schématique des éléments de la base de données distribuée (2). - Les figures 2a, 2b, 2c et 2d sont des représentations schématiques, respectivement, d'un fournisseur de données (3) qui crée un service à l'aide de la plate-forme de traçabilité de données (1) (DTP), d'un fournisseur de 10 données (3) qui fournit un service à un consommateur de données à l'aide de la plate-forme de traçabilité de données, et du processus de traçabilité de l'utilisation des données consommées à l'aide de la plate-forme de traçabilité de données et de l'utilisation de la plate-forme pour estimer la contribution relative des ensembles de données d'entrée à la valeur de l'ensemble de 15 données résultant, selon un mode de réalisation ; - La figure 3 est une représentation de tableaux contenant les attributs relatifs à un objet de données, selon un mode de réalisation ; - La figure 4 est une représentation de tableaux contenant les attributs relatifs à un bloc, selon un mode de réalisation ; 20 - La figure 5 est une représentation de tableaux contenant les attributs relatifs au groupe de transactions de la couche de stockage, selon un mode de réalisation ; - La figure 6 est une représentation de tableaux contenant les attributs relatifs à la file d'attente de blocs de la couche de stockage, selon un mode 25 de réalisation ; - Les figures 7a et 7b sont des représentations de tableaux contenant des attributs relatifs respectivement à la gestion de stockage et au vote de blocs, selon un mode de réalisation - La figure 8 est une représentation de tableaux contenant les attributs 30 relatifs aux transactions dans la couche de stockage, selon un mode de réalisation ; 12 - La figure 9 est une représentation de tableaux contenant les attributs relatifs au « propriétaire d'un agent » de la couche de traçabilité, selon un mode de réalisation ; - La figure 10 est une représentation de tableaux contenant les 5 attributs relatifs à un « agent » de la couche de traçabilité, selon un mode de réalisation ; - La figure 11 est une représentation de tableaux contenant les attributs relatifs aux « services » de la couche de traçabilité, selon un mode de réalisation ; 10 - La figure 12 est une représentation de tableaux contenant les attributs relatifs aux transactions de la couche de traçabilité, selon un mode de réalisation. 15 DESCRIPTION DÉTAILLÉE La présente invention concerne une infrastructure technique distribuée qui permet de suivre des données. Dans certains modes de réalisation, l'infrastructure technique distribuée destinée à un système de plate-forme (1) de traçabilité de 20 données basé sur des(DTP) comprend au moins un serveur de base de métadonnées (2) à architecture en couches (figure 1) et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d'approvisionnement en données (DPS), et une machine d'interrogation automatique, et est caractérisée en ce que la base 25 de données (2) est utilisée pour stocker des données et conserver des preuves sécurisées de l'échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur (4) d'accéder à des ensembles de données (D01, ,D0n) fournis par d'autres utilisateurs, et de proposer un ensemble de 30 données accessible par un autre utilisateur (4), et dans laquelle la plate- forme de traçabilité de données (1) adapte la technologie de chaîne de blocs (22) pour le suivi sécurisé de la propriété d'un ensemble de données (DO) à 13 stocker dans la base de données (2), et met en place un processus de consensus par fédération (FC), au cours duquel un module de vote décide de la validité d'un bloc afin de stocker le bloc dans la base de données (2). La plate-forme (1) (DTP) peut comprendre au moins un ensemble de 5 couches et au moins : - une couche centrale qui maintient les couches de la plate-forme (1) et permet à toutes les couches d'accéder aux contrôleurs des autres couches. - une couche réseau qui conserve une liste des pairs qui sont 10 actuellement en ligne. Ainsi, une couche plus élevée peut vérifier si un pair et ses services sont actuellement en ligne. La couche réseau ne connaît pas les couches supérieures. Cependant, un paramètre réseau « PeerProfile » est préparé avec un agent et un champ de signature. Cela active le lien 15 entre un pair et un agent de la plate-forme, et l'intégrité cryptographique. Avant d'aller plus loin dans la description de la présente invention, certains des termes utilisés ou qui peuvent être utilisés doivent être définis. 20 Le terme « agent » désigne la plus petite entité autonome de la plate-forme (1) qui propose et/ou utilise les services de la plate-forme (1). Le terme « Agent » est en outre caractérisé par ce qui suit : - « Application d'agent »: techniquement, l'agent est une sorte d'application logicielle qui interagit avec la plate-forme (1) et 25 comprend la logique de communication connexe et le protocole collaboratif ; - « Opérateur d'agent »: un agent (une application) peut être contrôlé par une personne, une logique logicielle (comme un démon de base de données (2), un contrôleur d'analyse de 30 données, un agent logiciel) ou une intelligence artificielle qui interagit avec l'application d'agent. Cette logique peut être 14 intégrée à un matériel embarquée (comme des capteurs intelligents). - « Machine d'agent »: la machine d'agent est l'ordinateur sur lequel est exécutée l'application d'agent. Pour des raisons de 5 simplicité, nous supposons une application d'agent exécutée sur une machine dédiée. Une machine d'agent peut être reliée à d'autres machines afin de proposer plus efficacement le service (comme un cluster de serveurs d'analyse de données massives). Ces machines servent uniquement de support 10 pour l'exécution du service de l'agent, et ne sont pas directement reliées à la plate-forme. - « Représentant légal d'agent »: chaque agent possède une seule et unique personne qui fait office de représentant légal, et qui est responsable 1) des opérations de l'agent sur la 15 plate-forme (1) et 2) des transferts monétaires, comme le paiement d'un service. Pour des raisons de simplicité, nous supposons que ces deux responsabilités sont assumées par une seule personne, tandis que plusieurs machines d'agents peuvent avoir le même représentant légal d'agent. 20 - « Agent de plate-forme (1) » : il s'agit d'un agent spécial qui travaille pour le compte du fournisseur de la plate-forme (1) (3, figures 2a, 2b) et qui se concentre sur la disponibilité et l'exactitude du service disponible. Ainsi, il effectue des vérifications de preuves (métadonnées de provenance, par 25 exemple) et prend en charge certaines opérations, comme la dissémination et la mise en cache des données. Le terme « service » désigne un ensemble « d'opérations » proposées par un agent, le « prestataire de service (3, figures 2a, 2b) » ou le fournisseur de données, à un autre agent, le « consommateur du service ». 30 Une « consommation de service » désigne le fait que le consommateur d'un service (ou l'utilisateur d'un service (4, figures 2b, 2c), ou un consommateur 15 de données) utilise une opération spécifique proposée par le prestataire de service (3). Dans ce qui suit, si cela n'est pas explicitement mentionné, nous utilisons le terme « service » de manière interchangeable avec le terme « opération (service) ». 5 Certains des termes liés à un service proposé sur la plate-forme (1) sont, par exemple et sans limitation, les suivants : - Un « appel de service », qui désigne la requête ou demande, par un agent, de la consommation d'un service proposé par un fournisseur (3). 10 - Une « activité de service », qui désigne l'activité réalisée par un prestataire de service (3) pour exécuter un service spécifique (et pour laquelle un consommateur peut payer des frais). L'activité comprend : soit la mise à disposition d'un objet de données 15 préparé à l'avance ; soit la mise à disposition d'un objet de données créé à la demande par un certain traitement (en prenant en compte des objets de données d'entrée ou des ressources externes) ; soit 20 le traitement des données sans délivrer d'objet de données en guise de service (comme la remise d'une réputation, la modification des droits de contrôle d'accès). - Le terme « métadonnées de service » décrit le service et 25 l'activité de service correspondante. Plus particulièrement, il contient (s'il est fourni par l'agent) des métadonnées de provenance détaillées afin de permettre la traçabilité des objets de données en guise de service (comme le traitement des scripts dans un code source pour la création de l'objet de 30 données). 16 - Le terme « entrée de service » désigne les objets de données (propres ou issus d'autres services) utilisés comme entrée pour l'exécution d'une opération de service par le prestataire de service (3). En termes de langages de programmation, 5 cela représente les paramètres d'entrée d'un procédé de traitement de données. - Le terme « sortie de service » désigne le résultat de l'activité de service qui est transmis au consommateur du service. Il comprend au moins un code de statut et généralement un ou 10 plusieurs objets de données également. - « type de service » définit la manière dont les services sont exécutés. Deux manières sont possibles : Un « service pull », qui est exécuté de manière réactive. Le consommateur d'un service émet un appel de service 15 vers un prestataire de service (3) afin de consommer le service proposé. Le prestataire (3) exécute l'activité de service et renvoie le service au consommateur. Un « service push », qui est exécuté de manière proactive. Le consommateur du service s'abonne à un 20 service spécifique en émettant un appel de service. Le prestataire de service (3) exécute le service et fournit le service sur la base d'un évènement ou de manière périodique. Le terme « objet de données » (DO) désigne une entité qui 25 encapsule des données pour un échange entre les agents dans le contexte de l'entrée de service ou de la sortie de service. L'« origine de l'objet de données » (voir les métadonnées d'objet de données) spécifie la manière dont l'objet de données a été créé. Elle se rapporte généralement à une transaction de service et, ainsi, à un service/un agent spécifique, où la 30 création réelle doit être décrite par le biais des métadonnées de provenance. Cependant, des agents peuvent également créer un objet de données pour 17 l'entrée de service (éventuellement à l'aide d'un autre objet de données et de ressources externes). Dans ce cas, l'agent doit idéalement fournir les métadonnées de provenance correspondantes de la même manière que le prestataire de service (3). 5 Un objet de données peut être l'un des « types d'objet de données » suivants : - Un « ensemble de valeurs » - Un « ensemble de données » - Un « flux de données » 10 - Des « données génériques » Des « métadonnées d'objet de données » décrivent l'objet de données et son contexte. Elles contiennent, entre autres, le type d'objet de données, la date et l'heure de création, le service responsable de la création, le prestataire de service (3), les informations sur l'intégrité et la sécurité 15 (sommes de contrôle, signatures numériques, etc.), et l'identification du propriétaire (voir la figure 3). La provenance indique, d'un point de vue ou une approche «topdown », la possibilité (ou capacité) de dériver l'historique des données au fil des étapes de calcul pendant le traitement, en commençant par les sources 20 initiales. À l'inverse, nous considérons la traçabilité comme présentant des caractéristiques ascendantes ou « bottom-up », indiquant la possibilité (ou capacité) de suivre les relations entre les données et les changements de données afin de déterminer les processus de provenance. Par conséquent, nous considérons la traçabilité en indiquant les aspects techniques de 25 l'association de données, tandis que la provenance aborde le concept global de détermination des informations de provenance (comme les processus de retour à la création initiale des données). Un système de provenance est, en général, caractérisé par au moins trois caractéristiques principales : l'orientation de la provenance, le modèle et 30 les mécanismes de capture. 18 L'orientation de la provenance peut être orientée données ou orientée calculs. Dans le premier cas, le système de provenance capture des informations sur le flux et la transformation des données. Dans le second cas, qui correspond à l'orientation calculs, les informations capturées sont 5 les détails de la transformation des données (traitement des données). Dans le système de provenance, le modèle de provenance utilisé pour capturer les informations est en général de deux types : rétrospectif et prospectif. Dans un modèle rétrospectif (RPM), les annotations sur le flux et la transformation des données sont enregistrées. Le modèle rétrospectif peut 10 conserver les annotations sur les données et/ou leur traitement. À l'inverse, le modèle prospectif (PPM) offre une « recette » (un ensemble d'étapes, une méthode, ... ) qui décrit comment traiter les données. Ainsi, un modèle prospectif est généralement axé sur le traitement afin de pouvoir répéter facilement le même calcul. La plate-forme de traçabilité de données met en 15 oeuvre un modèle rétrospectif en conservant automatiquement les preuves des interactions (les preuves de consommation d'un service sont par exemple conservées par le biais de la « transaction de traçabilité », qui contient des informations détaillées sur le fournisseur, le consommateur, le service, etc.), qui sont sécurisées de manière cryptographique pour garantir 20 la protection des données. Les mécanismes de capture, essentiellement utilisés dans un système de provenance, sont des mécanismes qui reposent sur des processus et/ou un système d'exploitation. En ce qui concerne les mécanismes qui reposent sur des processus, 25 ceux-ci sont étroitement liés à des systèmes de gestion de processus (WMS). Ainsi, les informations de provenance indiquent les liens entre les entrées et les sorties des calculs, qui déterminent un processus. Les mécanismes qui reposent sur des processus enregistrent les informations de calcul depuis l'intérieur d'une application, c'est-à-dire qu'ils 30 nécessitent un processus propre pour documenter les tâches de calcul. Les mécanismes qui reposent sur un système d'exploitation (également désignés « capture environnementale ») n'ont besoin d'aucune 19 modification sur l'application elle-même. Ils utilisent les fonctionnalités ou caractéristiques d'un système d'exploitation (ou un environnement par le biais de wrappers) pour capturer les données. Ainsi, les processus d'exécution d'une application sont considérés comme une boîte noire, tandis 5 que l'entrée et la sortie peuvent être capturées. Une représentation graphique est une visualisation courante et est utilisée par les mécanismes qui reposent sur un système de gestion de processus et un système d'exploitation. Cependant, ils présentent des approches fondamentalement différentes. 10 De nombreux systèmes de provenance comprennent au moins l'une des caractéristiques principales décrites ci-dessus, comme par exemple, et sans limitation, Sumatra, Taverna ou Vistrails. Les systèmes les plus courants reposent sur des processus, et visent des calculs reproductibles et, ainsi, des données clairement traçables. En règle générale, ils spécifient le 15 calcul à l'avance, tout en enregistrant rétrospectivement des informations supplémentaires. Cependant, aucun des systèmes ne convient pour être directement appliqué pour la traçabilité des données. Les systèmes de gestion de processus sont trop axés sur la gestion centrale et sur les processus eux-mêmes, c'est-à-dire qu'ils spécifient les processus (ou 20 l'orchestration du service) à l'avance. Les systèmes dont la capture de données repose sur un système d'exploitation sont hors sujet, étant donné qu'ils brisent l'hypothèse de surveillance. Les systèmes de provenance qui reposent sur un traitement constituent des candidats prometteurs, cependant. Dans ces systèmes, un 25 agent spécifie le traitement des données par le biais d'assertions, et indique avec des métadonnées les relations avec les autres ensembles de données d'entrée. Cela correspond également à un système de gestion de processus organisé et décentralisé, axé sur le traitement tout en capturant également les processus. Le traitement adéquat peut ensuite être vérifié par le biais de 30 contrôles, avec un ensemble de données particulier. 20 Dans la présente invention, un système à chaîne de blocs (22) est adapté afin d'offrir plusieurs avantages en termes de provenance et de traçabi I ité. La chaîne de blocs (22) n'est pas un système de provenance 5 classique, mais plutôt un type de base de données distribuée (2). La chaîne de blocs (22) est capable de stocker des informations de manière sécurisée par le biais de preuves cryptographiques, sans avoir besoin d'une instance centrale (de confiance). La chaîne de blocs (22) (voir la figure 1) stocke les informations sous forme de blocs, qui sont concaténés en une chaîne et 10 stockés de manière distribuée. Chaque bloc possède une référence au bloc précédent, ce qui permet de traverser l'intégralité de la chaîne depuis le dernier bloc. Étant donné que de nouveaux blocs peuvent être ajoutés en même temps, des « ramifications » peuvent apparaître, et engendrer plusieurs derniers blocs. Une seule chaîne peut être valide pour garantir un 15 dernier bloc unique, et est déterminée par un protocole de consensus. Chaque bloc comprend plusieurs transactions, qui sont sécurisées avec une cryptographie asymétrique. Chaque nouvelle transaction est validée par le propriétaire de la transaction actuelle, ce qui crée ainsi une chaîne de transactions validées. En guise de preuve de validité, le propriétaire d'une 20 transaction en cours signe numériquement une valeur de hachage de la nouvelle transaction. La valeur de hachage utilise la transaction actuelle et la clé publique du propriétaire de la nouvelle transaction comme entrée. Il est important de noter que la chaîne de blocs (22) est dépourvue d'état. Les transactions stockées dans un bloc sont le seul état existant. 25 Le terme « transaction » désigne généralement tous les messages échangés pour assurer la consommation d'un service. Une transaction, comme pour les bases de données (2), est soit exécutée en entier (consommation réussie du service, avec tous les échanges de messages 30 connexes), soit en échec (aucune consommation de service). Le terme « hachage » désigne la valeur renvoyée par une fonction de hachage. Une fonction de hachage est n'importe quelle fonction qui peut 21 être utilisée pour mapper des données de taille arbitraire par rapport à des données de taille fixe. Un exemple d'utilisation est une structure de données appelée « table de hachage », largement utilisée dans les logiciels informatiques pour 5 rechercher rapidement des données. Les fonctions de hachage accélèrent la recherche dans une table ou une base de données (2) en détectant les enregistrements en double dans un fichier de grande taille. Exemple : recherche de tronçons similaires dans des séquences ADN. Elles sont également utiles pour la cryptographie. Une fonction de hachage 10 cryptographique permet de vérifier facilement que certaines données d'entrée sont mappées par rapport à une valeur de hachage donnée, mais si les données d'entrée sont inconnues, il est délibérément difficile de les reconstruire (ou autre) en connaissant la valeur de hachage stockée. Celle-ci est utilisée pour garantir l'intégrité des données transmises. 15 La création d'un bloc capable de stocker des transactions dans la chaîne de blocs (22) nécessite la résolution d'un certain puzzle cryptographique. Généralement, comme par exemple dans Bitcoin, cela consiste à trouver certaines valeurs nonce (nombre aléatoire ou pseudoaléatoire destiné à être utilisé une seule fois) de sorte que la valeur de 20 hachage pour les transactions à stocker commence par un groupe de zéros. Cela est également désigné « minage » (Bitcoin); le mineur est récompensé avec des bitcoins pour ses efforts de calcul. Un nouveau bloc, s'il est vérifié par d'autres explorateurs, est ensuite ajouté à la chaîne à blocs (22), qui sert de confirmation de stockage pour les transactions associées. 25 Par mineur, on entend une personne qui dispose d'au moins d'une architecture matérielle et logicielle pour mettre en oeuvre le procédé de minage ci-dessus. Dans certains modes de réalisation, un bloc est défini par une table 30 (voir figure 4) qui contient les attributs suivants (ID, horodatage, statut, dm_version, charge utile, créateur, votants, commentaire, signature, ID du bloc précédent) 22 Il doit être compris que le consensus par fédération (FC) de la présente invention est très différent des autres approches de validité des blocs, et notamment de l'approche « preuve de fonctionnement » qui utilise le calcul d'un bloc valide par le biais d'un « minage de bloc » (en résolvant 5 un puzzle), au cours duquel la validité d'un bloc est vérifiée individuellement par chaque utilisateur de la chaîne à blocs. Au lieu de cela, le consensus par fédération de la présente invention fonctionne comme un pur système distribué, dans lequel le module de vote de chaque agent de plate-forme de traçabilité des données (entité active d'une instance de plate-forme de 10 traçabilité de données) d'une « fédération de plate-forme » (un sous- ensemble de tous les agents de plate-forme disponibles) propose un vote individuel sur la validité, et le total finalement cumulé des votes détermine la validité du bloc. Les différences significatives résident en outre dans la possibilité de paramétrage, et notamment de la taille réelle de la fédération 15 DTP et des participants, et du seuil de validité. Les transactions comprennent en outre des scripts de transactions qui doivent être exécutés sans problème afin d'être acceptés dans un bloc. Lesdits scripts de transactions vérifient généralement les valeurs de hachage et les signatures des transactions (représentées par un paramètre indiqué 20 transaction « pay-to-pub-key-hash »). Cependant, le langage de script utilisé offre quasiment 200 commandes, appelées « codes opération » (opcodes), qui comprennent une prise en charge des opérations cryptographiques. Cela permet une logique complexe pour le stockage des transactions. Dans une chaîne de blocs (22), il n'existe aucune notion inhérente 25 d'identités ou de comptes individuels qui « possèdent » une transaction. Dans une chaîne de blocs, la propriété désigne simplement le fait de connaître une clé privée qui est capable d'effectuer une signature qui récupère la transaction. En plus des caractéristiques technologiques susmentionnées 30 intégrées à une chaîne de blocs (22), comme les transactions et les scripts qui concernent le format et les scripts d'une transaction, c'est-à-dire la manière dont une transaction est techniquement spécifiée et son exactitude 23 est validée, un protocole de consensus qui spécifie la chaîne qui sera considérée comme valide lorsque plusieurs blocs sont valides en termes de puzzle cryptographique, une fonctionnalité de minage de blocs qui spécifie un puzzle cryptographique adéquat afin de trouver un identifiant de bloc 5 valide (ID) et qui peut également gérer les récompenses appropriées pour les explorateurs pour leurs efforts de calcul, une chaîne de blocs (22) peut également comprendre au moins un module de communication peer-to-peer (P2P) qui gère au moins la distribution des blocs sur la plate-forme (1) et/ou les transactions. 10 Les caractéristiques susmentionnées peuvent permettre à une chaîne de blocs (22) d'être utilisée comme un système de gestion de preuves distribué pour la traçabilité des données. En fait, la chaîne à blocs (22) exécute intrinsèquement une gestion de preuve sur un système P2P sans avoir besoin d'une instance centrale de confiance. De plus, la traçabilité 15 est naturellement assurée par le biais de l'architecture à chaîne. De plus, toutes les transactions et les données qu'elles contiennent sont automatiquement vérifiables. Cependant, les aspects tels que l'algorithme du protocole de consensus et les récompenses liées au minage doivent reposer sur des décisions éclairées, étant donné qu'ils affectent la stabilité et les 20 performances globales de la plate-forme distribuée. En ce qui concerne le système de provenance, en règle générale, la chaîne de blocs (22) peut être caractérisée par ce qui suit : - informations de capture orientées données : la chaîne de blocs (22) vise à persister les données classiques au sein de 25 la chaîne de blocs distribuée (22). Cependant, le format des transactions est généralement modifié afin d'exécuter des fonctionnalités supplémentaires (comme des contrats intelligents, ou « smart contracts ») - modèle de provenance rétrospectif : une chaîne de blocs (22) 30 possède généralement un modèle de provenance rétrospectif étant donné que la sortie (résultat) de certains traitements ou d'autres données disponibles sont stockées. 24 - mécanisme de capture reposant sur un processus : la chaîne de blocs (22) repose sur un processus, étant donné que l'application réelle doit persister les données au sein de la chaîne (22). 5 Par « persister » des données, on entend « stocker » des données d'une de manière persistante. Autrement dit, de les sauvegarder afin qu'elles ne disparaissent pas lorsque, par exemple, le processus ou le programme de traitement se termine. 10 Dans certains modes de réalisation, l'infrastructure technique distribuée comprend au moins une infrastructure de clés publiques (PKI) qui permet d'utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d'un ensemble de données ou d'objets de données (DO) et 15 suivre la propriété d'un ensemble de données. Dans certains modes de réalisation, un agent doit créer un compte de plate-forme pour pouvoir participer à la plate-forme (1) et désigner un représentant légal, responsable des actions de l'agent, dont l'identité (ID) est 20 vérifiée. Pendant la création du compte, une clé publique et privée unique est générée pour l'agent afin de pouvoir utiliser au moins un outil cryptographique asymétrique de l'infrastructure de clés publiques. Dans certains modes de réalisation, ladite clé publique et privée unique peut également permettre audit agent d'agir comme une entité DTP active, qui est 25 active dans une machine qui exécute une instance DTP et qui est responsable des actions de l'instance à l'aide des signatures numériques de toutes les communications qui utilisent ladite clé privée. Dans certains modes de réalisation, l'infrastructure technique distribuée comprend au moins un système d'accès et de contrôle (AC) qui 30 maintient l'accès aux services disponibles et/ou qui contrôlent la création de services frauduleux au sein de la plate-forme, tandis que les droits d'accès sont spécifiés par chaque prestataire de service (3) qui crée une preuve de 25 droit d'accès pour l'utilisateur concerné à l'aide des fonctionnalités de gestion des données à chaîne de blocs (un document de preuve est créé avec la transaction « CREATE » de la chaîne de blocs, dont le modèle de données indique le propriétaire actuel par le biais d'un attribut ou d'un champ 5 « c_owner », et est sécurisé de manière cryptographique par la signature numérique du prestataire de service). À l'aide du système d'accès et de contrôle, un agent doit spécifier à l'avance, par le biais d'assertions, les services proposés et l'activité de service menée. Les assertions peuvent ensuite être contrôlées après la consommation du service et, ainsi, peuvent 10 détecter les éventuelles fraudes spécifiées ci-dessus. En effet, les assertions spécifient l'activité de service et vérifient le service rendu correspondant par rapport aux assertions. En cas d'absence de correspondance, l'accès n'est pas accordé, et le service et le résultat sont stockés dans une mémoire de l'infrastructure technique afin de procéder à des vérifications 15 complémentaires. « Aucun accès accordé » signifie que le service lui-même est visible, mais que la consommation de ce service sera refusée. L'expression « modèle de données » désigne un modèle qui documente et organise les données, la manière dont elles sont stockées et accédées, et les relations entre les différents types de données. 20 Dans certains modes de réalisation, le système d'accès et de contrôle permet une traçabilité inter- et intra-service, étant donné que l'activité de service peut être suivie en détail si des assertions appropriées sont fournies par un prestataire de service. Pour chaque service numérique consommable (et les objets de données de sortie proposés par le biais d'un 25 service), le prestataire de service (3) spécifie, à l'aide d'une interface interactive qui repose sur un navigateur Web (et qui crée les modèles de données qui peuvent être traités par la plate-forme de traçabilité des données), des métadonnées de provenance qui permettent la traçabilité inter-service et intra-service. Les prestataires de services (3), au sein de la 30 plate-forme, fournissent au moins les détails des calculs effectués et des objets de données de sortie prévus. 26 Le terme « traçabilité inter-service » désigne le suivi de l'orchestration du service (le cas échéant) et de l'utilisation de ressources externes. Cela s'effectue à l'aide d'une spécification des services utilisés par le biais du prestataire de service pendant la création du service (comme un 5 service interactif par le biais d'une interface utilisateur à navigateur Web qui crée des modèles de données utilisables par la plate-forme de traçabilité des données), conservée dans les modèles de données corrélés de la plate-forme (par exemple, un service peut indiquer « autres services utilisés »). Étant donné que la plate-forme de traçabilité des données est un système 10 privé, n'importe quel utilisateur doit accepter les conditions générales, qui comprennent l'exactitude des informations indiquées, représentant ainsi une protection par la loi, dont le non-respect peut être détecté par les processus d'analyse des données de la plate-forme et faire finalement l'objet de poursuites judiciaires en utilisant également les preuves de traçabilité 15 stockées sur la plate-forme de traçabilité des données. L'expression « traçabilité intra-service » désigne le suivi de la manière dont le service lui-même est exécuté, c'est-à-dire des calculs liés à un service et de la création des objets de données de sortie (y compris les éventuels modèles/algorithmes, valeurs d'entrée, etc.). 20 Dans certains modes de réalisation, la chaîne à blocs (22) est adaptée pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les assertions d'une approche d'accès et de contrôle (AC) dans le cadre d'une transaction, contenant ainsi des informations purement prospectives 25 sur le calcul qui spécifie la logique réelle exécutée (comme des résultats de calcul immédiats qui permettent de suivre les calculs ou d'évaluer statistiquement le niveau de confiance des résultats) et qui peuvent avoir des niveaux d'abstraction différents (par exemple, code source, diagrammes de flux de travail, pseudo-code). 30 Dans certains modes de réalisation, le système de chaîne à blocs (22) est adapté pour comprendre un modèle rétrospectif en tirant profit de la fonctionnalité de stockage et de consignation des données (notary 27 functionality), c'est-à-dire de preuves (cryptographiques) selon lesquelles les données ont été fournies ou conservées avec les opérations de gestion des données intégrées de la chaîne de blocs de la plate-forme de traçabilité de données (création, mise à jour, transfert, suppression, activation, 5 désactivation) afin de maintenir les informations de traitement. Cela comprend des informations sur la logique réellement exécutée avant l'exécution elle-même (par exemple utilisation d'autres services lors du calcul, résultats de calcul). Dans certains modes de réalisation, le système de chaîne de blocs 10 (22) est adapté pour comprendre un modèle pro-/rétrospectif avec la fonctionnalité d'un système de gestion de processus distribué. Cela est rendu possible en combinant les informations pro- et rétrospectives, comme par exemple les connaissances sur la logique d'exécution du service et les résultats des calculs intermédiaires, afin de permettre le suivi des calculs et 15 d'évaluer la fiabilité des résultats. Dans certains modes de réalisation, la base de données (2) (DB) est conçue pour gérer les charges de travail élevées et les fonctionnalités en parallèle. Elle est distribuée avec des performances de correction linéaire optimisées pour les opérations d'écriture, qui représentent les principales 20 opérations de la plate-forme ciblée. Ladite base de données (2) peut également prendre en charge des données hétérogènes, avec lesquelles les champs de données non affectés ne consomment/ne réservent pas de données. De préférence, la base de données sous-jacente (2) est Apache Cassandra. Ladite base de données (2) Apache Cassandra peut fournir au 25 moins un algorithme de consensus insensible aux défaillances, comme par exemple, et sans limitation, PAXOS, qui garantit l'exactitude de la réplication de données distribuée et, ainsi, une excellente cohérence de la base de données (2). Dans certains modes de réalisation, la base de données (2) 30 comprend au moins une couche de stockage et une couche de traçabilité. La couche de stockage comprend au moins un ensemble de modules : un module de groupe de transactions (transaction pool) (20) 28 comprenant les attributs suivants (voir figure 5) (ID, dm_version, charge utile, horodatage, opération, previoustid, c_owner, f_owner, payload_properties, commentaire, data_other, data_dle, signature, responsible_agent) pour traiter les transactions entrantes qui vont être stockées dans des blocs dans 5 la file d'attente de blocs (21), un module de file d'attente de blocs (21) comprenant les attributs suivants (voir figure 6) (id, dm_version, charge utile, horodatage, transactions, créateur, votants, commentaire, statut, signature) pour traiter les blocs qui ne sont pas encore validés et qui font l'objet du consensus par fédération pour la validation distribuée des blocs, un module 10 de chaîne à blocs (id, dm_version, charge utile, horodatage, créateur, votants, commentaire, statut, signature, ID du bloc précédent) (voir figure 4) pour traiter les blocs validés, un module de dépôt de blocs invalides (23) (comprenant les mêmes attributs que le module de chaîne à blocs) pour traiter les blocs qui ont été validés comme étant invalides pendant la 15 validation des blocs par consensus par fédération par un module de vote de blocs comprenant les attributs suivants (voir figure 7b) (ID, dm_version, charge utile, voter_pubkey (clé publique), horodatage (timestamp), current_blockid, Id du bloc précédent, is_valid, vote_invalid_reason, signature), un module de gestion du stockage comprenant au moins les 20 attributs suivants (voir figure 7a) (ID, horodatage, statut, previous_blockid, node_pubkey, signature, type, dm_version, transaction_id, indices, couche, data_dle_data_meta, data_other, data_dle_count) pour stocker et traiter les entités supplémentaires qui font partie des blocs et des transactions , notamment les votes requis pour le vote de blocs, des statuts de bloc utilisés 25 pour conserver le résultat d'un vote de validité de blocs et d'éléments de lac de données (24) (DLE) extraits pour améliorer les performances en raison de leur taille de données variable, qui peut être importante. Dans certains modes de réalisation, les transactions contenues dans la couche de stockage sont définies dans des tables illustrées sur la figure 8, 30 qui contiennent les attributs suivants (ID, dm_version, charge utile, t_index (indice de transaction, c'est-à-dire l'indice de stockage dans le bloc correspondant), charge utile, horodatage, opération, previoustid (ID de 29 transaction), c_owner (propriétaire actuel, c'est-à-dire le propriétaire actuel de la clé publique), f_owner (respect de la condition définie par le champ « propriétaire actuel » de la transaction précédente, c'est-à-dire une signature avec la clé privée qui correspond à la clé publique du propriétaire 5 actuel), « payload_properties », commentaire, data_other, signature, blockid, dle_count (élément de lac de données). Le terme « lac de données » (24) désigne un répertoire de stockage de grande taille orienté objet qui conserve les données dans leur format natif jusqu'à ce qu'elles soient utilisées. 10 Dans certains modes de réalisation, la couche de stockage (figure 1) de la base de données (2) comprend au moins un stockage de groupe de transactions (20), un stockage de file d'attente de blocs (21), un stockage de chaîne de blocs (22), et stockage de blocs invalides et un lac de données (24). 15 Dans certains modes de réalisation, les transactions entrantes sont stockées dans le stockage de groupes de transactions (20), lesdites transactions étant ensuite traitées par le module de groupe de transactions (20), qui les extrait et les enregistre sous forme de blocs dans la file d'attente de blocs (21). Les blocs stockés dans la file d'attente de blocs (21) sont 20 ensuite soumis à une validation de bloc via un consensus par fédération. La validation est effectuée à l'aide du module de vote de blocs. Le module de file d'attente de blocs (21) extrait les blocs qui ont été déterminés comme validés et les transmet au stockage de chaîne de blocs (22). Les blocs qui ont été déterminés comme invalides sont transmis au stockage de blocs 25 invalides. Dans ce dernier cas, toutes les transactions dudit stockage de blocs invalides sont copiées, à l'aide du module de dépôt de blocs invalides (23), vers le groupe de transactions, pour avoir une seconde chance. Dans certains modes de réalisation, au moins une partie des transactions entrantes est copiée dans le lac de données (24). 30 Dans certains modes de réalisation, le module de gestion du stockage gère les transactions entrantes. En effet, l'exécution du module de gestion du stockage sur le processeur permet au stockage de groupe de 30 transactions (20) au moins de recevoir les transactions brutes, de vérifier les transactions à l'aide d'un algorithme de validation approfondie, d'affecter les transactions entrantes à un agent DTP par le biais d'une stratégie de sélection (randomisée pour la répartition de la charge de travail, par 5 exemple), et d'ajouter lesdites transactions vérifiées au stockage du groupe de transactions (20). Lesdites transactions vérifiées sont indiquées « transactions », avec une forte autorisation (strong clearance). Dans certains modes de réalisation, l'algorithme de validation approfondie (DV) permet de valider par la suite les données arbitraires par 10 toutes les couches architecturales de la plate-forme de traçabilité des données, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée (comme des contrôles de validité cryptographiques, la cohérence 15 du modèle de données) optimisée pour une exécution simultanée (par le biais d'un matériel à plusieurs noyaux/plusieurs CPU). La validation approfondie est utilisée pour valider n'importe quelles données de la plate-forme de traçabilité, et les validateurs peuvent être utilisés et étendus par des applications individuelles exécutées « au dessus » de la plate-forme, 20 servant ainsi de routine de validation à usage général. Dans certains modes de réalisation, le module de groupe de transactions (20) identifie les transactions vérifiées ou les transactions avec une marge importante à l'aide de l'agent DTP assigné qui est responsable de l'exécution du module de groupes de transactions, crée des blocs en utilisant 25 l'autorisation des transactions, transmet les blocs à stocker dans la file d'attente de blocs (21), et supprime les transactions utilisées du stockage de groupe de transactions (20). Dans certains modes de réalisation, l'exécution du module de vote permet au moins de vérifier si l'« ID » d'un agent (identité) se trouve dans 30 une liste de votants stockée dans la couche de stockage de la base de données, d'exécuter un processus de validation approfondie pour déterminer la validité d'un bloc, d'ajouter un vote au bloc correspondant au résultat de la 31 validation, et de déclencher ou non une minuterie pour chaque vote manquant. La couche de stockage comprend également au moins : - une liste des agents et des services qui existent sur la plate- 5 forme. Lesdits agents et services ont été créés et stockés dans un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés. - une mémoire cache (BBC) de blocs de chaîne de blocs (22), qui est une mémoire cache d'un certain nombre de blocs pour 10 lesquels une décision a été prise (stockés dans la chaîne de blocs (22) ou dans le dépôt de blocs invalides (23)) qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme une file d'attente limitée en taille (paramètre de configuration) qui 15 utilise des HashMaps sous-jacents pour une recherche efficace de tous les ID de blocs (identité de blocs), ID de transactions, etc. - une mémoire cache de blocs de consensus (CBC), qui est analogue à la mémoire cache de chaîne de blocs (22) et qui 20 est utilisée pour les blocs pour lesquels aucune décision n'a été prise. - une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par l'agent correspondant, c'est-à-dire lorsque l'ID de l'agent a été ajouté 25 à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu'aucun vote n'a encore été fourni ; - une mémoire cache de groupe de transactions (PTC), qui conserve les transactions issues du groupe de 30 transactions (20). 32 - une liste d'autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si une transaction peut être ajoutée à un bloc destiné à être stocké - 5 une transaction précédente (le cas échéant) est stockée dans un bloc validé un agent émetteur d'une transaction n'est pas placé sur liste noire toutes les données (DLE, agent, etc.) sont disponibles 10 dans le système afin de procéder à leur vérification. La couche de traçabilité comprend au moins un module « agents » destiné à stocker le modèle de données d'agent de traçabilité, un module d'objets de données (DO) destiné à stocker le modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le 15 modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche de traçabilité. Toutes les entités fournissent la valeur de hachage du modèle de données sous la forme d'un ID unique dans le champ « ID ». Cela suffit particulièrement pour les objets de données et les transactions des entités 20 de traçabilité, qui sont toujours uniques dans le système (les mises à niveau vers un objet de données deviennent une entrée de base de données distincte). Dans certains modes de réalisation, les entités de traçabilité sont également identifiées par un « ID statique » qui ne change pas pendant une mise à jour (comme en cas de changement de l'adresse e-mail du 25 propriétaire d'un agent) et sont les suivantes : - Propriétaire de l'agent (AgentOwner): « agent_owner_id » (ID unique) - Agent : « agent_id » (clé publique) - Service : « service_id » (ID unique) + « service_version » 30 Les « ID » susmentionnés (hachage du modèle de données) des entités de la couche de traçabilité (Propriétaire de l'agent, agent, service, 33 etc.) sont utilisés pour l'identification d'une entrée de base de données spécifique. Une mise à jour des entités « Propriétaire de l'agent », « Agent » et « Service » peut provoquer un problème à première vue, étant donné que le hachage change. Par conséquent, un « ID statique », un identifiant 5 universel unique (UUID) ou une clé publique est utilisé(e) comme autre identifiant unique qui ne change pas en cas de mise à jour du modèle de données (comme le numéro de téléphone du propriétaire de l'agent). Le terme « UUID » désigne un chiffre à 128 bits utilisé pour identifier de manière unique un certain objet ou une certaine entité sur Internet. 10 Dans certains modes de réalisation, l'entité « Propriétaire de l'agent » comprend au moins l'un des attributs suivants (voir figure 9) : ID, dm_version, digest, agent_owner_id, asset_index, charge utile, first_name, last_name, date de naissance, adresse, numéro de téléphone, e-mail, photo, commentaire, data_other, data_dle, dle_count, pays, ville, sblock_id, 15 stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage. Dans certains modes de réalisation, l'entité « Agent » comprend au moins l'un des attributs suivants (voir figure 10) : ID, dm_version, agent_id, 20 asset_index, charge utile, agent_version, agent_owner, agent_type, agent_name, agent_picture, commentaire, data_other, data_dle, dle_count, sblockid, stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage. 25 Dans certains modes de réalisation, l'entité « Service » comprend au moins l'un des attributs suivants (voir figure 11) : ID, dm_version, asset_index, charge utile, service_id, service_version, provider_agent, description, result_description, result_type, input_param_descr, input_param_types, « output_do », used_service_id, used_service_version, 30 used_service_op, api_specification, is_traceable, comment, data_other, data_dle, dle_count, sblock_id, stransaction_id, stransaction_op, stimestamp, input_param_count, do_output_count, tandis que les attributs 34 sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux transactions contenues dans la couche de stockage. Dans certains modes de réalisation, les transactions contenues dans la couche de traçabilité comprennent au moins l'un des attributs suivants 5 (voir figure 12) : ID, dm_version, asset_index, charge utile, provider_agent, consumer_agent, service_id, service_version, service_op, input_param, output_do, result, comment, data_other, data_dle, dle_count, sblockid, stransaction_id, stransaction_op, stimestamp, tandis que les attributs sblockid, stransaction_id, stransaction_op et stimestamp sont liés aux 10 transactions contenues dans la couche de stockage. La couche de stockage comprend au moins un ensemble de modules qui permettent le stockage et la validation des données. Pour effectuer lesdites opérations, c'est-à-dire le stockage et la validation des données, au moins un ensemble de requêtes est nécessaire. Afin d'obtenir 15 des performances élevées pour le stockage des données et les requêtes qui y sont associées, les données importantes sont conservées en mémoire, en exécutant un certain type de fenêtres glissantes sur les données qui sont en train de subir le processus de validation. Ainsi, seule la validation des données est importante pour le modèle de données. 20 Dans certains modes de réalisation, pour obtenir des performances élevées, un modèle de données qui cible une validation qui repose sur des blocs peut être pris en considération. Cela signifie que les demandes d'informations liées à un bloc doivent être traitées efficacement. Au moins l'une des principales requêtes suivantes est prise en considération : 25 - Obtention des blocs par ID; - Obtention de l'heure de création des blocs ; - Obtention des transactions du stockage par ID de bloc ; - Obtention des informations de statut par ID de bloc ; - Obtention des votes par ID de bloc ; 30 - Obtention du DLE par ID de transaction du stockage Dans certains modes de réalisation, au moins l'une des requêtes suivantes est prise en considération pour la traçabilité des données dans la couche de traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes : 5 - Obtention de la transaction à tracer par ID d'objet de donnée ; - Obtention de la transaction à tracer par ID de service ; - Obtention des agents par ID de transaction à tracer ; - Obtention des services par ID de transaction à tracer - Obtention des agents par ID de propriétaire d'agent ; 10 - Obtention des services par ID de service. Les requêtes sur la couche de traçabilité ne sont pas urgentes (critiques en terme de temps). 15 Dans certains modes de réalisation, le module de vote est caractérisé par des performances élevées et une fonctionnalité de paramétrabilité, étant donné que le vote peut être ajusté selon une taille de fédération réduite, comme par exemple celle d'agents DTP de confiance du fournisseur de la plate-forme de traçabilité de données, avec un temps- 20 système de vote réduit et des latences de stockage correspondantes réduites, et étant donné que le vote peut stocker instantanément et ne nécessite pas, en raison de sa conception architecturale, une durée de stockage minimum comme les autres systèmes, et plus particulièrement ceux qui utilisent un consensus à « preuve de fonctionnement » (comme 25 Bitcoin, avec son minage de blocs). De plus, la technologie de couche de stockage (base de données Apache Cassandra), aussi bien que la conception du module de vote se met à l'échelle (évolue), peut se mettre à l'échelle (évoluer) par sa conception, ce qui permet d'obtenir un débit de stockage total élevé. 30 Dans certains modes de réalisation, la fonctionnalité de paramétrabilité de l'infrastructure technique distribuée est assurée par un 36 programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure pouvant fournir des configurations individuelles. En effet, l'infrastructure distribuée comprend au moins un ensemble d'outils qui permettent de définir les couches architecturales de 5 configuration de la plate-forme (1) sans modifier un quelconque programme stocké dans la mémoire de ladite plate-forme. Ainsi, les couches optimales peuvent être choisies ou remplacées par d'autres couches. Dans certains modes de réalisation, le stockage est séparé en une infrastructure de stockage (base de données (2)) et une gestion du stockage (chaîne de blocs (22)) qui possèdent des configurations complètes et indépendantes, ce qui contribue à la grande capacité de paramétrage (à la fois pour l'architecture de la plate-forme (1) et la configuration propre à la couche). Dans certains modes de réalisation, le service d'approvisionnement en de données (DPS) conserve des preuves d'activité (fourniture de 15 données, accès aux données) de manière transparente pour l'utilisateur. Dans certains modes de réalisation, le service d'approvisionnement en données (DPS) maintient l'activité de fourniture de données, qui requiert d'indiquer les métadonnées connexes, comme les références aux ensembles de données utilisés des autres. 20 Dans certains modes de réalisation, le service d'approvisionnement en données (DPS) conserve l'historique complet d'un ensemble de données en analysant les preuves et en suivant les références au sein des métadonnées afin de permettre le suivi de l'historique complet d'un ensemble de données, et d'identifier tous les utilisateurs qui peuvent 25 contribuer à sa création. Cela est effectué en analysant les modèles de données stockés dans la couche de stockage, en suivant leurs informations corrélées (par exemple, la transaction de traçabilité stocke des informations sur la consommation d'un service, avec l'agent du fournisseur/du consommateur, le service utilisé, le modèle de données d'entrée/de sortie, 30 etc.) et en créant une structure de données graphique qui représente la traçabilité des données de toutes les entités de la plate-forme (objet de données, service, agent, transaction de traçabilité, etc.). 37 Dans certains modes de réalisation, le service d'approvisionnement en données (DPS) étend la fonctionnalité (caractéristique) de propriété pure avec des opérations (création, mise à jour, transfert, suppression, désactivation, activation) destinées à maintenir les ensembles de données 5 sur la plate-forme. Dans certains modes de réalisation, la plate-forme (1) reçoit une requête en provenance d'un service d'analyse de données complexes qui utilise des modèles d'apprentissage machine (ML) et des ensembles de données d'apprentissage disponibles sur la plate-forme (1) afin d'offrir un 10 service d'analyse par apprentissage machine. Dans certains modes de réalisation, le système comprend : - une chaîne de blocs (22 ) ; et - une ressource de calcul prévue pour exécuter une boucle de sorte que l'exécution de la boucle soit influencée par 15 l'état de la chaîne de blocs (22), la boucle étant mise en oeuvre à l'aide d'un script, afin de conserver un décompte d'un ou plusieurs votes pour la validation des blocs liée au consensus, la validité des blocs ou les décisions de validité des blocs, et un statut de bloc correspondant 20 généré pour ou associé au bloc extrait de la file d'attente de blocs (21) ; et un ensemble de conditions d'invalidité définies par la fédération afin de déterminer la validité des blocs (et validées par chaque agent qui participe à un vote) sont évaluées et au moins une action est menée sur 25 la base du résultat de l'évaluation ; ladite action comprenant au moins: faire qu'au moins une transaction soit écrite dans le volume de la chaîne de blocs (22) de la base de données (2) ; et/ou 30 faire qu'une action hors chaîne de blocs (22) soit exécutée. 38 Dans certains modes de réalisation, pour chaque itération de la boucle, un hachage cryptographique (valeur de hachage) du script est généré, et les informations relatives à au moins une itération de la boucle sont stockées dans une transaction sur la chaîne de blocs (22) ; de 5 préférence, les informations sont stockées sous la forme de métadonnées dans la transaction. Dans certains modes de réalisation, les conditions concernent les données reçues, et les changements de propriété (par l'opération de stockage de chaîne à blocs « TRANSFER », avec c_owner définissant le 10 nouveau propriétaire) détectés ou générés par la ressource de calcul ; (ou l'état de la chaîne de blocs (22)). Dans certains modes de réalisation, la base de données (2) offre un moyen d'identification des processus liés au stockage du groupe de transactions (20), à la file d'attente de blocs (21), à la chaîne de blocs (22) et 15 au dépôt des blocs invalides (23), à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions. Plus spécifiquement, tous les modèles de données fournissent des informations sur l'agent émetteur et sont protégés de manière cryptographique par le biais de signatures, dont l'exactitude peut être prouvée avec la clé publique de 20 l'agent concerné, qui est connue publiquement dans son modèle de données dans la table de base de données de l'agent, rendant ainsi toutes les interactions avec la base de données non seulement traçables, mais également sécurisées de manière cryptographique. La base de données elle-même est strictement « append-only » (à ajout seulement) pour des 25 raisons de traçabilité. Par exemple, les mises à jour sont réalisées sous la forme d'une entrée supplémentaire de la base de données (en référence à l'état précédent), et la suppression sur la base de données n'est même pas mise en oeuvre, mais est détectée (en cas de comportement malhonnête) en raison des relations cryptographiques. 30 Les agents sont les seules entités actives de la plate-forme (1) (contrôlées par des utilisateurs humains ou une logique logicielle) qui travaillent pour le compte d'un propriétaire d'agent, l'utilisateur humain (4) 39 étant légalement responsable des actions des agents qu'il possède. La validité des blocs est déterminée par la vérification d'un ensemble de « conditions d'invalidité » (tout état d'invalidité engendre un vote d'invalidité de bloc), et un seuil paramétrable de votes valides doit être atteint, après 5 quoi chaque vote est sécurisé de manière cryptographique avec une signature de l'agent émetteur. Dans certains modes de réalisation, les processus de stockage de la base de données et de consensus par chaîne de blocs (22) constituent chacun une couche de l'architecture qui peut être supprimée, remplacée ou 10 étendue avec d'autres caractéristiques, comme par exemple une couche d'estimation de la valeur des données. Dans certains modes de réalisation, la plate-forme de traçabilité des données (1) comprend au moins un module d'estimation comprenant au moins un ensemble de modèles et de programmes destinés à estimer la 15 contribution de différents ensembles de données pour la création d'un nouvel ensemble et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l'ensemble de données. Dans certains modes de réalisation, l'ensemble de modèles et de programmes comprend au moins un modèle d'estimation de valeur de 20 Shapley. La valeur de Shapley peut estimer la valeur d'un ensemble de données et/ou la contribution relative d'ensembles de données d'entrée à la valeur de l'ensemble de données résultant. Par exemple, et de manière non limitative, un ensemble de données d'origine peut être partagé sur la plate-forme (1) par un premier utilisateur. Ledit ensemble de données peut être 25 modifié par un second utilisateur (4, figure 2c) (consommateur des données) ou un troisième utilisateur (4) et réutilisé sur la plate-forme. La mise en oeuvre des outils de traçabilité de la plate-forme (1) de la présente invention peut permettre de suivre la provenance partagée des ensembles de données, et chacune de leurs transformations. Lesdites informations sont 30 ainsi saisies sous la forme d'une entrée dans le module d'estimation, qui délivre à son tour la contribution de chaque utilisateur (4) au nouvel ensemble de données (l'ensemble de données qui résulte de toutes les transformations), voir la figure 2d. Lesdits résultats peuvent être utilisés pour la rémunération de chaque utilisateur (4) qui a participé à la création du nouvel ensemble de 5 données selon le montant de la participation. La présente demande décrit diverses caractéristiques techniques et 10 avantages en référence aux figures et/ou à divers modes de réalisation. L'homme de métier comprendra que les caractéristiques techniques d'un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne 15 fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné. 20 Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini 25 par la protection demandée, et l'invention REVENDICATIONS1. Infrastructure technique distribuée destinée à un système de plate-forme (1) de traçabilité de données basé sur des agents (DTP) comprenant au moins un serveur de base de métadonnées (2) à architecture en couches et à ressources de calcul, un serveur de surveillance de la qualité des données, un serveur de gestion pour un service d'approvisionnement en données (DPS), et une machine d'interrogation automatique, caractérisée en ce que la base de données (2) est utilisée pour 10 stocker des données et conserver des preuves sécurisées de l'échange de données, de la propriété des données et du transfert de propriété des données dans des objets de données (DO) afin de permettre à un utilisateur (4) d'accéder à des ensembles de données (D0i,..., DOM) fournis par d'autres utilisateurs, et de proposer un ensemble de données accessible par un autre 15 utilisateur (4), et dans laquelle la plate-forme de traçabilité de données est configurée pour suivre de manière sécurisée la propriété d'un ensemble de données (DO) à stocker dans la base de données (2) et pour mettre en place un processus de consensus par fédération (FC) en adaptant la technologie de chaîne de blocs (22), un module de vote décidant de la validité d'un bloc 20 afin de stocker le bloc dans la base de données (2) au cours dudit processus. 2. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que le module de vote de chaque agent de la plate-forme de traçabilité de données d'une « fédération DTP », pendant le consensus 25 par fédération (FC), propose un vote individuel sur la validité, et le total cumulé des votes détermine la validité du bloc, au moins la taille et les participants à la fédération DTP et le seuil de validité étant paramétrables. 3. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la technologie de chaîne de blocs (22) est adaptée 30 pour comprendre un modèle prospectif permettant à un prestataire de service de fournir des informations orientées calcul, en stockant au moins les 2 assertions d'une approche d'accès et de contrôle (AC) dans le cadre d'une transaction, contenant ainsi des informations purement prospectives sur le calcul qui spécifie la logique réelle exécutée. 4. Infrastructure technique distribuée selon les revendications 1 à 3, caractérisée en ce que la technologie de chaîne de blocs (22) est configurée, via la fonctionnalité de stockage et de consignation des données afin de maintenir les informations de traitement, pour comprendre un modèle rétrospectif. 5. Infrastructure technique distribuée selon les revendications 1 à 4, caractérisée en ce que la technologie de chaîne de blocs (22) est configurée pour comprendre un modèle pro-/rétrospectif mixte avec la fonctionnalité d'un système de gestion de processus distribué, la combinaison des informations pro- et rétrospectives permettant le suivi du calcul et l'évaluation de la fiabilité du résultat du calcul. 6. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce qu'elle comprend au moins une infrastructure de clés publiques (PKI) qui permet d'utiliser des outils cryptographiques asymétriques pour sécuriser les transactions d'un ensemble de données ou d'objets de données (DO) et suivre la propriété d'un ensemble de données. 7. Infrastructure technique distribuée selon la revendication 6, caractérisée en ce qu'une clé publique et privée unique est générée pour la création d'un compte d'agent, afin de permettre audit agent d'utiliser au moins un outil cryptographique asymétrique de l'infrastructure de clés publiques. 8. Infrastructure technique distribuée selon la revendication 7, caractérisée en ce que ladite clé publique et privée unique permet également audit agent d'agir comme une entité DTP active, qui est active dans une machine qui exécute une instance DTP et qui est responsable des actions de l'instance à l'aide des signatures numériques de toutes les communications qui utilisent ladite clé privée. 3 9. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce qu'elle comprend au moins un système d'accès et de contrôle (AC) qui maintient l'accès aux services disponibles et/ou qui contrôlent la création de services frauduleux au sein de la plate-forme, tandis 5 que les droits d'accès sont spécifiés par chaque prestataire de service (3) qui crée une preuve de droit d'accès pour l'utilisateur concerné à l'aide des fonctionnalités de gestion des données de la chaîne de blocs, ledit système AC permettant une traçabilité inter- et intra-service si des assertions appropriées sont fournies par un prestataire de service (3). 10 10. Infrastructure technique distribuée selon la revendication 9, caractérisée en ce que le prestataire de service (3) spécifie, pour un service numérique consommable, à l'aide d'une interface interactive basée sur un navigateur Web, des métadonnées de provenance qui permettent une traçabilité inter-service et intra-service, et au moins des détails à propos du 15 calcul effectué et des objets de données (DO) de sortie prévus. 11. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la base de données (2) est conçue pour gérer les charges de travail élevées et les fonctionnalités en parallèle, ladite base étant distribuée avec des performances de correction linéaire, optimisées 20 pour les opérations d'écriture. 12. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que la base de données (2) est Apache Cassandra. 13. Infrastructure technique distribuée selon la revendication 1 ou 11 ou 12, caractérisée en ce que la base de données (2) comprend au moins 25 une couche de stockage comprenant au moins un stockage de groupe de transactions (20), un stockage de file d'attente de blocs (21), un stockage de chaîne de blocs (22), un stockage de blocs invalides, et un lac de données (24). 14. Infrastructure technique distribuée selon les revendications 1 et 30 13, caractérisée en ce que ladite couche de stockage comprend au moins un 4 ensemble de modules : un module de groupe de transactions (20) destiné à traiter les transactions qui entrent dans le stockage de groupe de transactions (20) et vont être stockées dans les blocs de la file d'attente de blocs (21), un module de file d'attente de blocs (21) destiné à traiter les blocs 5 qui ne sont pas encore validés et qui sont soumis au consensus pour la validation des blocs distribués, un module de chaîne à blocs (22) destiné à traiter les blocs validés, un module de dépôt de blocs invalides (23) destiné à traiter les blocs qui ont été validés comme étant invalides pendant la validation de blocs par consensus par un module de vote de blocs, un 10 module de gestion de stockage destiné à stocker et à traiter des entités supplémentaires qui font partie des blocs et des transactions, notamment les votes qui sont requis pour le vote de blocs, des statuts de blocs utilisés pour persister le résultat d'un vote de validité de blocs et d'éléments de lac de données (DLE) (24) extraits pour améliorer les performances en raison de 15 leur taille de données variable. 15. Infrastructure technique distribuée selon la revendication 14, caractérisée en ce que l'exécution du module de gestion du stockage permet au stockage de groupes de transactions (20) au moins de recevoir les transactions brutes entrantes, de vérifier les transactions à l'aide d'un 20 algorithme de validation approfondie, d'affecter les transactions entrantes à un agent DTP par le biais d'une stratégie de sélection, et d'ajouter lesdites transactions vérifiées au stockage de groupes de transactions (20). 16. Infrastructure technique distribuée selon la revendication 15, caractérisée en ce que l'algorithme de validation approfondie (DV) permet de 25 valider par la suite des données arbitraires par toutes les couches architecturales DTP, en validant ainsi les données éventuellement imbriquées en profondeur, pendant que la logique de validation est fournie par le biais de « validateurs » qui ont exécuté la validation sous une forme sémantiquement capsulée optimisée pour une exécution simultanée. 30 17. Infrastructure technique distribuée selon les revendications 14 et 15, caractérisée en ce que le module de groupes de transactions (20) 5 identifie les transactions vérifiées à l'aide de l'agent DTP assigné qui est responsable de l'exécution du module de groupes de transactions, crée des blocs en utilisant l'autorisation des transactions, transmet les blocs à stocker dans la file d'attente de blocs (21), et supprime les transactions utilisées du 5 stockage de groupes de transactions (20). 18. Infrastructure technique distribuée selon les revendications 1 à 17, caractérisée en ce que l'exécution du module de vote permet au moins de vérifier si l' « ID » (identité) d'un agent se trouve dans une liste de votants stockée dans la couche de stockage de la base de données, d'exécuter un 10 processus de validation approfondie pour déterminer la validité d'un bloc, d'ajouter un vote au bloc correspondant au résultat de la validation, et de déclencher ou non une minuterie pour chaque vote manquant. 19. Infrastructure technique distribuée selon les revendications 1 et 13, caractérisée en ce que la couche de stockage comprend au moins : 15 - une liste des agents et des services qui existent sur la plate-forme. Lesdits agents et services ont été créés et stockés dans un bloc qui a été validé. Ladite liste tient compte de tous les états créés, désactivés et supprimés. - une mémoire cache (BBC) de blocs de chaîne de 20 blocs (22), qui est une mémoire cache d'un certain nombre de blocs, pour lesquels une décision a été prise (stockés dans la chaîne de blocs (22) ou dans le dépôt de blocs invalides (23)), qui sont conservés en mémoire pour des raisons de performances. Ladite mémoire cache est matérialisée comme 25 une file d'attente limitée en taille (paramètre de configuration) qui utilise des HashMaps sous-jacents pour une recherche efficace d'au moins tous les ID de blocs (identités de blocs), ID de transactions - une mémoire cache de blocs de consensus 30 (CBC), qui est analogue à la mémoire cache de chaîne de 6 blocs (22) et qui est utilisée pour les blocs pour lesquels aucune décision n'a été prise. - une liste de vote, conservée par chaque agent, qui comprend les blocs pour lesquels un vote est exigé par 5 l'agent correspondant, c'est-à-dire lorsque l'ID de l'agent a été ajouté à la liste des « agents votants » du bloc (ID des agents qui doivent fournir un vote), mais qu'aucun vote n'a encore été fourni ; - une mémoire cache de groupes de transactions 10 (PTC), qui conserve les transactions issues du groupe de transactions (20). - une liste d'autorisations de transaction (TLC). Ladite liste contient au moins les informations suivantes afin de décider si une transaction peut être ajoutée à un bloc 15 destiné à être stocké : - une transaction précédente (le cas échéant) est stockée dans un bloc validé - un agent émetteur d'une transaction n'est pas placé sur liste noire 20 - toutes les données (DLE, agent, etc.) sont disponibles dans le système afin de procéder à leur vérification. 20. Infrastructure technique distribuée selon les revendications 1 et 13, caractérisée en _ce que la couche de traçabilité comprend au moins un 25 module « agents » destiné à stocker le modèle de données d'agent de traçabilité, un module d'objets de données (DO) destiné à stocker le modèle de données des objets de données de traçabilité (DO), un module « service » destiné à stocker le modèle de données du service de traçabilité, et un module « transactions » destiné à stocker les transactions de la couche 30 de traçabilité. 7 21. Infrastructure technique distribuée selon la revendication 20, caractérisée en ce que les entités de traçabilité sont également identifiées par un « ID statique » qui ne change pas pendant une mise à jour et comprend au moins : 5 - Propriétaire de l'agent (AgentOwner) : « agent_owner id » (ID unique) - Agent : « agent_id » (clé publique) - Service : « service_id » (ID unique) « service_version » 10 22. Infrastructure technique distribuée selon la revendication 19, caractérisée en ce que, dans la couche de stockage, au moins l'une des requêtes suivantes est prise en considération pour garantir le traitement efficace des informations liées à un bloc : - Obtention des blocs par ID; 15 - Obtention de l'heure de création des blocs ; - Obtention des transactions du stockage par ID de bloc ; - Obtention des informations de statut par ID de bloc ; - Obtention des votes par ID de bloc ; - Obtention du DLE par ID de transaction du stockage 20 23. Infrastructure technique distribuée selon les revendications 20 et 21, caractérisée en ce que les requêtes suivantes sont prises en considération pour la traçabilité des données dans la couche de traçabilité, qui sont réalisées en tant que requêtes de base de données avec les informations correspondantes : 25 - Obtention de la transaction à tracer par ID d'objet de donnée ; - Obtention de la transaction à tracer par ID de service ; - Obtention des agents par ID de transaction à tracer; - Obtention des services par ID de transaction à tracer ; - Obtention des agents par ID de propriétaire d'agent ; 30 - Obtention des services par ID de service. 8 24. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le module de vote, ayant des performances élevées et une fonctionnalité de paramétrabilité, permet: - d'ajuster le vote selon une taille de fédération réduite, avec 5 un temps-système de vote réduit et des latences de stockage correspondantes réduites, - de stocker instantanément le vote sans que la conception architecturale exige une durée de stockage minimale. 25. Infrastructure technique distribuée selon la revendication 24, 10 caractérisée en ce que la technologie de couche de stockage de la base de données est configurée pour mettre à l'échelle sa conception architecturale et obtenir un débit de stockage total élevé. 26. Infrastructure technique distribuée selon les revendications 1 et 24, caractérisée en ce que la fonctionnalité de paramétrabilité de 15 l'infrastructure technique distribuée est assurée par un programme et des fichiers de configuration propres aux couches, chaque couche de ladite infrastructure étant apte à fournir des configurations individuelles. 27. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d'approvisionnement en données (DPS) 20 conserve des preuves d'activité de manière transparente pour l'utilisateur. 28. Infrastructure technique distribuée selon les revendications 1 et 28, caractérisé en ce que le service d'approvisionnement en données (DPS) maintient l'activité de fourniture de données, qui requiert d'indiquer les métadonnées connexes comme les références aux ensembles de données 25 utilisés des autres. 29. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d'approvisionnement en données (DPS) conserve l'historique complet d'un ensemble de données en analysant les preuves et en suivant les références au sein des métadonnées afin de 9 permettre le suivi de l'historique complet d'un ensemble de données, et d'identifier tous les utilisateurs qui peuvent contribuer à sa création. 30. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que le service d'approvisionnement en données (DPS) est 5 configuré pour étendre la fonctionnalité de propriété pure via des opérations de maintien d'ensembles de données sur la plate-forme. 31. Infrastructure technique distribuée selon la revendication 1, caractérisé en ce que la plate-forme (1) est configurée pour recevoir une requête en provenance d'un service d'analyse de données complexes, ledit 10 service d'analyse utilisant des modèles d'apprentissage machine (ML) et des ensembles de données d'apprentissage disponibles sur la plate-forme (1) afin d'offrir un service d'analyse par apprentissage machine. 32. Infrastructure technique distribuée selon la revendication 5, caractérisé en ce que le système comprend : 15 - une chaîne de blocs (22) ; et - une ressource de calcul prévue pour exécuter une boucle de sorte que l'exécution de la boucle soit influencée par l'état de la chaîne de blocs (22), la boucle étant mise en oeuvre à l'aide d'un script, 20 afin de conserver un décompte d'un ou plusieurs votes pour la validation des blocs liée au consensus, la validité des blocs ou les décisions de validité des blocs, et un statut de bloc correspondant généré pour ou associé au bloc extrait de la file d'attente de blocs (21) ; et un ensemble de 25 conditions d'invalidité définies par la fédération afin de déterminer la validité des blocs, et validées par chaque agent qui participe à un vote sont évaluées et au moins une action est menée sur la base du résultat de l'évaluation ; ladite action comprenant au moins: 10 - faire qu'au moins une transaction soit écrite dans le volume de chaîne de blocs (22) de la base de données (2) ; et/ou - faire qu'une action hors chaîne de blocs 5 soit exécutée. 33. Infrastructure technique distribuée selon la revendication 1 à 31, caractérisé en ce que, pour chaque itération de la boucle, un hachage cryptographique du script est généré, et les informations relatives à au moins une itération de la boucle sont stockées dans une transaction sur la chaîne 10 de blocs (22), les informations étant stockées sous la forme de métadonnées dans la transaction. 34. Infrastructure technique distribuée selon la revendication 1 à 32, caractérisé en ce que les conditions concernent les données reçues, et les changements de propriété détectés ou générés par la ressource de calcul ; 15 ou l'état de la chaîne de blocs (22). 35. Infrastructure technique distribuée selon les revendications 1 à 33, caractérisée en ce que la base de données (2) offre un moyen d'identification des processus liés au stockage du groupe de transactions (20), à la file d'attente de blocs (21), à la chaîne de blocs (22) et au dépôt 20 des blocs invalides (23), à la gestion des blocs, aux agents, aux objets de données, aux services et à la traçabilité des transactions. 36. Infrastructure technique distribuée selon la revendication 1 à 34, caractérisé en ce que les processus de stockage de la base de données (2) et de consensus par chaîne de blocs (22) constituent chacun une couche de 25 l'architecture qui peut être supprimée, remplacée ou étendue avec d'autres caractéristiques. 37. Infrastructure technique distribuée selon la revendication 1, caractérisée en ce que la plate-forme de traçabilité des données comprend au moins un module d'estimation, ledit module comprenant au moins un 30 ensemble de modèles et de programmes destinés à estimer la contribution de différents ensembles de données pour la création d'un nouvel ensemble 11 et, ainsi, à estimer un barème de rémunération équitable pour la réutilisation de l'ensemble de données. 38. Infrastructure technique distribuée selon la revendication 37, caractérisée en ce que l'ensemble de modèles et de programmes du module d'estimation comprend au moins un modèle d'estimation de valeur de Shapley, ladite valeur de Shapley estimant la valeur d'un ensemble de données et/ou la contribution relative d'ensembles de données d'entrée à la valeur de l'ensemble de données résultant. 39. Infrastructure technique distribuée selon les revendications 37 et 10 38, caractérisée en ce que le module d'estimation est utilisé pour la rémunération de chaque utilisateur (4) qui a participé à la création du nouvel ensemble de données selon le montant de la participation.