FR 3153671 A1 20250404 FR 2410601 A 20241002 L'invention tire profit de certaines caractéristiques de la spécification URI pour incorporer un contenu cryptographique de manière à ne pas entraver le fonctionnement normal d'un URI. Le contenu cryptographique peut ensuite être utilisé pour garantir l'authenticité du chemin défini dans la partie non chiffrée. Le chemin peut également servir pour pointer un dispositif de lecture vers une ressource de réseau apte à réaliser l'opération de déchiffrement, ou pour une clé de déchiffrement. Fig. 6 Procédé et système mettant en œuvre des opérations sécurisées avec des identifiants de ressource de réseau Domaine de l'invention L'invention concerne des sceaux basés sur des URI, susceptibles d'être mis en œuvre dans un format lisible par machine. État de la technique Les dernières décennies ont vu les données migrer d'un support physique comme un document papier vers le monde du numérique. Il existe toutefois de nombreux cas où une matérialisation des données reste nécessaire. On citera notamment les étiquettes de produits, les codes de référence dans les communications imprimées, l'affichage public et autres, les exemples pouvant aller de simples codes de référence au contenu intégral d'un document. Même si ces cas de figure peuvent laisser supposer un besoin de lisibilité humaine, la tendance générale vers un traitement numérique fait qu'il est souhaitable de présenter de telles informations sous une forme également adaptée à une interprétation machine. Bon nombre de représentations de ce type existent déjà. Le développement de la technologie Internet au cours du XXe siècle a vu émerger un certain nombre de mécanismes différents permettant d'établir un lien entre un objet et un système de gestion électronique des informations. Les cartes perforées furent développées comme moyen d'entrée primitif pour des dispositifs informatiques, et la possibilité d'utiliser des cartes similaires fut très vite identifiée comme moyen rapide d'enregistrer la vente d'un objet. Une avancée majeure fut réalisée dans ce domaine avec la mise au point du système du Code Universel des Produits, basé sur la lecture d'un code-barres à deux dimensions au moyen d'un scanner laser. Dans le domaine des Biens de Consommation Emballés (désignés par l'acronyme en langue anglaise CPG pour "​​Consumer-Packaged Good"), on utilise les Codes Articles Internationaux (désignés par l'acronyme en langue anglaise GTIN pour "Global Trade Identifier Number") pour identifier les produits au moyen d'étiquettes et d'emballages imprimés. Le code-barres linéaire est une représentation visuelle du code GTIN figurant en dessous. Le dernier chiffre d'un numéro à 14 chiffres du GTIN 14, ou d'un numéro à 13 chiffres du GTIN 13, constitue une clé. Cette clé, également dénommée chiffre de contrôle, sert à vérifier que les chiffres précédents sont corrects et ne sont pas corrompus. Sur la base de cette technologie et de technologies connexes, pratiquement tous les biens de consommation emballés actuels sont munis d'un tel code. Plus récemment, l'utilisation de codes-barres matriciels ou à deux dimensions, notamment de "QR Codes" (marque déposée dans certains territoires) décrits par exemple dans le brevet des États-Unis portant la référence US5726435, s'est généralisée. Ces codes sont capables de coder davantage d'informations dans une surface réduite que les codes-barres traditionnels à une dimension et sont, à ce titre, fréquemment utilisés pour coder un Identifiant Uniforme de Ressource. Par ailleurs, outre ces solutions optiques, les solutions d'étiquetage basées sur les ondes radio, notamment celles basées sur les étiquettes RFID, se généralise. L'utilisation généralisée de codes de ce type soulève la question de la sécurité, dès lors qu’il devient nécessaire de vérifier l'authenticité, l'exactitude ou la validité d'un code particulier. Parmi les solutions cryptographiques à cette question, on pourra citer le Cachet Électronique Visible (désigné par l'acronyme en langue anglaise VDS pour "Visible Digital Seal"), une structure de données signée cryptographiquement (autrement dit un ensemble de données codées signé électroniquement, désigné par l'acronyme en langue anglaise ESEDS pour "Electronically Signed Encoded Data Set) qui peut être codée dans une symbologie de code-barres à deux dimensions, généralement un code Datamatrix, un QR code ou un code Han Xin. La FIG. 1 présente un exemple d'un Cachet Électronique Visible dans un format Datamatrix. La FIG. 1 présente un exemple d'un Cachet Électronique Visible dans un format QR code. La FIG. 1 présente un exemple d'un Cachet Électronique Visible dans un format Han Xin. Le code contient les informations essentielles du document respectif ainsi qu'une signature numérique qui offre une protection contre la manipulation des données. Les sceaux Électroniques Visibles (VDS) visent à garantir, de façon économique et sécurisée, l'authenticité et l'intégrité des documents par cryptographie asymétrique. Parmi les applications possibles des VDS, on citera les cartes d'identité, les passeports, les passeports produits, les certificats, les timbres fiscaux ou tout autre document dont il convient de garantir l'authenticité et l'intégrité. La suite de caractères ci-après est un exemple de la partie signature d'un Cachet Électronique Visible ESDS : 3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG Le cas d'utilisation général pour des codes de ce type, au croisement d'objets physiques et de systèmes informatiques, comprend implicitement le très large éventail de scénarios dans lesquels la lecture du code pourra s'avérer nécessaire. Compte tenu de la mobilité et de la durabilité de ces objets physiques, nul ne sait comment, où ou quand il pourra être souhaitable de lire le code. Par ailleurs, une structure cryptographique telle que le VDS présenté ci-dessus est généralement une construction assez opaque dont il faut a priori connaître le format pour en permettre la bonne interprétation. Il s'ensuit que, dans la pratique, une interface généraliste sera incapable de traiter ou d'interpréter des données ainsi codées, ce qui nécessitera le recours à un lecteur dédié. En guise d'exemple, dans un scénario type de la technique antérieure, un Cachet Électronique Visible ESEDS, codé dans un code-barres à deux dimensions, un code Datamatrix, un QR Code ou un code Han Xin, ne pourra être lu que par une application dédiée, comme une application mobile sécurisée spécialisée, sans nécessiter de connexion Internet dans l'hypothèse où le type de cas d'utilisation du VDS est déjà connu de l'application mobile. Il est souhaitable de proposer un mécanisme permettant à des interfaces de données généralistes de gérer des données incorporées dans des composantes d'authentification cryptographiques. Conformément à la présente invention, selon un premier aspect, on propose un procédé, mis en œuvre par ordinateur, de définition d’une structure d'identifiant de ressource de réseau sécurisé, comprenant la définition d'un Identifiant Uniforme de Ressource (désigné par l’acronyme en langue anglaise URI pour "Uniform Resource Identifier") possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et l'association des composantes de schéma et de chemin à une partie fragment et/ou requête comprenant une structure de données signée cryptographiquement. Conformément à la présente invention, selon un deuxième aspect, on propose un procédé, mis en œuvre par ordinateur, de définition d'une structure d'identifiant de ressource de réseau sécurisé, comprenant la définition d'un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, associant les composantes de schéma et de chemin à un suffixe de partie chemin comprenant une structure de données signée cryptographiquement constituant un identifiant unique. Dans un développement du premier ou du deuxième aspect, on propose une étape supplémentaire de codage de la structure d'identifiant de ressource de réseau sécurisé dans un code lisible par machine. Dans un développement du premier ou du deuxième aspect, l'Identifiant Uniforme de Ressource pointe vers un référentiel duquel peut être extraite une application logicielle apte à vérifier que la composante de chemin correspond à la structure de données signée. Conformément à la présente invention, selon un troisième aspect, on propose un procédé d'accès à une ressource de réseau, comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé selon le premier ou le deuxième aspect, le déchiffrement de la structure de données signée cryptographiquement, la vérification que la composante de chemin correspond à ladite structure de données signée et, en réponse à la vérification, l'accès à la ressource de réseau désignée par l'Identifiant Uniforme de Ressource. Dans un développement du troisième aspect, on propose une étape supplémentaire de réception de la structure d'identifiant de ressource de réseau sécurisé au niveau d'un dispositif utilisateur, l'étape de vérification que la composante de chemin correspond à la structure de données signée étant réalisée au niveau soit du dispositif utilisateur soit d'un serveur distant identifié par la composante de chemin. Conformément à la présente invention, selon un quatrième aspect, on propose un procédé de décodage d'une structure d'identifiant de ressource de réseau sécurisé, comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé selon des modes de réalisation précités, l'identification d'une structure caractéristique d'un schéma connu comme étant utilisé avec des structures d'identifiant de ressource de réseau sécurisé selon des modes de réalisation précités, l'isolement d'une partie de la structure d'identifiant de ressource de réseau sécurisé connue comme correspondant à un identifiant unique selon le schéma, et la tentative de déchiffrement de la partie isolée de la structure d'identifiant de ressource de réseau sécurisé. Dans un développement du quatrième aspect, la structure de données signée cryptographiquement comprend une charge utile de données supplémentaire, et le procédé comprend une étape supplémentaire d'extraction de données de référence à partir de la ressource de réseau désignée par la composante de chemin, et la comparaison des données de référence à la charge utile de données supplémentaire. Dans un développement du troisième ou du quatrième aspect, la structure de données signée cryptographiquement comprend une charge utile de données supplémentaire, et le procédé comprend une étape supplémentaire d'identification d'une caractéristique de la structure d'identifiant de ressource de réseau sécurisé associée à une ressource de réseau supplémentaire, et d'extraction de données de référence à partir de ladite ressource de réseau supplémentaire, et de comparaison des données de référence à la charge utile de données supplémentaire. Conformément à la présente invention, selon un cinquième aspect, on propose un procédé d'association d'un identifiant unique à un produit, le produit appartenant à une classification arborescente de produit, le procédé comprenant les étapes de composition d'un URI sur la base de la classification du produit selon la classification arborescente de produit, d'obtention d'une structure de données signée cryptographiquement au regard de l'URI selon la revendication 1, et d'association de la structure de données signée cryptographiquement au produit en tant qu'identifiant unique. Conformément à la présente invention, selon un sixième aspect, on propose un système de traitement de données comprenant des moyens de réalisation du premier, du deuxième, du troisième, du quatrième ou du cinquième aspect. Conformément à la présente invention, selon un septième aspect, on propose un programme informatique comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, amènent l'ordinateur à réaliser le premier, le deuxième, le troisième, le quatrième ou le cinquième aspect. Conformément à la présente invention, selon un huitième aspect, on propose un support lisible par ordinateur comprenant des instructions qui, lorsque les instructions sont exécutées par un ordinateur, amènent l'ordinateur à réaliser le premier, le deuxième, le troisième, le quatrième ou le cinquième aspect. Conformément à la présente invention, selon un neuvième aspect, on propose une structure d’identifiant de ressource de réseau sécurisé, comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et une partie fragment et/ou requête comprenant une structure de données signée cryptographiquement. Conformément à la présente invention, selon un dixième aspect, on propose une structure d'identifiant de ressource de réseau sécurisé, comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, associant les composantes de schéma et de chemin et un suffixe de partie chemin comprenant un identifiant unique et une structure de données signée cryptographiquement. Les avantages ci-dessus de la présente invention, ainsi que d'autres, vont être à présent décrits en référence aux dessins annexés, dans lesquels : la FIG. 1 présente un exemple d’un Cachet Électronique Visible dans un format Datamatrix ; la FIG. 1 présente un exemple d’un Cachet Électronique Visible dans un format QR code ; la FIG. 1 présente un exemple d’un Cachet Électronique Visible dans un format Han Xin ; la FIG. 2 présente un exemple d’un URI codé dans un format Datamatrix ; la FIG. 2 présente un exemple d’un URI codé dans un format QR code ; la FIG. 2 présente un exemple d’un URI codé dans un format Han Xin ; la FIG. 3 présente un exemple d’un URI incorporant une composante cryptographique, codé dans un format Datamatrix ; la FIG. 3 présente un exemple d’un URI incorporant une composante cryptographique, codé dans un format QR code ; la FIG. 3 présente un exemple d’un URI incorporant une composante cryptographique, codé dans un format Han Xin ; la FIG. 4 résume un procédé selon ce premier ensemble de modes de réalisation ; la FIG. 4 résume un procédé selon ce deuxième ensemble de modes de réalisation ; la FIG. 5 présente un procédé de décodage d'une structure d'identifiant de ressource de réseau sécurisé tel que présenté en référence à la FIG. 4 ; la FIG. 5 présente un procédé d'accès à une ressource de réseau selon un mode de réalisation ; la FIG. 6 présente divers scénarios de cas d'utilisation découlant de modes de réalisation ; la FIG. 7 montre un système informatique générique convenant à la mise en œuvre de modes de réalisation de l'invention ; et la FIG. 8 montre un dispositif type smartphone adaptable pour constituer un mode de réalisation. Description détaillée Une structure de données très largement adoptée est l'URI (acronyme en langue anglaise de "Uniform Resource Identifier", ou Identifiant Uniforme de Ressource) Web. L'URI est une chaîne de caractères utilisée pour identifier une ressource. L'URL (acronyme en langue anglaise de "Uniform Resource Locator" ou Localisateur Uniforme de Ressource) Web peut être une ressource d'informations telle qu'une page Web – comme le décrit le document intitulé Request for Comments RFC 3986 : Uniform Resource Identifier (URI) : Generic Syntax. La structure de base de l'URI s'établit comme suit : scheme : [//authority][/path][?query][#fragment] À titre d'exemple, un URI type peut prendre la forme : http://machine.domain:port/path/data?key=value#fragid Les informations de chemin de l'URI se composent d'une séquence de segments de chemin séparés par une barre oblique ("/"). La composante de chemin contient des données, habituellement organisées sous forme hiérarchique. Le chemin se termine par le premier point d'interrogation ("?"), à la fin de l'URI, ou par le caractère ("#") – comme le décrit RFC 3986 Section-3.3. La requête de l'URI contient des données non hiérarchiques qui, associées à des données dans la composante de chemin, servent à identifier une ressource dans le cadre du schéma et de l'autorité de nommage de l'URI. Les données dans la composante de chemin hiérarchique, associées à des données dans la composante de requête non hiérarchique, servent à identifier une ressource dans le cadre du schéma et de l'autorité de nommage de l'URI. La composante de requête est indiquée par le premier point d'interrogation ("?"), suivi de l'esperluette (“&”). Les composantes de requête sont utilisées pour véhiculer des informations d'identification sous la forme de paires "&key=value" – comme le décrit RFC 3986 Section-3.4. Exemple d'un URI formé selon la norme GS1 Digital Link : https://zt.ag/01/03779000004901/22/01/10/001/21/0001 https://zt.ag/01/03779000004901/22/01/10/001?17=230701 Dans ce cas, la valeur “230701” peut par exemple représenter une date d'expiration d'un produit. Un exemple d'un URI comprenant un URL AutoID contenant des données selon la norme ANSI MH10.8.2 peut prendre la forme : https://zt.ag/?.8P=03779000004901&.1T=001&.S=0001 https://zt.ag/?.8P=03779000004901&.1T=001. 5D=230701036 Dans ce cas, la valeur “230701” peut par exemple représenter une date d'expiration d'un produit, et 036 indique le format de date AAMMJJ. La composante d'identifiant de fragment URI d'un URI permet l'identification indirecte d'une ressource secondaire par renvoi à une ressource primaire et à des informations d'identification additionnelles. La ressource secondaire identifiée peut représenter une portion ou un sous-ensemble de la ressource primaire, une vue sur des représentations de la ressource primaire, ou une autre ressource définie ou décrite par ces représentations – comme le décrit RFC 3986 Section-3.5. Une composante d'identifiant de fragment est indiquée par la présence d'un caractère dièse ("#") et se termine à la fin de l'URI. Une utilisation type d'un identifiant de fragment URI vise à fournir un lien direct vers une section particulière au sein d'une page HTML, à savoir un document Web. Le caractère dièse ("#") permet d'appeler une page HTML. Cet appel est neutre et n'a aucune incidence sur l'obtention de la page. C'est le navigateur local qui réalise la navigation locale dans la page obtenue. https://zt.ag/01/03779000004901/22/01/10/001/21/001#hello_world https://zt.ag/?.8P=03779000004901&.1T=001&.S=0001#hello_world Il est courant, par ailleurs, de représenter les URI dans un format lisible par machine. Le format lisible par machine peut prendre une forme quelconque. En guise d'exemple : Il peut être lisible optiquement, par exemple sous la forme d'une image, d'un code alphanumérique, ou d'un code-barres à une, deux (notamment les “QR codes") ou trois dimensions, ou d'un code holographique. Le code peut être associé à un autre contenu visuel, par exemple par stéganographie ou tout autre code invisible. La lecture optique, au moyen d'une caméra, d'un scanner laser, etc., offre un avantage sécuritaire par rapport aux communications radio en ce sens qu'elle nécessite une ligne de visée et un alignement déterminé avec l'objet, ce qui rend difficile la lecture furtive de l'objet. Les dispositifs grand public étant bien souvent dotés d'une caméra, ces lecteurs peuvent par conséquent être mis en œuvre sans nécessiter l'ajout de matériel dédié spécialisé. Il peut être lisible magnétiquement, par exemple sous la forme d'une bande magnétique. Il peut être lisible par communication radio, par exemple par des systèmes RFID, NFC ou Bluetooth à faible consommation d'énergie ("Bluetooth Low Energy" en langue anglaise). Les communications radio présentent l'avantage de ne pas nécessiter de contact physique, ni même de ligne de visée entre l'objet et un lecteur. La communication radio à courte portée renforce la sécurité et permet, de par sa conception, d'éviter les attaques par interception. L'utilisation de plus en plus répandue des communications radio à courte portée dans les dispositifs grand public permet la mise en œuvre de tels lecteurs sans recours à du matériel spécialisé. Il peut être lisible acoustiquement, ou sous forme d'une onde sonore émise par l'objet, soit en continu, soit périodiquement, soit en réponse à une stimulation par un utilisateur, soit générée par le dispositif utilisateur mettant en œuvre l'invention. Cette stimulation peut être mécanique, sonique, électronique, optique ou être réalisée par tout autre mécanisme approprié. Si les ondes sonores ne nécessitent pas de contact ni même de ligne de visée entre l'objet et un lecteur, elles sont toutefois intrinsèquement sujettes à la diffusion et aux interférences, ce qui limite leur portée d'utilisation. À cet égard, dans certaines mises en œuvre, les ondes sonores peuvent offrir un compromis entre les caractéristiques d'une lecture optique et celles d'une lecture radio. Les dispositifs grand public étant souvent équipés d'un microphone (ainsi que d'un haut-parleur), ces lecteurs (respectivement, émetteurs sonores) peuvent donc être mis en œuvre sans recours à du matériel spécialisé. Il peut être lisible sous forme d'un code tactile ou palpable, par exemple sous la forme de bosses ou de creux poinçonnés, lisible par des moyens optiques ou mécaniques. Une approche privilégiée consiste à utiliser un format graphique lisible par machine tel qu'un code Datamatrix, un QR code or un code Han Xin. La FIG. 2 présente un URI codé dans un format Datamatrix. La FIG. 2 montre en particulier une représentation de l'URI https://zt.ag/01/03779000004901/22/01/10/001/21/0001 codé dans un format Datamatrix. La FIG. 2 présente un exemple d'un URI codé dans un format QR code. La FIG. 2 montre en particulier une représentation de l'URI https://zt.ag/01/03779000004901/22/01/10/001/21/0001 codé dans un format QR code. La FIG. 2 présente un exemple d'un URI codé dans un format Han Xin. La FIG. 2 montre en particulier une représentation de l'URI https://zt.ag/01/03779000004901/22/01/10/001/21/0001 codé dans un format Han Xin. Un URI, par exemple codé dans un QR Code ou autre, peut être lu par la plupart des dispositifs mobiles modernes dans la mesure où les dispositifs mobiles existants sont en grande majorité dotés d'une fonctionnalité permettant de scanner ces Codes à l'aide uniquement de la caméra. Par ailleurs, un URL peut pointer vers un serveur hôte distant, mais être traité localement dans le dispositif, ou à distance sur un autre serveur distant différent de celui désigné dans l'URL, défini par l'application mobile sur le dispositif. C'est ce qu'un terminal point de vente (ou POS pour "Point Of Sale" en langue anglaise) est capable de faire avec un URI comprenant un URL AutoID contenant des données en conformité avec, par exemple, la norme GS1 Digital Link ou la norme ANSI MH10.8.2, afin d'extraire le GTIN (acronyme en langue anglaise de "Global Trade Item Number" ou Code Article International, Identifiant d'Application 01 ou Identifiant de Données .8P dans la norme ANSI MH10.8.2) et déterminer ainsi le prix correct d'un produit donné. Conformément à la présente invention, des informations cryptographiques sont incorporées dans une structure d'URI. On propose en particulier, selon une première approche, un procédé de définition d’une structure d'identifiant de ressource de réseau sécurisé, la structure d'identifiant de ressource de réseau sécurisé comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et des parties fragment et/ou requête comprenant une structure de données signée cryptographiquement. À cet égard, le mécanisme proposé ne repose pas sur la signature de la partie URL initiale de l'URI mais sur la signature d'un segment indépendant, qui peut ou non être partiellement associé à la valeur de l'URL. À ce titre, un VDS - ou une autre structure signée cryptographiquement - peut être rattaché à un URL quelconque, lequel peut ou non être associé à la structure de données signée cryptographiquement proprement dite. La structure de données signée cryptographiquement peut obéir à un format de Cachet Numérique Visible, à un modèle de Justificatifs Vérifiables ("Verifiable Credentials" en langue anglaise) ou à tout autre modèle cryptographique, notamment par exemple le schéma cryptographique PKI (acronyme en langue anglaise de "Public Key Infrastructure" ou Infrastructure à Clés Publiques). Sur cette base et à titre d'exemple, l'URI qui suit peut être obtenu : HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001#3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG Dans cet exemple, la partie qui suit le symbole # constitue un fragment conforme à la norme RFC 3986, et c'est cette partie qui incorpore le contenu cryptographique. En incorporant le contenu cryptographique dans la partie fragment, l'URI reste intelligible pour tout dispositif ou système standard capable d'interpréter des URI génériques. La partie hiérarchique pointe vers des ressources additionnelles qui peuvent permettre ensuite au dispositif ou au système de gérer la partie cryptographique. Au pire des cas, la partie fragment peut être simplement ignorée. De plus, le contenu cryptographique pourrait également être traité à distance par le serveur hôte distant, ou par tout autre serveur distant, différent de celui désigné dans l'URL, défini par l'application mobile sur le dispositif. Ceci peut être réalisé en configurant le dispositif local pour qu'il reconnaisse le format général du contenu cryptographique et qu'il contacte en conséquence le serveur distant, ou par adressage de données incorporées dans la partie fragment. HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001#3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG Ainsi, si d'ordinaire le dispositif devrait théoriquement accéder à la ressource indiquée par HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001, du fait du déchiffrement du contenu cryptographique 3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG selon des modes de réalisation, le dispositif pourra accéder à toute autre ressource éventuellement désignée dans le contenu cryptographique (et/ou indiquée par une partie sélectionnée des parties schéma et/ou chemin), en vertu d'une programmation ou d'une autre façon. Facultativement, l'élément de chemin de l'Identifiant Uniforme de Ressource sécurisé peut pointer vers un référentiel duquel peut être extraite une application logicielle apte à vérifier que l'Identifiant Uniforme de Ressource correspond à la structure de données signée. En guise d'exemple, l'URI (ou le code graphique qui la représente) pourrait être lu afin de télécharger et d'installer une application mobile sécurisée depuis la ressource de réseau indiquée par la partie hiérarchique de l'URI. Cette application pourrait ensuite être utilisée pour (re)scanner ce même URI dans le but d'en lire et d'en traiter la partie cryptographique. De préférence, pour pouvoir être combiné avec un URI, le contenu cryptographique devra contenir un jeu de caractères qui répond aux critères de l'URL. On se gardera de préférence d'utiliser des caractères autres que ceux figurant dans la bibliothèque Base64-safe URL ('A' à 'Z', 'a' à 'z', '0' à '9', '-' et '_'). Facultativement, le procédé peut comprendre une étape supplémentaire de codage de la structure d'identifiant de ressource réseau sécurisé dans un code lisible par machine, comme par exemple un code Datamatrix, un code Han Xin, un code JAB ou un QR code. Comme indiqué précédemment, le fragment (qui suit le symbole #) dans un URL n'est généralement pas communiqué par le navigateur Internet et reste local. Aussi, son utilisation proposée dans le contexte d'un message sécurisé reste de ce fait locale, pour une sécurité renforcée. Une telle utilisation peut être exclusivement locale par nature, en dépit du champ d'utilisation habituel d'un URL. À ce titre, les modes de réalisation basés sur l'utilisation de la partie fragment sont jugés particulièrement avantageux. La FIG. 3 présente un exemple d'un URI incorporant une composante cryptographique, codé dans un format Datamatrix. La FIG. 3 montre en particulier une représentation de l'URI HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001#3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG codé dans un format Datamatrix. La FIG. 3 présente un exemple d'un URI incorporant une composante cryptographique, codé dans un format QR code. La FIG. 3 montre en particulier une représentation de l'URI HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001#3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG codé dans un format QR code. La FIG. 3 présente un URI incorporant une composante cryptographique, codé dans un format Han Xin. La FIG. 3 montre en particulier une représentation de l'URI HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001#3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG codé dans un format Han Xin. La combinaison d'un contenu cryptographique tel qu'un Cachet Numérique Visible et d'un URI dans une symbologie de code-barres à deux dimensions, telle qu'un QR Code, permet non seulement une lecture et un traitement locaux par une application particulière, mais aussi une lecture commode par la plupart des dispositifs mobiles et autres dispositifs adéquats (smartphones, tablettes, ordinateurs portables, téléviseurs intelligents, etc.) sans recours à une application particulière. Si le mode de réalisation de la figure 3 utilise la partie fragment d'un URI pour l'incorporation d'un contenu cryptographique, d'autres approches sont toutefois envisagées. Selon un ensemble de variantes de réalisation, un contenu cryptographique peut être ajouté à une partie requête de l'URI. Conformément à RFC 3986 Section-3.5, une partie requête est délimitée par la séquence variable = valeur. À noter que les parties requête sont également définies par la présence d'un symbole “?” ou “&”, et que les requêtes prennent, en première instance, la forme “?Key1=val1” et, dans les instances ultérieures, la forme “&key2=val2. Comme le symbole “=” apparaît dans tous les cas (et nulle part ailleurs dans un URI valide), il peut être systématiquement considéré comme indicateur de l'instanciation d'une requête. L'URI qui suit est un exemple d'incorporation d'un contenu cryptographique dans une partie requête, illustrant un codage GS1 Digital Link. HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/0001?250=3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG L'URI qui suit est un exemple d'incorporation d'un contenu cryptographique dans une partie requête, l'URI comprenant un URL AutoID contenant des données en conformité avec le codage ANSI MH10.8.2. .HTTPS://ZT.AG/?.8P=03779000004901&.1T=001&.S=3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG L'URI qui suit est un exemple d'incorporation d'un contenu cryptographique dans une partie requête, l'URI comprenant un URL AutoID contenant des données en conformité avec le codage ANSI MH10.8.2 utilisant le code du numéro de série secondaire. HTTPS://ZT.AG/?.8P=03779000004901&.1T=001&.S=0001&.30S=3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG La FIG. 4 résume un procédé selon ce premier ensemble de modes de réalisation. Comme le montre la FIG. 4 , le procédé débute à l'étape 400 avant de passer à l'étape 405 à laquelle sont définies les composantes de schéma et de chemin d'un URI. Le procédé passe ensuite à l'étape 410 à laquelle une partie fragment ou requête cryptographique est associée aux composantes de schéma et de chemin dans la structure de l'URI. Le procédé peut ensuite facultativement passer à l'étape 415 de codage de l'URI ainsi obtenu dans un code lisible par machine. Quoique non représentées, le procédé peut également comprendre des étapes supplémentaires décrites ici. On comprendra que, dans certains modes de réalisation, les étapes 405 et 410 peuvent être réalisées selon une séquence quelconque ou en parallèle et, comme exposé plus en détail ci-après, peuvent être répétées pour créer de multiples parties fragment ou requête. Dans un autre ensemble de variantes de réalisation, le contenu cryptographique peut être ajouté à l'URI sous la forme d'un suffixe de partie chemin à la fin du segment hiérarchique. Comme évoqué plus haut, un identifiant de ressource de réseau sécurisé selon des modes de réalisation peut servir de base pour une étiquette produit sécurisée apposable sur un produit, puis être scanné par un client ou à un autre stade de la chaîne d'approvisionnement pour confirmer des caractéristiques du produit sur lequel l'étiquette est apposée. La norme GS1 Digital Link, par exemple, définit différents niveaux de granularité, depuis la référence produit (01 GTIN), jusqu'au numéro de série (21 S/N) qui identifie de manière unique un article particulier, en passant par le numéro de Lot (10 LOT). On comprendra que la chaîne de caractères constituant le contenu cryptographique pour un produit particulier devrait théoriquement être elle aussi unique. Dans ces conditions, on pourra considérer le contenu cryptographique de la chaîne de caractères comme le numéro de série pour le produit en question sans pour autant remettre en cause la logique d'étiquetage. À titre d'exemple, la norme GS1 Digital Link définit l'Identifiant d'Application "21" du Numéro de Série (désigné par l'acronyme en langue anglaise S/N pour "Serial Number"). Sur cette base, le dispositif utilisateur qui reçoit l'URI selon l'invention peut identifier la structure caractéristique d'un élément GS1 Digital Link, et la présence du code 21 indiquant que la valeur qui suit est un identifiant unique, puis tenter spéculativement de décoder la suite en partant de l'hypothèse qu'il peut s'agir d'un contenu cryptographique au sens d'un mode de réalisation. Si la suite est déchiffrée avec succès, elle peut alors être utilisée de la même manière que dans d'autres modes de réalisation décrits ici et, dans le cas contraire, elle peut être marquée comme non sécurisée et traitée de la même manière que d'autres URI traditionnels. À noter que, comme le contenu qui suit le code 21 constitue dans tous les cas une valeur unique, l'utilisation d'un contenu cryptographique dans ce segment n'empêche pas l'utilisation de la même chaîne pour désigner une ressource de réseau. Un exemple de cette approche est donné par l'URI qui suit HTTPS://ZT.AG/01/03779000004901/22/01/10/001/21/3YBGMNJGEUM43777DRR637K2AA3NSNDIOR2HA4Z2F4XXU5BOMFTS6MBRF4YDGNZXHEYDAMBQGA2DSMBRF4ZDELZQGEXTCMBPGAYDCLZSGEXTAMBQGHQIZDE4VZOB4HZAVTU27JQNQHKCZOKG4ZQP3L3LK5BLKULDCGEMXHGTB2SMS7FUAUYF36K226FUDIKFZUKMYAFMW27OIXIAIYIAAZUG On propose en conséquence un procédé de décodage d'une structure d'identifiant de ressource de réseau sécurisé, le procédé comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé selon des modes de réalisation exposés plus haut, l'identification d'une structure caractéristique d'un schéma connu pour être utilisé avec des structures d'identifiant de ressource de réseau sécurisé selon des modes de réalisation exposés plus haut, l'isolement d'une partie de ladite structure d'identifiant de ressource de réseau sécurisé connue comme correspondant à un identifiant unique selon ledit schéma, et la tentative de déchiffrement de ladite partie isolée de ladite structure d'identifiant de ressource de réseau sécurisé. Facultativement, on peut proposer une étape supplémentaire de détermination de l'impossibilité de déchiffrer ladite partie isolée de ladite structure d'identifiant de ressource de réseau sécurisé, et d'émission d'une indication que ladite structure d'identifiant de ressource de réseau sécurisé n'est pas jugée sécurisée. Facultativement, on pourra, lorsque ladite partie isolée de ladite structure d'identifiant de ressource de réseau sécurisé est déchiffrée avec succès, proposer une étape supplémentaire de vérification que ladite composante de chemin correspond à ladite structure de données signée. Le procédé peut en outre comprendre, facultativement, des étapes supplémentaires telles qu'évoquées ici ayant trait à une quelconque opération réalisée sur la base du déchiffrement du contenu cryptographique d'une structure d'identifiant de ressource de réseau sécurisé décrite ici. La FIG. 4 résume un procédé selon ce deuxième ensemble de modes de réalisation. Comme le montre la FIG. 4 , le procédé débute à l'étape 400 avant de passer à l'étape 405 à laquelle sont définies les composantes de schéma et de chemin d'un URI. Le procédé passe ensuite à l'étape 411 à laquelle un suffixe de chemin cryptographique à identifiant unique est associé aux composantes de schéma et de chemin dans la structure de l'URI. Le procédé peut ensuite facultativement passer à l'étape 415 de codage de l'URI ainsi obtenu dans un code lisible par machine. Quoique non représentées, le procédé peut également comprendre des étapes supplémentaires décrites ici. On comprendra que, dans certains modes de réalisation, les étapes 405 et 411 peuvent être réalisées selon une séquence quelconque ou en parallèle et, comme exposé plus en détail ci-après, peuvent être répétées pour créer de multiples parties suffixe de chemin. Qui plus est, dans certains modes de réalisation, les étapes 410 et 411 peuvent être réalisées selon une séquence quelconque ou en parallèle et, comme exposé plus en détail ci-après, peuvent être répétées pour créer des multiples parties fragment, requête ou suffixe de chemin. Par ailleurs, on peut, sur cette base, proposer un procédé d'association d'un identifiant unique à un produit, le produit appartenant à une classification arborescente de produit, le procédé comprenant les étapes de composition d'un URI sur la base de la classification dudit produit selon ladite classification arborescente de produit, d'obtention d'une structure de données signée cryptographiquement au regard d'un identifiant de ressource de réseau sécurisé tel que présenté ici, et d'association de la structure de données signée cryptographiquement au produit en tant qu'identifiant unique. On comprendra qu'une suite quelconque de caractères adéquate qui ne peut être résolue en une ressource Web valide peut être définie à cet effet à la fin de la partie caractérisante. À ce titre, on propose un procédé de définition d’une structure d'identifiant de ressource de réseau sécurisé, ladite structure d'identifiant de ressource de réseau sécurisé comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et un suffixe de partie chemin comprenant un identifiant unique et une structure de données signée cryptographiquement signée à l'aide d'une infrastructure de cryptographie. Il y a lieu de souligner que des structures selon des modes de réalisation peuvent incorporer de multiples parties requête et/ou fragment et/ou suffixe de chemin, soit avec de multiples parties du même type soit avec une combinaison de parties de types différents (toujours dans le respect des critères, de sorte, par exemple, qu'une partie fragment suive systématiquement la dernière partie suffixe de chemin). À cet égard, un certain nombre de structures possibles ont été décrites, chacune constituant un identifiant de ressource de réseau sécurisé selon des modes de réalisation. On peut envisager un certain nombre d'utilisations possibles pour la partie contenu cryptographique de l'identifiant de ressource de réseau sécurisé défini ici. Dans certains modes de réalisation, on peut envisager une relation plus étroite entre la partie hiérarchique de l'URI et la partie cryptographique. Plus précisément, la partie cryptographique peut incorporer une version chiffrée de la partie hiérarchique proprement dite, ou une autre représentation du contenu de la partie hiérarchique proprement dite, la partie cryptographique pouvant ainsi servir à authentifier la partie hiérarchique. Cette représentation peut comprendre un hachage, une signature, ou une autre représentation de la partie hiérarchique. De fait, comme il est généralement souhaitable de limiter la taille de l'identifiant de ressource de réseau sécurisé dans sa globalité et du contenu cryptographique en particulier, la représentation peut se limiter à une partie seulement de la partie hiérarchique, par ex. pour n'en préciser que le domaine. À ce titre, et afin de protéger un URI Web en tant que tel (autrement dit, les composantes de schéma et de chemin identifiant une ressource de réseau, en excluant un suffixe de partie chemin), la composante cryptographique peut contenir les données déjà disponibles dans la partie chemin et la partie chaîne de requête de l'URI Web. Cette approche peut constituer un procédé d'accès à une ressource de réseau, comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé telle qu'exposée ci-dessus, l'extraction d'une clé publique pour la structure de données signée cryptographiquement, la vérification que la composante de chemin (et, le cas échéant, toute autre partie de l'identifiant de ressource de réseau sécurisé qui n'appartient pas au contenu cryptographique) correspond à la structure de données signée et, en réponse à ladite vérification, l'accès à la ressource de réseau désignée par ledit identifiant de ressource de réseau sécurisé. Dans le but de protéger une destination distante de l'URI Web, le contenu cryptographique peut contenir certaines données relatives à la destination distante ou au contenu à cette destination, notamment un hachage d'un document à la destination, lequel peut être vérifié au moment de la résolution du contenu cryptographique. À ce titre, un procédé d'accès à une ressource de réseau peut comprendre une étape supplémentaire de réception de la structure d'identifiant de ressource de réseau sécurisé au niveau d'un dispositif utilisateur, ladite étape de vérification que ledit Identifiant Uniforme de Ressource correspond à ladite structure de données signée étant réalisée au niveau soit du dispositif utilisateur soit d'un serveur distant identifié par ledit Identifiant Uniforme de Ressource. Dans certains modes de réalisation, le contenu cryptographique peut comprendre, en sus ou en variante, une charge utile de données supplémentaire. Comme évoqué plus haut, un identifiant de ressource de réseau sécurisé selon des modes de réalisation peut servir de base pour une étiquette produit sécurisée apposable sur un produit, puis être scanné par un client ou à un autre stade de la chaîne d'approvisionnement pour confirmer des caractéristiques du produit sur lequel l'étiquette est apposée. Dans ce contexte, la charge utile de données supplémentaire peut comprendre un identifiant produit, un numéro de série, une étiquette qualité, un label qualité, une indication de provenance géographique, et autres. En sus ou en variante, la charge utile de données peut incorporer une indication d'autres caractéristiques inhérentes du produit difficiles à déterminer par ailleurs, telles que la date de fabrication, la teneur en sucres, la teneur en alcool, etc. L'incorporation de ces données dans la composante cryptographique permet de les intégrer de façon permanente et indélébile à l'identifiant de ressource de réseau sécurisé. Toute divergence entre ces données et des données correspondantes, par exemple figurant sur une page Web indiquée par l'élément de chemin du même identifiant de ressource de réseau sécurisé, pourra être signalée comme preuve de falsification ou de tromperie. Une identité produit, comprenant la référence produit (01 GITN), le numéro de Lot (10 LOT) ou le numéro de série (21 S/N), peut être fournie à l'un quelconque des niveaux de granularité stipulés par la norme GS1 Digital Link par exemple. À ce titre, un procédé d'accès à une ressource de réseau peut comprendre une étape supplémentaire d'identification d'une caractéristique de ladite structure d'identifiant de ressource de réseau sécurisé associée à une ressource de réseau supplémentaire, et d'extraction de données de référence à partir de la ressource de réseau supplémentaire, et de comparaison des données de référence à la charge utile de données supplémentaire ; et, en outre, en cas de détection d'une discordance entre les données de référence et ladite charge utile de données supplémentaire, d'émission d'un message d'alerte et/ou de déconnexion de ladite ressource de réseau. La FIG. 5 présente un procédé de décodage d'une structure d'identifiant de ressource de réseau sécurisé, tel que présenté en référence à la FIG. 4 . Comme le montre la figure, le procédé débute à l'étape 500 à laquelle est reçue une structure d'identifiant de ressource de réseau sécurisé selon des modes de réalisation tels qu'exposés ici. Le procédé passe ensuite à l'étape 501 à laquelle est identifiée une structure caractéristique d'un schéma connu comme étant utilisé avec des structures d'identifiant de ressource de réseau sécurisé selon des modes de réalisation tels qu'exposés ici. Cette structure caractéristique étant ainsi identifiée, le procédé passe à l'étape 502 à laquelle est isolée une partie de ladite structure d'identifiant de ressource de réseau sécurisé connue comme correspondant à un identifiant unique conformément audit schéma. À l'étape 503, il est tenté de déchiffrer la partie isolée de la structure d'identifiant de ressource de réseau sécurisé. Le procédé peut ensuite prendre fin à l'étape 504. En variante, le procédé peut reboucler sur l'étape 501 pour un nouvel URI. La FIG. 5 présente un procédé d'accès à une ressource de réseau selon un mode de réalisation. La FIG. 5 présente plus particulièrement un procédé d'accès à une ressource de réseau selon la description précédente. Plus précisément, comme le montre la figure, le procédé débute à l'étape 505 avant de passer à l'étape 510 à laquelle est reçu un identifiant de ressource de réseau sécurisé, par exemple tel qu'obtenu à la suite du procédé des figures 4a et/ou 4b. Le procédé passe à l'étape 515 à laquelle est extraite une clé de chiffrement utilisée pour déchiffrer le contenu cryptographique de l'identifiant de ressource de réseau sécurisé. Le procédé peut ensuite passer à l'étape facultative 520 à laquelle le contenu cryptographique déchiffré est comparé aux parties schéma et chemin de l'identifiant de ressource de réseau sécurisé. Le procédé peut alors passer à l'étape facultative 525 à laquelle s'effectue l'accès à la ressource désignée par le chemin vérifié et, à l'étape 530, des données de référence sont extraites et comparées à la charge utile facultative de l'identifiant de ressource de réseau sécurisé. En cas de détection d'une discordance, par exemple suite aux comparaisons aux étapes 520 ou 535, déterminée à l'étape 540, le procédé peut passer à l'étape 545 à laquelle une alerte peut être émise ou la ressource de réseau peut être déconnectée. On comprendra que les étapes de la FIG. 5 peuvent être réalisées selon une séquence différente, et que toute combinaison des étapes facultatives peut être réalisée. Par conséquent, le contenu cryptographique peut également contenir des informations additionnelles uniquement disponibles lors de l'utilisation de l'application sécurisée. La FIG. 6 présente divers scénarios de cas d'utilisation découlant de modes de réalisation. Comme le montre la FIG. 6 , un scénario peut partir d'un URI traditionnel 612 ou d'un URI formé selon l'un quelconque des modes de réalisation précédents 611. Par ailleurs, on peut prévoir un dispositif traditionnel 622 incorporant uniquement une application caméra générique permettant de scanner un QR code par exemple, et un dispositif augmenté 612 doté d'un logiciel apte à déceler un URI formé selon l'un quelconque des modes de réalisation précédents et, au besoin, à le décoder. Un identifiant de ressource de réseau sécurisé selon des modes de réalisation représenté dans un Code à deux dimensions (tel qu'un QR Code) 611 peut être scanné par une quelconque application mobile sécurisée compatible 621 comme représenté par la flèche 611a. Suite au scan par une application mobile sécurisée compatible 621 (par exemple l'application ”Otentik Code Reader”), l'application mobile 621 peut traiter et afficher la liste d'informations relatives au cachet électronique visible et, éventuellement, inviter à pointer vers l'URI de destination désigné dans l'URI initial. Si le serveur de destination est un serveur sécurisé 631, elle peut indiquer que le lien entre le Code et la destination du contenu est fiable dans la mesure où la demande émane de l'application mobile sécurisée. L'accès peut alors s'effectuer comme représenté par la flèche 621a. L'invite est facultative puisque l'utilisateur peut par ailleurs être connecté au lien de destination sécurisé et vérifié. Un identifiant de ressource de réseau non sécurisé 612 (autrement dit, un URI traditionnel dépourvu du contenu cryptographique exposé ici) dans un Code à deux dimensions peut toujours être scanné par une application mobile sécurisée compatible 621 comme représenté par la flèche 612b. Une fois l'identifiant scanné, l'application mobile peut afficher que l'URL n'est pas sécurisé et inviter à pointer vers la destination désignée dans l'élément de chemin de l'URL. Dans l'hypothèse où un URI traditionnel 612 indique un serveur sécurisé 631, l'accès peut toutefois être accordé mais sans exécuter de fonctions de sécurité additionnelles, comme représenté par la flèche 621a. Le dispositif 622 pourra ainsi comprendre une quelconque application mobile standard (comme le lecteur de QR Code par défaut dans la caméra de l'application embarquée sur un iPhone ou un smartphone Android). Le cas de figure classique d'une lecture d'un URI traditionnel 612 est représenté par la flèche 612a. Que l'URI 612 pointe ou non vers un serveur sécurisé, l'adresse désignée dans l'URI traditionnel 612 sera résolue de la manière habituelle, comme représenté par la flèche 622a. Dans un scénario dans lequel le dispositif 622 lit un identifiant de ressource de réseau sécurisé dans un code graphique 611 comme représenté par la flèche 611b, la ressource de destination désignée dans l'élément de chemin de l'identifiant de ressource de réseau sécurisé pourra être accédée de manière analogue comme représenté par la flèche 622b. Si le serveur de destination indiqué est un serveur sécurisé (autrement dit capable de déchiffrer le contenu cryptographique) 631, il peut alors traiter l'identifiant de ressource de réseau sécurisé complet et confirmer que le lien entre l'URI et la ressource est fiable. Si le serveur de destination indiqué n'est pas un serveur sécurisé, aucune sécurité supplémentaire n'est offerte, mais l'accès à l'URI peut continuer de s'effectuer de la manière habituelle. Un cas particulier est représenté par les flèches 621c et 622c, dans lequel une application locale (capable ou non de réaliser des opérations de sécurité selon des modes de réalisation) est configurée pour réacheminer des demandes d'accès référencées par un URI (conforme ou non à des modes de réalisation) par exemple en remplaçant des éléments de niveau supérieur de la partie hiérarchique. L'utilisation d'un URI pour coder l'identifiant d'objet offre une plateforme souple et ubiquitaire pour le codage et l'interprétation. Le codage de l'identifiant est gage de sécurité et permet d'apporter une meilleure preuve de l'intégrité et de la provenance des données. L'identification du codage dans l'URI proprement dit améliore l'autonomie du système d'identification du fait que davantage d'informations sont disponibles localement. Le nom du schéma peut être un protocole URI ou un nom de schéma existant approprié quelconque, ou peut être un nom de schéma désigné aux fins de la présente invention. Les systèmes d'exploitation embarqués ou autres logiciels de plateforme seront généralement configurés de manière à pouvoir gérer des URI selon divers schémas ou protocoles, et à gérer chacun selon ses propres caractéristiques et critères. Une configuration adaptée de ces logiciels permettra à ces dispositifs d'interpréter correctement le schéma adopté pour la mise en œuvre de la présente invention, quel qu'il soit. L'identification du codage dans l'URI proprement dit offre la possibilité de décoder localement l'identifiant d'objet. Les systèmes connus sont contraints de communiquer avec des systèmes distants pour l'identification, le décodage et la vérification des identifiants, alors que, selon la présente invention, ces activités peuvent faire l'objet d'une mise en œuvre locale. En d'autres termes, les systèmes mettant en œuvre l'invention n'ont pas besoin de disposer d'un accès réseau. Ce mode de réalisation offre l'avantage de permettre une vérification purement locale. Les algorithmes et leurs paramètres associés peuvent tous être stockés dans le dispositif utilisé pour le processus de vérification. La bibliothèque d'algorithmes et de leurs paramètres associés peut être statique ou mise à jour régulièrement, par exemple dès lors qu'une connectivité réseau est disponible. La possibilité d'une mise à jour régulière de la bibliothèque renforce la sécurité de la solution. Dans certains modes de réalisation, l'URI peut facultativement être défini de manière à être résolu en un emplacement réseau distant ou un site Web distant, en sus ou à la place de l'appel d'une ressource locale. L'emplacement réseau distant peut mettre en œuvre certains aspects du processus de vérification. L'appel d'un site Web de cette manière peut également permettre d'offrir un mécanisme de gestion harmonieuse de situations dans lesquelles le dispositif local est incapable, pour une raison ou une autre, de décoder l'identifiant d'objet. L'appel d'un site Web de cette manière peut également permettre d'offrir un mécanisme de traitement d'échecs de la vérification, soit sous forme d'un mécanisme de notification à l'utilisateur des implications de l'échec de la vérification, soit sous forme d'un mécanisme de signalement de l'échec de la vérification à un serveur distant à des fins de surveillance ou d'audit. L'appel d'un site Web de cette manière peut en outre permettre d'offrir un mécanisme de présentation d'informations auxiliaires à un utilisateur, parallèlement au processus de vérification. Selon un mode de réalisation supplémentaire des procédés décrits en référence à la figure 5, le procédé peut comprendre une étape supplémentaire de notification du résultat de ladite vérification à un utilisateur. Tout mécanisme commode pourra être utilisé à cette fin, par exemple par affichage d'un message sur une unité d'affichage du dispositif utilisateur mettant en œuvre le procédé, par émission d'un son, etc. Des modes de réalisation tirent donc profit de certaines caractéristiques de la spécification URI pour incorporer un contenu cryptographique de manière à ne pas entraver le fonctionnement normal d'un URI. Le contenu cryptographique peut ensuite être utilisé pour garantir l'authenticité du chemin défini dans la partie non chiffrée. Le chemin peut également servir pour pointer un dispositif de lecture vers une ressource de réseau apte à réaliser l'opération de déchiffrement, ou pour une clé de déchiffrement. Le procédés exposés peuvent prendre la forme d'un mode de réalisation intégralement logiciel (par ex. FPGA), d'un mode de réalisation intégralement logiciel (par exemple pour commander un système selon l'invention) ou d'un mode de réalisation contenant des éléments à la fois matériels et logiciels. Parmi les modes de réalisation logiciels, on pourra citer, sans toutefois s'y limiter, un micrologiciel (ou "firmware" dans la terminologie anglo-saxonne), un logiciel résident, un microcode, etc. L'invention peut prendre la forme d'un produit-programme informatique accessible à partir d'un support exploitable par ordinateur ou lisible par ordinateur, fournissant un code de programme destiné à être utilisé par, ou en relation avec, un ordinateur ou un système d'exécution d'instructions. Un support exploitable par ordinateur ou lisible par ordinateur peut être un appareil quelconque capable de contenir, stocker, communiquer, diffuser, ou transporter le programme en vue de son utilisation par, ou en relation avec, le système, appareil, ou dispositif d'exécution d'instructions. Le support peut être un système (ou appareil ou dispositif) électronique, magnétique, optique, électromagnétique, infrarouge ou à semi-conducteurs, ou un support de diffusion. Dans certains modes de réalisation, les procédés et processus décrits ici peuvent faire l'objet d'une mise en œuvre intégrale ou partielle par un dispositif utilisateur. Ces procédés et processus peuvent être mis en œuvre par des programmes ou services d'application sur ordinateur, une interface de programmation applicative (désignée par l'acronyme en langue anglaise API pour "Application-Programming Interface"), une bibliothèque et/ou autre produit-programme informatique, ou toute combinaison de ces entités. Le dispositif utilisateur peut être un dispositif mobile tel qu'un smartphone ou une tablette, un ordinateur ou tout autre dispositif doté d'une capacité de traitement, tel qu'un robot ou autre dispositif connecté. La FIG. 7 montre un système informatique générique convenant à la mise en œuvre de modes de réalisation de l'invention. Comme le montre la FIG. 7 , un système comporte un dispositif logique 701 et un dispositif de stockage 702. Le système peut facultativement comporter un sous-système d'affichage 711, un sous-système d'entrée 712, 713, 714, un sous-système de communication 720, et/ou d'autres composants non représentés. Le dispositif logique 701 comporte un ou plusieurs dispositifs physiques configurés pour exécuter des instructions. À titre d'exemple, le dispositif logique 701 peut être configuré pour exécuter des instructions qui font partie d'un/d'une ou de plusieurs applications, services, programmes, routines, bibliothèques, objets, composants, structures de données, ou autres constructions logiques. Ces instructions peuvent être mises en œuvre pour réaliser une tâche, mettre en œuvre un type de données, modifier l'état d'un ou de plusieurs composants, obtenir un effet technique ou, plus généralement, parvenir à un résultat recherché. Le dispositif logique 701 peut comporter un ou plusieurs processeurs configurés pour exécuter des instructions logicielles. En sus ou en variante, le dispositif logique peut comporter un ou plusieurs dispositifs logiques matériels ou micrologiciels configurés pour exécuter des instructions matérielles ou micrologicielles. Les processeurs du dispositif logique peuvent être monocœur ou multicœur, et les instructions qu'ils exécutent peuvent être configurées pour un traitement séquentiel, parallèle et/ou réparti. Des composants individuels du dispositif logique 701 peuvent facultativement être répartis entre au moins deux dispositifs distincts, lesquels peuvent être implantés à distance et/ou configurés pour effectuer un traitement coordonné. Des aspects du dispositif logique 701 peuvent être virtualisés et exécutés par des dispositifs informatiques en réseau accessibles à distance configurés selon une configuration de type informatique dans le cloud. Le dispositif de stockage 702 comporte un ou plusieurs dispositifs physiques configurés pour stocker des instructions exécutables par le dispositif logique pour mettre en œuvre les procédés et processus décrits ici. Lors de la mise en œuvre de ces procédés et processus, l'état du dispositif de stockage 702 peut être modifié - par ex. pour stocker des données différentes. Le dispositif de stockage 702 peut comporter des dispositifs amovibles et/ou intégrés. Le dispositif de stockage 702 peut comprendre un ou plusieurs types de dispositif de stockage comportant une mémoire optique (par ex. un CD, un DVD, un HD-DVD, un disque Blu-Ray, etc.), une mémoire à semi-conducteurs (par ex. une RAM, une EPROM, une EEPROM, etc.), et/ou une mémoire magnétique (par ex. une unité de disque dur, un lecteur de disquette, un lecteur de bande magnétique, une MRAM, etc.), entre autres. Le dispositif de stockage peut comporter des dispositifs volatils, non volatils, dynamiques, statiques, à lecture/écriture, à lecture seule, à accès aléatoire, à accès séquentiel, adressables par emplacement, adressables par fichier et/ou adressables par contenu. Dans certains agencements, le système peut comprendre une interface 703 adaptée à prendre en charge les communications entre le dispositif logique 701 et d'autres composants système. En guise d'exemple, on pourra citer comme composants système additionnels des dispositifs de stockage étendu amovibles et/ou intégrés. Les dispositifs de stockage étendu peuvent comprendre un ou plusieurs types de dispositif de stockage, notamment une mémoire optique 732 (par ex. un CD, un DVD, un HD-DVD, un disque Blu-Ray, etc.), une mémoire à semi-conducteurs 733 (par ex. une RAM, une EPROM, une EEPROM, une mémoire FLASH, etc.), et/ou une mémoire magnétique 731 (par ex. une unité de disque dur, un lecteur de disquette, un lecteur de bande magnétique, une MRAM, etc.), entre autres. Ce dispositif de stockage étendu peut comporter des dispositifs volatils, non volatils, dynamiques, statiques, à lecture/écriture, à lecture seule, à accès aléatoire, à accès séquentiel, adressables par emplacement, adressables par fichier et/ou adressables par contenu. On comprendra que le dispositif de stockage comporte un ou plusieurs dispositifs physiques, et exclut la diffusion de signaux en tant que telle. Toutefois, des aspects des instructions décrites ici peuvent, en variante, être diffusés par un support de communication (par ex. un signal électromagnétique, un signal optique, etc.) plutôt que d'être stockés sur un dispositif de stockage. Des aspects du dispositif logique 701 et du dispositif de stockage 702 peuvent être intégrés ensemble dans un ou plusieurs composants de logique matérielle. Ces composants de logique matérielle peuvent comporter des réseaux de portes programmables in situ (désignés par l'acronyme en langue anglaise FPGA pour "Field-Programmable Gate Array"), des circuits intégrés à programme et à application spécifiques (désignés par l'acronyme en langue anglaise PASIC/ASIC pour "Program- and Application-Specific Integrated Circuit"), des produits standards à programme et à application spécifiques (désignés par l'acronyme en langue anglaise PSSP/ASSP pour "Program- and Application-Specific Standard Product"), un système sur puce (désigné par l'acronyme en langue anglaise SOC pour "System-On-Chip"), et des dispositifs logiques programmables complexes (désignés par l'acronyme en langue anglaise CPLD pour "Complex Programmable Logic Devices"), par exemple. Le terme “programme” peut être utilisé pour décrire un aspect d'un système informatique mis en œuvre pour accomplir une fonction particulière. Dans certains cas, un programme peut être instancié via un dispositif logique exécutant des instructions lisibles par machine stockées par le dispositif de stockage. On comprendra que des modules différents peuvent être instanciés à partir de la même application, du même service, du même bloc de code, du même objet, de la même bibliothèque, de la même routine, de la même API, de la même fonction, etc. De manière analogue, le même programme peut être instancié à partir d'applications différentes, de services différents, de blocs de code différents, d'objets différents, de routines différentes, d'API différentes, de fonctions différentes, etc. Le terme “programme” peut englober des fichiers exécutables, des fichiers de données, des bibliothèques, des pilotes, des scripts, des enregistrements de base de données, etc., individuels ou groupés. Le système sur la FIG. 7 peut plus particulièrement être utilisé pour mettre en œuvre des modes de réalisation de l'invention. À titre d'exemple, un programme mettant en œuvre les étapes décrites au regard de la FIG. 4 , 4b ou 5 peut être stocké dans le dispositif de stockage 702 et exécuté par le dispositif logique 701. Le dispositif logique peut faire lire, par la caméra 716 ou l'interface en champ proche 721, l'identifiant d'objet depuis l'objet ou bien faire apposer, par l'imprimante 717 ou l'interface en champ proche 721, l'identifiant d'objet et/ou le code lisible par machine sur l'objet. Le chemin de l'URI peut indiquer la ressource 76, accessible via Internet 65. Ainsi, l'invention peut être matérialisée sous forme d'un programme informatique. Un tel système peut être en outre adapté à coder l'URI sous une forme lisible par machine. Par ailleurs, une fois convenablement configurés et connectés, les éléments sur la FIG. 7 peuvent constituer un système de vérification d'un URI. Le système peut être en outre adapté à décoder une partie restante de l'URI à l'aide de la combinaison algorithme/paramètres extraite afin d'obtenir un identifiant d'objet décodé. On comprendra qu'un “service”, tel qu'utilisé ici, est un programme d'application exécutable sur de multiples sessions utilisateurs. Un service peut être à la disposition d'un ou de plusieurs composants système, programmes et/ou autres services. Dans certaines mises en œuvre, un service peut tourner sur un ou plusieurs dispositifs informatiques serveurs. S'il est présent, le sous-système d'affichage 711 peut être utilisé pour présenter une représentation visuelle de données stockées par le dispositif de stockage. Cette représentation visuelle peut prendre la forme d'une interface utilisateur graphique (désignée par l'acronyme en langue anglaise GUI pour "Graphical User Interface"). Dans la mesure où les procédés et processus décrits ici changent les données stockées par le dispositif de stockage 702 et modifient donc l'état du dispositif de stockage 702, l'état du sous-système d'affichage 711 peut être de même modifié pour représenter visuellement des changements apportés aux données sous-jacentes. Le sous-système d'affichage 711 peut comporter un ou plusieurs dispositifs d'affichage ayant recours à pratiquement tout type de technologie. Ces dispositifs d'affichage peuvent être combinés au dispositif logique et/ou au dispositif de stockage dans une enceinte partagée, ou ces dispositifs d'affichage peuvent être des dispositifs d'affichage périphériques. S'il est présent, le sous-système d'entrée peut comprendre, ou s'interfacer avec, un ou plusieurs dispositifs d'entrée utilisateur tels qu'un clavier 712, une souris 713, un écran tactile 711, un contrôleur de jeu (non représenté). Dans certains modes de réalisation, le sous-système d'entrée peut comprendre, ou s'interfacer avec, des composants d'entrée utilisateur naturelle (désignée par l'acronyme en langue anglaise NUI pour "Naturel User Input"). Ces composants peuvent être intégrés ou périphériques, et la transduction et/ou le traitement d'actions d'entrée peuvent être gérés en interne ou en externe. Parmi les exemples de composants NUI, on pourra citer un microphone pour la reconnaissance de la parole et/ou de la voix ; une caméra infrarouge, couleur, stéréoscopique et/ou de profondeur pour la visionique et/ou la reconnaissance des gestes ; un système de suivi des mouvements de la tête, un système de suivi des mouvements oculaires, un accéléromètre, et/ou un gyroscope pour la détection des mouvements et/ou la reconnaissance de l'intention ; ainsi que des composants capteurs de champ électrique pour l'évaluation de l'activité cérébrale. S'il est présent, le sous-système de communication 720 peut être configuré pour coupler en communication le système informatique à un ou plusieurs autres dispositifs informatiques. À titre d'exemple, un module de communication peut coupler en communication un dispositif informatique à un service distant hébergé par exemple sur un serveur distant 76 via un réseau de taille quelconque comportant par exemple un réseau personnel, un réseau local, un réseau étendu, ou le réseau Internet. Le sous-système de communication peut comporter des dispositifs de communication filaires et/ou sans fil compatibles avec un ou plusieurs protocoles de communication différents. À titre d'exemples non limitatifs, le sous-système de communication peut être configuré pour communiquer via un réseau de téléphonie sans fil 74, ou un réseau local ou étendu sans fil ou filaire. Dans certains modes de réalisation, le sous-système de communication peut permettre au système informatique d'envoyer et/ou de recevoir des messages à destination/en provenance d'autres dispositifs via un réseau tel que le réseau Internet 75. Le sous-système de communication peut en outre prendre en charge des communications inductives à courte portée 721 avec des dispositifs passifs (NFC, RFID, etc.). Le système sur la FIG. 7 est censé illustrer un large éventail de types différents de système de gestion d'informations. On comprendra que bon nombre des sous-systèmes et caractéristiques décrits au regard de la FIG. 7 ne sont pas nécessaires à la mise en œuvre de l'invention, mais qu'ils sont incorporés dans le but d'illustrer des systèmes possibles selon la présente invention. On comprendra que les architectures système peuvent varier considérablement, et que la relation entre les différents sous-systèmes sur la FIG. 7 est purement schématique et susceptible de varier en termes de disposition et de répartition des rôles dans les systèmes. On comprendra que, dans la pratique, les systèmes incorporeront vraisemblablement différents sous-ensembles des divers sous-systèmes et caractéristiques décrits au regard de la FIG. 7 . La FIG. 8 présente un exemple supplémentaire de dispositif selon la présente invention. L'homme du métier comprendra qu'il sera possible d'avoir recours à des systèmes développés à l'avenir, fonctionnant également selon la présente invention. La FIG. 8 montre un dispositif type smartphone adaptable pour constituer un mode de réalisation. Comme le montre la FIG. 8 , le dispositif type smartphone incorpore les éléments 701, 702, 703, 720, 733, 714, 715, 716, 711 décrits plus haut. Il est en communication avec le réseau de téléphonie 74 et un serveur 76 via le réseau 75. Les éléments 731, 732, 717, 712, 713 sont en revanche omis. Les caractéristiques présentées sur cette figure peuvent également être intégrées à un dispositif type tablette. On comprendra que les configurations et/ou approches décrites ici n'ont qu'un caractère illustratif et que ces modes de réalisation ou exemples particuliers ne doivent pas être entendus dans un sens limitatif dans la mesure où de nombreuses variantes sont possibles. Les routines ou procédés particuliers décrits ici peuvent représenter une ou plusieurs stratégies parmi un nombre quelconque de stratégies de traitement possibles. À cet égard, diverses actions illustrées et/ou décrites peuvent s'effectuer selon la séquence illustrée et/ou décrite, selon d'autres séquences, en parallèle, ou omises. De même, il est possible de modifier l'ordre des processus décrits ci-dessus. L'objet de la présente invention englobe toutes les combinaisons et sous-combinaisons nouvelles et n'allant pas de soi des divers processus, systèmes et configurations, et autres caractéristiques, fonctions, actions et/ou propriétés décrits ici ainsi que tout ou partie de leurs équivalents. Procédé, mis en œuvre par ordinateur, de définition d’une structure d'identifiant de ressource de réseau sécurisé, ledit procédé comprenant la définition d'un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et l'association desdites composantes de schéma et de chemin à une partie fragment et/ou requête comprenant une structure de données signée cryptographiquement. Procédé, mis en œuvre par ordinateur, de définition d'une structure d'identifiant de ressource de réseau sécurisé, ledit procédé comprenant la définition d'un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, associant lesdites composantes de schéma et de chemin à un suffixe de partie chemin comprenant une structure de données signée cryptographiquement constituant un identifiant unique. Procédé selon l'une quelconque des revendications précédentes, comprenant une étape supplémentaire de codage de ladite structure d'identifiant de ressource de réseau sécurisé dans un code lisible par machine. Procédé selon l'une quelconque des revendications précédentes, ledit Identifiant Uniforme de Ressource pointant vers un référentiel duquel peut être extraite une application logicielle apte à vérifier que ladite composante de chemin correspond à ladite structure de données signée. Procédé, mis en œuvre par ordinateur, d'accès à une ressource de réseau, ledit procédé comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé selon l'une quelconque des revendications précédentes, le déchiffrement de ladite structure de données signée cryptographiquement, la vérification que ladite composante de chemin correspond à ladite structure de données signée et, en réponse à ladite vérification, l'accès à la ressource de réseau désignée par ledit Identifiant Uniforme de Ressource. Procédé selon la revendication 5, comprenant une étape de réception de la structure d'identifiant de ressource de réseau sécurisé au niveau d'un dispositif utilisateur, ladite étape de vérification que ladite composante de chemin correspond à ladite structure de données signée étant réalisée au niveau soit du dispositif utilisateur soit d'un serveur distant identifié par ladite composante de chemin. Procédé, mis en œuvre par ordinateur, de décodage d'une structure d'identifiant de ressource de réseau sécurisé, ledit procédé comprenant la réception d'une structure d'identifiant de ressource de réseau sécurisé selon des modes de réalisation précités, l'identification d'une structure caractéristique d'un schéma connu comme étant utilisé avec des structures d'identifiant de ressource de réseau sécurisé selon des modes de réalisation précités, l'isolement d'une partie de ladite structure d'identifiant de ressource de réseau sécurisé connue comme correspondant à un identifiant unique selon ledit schéma, et la tentative de déchiffrement de ladite partie isolée de ladite structure d'identifiant de ressource de réseau sécurisé. Procédé selon l'une quelconque des revendications 6 ou 7, ladite structure de données signée cryptographiquement comprenant une charge utile de données supplémentaire, et ledit procédé comprenant une étape supplémentaire d'extraction de données de référence à partir de la ressource de réseau désignée par ladite composante de chemin, et de comparaison desdites données de référence à ladite charge utile de données supplémentaire. Procédé selon l'une quelconque des revendications 6 à 8, ladite structure de données signée cryptographiquement comprenant une charge utile de données supplémentaire, et ledit procédé comprenant une étape supplémentaire d'identification d'une caractéristique de ladite structure d'identifiant de ressource de réseau sécurisé associée à une ressource de réseau supplémentaire, et d'extraction de données de référence à partir de ladite ressource de réseau supplémentaire, et de comparaison desdites données de référence à ladite charge utile de données supplémentaire. Procédé, mis en œuvre par ordinateur, d'association d'un identifiant unique à un produit, ledit produit appartenant à une classification arborescente de produit, ledit procédé comprenant les étapes de composition d'un URI sur la base de la classification dudit produit selon ladite classification arborescente de produit, d'obtention d'une structure de données signée cryptographiquement au regard dudit URI selon la revendication 1, et d'association de ladite structure de données signée cryptographiquement audit produit en tant que ledit identifiant unique. Système de traitement de données comprenant des moyens de réalisation du procédé selon l'une quelconque des revendications précédentes. Programme informatique comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, amènent l'ordinateur à réaliser le procédé selon l'une quelconque des revendications 1 à 10. Support lisible par ordinateur comprenant des instructions qui, lorsque les instructions sont exécutées par un ordinateur, amènent l’ordinateur à réaliser le procédé selon l’une quelconque des revendications 1 à 10. Structure d’identifiant de ressource de réseau sécurisé, comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, et une partie fragment et/ou requête comprenant une structure de données signée cryptographiquement. Structure d'identifiant de ressource de réseau sécurisé, comprenant un Identifiant Uniforme de Ressource (URI) possédant des composantes de schéma et de chemin identifiant une ressource de réseau, associant lesdites composantes de schéma et de chemin et un suffixe de partie chemin comprenant un identifiant unique et une structure de données signée cryptographiquement.