FR3108425A1

FR3108425A1 - Procédé de traçabilité d’actions réalisées sur un site

Info

Publication number: FR3108425A1
Application number: FR2002750A
Authority: FR
Inventors: Philippe Calvez; Hammad Aslam KHAN
Original assignee: Engie SA
Current assignee: Engie SA
Priority date: 2020-03-20
Filing date: 2020-03-20
Publication date: 2021-09-24
Anticipated expiration: 2040-03-20
Also published as: FR3108425B1

Abstract

TITRE DE L’INVENTION : PROCÉDÉ DE TRAÇABILITÉ D’ACTIONS RÉALISÉES SUR UN SITE Le procédé (100) de traçabilité d’actions réalisées sur un site, comporte :- une étape (105) de génération d’une entrée dans un registre distribué, ladite entrée comportant un identifiant unique d’un élément matériel du site,- une étape (107) d’assemblage d’une étiquette de stockage comportant une étape (110) d’enregistrement, dans l’étiquette de stockage, de l’identifiant unique généré, puis, de manière itérative :- une étape (115) de lecture, par un lecteur d’étiquette, d’un identifiant enregistré dans l’étiquette,- une étape (120) de réalisation d’une action en relation avec l’élément associé à l’identifiant,- une étape (125) de validation de la réalisation de l’action sur un terminal communicant et- une étape (130) d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué en fonction de l’identifiant lu. Figure pour l'abrégé : figure 1

Description

PROCÉDÉ DE TRAÇABILITÉ D’ACTIONS RÉALISÉES SUR UN SITE

DOMAINE TECHNIQUE DE L’INVENTION

La présente invention vise un procédé de traçabilité d’actions réalisées sur un site. Elle s’applique, notamment, à la conduite d’opérations de maintenance d’un bâtiment.

ÉTAT DE LA TECHNIQUE

Dans le domaine de la gestion immobilière, plusieurs parties prenantes (constructeur, syndic et opérateurs de maintenance, par exemple) coopèrent en vue de garantir le maintien à niveau des installations d’un site administré et en vue de tracer les évolutions du site en question, telles de nouvelles installations d’équipements, des changements d’équipements et autre.

Parmi ces opérations, on peut notamment citer les opérations de maintenance préventive, destinées notamment à constater des irrégularités en amont d’un dégât éventuel et les opérations de maintenance corrective, destinées à réparer une défaillance constatée. De telles opérations couvrent également les modifications de l’installation.

De telles opérations ont lieu à la fois sur les éléments immobiliers du site, comme les murs par exemple, et sur les éléments mobiliers, telles des chaudières par exemple.

Certains systèmes, dits de « GMAO » (pour « Gestion de Maintenance Assistée par Ordinateur »), consistent à stocker sur un serveur privé des données déclaratives des actions des différentes parties prenantes du site administré. Ces systèmes présentent pour principaux désavantages :
- la vulnérabilité des données stockées vis-à-vis d’attaques informatiques, rendant la traçabilité des actions réalisées incertaine,
- la partialité possible de l’hébergeur vis-à-vis d’une ou plusieurs parties prenantes, assurant la méfiance des parties prenantes vis-à-vis du système en cas de dispute entre parties prenantes et
- la durée de vie du système dépendant d’un lien d’affaire entre l’opérateur du système et les parties prenantes, créant le risque d’une perte de données en cas de rupture du lien d’affaires.

Ces solutions propriétaires et l'ensemble du processus de gestion des installations (conception, maintenance corrective et préventive) sont suivis par chaque partenaire impliqué, dans leurs propres solutions. Pour la gestion des installations (maintenance préventive et corrective), l'exécution des tâches est suivie dans des systèmes propriétaires qui peuvent être hors ligne.

Ces solutions présentent les inconvénients suivants :
- il n'y a pas de vue d'ensemble de l'ensemble du processus à un seul endroit, mais des éléments du processus sont stockés par les parties prenantes de manière séparée,
- il est impossible de maintenir et visualiser le cycle de vie d'un bien,
- les paiements sont effectués par l'intermédiaire de canaux bancaires qui dépendent de la soumission par les entrepreneurs des résultats de leurs travaux et des approbations des propriétaires des bâtiments - ces approbations sont hors ligne et ne peuvent pas être suivies si elles sont modifiées et

- les différences dans les registres d'entretien sont une cause de conflits entre les entrepreneurs et les propriétaires de bâtiments.

Aujourd’hui, il existe ainsi un problème de traçabilité des actions réalisées sur un élément de site et d’authentification de cette traçabilité. En effet, il n’existe aucun moyen efficace, durable dans le temps, invulnérable ou résistant aux attaques informatiques et impartial, vis-à-vis des parties prenantes, de garantir effectivement qu’un opérateur a réalisé une action sur un élément. Cette traçabilité mal assurée et mal certifiée conduit à des risques de dégâts sur les équipements, faute de maintenance.

De surcroît, ces systèmes ne permettent pas d’identifier sans équivoque et sans risque de compromission de la donnée un opérateur responsable d’une défaillance du système de maintenance. Au-delà des incidences assurantielles de cette incapacité à déterminer l’opérateur responsable de la défaillance, une telle incapacité empêche la datation d’un dégât. Sans une telle datation, les efforts pour corriger un dégât ou une irrégularité peuvent se révéler inadaptés.

Ces systèmes ne permettent pas de résoudre les problèmes techniques suivants :
- comment s'assurer que l'entretien des bâtiments a bien eu lieu ?
- comment s'assurer que la personne qui effectue une action de maintenance a une compétence certifiée pour effectuer cette activité ?
- comment suivre le cycle de vie des actifs (système de chauffage, système de refroidissement, etc.) installés dans le bâtiment ?

La présente invention vise à remédier à tout ou partie de ces inconvénients.

À cet effet, la présente invention vise un procédé de traçabilité d’actions réalisées sur un site, qui comporte :
- une étape de génération d’une entrée dans un registre distribué, ladite entrée comportant un identifiant unique d’un élément matériel du site,
- une étape d’assemblage d’une étiquette de stockage comportant une étape d’enregistrement, dans l’étiquette de stockage, de l’identifiant unique généré,

puis, de manière itérative :
- une étape de lecture, par un lecteur d’étiquette, d’un identifiant enregistré dans l’étiquette,
- une étape de réalisation d’une action en relation avec l’élément associé à l’identifiant,
- une étape de validation de la réalisation de l’action sur un terminal communicant et
- une étape d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué en fonction de l’identifiant lu.

Grâce à ces dispositions, les actions réalisées par les différents opérateurs sur les différents éléments (immobiliers et mobiliers) d’un site sont stockées dans le registre distribué. Une technologie de registre distribué garantissant l’authenticité des données stockées, un tel procédé permet une traçabilité renforcée susceptible de permettre l’identification d’un opérateur responsable d’une défaillance.

Ces dispositions permettent :
- une collaboration de confiance dans le processus BIM (gestion des informations sur les bâtiments), tant dans les phases de conception que de maintenance,
- l'élimination de la dépendance des contractants à l'égard des systèmes propriétaires,
- le déclenchement automatique des paiements sur la base de règles et d'autorisations dans la technologie du registre distribué utilisé pour les ordres de travail de maintenance corrective,
- l’introduction potentielle d'une nouvelle méthode d'identification des actifs par le biais de balises NFC ("Near Field Communication") qui permettent de stocker les transactions d'un actif dans la chaîne de blocs, ce qui permet de suivre le cycle de vie des actifs,
- en option, l'intégration avec des composants hors-ligne pour fournir des services à valeur ajoutée aux propriétaires de bâtiments, tels que
- des recommandations d'optimisation des coûts pour la gestion des installations et
- de calculer une inférence pour extraire une valeur à partir de faits établis sur les actifs.

Dans des modes de réalisation, l’étiquette comporte une mémoire réinscriptible, le procédé objet de la présente invention comportant, de plus, en aval de l’étape d’enregistrement d’une information représentative de la réalisation d’une action, une étape de mémorisation, dans la mémoire réinscriptible de l’étiquette, d’un identifiant de l’entrée du registre distribué enregistrée au cours de ladite étape d’enregistrement.

Ces modes de réalisation permettent de déterminer rapidement la dernière action réalisée sur un élément par lecture de la mémoire de l’étiquette.

Dans des modes de réalisation, le procédé objet de la présente invention comporte, en amont de l’étape de lecture, une étape d’émission d’une alerte, comportant un identifiant enregistré dans une radio-étiquette, ladite alerte étant émise en fonction d’un calendrier de réalisation d’action de l’élément prédéterminé associé à l’identifiant.

Ces modes de réalisation permettent de réaliser une maintenance préventive et/ou corrective d’un élément selon un calendrier prédéterminé. En effet, l’alerte peut correspondre à la nécessité, pour une partie prenante, de réaliser une action sur un élément en adéquation avec un plan de maintenance par exemple. Une telle alerte peut être émise en fonction d’un calendrier établi dans le cadre d’un contrat intelligent (« smart contract », en anglais) validé par les parties prenantes. Ce contrat intelligent représente alors la logique métier des actes de maintenance, par exemple.

Dans des modes de réalisation, le procédé objet de la présente invention comporte, une étape de mesure d’une durée écoulée entre l’étape d’émission d’une alerte et au moins une des étapes parmi l’étape de lecture de l’identifiant enregistré dans l’étiquette et l’étape de validation de la réalisation de l’action, ladite durée étant enregistrée au cours de l’étape d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué.

Ces modes de réalisation permettent de garantir qu’une action a été réalisée dans un intervalle de temps considéré comme acceptable par les parties prenantes de la gestion du site. En cas de retard d’un opérateur, une pénalité financière peut être imposée au dit opérateur, par exemple. La gestion des pénalités peut être intégrée dans un contrat intelligent validé par les parties prenantes.

Dans des modes de réalisation, un identifiant d’utilisateur associé au lecteur est associé à une clé privée, l’étape d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué comportant une étape d’authentification de la clé privée pour réaliser l’enregistrement si la clé publique est authentifiée.

Ces modes de réalisation permettent de garantir que l’opérateur responsable de la réalisation de l’action est autorisé à réaliser l’action par les parties prenantes de la gestion du site. Dans des modes de réalisation, chaque partie prenante, et donc chaque opérateur et chaque élément, est associé à un identifiant unique de manière à garantir l’identification des acteurs et des choses concernées.

Dans des modes de réalisation, le procédé objet de la présente invention comporte une étape de saisie d’information en amont de l’étape de validation, un identifiant représentatif de chaque information saisie étant enregistré au cours de l’étape d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre.

Ces modes de réalisation permettent de garantir la traçabilité de contenus associés à la réalisation d’une action. Ceci permet, par exemple, d’authentifier un commentaire textuel en relation avec une irrégularité constatée par un opérateur au cours de la réalisation de l’action, ce commentaire pouvant être stocké par ailleurs.

BRÈVE DESCRIPTION DES FIGURES

D’autres avantages, buts et caractéristiques particulières de l’invention ressortiront de la description non limitative qui suit d’au moins un mode de réalisation particulier du procédé objet de la présente invention, en regard des dessins annexés, dans lesquels :

représente, schématiquement, et sous forme d’un logigramme, une succession d’étapes particulières du procédé objet de la présente invention,

représente, schématiquement, un mode de réalisation particulier d’un système susceptible de mettre en œuvre le procédé objet de la présente invention et

représente, schématiquement, un registre distribué comportant une pluralité d’entrées organisées de manière non-linéaire.

La présente description est donnée à titre non limitatif, chaque caractéristique d’un mode de réalisation pouvant être combinée à toute autre caractéristique de tout autre mode de réalisation de manière avantageuse.

On note dès à présent que les figures ne sont pas à l’échelle.

On note que le terme « site » désigne un espace comportant au moins un élément mobilier ou immobilier. Un tel site peut être à usage professionnel ou personnel. Par exemple, le terme « site » peut faire référence à un immeuble comportant une structure immobile et un système de sécurité d’incendie.

On note que le terme « registre distribué » désigne un registre informatique simultanément enregistré et synchronisé sur un réseau d'ordinateurs, qui évolue par l'addition de nouvelles informations préalablement validées par l'entièreté du réseau et destinées à ne jamais être modifiées ou supprimées. Un registre distribué n'a ni administrateur central ni stockage de données centralisé. Un réseau pair-à-pair et un algorithme de consensus sont nécessaires afin d'assurer le fonctionnement du système. Une des formes de registre distribué est le système de la chaîne de blocs, qui peut être publique, privée, à permission ou à consortium.

On observe, sur la figure 1, qui n’est pas à l’échelle, une vue schématique d’une succession particulière d’étapes du procédé 100 objet de la présente invention. Ce procédé 100 de traçabilité d’actions réalisées sur un site comporte :
- une étape 105 de génération d’une entrée dans un registre distribué, ladite entrée comportant un identifiant unique d’un élément matériel du site,
- une étape 107 d’assemblage d’une étiquette de stockage comportant une étape 110 d’enregistrement, dans l’étiquette de stockage, de l’identifiant unique généré,

puis, de manière itérative :
- une étape 115 de lecture, par un lecteur d’étiquette, d’un identifiant enregistré dans l’étiquette,
- une étape 120 de réalisation d’une action en relation avec l’élément associé à l’identifiant,
- une étape 125 de validation de la réalisation de l’action sur un terminal communicant et
- une étape 130 d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué en fonction de l’identifiant lu.

L’étape 105 de génération d’une entrée est réalisée, par exemple, par un serveur central. Une entrée dans le registre distribué comporte :
- un identifiant d’une entrée enregistrée sur le registre précédemment (a minima, celui de la première entrée du registre permettant l’initialisation dudit registre)

- l’identifiant unique d’élément associé à l’entrée,
- un identifiant d’entrée propre obtenu par hachage de données stockées dans l’entrée et
- des données stockées dans l’entrée.

On rappelle ici qu’une fonction de hachage (en anglais « hash function ») est une fonction particulière qui, à partir d'une donnée fournie en entrée, calcule une empreinte servant à identifier rapidement la donnée initiale, au même titre qu'une signature pour identifier une personne.

Un exemple d’un tel registre et d’entrées est présenté en figure 3. Dans cette figure 3, on observe :
- une entrée initiale 300 comportant un identifiant 305 d’entrée arbitraire ou obtenu à partir du hachage de données 310 de ladite entrée 300 initiale,
- un ensemble d’entrées 315 successives comportant :
- un identifiant d’entrée 320 précédente dans le registre,
- l’identifiant 335 unique représentatif de l’élément considéré,
- des données stockées 325 et
- un identifiant d’entrée 330 obtenu par hachage d’au moins une partie des données stockées 325.

Par exemple, dans le procédé 100, le hachage est réalisé à partir de données représentatives de caractéristiques et données clés (telles des métadonnées) et d’un numéro de série de l’étiquette. N’importe quelle fonction de hachage peut être utilisée par l’Homme du Métier pour obtenir l’identifiant d’entrée.

Dans des variantes, l’identifiant unique 335 peut faire partie des données stockées 325.

La capacité d’un utilisateur à ajouter une entrée dans le registre distribué peut dépendre de permissions accordées par contrat intelligent. Par exemple, un opérateur peut être autorisé à ajouter une entrée dans le registre distribué après qu’une requête d’action de maintenance a été envoyée par le serveur central. Un tel contrat intelligent peut ainsi comporter des permissions conditionnelles d’ajout d’une entrée dans le registre, ces conditions représentant un accord contractuel entre les parties prenantes pour l’administration du site.

De plus, chaque acteur est associé à une clé privée authentifiée lors de la tentative d’enregistrement d’une entrée dans le registre.

Ce serveur central peut également être configuré pour assurer les services « hors du registre distribué », c’est-à-dire notamment les interfaces de navigation permettant aux différentes parties prenantes de recevoir/émettre des informations. Ce serveur stocke aussi, par exemple, des données relatives au site et aux parties prenantes de la gestion de ce site. Alternativement, ces données sont stockées sur une base de données à fonctionnalités de registre distribué telle BigchainDB (Marque déposée) ou de type IPFS (pour « InterPlanetary File System », traduit par système de fichier interplanétaire).

L’IPFS est un système distribué de fichiers pair à pair qui ne dépend pas de serveurs centralisés. Son but est de connecter un ensemble d'équipements informatiques avec le même système de fichiers. D'une certaine manière IPFS est similaire au World Wide Web, à la différence qu'il peut être vu comme un essaim (« Swarm », en anglais) BitTorrent (Marque déposée) unique, qui échange des objets au sein d'un dépôt de type Git par exemple.

En d'autres termes, IPFS fournit un modèle de stockage par blocs adressable par contenu de haute capacité, utilisant des hyperliens pour l'accès. Ceci forme un graphe orienté acyclique de Merkle généralisé. IPFS combine une table de hachage, un échange de blocs encouragé et un espace de noms auto-certifié. IPFS n'a pas de point unique de défaillance et les nœuds n'ont pas besoin de se faire mutuellement confiance.

Lors de l’assemblage 107 d’une étiquette, c’est-à-dire de la création d’un identifiant unique d’élément ensuite stocké dans ladite étiquette, le serveur génère préférentiellement une entrée représentative de l’assemblage 107 de cette étiquette dans le registre distribué.

L’étape d’assemblage 107 comporte, a minima, l’étape d’enregistrement 110 de l’identifiant unique d’élément dans l’étiquette. Cette étape 110 d’enregistrement peut avoir plusieurs formes et dépend de la manière dont est enregistré l’identifiant d’élément généré au cours de l’étape 105 de génération.

Par exemple, l’étape 110 d’enregistrement peut consister en l’impression d’un code-barres ou d’un code QR ou d’un code alphanumérique représentatif de l’identifiant d’élément. Alternativement, l’étape 110 d’enregistrement peut consister en l’enregistrement, sur une mémoire informatique, d’une donnée représentative de cet identifiant d’élément.

L’étape d’assemblage 107 peut également comporter une étape (non représentée) de fabrication de l’étiquette. Cette fabrication dépend de la nature de l’étiquette. Par exemple, l’étiquette peut être un autocollant configuré pour recevoir une impression d’un code-barres ou d’un code QR ou d’un code alphanumérique représentatif de l’identifiant d’élément.

Dans des variantes, l’étiquette est une étiquette de radio-identification.

On note que les termes « étiquette de radio-identification » ou « radio-étiquette » désignent des étiquettes selon les technologies RFID (pour « Radio Frequency Identification », traduit par identification à radiofréquences) ou NFC (pour « Near Field Communication », traduit par « Communication en champ proche »), par exemple.

Cette radio-étiquette ou étiquette peut comporter ou non une mémoire réinscriptible.

Lorsque cette étiquette comporte une mémoire réinscriptible, cette mémoire comporte préférentiellement un identifiant d’entrée dans le registre distribué. Préférentiellement, cet identifiant d’entrée correspond à l’identifiant de la dernière entrée ajoutée au registre pour l’identifiant unique d’élément considéré. Ceci facilite l’ajout de nouvelles entrées dans le registre distribué. Il est ainsi possible, en connaissant l’identifiant unique d’élément stocké dans une étiquette de parcourir le registre distribué pour connaître la succession d’actions réalisées sur l’élément associé à l’identifiant unique.

Préférentiellement, une entrée est générée 105 en amont de l’assemblage 107 de l’étiquette et comporte, en guise de données pour générer un hachage utilisé en tant qu’identifiant de l’entrée, au moins une valeur de paramètre de fabrication et/ou un identifiant unique d’élément associé à l’étiquette. Un tel paramètre peut être, par exemple, une date de fabrication, au moins un identifiant de machine utilisée pour réaliser la fabrication, un identifiant de fournisseur, un identifiant de client, un identifiant de site pour lequel la radio-étiquette est fabriquée.

Lorsqu’un identifiant d’entrée est associé à une étiquette après fabrication, ladite étiquette étant munie d’une mémoire réinscriptible, l’étiquette est approchée d’un lecteur/inscripteur. Ce lecteur/inscripteur est configuré pour émettre une commande de mémorisation d’un identifiant d’entrée du registre distribué correspondant à l’identifiant unique d’élément associé à l’étiquette. À la réception de cette commande, l’étiquette enregistre cet identifiant d’entrée. Cette émission d’une commande de mémorisation constitue un exemple d’étape 110 d’enregistrement.

Ainsi, une fois l’initialisation réalisée, le serveur d’initialisation mémorise l’identifiant unique d’élément associé à un étiquette et l’associe à un site.

Un tel serveur d’initialisation 210 est représenté en figure 2. Dans des variantes, le serveur d’initialisation 210 et le serveur d’exécution d’un système de gestion de site sont distincts. Ce serveur d’initialisation 210 est associé à un lecteur/inscripteur 205 configuré pour émettre une commande de mémorisation d’un identifiant entré à une étiquette 215.

L’étiquette est ensuite positionnée pour permettre son accès par un opérateur préférentiellement muni d’un lecteur d’étiquette. Pour des raisons de simplicité de l’opération, l’étiquette peut être collée sur l’élément associé à ladite étiquette. Alternativement, l’étiquette peut être fixée, de manière amovible ou permanente, à proximité de l’élément en question.

Dans des variantes, l’étiquette est solidarisée à un élément lors de l’assemblage de cet élément, en amont de son positionnement sur le site.

Dans des modes de réalisation, le procédé 100 comporte, en aval de cette étape de positionnement d’une étiquette, pouvant être réalisée lors de l’étape d’assemblage de l’élément, une étape de validation du positionnement de ladite étiquette. Cette étape de validation est réalisée, par exemple, par la comparaison d’informations représentatives de l’élément (type d’élément, numéro de série, coordonnées de géolocalisation), éventuellement saisis par un opérateur ou lus par un dispositif de lecture de l’opérateur, et d’informations représentatives de l’élément enregistrées soit sur un serveur d’administration de site, soit sur le registre distribué et associés à une entrée associée à l’identifiant unique d’élément.

Un exemple d’étiquette 220 positionnée sur un élément 225 est illustré en figure 2. L’élément 225 est, par exemple, une chaudière à gaz.

Lorsqu’une action doit être réalisée sur l’équipement, comme par exemple une action de maintenance préventive ou une action de réparation d’un dégât, un opérateur se rend à proximité de la radio-étiquette muni d’un lecteur d’étiquette de radio-identification. Un exemple de lecteur 230 est illustré en figure 2. Un tel lecteur 230 est de tout type connu de l’homme du métier et adapté à la lecture d’une mémoire d’étiquette RFID ou NFC.

L’étape 115 de lecture est ainsi réalisée, par exemple, par le rapprochement du lecteur de la radio-étiquette de sorte à en lire l’identifiant.

L’étape 120 de réalisation d’une action dépend de la nature de l’action à réaliser. Une telle action peut être une action de maintenance préventive ou une action de réparation d’un dégât.

Une fois l’action réalisée, l’opérateur valide la réalisation de l’action sur un terminal communicant. On note que les termes « terminal communicant » désignent tout dispositif muni d’une interface homme-machine configurée pour permettre à minima la saisie d’une commande de validation et d’un moyen de communication, filaire ou sans-fil, vers un réseau de données tel internet. Un exemple de terminal communicant 235 est illustré en figure 2. Ce terminal communicant 235 comporte le lecteur 230. Ce terminal 235 est, par exemple, un téléphone intelligent ou une tablette numérique.

L’étape 125 de validation est ainsi réalisée, par exemple, par la mise en œuvre d’une interface homme-machine du terminal communicant.

Dans des modes de réalisation, l’étape 125 de validation comporte une étape de saisie d’informations, par l’opérateur, et une étape de contrôle des informations saisies. Au cours de cette étape de contrôle, les informations saisies sont comparées à des informations attendues, ces informations pouvant être un type de fichier par exemple. Dans un tel exemple, pour que la saisie d’information soit validée, l’opérateur doit prendre une photographie de l’élément et, en l’absence d’un fichier image ou d’une pièce-jointe associée à une saisie d’information, l’étape de validation 125 ne peut être complétée.

Dans des modes de réalisation, l’étiquette comporte une mémoire réinscriptible, le procédé objet de la présente invention comportant, de plus, en aval de l’étape 130 d’enregistrement d’une information représentative de la réalisation d’une action, une étape 135 de mémorisation, dans la mémoire réinscriptible de l’étiquette, d’un identifiant de l’entrée du registre distribué enregistrée au cours de ladite étape d’enregistrement.

Le déclenchement de l’étape 125 de validation entraîne une tentative d’enregistrement 130 sur le registre distribué d’une information représentative de la réalisation de l’action. Pour réaliser la validation, l’identifiant unique d’élément associé à l’étiquette doit être soit saisi en amont de la tentative de validation. Cette saisie peut correspondre à une saisie manuelle réalisée par un opérateur ou au cours de l’étape de lecture 115 décrite ci-dessus.

L’étape 125 de validation peut être réalisée par inscription dans le registre distribué depuis le terminal communicant ou via un serveur, relié au terminal, le serveur réalisant l’inscription.

Si l’étape d’enregistrement 130 est un succès, c’est-à-dire que l’inscription sur le registre distribué est validée par le mécanisme de consensus considéré, une nouvelle entrée est créée, cette nouvelle entrée comportant au moins une information représentative de l’action réalisée.

Dans des variantes, cette entrée comporte, en guise d’identifiant d’entrée précédente dans le registre, l’identifiant de la dernière entrée créée dans le registre, l’identifiant unique d’élément de l’étiquette tel que lu par le lecteur, ou saisi par l’opérateur, étant incorporé aux données de l’entrée participant à générer, par hachage, l’identifiant de ladite entrée.

Au cours de l’étape 135 de mémorisation, optionnelle, l’identifiant de la nouvelle entrée créée est préférentiellement enregistré dans une mémoire de l’étiquette. Cet enregistrement est réalisé, par exemple, par émission d’une commande de mémorisation provenant d’un lecteur ou du terminal communicant.

Parallèlement à cet enregistrement au niveau de l’étiquette, l’identifiant de l’entrée est préférentiellement enregistré au niveau d’un serveur central, ou serveur applicatif, en charge d’exécuter l’application liant les parties prenantes du site.

Ainsi, l’identifiant de l’entrée représentative de la dernière action réalisée sur l’élément change à chaque action réalisée et le registre distribué stocke une information de chaque action réalisée, ce qui permet une traçabilité renforcée de la succession d’actions réalisées.

Dans des modes de réalisations, le procédé 100 comporte, en amont de l’étape 115 de lecture, une étape 140 d’émission d’une alerte, comportant un identifiant unique d’élément enregistré dans une étiquette, ladite alerte étant émise en fonction d’un calendrier de réalisation d’action de l’élément prédéterminé associé à l’identifiant unique d’élément.

Cette étape 140 d’émission est réalisée, par exemple, par un serveur central, ou serveur applicatif, en charge d’exécuter l’application liant les parties prenantes du site. Un tel serveur central 240 est illustré en figure 2.

Le calendrier peut être défini, pour un identifiant unique d’élément, de sorte qu’une alerte soit émise périodiquement ou ponctuellement. Dans des variantes, au moins un identifiant d’élément est associé à un type d’élément, un calendrier pouvant être défini pour un type d’élément, ce qui entraîne par hérédité la création d’un calendrier propre à chaque identifiant d’élément du type d’élément déterminé. Par exemple, une maintenance de chaudière peut avoir lieu une fois par an. Ainsi, pour chaque identifiant de type « chaudière », un calendrier d’émission d’alerte est déterminé pour qu’à chaque anniversaire de la création de l’identifiant, une alerte de maintenance soit émise. Dans des variantes, le calendrier n’est exécuté qu’à partir d’une première action réalisée sur un élément correspondant à l’installation dudit élément.

Dans des variantes, chaque alerte est associée à un identifiant d’opérateur de sorte que chaque opérateur associé à l’alerte reçoive l’alerte. Dans des variantes, chaque alerte est associée à un identifiant de type d’opérateur, chaque opérateur d’un dit type (par exemple, les électriciens) recevant l’alerte. Dans des variantes, une date d’échéance est associée à l’alerte. Dans des variantes, une date de mise en œuvre de pénalités est associée à l’alerte.

Au moins une partie des paramètres de la réalisation de l’action peut faire l’objet d’un contrat intelligent enregistré sur le registre distribué.

Dans des variantes, l’alerte est associée à au moins deux identifiants d’opérateurs, chaque dit identifiant étant associé à une valeur de priorité. L’alerte est alors émise en premier à l’identifiant d’opérateur présentant la priorité la plus importante puis, après un délai limite déterminé, correspondant une durée d’acceptation de la réalisation de l’action, à l’identifiant d’opérateur suivant présentant la priorité la plus importante parmi les priorités restantes.

Dans des modes de réalisation, le procédé 100 comporte une étape de mesure 145 d’une durée écoulée entre l’étape 140 d’émission d’une alerte et au moins une des étapes parmi l’étape 115 de lecture et l’étape 125 de validation de la réalisation de l’action, ladite durée étant enregistrée au cours de l’étape 130 d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué.

L’étape de mesure 145 est réalisée, par exemple, par une horloge électronique pouvant être associé à un serveur central ou applicatif. Une telle horloge électronique 245 est représentée en figure 2.

La mesure d’une durée entre l’étape 140 d’émission d’une alerte et l’étape 115 de lecture permet de mesurer le délai d’intervention de l’opérateur tandis que la durée entre l’étape 140 de lecture et l’étape 125 de validation permet de mesurer le délai de réalisation total de l’action. Dans des variantes, une mesure de la durée entre l’étape 115 de lecture et l’étape 125 de validation est réalisée. Ces variantes permettent de mesurer le délai de réalisation de l’action une fois sur site.

Lorsque la durée mesurée dépasse une valeur limite déterminée, une pénalité peut être infligée à l’opérateur. Parmi les pénalités pouvant être infligées en cas de validation tardive d’une action, une réduction de la valeur de priorité ou une pénalité financière peut être réalisée. Ceci a pour effet de créer une mesure incitative à la performance des opérateurs désireux de jouir du contrat les liant à un site.

Inversement, lorsque la durée est inférieure à une valeur limite déterminée, un bonus peut être accordé à l’opérateur. Un tel bonus peut être, par exemple, une augmentation de la valeur de priorité de cet opérateur ou une compensation financière.

Dans des modes de réalisation, le procédé 100 comporte une étape 150 de saisie d’information en amont de l’étape 125 de validation, un identifiant représentatif de chaque information saisie étant enregistré au cours de l’étape 130 d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre. Par identifiant représentatif, on entend, par exemple, l’identifiant obtenu par hachage de tout ou partie des données saisies et stocké dans une entrée du registre distribué.

L’étape 150 de saisie est réalisée, par exemple, par la mise en œuvre d’une interface homme-machine de saisie d’information alphanumériques ou par la mise en œuvre d’un moyen de capture de signaux audiovisuels, tel une cybercaméra ou un microphone par exemple.

Il est entendu que ces dispositions permettent de programmer des tâches définies selon un processus standard. Chaque tâche a une fréquence ; par exemple, la vérification des détecteurs de fumée ou des actionneurs chaque mois. Lorsque les tâches programmées pour les actifs sont définies dans le registre, les contrats intelligents ouvrent automatiquement les tâches programmées pour le contractant assigné lorsqu'il est temps de les exécuter et les assignent à ce dernier - les horloges sont initialisées et l'heure à laquelle elles ont été ouvertes et l'heure à laquelle elles ont été fermées par le contractant sont toutes maintenues comme faisant partie de la chaîne de blocs avec les remarques du contractant et le résultat de la vérification.

De préférence, la gestion des utilisateurs est également maintenue à l'intérieur du registre distribué. Chaque utilisateur se voit attribuer un rôle en fonction de sa clé publique. Si une clé publique est attribuée à un contractant, seul un compte possédant cette clé publique peut effectuer une tâche de planification. Le contractant ayant accès à sa clé privée peut clôturer une tâche programmée avec un résultat/une remarque.

Lorsqu'une tâche de maintenance préventive révèle un défaut, un ordre de travail peut être lancé par un utilisateur d’un type donné, tel le propriétaire ou l’exploitant du projet/du bâtiment, avec un montant, une identification de l'ordre de travail, une clé publique de l'entrepreneur - cela déplace automatiquement la tâche dans la file d'attente de l'entrepreneur. L'entrepreneur confirme la transaction en clôturant l'événement et en ajoutant une remarque sur le travail effectué, le propriétaire vérifie et confirme le travail effectué - cela complète le processus et le montant sur le compte séquestre du canal de paiement est automatiquement transféré sur le compte de l'entrepreneur. Des pénalités sont automatiquement déduites si l'entrepreneur ne termine pas le travail dans les délais impartis (c'est-à-dire 5 % par jour du montant déposé, par exemple).

Claims

Procédé (100) de traçabilité d’actions réalisées sur un site, caractérisé en ce qu’il comporte :
- une étape (105) de génération d’une entrée dans un registre distribué, ladite entrée comportant un identifiant unique d’un élément matériel du site,
- une étape (107) d’assemblage d’une étiquette de stockage comportant une étape (110) d’enregistrement, dans l’étiquette de stockage, de l’identifiant unique généré,
puis, de manière itérative :
- une étape (115) de lecture, par un lecteur d’étiquette, d’un identifiant enregistré dans l’étiquette,
- une étape (120) de réalisation d’une action en relation avec l’élément associé à l’identifiant,
- une étape (125) de validation de la réalisation de l’action sur un terminal communicant et
- une étape (130) d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué en fonction de l’identifiant lu.
Procédé (100) selon la revendication 1, dans lequel l’étiquette comporte une mémoire réinscriptible, le procédé objet de la présente invention comportant, de plus, en aval de l’étape (130) d’enregistrement d’une information représentative de la réalisation d’une action, une étape (135) de mémorisation, dans la mémoire réinscriptible de l’étiquette, d’un identifiant de l’entrée du registre distribué enregistrée au cours de ladite étape d’enregistrement.
Procédé (100) selon l’une des revendications 1 ou 2, qui comporte, en amont de l’étape (115) de lecture, une étape (140) d’émission d’une alerte, comportant un identifiant enregistré dans une étiquette, ladite alerte étant émise en fonction d’un calendrier de réalisation d’action de l’élément prédéterminé associé à l’identifiant.
Procédé (100) selon la revendication 3, qui comporte une étape de mesure (145) d’une durée écoulée entre l’étape (140) d’émission d’une alerte et au moins une des étapes parmi l’étape (115) de lecture de l’identifiant enregistré dans l’étiquette et l’étape (125) de validation de la réalisation de l’action, ladite durée étant enregistrée au cours de l’étape (130) d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre distribué.
Procédé (100) selon l’une des revendications 1 à 4, qui comporte une étape (150) de saisie d’information en amont de l’étape (125) de validation, un identifiant représentatif de chaque information saisie étant enregistré au cours de l’étape (130) d’enregistrement d’une information représentative de la réalisation de l’action dans une entrée du registre.