Titre de l'invention : procédé mis en œuvre par ordinateur d’établissement sécurisé d’un document de transfert de responsabilité d’un bien

[0001] L’invention concerne un procédé mis en oeuvre par ordinateur pour l’établissement sécurisé d’un document de transfert de responsabilité d’un bien.

[0002] En particulier, l’invention se rapporte à l’établissement sécurisé d’une fiche d’état d’un bien de location lors de la prise et/ou de la remise du bien, notamment pour la location d’un véhicule automobile.

[0003] L’invention n’est toutefois pas seulement limitée au domaine de la location, elle s’applique aussi aux domaines connexes des assurances - constat avant souscription de la police et déclaration de sinistre-, dans le cadre de la gestion de flotte automobiles par les entreprises/administrations, en sortie d’usines par les constructeurs pour repérer les malfaçons et/ou défauts sur les véhicules neufs.

[0004] Le procédé selon l’invention peut en outre être utilisé dans des domaines généraux différents tels que la location immobilière.

[0005] Dans le domaine de la location de véhicules automobiles, et plus généralement dans le domaine de la location de biens, l’établissement d’une fiche d’état, aussi appelé rapport, état des lieux ou encore constat, est nécessaire tant lors de la prise du bien que lors de sa remise, afin d’attester de l’état du bien lors du transfert de responsabilités.

[0006] Ces états des lieux sont habituellement effectués par un constat contradictoire du locataire et du propriétaire, constatant sur un document physique, généralement une fiche papier, l’état d’usure et les dégâts présents sur le bien à louer ou sur le bien remis ; le document étant ensuite signé par les deux parties.

[0007] L’introduction des technologies numériques a permis l’apparition des constats numériques, pour lesquels le document papier est remplacé par un formulaire électronique, rempli par l’une des deux parties lors de l’état des lieux contradictoire. [0008] Toutefois les solutions connues d’état des lieux numériques n’assurent pas une sécurité suffisante sur le document obtenu.

[0009] En effet, les informations stockées sont généralement falsifiables par la suite, de manière relativement indétectable, ce qui crée un risque juridique dans l’établissement de tels constats.

[0010] C’est pourquoi il existe le besoin d’un procédé sécurisé et fiable pour l’établissement d’un document de transfert de responsabilité d’un bien, tel qu’un bien de location, notamment un véhicule automobile.

[0011] A cet effet on propose un procédé mis en oeuvre par ordinateur d’établissement d’un document de transfert de responsabilité d’un bien comprenant :

[0012] - L’acquisition d’une pluralité de données saisies par un utilisateur, chaque donnée acquise correspondant à une information dudit document ; lesdites données étant saisies les unes après les autres par ledit utilisateur ;

[0013] - La création d’un journal de saisie formant chaînage chronologique de la saisie des données par ledit utilisateur ;

[0014] - Une étape de calcul d’une clé de sécurité finale fonction desdites données saisies par ledit utilisateur ;

[0015] - Une étape de stockage desdites données acquises, dudit journal de saisie et de ladite clé de sécurité ; et

[0016] - Une étape d’édition numérique d’un document de transfert de responsabilité en fonction desdites données acquises.

[0017] Ainsi, on peut éditer un document de transfert de responsabilité, aussi appelé rapport, de manière sécurisée, en associant ce document à des données de sécurité aptes à en authentifier le contenu.

[0018] Avantageusement et de manière non limitative, le procédé comprend après l’étape de saisie, une étape de constitution d’un premier journal de clé de sécurité, de sorte que pour chaque entrée du journal de saisie, le premier journal de clé de sécurité comprend une clé calculée en fonction de ladite entrée. Ainsi, on peut obtenir un journal de données et un journal de clés de sécurité associées, de sorte que chaque clé de sécurité permet la vérification de l’authenticité de chaque donnée associée du journal de donnée.

[0019] Avantageusement et de manière non limitative, le procédé comprend en outre une étape de calcul de clé de sécurité incrémental dans lequel on calcule une première clé lors de l’acquisition d’une première donnée saisie par ledit utilisateur, et pour chaque acquisition d’une donnée suivante saisie par l’utilisateur, on calcule une clé de sécurité suivante en fonction de ladite donnée saisie et de la clé de sécurité précédente. Ainsi, on peut obtenir une clé de sécurité finale de manière incrémentale, autrement dit obtenue en prenant en compte l’ensemble des données acquises.

[0020] Avantageusement et de manière non limitative, lesdites clés de sécurité calculées lors de l’étape de calcul de clé de sécurité incrémental sont stockées de manière chaînées, de sorte à former un journal de clés de sécurité incrémental. Ainsi, on peut tracer l’ensemble des clés calculées de façon incrémentale ce qui améliore la capacité à détecter une divergence potentielle entre les données stockées et un rapport préalablement établi.

[0021] Avantageusement et de manière non limitative, au moins ladite clé de sécurité finale est stockée de manière décentralisée en particulier sur une Blockchain. Ainsi, on peut améliorer la sécurité du stockage de la clé de sécurité.

[0022] Avantageusement et de manière non limitative, l’étape d’acquisition comprend l’acquisition d’au moins un contenu multimédia, tel qu’une image numérique ou une vidéo numérique, associés chacun à une empreinte distincte calculée par un calcul d’empreinte distinct des autres données acquises et/ou stockée dans un journal d’empreintes de contenu multimédia distinct des autres données acquises. Ainsi, on peut authentifier et sécuriser l’acquisition de contenu multimédia de manière relativement simple et rapide lors de la création d’un rapport sécurisé.

[0023] L’invention concerne aussi un procédé mis en oeuvre par ordinateur de vérification de l’authenticité d’un document établi par ledit procédé décrit précédemment, comprenant :

[0024] L’acquisition d’un ensemble de données stockées, d’une clé de sécurité associée et d’un journal de saisie associée ; [0025] Le calcul d’une seconde clé de sécurité en fonction dudit journal de saisie associé et desdites données stockées ;

[0026] La comparaison entre la clé de sécurité associée et la seconde clé de sécurité, si les deux clés sont identiques ledit document étant authentique.

[0027] Ainsi on peut déterminer de manière certaine la validité d’un rapport créé avec le procédé d’établissement décrit précédemment.

[0028] En ce sens l’invention résout le problème obtenu par la combinaison avantageuse des deux procédés revendiqués, d’un part par la création d’un rapport associé à des données d’authentification et une clé de sécurité et d’autre part la vérification de ce rapport avec les données stockées.

[0029] L’invention concerne aussi un dispositif de traitement de données, tel qu’un serveur, un ordinateur personnel, un téléphone, une tablette, ou tout autre dispositif, comprenant des moyens pour mettre en oeuvre les étapes du procédé d’établissement tel que décrit précédemment et/ou les étapes du procédé de vérification décrit précédemment.

[0030] L’invention concerne aussi un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en oeuvre les étapes du procédé d’établissement décrit précédemment et/ou les étapes du procédé de vérification tel que décrit précédemment.

[0031] L’invention concerne aussi un support de données lisible par ordinateur, tel qu’un disque dur, un CD-Rom, un DVD-Rom, une mémoire flash, une mémoire morte, et tout autre support connu de l’homme du métier, sur lequel est enregistré l’un ou les programmes d'ordinateur décrit précédemment.

[0032] D’autres particularités et avantages de l’invention ressortiront à la lecture de la description faite ci-après d’un mode de réalisation particulier de l’invention, donné à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels :

[0033] [Fig. 1] est un organigramme d’un procédé pour l’établissement d’un document de transfert de responsabilité selon un mode de réalisation de l’invention ; [0034] [Fig. 2] est un organigramme de détail d’une étape de création de clé de sécurité selon le mode de réalisation de la figure 1 ; et

[0035] [Fig. 3] est un organigramme d’un procédé de vérification selon un mode de réalisation de l’invention.

[0036] Selon un premier mode de réalisation de l’invention, un dispositif tel qu’un ordinateur, un serveur fournissant une interface de saisie, ou tout autre appareil informatique mobile tel qu’un smartphone ou une tablette numérique, met en oeuvre un procédé pour l’établissement sécurisé d’un document de transfert de responsabilité d’un bien.

[0037] On entend dans le cadre de cette invention d’un document de transfert de responsabilité d’un bien, tout document de d’état des lieux, d’état d’un bien mobilier ou immobilier, ou tout autre constat, contradictoire ou non, pour établir à date certaine l’état d’un bien.

[0038] Un tel document, aussi appelé indifféremment dans la suite de la description rapport, état-des-lieux ou constat, comprend ainsi une succession de données textuelles et visuelles, telles que des images et des vidéos. Tout autre type de données numériques peuvent être inclus tel que des documents numériques, des sons numérisés, en fonction du domaine ou du bien auquel le constat est appliqué.

[0039] L’invention peut donc s’appliquer à tout bien, mobilier ou immobilier, et à toute activité associée telle que la location immobilière, la location automobile ou de tout autre bien, le convoyage, la mise-à-disposition, le gardiennage, la logistique, les assurances, etc.

[0040] Le procédé 1 , en référence aux figures 1 et 2, comprend une succession d’étapes associées à une interface utilisateur.

[0041] Le procédé mis en oeuvre par ordinateur est aussi appelé dans la suite de la description application ou programme informatique.

[0042] Ainsi, pour créer un nouveau constat, le procédé requiert dans une première étape une connexion sécurisée de l’utilisateur.

[0043] Dans ce mode de réalisation, la connexion s’effectue par une authentification combinant un identifiant individuel, telle qu’une adresse email, un numéro de téléphone, une immatriculation et un mot de passe ou un code à usage unique composé de plusieurs caractères alphanumériques, communiqué par message.

[0044] Pour ceux des utilisateurs possédant un compte individuel, le compte est stocké dans une base de données et est associé en outre à un numéro unique d’identification. Certains utilisateurs sont rattachés à un compte de personne morale (entreprise, administration...) et ne possèdent donc pas de compte individuel.

[0045] Lorsqu’un utilisateur se connecte pour réaliser un constat, il s’authentifie, choisit le formulaire correspondant au cœur de métier recherché (tel que la location, l’assurance, le convoyage de biens, etc.) ou alloué à la personne morale à laquelle il est rattaché, et/ou au type de bien à inspecter (automobile, bateau, appartement, etc.).

[0046] En fonction de ces données, le procédé propose à l’utilisateur un formulaire de saisie des informations.

[0047] Ce formulaire, aussi appelé modèles ou template, est un document comprenant des champs prédéfinis à remplir par l’utilisateur.

[0048] Bien que la nature des données collectées diffère en fonction du type d’inspection et des besoins clients, les formulaires sont généralement divisés en sections contenant des champs à remplir, se rapportant respectivement :

- Aux personnes concernées/signataires. Il s’agit de renseigner ici les champs tels que les nom et prénom, société de rattachement, fonction, numéro de téléphone, email, etc.

- Au bien objet de l’inspection. Il s’agit là de fournir les références du bien : marque/modèle, immatriculation, numéro unique d’identification (VIN), type et adresse pour les biens immobiliers ;

- Aux photos guidées (aussi appelées photo-scan) du bien destinées à apporter une preuve visuelle de l’état du bien ;

- Aux photos libres destinées à apporter un complément visuel d’information dans la mesure où l’utilisateur l’estime nécessaire, sur l’état du bien ;

- A la signature du rapport par la/les personne(s) initiatrice(s) et/ou concernée(s). [0049] Aussi lorsque l’utilisateur complète le formulaire, il saisit des données acquises par le procédé, chaque donnée étant associée à un champ prédéfini du formulaire.

[0050] L’objectif de l’invention est de permettre d’attester que les informations contenues dans le constat final correspondent effectivement aux données saisies par l’initiateur du rapport, et aux photos du bien prises à l’aide du procédé mis en oeuvre par ordinateur, et qu’elles n’ont pas été modifiées par une personne non autorisée ni pendant ni après la réalisation de l’état des lieux.

[0051] Il s’agit donc en d’autres termes, de garantir l’intégrité des données du rapport tant pendant la réalisation de l’état des lieux et qu’après la génération du rapport.

[0052] Plusieurs moyens de sécurité ont été mis en place, dont la combinaison résulte en un procédé de sécurisation de données/informations dans le sens de la préservation de leur intégrité.

[0053] A cet effet plusieurs éléments de sécurité ont été mis en oeuvre.

[0054] Lorsqu’un utilisateur se connecte à l’Application pour créer un rapport, il accomplit un certain nombre d’actions tel que choisir un modèle de formulaire, en remplir les champs, prendre des photos, signer le rapport.

[0055] Chacune de ses actions est acquise 11 par le procédé 1 sous forme de données d’acquisition, enregistrées par le procédé.

[0056] Aussi le procédé 1 comprend une étape d’acquisition 11 d’une pluralité de données saisies par un utilisateur, chaque donnée acquise correspondant à une information dudit document.

[0057] Ces données étant saisies les unes après les autres par l’utilisateur, l’ensemble des acquisitions successives est appelé Journal de saisie.

[0058] Le procédé 1 met à cet effet en oeuvre une étape de création 12 d’un journal de saisie formant chaînage chronologique de la saisie des données par ledit utilisateur.

[0059] Le journal retrace ainsi de manière chronologique, toutes les actions ayant abouti à la génération du rapport final et permet de retracer l’historique du rapport. [0060] Le journal, et les autres journaux selon l’invention, peut être stocké sous forme de fichier, dans une base de données ou sous tout autre format numérique adapté.

[0061] L’étape de création 12 du journal peut être effectuée en parallèle de l’étape d’acquisition 11 , en ce sens que chaque fois qu’une donnée est saisie par l’utilisateur et acquise 11 par le procédé, elle est ajoutée 12 au journal en temps réel.

[0062] En particulier, dans ce mode de réalisation de l’invention, après chaque ajout d’une donnée au journal lors de l’étape de création 12 du journal, le journal est chiffré et enregistré localement sur le dispositif mettant en oeuvre le procédé.

[0063] Le chiffrement du journal peut être réalisé par tout procédé de chiffrement connu adapté pour protéger un journal de données et pour être sauvegardé dans un fichier stocké localement, par exemple sur un organe de stockage de mémoire du dispositif, tel qu’un disque dur ou une mémoire flash.

[0064] Tout algorithme de chiffrement peuvent être mis en oeuvre, tel que Advanced Encryption Standard (AES), Data Encryption Standard (DES) ou encore l’algorithme de Rivest-Shamir-Adleman (RSA), dès lors que le procédé est adapté pour chiffrer le journal régulièrement avant de le stocker localement.

[0065] Le stockage du fichier de journal chiffré est effectué de manière temporaire en local sur le dispositif mettant en oeuvre le procédé, tel qu’un dispositif mobile, smartphone ou tablette, de sorte à pouvoir fonctionner même en l’absence de réseau de communication distant tel qu’un réseau Wifi ou GSM.

[0066] Toutefois, le stockage local est seulement temporaire, jusqu’au retour d’un réseau de communication permettant la transmission du fichier de journal chiffré jusqu’à un serveur distant sécurisé.

[0067] Le stockage permanent des fichiers de journaux est réalisé sur un serveur distant et les fichiers locaux sont supprimés après transfert au serveur distant.

[0068] Ainsi, le journal est créé, chiffré et stocké, en temps réel à chaque saisie, ce qui permet d’assurer une sécurité élevée et un suivi optimal des actes de l’utilisateur, même en cas de fermeture intempestive du logiciel, tout en garantissant que le fichier de journal ne soit pas modifié de manière frauduleuse. [0069] En plus des données saisies par l’utilisateur de manière active, telles que les actions de connexion, remplissage des champs, prise de photos, import de contacts, acceptation de conditions contractuelles, d’autres événements peuvent être acquis dans le journal. On parle alors d’événements automatiquement captés par le système, de manière régulière ou ponctuelle, telles que l’identification de l’utilisateur ou l’identification et la localisation géographique du dispositif de création du constat.

[0070] Tous ces éléments constitutifs du constat final, saisies et acquisitions automatiques, forment des éléments appelés traces de constitution du rapport, et plus simplement traces.

[0071] Chaque trace est ainsi un élément ajouté au journal, l’ensemble des traces formant le journal final de création du rapport.

[0072] Ainsi, en rejouant l’ensemble du journal final de la première trace à la dernière trace, on peut obtenir de nouveau le rapport tel que créé.

[0073] Toutefois l’un des objectifs de l’invention est justement de pouvoir attester que le journal n’a pas été modifié a posteriori, qu’il s’agisse d’une modification volontaire, par exemple malveillante, ou d’une donnée corrompue.

[0074] Ainsi à titre d’exemple pour un constat automobile, le procédé peut journaliser les traces suivantes :

[0075] Une date et heure de réalisation de la trace ;

[0076] L’identification de l’utilisateur à l’origine de l’événement tracé ;

[0077] L’identification du type d’événement ;

[0078] La localisation géographique de l’événement (localisation géographique de l’appareil utilisé pour réaliser l’état des lieux) ;

[0079] Un identifiant unique de preuve.

[0080] Dans le cas d’un état des lieux de véhicule par exemple, les champs ci-après peuvent être répertoriés en tant que traces.

[0081] - Identification du système d’exploitation intégré dans le dispositif informatique utilisé pour réaliser le constat (IOS, Android, etc.)

[0082] - Nom et prénom de l’utilisateur [0083] - numéro de référence servant à identifier l’Utilisateur ;

[0084] - identifiant public, tel que l’adresse électronique ;

[0085] - localisation géographique de l’appareil utilisé pour la réalisation de l’état des lieux ; [0086] - paramètres géographiques relevés par le système correspondant à l’altitude

[0087] - paramètres géographiques relevés par le système correspondant à la latitude ;

[0088] - paramètres géographiques relevés par le système correspondant à la longitude ; [0089] - horodatage des saisies ou horodatage régulier [0090] - Position dans le formulaire en cours d’édition

[0091] - Section du modèle de formulaire, si le modèle de formulaire est divisé en sous-parties distinctes

[0092] - numéro d’immatriculation du véhicule ; [0093] - ancienne valeur dans le cadre du remplacement ou de la correction d’une saisie précédente erronée ;

[0094] - photo de la face avant du véhicule ;

[0095] - photo du côté latéral gauche avant du véhicule ;

[0096] - photo du côté latéral droit avant du véhicule ; [0097] - photo du côté latéral gauche arrière du véhicule ;

[0098] - photo du côté latéral droit arrière du véhicule ;

[0099] - photo de la face arrière du véhicule ;

[0100] - photos librement prises par l’utilisateur ;

[0101] En outre parmi les événements automatiquement acquis, les traces suivantes peuvent sont journalisées :

[0102] - initialisation d’un rapport à partir d’un modèle ;

[0103] - réouverture d’un rapport en attente ; [0104] - récupération d’un rapport et/ou d’un journal après un crash (bug ou autre incident ayant interrompu l’état des lieux en cours) ;

[0105] - démarrage d’un import de profil ;

[0106] - fin d’un import de profil ;

[0107] - démarrage d’un import de rapport à partir du répertoire ;

[0108] - fin de l’import du rapport à partir du répertoire ;

[0109] - finalisation d’une étape et sollicitation par l’utilisateur du passage à l’étape suivante de constitution du rapport ;

[0110] - l’utilisateur met un terme prématuré à l’établissement du rapport avec sauvegarde d’état du rapport, par exemple en cliquant sur « quitter et sauvegarder » dans une interface utilisateur ;

[0111] - L’utilisateur accepte des conditions contractuelles, par exemple en cochant une case adéquate.

[0112] De manière plus générale, le procédé journalise aussi le chargement de toutes données obtenues de manière dynamique, qu’il s’agisse de données internes chargées après le lancement du procédé ou de données externes acquise par exemple via un mécanisme d’interface de programmation (plus connu sous l’acronyme anglophone d’API).

[0113] De telles données chargées dynamiquement peuvent par exemple comprendre des données relatives à un parc comprenant l’ensemble des biens, dans cet exemple de réalisation des véhicules, enregistrés dans la base de données et étant associés à l’utilisateur, soit parce qu’il a eu à effectuer des constats portant sur ces biens, soit parce qu’il les ajoutés à travers une fonctionnalité dédiée du logiciel associé au procédé selon l’invention.

[0114] L’import de parc renvoi donc dans ce cas à la sélection automatique d’un bien déjà enregistré.

[0115] Par un tel import, lorsque l’utilisateur sélectionne le bien, toutes les informations y afférentes s’affichent automatiquement et remplissent les champs du formulaire prévus à cet effet (ex: marque, VIN, immatriculation...). Cette action de remplissage automatique étant journalisée elle aussi par le procédé. [0116] Afin de constituer une preuve cryptographique de l’authenticité du rapport, le procédé met ensuite en oeuvre une étape de calcul (13) d’une clé de sécurité finale fonction des données saisies par l’utilisateur et des données acquises automatiquement par le procédé.

[0117] Pour chaque trace enregistrée dans le journal, une empreinte unique est calculée 131 à partir d’une fonction de hachage, de l’anglais to hash ; autrement dit, on procède au calcul d’une empreinte de cette donnée.

[0118] Une fonction de hachage est une fonction calculant une empreinte, encore appelée signature, condensât, ou haché, unique à partir de la ou des données fournies.

[0119] La fonction de hachage, parfois appelée fonction de condensation, permet d'obtenir un condensé d'un texte, c'est-à-dire une suite de caractères assez courte représentant le texte qu'il condense.

[0120] La fonction de hachage est telle qu'elle associe une et une seule empreinte à un texte en clair. Par conséquent, la moindre modification du document entraîne la modification de son empreinte.

[0121] D'autre part, il s'agit d'une fonction à sens unique, afin qu'il soit impossible de retrouver le message original à partir du condensé. S'il existe un moyen de retrouver le message en clair à partir du condensât, la fonction de hachage est dite « à brèche secrète ».

[0122] La longueur de l’empreinte doit être toujours la même, quelle que soit la longueur des données en entrée, bien que l’invention pourrait être adaptée pour fonctionner avec des longueurs de hash variables.

[0123] Il n’est pas possible de trouver les données originales à partir des empreintes : Les fonctions de hachage ne fonctionnent que dans un seul sens.

[0124] Dans ce mode de réalisation de l’invention, la fonction de hachage est une fonction SHA-256. Toutefois l’invention n’est pas limitée à une unique fonction de hachage, dont de nombreuses alternatives sont connues de l’homme du métier.

[0125] La transformation 131 d’une trace par la fonction de hachage donne une empreinte ou hash, appelée Blockhash. Autrement dit l’empreinte d’une trace dans le journal est appelée le Blockhash. [0126] A partir du hash de chaque trace, on crée un journal 133, 133’ de clés de sécurité.

[0127] Plus précisément dans ce mode de réalisation de l'invention, on crée deux journaux 133, 133’ d’une part un journal 133’ formant chaînage des Blockhash, et d’autre part un journal 133 de hash incrémental.

[0128] En effet, chaque empreinte, qui se présente dans ce mode de réalisation sous la forme d’une chaîne de 64 caractères, est associée 132, par calcul avec la fonction de hachage, à l’empreinte de la trace suivante dans le journal, créant un nouveau hash, et ainsi de suite, jusqu’à la dernière trace. On obtient en d’autres mots une empreinte calculée 132 de manière incrémentale avec les empreintes précédentes successivement calculées, appelée current hash, ou aussi empreinte incrémentale.

[0129] Ainsi, le journal de hash incrémental 133 comprend une succession d’empreintes, formée chacune de la combinaison d’une trace associée avec l’empreinte précédente du journal 133, autrement dit avec le hash incrémental précédent.

[0130] Toutefois bien que la création des deux journaux de clés 133, 133’ soit préférée, l’invention peut aussi être mise en oeuvre avec seulement la création de l’un des deux journaux 133, 133’.

[0131] Dans le cas de photos, l’empreinte de chaque photo du rapport d’état des lieux est également calculée à l’aide d’une fonction de hachage ici SHA-1 , et se présente sous la forme d’une série de 40 caractères.

[0132] Les preuves des photos seules peuvent ainsi selon une mise en oeuvre de l’invention être séparées des autres éléments tracés.

[0133] Par ailleurs les photos peuvent aussi être stockées dans un journal distinct.

[0134] Toutefois des métadonnées de la photo peuvent être ajoutées dans le journal principal afin de renforcer la capacité d’authentification des données du rapport.

[0135] La dernière empreinte incrémentale calculée, soit le dernier hash incrémental calculé, qui correspond à l’empreinte de la dernière trace acquise avant la fin d’édition du rapport calculée avec le hash incrémental précédent, correspond à la clé de sécurité finale. [0136] L’empreinte finale du journal, aussi appelée clé de sécurité finale, est alors enregistrée 134 dans une Blockchain, dans ce mode de réalisation dans la Blockchain publique Bitcoin.

[0137] Ce processus permet d’obtenir une preuve irréfutable de l’existence des données contenues dans le journal et par ricochet, dans le rapport d’état des lieux généré.

[0138] Puis le procédé procède à une étape d’édition numérique 15 et/ou d’impression physique du rapport final.

[0139] Dans ce mode de réalisation de l’invention le rapport est édité dans un format de fichier encapsulé, ici du PDF, mais tout autre mode d’édition du rapport peut être mis en oeuvre par l’homme du métier.

[0140] En particulier, le document édité est signé, via un cachet électronique apposé par le procédé 1 , de sorte à attester de la création de ce fichier par ce procédé 1 , par exemple avec un cachet basé sur un certificat numérique délivré par une autorité de certification agréée.

[0141] L’invention concerne aussi un procédé de vérification 3 de l’authenticité d’un document établi par ledit procédé de création 1 précédent.

[0142] Le procédé 3, en référence à la figure 3, comprend une étape d’acquisition 31 des données stockées, d’une clé de sécurité associée et d’un journal de saisie, associés au rapport à vérifier.

[0143] Les éléments acquis sont ainsi acquis par le procédé sur une plateforme, par exemple un serveur distant et privé.

[0144] A partir des données acquises 31 , on calcule 32 d’une seconde clé de sécurité, dite clé de vérification, avec le même procédé de hachage que pour la création de rapport, à partir des données du journal de saisie associé et desdites données stockées.

[0145] Une fois la clé de de vérification calculée, selon le même procédé de calcul que pour le procédé 1 de création, on la compare 33 à la clé de sécurité finale.

[0146] La clé de sécurité finale ayant put être acquise lors de l’étape d’acquisition 31 ou lors d’une autre d’étape d’acquisition, par exemple en l’acquérant sur une Blockchain, telle que la Blockchain publique de Bitcoin. [0147] Si on constate lors de la comparaison 33 entre la clé de sécurité associée et la seconde clé de sécurité, que les deux clés sont identiques alors le document est authentique 34.

[0148] Par contre si les deux clés sont différentes, alors il est établi que le journal n’est pas conforme 35 au rapport associé.

[0149] Ainsi, les deux procédés 1 et 3 permettent de sécuriser la constitution et la vérification de rapports.

[0150] En particulier, le scellement des traces dans la Blockchain donne lieu à la génération d’un reçu d’ancrage ou reçu de preuve, qui est un fichier contenant l’ensemble des informations nécessaires pour vérifier l’existence des données (traces) contenues dans un journal, et leur horodatage. Le format de preuve utilisé dans ce mode de réalisation de l’invention est Chainpoint 1.0.

[0151 ] Un tel fichier atteste ainsi de l’enregistrement dans la Blockchain de la clé de sécurité finale ; l’enregistrement de la clé dans la Blockchain ayant pour objectif d’en garantir son intégrité.

[0152] Le reçu de preuve peut ainsi être communiqué en cas de contentieux ou de précontentieux, sur demande de toute personne intéressée par la vérification des données d’un journal. Le destinataire peut ainsi effectuer la vérification en deux temps :

[0153] Il pourra tout d’abord vérifier la réalité de l’ancrage de l’empreinte des données dans la Blockchain. Pour ce faire il utilisera le reçu de preuve et effectuera une recherche sur un site internet dédié ;

[0154] Dans un second temps, il recalculera l’empreinte des données à l’aide du procédé selon l’invention et comparera l’empreinte obtenue avec l’empreinte scellée dans la Blockchain.