FR 3101454 A1 20210402 FR 1910815 A 20190930 L’invention concerne un procédé pour permettre à un utilisateur (1) d’accéder à une chaîne de blocs d’une organisation, ledit procédé prévoyant de : créer une paire de clés privée (9a) et publique (9b) pour permettre audit utilisateur d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs ; collecter des données personnelles de l’utilisateur (1), lesdites données comprenant au moins une information sur l’identité de l’utilisateur (1) et une information sur ladite organisation ; vérifier la validité desdites données personnelles ; identifier un statut dudit utilisateur au sein de ladite organisation au moyen desdites données vérifiées ; enregistrer la clé publique (9b) dans au moins un coffre-fort numérique de la chaîne de blocs en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à au moins une fonction opérationnelle dans ladite chaîne de blocs accessible par ledit coffre-fort. Figure 1 Procédé pour permettre à un utilisateur d’accéder à une chaîne de blocs d’une organisation L’invention concerne un procédé pour permettre à un utilisateur d’accéder à une chaîne de blocs d’une organisation, ainsi qu’une architecture comprenant des moyens pour la mise en œuvre d’un tel procédé. Les chaines de blocs (pour l’anglais « blockchain ») sont des technologies qui permettent à leurs utilisateurs de stocker et transmettre des données de manière sécurisée et sans organe central de contrôle, grâce à une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes sont vérifiés et groupés à intervalles de temps réguliers en blocs, formant ainsi une chaîne (voir notamment l’article « Blockchain » sur le site de l’encyclopédie collaborative Wikipedia® et l’article du journal en ligne « Le Journal du Net » disponible à l’adresse https://www.journaldunet.com/economie/finance/1195520-blockchain-avril-2019/). Cette technologie en pleine expansion est notamment utilisée pour permettre aux utilisateurs de réaliser des transactions, validées par un mécanisme de consensus entre des nœuds de la chaîne (appelés « mineurs »), et trouve plus particulièrement son application dans la création et la gestion de monnaies virtuelles, ou crypto-monnaies, telles que par exemple le Bitcoin®, Ether®, Monero® ou encore Peercoin® (ou PPcoin®). L’utilisation d’une chaîne de blocs s’avère particulièrement avantageuse pour une organisation, notamment une grande entreprise, en ce qu’elle permet de relier facilement les différentes fonctions opérationnelles réalisées au sein de ladite organisation, ainsi que les différents dirigeants bénéficiant de mandats au sein de ladite organisation pour participer à ces fonctions opérationnelles. Pour accorder l’accès à la chaîne de blocs des différents membres de l’organisation, les systèmes actuels reposent principalement sur une présomption de confiance pour les actes commerciaux standards et, pour les fonctions opérationnelles plus complexes nécessitant l’intervention de dirigeants, une vérification des pièces d’identité desdits dirigeants et des documents officiels de l’organisation, par exemple un extrait K-Bis. Cette solution ne donne pas entière satisfaction, en ce qu’elle ne permet pas de réaliser de façon totalement sécurisée une fonction opérationnelle complexe, qui nécessite notamment une garantie de l’identité de chacun des participants, de leur consentement respectif et de la sécurisation du lien entre l’identité et le consentement. L’invention vise à perfectionner l’art antérieur en proposant notamment un procédé pour permettre à une organisation de gérer facilement ses fonctions opérationnelles, par exemple ses interactions commerciales avec des entités extérieures, au moyen d’une chaîne de blocs, tout en garantissant à ladite organisation une sécurité optimale par rapport à l’identité des participants auxdites fonctions opérationnelles et au consentement desdits participants. A cet effet, selon un premier aspect, l’invention propose un procédé pour permettre à un utilisateur d’accéder à une chaîne de blocs d’une organisation, ledit procédé prévoyant de : créer une paire de clés privée et publique pour permettre audit utilisateur d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs ; collecter des données personnelles de l’utilisateur, lesdites données comprenant au moins une information sur l’identité de l’utilisateur et une information sur ladite organisation ; vérifier la validité desdites données personnelles ; identifier un statut dudit utilisateur au sein de ladite organisation au moyen desdites données vérifiées ; enregistrer la clé publique dans au moins un coffre-fort numérique de la chaîne de blocs en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à une fonction opérationnelle dans ladite chaîne de blocs accessible par ledit coffre-fort. Selon un deuxième aspect, l’invention propose une architecture pour permettre à un utilisateur d’accéder à une chaîne de blocs d’une organisation, ladite architecture comprenant : une application installée sur un terminal dudit utilisateur, ladite application comprenant des moyens pour créer une paire de clés privée et publique pour permettre audit utilisateur d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs ; une plateforme de fourniture d’au moins un coffre-fort numérique permettant de participer à une fonction opérationnelle dans ladite chaîne de blocs ; une plateforme centrale comprenant : des moyens pour collecter la clé publique ; des moyens pour collecter des données personnelles d’un utilisateur, lesdites données comprenant au moins une information sur l’identité de l’utilisateur et une information sur ladite organisation ; des moyens pour vérifier la validité desdites données personnelles ; des moyens pour identifier un statut dudit utilisateur au sein de ladite organisation au moyen desdites données vérifiées ; des moyens pour enregistrer la clé publique dans au moins un coffre-fort numérique en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à au moins une fonction opérationnelle dans ladite chaîne de blocs accessible par ledit coffre-fort. 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 : représente une architecture de mise en œuvre d’un procédé selon un mode de réalisation de l’invention ; représente l’organisation hiérarchique des utilisateurs de la chaîne de blocs, ainsi que leurs accès aux coffres-forts correspondants. En relation avec ces figures, on décrit ci-dessous un procédé pour permettre à un utilisateur 1, 1a, 1b, 1c, 1d d’accéder à une chaîne de blocs d’une organisation, ainsi qu’une architecture comprenant des moyens pour la mise en œuvre d’un tel procédé. L’organisation peut notamment être une entreprise, mais également une association. Le procédé prévoit de créer une paire de clés privée 9a et publique 9b pour permettre à l’utilisateur 1, 1a, 1b, 1c, 1d d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs. En particulier, le procédé prévoit de créer la paire de clés 9a, 9b dans un terminal 3 de l’utilisateur 1, 1a, 1b, 1c, 1d sous le contrôle dudit utilisateur. De ce fait, la clé privée 9a ne quitte jamais le terminal 3 de l’utilisateur 1, 1a, 1b, 1c, 1d, ce qui garantit audit utilisateur une confidentialité optimale. Pour ce faire, l’architecture comprend une application qui est installée sur le terminal 3 de l’utilisateur, ladite application comprenant des moyens pour créer de telles clés 9a, 9b sous le contrôle dudit utilisateur. Sur les figures, le terminal 3 est un téléphone portable dit intelligent (pour l’anglais « smartphone »). Le terminal 3 peut aussi être une tablette numérique, ou encore un assistant personnel (PDA, pour l’anglais « Personal Digital Assistant »). Le procédé prévoit également de collecter des données personnelles de l’utilisateur 1, 1a, 1b, 1c, 1d, lesdites données comprenant au moins une information sur l’identité dudit utilisateur et une information sur ladite organisation. L’information sur l’identité de l’utilisateur 1, 1a, 1b, 1c, 1d peut notamment comprendre une information nominative, par exemple le nom et/ou le prénom dudit utilisateur. Par ailleurs, l’information sur l’organisation peut comprendre un identifiant d’enregistrement de ladite organisation auprès d’une instance juridique ou légale, telle que par exemple un numéro SIREN (pour Système d’Identification du Répertoire des Entreprises). L’architecture comprend une plateforme centrale 2 qui comprend des moyens pour collecter de telles données personnelles, ainsi que des moyens pour collecter la clé publique 9b de l’utilisateur 1, 1a, 1b, 1c, 1d. En relation avec la figure 1, l’utilisateur 1 envoie au moyen de son terminal 3 au moins un message 4 comprenant les données personnelles requises et/ou la clé publique 9b, la plateforme centrale 2 étant agencée pour recevoir le(s)dit(s) message(s) et en extraire lesdites données et ladite clé publique grâce à des moyens de collecte adaptés. En particulier, l’envoi des données personnelles peut être effectué au moyen d’un système de sécurisation, tel que par exemple le système Safekey® développé par la société American Express®, qui prévoit de communiquer au terminal 3 un identifiant à usage unique que l’utilisateur 1, 1a, 1b, 1c, 1d doit renseigner pour permettre ledit envoi, ou encore des systèmes reposant sur un procédé cryptographique TLS (pour l’anglais « Transaction Secure Layer »). Le procédé prévoit ensuite de vérifier la validité des données personnelles collectées, notamment pour vérifier que l’utilisateur 1, 1a, 1b, 1c, 1d fait bien partie de l’organisation. Pour ce faire, la plateforme centrale 2 comprend des moyens pour effectuer une telle vérification. En particulier, la plateforme centrale 2 peut interagir avec une base de données dans laquelle les identités de tous les membres de l’organisation sont enregistrées, afin de vérifier la validité des données collectées en fonction de la présence ou non de l’information d’identité de l’utilisateur 1, 1a, 1b, 1c, 1d dans ladite base de données. De façon avantageuse, le procédé peut également vérifier un niveau de confiance des données personnelles collectées, afin de ne les valider que si ledit niveau correspond au moins à un niveau minimal prédéterminé. Le procédé prévoit ensuite d’identifier un statut de l’utilisateur 1, 1a, 1b, 1c, 1d au sein de l’organisation au moyen des données vérifiées, la plateforme centrale 2 comprenant des moyens adaptés pour réaliser une telle identification. En particulier, le procédé prévoit d’identifier ce statut en vérifiant la présence de l’information d’identité collectée dans un registre numérique légal 5 des dirigeants de l’organisation, ledit registre étant sélectionné au moyen de l’information collectée sur ladite organisation. Pour ce faire, les moyens d’identification de la plateforme centrale 2 sont agencés pour interagir avec une plateforme 6 de fourniture de registres numériques légaux de plusieurs organisations, par exemple au moyen d’une interface de programmation adaptée (API, pour l’anglais « Application Programming Interface »), pour : sélectionner le registre numérique 5 des dirigeants de l’organisation au moyen de l’information collectée sur ladite organisation ; et vérifier la présence dans ledit registre de l’information d’identité collectée. La plateforme 6 peut être par exemple la plateforme Datainfogreffe® des Greffes des Tribunaux de Commerce, dans laquelle les entreprises sont enregistrées avec leur numéro SIREN. En relation avec la figure 1, la plateforme centrale 2 envoie à la plateforme des registres 6 une requête 7 comprenant l’information collectée sur l’organisation, la plateforme 6 envoyant en retour un message 8 comprenant la liste des dirigeants de ladite organisation extraite du registre 5 correspondant, afin de permettre aux moyens d’identification du statut de vérifier la présence dans ladite liste de l’information d’identité de l’utilisateur 1. En particulier, les informations d’identité des dirigeants de l’organisation peuvent être enregistrées dans le registre numérique 5 suivant n catégories, n étant un entier naturel supérieur ou égal à 2, selon le poste occupé par chacun desdits dirigeants. Ainsi, le registre 5 peut comprendre une catégorie n regroupant les dirigeants supérieurs, par exemple le Président Directeur Général (PDG) ou le Directeur Général (DG) d’une entreprise, ainsi qu’au moins une catégorie n-1 regroupant les dirigeants intermédiaires, par exemple les membres du Conseil d’Administration de l’entreprise. Dans ce cas, le procédé peut prévoir d’identifier le statut de l’utilisateur 1, 1a, 1b, 1c, 1d en déterminant son niveau d’importance k, k étant un entier naturel compris entre 1 et n, en fonction de l’éventuelle catégorie avec laquelle son information d’identité est enregistrée dans le registre 5. Pour ce faire, les moyens d’identification de la plateforme centrale 2 peuvent être agencés pour déterminer un tel niveau d’importance k pour l’utilisateur 1, 1a, 1b, 1c, 1d. Et, en cas d’absence de l’information d’identité de l’utilisateur 1, 1a, 1b, 1c, 1d dans le registre 5, notamment dans le cas d’un employé de l’organisation ne faisant pas partie des dirigeants, le procédé peut prévoir de déterminer pour ledit utilisateur un niveau d’importance minimal 1, afin de lui permettre d’accéder à la chaîne de blocs, mais avec des possibilités d’action limitées. Une fois le statut de l’utilisateur 1, 1a, 1b, 1c, 1d identifié, le procédé prévoit d’enregistrer la clé publique 9b dans au moins un coffre-fort numérique C(1), C(k), C(n) de la chaîne de blocs en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à au moins une fonction opérationnelle dans la chaîne de blocs accessible par ledit coffre-fort. Pour ce faire, l’architecture comprend une plateforme 10 de fourniture d’au moins un coffre-fort numérique C(1), C(k), C(n) permettant de participer à une fonction opérationnelle F(1), F(k), F(n) dans la chaîne de blocs, la plateforme centrale 2 comprenant des moyens pour enregistrer la clé publique 9b dans au moins l’un desdits coffres-forts en fonction du statut identifié pour l’utilisateur 1, 1a, 1b, 1c, 1d. La plateforme de coffre-fort numérique 10 peut notamment comprendre des moyens pour créer un coffre-fort numérique C(1), C(k), C(n) sous la forme d’un protocole informatique de type contrat intelligent (pour l’anglais « smart contract »), ledit contrat intelligent étant accessible à l’utilisateur 1, 1a, 1b, 1c, 1d au moyen d’une adresse numérique publique 14. De façon avantageuse, la chaîne de blocs comprend n coffres-forts numériques C(1), C(k), C(n) donnant accès à un ensemble F(1), F(k), F(n) de fonctions opérationnelles, le procédé prévoyant d’enregistrer la clé publique 9b de l’utilisateur 1, 1a, 1b, 1c, 1d dans au moins un de ces coffres C(1), C(k), C(n) en fonction de son niveau d’importance k déterminé. Pour ce faire, la plateforme de coffre-fort 10 comprend n coffres-forts numériques C(1), C(k), C(n) tels que décrits précédemment, les moyens d’enregistrement de la plateforme centrale 2 étant agencés pour enregistrer la clé publique 9b dans au moins un de ces coffres C(1), C(k), C(n) en fonction du niveau d’importance k déterminé pour l’utilisateur 1, 1a, 1b, 1c, 1d. En particulier, pour un utilisateur 1, 1a, 1b, 1c, 1d présent sur le registre 5, le procédé prévoit d’enregistrer la clé publique 9b dans chaque coffre-fort C(1), C(k), afin de pouvoir participer à tous les ensembles F(1), F(k) de fonctions opérationnelles correspondant à son niveau d’importance k. Et, en l’absence des informations d’identité de l’utilisateur 1, 1a, 1b, 1c, 1d dans le registre numérique 5, le procédé prévoit d’enregistrer la clé publique 9b dans un coffre-fort numérique C(1) de participation à des fonctions opérationnelles F(1) standard de l’organisation. Pour ce faire, les moyens d’enregistrement de la plateforme centrale 2 sont agencés pour enregistrer la clé publique 9b dans un tel coffre-fort C(1). En relation avec la figure 2, les utilisateurs 1a, 1b, 1c, dont le statut dans l’organisation présente un niveau d’importance compris entre 2 et n du fait de leur présence sur le registre 5, ont tous accès à k ensembles F(1), F(k) de fonctions opérationnelles dans la chaîne de blocs, k désignant le niveau d’importance le plus bas parmi ceux desdits utilisateurs. En revanche, seulement deux utilisateurs 1a, 1b, du fait de leur niveau d’importance maximal n, ont accès à l’ensemble F(n) regroupant les fonctions opérationnelles les plus importantes, par exemples relatives à la nomination de cadres dirigeants pour l’organisation. Ainsi, les utilisateurs 1a, 1b les plus importants, par exemple le Président Directeur Général (PDG) et le Directeur Général (DG) d’une entreprise, peuvent se connecter à la chaîne de blocs par l’intermédiaire de tous les coffres-forts C(1), C(k), C(n) de la chaîne de blocs, afin de pouvoir participer à tous les ensembles F(1), F(k), F(n) de fonctions opérationnelles disponibles dans ladite chaîne de blocs. De même, le troisième utilisateur 1c, par exemple un membre du Conseil d’Administration de l’entreprise, peut se connecter à la chaîne de blocs uniquement par l’intermédiaire des coffres-forts C(1), C(k), afin de pouvoir participer aux fonctions opérationnelles F(1), F(k) disponibles pour son niveau d’importance k. Enfin, l’utilisateur 1d, dont le statut présente un niveau d’importance minimale 1 du fait de son absence du registre 5, a uniquement accès à un ensemble F(1) de fonctions opérationnelles standard, et ne peut donc se connecter à la chaîne de blocs que par l’intermédiaire du coffre-fort C(1) correspondant. Un coffre-fort C(1), C(k), C(n) peut être programmé pour ne permettre la validation d’une fonction opérationnelle F(1), F(k), F(n) qu’en cas d’accord d’un certain nombre d’utilisateurs 1, 1a, 1b, 1c, 1d dudit coffre-fort. Ainsi, on garantit une sécurité optimale quant au consentement des participants éligibles pour les fonctions opérationnelles les plus importantes, par exemple les sessions de vote du Conseil d’Administration d’une entreprise. En particulier, chaque clé publique 9b peut être enregistrée dans la plateforme 10 avec un niveau de sécurité qui correspond au niveau d’importance k de son utilisateur 1, 1a, 1b, 1c, 1d, le risque d’utilisation frauduleuse de ladite clé publique étant d’autant plus réduit que son niveau de sécurité est élevé. A titre d’exemple, le risque d’utilisation frauduleuse d’une clé publique 9b peut être représenté par une valeur numérique comprise entre 0 et 1. Ainsi, on garantit un risque d’infraction réduit durant chaque fonction opérationnelle F(1), F(k), F(n) réalisée au moyen de la chaîne de blocs, dans la mesure où un tel risque, qui peut être calculé en faisant le produit des risques d’utilisation frauduleuse des clés 9b de chaque participant et du risque d’utilisation frauduleuse de la plateforme 2, présentera toujours une valeur inférieure à celle du risque le plus faible parmi ceux desdits participants et de ladite plateforme. Par exemple, si la plateforme 2 présente un risque d’utilisation frauduleuse moyen et que, parmi les participants, le niveau de risque le plus faible est également moyen, alors le risque d’infraction durant l’accomplissement de la fonction opérationnelle F(1), F(k), F(n) sera moyen. De même, si la plateforme 2 présente un risque d’utilisation frauduleuse minimal et que, parmi les participants, le niveau de risque le plus faible est également minimal, alors le risque d’infraction durant l’accomplissement de la fonction opérationnelle F(1), F(k), F(n) sera minimal. En outre, compte tenu du principe mathématique évoqué précédemment, il est également possible d’obtenir un risque d’infraction minimal avec des participants présentant des valeurs de risque moyennes et/ou plus importantes. En relation avec la figure 1, après la création des clés 9a, 9b et la détermination du niveau d’importance k de l’utilisateur 1, 1a, 1b, 1c, 1d, la plateforme centrale 2 envoie à la plateforme 10 un message 11 comprenant la clé publique 9b dudit utilisateur, afin de permettre à la plateforme 10 de l’enregistrer dans le(s) coffre(s)-fort(s) C(1), C(k), C(n) correspondant(s). Le procédé peut également prévoir de communiquer à l’utilisateur 1, 1a, 1b, 1c, 1d un lien d’accès au coffre-fort C(1), C(k), C(n), notamment l’adresse numérique 14 dudit coffre-fort, en parallèle de l’enregistrement de sa clé publique 9b. Pour ce faire, la plateforme centrale 2 comprend des moyens pour effectuer une telle communication, par exemple en envoyant au terminal 3 un message 12 comprenant un tel lien 14. Le lien 14 peut être agencé pour permettre, lorsqu’un utilisateur 1, 1a, 1b, 1c, 1d l’active, l’affichage sur le terminal 3 dudit utilisateur d’une interface utilisateur lui permettant d’envoyer sa clé publique 9b à la plateforme 10, notamment par l’intermédiaire d’un message 13, afin d’accéder au coffre-fort C(1), C(k), C(n) correspondant à la fonction opérationnelle F(1), F(k), F(n) à laquelle il souhaite participer. Procédé pour permettre à un utilisateur (1, 1a, 1b, 1c, 1d) d’accéder à une chaîne de blocs d’une organisation, ledit procédé prévoyant de : créer une paire de clés privée (9a) et publique (9b) pour permettre audit utilisateur d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs ; collecter des données personnelles de l’utilisateur (1, 1a, 1b, 1c, 1d), lesdites données comprenant au moins une information sur l’identité de l’utilisateur (1, 1a, 1b, 1c, 1d) et une information sur ladite organisation ; vérifier la validité desdites données personnelles ; identifier un statut dudit utilisateur au sein de ladite organisation au moyen desdites données vérifiées ; enregistrer la clé publique (9b) dans au moins un coffre-fort numérique (C(1), C(k), C(n)) de la chaîne de blocs en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à au moins une fonction opérationnelle (F(1), F(k), F(n)) dans ladite chaîne de blocs accessible par ledit coffre-fort. Procédé selon la revendication 1, caractérisé en ce qu’il prévoit d’identifier le statut de l’utilisateur (1, 1a, 1b, 1c, 1d) en vérifiant la présence de l’information d’identité collectée dans un registre numérique légal (5) des dirigeants de l’organisation, ledit registre étant sélectionné au moyen de l’information collectée sur ladite organisation. Procédé selon la revendication 2, caractérisé en ce les informations d’identité des dirigeants de l’organisation sont enregistrées dans le registre numérique (5) suivant n catégories, n étant un entier naturel supérieur ou égal à 2, le procédé prévoyant d’identifier le statut de l’utilisateur (1, 1a, 1b, 1c, 1d) en déterminant son niveau d’importance k, k étant un entier naturel compris entre 1 et n, en fonction de l’éventuelle catégorie avec laquelle son information d’identité est enregistrée dans ledit registre. Procédé selon la revendication 3, caractérisé en ce que la chaîne de blocs comprend n coffres-forts numériques (C(1), C(k), C(n)) donnant accès à un ensemble (F(1), F(k), F(n)) de fonctions opérationnelles, le procédé prévoyant d’enregistrer la clé publique (9b) de l’utilisateur dans au moins un de ces coffres C(1), C(k), C(n) en fonction de son niveau d’importance k déterminé. Procédé selon la revendication 4, caractérisé en ce qu’il prévoit, en l’absence des informations d’identité de l’utilisateur (1, 1a, 1b, 1c, 1d) dans le registre numérique (5), d’enregistrer la clé publique (9b) dudit utilisateur dans un coffre-fort numérique (C(1)) de participation à des fonctions opérationnelles (F(1)) standard de l’organisation. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce qu’il prévoit de communiquer à l’utilisateur (1, 1a, 1b, 1c, 1d) un lien (14) d’accès au coffre-fort (C(1), C(k), C(n)) en parallèle de l’enregistrement de sa clé publique (9b) dans ledit coffre-fort. Architecture pour permettre à un utilisateur d’accéder à une chaîne de blocs d’une organisation, ladite architecture comprenant : une application installée sur un terminal dudit utilisateur, ladite application comprenant des moyens pour créer une paire de clés privée (9a) et publique (9b) pour permettre audit utilisateur d’effectuer des signatures cryptographiques durant une participation à une fonction opérationnelle dans la chaîne de blocs ; une plateforme (10) de fourniture d’au moins un coffre-fort numérique (C(1), C(k), C(n)) permettant de participer à une fonction opérationnelle (F(1), F(k), F(n)) dans ladite chaîne de blocs ; une plateforme centrale (2) comprenant : des moyens pour collecter la clé publique (9b) ; des moyens pour collecter des données personnelles d’un utilisateur (1, 1a, 1b, 1c, 1d), lesdites données comprenant au moins une information sur l’identité de l’utilisateur (1, 1a, 1b, 1c, 1d) et une information sur ladite organisation ; des moyens pour vérifier la validité desdites données personnelles ; des moyens pour identifier un statut dudit utilisateur au sein de ladite organisation au moyen desdites données vérifiées ; des moyens pour enregistrer la clé publique (9b) dans au moins un coffre-fort numérique (C(1), C(k), C(n)) en fonction dudit statut identifié, afin de permettre audit utilisateur de participer à au moins une fonction opérationnelle (F(1), F(k), F(n)) dans ladite chaîne de blocs accessible par ledit coffre-fort. Architecture selon la revendication 7, caractérisée en ce que les moyens d’identification sont agencés pour interagir avec une plateforme (6) de fourniture de registres numériques légaux de plusieurs organisations pour : sélectionner le registre numérique (5) des dirigeants de l’organisation au moyen de l’information collectée sur ladite organisation ; et vérifier la présence dans ledit registre de l’information d’identité collectée. Architecture selon la revendication 8, caractérisée en ce les informations d’identité des dirigeants de l’organisation sont enregistrées dans le registre numérique (5) suivant n catégories, n étant un entier naturel supérieur ou égal à 2, les moyens d’identification étant agencés pour identifier le statut de l’utilisateur (1, 1a, 1b, 1c, 1d) en déterminant son niveau d’importance k, k étant un entier naturel compris entre 1 et n, en fonction de l’éventuelle catégorie avec laquelle son information d’identité est enregistrée dans ledit registre. Architecture selon la revendication 9, caractérisée en ce que la plateforme de coffre-fort (10) comprend n coffres-forts numériques (C(1), C(k), C(n)) donnant accès à un ensemble (F(1), F(k), F(n)) de fonctions opérationnelles, les moyens d’enregistrement étant agencés pour enregistrer la clé publique (9, 9a, 9b, 9c) de l’utilisateur (1, 1a, 1b, 1c, 1d) dans au moins un de ces coffres (C(1), C(k), C(n)) en fonction de son niveau d’importance k déterminé. Architecture selon la revendication 10, caractérisée en ce que les moyens d’enregistrement sont agencés pour, en l’absence des informations d’identité de l’utilisateur (1, 1a, 1b, 1c, 1d) dans le registre numérique (5), enregistrer la clé publique (9b) dudit utilisateur un coffre-fort numérique (C(1)) de participation à des fonctions opérationnelles (F(1)) standard de l’organisation. Architecture selon l’une quelconque des revendications 7 à 11, caractérisée en ce que la plateforme centrale (2) comprend des moyens pour communiquer à l’utilisateur (1, 1a, 1b, 1c, 1d) un lien (14) d’accès au coffre-fort (C(1), C(k), C(n)) en parallèle de l’enregistrement de sa clé publique (9b).