FR 3159844 A1 20250905 FR 2402054 A 20240229 L’invention concerne un procédé qui prévoit : l’enregistrement par un utilisateur (1), dans un coffre-fort d’échanges (35), de listes (n, m) comprenant chacune l’identifiant d’au moins un jeton non-fongible qu’il souhaite respectivement échanger et acquérir, associé à l’adresse numérique (39a, 40) du coffre-fort (10a, 11) de gestion dudit jeton ; l’envoi des listes (m, n) et de l’adresse (36) du coffre-fort d’échanges (35) au coffre-fort (11) de gestion du jeton non-fongible souhaité ; l’approbation de l’échange par l’utilisateur (2) possédant le jeton souhaité, en associant à son identifiant unique l’adresse (36) du coffre-fort d’échanges (35) et un statut d’autorisation d’échange, et en envoyant une notification (52) au coffre-fort d’échanges (35), le coffre-fort d’échanges (35) enregistrant, dans le coffre-fort (10a, 11) correspondant, l’utilisateur (1) en tant que nouveau propriétaire du jeton obtenu par l’échange et l’utilisateur (2) en tant que nouveau propriétaire du jeton échangé avec le premier utilisateur (1). Figure 1b Procédé d’échanges de jetons non-fongibles sur une chaîne de blocs L’invention concerne un procédé pour permettre à deux utilisateurs d’échanger des jetons non-fongibles sur une chaîne de blocs, ainsi qu’une architecture comprenant des moyens pour mettre en œuvre un tel procédé. Les jetons non-fongibles correspondent à des représentations numériques de bien 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, ou encore des éléments mixtes, notamment des objets connectés à Internet® (IoT, pour l’anglais « Internet of Things »). 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é. Les architectures connues d’échange de biens et de jetons non-fongibles sur une chaîne de blocs reposent généralement sur des plateformes de commerce en ligne, ce qui représente un risque de fraude non négligeable. En particulier, elles ne donnent pas entière satisfaction tant pour la protection du créateur des biens vendus que pour leurs acheteurs, qui ne disposent pas de garantie suffisante quant à l’identité dudit créateur, l’authenticité des œuvres vendues, ni l’honnêteté des parties intermédiaires d’une vente. Par ailleurs, avec les solutions existantes, les utilisateurs acquièrent des jetons non-fongibles en versant un montant en monnaie fiduciaire ou cryptographique directement à leur propriétaire et, dans la mesure où ces transactions sont inscrites sur la chaîne de blocs, ce montant peut être lu par des utilisateurs autres que les parties à la transaction initiale, d’autant plus lorsque ladite chaîne de blocs est publique. Ainsi, un problème se pose par rapport à la confidentialité de cette transaction, dont l’acheteur et/ou le vendeur peut souhaiter que le montant reste secret pour préserver leur vie privée ou la confidentialité de leurs activités professionnelles. L’invention vise à perfectionner l’art antérieur en proposant notamment un procédé pour permettre à des utilisateurs d’échanger des jetons non-fongibles sur une chaîne de blocs via un système intégré de vente qui permet de s’affranchir des plateformes de commerce en ligne classiques, ledit système permettant en outre de réaliser ces échanges en évitant les transferts directs de monnaie fiduciaire ou cryptographique entre lesdits utilisateurs, tout en simplifiant le suivi desdits échanges dans le cas où ils concernent plusieurs jetons non-fongibles à la fois. A cet effet, selon un premier aspect, l’invention propose un procédé pour permettre à deux utilisateurs d’échanger des jetons non-fongibles sur une chaîne de blocs, ledit procédé prévoyant au préalable : lors de la création d’un jeton non-fongible, l’enregistrement d’une information liée audit jeton non-fongible dans un coffre-fort numérique de gestion de jetons sur la chaîne de blocs, en l’associant à un identifiant unique pour ledit jeton non-fongible ; lorsqu’un utilisateur acquiert un jeton non-fongible, l’enregistrement, dans le coffre-fort numérique de gestion dudit jeton non-fongible, d’une adresse numérique dudit utilisateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible ; ledit procédé prévoyant en outre, lorsqu’un premier utilisateur souhaite échanger des jetons non-fongibles avec un second utilisateur sur la chaîne de blocs : la sélection par le premier utilisateur d’au moins un jeton non-fongible à échanger, parmi les jetons non-fongibles qu’il possède sur la chaîne de blocs, en associant à l’identifiant unique dudit jeton non-fongible à échanger, enregistré dans le coffre-fort numérique de gestion correspondant : une adresse numérique d’un coffre-fort numérique présent sur la chaîne de blocs pour gérer les échanges de jetons non-fongibles entre utilisateurs sur ladite chaine de blocs ; un statut d’autorisation d’échange dudit jeton non-fongible ; l’enregistrement par le premier utilisateur, dans le coffre-fort d’échanges, d’une proposition d’échange comprenant : une première liste m comprenant l’identifiant unique d’au moins un jeton non-fongible qu’il souhaite échanger, associé à l’adresse numérique du coffre-fort de gestion dudit jeton non-fongible à échanger ; une seconde liste n comprenant l’identifiant unique d’au moins un jeton non-fongible du second utilisateur que ledit premier utilisateur souhaite acquérir via ledit échange, associé à l’adresse numérique du coffre-fort de gestion dudit jeton non-fongible souhaité ; l’envoi par le premier utilisateur, au coffre-fort de gestion du jeton non-fongible souhaité, d’une notification comprenant les listes m, n, ainsi que l’adresse numérique du coffre-fort d’échanges ; la vérification par le second utilisateur de la proposition d’échange enregistrée dans le coffre-fort d’échanges ; la vérification par le second utilisateur dans le coffre-fort de gestion du jeton non-fongible à échanger : du statut d’autorisation d’échange enregistré pour ledit jeton non-fongible à échanger ; de l’association de l’adresse numérique du coffre-fort d’échanges à l’identifiant unique dudit jeton non-fongible à échanger ; en cas de succès de ces vérifications, l’approbation par le second utilisateur de cette proposition d’échange : en associant à l’identifiant unique du jeton non-fongible souhaité, enregistré dans le coffre-fort de gestion correspondant : l’adresse numérique du coffre-fort d’échanges ; un statut d’autorisation d’échange dudit jeton non-fongible souhaité ; en envoyant au coffre-fort d’échanges une notification d’approbation de ladite proposition d’échange ; l’enregistrement, par le coffre-fort d’échanges, de : l’adresse numérique du premier utilisateur dans le coffre-fort numérique de gestion du jeton non-fongible obtenu du second utilisateur, en l’associant à l’identifiant unique dudit jeton non-fongible obtenu, afin de désigner ledit premier utilisateur comme nouveau propriétaire dudit jeton non-fongible obtenu ; l’adresse numérique du second utilisateur dans le coffre-fort numérique de gestion du jeton non-fongible échangé avec le premier utilisateur, en l’associant à l’identifiant unique dudit jeton non-fongible échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. Selon un second aspect, l’invention propose une architecture pour permettre à deux utilisateurs d’échanger des jetons non-fongibles sur une chaîne de blocs, ladite architecture comprenant : au moins un coffre-fort numérique de gestion de jetons non-fongibles sur la chaîne de blocs, dans lequel sont enregistrés : lors de la création d’un jeton non-fongible, une information liée audit jeton non-fongible, en étant associée à un identifiant unique pour ledit jeton non-fongible ; lorsqu’un utilisateur acquiert un jeton non-fongible géré au moyen dudit coffre-fort de gestion de jetons, une adresse numérique dudit utilisateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible ; un coffre-fort numérique pour gérer les échanges de jetons non-fongibles entre utilisateurs sur ladite chaine de blocs ; un premier terminal comprenant des moyens pour permettre à un premier utilisateur souhaitant échanger des jetons non-fongibles avec un second utilisateur sur la chaîne de blocs de : sélectionner au moins un jeton non-fongible à échanger, parmi les jetons non-fongibles qu’il possède sur la chaîne de blocs, en associant à l’identifiant unique dudit jeton non-fongible à échanger, enregistré dans le coffre-fort numérique de gestion correspondant : une adresse numérique sur la chaîne de blocs du coffre-fort numérique d'échanges de jetons non-fongibles ; un statut d’autorisation d’échange dudit jeton non-fongible ; enregistrer dans le coffre-fort d’échanges une proposition d’échange comprenant : une première liste m comprenant l’identifiant unique d’au moins un jeton non-fongible qu’il souhaite échanger, associé à l’adresse numérique du coffre-fort de gestion dudit jeton non-fongible à échanger ; une seconde liste n comprenant l’identifiant unique d’au moins un jeton non-fongible du second utilisateur que ledit premier utilisateur souhaite acquérir via ledit échange, associé à l’adresse numérique du coffre-fort de gestion dudit jeton non-fongible souhaité ; envoyer, au coffre-fort de gestion du jeton non-fongible souhaité, une notification comprenant les listes m, n, ainsi que l’adresse numérique du coffre-fort d’échanges ; un second terminal comprenant des moyens pour permettre au second utilisateur de : vérifier la proposition d’échange enregistrée dans le coffre-fort d’échanges ; vérifier, dans le coffre-fort de gestion du jeton non-fongible à échanger : le statut d’autorisation d’échange enregistré pour ledit jeton non-fongible à échanger ; l’association de l’adresse numérique du coffre-fort d’échanges à l’identifiant unique dudit jeton non-fongible à échanger ; en cas de succès de ces vérifications, approuver cette proposition d’échange : en associant à l’identifiant unique du jeton non-fongible souhaité, enregistré dans le coffre-fort de gestion correspondant : l’adresse numérique du coffre-fort d’échanges ; un statut d’autorisation d’échange dudit jeton non-fongible souhaité ; en envoyant au coffre-fort d’échanges une notification d’approbation de ladite proposition d’échange ; le coffre-fort d’échanges comprenant des moyens pour enregistrer, à l’issue de cet échange : l’adresse numérique du premier utilisateur dans le coffre-fort numérique de gestion du jeton non-fongible obtenu du second utilisateur, en l’associant à l’identifiant unique dudit jeton non-fongible obtenu, afin de désigner ledit premier utilisateur comme nouveau propriétaire dudit jeton non-fongible obtenu ; l’adresse numérique du second utilisateur dans le coffre-fort numérique de gestion du jeton non-fongible échangé avec le premier utilisateur, en l’associant à l’identifiant unique dudit jeton non-fongible échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. 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 et FIG. 1 représentent schématiquement les différentes étapes d’échanges de jetons non-fongibles entre deux utilisateurs sur une chaîne de blocs, du point de vue respectivement d’un premier utilisateur émettant une proposition d’échange ( FIG. 1 ) et d’un second utilisateur acceptant cette proposition d’échange ( FIG. 1 ), suivant un procédé selon l’invention ; FIG. 2 , FIG. 2 et FIG. 2 représentent schématiquement les différentes étapes pour permettre au premier utilisateur d’acheter un bon d’achat numérique sous forme de jeton non-fongible à échanger ultérieurement avec un second utilisateur, selon respectivement une variante de réalisation de l’invention ; FIG. 3 et FIG. 3 représentent schématiquement les différentes étapes d’échanges de jetons non-fongibles, dont un bon d’achat numérique, entre deux utilisateurs sur une chaîne de blocs, du point de vue respectivement d’un premier utilisateur émettant une proposition d’échange contenant un bon d’achat numérique ( FIG. 3 ) et d’un second utilisateur acceptant cette proposition d’échange ( FIG. 3 ), suivant un procédé selon l’invention ; FIG. 4 représente schématiquement les étapes permettant au second utilisateur de vérifier la valeur monétaire d’un bon d’achat numérique que le premier utilisateur propose de lui échanger, selon un mode de réalisation de l’invention ; FIG. 5 représente schématiquement les étapes permettant au second utilisateur d’obtenir un remboursement monétaire à partir du bon d’achat numérique échangé avec le premier utilisateur dans les figures précédentes, selon un mode de réalisation de l’invention. En relation avec ces figures, on décrit ci-dessous un procédé pour permettre à deux utilisateurs 1, 2 d’échanger des jetons non-fongibles sur une chaîne de blocs, ainsi qu’une architecture comprenant des moyens techniques pour permettre la mise en œuvre d’un tel procédé. 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 et d’utilisateurs 1, 2 connectés à 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 un premier 4 et un second terminal 5 équipés chacun de moyens pour permettre à respectivement un premier 1 et un second utilisateur 2 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, les terminaux 4, 5 peuvent être des téléphones portables de type « intelligent » (pour l’anglais « smartphone »). Les terminaux 4, 5 peuvent é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és 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 chaque utilisateur 1, 2 peut télécharger pour l’installer sur son terminal 4, 5, notamment en envoyant une requête adaptée à ladite architecture. Pour pouvoir interagir avec la chaîne de blocs, chaque utilisateur 1, 2 doit générer une paire de clés privée et publique (non représentées), 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 est tenue secrète par son propriétaire (premier 1 ou second utilisateur 2) et la clé publique 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 pour représenter son propriétaire 1, 2 sur la chaîne de blocs. Pour générer de telles clés, l'utilisateur 1, 2 peut lancer une procédure adaptée sur son terminal 4, 5 notamment au moyen de l’application décrite précédemment. Les clés sont ainsi liées au terminal 4, 5 au sein duquel elles sont générées sous le contrôle de l'utilisateur 1, 2, qui n’utilise que la clé publique. De ce fait, la clé privée ne quitte jamais le terminal 4, 5, ce qui garantit à son propriétaire 1, 2 une sécurité optimale. Pour finaliser ou mettre à jour son adhésion à la chaîne de blocs, l’utilisateur 1, 2 enregistre sa clé publique sur ladite chaîne de blocs. En particulier, l’utilisateur 1, 2 peut effectuer cet enregistrement en associant sa clé publique à une empreinte numérique liée à l’identité dudit utilisateur. Pour ce faire, l’utilisateur 1, 2 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 liée au terminal 4, 5 dudit utilisateur. 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 l’utilisateur 1, 2 un identifiant unique, notamment basé sur les données d’identité. Cet enregistrement peut notamment être effectué dans un coffre-fort numérique personnel 6, 7 détenu par l’utilisateur 1, 2 sur la chaîne de blocs, comme représenté sur les figures, en relation avec les clés liées au terminal 4, 5 dudit utilisateur. L’utilisateur 1, 2 peut créer un tel coffre-fort personnel 6, 7 pour pouvoir interagir ultérieurement avec la chaîne de blocs uniquement au moyen de l’adresse numérique 8, 9 dudit coffre-fort personnel, ce qui permet audit utilisateur d’enregistrer plusieurs clés publiques dans un même coffre-fort personnel 6, 7 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 et/ou de son terminal 4, 5. Pour ce faire, l’architecture comprend une plateforme pour le déploiement de coffres-forts sur la chaîne de blocs, le terminal 4, 5 et/ou l’application comprenant des moyens pour solliciter ladite plateforme de déploiement pour créer un coffre-fort personnel 6, 7, notamment par l’envoi d’une requête adaptée (non représentée). De façon avantageuse, 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 6, 7 sur requête de tout utilisateur 1, 2 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 1, 2. A cet effet, l’architecture peut comprendre (non représentés sur les figures) : un coffre-fort numérique 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 d’accès de ladite plateforme à ladite chaîne de blocs ; un coffre-fort numérique central, 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 du coffre-fort 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 une entrée comprenant l’adresse 8, 9 du coffre-fort personnel 6, 7 de l’utilisateur 1, 2, associé à l’adresse numérique du coffre-fort lié à la plateforme 3. 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 utilisateur 1, 2. Après création de son coffre-fort numérique personnel 6, 7, l’utilisateur 1, 2 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 à l’utilisateur 1, 2 une notification contenant l’adresse numérique publique 8, 9 de son coffre-fort personnel 6, 7, afin que ledit utilisateur puisse accéder audit coffre-fort personnel au moyen de ladite adresse numérique. Pour permettre aux utilisateurs 1, 2 d’échanger des jetons non-fongibles sur la chaîne de blocs, le procédé prévoit au préalable, lors de la création d’un jeton non-fongible sur ladite chaîne de blocs, l’enregistrement d’une information liée audit jeton non-fongible dans un coffre-fort numérique 10a, 10b, 11 de gestion de jetons sur ladite chaîne de blocs, en l’associant à un identifiant unique i, j pour ledit jeton non-fongible. Pour ce faire, l’architecture comprend au moins un coffre-fort numérique 10a, 10b, 11 de gestion de jetons non-fongibles sur une chaîne de blocs, dans lequel est enregistrée, lors de la création d’un jeton non-fongible sur la chaîne de blocs, une information liée audit jeton non-fongible, en étant associée à un identifiant unique i, j tel que défini ci-dessus. Les jetons non-fongibles peuvent 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, qui peuvent être par exemple : des objets physiques, tels que par exemple des œuvres d’art ou des biens immobiliers ; ou des éléments numériques, tels que par exemple des images ou des photographies ; ou des éléments mixtes, notamment des objets connectés à Internet® (IoT, pour l’anglais « Internet of Things »). En particulier, un utilisateur souhaitant créer de tels jetons non-fongible sur la chaîne de blocs peut requérir la création d’un coffre-fort numérique 10a, 11 spécifique pour lui, en tant que créateur de jetons non-fongibles sur ladite chaîne de blocs, afin de lui permettre de gérer ses créations au moyen dudit coffre-fort numérique. Pour ce faire, comme expliqué précédemment en lien avec les coffres-forts personnels 6, 7, un utilisateur « créateur » peut, grâce des moyens ou une application adapté(e)(s) installé(e)(s) sur son terminal d’accès à la chaîne de blocs, solliciter une plateforme de déploiement présente sur ladite chaîne de blocs, notamment la plateforme 3 représentée sur les figures, afin de créer un tel coffre-fort numérique 10a, 11 pour la gestion de ses jetons non-fongibles. De façon avantageuse, la plateforme 3 crée un tel coffre-fort 10a, 11 de gestion sous la forme d’un contrat intelligent avec des fonctionnalités adaptées pour permettre à un utilisateur « créateur » de gérer facilement ses jetons non-fongibles, parmi lesquelles : un suivi des mises à jour des caractéristiques de ses jetons non-fongibles, afin de fournir audit utilisateur « créateur » une meilleure visibilité desdites mises à jour ; la possibilité de vendre ou d’échanger ses jetons non-fongibles avec d’autres utilisateurs de la chaîne de blocs en établissant une relation directe « de pair à pair » (pour l’anglais « peer to peer »), sans recourir à une plateforme de commerce en ligne intermédiaire ; un suivi de la logistique des biens correspondant aux jetons non-fongibles. En particulier, l’architecture peut comprendre un serveur répertoire (non représenté sur les figures), qui comprend au moins une base de données pour y enregistrer des fichiers numériques liés à des jetons non-fongibles d’au moins un utilisateur « créateur » sur la chaîne de blocs, lesdits fichiers pouvant être par exemple des images ou des photographies représentant un bien « matériel » auquel correspond un jeton non-fongible. Par ailleurs, lors de la création d’un coffre-fort numérique 10a, 11 pour gérer les jetons non-fongibles d’un utilisateur « créateur », la plateforme 3 peut enregistrer dans ledit coffre-fort de gestion, notamment parmi des variables immuables dudit coffre-fort de gestion : une adresse numérique sur la chaîne de blocs du serveur répertoire, afin de permettre audit utilisateur « créateur » de gérer ses jetons non-fongibles au moyen dudit serveur répertoire et de son coffre-fort de gestion 10a, 11 ; éventuellement, une adresse numérique alternative d’accès au serveur répertoire sur la chaine de blocs, notamment en cas de défaillance de l’adresse principale dudit serveur répertoire. Ces adresses numériques peuvent se présenter sous la forme de liens interactifs alphanumériques de type URI (pour l’anglais « Uniform Resource Identifier »), et ne peuvent pas être modifiées, car elles permettent de certifier l’identité du créateur initial d’un jeton non-fongible référencé dans le serveur, et ce même après la session dudit jeton non-fongible à un autre utilisateur 1, 2 de la chaîne de blocs. Par ailleurs, chaque coffre-fort 10a, 11 de gestion de jetons non-fongibles lié à un utilisateur « créateur » contient, dans sa liste de paramètres immuables, l’adresse numérique du coffre-fort numérique personnel dudit utilisateur « créateur » sur la chaîne de blocs, en tant que propriétaire dudit coffre-fort de gestion. Lors de la création d’un jeton non-fongible de type « bien » tel que mentionné ci-dessus, le procédé prévoit, grâce à des moyens ou une application adapté(e)(s) installé(e)(s) sur le terminal de son créateur, de : calculer un arbre de hachage, par exemple un arbre de Merkle (pour l’anglais « Merkle tree ») à partir du jeton non-fongible lui-même ou d’un fichier numérique lié audit jeton non-fongible, par exemple une photographie ou une image électronique dudit jeton non-fongible s’il s’agit d’un bien matériel ; enregistrer cet arbre de hachage dans le coffre-fort 10a, 11 de gestion appartenant audit créateur, en tant qu’information liée audit jeton non-fongible, en l’associant à un identifiant unique i, j pour ledit jeton non-fongible. Par ailleurs, d’autres informations sur le jeton non-fongible peuvent être enregistrées par l’utilisateur « créateur » dans le coffre-fort de gestion 10a, 11, au moment de la création dudit jeton non-fongible ou ultérieurement, parmi lesquelles : un statut pour autoriser la vente et/ou l’échange dudit jeton non-fongible ; et/ou dans le cas d’une vente dudit jeton contre un montant en cryptomonnaie ou en monnaie fiduciaire, une information liée à la rétribution à verser audit utilisateur « créateur », notamment : dans le cas d’une première vente effectuée par l’utilisateur « créateur » lui-même avec un autre utilisateur 1, 2 : un montant monétaire à verser audit utilisateur « créateur » ; ou dans le cas d’une vente ultérieure effectuée par un utilisateur 1, 2 autre que ledit « créateur » à un autre utilisateur 2, 1 : une valeur rationnelle de rétribution à verser audit « créateur », déduite du montant monétaire total fixé par l’utilisateur 1, 2 revendeur dudit jeton non-fongible. Le procédé prévoit en outre, lorsqu’un utilisateur 1, 2 acquiert un jeton non-fongible, l’enregistrement, dans le coffre-fort numérique 10a, 11 de gestion dudit jeton non-fongible, d’une adresse numérique 8, 9 dudit utilisateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible. Dans le cas où l’utilisateur est le créateur du jeton non-fongible, il est considéré que ledit utilisateur acquiert ledit jeton non-fongible au moment de sa création, et l’adresse numérique du coffre-fort personnel dudit créateur est enregistrée dans le coffre-fort 10a, 11 de gestion lié audit créateur, en étant associée à l’identifiant unique dudit jeton non-fongible pour en désigner ledit créateur comme propriétaire. Dans le cas où l’utilisateur 1, 2 n’est pas le créateur du jeton non-fongible, le procédé prévoit d’enregistrer l’adresse numérique 8, 9 du coffre-fort personnel 6, 7 dudit utilisateur dans le coffre-fort de gestion 10a, 11 dudit jeton au moment de la cession dudit jeton par son créateur audit utilisateur, en associant ladite adresse numérique à l’identifiant unique dudit jeton, afin de désigner ledit utilisateur comme nouveau propriétaire dudit jeton. Les jetons non-fongibles peuvent également se présenter sous forme de bons d’achat numériques, qu’un premier utilisateur 1 peut acheter au préalable pour l’échanger ultérieurement avec un second utilisateur 2 sur la chaîne de blocs. Pour ce faire, comme représenté sur les figures 2a à 2c, 3a, 3b, 4 et 5, l’architecture comprend un serveur 12 lié à la chaîne de blocs pour la fourniture de tels bons d’achats aux utilisateurs 1, 2 de ladite chaîne de blocs. Dans ce cas, le serveur 12 est assimilable à un « créateur » de jetons non-fongibles sur la chaîne de blocs, et peut disposer à ce titre de : un coffre-fort numérique 14 « personnel » qui lui est lié, dans lequel peut être enregistrée une clé publique 13b représentant ledit serveur 12 sur la chaîne de blocs, et liée à une clé privée 13a de signature cryptographique qui est enregistrée et tenue secrète au sein d’une mémoire dans ledit serveur ; un coffre-fort numérique 10b pour la gestion des jetons non-fongibles de type « bons d’achat numériques » qu’il crée pour des utilisateurs 1, 2 sur la chaîne de blocs, en réponse à des requêtes envoyées par lesdits utilisateurs, et dans lequel est enregistrée la clé publique 13b dudit serveur (comme représenté) et/ou l’adresse numérique 15 de son coffre-fort « personnel » 14 sur la chaîne de blocs. Pour réaliser l’achat d’un tel jeton non-fongible / bon d’achat numérique, le procédé prévoit en premier lieu l’envoi par le premier utilisateur 1 d’une requête 16 au serveur 12 de fourniture de bons d’achats numériques, ladite requête comprenant une information sur un montant monétaire que ledit premier utilisateur souhaite attribuer audit bon d’achat numérique. En particulier, le serveur 12 est sous le contrôle d’un organisme habilité à recevoir, conserver et envoyer de la monnaie numérique. Pour ce faire, comme représenté sur les figures 2a à 2c, le premier terminal 4 comprend des moyens, notamment sous la forme d’une interface de programmation 22 (API) intégrée audit terminal ou à l’application qui y est installée, pour permettre au premier utilisateur 1 d’effectuer un tel achat, en envoyant d’abord une requête 16 telle que mentionnée ci-dessus. En particulier, cette requête comprend non seulement une information sur le montant monétaire à attribuer au bon d’achat numérique demandé, mais également l’adresse numérique 8 du coffre-fort personnel 6 du premier utilisateur 1 sur la chaîne de blocs. Après envoi de la requête 16, et sa bonne réception par le serveur 12 grâce à des moyens adaptés implantés dans ledit serveur, le procédé prévoit : la création par le serveur 12 d’un bon d’achat numérique correspondant aux besoins de l’utilisateur 1, dans le coffre-fort numérique 10b attribué audit serveur sur la chaîne de blocs pour gérer les bons d’achats qu’il crée, en lui attribuant un identifiant unique j et une valeur monétaire correspondant à l’information de montant communiquée dans la requête 16 ; l’envoi par le premier utilisateur 1 du montant monétaire requis, correspondant à l’information communiquée dans la requête 16, à un serveur de paiement 17 lié à la chaîne de blocs ; l’enregistrement par le serveur 12 de bons d’achat, dans le coffre-fort 10b de gestion de bons d’achats, de l’adresse numérique 8 dudit premier utilisateur sur la chaîne de blocs, en tant que propriétaire dudit bon d’achat. Pour ce faire, le serveur 12 comprend des moyens pour, à la réception de la requête 16, envoyer à son coffre-fort 10b de gestion une notification 18 pour y créer le bon d’achat requis par le premier utilisateur 1, en lui attribuant l’identifiant unique j et la valeur monétaire susmentionnés. En particulier, à la création du bon d’achat, le serveur 12 lui associe dans le coffre-fort 10b l’adresse numérique 15 de son coffre-fort « personnel » 14 sur la chaîne de blocs, en tant que propriétaire provisoire dudit bon d’achat, en attendant le versement du montant monétaire requis par le premier utilisateur 1. De façon avantageuse, le serveur 12 comprend des interfaces de programmation (API) certifiées, notamment téléchargeables depuis la plateforme 3, pour pouvoir effectuer toutes les opérations nécessaires à la fourniture de bons d’achats aux utilisateurs 1, 2 qui en font la demande sur la chaîne de blocs. Ainsi, on prévient les risques de vol d’un bon d’achat par un utilisateur autre que celui ayant requis sa création. En particulier, après création du bon d’achat, le serveur 12 inscrit dans le coffre-fort 10b de gestion, en l’associant à l’identifiant unique j dudit bon d’achat, l’adresse numérique 8 du premier utilisateur 1, en tant que personne autorisée à consulter les informations relatives audit bon d’achat dans le coffre-fort 10b, afin de pouvoir les vérifier avant de verser le montant monétaire requis. Sur les figures 2a et 2b, l’architecture comprend un serveur de paiement 17 qui est distinct du serveur 12 de fourniture de bons d’achat, le premier utilisateur 1 envoyant le montant monétaire requis au serveur de paiement 17, au moyen d’une carte de paiement ( FIG. 2 ) ou d’un virement bancaire ( FIG. 2 ). Lors d’un paiement par carte ( FIG. 2 ), après réception de la requête 16, le serveur 12 de bons d’achat envoie au serveur de paiement 17 une requête 19 en connexion, notamment au moyen d’une adresse numérique communiquée dans la requête 16 pour accéder audit serveur de paiement, et le serveur de paiement 17 y répond par une notification 20 contenant un lien et/ou un numéro d’identification de paiement pour la transaction en cours. A la réception de la notification 20, le serveur 12, après avoir créé le bon d’achat requis dans le coffre-fort 10b (via la notification 18), envoie sur le premier terminal 4 une notification 21 contenant : le lien de paiement auprès du serveur 17 ; une empreinte de hachage du bon d’achat créé dans le coffre-fort 10b en réponse à la requête 16 du premier utilisateur 1 ; une information sur le montant monétaire requis, qui correspond à l’information de montant communiquée dans la requête 16. A partir de cette notification 21, le premier terminal 4, notamment via l’interface de programmation 22 qui y est installée, se connecte au coffre-fort 10b pour pouvoir contrôler le bon d’achat qui y est enregistré, puis lance une procédure 23 pour se connecter au serveur de paiement 17, au moyen du lien de paiement communiqué dans la notification 21, afin de pouvoir envoyer audit serveur de paiement le montant monétaire requis pour l’achat du bon, et correspondant à l’information communiquée dans la requête 16 et rappelée dans la notification 21. En particulier, la procédure 23 prévoit d’afficher sur le premier terminal 4 une interface de paiement par carte conventionnelle, dans laquelle le premier utilisateur 1 doit remplir plusieurs champs, par exemple pour renseigner le numéro de sa carte de paiement, sa date d’expiration et son numéro cryptographique, puis s’authentifier auprès du serveur de paiement 17, par exemple en renseignant un code secret pour autoriser le paiement. A l’issue de cette procédure 23, le premier terminal 4 envoie au serveur 12 de bons d’achat une requête 24 de transfert contenant l’identifiant de paiement lié à la transaction en cours, et relance si besoin une procédure 25 dite de « polling » pour se connecter régulièrement au serveur 17 de paiement, jusqu’à ce que le versement du montant monétaire requis soit correctement effectué. Le serveur 12 envoie ensuite au serveur de paiement 17 une requête 26 pour vérifier la réception du paiement, par le premier utilisateur 1, du montant monétaire requis puis, dans l’affirmative : enregistre dans le coffre-fort 10b de gestion de bons d’achats, via une notification 27, l’adresse numérique 8 du premier utilisateur 1 en tant que nouveau propriétaire du bon d’achat, en associant cette adresse numérique 8 à l’identifiant unique j dudit bon d’achat ; envoie au premier terminal 4 une notification 28 pour informer le premier utilisateur 1 du transfert de propriété du bon d’achat qu’il a demandé. Lors d’un paiement par virement bancaire ( FIG. 2 ), après réception de la requête 16, le serveur 12 de bons d’achat envoie une notification 18 comme décrit précédemment pour créer le bon d’achat requis dans son coffre-fort 10b de gestion, en lui associant un identifiant unique j, la valeur monétaire requise et l’adresse numérique 15 de son coffre-fort « personnel » 14, puis envoie au serveur de paiement 17 une requête 29 en connexion, notamment via un protocole de sécurisation de paiement définie par une instance telle que la Directive Européenne relative aux Services de Paiement (DSP2). A la réception de cette requête 29, le serveur de paiement 17 : lance une procédure de paiement 31, suivant un protocole tel que décrit précédemment, avec un établissement bancaire 30 dont le premier utilisateur 1 est client, au cours de laquelle ledit premier utilisateur s’authentifie auprès dudit établissement bancaire pour initier, à destination dudit serveur de paiement, un virement correspondant au montant monétaire requis pour le bon d’achat ; puis en cas de confirmation de l’initiation de ce virement, envoie au serveur 12 de fourniture de bons une notification 32 adaptée. A la réception de la notification 32, le serveur 12, comme décrit précédemment en relation avec la FIG. 2 (paiement par carte) : enregistre dans le coffre-fort 10b de gestion de bons d’achats, via une notification 27, l’adresse numérique 8 du premier utilisateur 1 en tant que nouveau propriétaire du bon d’achat, en associant cette adresse numérique 8 à l’identifiant unique j dudit bon d’achat ; envoie au premier terminal 4 une notification 28 pour informer le premier utilisateur 1 du transfert de propriété du bon d’achat qu’il a demandé. Ensuite, l’établissement bancaire 30 peut exécuter le virement initié en envoyant une notification adaptée 33 au serveur 12, de manière immédiate ou différée, selon les modalités définies par le premier utilisateur 1 lors de l’initiation dudit virement. La FIG. 2 représente une variante de réalisation de l’invention, dans laquelle l’établissement bancaire 30 dont le premier utilisateur 1 est client propose un service de fournitures de bons d’achats numériques, et utilise à cet effet un serveur 12 adapté lié à la chaîne de blocs. Dans ce cas, le serveur de paiement 17 et ce serveur 12 de fourniture de bons d’achats sont confondus, et le premier utilisateur 1 interagit directement avec ce serveur unique 12, 17 tant pour créer un bon d’achat que pour en verser le montant monétaire correspondant. Ainsi, après réception de la requête 16 du premier utilisateur 1, le serveur 12 effectue successivement les étapes suivantes : l’envoi à son coffre-fort 10b de gestion d’une notification 18 pour y créer le bon d’achat requis, en lui associant l’identifiant unique j, la valeur monétaire correspondant à l’information communiquée dans la requête 16, ainsi que l’adresse numérique 15 de son coffre-fort « personnel » 14 pour l’identifier comme propriétaire provisoire dudit bon d’achat ; l’envoi au premier terminal 4 d’une requête 34 en authentification à destination du premier utilisateur 1, afin d’initier un virement correspondant au montant monétaire requis pour le bon d’achat. En cas de confirmation de l’initiation de ce virement, le premier terminal 4 envoie au serveur 12 une notification 32’ adaptée, puis le serveur 12, comme décrit précédemment : enregistre dans le coffre-fort 10b de gestion de bons d’achats, via une notification 27, l’adresse numérique 8 du premier utilisateur 1 en tant que nouveau propriétaire du bon d’achat, en associant cette adresse numérique 8 à l’identifiant unique j dudit bon d’achat ; envoie au premier terminal 4 une notification 28 pour informer le premier utilisateur 1 du transfert de propriété du bon d’achat qu’il a demandé. Enfin, de manière similaire au mode de réalisation représenté sur la FIG. 2 (paiement par virement bancaire), l’établissement bancaire 30 du premier utilisateur 1 exécute le virement en son sein via une notification 33 adaptée, de manière immédiate ou différée. Dans les trois modes de réalisation représentés, le premier utilisateur 1 peut s’authentifier auprès du serveur de paiement 17 et/ou de son établissement bancaire 30 au moyen de données relatives à son identité bancaire préalablement enregistrées dans son coffre-fort numérique personnel 6 sur la chaîne de blocs, afin de faciliter les opérations d’authentification dudit premier utilisateur lorsqu’il achète des bons d’achats numériques sur ladite chaîne de blocs. Pour permettre aux utilisateurs 1, 2 de la chaîne de blocs d’échanger des jetons non-fongibles, l’architecture comprend un coffre-fort numérique 35 spécialement dédié à la gestion de tels échanges sur la chaîne de blocs. Le coffre-fort 35 peut être créé par un administrateur en charge de la gestion du serveur 12, et notamment par interaction avec la plateforme 3 de fourniture de coffres-forts numériques décrite précédemment. Dans ce cas, les adresses numériques respectives des coffres-forts « personnels » liés à la plateforme 3 et au serveur 12 peuvent être enregistrées dans les paramètres immuables du coffre-fort 35 de gestion d’échanges, en tant qu’adresses parentes dudit coffre-fort de gestion d’échanges. Le procédé prévoit en premier lieu, lorsque le premier utilisateur 1 souhaite échanger des jetons non-fongibles avec un second utilisateur 2 sur la chaîne de blocs, la sélection par ledit premier utilisateur d’au moins un jeton non-fongible à échanger, parmi ceux qu’il possède sur la chaîne de blocs. Pour ce faire, le premier utilisateur 1 doit associer à l’identifiant unique j du jeton non-fongible à échanger, enregistré dans le coffre-fort numérique 10a, 10b de gestion de jetons non-fongibles correspondant : une adresse numérique 36 du coffre-fort numérique 35 présent sur la chaîne de blocs pour gérer les échanges de jetons non-fongibles entre utilisateurs 1, 2 sur ladite chaîne de blocs ; un statut d’autorisation d’échange dudit jeton non-fongible. En relation avec les figures 1a et 3a, le premier terminal 4 comprend des moyens adaptés, notamment intégrés à une application qui y a été préalablement installée, pour permettre au premier utilisateur 1 de sélectionner, parmi les jetons non-fongibles qu’il possède, ceux qu’il souhaite échanger avec le second utilisateur 2. Pour ce faire, le premier terminal 4 (ou l’application qui y est installée) envoie une requête 37, 37’ adaptée sur la chaîne de blocs, afin d’effectuer les inscriptions demandées dans le(s) coffre(s)-forts 10a, 10b de gestion de jetons dans le(s)quel(s) le(s) jeton(s) non-fongible(s) qu’il souhaite échanger est(sont) référencé(s). Dans le cas où le jeton non-fongible à échanger a été créé par un utilisateur humain sur la chaîne de blocs, par exemple le premier utilisateur 1 lui-même ou un autre utilisateur de ladite chaîne de blocs, et correspond notamment à un « bien » matériel, immobilier ou numérique, le premier terminal 4 envoie la requête 37 directement au coffre-fort 10a de gestion dudit jeton non-fongible ( FIG. 1 ), afin d’y inscrire les informations requises (adresse numérique 36 du coffre-fort 35 d’échanges et statut d’autorisation d’échange) en les associant à l’identifiant unique j dudit jeton non-fongible. Dans le cas où le premier utilisateur 1 sélectionne un bon d’achat numérique qu’il possède en tant que jeton non-fongible à échanger avec le second utilisateur 2, ledit premier utilisateur associe, au moyen du premier terminal 4, les informations requises (adresse numérique 36 du coffre-fort 35 d’échanges et statut d’autorisation d’échange) à l’identifiant unique j dudit bon d’achat enregistré dans le coffre-fort numérique 10b de gestion de bons d’achats correspondant. Pour ce faire, comme représenté sur la FIG. 3 , le premier terminal 4 envoie une requête 37’ telle que décrite ci-dessus au serveur 12 de gestion des bons d’achats numériques, ledit serveur 12 interagissant avec le coffre-fort numérique 10b de gestion de bons d’achats dans lequel sont enregistrés l’information et l’identifiant unique j liés au bon d’achat à échanger, notamment via une notification 37’’ adaptée, afin d’associer audit identifiant unique les informations requises pour permettre cet échange (adresse numérique 36 du coffre-fort d’échanges 35 et statut d’autorisation d’échange). Après que le premier utilisateur 1 ait sélectionné le(s) jeton(s) non-fongible(s) qu’il souhaite échanger avec un second utilisateur 2, le procédé prévoit l’enregistrement par le premier utilisateur 1 au coffre-fort d’échanges 35, notamment grâce à des moyens spécifiques implantés sur le premier terminal 4 ou l’application qui y est installée, d’une proposition d’échange comprenant : une première liste m comprenant l’identifiant unique j d’au moins un jeton non-fongible qu’il souhaite échanger, associé à l’adresse numérique 39a, 39b du coffre-fort 10a, 10b de gestion dudit jeton non-fongible à échanger ; une seconde liste n comprenant l’identifiant unique i d’au moins un jeton non-fongible du second utilisateur 2 que ledit premier utilisateur souhaite acquérir via ledit échange, associé à l’adresse numérique 40 du coffre-fort 11 de gestion dudit jeton non-fongible souhaité. Pour ce faire, comme représenté sur les figures 1a et 3a, le premier utilisateur 1 envoie au coffre-fort d’échanges 35, au moyen du premier terminal 4, une notification 38 comprenant les listes m, n, afin d’enregistrer ces listes m, n dans ledit coffre-fort d’échanges, en tant que proposition d’échange à destination du second utilisateur 2. De façon avantageuse, le premier terminal 4 comprend des moyens pour calculer une empreinte numérique des listes m, n, notamment au moyen d’une application de hachage appropriée qui est intégrée audit premier terminal ou implantée sous forme d’interface de programmation (API) dans l’application générale préalablement décrite, puis pour envoyer cette empreinte avec lesdites listes dans la notification 38 adressée au coffre-fort d’échanges 35. De même, le coffre-fort d’échanges 35 comprend des moyens pour calculer une empreinte numérique des listes m, n et la comparer avec l’empreinte communiquée dans la notification 38, afin de n’enregistrer la proposition d’échanges qu’en cas de concordance entre ces deux empreintes. A l’issue, notamment dans le cas d’échanges de jetons non-fongibles créés directement par l’(les) utilisateur(s) 1, 2, le premier utilisateur 1 initiant l’échange peut envoyer au coffre-fort d’échanges 35 une requête 41 pour vérifier un statut d’initiation de cette proposition d’échanges, ainsi que la conformité des adresses numériques des coffres-forts 10a, 10b, 11 de gestion et des identifiants des jetons non-fongibles concernés. Dans le cas où la première liste m de jetons non-fongibles que le premier utilisateur 1 souhaite échanger contient au moins un bon d’achat numérique, le procédé prévoit que ledit premier utilisateur enregistre dans le coffre-fort d’échanges 35, avec des moyens adaptés implantés dans le premier terminal 4 (ou dans l’application qui y est installée), cette première liste m comprenant l’identifiant unique j dudit bon d’achat, associé à l’adresse numérique 39b du coffre-fort numérique 10b de gestion de bons d’achat correspondant. En parallèle, le procédé prévoit l’envoi par le premier utilisateur 1, grâce à des moyens implantés à cet effet sur le premier terminal 4 ou l’application qui y est installée, d’une notification 42 au coffre-fort 11 de gestion du jeton non-fongible souhaité, ladite notification comprenant les listes m, n susmentionnées, ainsi que l’adresse numérique 36 du coffre-fort d’échanges 35. Dans le cas où la seconde liste n de jetons non-fongibles détenus par un second utilisateur 2 et souhaités par le premier utilisateur 1 contient plusieurs jetons non-fongibles gérés par des coffres-forts 11 différents, par exemple si ces jetons non-fongibles ont été préalablement achetés par ledit second utilisateur à des créateurs différents, le premier terminal 4 peut envoyer une notification 42 adaptée à chacun desdits coffres-forts de gestion, afin que le second utilisateur 2 puisse identifier le(s) jeton(s) non-fongible(s) souhaité(s) par le premier utilisateur 1 en consultant chacun des coffres-forts de gestion 11 correspondants. Une fois la proposition d’échanges émise par le premier utilisateur 1 et notifiée au second utilisateur 2, par exemple via des échanges directs ou par messagerie entre lesdits utilisateurs, le procédé prévoit : la vérification par le second utilisateur 2 de la proposition d’échanges enregistrée dans le coffre-fort d’échanges 35 ; la vérification par le second utilisateur 2, dans le coffre-fort 10a, 10b de gestion du jeton non-fongible à échanger : du statut d’autorisation d’échange enregistré pour ledit jeton non-fongible à échanger ; de l’association de l’adresse numérique 36 du coffre-fort d’échanges 35 à l’identifiant unique j dudit jeton non-fongible à échanger. Pour ce faire, le second terminal 5 comprend des moyens pour permettre au second utilisateur 2 d’effectuer ces vérifications. En relation avec les figures 1b et 3b, le second utilisateur 2 lance sur le second terminal 5 une procédure 43 adaptée pour déclencher l’envoi d’une requête 44 au coffre-fort d’échanges 35, afin d’y vérifier les listes m, n, et notamment de prendre connaissance, via la première liste m, des jetons non-fongibles que le premier utilisateur 1 propose d’échanger, ainsi que des adresses numériques 39a, 39b des coffres-forts 10a, 10b de gestion de ces jetons non-fongibles, afin de pouvoir accéder à ces coffres-forts 10a, 10b pour y effectuer les vérifications requises. Ensuite, le second utilisateur 2 envoie via le second terminal 5 une requête 45 au(x) coffre(s)-fort(s) 10a, 10b de gestion du(des) jeton(s) non-fongible(s) renseigné(s) dans la première liste m, dont il a obtenu l’(les) adresse(s) numérique(s) 39a, 39b en consultant le coffre-fort d’échanges 35, afin d’y vérifier, pour chaque jeton non-fongible : le statut d’autorisation d’échange enregistré par le premier utilisateur 1 pour ledit jeton non-fongible ; l’association de l’adresse numérique 36 du coffre-fort d’échanges 35 à l’identifiant unique j dudit jeton non-fongible, et ainsi l’accréditation dudit coffre-fort d’échanges pour superviser l’échange dudit jeton non-fongible. Ainsi, en cas de résultat négatif pour l’un et/ou l’autre de ces paramètres (pas d’autorisation d’échange pour un jeton non-fongible de la première liste m et/ou pas d’association de l’adresse numérique 36 du coffre-fort d’échanges 35 audit jeton non-fongible), le second utilisateur 2 peut choisir de refuser la proposition d’échange émise par le premier utilisateur 1. En particulier, le procédé prévoit, lorsque la première liste m enregistrée par le premier utilisateur 1 contient un bon d’achat numérique, la vérification par le second utilisateur 2 de la valeur monétaire dudit bon d’achat numérique dans le coffre-fort numérique 10b de gestion dudit bon d’achat. Pour ce faire, comme représenté sur les figures 3b et 4, le second terminal 5 comprend des moyens, implantés directement dans ledit second terminal ou dans une application préalablement installée, pour permettre au second utilisateur 2 de vérifier cette valeur monétaire, en envoyant au serveur 12 une requête 46 contenant, comme représenté plus en détails sur la FIG. 4 : l’adresse numérique 9 dudit second utilisateur sur la chaîne de blocs, de préférence associée à un coffre-fort personnel 7 attribué audit second utilisateur sur ladite chaîne de blocs ; l’adresse numérique 39b du coffre-fort 10b de gestion du bon d’achat présent sur la première liste m d’échange du premier utilisateur 1 ; l’identifiant unique j dudit bon d’achat référencé sur ladite première liste d’échanges m et enregistré dans ledit coffre-fort de gestion de bons d’achat. De façon avantageuse, le procédé prévoit au préalable la communication par le premier utilisateur 1, au serveur 12 de fourniture de bons d’achats, d’une notification 47 comprenant : l’adresse numérique 9 du second utilisateur 2 sur la chaîne de blocs, et notamment du coffre-fort personnel 7 attribué audit second utilisateur sur ladite chaîne de blocs ; et pour chaque bon d’achat numérique qu’il souhaite échanger avec le second utilisateur 2, l’identifiant unique j enregistré pour ledit bon d’achat dans le coffre-fort 10b de gestion de bons d’achats correspondant ; afin de positionner ledit second utilisateur comme partie autorisée à vérifier la valeur monétaire du(des)dit(s) bon(s) d’achat. Pour ce faire, comme représenté sur la FIG. 4 , le premier terminal 4 (ou l’application qui y est installée) comprend des moyens pour communiquer une telle notification 47 au serveur 12, ledit serveur enregistrant ensuite l’adresse numérique 9 du second utilisateur 2 dans le(s) coffre(s)-fort(s) 10b de gestion correspondant(s), en l’associant à l’(les) identifiant(s) unique(s) j du(des) bon(s) d’achat concerné(s). Ainsi, après réception de la requête 46 envoyée par le second utilisateur 2, le serveur 12 interagit avec le(s) coffre(s)-fort(s) 10b de gestion concerné(s), afin de : vérifier, via une première requête 48, que ledit second utilisateur est une partie autorisée à vérifier la valeur monétaire du(des) bon(s) d’achat correspondant(s), notamment en vérifiant que l’adresse numérique 9 renseignée par ledit second utilisateur est bien associée à(aux) identifiant(s) unique(s) renseigné(s) par ledit second utilisateur et enregistré(s) dans le(s) coffre-fort(s) 10b consulté(s) ; et dans l’affirmative, déchiffrer, via une seconde requête 49, la valeur monétaire associée à chacun des identifiants numériques j renseignés par le second utilisateur 2, par exemple au moyen de la clé privée 13a associée audit serveur 12 sur la chaîne de blocs. Ensuite, le serveur 12 répond au second utilisateur 2 en lui envoyant une notification 50 contenant la(les) valeur(s) monétaire(s) du(des) bon(s) d’achat que ledit second utilisateur souhaitait vérifier. En cas de succès des vérifications présentées ci-dessus, le procédé prévoit l’approbation par le second utilisateur 2 de cette proposition d’échanges : en associant à l’identifiant unique i du jeton non-fongible qu’il possède et que le premier utilisateur 1 souhaite acquérir, enregistré dans le coffre-fort 11 de gestion correspondant : l’adresse numérique 36 du coffre-fort d’échanges 35 ; un statut d’autorisation d’échange dudit jeton non-fongible souhaité ; en envoyant au coffre-fort d’échanges 35 une notification 52 d’approbation de ladite proposition d’échanges. Pour ce faire, en relation avec les figures 1b et 3b, le second terminal 5 (ou l’application qui y est installée) comprend des moyens adaptés pour permettre au second utilisateur 2 d’approuver la proposition d’échanges en effectuant les opérations requises. En particulier, le second terminal 5 envoie : plusieurs notifications 51 au(x) coffre(s)-fort(s) 11 de gestion du(des) jeton(s) non-fongible(s) qu’il possède et qui sont référencé(s) sur la seconde liste n de souhaits du premier utilisateur 1, afin d’associer un statut d’autorisation d’échange et l’adresse numérique 36 à l’(aux) identifiant(s) unique(s) i du(des)dit(s) jeton(s) non-fongible(s) ; une notification 52 d’approbation telle que décrite précédemment au coffre-fort d’échanges 35. A l’issue de l’approbation de l’échange par le second utilisateur 2, le procédé prévoit, pour finaliser cet échange, que le coffre-fort d’échanges 35 enregistre les informations suivantes : l’adresse numérique 8 du premier utilisateur 1, et notamment de son coffre-fort personnel 6, dans le(s) coffre(s)-fort(s) numérique(s) 11 de gestion du(des) jeton(s) non-fongible(s) obtenu(s) du second utilisateur 2, en l’associant à l’(aux) identifiant(s) unique(s) i du(des)dit(s) jeton (s) non-fongible(s) obtenu(s), afin de désigner ledit premier utilisateur comme nouveau propriétaire du(des)dit(s) jeton(s) non-fongible(s) obtenu(s) ; l’adresse numérique 9 du second utilisateur 2, en l’occurrence celle de son coffre-fort personnel 7, dans le(s) coffre(s)-fort(s) numérique(s) 10a, 10b de gestion du(des) jeton(s) non-fongible(s) échangé(s) par le premier utilisateur 1, en l’associant à l’(aux) identifiant(s) unique(s) j du(des)dit(s) jeton(s) non-fongible(s) échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire du(des)dit(s) jeton(s) non-fongible(s) échangé(s). Pour ce faire, le coffre-fort d’échanges 35 comprend des moyens pour effectuer de tels enregistrements, notamment après avoir reçu la notification 52 d’approbation de l’échange envoyée par le second utilisateur 2 via le second terminal 5. Ces moyens peuvent se présenter sous la forme d’un algorithme agencé pour se déclencher automatiquement à la réception de la notification d’approbation 52 décrite précédemment, la plateforme 3 comprenant des moyens pour permettre le déploiement du coffre-fort d’échanges 35 agencé pour exécuter ledit algorithme après avoir reçu ladite notification. De façon avantageuse, cet algorithme est agencé pour permettre au coffre-fort d’échanges 35 de vérifier la présence des adresses numériques 8, 9 respective des utilisateurs 1, 2 sur la chaîne de blocs, notamment dans un coffre-fort numérique central tel que décrit précédemment, ainsi que, le cas échéant, la présence dans ce même coffre-fort central d’une adresse numérique liée à la plateforme 3 de déploiement des coffres-forts personnels 6, 7 liés à ces adresses numériques 8, 9. Cet agencement permet de sécuriser davantage le procédé d’échanges de jetons non-fongibles entre les utilisateurs 1, 2. Dans le cas où le premier utilisateur 1 a échangé un bon d’achat numérique avec le second utilisateur 2, le coffre-fort d’échanges 35 enregistre l’adresse numérique 9 du second utilisateur 2 dans le coffre-fort 10b de gestion dudit bon d’achat échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit bon d’achat échangé. En relation avec la FIG. 5 , le procédé prévoit, lorsque le second utilisateur 2 souhaite récupérer un montant monétaire équivalent à la valeur monétaire d’un bon d’achat numérique échangé avec le premier utilisateur 1, que ledit second utilisateur 2 envoie au serveur 12 une requête en remboursement 53 comprenant : l'adresse numérique 9 de son coffre-fort personnel 7 sur la chaîne de blocs ; l'adresse numérique 39b du coffre-fort 10b de gestion du bon d’achat correspondant ; l'identifiant unique j du bon d’achat enregistré dans ledit coffre-fort de gestion dudit bon d’achat ; une information liée à une identité bancaire du second utilisateur 2, par exemple un identifiant alphanumérique d’un compte détenu par ledit second utilisateur dans un établissement bancaire 54. Pour ce faire, le second terminal 5 comprend des moyens pour envoyer une telle requête 53 au serveur 12, par exemple via une application dédiée installée sur ledit second terminal, ou via une interface de programmation (API) intégrée dans l’application générale préalablement décrite et installée sur ledit second terminal. De façon avantageuse, le procédé prévoit que le propriétaire d’un bon d’achat numérique, par exemple le premier utilisateur 1 après création et achat dudit bon, ou le second utilisateur 2 après échange dudit bon d’achat par ledit premier utilisateur, approuve le serveur 12 en tant que gestionnaire apte à effectuer des opérations de gestion dudit bon d’achat. Pour ce faire, le propriétaire 1, 2 peut effectuer une manipulation spécifique sur l’application correspondante, notamment au moment où il acquiert le bon d’achat numérique. Après réception de la requête 53, le serveur 12 envoie au coffre-fort 10b de gestion du bon d’achat une notification 55 pour y vérifier l’inscription du second utilisateur 2 en tant que propriétaire actuel dudit bon d’achat, notamment en y vérifiant l’association de l’adresse numérique 9 dudit second utilisateur à l’identifiant unique j dudit bon d’achat. Ensuite, le serveur 12 envoie au second terminal 5 une notification 56 pour vérifier l’information liée à l’identité bancaire du second utilisateur 2, cette information pouvant être un identifiant alphanumérique de type IBAN (pour l’anglais « International Bank Account Number »). En cas de succès de ces vérifications, le procédé prévoit, en réponse à cette requête 53, l’interaction du serveur 12 avec un serveur de paiement 57b lié à l’établissement bancaire 54 du second utilisateur 2, afin d’effectuer à destination dudit second utilisateur un remboursement monétaire équivalent à la valeur monétaire du bon d’achat. Pour ce faire, comme représenté sur la FIG. 5 , le serveur 12 comprend des moyens pour : envoyer au coffre-fort 10b de gestion du bon d’achat une notification 58 pour récupérer ledit bon d’achat ; envoyer au serveur de paiement 57 une notification 59 pour initier un virement du montant monétaire correspondant à la valeur monétaire dudit bon d’achat, ledit virement pouvant être effectué suivant un protocole de type SEPA (pour « Single Euro Payments Area ») ; envoyer au second terminal 5 une notification 60 contenant une référence alphanumérique d’identification dudit virement, afin d’informer le second utilisateur 2 de l’exécution dudit virement, et ainsi du remboursement de son bon d’achat. Procédé pour permettre à deux utilisateurs (1, 2) d’échanger des jetons non-fongibles sur une chaîne de blocs, ledit procédé prévoyant au préalable : lors de la création d’un jeton non-fongible, l’enregistrement d’une information liée audit jeton non-fongible dans un coffre-fort numérique (10a, 10b, 11) de gestion de jetons sur la chaîne de blocs, en l’associant à un identifiant unique (i, j) pour ledit jeton non-fongible ; lorsqu’un utilisateur (1, 2) acquiert un jeton non-fongible, l’enregistrement, dans le coffre-fort numérique (10a, 10b, 11) de gestion dudit jeton non-fongible, d’une adresse numérique (8, 9) dudit utilisateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible ; ledit procédé prévoyant en outre, lorsqu’un premier utilisateur (1) souhaite échanger des jetons non-fongibles avec un second utilisateur (2) sur la chaîne de blocs : la sélection par le premier utilisateur (1) d’au moins un jeton non-fongible à échanger, parmi les jetons non-fongibles qu’il possède sur la chaîne de blocs, en associant à l’identifiant unique (j) dudit jeton non-fongible à échanger, enregistré dans le coffre-fort numérique (10a, 10b) de gestion correspondant : une adresse numérique (36) d’un coffre-fort numérique (35) présent sur la chaîne de blocs pour gérer les échanges de jetons non-fongibles entre utilisateurs (1, 2) sur ladite chaine de blocs ; un statut d’autorisation d’échange dudit jeton non-fongible ; l’enregistrement par le premier utilisateur (1), dans le coffre-fort d’échanges (35), d’une proposition d’échange comprenant : une première liste (m) comprenant l’identifiant unique (j) d’au moins un jeton non-fongible qu’il souhaite échanger, associé à l’adresse numérique (39a, 39b) du coffre-fort (10a, 10b) de gestion dudit jeton non-fongible à échanger ; une seconde liste (n) comprenant l’identifiant unique (i) d’au moins un jeton non-fongible du second utilisateur (2) que ledit premier utilisateur souhaite acquérir via ledit échange, associé à l’adresse numérique (40) du coffre-fort (11) de gestion dudit jeton non-fongible souhaité ; l’envoi par le premier utilisateur (1), au coffre-fort (11) de gestion du jeton non-fongible souhaité, d’une notification (42) comprenant les listes (m, n), ainsi que l’adresse numérique (36) du coffre-fort d’échanges (35) ; la vérification par le second utilisateur (2) de la proposition d’échange enregistrée dans le coffre-fort d’échanges (35) ; la vérification par le second utilisateur (2) dans le coffre-fort (10a, 10b) de gestion du jeton non-fongible à échanger : du statut d’autorisation d’échange enregistré pour ledit jeton non-fongible à échanger ; de l’association de l’adresse numérique (36) du coffre-fort d’échanges (35) à l’identifiant unique (j) dudit jeton non-fongible à échanger ; en cas de succès de ces vérifications, l’approbation par le second utilisateur (2) de cette proposition d’échange : en associant à l’identifiant unique (i) du jeton non-fongible souhaité, enregistré dans le coffre-fort (11) de gestion correspondant : l’adresse numérique (36) du coffre-fort d’échanges (35) ; un statut d’autorisation d’échange dudit jeton non-fongible souhaité ; en envoyant au coffre-fort d’échanges (35) une notification (52) d’approbation de ladite proposition d’échange ; l’enregistrement, par le coffre-fort d’échanges (35), de : l’adresse numérique (8) du premier utilisateur (1) dans le coffre-fort numérique (11) de gestion du jeton non-fongible obtenu du second utilisateur (2), en l’associant à l’identifiant unique (i) dudit jeton non-fongible obtenu, afin de désigner ledit premier utilisateur comme nouveau propriétaire dudit jeton non-fongible obtenu ; l’adresse numérique (9) du second utilisateur (2) dans le coffre-fort numérique (10a, 10b) de gestion du jeton non-fongible échangé avec le premier utilisateur (1), en l’associant à l’identifiant unique (j) dudit jeton non-fongible échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. Procédé selon la revendication 1, caractérisé en ce qu’il prévoit au préalable l’achat par le premier utilisateur (1) d’un bon d’achat numérique sous forme de jeton non-fongible destiné à être échangé ultérieurement avec un second utilisateur (2), ledit achat étant réalisé par : l’envoi par le premier utilisateur (1) d’une requête (16) à un serveur (12) de fourniture de bons d’achats numériques lié à la chaîne de blocs, ladite requête comprenant une information sur un montant monétaire que ledit premier utilisateur souhaite attribuer audit bon d’achat numérique ; la création par le serveur (12) de bons d’achat, dans un coffre-fort numérique (10b) de gestion de bons d’achats présent sur la chaine de blocs, d’un bon d’achat numérique sous forme de jeton non-fongible, en lui attribuant un identifiant unique (j) et une valeur monétaire correspondant à l’information de montant communiquée dans la requête (16) ; l’envoi par ledit premier utilisateur du montant monétaire correspondant à l’information communiquée dans la requête (16) à un serveur (17) de paiement lié à la chaîne de blocs ; l'enregistrement par le serveur (12) de bons d’achats, dans le coffre-fort (10b) de gestion de bons d’achats, de l’adresse numérique (8) du premier utilisateur (1) sur la chaîne de blocs, en tant que propriétaire dudit bon d’achat. Procédé selon la revendication 2, caractérisé en ce qu’il prévoit, lorsque le premier utilisateur (1) sélectionne un bon d’achat numérique en tant que jeton non-fongible à échanger avec un second utilisateur (2), d’associer à l’identifiant unique (j) dudit bon d’achat numérique à échanger, enregistré dans le coffre-fort (10b) de gestion de bons d’achats correspondant : une adresse numérique (36) du coffre-fort d’échanges (35) sur la chaîne de blocs ; un statut d’autorisation d’échange dudit bon d’achat numérique ; le premier utilisateur (1) enregistrant ensuite dans le coffre-fort d’échanges (35) la première liste (m) comprenant l’identifiant unique (j) dudit bon d’achat associé à l’adresse numérique (39b) du coffre-fort (10b) de gestion de bons d’achats, le procédé prévoyant en outre, après l’échange du bon d’achat numérique avec le second utilisateur (2), d’enregistrer l’adresse numérique (9) dudit second utilisateur dans le coffre-fort numérique (10b) de gestion du bon d'achat échangé avec le premier utilisateur (1), en l’associant à l’identifiant unique (j) dudit bon d'achat échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. Procédé selon l’une des revendications 2 ou 3, caractérisé en ce qu’il prévoit, lorsque la première liste (m) d’échange enregistrée par le premier utilisateur (1) contient au moins un bon d’achat numérique, la vérification par le second utilisateur (2) de la valeur monétaire dudit bon d’achat numérique dans le coffre-fort numérique (10b) de gestion dudit bon d’achat. Procédé selon la revendication 4, caractérisé en ce qu’il prévoit l’envoi par le second utilisateur (2) au serveur (12) de fourniture de bons d’achat d’une requête (46) contenant l’adresse numérique (9) dudit second utilisateur sur la chaîne de blocs, l’adresse numérique (39b) du coffre-fort (10b) de gestion du bon d’achat présent sur la première liste d’échange (m), ainsi que l'identifiant unique (j) dudit bon d’achat référencé sur la première liste d’échanges (m) et enregistré dans ledit coffre-fort de gestion de bons d’achat. Procédé selon l’une des revendications 4 ou 5, caractérisé en ce qu’il prévoit au préalable la communication par le premier utilisateur (1) au serveur (12) de fourniture de bons d’achats d’une notification (47) comprenant l’adresse numérique (8) du second utilisateur (2) sur la chaîne de blocs et, pour chaque bon d’achat numérique qu’il souhaite échanger avec ledit second utilisateur, l’identifiant unique (j) enregistré pour ledit bon d’achat dans le coffre-fort (10b) de gestion de bons d’achat correspondant, afin de positionner ledit second utilisateur comme partie autorisée à vérifier la valeur monétaire du(des)dit(s) bon(s) d’achat. Procédé selon l’une quelconque des revendications 2 à 6, caractérisé en ce qu’il prévoit, lorsque le second utilisateur (2) souhaite récupérer un montant monétaire équivalent à la valeur monétaire d’un bon d’achat numérique échangé avec le premier utilisateur (1), l’envoi par le second utilisateur (2), au serveur (12) de fourniture de bons d’achats, d’une requête en remboursement (53) contenant : l'adresse numérique (9) du second utilisateur (2) sur la chaîne de blocs ; l'adresse numérique (39b) du coffre-fort (10b) de gestion du bon d’achat correspondant ; l'identifiant unique (j) du bon d’achat enregistré dans ledit coffre-fort de gestion dudit bon d’achat ; une information liée à une identité bancaire du second utilisateur (2) ; ledit procédé prévoyant en outre, en réponse à ladite requête, l’interaction dudit serveur avec un serveur de paiement (57) lié à un établissement bancaire (54) dudit second utilisateur pour effectuer à destination dudit second utilisateur un remboursement monétaire équivalent à la valeur monétaire dudit bon d’achat. Architecture pour permettre à deux utilisateurs (1, 2) d’échanger des jetons non-fongibles sur une chaîne de blocs, ladite architecture comprenant : au moins un coffre-fort numérique (10a, 10b, 11) de gestion de jetons non-fongibles sur la chaîne de blocs, dans lequel sont enregistrés : lors de la création d’un jeton non-fongible, une information liée audit jeton non-fongible, en étant associée à un identifiant unique (i, j) pour ledit jeton non-fongible ; lorsqu’un utilisateur (1, 2) acquiert un jeton non-fongible géré au moyen dudit coffre-fort de gestion de jetons, une adresse numérique (8, 9) dudit utilisateur sur la chaîne de blocs, en tant que propriétaire dudit jeton non-fongible ; un coffre-fort numérique (35) pour gérer les échanges de jetons non-fongibles entre utilisateurs (1, 2) sur ladite chaine de blocs ; un premier terminal (4) comprenant des moyens pour permettre à un premier utilisateur (1) souhaitant échanger des jetons non-fongibles avec un second utilisateur (2) sur la chaîne de blocs de : sélectionner au moins un jeton non-fongible à échanger, parmi les jetons non-fongibles qu’il possède sur la chaîne de blocs, en associant à l’identifiant unique (j) dudit jeton non-fongible à échanger, enregistré dans le coffre-fort numérique (10a, 10b) de gestion correspondant : une adresse numérique (36) sur la chaîne de blocs du coffre-fort numérique (35) d'échanges de jetons non-fongibles ; un statut d’autorisation d’échange dudit jeton non-fongible ; enregistrer dans le coffre-fort d’échanges (35) une proposition d’échange comprenant : une première liste (m) comprenant l’identifiant unique (j) d’au moins un jeton non-fongible qu’il souhaite échanger, associé à l’adresse numérique (39a, 39b) du coffre-fort (10a, 10b) de gestion dudit jeton non-fongible à échanger ; une seconde liste (n) comprenant l’identifiant unique (i) d’au moins un jeton non-fongible du second utilisateur (2) que ledit premier utilisateur souhaite acquérir via ledit échange, associé à l’adresse numérique (40) du coffre-fort (11) de gestion dudit jeton non-fongible souhaité ; envoyer, au coffre-fort (11) de gestion du jeton non-fongible souhaité, une notification (42) comprenant les listes (m, n), ainsi que l’adresse numérique (36) du coffre-fort d’échanges (35) ; un second terminal (5) comprenant des moyens pour permettre au second utilisateur (2) de : vérifier la proposition d’échange enregistrée dans le coffre-fort d’échanges (35) ; vérifier, dans le coffre-fort (10a, 10b) de gestion du jeton non-fongible à échanger : le statut d’autorisation d’échange enregistré pour ledit jeton non-fongible à échanger ; l’association de l’adresse numérique (36) du coffre-fort d’échanges (35) à l’identifiant unique (j) dudit jeton non-fongible à échanger ; en cas de succès de ces vérifications, approuver cette proposition d’échange : en associant à l’identifiant unique (i) du jeton non-fongible souhaité, enregistré dans le coffre-fort (11) de gestion correspondant : l’adresse numérique (36) du coffre-fort d’échanges (35) ; un statut d’autorisation d’échange dudit jeton non-fongible souhaité ; en envoyant au coffre-fort d’échanges (35) une notification (52) d’approbation de ladite proposition d’échange ; le coffre-fort d’échanges (35) comprenant des moyens pour enregistrer, à l’issue de cet échange : l’adresse numérique (8) du premier utilisateur (1) dans le coffre-fort numérique (11) de gestion du jeton non-fongible obtenu du second utilisateur (2), en l’associant à l’identifiant unique (i) dudit jeton non-fongible obtenu, afin de désigner ledit premier utilisateur comme nouveau propriétaire dudit jeton non-fongible obtenu ; l’adresse numérique (9) du second utilisateur (2) dans le coffre-fort numérique (10a, 10b) de gestion du jeton non-fongible échangé avec le premier utilisateur (1), en l’associant à l’identifiant unique (j) dudit jeton non-fongible échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. Architecture selon la revendication 8, caractérisée en ce que le premier terminal (4) comprend des moyens pour permettre au premier utilisateur (1) d’acheter un bon d’achat numérique destiné à être échangé ultérieurement avec un second utilisateur (2), en envoyant : une requête (16) comprenant une information sur un montant monétaire que ledit premier utilisateur souhaite attribuer audit bon d’achat numérique ; le montant monétaire correspondant à l’information communiquée dans la requête (16) à un serveur de paiement (17) lié à la chaîne de blocs ; ladite architecture comprenant en outre un serveur (12) de fourniture de bons d’achat numériques lié à la chaîne de blocs, qui comprend des moyens pour : recevoir la requête (16) envoyée par le premier terminal pour acheter un bon d’achat numérique ; à la réception de ladite requête, créer, dans un coffre-fort numérique (10b) de gestion de bons d’achat présent sur la chaîne de blocs, un bon d’achat numérique sous forme de jeton non-fongible, en lui attribuant un identifiant unique (j) et une valeur monétaire correspondant à l’information de montant communiquée dans ladite requête ; à la réception par le serveur de paiement (17) d’une confirmation du transfert du montant monétaire, enregistrer, dans le coffre-fort (10b) de gestion de bons d’achats, l’adresse numérique (8) du premier utilisateur (1) sur la chaîne de blocs, en tant que propriétaire dudit bon d’achat. Architecture selon la revendication 9, caractérisée en ce que le premier terminal (4) comprend des moyens pour permettre au premier utilisateur (1), lorsqu’il sélectionne un bon d’achat numérique en tant que jeton non-fongible à échanger avec un second utilisateur (2), d’associer à l’identifiant unique (j) dudit bon d’achat numérique à échanger, enregistré dans le coffre-fort (10b) de gestion de bons d’achats correspondant : une adresse numérique (36) du coffre-fort d’échanges (35) sur la chaîne de blocs ; un statut d’autorisation d’échange dudit bon d’achat numérique ; ainsi que des moyens pour permettre au premier utilisateur (1) d’enregistrer ensuite dans le coffre-fort d’échanges (35) la première liste (m) comprenant l’identifiant unique (j) dudit bon d’achat associé à l’adresse numérique (39b) du coffre-fort (10b) de gestion de bons d’achats, le coffre-fort d’échanges (35) comprenant en outre des moyens pour, après l’échange du bon d’achat numérique avec le second utilisateur (2), enregistrer l’adresse numérique (9) dudit second utilisateur dans le coffre-fort numérique (10b) de gestion du bon d'achat échangé avec le premier utilisateur (1), en l’associant à l’identifiant unique (j) dudit bon d'achat échangé, afin de désigner ledit second utilisateur comme nouveau propriétaire dudit jeton non-fongible échangé. Architecture selon l’une des revendications 9 ou 10, caractérisée en ce que le second terminal (5) comprend des moyens pour, lorsque la première liste (m) d’échange enregistrée par le premier utilisateur (1) contient au moins un bon d’achat numérique, vérifier la valeur monétaire dudit bon d’achat numérique dans le coffre-fort numérique (10b) de gestion dudit bon d’achat. Architecture selon la revendication 11, caractérisée en ce que le second terminal (5) comprend des moyens pour permettre au second utilisateur (2) d’envoyer, au serveur (12) de fourniture de bons d’achat, une requête (46) contenant l’adresse numérique (9) dudit second utilisateur sur la chaîne de blocs, l’adresse numérique (39b) du coffre-fort (10b) de gestion du bon d’achat présent sur la première liste d’échange (m), ainsi que l'identifiant unique (j) dudit bon d’achat référencé sur la première liste d’échanges (m) et enregistré dans ledit coffre-fort de gestion de bons d’achat. Architecture selon l’une des revendications 11 ou 12, caractérisée en ce que le premier terminal (4) comprend des moyens pour permettre au premier utilisateur (1) de communiquer au préalable, au serveur (12) de fourniture de bons d’achats, une notification (47) comprenant l’adresse numérique (9) du second utilisateur (2) sur la chaîne de blocs et, pour chaque bon d’achat numérique qu’il souhaite échanger avec ledit second utilisateur, l’identifiant unique (j) enregistré pour ledit bon d’achat dans le coffre-fort (10b) de gestion de bons d’achat correspondant, afin de positionner ledit second utilisateur comme partie autorisée à vérifier la valeur monétaire du(des)dit(s) bon(s) d’achat. Architecture selon l’une quelconque des revendications 9 à 13, caractérisée en ce que le second terminal (5) comprend des moyens pour permettre au second utilisateur (2), lorsqu’il souhaite récupérer un montant monétaire équivalent à la valeur monétaire d’un bon d’achat numérique échangé avec le premier utilisateur (1), d’envoyer au serveur (12) de fourniture de bons d’achats une requête en remboursement (53) contenant : l'adresse numérique (9) du second utilisateur (2) sur la chaîne de blocs ; l'adresse numérique (39b) du coffre-fort (10b) de gestion du bon d’achat correspondant ; l'identifiant unique (j) du bon d’achat enregistré dans ledit coffre-fort de gestion dudit bon d’achat ; une information liée à une identité bancaire du second utilisateur (2) ; ledit serveur de fourniture de bons d’achats comprenant en outre des moyens pour, en réponse à ladite requête, interagir avec un serveur de paiement (57) lié à un établissement bancaire (54) dudit second utilisateur pour effectuer à destination dudit second utilisateur un remboursement monétaire équivalent à la valeur monétaire dudit bon d’achat.