Brevet FR3146743A1 — publié le 20240920

L'invention propose un procédé de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données, le procédé étant mis en œuvre par un dispositif de vérification et caractérisé en ce qu’il comprend les étapes suivantes : obtention d’une commande émise à destination dudit service ; obtention de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ; obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ; vérification de ladite au moins une première donnée en fonction dudit deuxième résultat. Figure pour l'abrégé : Figure 3 Procédé et dispositif de vérification d’au moins une donnée obtenue depuis un service de fourniture de données 1. Domaine de l'invention L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »). 2. Art Antérieur Une chaîne de bloc est un système d'exécution de confiance garantissant, par exemple, l'intégrité et la transparence de l'exécution d’un processus. Concrètement, la chaîne de blocs forme une base de données distribuée dont les utilisateurs jouent un rôle actif dans sa mise à jour. Elle stocke de manière sécurisée, dans plusieurs blocs de données connectés/chaînés entre eux, l’historique de toutes les transactions effectuées par les utilisateurs. Elle est en outre accessible par chaque utilisateur sans aucun intermédiaire. Ainsi, chaque utilisateur a la possibilité de vérifier les données qui la constituent et donc sa validité. Les contrats intelligents (en anglais « smart contract ») des chaînes de blocs permettent, par exemple, la gestion de l'exécution de tâches du processus et l'attribution de ces tâches de manière décentralisée et fiable. L'objectif de ces contrats intelligents est de digitaliser les processus physiques en remplaçant les contrats papiers par du code informatique. Pour fonctionner correctement, certains contrats intelligents peuvent avoir besoin de données externes à la chaîne de blocs. Or la chaîne de blocs ne peut pas accéder à des données stockées en dehors de son réseau. Pour résoudre ce problème, le contrat intelligent a la possibilité d’utiliser les services d’un « oracle » qui a la possibilité d’ajouter des données du monde extérieur au sein d’une chaîne de blocs. Les oracles fournissent de nombreuses données comme par exemple des températures, des résultats sportifs, des horaires, etc. En fonction des informations fournies par les Oracles, le contrat intelligent s’exécutera ou non. Force est de constater qu’il n’existe pas de mécanisme technique qui permette de s’assurer que l’oracle est bien de confiance ou que celui-ci n’a pas commis une erreur dans la fourniture des informations. 3. Exposé de l'invention L'invention vient améliorer l'état de la technique et propose à cet effet un procédé de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données, le procédé étant mis en œuvre par un dispositif de vérification et caractérisé en ce qu’il comprend les étapes suivantes : obtention d’une commande émise à destination dudit service ; obtention de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ; obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ; vérification de ladite au moins une première donnée en fonction dudit deuxième résultat. Avantageusement, l’invention permet de contrôler les informations/données fournies par un service de fourniture de données. Concrètement, le procédé obtient une commande émise, par exemple par un utilisateur, à destination d’un service de fourniture de données et une ou plusieurs données (première(s) donnée(s)) correspondant au résultat (premier résultat) de l’exécution de la commande par le service. Il obtient également un deuxième résultat d’exécution de la commande (la commande pouvant être exécutée par le procédé lui-même) puis vérifie la ou les données obtenues du service par exemple via une comparaison des résultats d’exécution de la commande. S’ils sont identiques alors la ou les données fournies par le service sont considérées comme vérifiées. Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ledit service fournit à une chaîne de blocs des données externes à ladite chaîne de blocs et en ce que ladite commande est obtenue depuis un premier contrat intelligent inscrit à ladite chaîne de blocs et ladite au moins une première donnée est obtenue depuis un deuxième contrat intelligent inscrit à ladite chaîne de blocs. Avantageusement, ce mode de réalisation permet de contrôler les informations/données fournies par un service de fourniture de données externes à une chaîne de blocs tel qu’un oracle. De ce fait, ce mode de réalisation propose un nouveau rôle associé à la gestion d’une chaîne de blocs ; celui de vérificateur de données d’oracle. En effet, un oracle peut fortuitement ou sciemment (par exemple lorsque celui-ci est malveillant) retourner des données erronées ou bien omettre des données dans sa réponse. Ainsi, l’invention permet de vérifier le résultat (i.e. des données) obtenu à la suite de l’exécution d’une commande par un oracle et sa complétude. Concrètement, le procédé obtient depuis un premier contrat intelligent inscrit à la chaîne de blocs une commande émise par un utilisateur à destination d’un premier oracle. Le procédé obtient également le résultat de l’exécution de la commande par le premier oracle par exemple depuis un deuxième contrat intelligent. Selon un mode particulier de réalisation, le premier et le deuxième contrat intelligent est un seul et même contrat intelligent. Selon un mode particulier de réalisation, la commande peut être obtenue depuis le premier contrat intelligent et depuis l’utilisateur de la chaîne de blocs. Ce mode de réalisation permet comparer les requêtes obtenues et de s’assurer que la requête à traiter par le procédé, c’est-à-dire émise par le premier utilisateur à destination de l’oracle est bien la bonne. Le procédé obtient ensuite un deuxième résultat d’exécution de la commande, par exemple depuis un deuxième oracle. Puis, le procédé vérifie le premier résultat par exemple en le comparant au deuxième résultat. S’ils sont identiques alors les données fournies par le service (c’est-à-dire le premier oracle) sont considérées comme valides. Selon un mode particulier de réalisation, le procédé peut lui-même exécuter la commande, dans ce cas le procédé peut être considéré comme le deuxième oracle. Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite étape de vérification correspond à une comparaison de ladite au moins une première donnée avec ledit deuxième résultat et lorsque le résultat de ladite comparaison est négatif une demande de validité de tout ou partie dudit deuxième résultat est émise à destination d’un troisième contrat intelligent inscrit à ladite chaîne de blocs. Ce mode de réalisation permet de valider tout ou partie du deuxième résultat d’exécution de la commande auprès d’un contrat intelligent (troisième contrat intelligent au sens de l’invention) inscrit à la chaîne de blocs. Un contrat intelligent n’étant pas altérable dans le temps l’ensemble des tests réalisés par le troisième contrat intelligent sur le deuxième résultat d’exécution peuvent être considérés comme certifiés. Ainsi, le résultat de ces tests permet de certifier la validité de tout ou partie du deuxième résultat d’exécution de la commande. L'invention propose également un procédé de validation, par un contrat intelligent inscrit à une chaîne de blocs, d’au moins une donnée obtenue depuis un service de fourniture à ladite chaîne de blocs de données externes à ladite chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes : obtention d’une requête émise à destination dudit service, ladite requête comprenant une première estampille temporelle et une commande ; obtention d’un premier résultat d’exécution de ladite commande par ledit service ; obtention de tout ou partie d’un deuxième résultat d’exécution de ladite commande comprenant ladite au moins une donnée associée à une signature électronique et à une deuxième estampille temporelle ; et lorsque ladite au moins une donnée n’est pas comprise dans ledit premier résultat vérification de la validité de ladite au moins une donnée via le contrôle de la validité de ladite signature, de l’antériorité de ladite deuxième estampille temporelle par rapport à ladite première estampille temporelle et de la validité de ladite au moins une donnée comme résultat de ladite commande. Avantageusement, l’invention permet de s’assurer de la validité des informations/données fournies par un service de fourniture de données d’une chaîne de blocs. Concrètement, le procédé obtient par exemple d’un premier utilisateur inscrit à une chaîne de blocs une demande d’information/de donnée(s) (requête au sens de l’invention) émise à destination d’un premier oracle (service de fourniture de données au sens de l’invention). La demande comprend au moins une commande à exécuter par l’oracle et une première estampille temporelle indiquant par exemple la date d’émission ou de création de la demande /requête. Le procédé obtient ensuite le résultat de l’exécution de la commande par l’oracle. Le résultat est par exemple obtenu depuis un contrat intelligent inscrit à la chaîne de blocs. Le procédé obtient par la suite tout ou partie d’un deuxième résultat d’exécution de la commande par exemple via un deuxième utilisateur de la chaîne de blocs tel qu’un deuxième oracle. La réponse comprend une ou plusieurs données avec pour chaque donnée obtenue une signature électronique et une deuxième estampille temporelle associée. Par exemple, lorsque la commande est une requête de type SQL (Structure Query Language en anglais) la ou les données peuvent correspondre à un ou plusieurs enregistrements d’une base de données (une ligne ou plusieurs lignes de la base de données). La deuxième estampille temporelle peut alors correspondre à une information sur la chronologie de l’écriture de la donnée au sein de la base de données comme par exemple l’index de la base de données lorsque celle-ci est seulement accessible en écriture (pas de suppression d’enregistrement/donnée/ligne au sein de la base de données) ou bien à un horodatage de la donnée elle-même. La signature électronique peut quant à elle correspondre à la signature électronique de l’entité qui alimente la base de données. Lorsque la ou les données obtenues ne sont pas comprises dans le premier résultat d’exécution de la requête, le procédé vérifie la validité des données reçues via la réalisation de plusieurs tests. Le premier test consiste à vérifier que la signature associée à une donnée est bien valide. Bien évidement cela suppose que le procédé dispose de clef(s) cryptographique(s) (privé et/ou publique) permettant cette vérification. Le deuxième test a pour but de vérifier que les données reçues sont bien antérieures à la création ou à l’émission de la requête. Pour cela le procédé vérifie que l’estampille temporelle de la requête est bien postérieure aux estampilles temporelles des données. Enfin, le procédé vérifie également que les données reçues correspondent bien à une réponse valide de la requête. Dans le cas où les données reçues correspondent à une ou plusieurs lignes d’une base de données, le procédé vérifie que l’ensemble des données correspondent à un résultat possible d’exécution de la commande SQL. On entend par commande une instruction informatique permettant l’exécution d’un ordre, d’une action ou d’une suite d’ordres et d’actions. On entend par signature électronique (ou signature numérique) une suite de caractères permettant d’authentifier l’auteur d’une donnée (par exemple l’entité qui a ajouté une donnée à une base de données) et d’en garantir l’authenticité. La signature électronique peut également permettre de garantir l’inaltérabilité de la donnée une fois celle-ci signée par l’entité qui la détient/partage. De façon connue, l'essentiel des procédures de signature numérique existantes s’appuie sur la cryptographie asymétrique comme l’algorithme RSA. Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de vérification est suivie par une étape d’émission d’une notification de validité de ladite au moins une donnée. Ce mode de réalisation permet d’informer/notifier un utilisateur de la chaîne de blocs (oracle ou non) de la validité ou de la non-validité des données obtenues. Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite étape de vérification est précédée d’une étape d’obtention (E20) d’un paramètre dont la valeur correspond à un montant financier et en ce que lorsque le résultat de ladite vérification est positif tout ou partie de la valeur dudit paramètre est émis (E120, E121) à destination d’un utilisateur de ladite chaîne de blocs. Ce mode de réalisation permet de rémunérer un utilisateur (par exemple un deuxième oracle) de la chaîne de blocs lorsque celui-ci fournit/trouve une donnée valide (c’est-à-dire une donnée qui correspond à tout ou partie d’un résultat possible d’exécution de la commande) non transmise par l’oracle. Pour ce faire le procédé obtient, par exemple du premier oracle, un paramètre dont la valeur correspond à un montant financier. La valeur du paramètre peut correspondre à un montant libellé dans une monnaie d’un pays, à un nombre défini de jetons d’une cryptomonnaie ou plus généralement à une valeur marchande quelconque (par exemple des jetons de calcul d’un serveur informatique). Concrètement, le paramètre peut être assimilé à une caution/séquestre consentie par l’oracle en cas d’erreur de celui-ci. Lorsqu’une erreur est avérée tout ou partie de la caution est reversée à l’utilisateur (par exemple sur un de ses contrats intelligent) qui a permis de détecter l’erreur, c’est-à-dire à l’utilisateur qui a fourni au procédé une donnée valide non transmise par l’oracle. L'invention concerne également un dispositif de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données caractérisé en ce qu’il comprend : un premier module d’obtention d’une commande émise à destination dudit service ; un deuxième module d’obtention de ladite moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ; un troisième module d’obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ; un module de vérification de ladite au moins une première donnée en fonction dudit deuxième résultat. Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de vérification et/ou de validation décrits ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Ce dispositif de vérification et le programme d'ordinateur mettant en œuvre le procédé de vérification présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de vérification. Le programme d'ordinateur mettant en œuvre le procédé de validation présente des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de validation. 4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention ; La représente l’architecture matérielle d’un dispositif de vérification selon un mode particulier de réalisation. La représente sous forme d’organigramme les principales étapes des procédés de vérification et de validation selon un mode particulier de réalisation de l’invention, 5. Description d'un mode de réalisation de l'invention La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation. L’environnement représenté en comprend une chaîne de blocs BC et une base de données BDD. L’environnement comprend aussi deux terminaux O et BH appartenant à des utilisateurs de la chaîne de blocs aptes à fournir à la chaîne de blocs des données externes à la chaîne de blocs. Le terminal O appartient par exemple à un oracle. Le terminal BH intègre un dispositif de vérification apte à mettre en œuvre le procédé de vérification et peut également appartenir à un oracle. L’environnement comprend en outre un terminal S appartenant à un utilisateur de la chaîne de blocs BC. La chaîne de blocs BC et/ ou un contrat intelligent inscrit à la chaîne de blocs BC est apte à mettre en œuvre le procédé de validation. Les terminaux O, S et BH sont par exemple des terminaux de type smartphone (téléphone intelligent en anglais), tablette, serveur, télévision connectée, objet connecté, ordinateur de bord d’une voiture, ordinateur personnel ou tout autre terminal apte à communiquer (émettre et/ou recevoir des requêtes) selon les technologies de l’état l’art via par exemple un réseau IP (100), le réseau pouvant être privé ou public. Selon un mode particulier de réalisation de l'invention, la chaîne de blocs BC peut être hébergée par un ou plusieurs serveurs informatiques. La illustre un dispositif DISP configuré pour mettre en œuvre le procédé de vérification selon un mode particulier de réalisation de l'invention. Le dispositif DISP a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de vérification tel que décrit ultérieurement à l’appui de la , lorsque le programme est exécuté par le processeur PROC. A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de vérification selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la et selon les instructions du programme d'ordinateur PG. Le dispositif DISP comprend un premier module d’obtention OBT1 apte à obtenir une commande émise à destination d’un service de fourniture de données comme par exemple un oracle d’une chaîne de blocs. La commande peut être obtenue depuis un utilisateur de la chaîne de blocs ou bien depuis un contrat intelligent inscrit à la chaîne de blocs. Le dispositif DISP comprend aussi un deuxième module d’obtention OBT2 apte à obtenir au moins une donnée correspondant à un résultat d’exécution de la commande par le service de fourniture de données. Le dispositif DISP comprend également un troisième module d’obtention OBT3 apte à obtenir un deuxième résultat d’exécution de ladite commande. Le deuxième résultat est par exemple obtenu par le dispositif DISP à la suite de l’exécution de la commande par le procédé de vérification. Le dispositif DISP comprend en outre un module de vérification VERIF de la ou des données obtenues via le module OBT2. La vérification est par exemple réalisée par comparaison de la ou des données avec le deuxième résultat obtenu via le module OBT3. La illustre des étapes des procédé de vérification et de validation selon un mode particulier de réalisation de l'invention en lien avec l’environnement de mise en œuvre décrit à l’appui de la . Lors de l’étape E30, l’oracle O émet à destination d’un contrat intelligent SC V un paramètre dont la valeur correspond à un montant financier, par exemple un nombre de jetons d’une monnaie cryptographique, un nombre de jetons offrant des crédits d’utilisation de la chaîne de blocs BC ou un montant libellé dans une monnaie officielle d’un pays (Euro, Dollars, etc.). Concrètement, l’oracle O transfère une somme d’argent au contrat intelligent SC V . Cet argent peut être vu comme une caution concédée par l’oracle O permettant par exemple de garantir une certaine qualité de service / d’exécution d’action(s) de sa part. Lorsque l’oracle commet une erreur, la caution peut être utilisée pour dédommager le client et/ou rémunérer l’acteur qui a détecté l’erreur. Le paramètre est reçu par le contrat intelligent SC V lors de l’étape E20. A l’étape E21 le contrat intelligent SC V obtient depuis le terminal S d’un client une commande dont le destinataire est l’oracle O (non représenté). Le contrat intelligent SC V obtient également une première estampille temporelle associée à la commande reçue. Cette estampille correspond par exemple à la date à laquelle la commande a été reçue par le contrat intelligent SC V et/ou à un numéro de bloc de la chaîne de blocs BC associé à la commande. Alternativement, l’estampille temporelle peut correspondre à la date de création la commande et/ou d’émission par le terminal S. Alternativement, la commande est obtenue depuis un contrat intelligent du client (SC C ). La commande est par exemple obtenue via ou à la suite de la réception d’un évènement diffusé au sein de la chaîne de blocs indiquant l’émission, par le contrat intelligent du client, de la commande à destination de l’oracle O. Selon un mode particulier de réalisation de l’invention, le contrat intelligent SC V relaie la commande obtenue du terminal S du client ou du contrat intelligent SC C à destination de l’oracle et du terminal BH. Alternativement, la commande est obtenue par le terminal BH via ou à la suite de la réception d’un évènement diffusé au sein de la chaîne de blocs indiquant l’émission de la commande à destination de l’oracle O. La commande est obtenue par l’oracle O et le terminal BH respectivement aux étapes E31 et E41. Lors de l’étape E32, l’oracle exécute la commande. La commande est par exemple apte à obtenir un ensemble de lignes d’un tableau stocké dans un espace de stockage numérique tel qu’un fichier, une base de données BDD, etc. Par exemple, la commande peut correspondre à une requête effectuée dans un langage informatique de type SQL, NoSQL, OQL, Prolog ou à une liste de paramètres de filtrage permettant d’obtenir, depuis la base de données BDD, un ou de plusieurs enregistrements (i.e. lignes). Prenons le cas d’une requête SQL de données météo. La base de données/table BDD peut correspondre à : Index Latitude Longitude Température Précipitation (Millimètre) Date Signature 1 40.77 -73.96 15°C 5mm D1 S1 2 40.77 -73.96 8°C 8mm D2 S2 3 40.77 -73.96 6°C 7mm D3 S3 4 40.77 -73.96 11°C 0mm D4 S4 5 40.77 -73.96 9°C 0mm D5 S5 La base de données BDD stocke de façon chronologique les relevés de température et de pluviométrie d’une station météo identifiée par sa position GPS (latitude, longitude). Chaque nouvel enregistrement ajouté à la table BDD (index +1) est associé à une signature électronique Sn du service qui a inscrit les informations dans la table et à une donnée de temps Dn (deuxième estampille temporelle au sens de l’invention) indiquant par exemple la date des mesures de température et de pluviométrie. Dans notre cas la signature électronique peut correspondre à la signature du service de météorologie national du pays ou de la localité qui gère la station météo en question. Alternativement, la signature peut correspondre à une empreinte numérique (par exemple un hash) d’une donnée unique appartenant au signataire et stockée dans un de ses contrats intelligent au sein de la chaîne de blocs. La base de données obtient la requête SQL à l’étape E52 et envoie le résultat à destination de l’oracle O lors de l’étape E53. Dans notre exemple la requête SQL peut être : Select * From BDD where Index ≥ 2 Une fois le résultat reçu par l’oracle O (E33), celui-ci le retransmet (E34) à destination du contrat intelligent SC V . Le résultat reçu par le contrat intelligent SC V lors de l’étape E24 peut par exemple correspondre à : Index Latitude Longitude Température Précipitation (Millimètre) Date Signature 2 40.77 -73.96 8°C 8mm D2 S2 3 40.77 -73.96 6°C 7mm D3 S3 4 40.77 -73.96 11°C 0mm D4 S4 Dans l’exemple décrit ci-dessus l’enregistrement de l’index 5 n’est pas présent alors qu’il correspond également un résultat possible de la requête/commande SQL. Le résultat fournit par l’oracle O est donc partiel (erreur par omission). Cette erreur peut être fortuite (problème d’intégrité des données suite à un problème technique / réseau ou bien provoquée par l’oracle par exemple lorsque celui-ci optimise ses processus pour aller plus vite avec pour conséquence un manque de vérification et une qualité de traitement plus faible. Les informations étant fournies par une entité dite de confiance, c’est-à-dire l’oracle O, le contrat intelligent SC V peut ne pas réaliser de test de validité. Selon un mode particulier de réalisation de l’invention, le contrat intelligent SC V peut tester la ou les signatures des données reçues de l’oracle O (résultat de la commande reçu lors de l’étape E24). Le contrat intelligent SC V envoie (E24_1) à destination du contrat intelligent du client SC C le résultat de la commande obtenu de l’oracle O, le résultat étant reçu par le contrat intelligent du client SC C à l’étape E14_1. Bien évidemment cela suppose que le contrat intelligent SC V connaisse l’adresse électronique du contrat intelligent SC C . L’adresse du contrat intelligent SC C est par exemple obtenue lorsque la commande est reçue depuis le contrat intelligent du client SC C (E21). Alternativement, l’adresse électronique du contrat intelligent SC C est envoyée depuis le terminal S en même temps que la commande (E21). Dans le cas où les signatures sont testées et qu’elles ne sont pas valides le contrat intelligent SC V envoie (E24_1) en remplacement ou en plus du résultat de la commande un paramètre indiquant que les données envoyées ne sont pas valides. Lors de l’étape E45, le terminal BH envoie une demande au contrat intelligent SC C pour obtenir le résultat de la commande fourni par l’oracle au contrat intelligent SC C . Selon un mode particulier de réalisation de l’invention, l’envoi de la demande peut être émis suite à la réception (par exemple depuis la chaîne de blocs ou depuis le terminal S) par le terminal BH d’un évènement indiquant que le contrat intelligent SC C et/ou SC V a reçu le résultat de la commande en provenance de l’oracle O. Alternativement, le terminal BH envoie une demande au contrat intelligent SC V pour obtenir le résultat de la commande fourni par l’oracle. La demande est reçue par le contrat intelligent SC C à l’étape E15. Le résultat reçu lors de l’étape E14_1 est ensuite transmis au terminal BH (E16) puis reçu par le terminal BH lors de l’étape E46. A ce stade le terminal BH dispose de la commande reçue lors de l’étape E41 et du résultat de la commande fourni par l’oracle O lors de l’étape E46. Le terminal BH peut alors vérifier le résultat par exemple pour le compte de l’utilisateur du terminal S. Ainsi, lors de l’étape E47, le terminal BH émet la commande à destination de la base de données BDD. La commande est reçue par la base de données lors de l’étape E57. Le résultat de la commande est obtenu par la base de données BDD lors de l’étape E58 puis transmis au terminal BH à l’étape E48. Le terminal BH compare (E49) ensuite les deux résultats de la commande obtenus respectivement lors des étapes E46 et E48 afin de vérifier le résultat transmis par l’oracle O au contrat intelligent SC V . Lorsque les résultats sont identiques le procédé de vérification considère que le résultat fourni par l’oracle O au contrat intelligent SC C / SC V est valide. Dans le cas contraire le procédé de vérification teste la validité de tout ou partie des données obtenues lors de l’étape E48 auprès de la chaîne de blocs et plus particulièrement auprès du contrat intelligent SC V qui met en œuvre le procédé de validation. Concrètement, le terminal BH émet (E49) une demande de validation de tout ou partie des données obtenues lors de l’étape E48 à destination du contrat intelligent SC V . La demande est reçue puis traitée par le contrat intelligent SC V à l’étape E29. Concrètement le contrat intelligent SC V réalise (cumulativement ou alternativement) trois tests afin de déterminer si les données reçues du terminal BH sont valides. Le premier test consiste à vérifier que la signature (Sn) associée à chaque donnée reçue (enregistrement) est bien valide. Bien évidement cela suppose que le procédé dispose de clef(s) cryptographique(s) (privé et/ou publique) permettant cette vérification. Le deuxième test a pour but de vérifier que les données reçues sont bien antérieures à la création ou à l’émission de la requête. Pour cela le procédé vérifie que l’estampille temporelle de la commande est bien postérieure aux estampilles temporelles des données reçues du terminal BH. Enfin, le procédé vérifie également que les données reçues correspondent bien à une réponse valide de la requête. Dans notre exemple, le procédé vérifie que les données reçues correspondent à un résultat possible d’exécution de la commande SQL. Concrètement, le procédé vérifie que l’index de la donnée reçue du terminal BH est bien ≥ 2. Alternativement, la comparaison des résultats de la commande obtenus respectivement lors des étapes E46 et E48 et réalisée par le terminal BH peut être réalisée par le contrat intelligent SC V . Selon un mode particulier de réalisation de l’invention, lorsqu’une donnée reçue du terminal BH n’est pas comprise dans le résultat de la commande obtenu de l’oracle (E24) et que cette donnée est déterminée comme valide par le contrat intelligent SC V , alors tout ou partie de la caution est reversée au terminal BH (étapes E121, E131) et/ou au client S (étapes E120, E110) via par exemple un transfert de tout ou partie du montant de la caution vers un contrat intelligent du client (SC C ) ou du détenteur du terminal BH (SC BH ). Bien évidemment, la ou les données valides reçues du terminal BH et non comprises dans le résultat de la commande obtenu de l’oracle (E24) peuvent également être émises à destination du contrat intelligent du client (SC C ) lors de l’étape E120. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention. Selon d'autres modes particuliers de réalisation de l'invention, l'invention s'applique également à des données autres que des données météo comme par exemple des informations de recyclage d’éléments constituant un produit manufacturier permettant par exemple de calculer l'empreinte carbone du produit en question ou bien des informations de traçabilité d’éléments d’un produit comme les pièces d’une automobile. Procédé de vérification d’au moins une première donnée obtenue depuis un service de fourniture de données (O), le procédé étant mis en œuvre par un dispositif de vérification (DISP) et caractérisé en ce qu’il comprend les étapes suivantes : - obtention (E41) d’une commande émise à destination dudit service ; - obtention (E46) de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ; - obtention (E48) d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ; - vérification (E49) de ladite au moins une première donnée en fonction dudit deuxième résultat. Procédé selon la revendication 1 dans lequel ledit service fournit à une chaîne de blocs (BC) des données externes à ladite chaîne de blocs et en ce que ladite commande est obtenue depuis un premier contrat intelligent (SC V ) inscrit à ladite chaîne de blocs et ladite au moins une première donnée est obtenue depuis un deuxième contrat intelligent (SC C ) inscrit à ladite chaîne de blocs. Procédé selon la revendication 1 dans lequel ladite étape de vérification correspond à une comparaison de ladite au moins une première donnée avec ledit deuxième résultat et lorsque le résultat de ladite comparaison est négatif une demande de validité de tout ou partie dudit deuxième résultat est émise (E49) à destination d’un troisième contrat intelligent (SC V ) inscrit à ladite chaîne de blocs. Procédé de validation, par un contrat intelligent (SC V ) inscrit à une chaîne de blocs, d’au moins une donnée obtenue depuis un service de fourniture à ladite chaîne de blocs de données externes à ladite chaîne de blocs (O), le procédé étant caractérisé en ce qu’il comprend les étapes suivantes : - obtention d’une requête émise à destination dudit service, ladite requête comprenant une première estampille temporelle et une commande ; - obtention (E24) d’un premier résultat d’exécution de ladite commande par ledit service ; - obtention (E29) de tout ou partie d’un deuxième résultat d’exécution de ladite commande comprenant ladite au moins une donnée associée à une signature électronique et à une deuxième estampille temporelle ; et lorsque ladite au moins une donnée n’est pas comprise dans ledit premier résultat - vérification (E29) de la validité de ladite au moins une donnée via le contrôle de la validité de ladite signature, de l’antériorité de ladite deuxième estampille temporelle par rapport à ladite première estampille temporelle et de la validité de ladite au moins une donnée comme résultat de ladite commande. Procédé selon la revendication 4 dans lequel ladite étape de vérification est suivie par une étape d’émission (E120, E121) d’une notification de validité de ladite au moins une donnée. Procédé selon la revendication 4 dans lequel ladite étape de vérification est précédée d’une étape d’obtention (E20) d’un paramètre dont la valeur correspond à un montant financier et en ce que lorsque le résultat de ladite vérification est positif tout ou partie de la valeur dudit paramètre est émis (E120, E121) à destination d’un utilisateur de ladite chaîne de blocs. Dispositif de vérification (DISP) d’au moins une première donnée obtenue depuis un service de fourniture de données caractérisé en ce qu’il comprend : - un premier module (OBT1) d’obtention d’une commande émise à destination dudit service ; - un deuxième module (OBT2) d’obtention de ladite au moins une première donnée correspondant à un premier résultat d’exécution de ladite commande par ledit service ; - un troisième module (OBT3) d’obtention d'au moins une seconde donnée correspondant à un deuxième résultat d’exécution de ladite commande ; - un module de vérification (VERIF) de ladite au moins une première donnée en fonction dudit deuxième résultat. Programme d'ordinateur comportant des instructions pour la mise en œuvre des procédés de vérification et de validation selon l'une quelconque des revendications 1 à 3 et 4 à 6, lorsque le programme est exécuté par un processeur.