FR 3153908 A1 20250411 FR 2310686 A 20231005 L’invention concerne un procédé qui prévoit : d’associer à un fichier (2) un code (18) et une adresse (15) d'accès à un coffre-fort (14) sur une chaîne de blocs ; calculer et enregistrer une première empreinte (19) dudit fichier dans le coffre-fort (14), en l'associant au code (18), enregistrer un statut d'autorisation de téléchargement défini par ledit créateur, en l’associant au code (18) ; lors du téléversement dudit fichier sur un serveur (16), de : calculer une deuxième empreinte ; lire le code (18) et l'adresse (15) associés audit fichier ; comparer la deuxième empreinte à la première empreinte (19) ; enregistrer ledit fichier téléversé sur le serveur (16) en cas de succès ; lorsqu'un utilisateur requiert le téléchargement du fichier (2), de : vérifier dans le coffre-fort (14) son statut d'autorisation de téléchargement ; et le cas échéant, procéder audit téléchargement selon des modalités de sécurité associées audit statut. Figure 1 Procédé d’enregistrement de fichiers informatiques sur un serveur lié à une chaîne de blocs L’invention concerne un procédé pour permettre à un créateur d’enregistrer un fichier informatique sur un serveur lié à une chaîne de blocs, afin d’en assurer l’accès et la sécurité, ainsi qu’une architecture comprenant des moyens pour mettre en œuvre un tel procédé. Elle s’applique en particulier à l’enregistrement de fichiers informatiques associés à des jetons non fongibles (NFT, pour l’anglais (« Non-Fungible Token »), qui correspondent à des représentations numériques de biens sur une chaîne de blocs (pour l’anglais « blockchain »), assimilables à un titre de propriété desdits biens. Ces biens peuvent être des objets physiques, tels que par exemple des œuvres d’art ou des biens immobiliers, des éléments numériques, tels que par exemple des images ou des photographies. Une telle représentation permet au propriétaire d’un tel bien de l’échanger ou de le vendre à un autre utilisateur présent sur la chaîne de blocs de manière sécurisée, en effectuant la transmission de cette représentation numérique peut en parallèle de celle dudit bien, notamment contre une somme en monnaie scripturale ou en cryptomonnaie. En effet, la duplication d’un jeton non-fongible étant impossible, cette procédure permet d’annuler le risque de contrefaçon du titre de propriété. Pour pouvoir effectuer de tels échanges, les créateurs de tels fichiers informatiques, ainsi que les utilisateurs souhaitant les acquérir, peuvent passer par des structures décentralisées, telles que par exemple des protocoles de pair à pair comme le Système de Fichier Interplanétaire (IFPS, pour l’anglais « InterPlanetary File System »), ou encore des plateformes de stockage et de distribution comme Swarm®. Ces solutions ne donnent pas entière satisfaction, en ce que les fichiers informatiques qui y sont enregistrés sont lisibles et téléchargeables par n’importe quel utilisateur de la chaîne de blocs, ce qui n’est pas compatible avec les cadres légaux régissant les services sécurisés de transactions électroniques, notamment les législations relatives au droit des affaires et/ou au respect de la vie privée. En particulier, ces solutions ne permettent pas de limiter l’accès à un fichier informatique à des utilisateurs autorisés, notamment le(s) créateur(s) dudit fichier informatique, les propriétaires désignés dudit fichier informatique, ou encore de potentiels futurs acheteurs dudit fichier informatique. L’invention vise à perfectionner l’art antérieur en proposant un procédé pour permettre à un créateur de conserver ses fichiers informatiques sur un serveur lié à une chaîne de blocs de manière sécurisée, notamment en permettant audit créateur de limiter l’accès au(x)dit(s) fichier(s) à des utilisateurs donnés, avantageusement suivant plusieurs niveaux de sécurité. A cet effet, selon un premier aspect, l’invention propose un procédé pour permettre à un créateur d’enregistrer un fichier informatique sur un serveur lié à une chaîne de blocs, ledit procédé prévoyant de : associer audit fichier un code d'indexation, ainsi qu'une adresse numérique d'accès à un coffre-fort numérique sur la chaîne de blocs ; calculer une première empreinte de hachage dudit fichier informatique ; enregistrer ladite première empreinte de hachage dans le coffre-fort numérique, en l'associant au code d'indexation ; enregistrer dans le coffre-fort numérique un statut d’autorisation défini par le créateur pour un éventuel téléchargement ultérieur dudit fichier informatique, en l’associant au code d’indexation ; ledit procédé prévoyant, lors du téléversement dudit fichier informatique par ledit créateur sur un serveur dédié comprenant un accès en lecture sur la chaîne de blocs, de : calculer une deuxième empreinte de hachage à partir dudit fichier téléversé ; lire le code d'indexation et l'adresse numérique associés audit fichier téléversé ; comparer la deuxième empreinte de hachage calculée à partir dudit fichier téléversé à la première empreinte de hachage préalablement enregistrée dans le coffre-fort numérique et associée au code d'indexation lu avec ledit fichier téléversé ; enregistrer ledit fichier téléversé sur le serveur en cas de succès de ladite comparaison ; ledit procédé prévoyant en outre, lorsqu'un utilisateur de la chaîne de blocs requiert le téléchargement du fichier informatique auprès du serveur, de : vérifier dans le coffre-fort numérique le statut d'autorisation de téléchargement défini pour ledit fichier informatique et associé au code d’indexation ; et le cas échéant, procéder audit téléchargement selon des modalités de sécurité associées audit statut. Selon un second aspect, l’invention propose une architecture pour permettre à un créateur d’enregistrer un fichier informatique sur un serveur lié à une chaîne de blocs, ladite architecture comprenant : un terminal lié au créateur et comprenant : des moyens pour associer audit fichier un code d'indexation, ainsi qu'une adresse numérique d'accès à un coffre-fort numérique sur la chaîne de blocs ; des moyens pour calculer une première empreinte de hachage dudit fichier informatique ; des moyens pour enregistrer ladite première empreinte de hachage dans le coffre-fort numérique, en l'associant au code d'indexation ; des moyens pour permettre au créateur de définir et d’enregistrer dans le coffre-fort numérique un statut d’autorisation pour un éventuel téléchargement ultérieur dudit fichier informatique, en l’associant au code d’indexation ; un serveur pour le téléversement et le téléchargement de fichiers informatiques, ledit serveur comprenant un accès en lecture sur la chaîne de blocs ; ledit terminal du créateur comprenant des moyens pour permettre audit créateur de téléverser et d’enregistrer le fichier informatique sur le serveur, ledit serveur comprenant des moyens pour, lors du téléversement dudit fichier : calculer une deuxième empreinte de hachage à partir dudit fichier téléversé ; lire le code d'indexation et l'adresse numérique associés audit fichier téléversé ; comparer la deuxième empreinte de hachage calculée à partir dudit fichier téléversé à la première empreinte de hachage préalablement enregistrée dans le coffre-fort numérique et associée au code d'indexation lu avec ledit fichier téléversé ; enregistrer ledit fichier téléversé sur ledit serveur en cas de succès de ladite comparaison ; ladite architecture comprenant en outre un terminal pour permettre à un utilisateur de requérir le téléchargement du fichier informatique auprès dudit serveur, ledit serveur comprenant des moyens pour, le cas échéant : vérifier dans le coffre-fort numérique le statut d'autorisation de téléchargement défini pour ledit fichier informatique et associé au code d’indexation ; et le cas échéant, procéder audit téléchargement selon des modalités de sécurité associées audit statut. D’autres particularités et avantages de l’invention apparaîtront dans la description qui suit, faite en référence aux figures annexées, dans lesquelles : FIG. 1 représente schématiquement les étapes d’enregistrement (ou téléversement) d’un fichier informatique sur un serveur lié à une chaîne de blocs, selon un mode de réalisation de l’invention ; FIG. 2 représente schématiquement, avec l’architecture de la FIG. 1 , les étapes de téléchargement d’un fichier informatique préalablement enregistré sur un serveur lié à la chaîne de blocs par un utilisateur autorisé de ladite chaîne de blocs, selon un mode de réalisation de l’invention. En relation avec ces figures, on décrit ci-dessous un procédé pour permettre à un créateur 1 d’enregistrer un fichier informatique 2 sur un serveur 16 lié à une chaîne de blocs, ainsi qu’une architecture comprenant des moyens techniques pour permettre la mise en œuvre d’un tel procédé. En particulier, les fichiers informatiques 2 sont associés à des jetons non fongibles (NFT), et correspondent à des représentations numériques de biens du créateur 1, dont le jeton non fongible associé représente cette propriété sur la chaîne de blocs. L’architecture comprend une plateforme 3 liée à la chaîne de blocs, qui comprend une interface de programmation d’applications (API, pour l’anglais « Application Programming Interface ») réalisant l’activation des moyens techniques pour recevoir des requêtes de créateurs 1 et d’utilisateurs 4 connectés eux aussi à la chaîne de blocs, cette dernière étant formée par un ensemble de plateformes de communication et de calcul permettant son fonctionnement, et servant de moyens d’accès à ladite chaîne de blocs. L’architecture comprend en outre au moins un terminal 5, 6 équipé de moyens pour permettre à un créateur 1 ou un utilisateur 4 d’interagir avec la chaîne de blocs et/ou la plateforme 3, notamment pour envoyer des requêtes telles que susmentionnées. Comme représenté sur les figures, le terminal 5, 6 peut être un téléphone portable de type « intelligent » (pour l’anglais « smartphone »). Le terminal 5, 6 peut également être d’un autre type, notamment une tablette numérique, un assistant personnel (PDA, pour l’anglais « Personal Digital Assistant »), un ordinateur portable ou un ordinateur de bureau, sous réserve d’être équipé de moyens techniques adaptés pour la mise en œuvre du procédé. En particulier, l’architecture peut comprendre au moins une application avec des moyens adaptés pour la mise en œuvre du procédé, que l’utilisateur 4 ou le créateur 1 peut télécharger pour l’installer sur son terminal 5, 6, notamment en envoyant une requête adaptée à ladite architecture. Pour pouvoir interagir avec la chaîne de blocs, le créateur 1 ou l'utilisateur 4 doit générer une paire de clés privée 7a, 35a et publique 7b, 35b, notamment lors de sa première connexion à ladite chaîne de blocs et en cas de perte ou de vol de ses précédentes clés. La clé privée 7a, 35a est tenue secrète par son propriétaire (créateur 1 ou utilisateur 4) et la clé publique 7b, 35b permet audit propriétaire d’interagir avec la chaîne de blocs pour y effectuer des opérations. En particulier, une adresse numérique personnelle est dérivable de la clé publique 7b, 35b pour représenter son propriétaire 1, 4 sur la chaîne de blocs. Pour générer de telles clés 7a, 7b, 35a, 35b, le créateur 1 ou l'utilisateur 4 peut lancer une procédure adaptée sur son terminal 5, 6 notamment au moyen de l’application décrite précédemment. Les clés 7a, 7b, 35a, 35b sont ainsi liées au terminal 5, 6 au sein duquel elles sont générées sous le contrôle du créateur 1 ou de l'utilisateur 4, qui n’utilise que la clé publique 7b, 35b. De ce fait, la clé privée 7a, 35a ne quitte jamais le terminal 5, 6, ce qui garantit à son propriétaire 1, 4 une sécurité optimale. Pour finaliser ou mettre à jour son adhésion à la chaîne de blocs, le créateur 1 ou l’utilisateur 4 enregistre sa clé publique 7b, 35b sur ladite chaîne de blocs. En particulier, le créateur 1 ou l’utilisateur 4 peut effectuer cet enregistrement en associant sa clé publique 7b, 35b à une empreinte numérique liée à l’identité dudit utilisateur. Pour ce faire, le créateur 1 ou l’utilisateur 4 peut authentifier son identité auprès d’une plateforme tierce (non représentée), afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée sur la chaîne de blocs pour être associée avec la clé publique 7b, 35b. La plateforme tierce présente un niveau de confiance qui peut être évalué dans le cadre de la réglementation eIDAS (pour l’anglais « Electronic IDentification And Trust Services ») ou de tout autre système d’évaluation de la confiance basé sur l’identité, et peut être par exemple une plateforme de fourniture d’un service d’identification publique et/ou administratif tel que la sécurité sociale, un service pour le paiement de taxes officielles telles que les impôts sur le revenu, ou tout autre service d’identification permettant d’atteindre le niveau de confiance eIDAS requis par les utilisateurs, ou encore tout autre système fournissant une identité, par exemple un système d’identification des employés d’une entreprise. En particulier, la plateforme tierce peut fournir pour le créateur 1 ou l’utilisateur 4 un identifiant unique, notamment basé sur les données d’identité. Cet enregistrement peut notamment être effectué dans un coffre-fort numérique personnel 8, 36 détenu par le créateur 1 ou l’utilisateur 4 sur la chaîne de blocs, comme représenté sur la FIG. 1 en relation avec les clés 7a, 7b détenues par le créateur 1, et sur la FIG. 2 en relation avec les clés 35a, 35b détenues par un utilisateur tiers 4. Le créateur 1 ou l’utilisateur 4 peut créer un tel coffre-fort personnel 8, 36 pour pouvoir interagir ultérieurement avec la chaîne de blocs uniquement au moyen de l’adresse numérique 9, 37 dudit coffre-fort personnel, ce qui permet audit créateur ou utilisateur d’enregistrer plusieurs clés publiques 7b, 35b dans un même coffre-fort personnel 8, 36 et d’accéder à la chaîne de blocs avec n’importe laquelle desdites clés, et donc d’éviter la perte de son accès à la chaîne de blocs en cas de perte et/ou de vol de ses clés 7a, 7b, 35a, 35b et/ou de son terminal 5, 6. Pour ce faire, l’architecture comprend une plateforme pour le déploiement de coffres-forts sur la chaîne de blocs, le terminal 5, 6 et/ou l’application comprenant des moyens pour solliciter ladite plateforme de déploiement pour créer un coffre-fort personnel 8, 36, notamment par l’envoi d’une requête adaptée (non représentée). Dans le mode de réalisation représenté, cette fonctionnalité est réalisée par la plateforme 3 d’accès à la chaîne de blocs, qui comprend des moyens techniques adaptés pour réaliser le déploiement de coffres-forts 8, 36 sur requête de tout utilisateur 4 ou créateur 1 présent sur ladite chaîne de blocs. En variante, l’architecture peut comprendre une plateforme additionnelle de déploiement de coffres-forts qui est distincte de la plateforme 3 d’accès à la chaîne de blocs. Tous les coffres-forts numériques de l’architecture peuvent être créés sous la forme de protocoles informatiques de type contrats intelligents (pour l’anglais « smart contract »), qui sont accessibles sur la chaîne de blocs au moyen d’une adresse numérique publique. La plateforme de déploiement 3 comprend une interface de programmation d’applications (API), qui comprend des moyens techniques adaptés pour permettre la création de coffres-forts sur la chaîne de blocs. De façon avantageuse, la plateforme de déploiement 3 est agencée pour permettre la création automatique de coffres-forts numériques sur simple requête d’un utilisateur 4 ou créateur 1. A cet effet, comme représenté sur les figures, l’architecture comprend : un coffre-fort numérique 10 lié à la plateforme de déploiement 3, dans lequel est enregistré au moins un identifiant de ladite plateforme de déploiement sur la chaîne de blocs, par exemple une adresse numérique dérivée d’une clé publique 11 d’accès de ladite plateforme à ladite chaîne de blocs ; un coffre-fort numérique central 12, qui comprend notamment : une liste répertoriant les plateformes de déploiement de coffres-forts appartenant à un réseau de confiance, ladite liste comprenant les adresses numériques des coffres-forts liés à chacune de ces plateformes de confiance, notamment l’adresse numérique 13 du coffre-fort 10 lié à la plateforme 3 représentée ; et une liste répertoriant l’ensemble des coffres-forts numériques créés par ces plateformes de confiance sur la chaîne de blocs, ladite liste comprenant des entrées qui contiennent chacune l’adresse numérique d’un coffre-fort créé par une plateforme de déploiement, associée à l’adresse numérique du coffre-fort lié à cette plateforme de déploiement, et notamment deux entrées comprenant respectivement l’adresse 9 du coffre-fort personnel 8 du créateur 1 et l’adresse 37 du coffre-fort personnel 36 d’un utilisateur tiers 4, associées chacune à l’adresse numérique 13 du coffre-fort 10 présenté ci-dessus. En variante, la plateforme de déploiement 3 peut être agencée pour permettre la création de coffres-forts numériques par un administrateur de la chaîne de blocs, notamment suite à la réception d’une requête de sollicitation par un créateur 1 ou un utilisateur 4. Après création de son coffre-fort numérique personnel 8, 36, le créateur 1 ou l’utilisateur 4 peut authentifier son identité auprès de la plateforme tierce décrite précédemment, afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée dans ledit coffre-fort numérique personnel par la plateforme de déploiement 3. A l’issue de cet enregistrement, la plateforme de déploiement 3 envoie au créateur 1 ou à l’utilisateur tiers 4 une notification contenant l’adresse numérique publique 9, 37 de son coffre-fort personnel 8, 36, afin que ledit créateur ou utilisateur puisse accéder audit coffre-fort personnel au moyen de ladite adresse numérique. Le procédé prévoit en outre, lorsqu’un créateur 1 présent sur la chaîne de blocs souhaite y créer des fichiers informatiques 2, de créer un coffre-fort numérique 14 spécifique pour ledit créateur sur ladite chaîne de blocs, afin de permettre audit créateur de gérer la création, l’édition et la diffusion de ses fichiers informatiques 2 au moyen dudit coffre-fort de gestion. Pour ce faire, le terminal 5 du créateur 1 comprend des moyens pour permettre audit créateur de solliciter une plateforme de déploiement présente sur la chaîne de blocs, notamment la plateforme 3 représentée sur les figures, afin de créer un tel coffre-fort numérique 14 pour la gestion de ses fichiers informatiques 2. En particulier, le procédé prévoit d’enregistrer l’adresse numérique 9 du coffre-fort personnel 8 du créateur 1, en tant qu’adresse parente dans le coffre-fort numérique 14 de gestion des fichiers informatiques 2 dudit créateur lors de la création dudit coffre-fort numérique de gestion. Pour ce faire, la plateforme 3 comprend des moyens adaptés pour effectuer cet enregistrement dans le coffre-fort 14 de gestion lors de sa création. De façon avantageuse, le coffre-fort 14 de gestion se présente sous la forme d’un contrat intelligent avec des fonctionnalités adaptées pour permettre au créateur 1 de gérer facilement la création, l’édition et l’enregistrement de données de lecture et d’autorisation d’accès de ses fichiers informatiques 2 sur la chaîne de blocs, parmi lesquelles un suivi des mises à jour des caractéristiques desdits fichiers, afin de fournir audit créateur une meilleure visibilité desdites mises à jour. La plateforme 4, après avoir créé le coffre-fort de gestion 14 : enregistre dans le coffre-fort central 12 une adresse numérique 15 permettant d’accéder audit coffre-fort de gestion sur la chaîne de blocs ; communique cette adresse numérique 15 au créateur 1, par exemple via une notification adaptée envoyée à son terminal 5, afin de permettre au créateur 1 d’accéder audit coffre-fort de gestion au moyen de ladite adresse numérique. En relation avec les figures, l’architecture comprend en outre un serveur 16 lié à la chaine de blocs pour le téléversement et le téléchargement de fichiers informatiques 2, ledit serveur comprenant notamment comprenant un accès en lecture sur la chaîne de blocs, ainsi qu’une base de données 17 dans lequel les fichiers 2 téléversés sur ledit serveur sont enregistrés. Pour améliorer la sécurité de conservation de ses fichiers informatiques 2, l’architecture peut comprendre plusieurs serveurs 16 comprenant les moyens techniques requis, et le créateur 1 peut enregistrer lesdits fichiers sur plusieurs serveurs 16 à la fois. En particulier, le créateur 1 peut enregistrer, notamment au moyen de la plateforme 3 et d’une application installée sur son terminal 5, l’(les) adresse(s) numérique(s) sur la chaine de blocs du(des) serveur(s) 16 sur le(s)quel(s) il souhaite enregistrer ses fichiers informatiques 2 dans une liste de variables prévue à cet effet dans le coffre-fort numérique 14 de gestion. L’adresse numérique d’un serveur 16 se présente notamment sous la forme d’un lien hypertexte de type URL (pour l’anglais « Uniform Resource Locator ») et permet à toute personne (créateur 1 ou utilisateur tiers 4) présente sur la chaîne de blocs d’accéder audit serveur en entrant ladite adresse numérique sur son terminal 5, 6. De façon avantageuse, le créateur 1 peut changer l’(les) adresse(s) numérique(s) de serveur(s) préalablement enregistrée(s) dans le coffre-fort 14 de gestion, notamment pour supprimer des adresses numériques de serveurs 16 devenus obsolètes ou qu’il ne souhaite plus utiliser et/ou pour ajouter des adresses numériques de nouveaux serveurs 16. Préalablement au téléversement d’un fichier informatique 2 par son créateur 1 sur le serveur 16, le procédé prévoit de : associer audit fichier un code d’indexation 18, ainsi que l’adresse numérique 15 d’accès au coffre-fort numérique 14 ; calculer une première empreinte 19 de hachage dudit fichier informatique ; enregistrer ladite première empreinte de hachage dans le coffre-fort 14, en l’associant au code d’indexation 18. Pour ce faire, le terminal 5 lié au créateur 1 comprend, notamment au moyen d’une application installée sur ledit terminal, des moyens adaptés pour effectuer les opérations susmentionnées. En relation avec la FIG. 1 , le terminal 5 ou l’application qui y est installée comprend des moyens pour lancer une procédure 20 adaptée pour : ajouter au fichier 2 des métadonnées contenant le code d’indexation 18 et l’adresse numérique 15 du coffre-fort 14 ; calculer une première empreinte 19 dudit fichier complété desdites métadonnées, par exemple sous la forme d’une suite alphanumérique comprenant un grand nombre de bits, notamment de l’ordre de 256 bits, et de préférence exprimée en hexadécimal, afin de minimiser le risque de collision avec des empreintes d’autres fichiers préalablement enregistrés sur le serveur 16. Cet agencement permet par ailleurs de prévenir toute gestion de ce fichier informatique 2 avec un coffre-fort numérique autre que le coffre-fort 14 du créateur 1. A l’issue de cette procédure 20, le terminal 5 envoie au coffre-fort 14 de gestion des fichiers 2 une notification 21 contenant la première empreinte 19, afin de l’enregistrer dans ledit coffre-fort de gestion. Le terminal 5 comprend en outre des moyens pour téléverser le fichier 2 complété des métadonnées sur le serveur 16, par exemple en envoyant audit serveur une requête 22 contenant ledit fichier. A la réception de la requête 22, le serveur 16 lance une procédure 23 pour vérifier le référencement du coffre-fort 14 de gestion dans le coffre-fort central 12 de la chaîne de blocs, en vérifiant la présence dans ledit coffre-fort central de l’adresse numérique 15 dudit coffre-fort de gestion. Pour ce faire, le serveur 16 comprend des moyens pour lire l’adresse numérique 15 ajoutée sur forme de métadonnée au fichier 2 extrait de la requête 22, ainsi que des moyens pour envoyer au coffre-fort central 12 une requête 24 comprenant cette adresse 15, afin d’en vérifier la présence dans ledit coffre-fort central. Si le coffre-fort 14 de gestion est bien référencé dans le coffre-fort central 12, le procédé prévoit ensuite de : calculer une deuxième empreinte de hachage à partir dudit fichier téléversé ; lire le code d’indexation et l’adresse numérique associés audit fichier téléversé ; comparer la deuxième empreinte de hachage calculée à partir dudit fichier téléversé à la première empreinte 19 préalablement enregistrée dans le coffre-fort 14 et associée au code d’indexation 18 lu dans ledit fichier téléversé ; enregistrer ledit fichier téléversé sur ledit serveur en cas de succès de ladite comparaison. Pour ce faire, en relation avec la FIG. 1 , le serveur 16 comprend des moyens pour, en lançant une procédure 25 adaptée : lire le code d’indexation 18 et l’adresse numérique 15 associés au fichier informatique 2 téléversé via la requête 22. calculer une deuxième empreinte de hachage du fichier 2 communiqué dans la requête 22 ; comparer cette deuxième empreinte de hachage à la première empreinte 19 préalablement enregistrée dans le coffre-fort 14 et associée au code d’indexation 18 lu dans ledit fichier téléversé. Dans le cas où le code 18 et l’adresse 15 sont ajoutées sous forme de métadonnées au fichier 2 téléversé, le serveur 16 comprend des moyens adaptés pour effectuer la lecture dudit code et de ladite adresse en consultant lesdites métadonnées lors du téléversement dudit fichier. Le serveur 16 comprend en outre des moyens pour, en cas de succès de comparaison des empreintes de hachage, lancer une procédure 26 adaptée pour : enregistrer le fichier 2 téléversé dans sa base de données 17 ; envoyer au terminal 5 une notification 27 pour informer le créateur 1 du succès de cet enregistrement. En particulier, le procédé peut prévoir de renommer le fichier 2 en utilisant sa première empreinte 19 comme nouveau nom au moment de son enregistrement sur le serveur 16, afin de faciliter le référencement conjoint dudit fichier enregistré sur ledit serveur et de ladite première empreinte enregistrée dans le coffre-fort 14. Pour ce faire, le terminal 5 peut comprendre des moyens pour, à la réception de la notification 27 d’enregistrement du fichier 2 sur le serveur 16, afficher sur son écran une fenêtre à l’attention du créateur 1, dans laquelle est indiqué par défaut le nouveau nom utilisé pour enregistrer ledit fichier sur ledit serveur. En particulier, la fenêtre peut comprendre un bouton interactif pour permettre au créateur de valider ce nouveau nom, ainsi qu’éventuellement un bouton interactif pour refuser ledit nouveau nom et choisir lui-même un autre nom, par exemple en entrant manuellement le nom de son choix dans un champ prévu à cet effet sur ladite fenêtre. Le procédé prévoit d’enregistrer dans le coffre-fort numérique 14 un statut d’autorisation défini par le créateur 1 pour un éventuel téléchargement ultérieur dudit fichier téléversé, par exemple par le créateur 1 lui-même ou par un autre utilisateur 4 présent sur la chaîne de blocs, en l’associant au code d’indexation 18. Cet agencement permet au créateur 1 de conserver ses fichiers informatiques 2 avec plusieurs niveaux de sécurité, qu’il peut également faire évoluer au cours du temps. Par ailleurs, cet agencement permet au créateur 1 de bénéficier facilement d’un suivi sur les mises à jour effectuées sur ses fichiers 2. Pour ce faire, le terminal 5 ou l’application qui y est installée comprend des moyens pour permettre au créateur 1 de définir et d’enregistrer dans le coffre-fort numérique 14 un tel statut d’autorisation de téléchargement pour un fichier 2 enregistré ou devant être enregistré sur le serveur 16, en l’associant au code d’indexation 18. En particulier, le procédé prévoit, grâce à des moyens adaptés de son terminal 5 ou de l’application qui y est installée, de permettre au créateur 1 de définir un statut d’autorisation de téléchargement pour un fichier informatique 2 en le choisissant parmi un ensemble de statuts d’autorisation prédéterminés, afin de faciliter cette opération pour ledit créateur. En particulier, l’application installée sur le terminal 5 peut comprendre une base de données, notamment enregistrée sur ledit terminal, dans lequel des statuts d’autorisation prédéterminés sont pré-enregistrés, ainsi que des moyens pour afficher sur ledit terminal une fenêtre pour permettre au créateur 1 de choisir parmi ces statuts pré-enregistrés un statut à associer au fichier informatique 2, par exemple au moyen d’un menu déroulant contenant une liste des statuts d’autorisation possibles. Cet enregistrement peut être effectué dans le coffre-fort 14 en même temps que celui de la première empreinte 19, notamment au cours de la procédure 20 de calcul et d’enregistrement de ladite première empreinte, afin de simplifier le téléversement et l’enregistrement du fichier 2 sur le serveur 16. En particulier, le statut d’autorisation de téléchargement peut être envoyé dans la requête 21 contenant la première empreinte 19. En variante, l’enregistrement du statut d’autorisation dans le coffre-fort 14 peut être réalisée durant une procédure indépendante (non représentée). En particulier, le terminal 5 peut afficher sur son écran, à tout moment durant le téléversement du fichier 2 sur le serveur 16, une fenêtre telle que décrite précédemment pour inviter le créateur 1 à choisir un statut d’autorisation de téléchargement à associer audit fichier. Le statut d’autorisation de téléchargement attribué à un fichier 2 peut notamment être inscrit sous la forme d’un code alphanumérique dans le coffre-fort numérique 14 de gestion, notamment dans une liste dédiée au sein dudit coffre-fort, dans laquelle il est associé au code d’indexation 18 et à la première empreinte de hachage 19 dudit fichier. De façon avantageuse, l’ensemble des statuts d’autorisation prédéterminés comprend au moins un statut d’autorisation qui comprend une modalité de sécurité prévoyant une authentification auprès du serveur d’un utilisateur 1, 4 (créateur 1 ou utilisateur tiers 4) qui requiert le téléchargement du fichier informatique 2 correspondant. En particulier, le créateur 1 peut choisir un statut d’autorisation de téléchargement parmi les six statuts prédéterminés suivants, classés dans l’ordre décroissant de leurs niveaux de sécurité : un statut « 0 », correspondant à un niveau de sécurité maximal, pour lequel le fichier 2 ne doit pas être affiché par le serveur 16 ; un statut « 1 », pour lequel le serveur 16 ne doit afficher le fichier 2 qu’à destination de son créateur 1, après authentification dudit créateur ; un statut « 2 », pour lequel le serveur 16 doit envoyer une notification au créateur 1 pour l’avertir qu’un utilisateur tiers 4 souhaite visualiser son fichier 2, afin de requérir la validation dudit créateur pour autoriser l’affichage dudit fichier ; un statut « 3 », pour lequel le serveur 16 ne doit afficher le fichier 2 qu’à destination de son créateur 1 ou d’un utilisateur tiers 4 autorisé, après authentification dudit créateur ou utilisateur tiers ; un statut « 4 », pour lequel le serveur 16 peut afficher le fichier 2 sans condition, pour tout utilisateur 1, 4 de la chaîne de blocs, notamment référencé dans le coffre-fort central 13 de ladite chaîne de blocs, qui le requiert ; et un statut « 5 », pour lequel le serveur 16 peut afficher le fichier 2 sans condition, pour tout utilisateur qui le requiert. Par ailleurs, suivant les utilisations souhaitées pour les fichiers informatiques 2, d’autres types de statuts peuvent être envisagés. Le procédé prévoit en outre, lorsque le créateur 1 choisit pour un fichier informatique 2 téléversé un statut d’autorisation de téléchargement qui prévoit une authentification d’un utilisateur 1, 4 qui le requiert, tel que par exemple le statut « 1 » ou le statut « 3 » mentionné(s) ci-dessus, d’enregistrer au moins une liste d’adresses numériques 7b, 9, 35b, 37 des utilisateurs 1, 4 autorisés à télécharger ledit fichier informatique, afin de permettre une authentification ultérieure d’un utilisateur tiers 4 requérant le téléchargement dudit fichier en vérifiant la présence dans ladite liste d’une adresse numérique 7b, 9, 35b, 37 dudit utilisateur. Pour ce faire, le terminal 5 comprend des moyens pour permettre au créateur 1 d’effectuer un tel enregistrement, par exemple en affichant sur son écran une fenêtre adaptée lorsque ledit créateur sélectionne un statut d’autorisation prédéterminé qui requiert l’authentification d’un utilisateur 1, 4 souhaitant télécharger le fichier 2. Le créateur 1 peut alors renseigner dans cette fenêtre au moins une adresse numérique 7b, 9, 35b, 37 d’un utilisateur 1, 4 qu’il souhaite autoriser à télécharger le fichier 2, afin d’enregistrer ladite adresse, par exemple dans le coffre-fort numérique 14, en l’associant au code d’indexation 18 dudit fichier. En particulier, le créateur 1 peut enregistrer dans le coffre-fort 14 deux listes distinctes pour le(s) créateur(s) 1 du fichier 2 et pour l’(les) utilisateur(s) tiers 4 autorisé(s) à accéder audit fichier, afin de garantir des accès avec des niveaux de sécurité distincts pour le(s)dit(s) créateur(s) et le(s)dit(s) utilisateur(s) tiers. De façon avantageuse, la clé publique 7b et/ou l’adresse numérique 9 utilisée(s) par le créateur 1 au moment du téléversement du fichier 2 peu(ven)t être enregistrée(s) automatiquement dans une liste d’accès « créateur(s) » du coffre-fort 14 à l’issue du téléversement. En relation avec la FIG. 2 , le procédé prévoit, lorsqu’un utilisateur 4 de la chaîne de blocs requiert auprès du serveur 16 le téléchargement d’un fichier 2 préalablement téléversé sur ledit serveur, de : vérifier dans le coffre-fort numérique 14 le statut d’autorisation de téléchargement défini pour ledit fichier et associé au code d’indexation 18 ; et le cas échéant, procéder audit téléchargement, selon des modalités de sécurité associées audit statut. Pour ce faire, l’architecture comprend un terminal 6 pour permettre à un utilisateur 4 de requérir le téléchargement d’un fichier 2, notamment par l’envoi au serveur 16 d’une requête 28 adaptée, ledit serveur comprenant des moyens pour, le cas échéant, vérifier le statut d’autorisation associé audit fichier, et, dans le cas où les conditions requises pour ledit téléchargement sont remplies, procéder audit téléchargement selon les modalités de sécurité associées audit statut. Sur la FIG. 2 , l’utilisateur 4 requérant le téléchargement d’un fichier 2 est un utilisateur tiers différent du créateur 1 ayant téléversé ledit fichier sur le serveur 16, et son terminal 6 d’accès à la chaîne de blocs est différent du terminal 5 utilisé par ledit créateur. Le terminal 6 est toutefois similaire au terminal 5 du créateur 1, et comprend notamment une application adaptée pour permettre à l’utilisateur 4 d’accéder à la chaîne de blocs au moyen de clés associées à son terminal et/ou, de façon avantageuse, enregistrées dans un coffre-fort numérique personnel similaire au coffre-fort personnel 8 du créateur 1. En variante non représentée, l’utilisateur requérant le téléchargement d’un fichier 2 peut être son créateur 1 lui-même, qui peut effectuer ces opérations de téléchargement au moyen de l’application installée sur son terminal 5, qu’il a utilisée au préalable pour téléverser ledit fichier sur le serveur 16. Sur la FIG. 2 , le terminal 6 envoie au coffre-fort 14, grâce à son adresse numérique 15, une requête 29 préliminaire comprenant le code d’indexation 18 du fichier 2 que l’utilisateur 4 souhaite télécharger, afin de lire la première empreinte 19 enregistrée pour ledit fichier. Ensuite, le terminal 6 envoie au serveur 16 une requête telle que décrite précédemment, qui contient notamment la première empreinte 19 lue dans le coffre-fort 14. A la réception de ces requêtes, le serveur 16 envoie au coffre-fort 14 une requête 30 contenant notamment l’empreinte 19 et le code d’indexation 18, afin d’y vérifier en parallèle, grâce à deux procédures 31, 32 adaptées : l’existence d’une empreinte 19 correspondante à celle communiquée dans la requête 28 (procédure 31) ; et le statut d’autorisation de téléchargement défini pour le fichier 2 correspondant, et notamment associé au code d’indexation 18 dudit fichier dans ledit coffre-fort numérique (procédure 32). En particulier, le serveur 16 comprend des moyens pour authentifier l’utilisateur 4 requérant le téléchargement du fichier informatique 2, dans le cas où le statut d’autorisation de téléchargement qui lui est associé comprend une modalité de sécurité qui le prévoit. Pour ce faire, durant la procédure 32 correspondante, le serveur 16 peut notamment authentifier l’utilisateur 4 en vérifiant la présence d’une adresse numérique 35b, 37 dudit utilisateur dans une liste d’adresses numériques autorisées préalablement enregistrées dans le coffre-fort 14 pour ce fichier 2. De façon avantageuse, pour améliorer la sécurité du téléchargement des fichiers 2, mais également la connexion de l’utilisateur 4 à la chaîne de blocs, le procédé peut prévoir d’authentifier l’utilisateur 4 au moyen d’un système de jetons de connexion, couplé à un coffre-fort personnel 36 détenu par ledit utilisateur sur ladite chaîne de blocs. Pour ce faire, le serveur 16 peut, au cours de la procédure 32, communiquer à l’utilisateur 4 un jeton identifiant sa session de connexion à la chaîne de blocs, et l’utilisateur 4 peut, au moyen de son terminal 6 : générer un numéro aléatoire ; signer électroniquement le jeton de session communiqué par le serveur 16 et ledit numéro aléatoire au moyen d’une clé privée 35a liée au terminal 6, et associée à une clé publique 35b préalablement enregistrée dans le coffre-fort personnel 36 dudit utilisateur sur la chaîne de blocs ; communiquer le jeton de session et le numéro aléatoire signés, ainsi que l’adresse numérique 37 du coffre-fort personnel 36 ; afin de permettre une authentification de l’utilisateur 4 successivement par : vérification de la signature électronique du jeton de session et du numéro aléatoire par comparaison avec la clé publique 35b enregistrée dans le coffre-fort personnel 36, ce qui permet d’assurer la validité de ladite clé publique et de ladite adresse numérique ; puis vérification de la présence de la clé publique 35b et/ou de l’adresse numérique 37 du coffre-fort personnel 36 de l’utilisateur 4 dans une liste d’adresses numériques 7b, 9, 35b, 37 autorisées associées au fichier 2 dans le coffre-fort 14. En particulier, pour mettre en place cette procédure d’authentification, l’architecture peut comprendre un serveur (non représenté) spécifiquement dédié à ladite authentification, qui comprend : des moyens pour recevoir le jeton de session et le numéro aléatoire signés et l’adresse numérique 37 communiqués par le terminal 6 ; des moyens pour vérifier la signature dudit jeton de session et dudit numéro aléatoire ; des moyens pour signer le numéro aléatoire au moyen d’une clé privée dudit serveur d’authentification ; des moyens pour communiquer ledit numéro aléatoire signé au serveur 16, afin de permettre au serveur 16 de vérifier la fiabilité dudit serveur d’authentification par vérification d’une clé publique associée à sa clé privée ; et des moyens pour, en cas de succès de l’authentification de l’utilisateur 4, communiquer à son terminal 6 une notification comprenant des copies du jeton de session et du numéro aléatoire signées au moyen de la clé privée dudit serveur d’authentification. A l’issue des procédures 31, 32, le serveur 16 envoie au terminal 6 une notification 33 qui varie selon le résultat desdites procédures, notamment selon le référencement ou non du fichier 2 requis dans le coffre-fort 14 et/ou selon le succès ou l’échec de l’authentification de l’utilisateur 4. Sur la FIG. 2 , correspondant au cas où le fichier 2 est bien référencé dans le coffre-fort 14 et où l’utilisateur 4 bénéficie d’une autorisation pour le télécharger, notamment s’il a été correctement authentifié par le serveur 16, la notification 33 communiquée à son terminal 6 comprend le fichier 2 requis. Dans les autres cas, la notification 33 comprend des codes d’erreur correspondant aux raisons de l’échec du téléchargement du fichier 2, notamment : en cas d’erreur dans le code d’indexation et/ou dans l’empreinte de hachage communiqué(e)(s) par le terminal 6 ; et/ou en cas d’absence du fichier 2 requis dans la base de données 17 ; et/ou en cas d’absence de référencement dudit fichier dans le coffre-fort 14 ; et/ou en cas de non autorisation de téléchargement pour l’utilisateur 4 (statut « 0 » interdisant tout téléchargement, ou absence de l’adresse numérique renseignée par l’utilisateur 4 dans la liste associée au fichier 2 dans le coffre-fort 14). Enfin, à la réception de la notification 33, le terminal 6 lance une procédure 34 adaptée pour afficher sur son écran le résultat de la requête en téléchargement du fichier 2, avec des informations lisibles pour un utilisateur 4 humain. Procédé pour permettre à un créateur (1) d’enregistrer un fichier informatique (2) sur un serveur lié à une chaîne de blocs, ledit procédé prévoyant de : associer audit fichier un code d'indexation (18), ainsi qu'une adresse numérique (15) d'accès à un coffre-fort numérique (14) sur la chaîne de blocs ; calculer une première empreinte (19) de hachage dudit fichier informatique ; enregistrer ladite première empreinte de hachage dans le coffre-fort numérique (14), en l'associant au code d'indexation (18) ; enregistrer dans le coffre-fort numérique (14) un statut d'autorisation défini par le créateur (1) pour un éventuel téléchargement ultérieur dudit fichier informatique, en l’associant au code d'indexation (18) ; ledit procédé prévoyant, lors du téléversement dudit fichier informatique par ledit créateur sur un serveur (16) dédié comprenant un accès en lecture sur la chaîne de blocs, de : calculer une deuxième empreinte de hachage à partir dudit fichier téléversé ; lire le code d'indexation (18) et l'adresse numérique (15) associés audit fichier téléversé ; comparer la deuxième empreinte de hachage calculée à partir dudit fichier téléversé à la première empreinte de hachage (19) préalablement enregistrée dans le coffre-fort numérique (14) et associée au code d'indexation (18) lu avec ledit fichier téléversé ; enregistrer ledit fichier téléversé sur le serveur (16) en cas de succès de ladite comparaison ; ledit procédé prévoyant en outre, lorsqu'un utilisateur (1, 4) de la chaîne de blocs requiert le téléchargement du fichier informatique (2) auprès du serveur (16), de : vérifier dans le coffre-fort numérique (14) le statut d'autorisation de téléchargement défini pour ledit fichier informatique et associé au code d’indexation (18) ; et le cas échéant, procéder audit téléchargement selon des modalités de sécurité associées audit statut. Procédé selon la revendication 1, caractérisé en ce qu’il prévoit d’ajouter au fichier informatique (2) des métadonnées contenant le code d'indexation (18) et l’adresse numérique (15) du coffre-fort (14), afin de permettre la lecture dudit code d’indexation et de ladite adresse numérique par consultation desdites métadonnées lors du téléversement dudit fichier informatique sur le serveur (16). Procédé selon l’une des revendications 1 ou 2, caractérisé en ce que le statut d’autorisation de téléchargement défini par le créateur (1) pour le fichier informatique (2) est choisi par le créateur (1) parmi un ensemble de statuts d’autorisation prédéterminés. Procédé selon la revendication 3, caractérisé en ce que l’ensemble de statuts d’autorisation prédéterminés comprend au moins un statut d’autorisation qui comprend une modalité de sécurité prévoyant une authentification auprès du serveur (16) d’un utilisateur (1, 4) requérant le téléchargement du fichier informatique (2). Procédé selon la revendication 4, caractérisé en ce qu’il prévoit, lorsque le créateur (1) choisit pour le fichier informatique (2) téléversé un statut d’autorisation de téléchargement prévoyant une authentification d’un utilisateur (1, 4) qui en requiert le téléchargement, d’enregistrer au moins une liste d’adresses numériques (7b, 9, 35b, 37) des utilisateurs (1, 4) autorisés à télécharger ledit fichier informatique, afin de permettre une authentification ultérieure d’un utilisateur qui en requiert le téléchargement en vérifiant la présence dans ladite liste d’une adresse numérique dudit utilisateur. Architecture pour permettre à un créateur (1) d’enregistrer un fichier informatique (2) sur un serveur lié à une chaîne de blocs, ladite architecture comprenant : un terminal (5) lié au créateur (1) et comprenant : des moyens pour associer audit fichier un code d'indexation (18), ainsi qu'une adresse numérique (15) d'accès à un coffre-fort numérique (14) sur la chaîne de blocs ; des moyens pour calculer une première empreinte (19) de hachage dudit fichier informatique ; des moyens pour enregistrer ladite première empreinte de hachage dans le coffre-fort numérique (14), en l'associant au code d'indexation (18) ; des moyens pour permettre au créateur (1) de définir et d’enregistrer dans le coffre-fort numérique (14) un statut d’autorisation pour un éventuel téléchargement ultérieur dudit fichier informatique, en l’associant au code d’indexation (18) ; un serveur (16) pour le téléversement et le téléchargement de fichiers informatiques (2), ledit serveur comprenant un accès en lecture sur la chaîne de blocs ; ledit terminal du créateur (1) comprenant des moyens pour permettre audit créateur de téléverser et d’enregistrer le fichier informatique (2) sur le serveur (16), ledit serveur comprenant des moyens pour, lors du téléversement dudit fichier : calculer une deuxième empreinte de hachage à partir dudit fichier téléversé ; lire le code d'indexation (18) et l'adresse numérique (15) associés audit fichier téléversé ; comparer la deuxième empreinte de hachage calculée à partir dudit fichier téléversé à la première empreinte de hachage (19) préalablement enregistrée dans le coffre-fort numérique (14) et associée au code d'indexation (18) lu avec ledit fichier téléversé ; enregistrer ledit fichier téléversé sur ledit serveur en cas de succès de ladite comparaison ; ladite architecture comprenant en outre un terminal (5, 6) pour permettre à un utilisateur (1, 4) de requérir le téléchargement du fichier informatique (2) auprès dudit serveur, ledit serveur comprenant des moyens pour, le cas échéant : vérifier dans le coffre-fort numérique (14) le statut d'autorisation de téléchargement défini pour ledit fichier informatique et associé au code d’indexation (18) ; et le cas échéant, procéder audit téléchargement selon des modalités de sécurité associées audit statut. Architecture selon la revendication 6, caractérisée en ce que le terminal (5) du créateur (1) comprend des moyens pour ajouter au fichier informatique (2) des métadonnées contenant le code d'indexation (18) et l’adresse numérique (15) du coffre-fort (14), le serveur (16) comprenant des moyens pour lire ledit code d’indexation et ladite adresse numérique en consultant lesdites métadonnées lors du téléversement dudit fichier informatique. Architecture selon l’une des revendications 6 ou 7, caractérisée en ce que le terminal (5) du créateur (1) comprend des moyens pour permettre au créateur (1) de définir un statut d’autorisation de téléchargement pour le fichier informatique (2) en le choisissant parmi un ensemble de statuts d’autorisation prédéterminés. Architecture selon la revendication 8, caractérisée en ce que l’ensemble de statuts d’autorisation prédéterminés comprend au moins un statut d’autorisation qui comprend une modalité de sécurité prévoyant une authentification auprès du serveur (16) d’un utilisateur (1, 4) requérant le téléchargement du fichier informatique (2), ledit serveur comprenant des moyens pour réaliser ladite authentification. Architecture selon la revendication 9, caractérisé en ce que le terminal (5) du créateur (1) comprend des moyens pour permettre au créateur (1), lorsqu’il choisit pour le fichier informatique (2) téléversé un statut d’autorisation de téléchargement prévoyant une authentification d’un utilisateur (1, 4) qui en requiert le téléchargement, d’enregistrer au moins une liste d’adresses numériques (7b, 9, 35b, 37) des utilisateurs (1, 4) autorisés à télécharger ledit fichier informatique, le serveur (16) comprenant des moyens pour authentifier ultérieurement un utilisateur (1, 4) qui en requiert le téléchargement en vérifiant la présence dans ladite liste d’une adresse numérique (7b, 9, 35b, 37) dudit utilisateur.