Brevet FR3131153A1 — publié le 20230623

Procédé d’établissement d’une communication entre un utilisateur (23) et un service (21) mis en œuvre par au moins un serveur (11), au moyen d’un réseau de télécommunication, comportant - l’enregistrement du service comportant la création d’un réseau virtuel superposé (30) pour ledit service, au-dessus dudit réseau de télécommunication, l’assignation et la mémorisation d’identifiants et d’une adresse virtuelle pour ce service et pour ce serveur; - l’enregistrement de l’utilisateur auprès du service et du réseau virtuel superposé (30), comportant la connexion sur une interface Web adaptée à déclencher l’assignation d’un identifiant de l’utilisateur, ainsi que la connexion d’un terminal (13) utilisé par celui-ci déclenchant l’assignation et la mémorisation d’un identifiant et d’une adresse virtuelle de ce terminal et d’une adresse virtuelle du terminal - l’acheminement de paquets de données entre l’utilisateur et le service via une connexion virtuelle établie au sein du réseau virtuel superposé sur la base de ces adresses virtuelles Figure pour l’abrégé : fig. 3 . Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements DOMAINE DE L’INVENTION La présente invention est relative à la sécurisation des communications sur les réseaux de communication entre des entités telles que des utilisateurs et des services. Elle s’applique particulièrement à la gestion des communications sur Internet entre des usagers et des services sensibles tels que les services commerciaux, bancaires, relatifs à la santé, administratifs, etc. CONTEXTE DE L’INVENTION Les communications basées sur le réseau Internet obéissent très généralement toujours à un paradigme constitué il y a une quarantaine d’années autour de la pile protocolaire TCP/IP. Dans ce paradigme, les équipements se voient attribuer des adresses IP qui leur permettent de communiquer avec les autres équipements connectés au réseau Internet. Même si des mécanismes ont été proposés afin de gérer la mobilité, la sécurité et la diffusion (ou « multicasting » en anglais), ceux-ci reposent toujours sur cette idée de communications d’équipement à équipement. Ces mécanismes visent la couche 2 du modèle OSI et permettent certaines mobilités entre réseaux WLAN (e.g., famille IEEE 802.11), cellulaires (e.g., 2G à 5G), véhiculaires (e.g., IEEE 1609 et 802.11p), mais ne permettent pas une bonne gestion de la mobilité au niveau des couches supérieures du modèle OSI, et notamment au niveau de la couche 3, comme le montre l’échec du déploiement du protocole MobileIP. Ces mécanismes ne permettent pas une mobilité complète comprenant le transfert d’une communication d’un équipement à un autre sans interrompre la communication courante pour en démarrer une nouvelle. De même, alors qu’un utilisateur peut disposer sur son équipement d’une pluralité d’applications, il ne lui est actuellement pas possible de transférer une communication d’une application à l’autre. En outre, dans le cadre de communications sécurisées, les mécanismes de sécurité actuels, tels que TLS, DTLS et IPsec, se basent sur les adresses IP des équipements, ou sur les noms de domaines associés à ces adresses, afin de générer des clés secrètes de sessions pour chiffrer les communications. Dès lors, en cas de changement d’équipement ou de déplacement de l’équipement d’un réseau d’accès à un autre, l’adresse IP est modifiée, et le processus de sécurisation doit être réinitialisé sur la base de la nouvelle adresse, ce qui provoque une discontinuité du service fourni à l’utilisateur et impacte la qualité de service perçue (ou QoS pour « Quality of Service » en anglais). Il apparait donc que l’état de l’art est insuffisant à fournir un mécanisme de communication permettant une mobilité totale des équipements, des services et des utilisateurs, de façon en outre totalement sécurisée. Un objectif de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités. Elle vise en particulier à améliorer la connectivité (c’est-à-dire la façon d’acheminer des paquets de données de bout en bout) entre un (ou plusieurs) utilisateurs et un service. Plus précisément, selon des modes de réalisation, elle vise à fournir un procédé et une architecture permettant aux utilisateurs et aux services de se déplacer d’un équipement à un autre, et aux équipements de modifier leur connexion au réseau, sans pour autant impacter ni le maintien de la connexion entre l’utilisateur et le service, ni la sécurité de la connexion. Pour ce faire, l’invention vise à changer le paradigme habituel de la connectivité basée sur les adresses de la couche réseau (e.g. adresses IP) attribuées aux équipements pour une connectivité basée sur des identifiants assignés aux utilisateurs et aux services, qui sont indépendants des adresses IP des équipements sur lesquels ils sont déployés. À cette fin, selon un premier aspect, la présente invention peut être mise en œuvre par un procédé d’établissement d’une communication entre un utilisateur et un service mis en œuvre par au moins un serveur, au moyen d’un réseau de télécommunication, comportant l’enregistrement dudit service comportant la création d’un réseau virtuel superposé pour ledit service, au-dessus dudit réseau de télécommunication, l’assignation d’un identifiant du service, d’un identifiant du serveur et d’une adresse virtuelle du serveur au sein dudit réseau virtuel superposé, et la mémorisation d’une association entre ledit identifiant du service et ledit identifiant dudit serveur et d’une association entre ledit identifiant du serveur et ladite adresse virtuelle du serveur, au sein d’une table de hachage distribuée sur des nœuds dudit réseau virtuel superposé ; l’enregistrement dudit utilisateur auprès dudit service et dudit réseau virtuel superposé, comportant la connexion dudit utilisateur sur une interface Web adaptée à déclencher l’assignation d’un identifiant dudit utilisateur, ainsi que la connexion d’un terminal utilisé par ledit utilisateur déclenchant l’assignation d’un identifiant du terminal et d’une adresse virtuelle du terminal au sein dudit réseau virtuel superposé, et la mémorisation d’une association entre ledit identifiant d’utilisateur et ledit identifiant du terminal et d’une association entre ledit identifiant du terminal et ladite adresse virtuelle du terminal, au sein de ladite table de hachage; l’acheminement de paquets de données entre ledit utilisateur et ledit service via une connexion virtuelle établie au sein dudit réseau virtuel superposé, sur la base desdites adresses virtuelles Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : l’adresse virtuelle du serveur et l’adresse virtuelle du terminal sont déterminées en fonction de la topologie dudit réseau virtuel superposé et du rattachement, respectivement, dudit serveur et dudit terminal audit réseau virtuel superposé ; le procédé comporte en outre une étape de modification d’une association dans ladite table de hachage distribuée, si pendant ladite communication, ledit utilisateur ou ledit service n’est plus accessible à la même adresse virtuelle, et, une étape d’interrogation de ladite table de hachage distribuée par au moins un nœud dudit réseau virtuel superposé pour ledit acheminement de paquets de données ; si ledit serveur ou ledit terminal change de rattachement audit réseau virtuel superposé durant ladite communication, on détermine à nouveau l’adresse virtuelle pour ledit serveur, respectivement ledit terminal, et on modifie l’association entre l’adresse virtuelle et l’identifiant dudit serveur, respectivement dudit terminal ; si ledit service ou ledit utilisateur est redéployé sur un nouveau serveur, respectivement un nouveau terminal, distinct du précédent, on détermine à nouveau l’identifiant dudit serveur, respectivement dudit terminal, et on modifie l’association entre l’identifiant dudit service, respectivement dudit utilisateur, et l’identifiant dudit serveur, respectivement dudit terminal ; le procédé comporte en outre une étape ) de création et mémorisation d’information de session liant ledit utilisateur et ledit service, au sein d’un au moins parmi ledit terminal, ledit serveur, ladite table de hachage distribuée et un jeton de sécurité attaché à un connecteur dudit terminal. lesdits paquets de donnés contiennent un entête dans lesquels au moins lesdites adresses virtuelles dudit serveur et dudit terminal sont insérées ; ledit entête comprend également ledit identifiant dudit terminal, ledit identifiant dudit serveur, ledit identifiant dudit utilisateur et ledit identifiant dudit service. Selon un autre aspect, l’invention peut également être mise en œuvre par un programme d’ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé tel que précédemment décrit. Selon un second aspect, l’invention peut également être mise en œuvre par un équipement adapté pour l’établissement d’une communication entre un utilisateur utilisant ledit terminal et un service mis en œuvre par au moins un serveur, au moyen d’un réseau de télécommunication, comportant un intergiciel adapté pour : l’enregistrement dudit utilisateur auprès dudit service, comportant la connexion dudit utilisateur sur une interface Web adaptée à déclencher l’assignation d’un identifiant dudit utilisateur, ainsi que la connexion d’un terminal utilisé par ledit utilisateur déclenchant l’assignation d’un identifiant du terminal et d’une adresse virtuelle du terminal au sein dudit réseau virtuel superposé, et la mémorisation d’une association entre ledit identifiant d’utilisateur et ledit identifiant du terminal et d’une association entre ledit identifiant du terminal et ladite adresse virtuelle du terminal, au sein de ladite table de hachage ; l’acheminement de paquets de données entre ledit utilisateur et ledit service via une connexion virtuelle établie au sein dudit réseau virtuel superposé, sur la base desdites adresses virtuelles. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES FIGURES Les dessins annexés illustrent l’invention : la représente schématiquement un exemple d’organigramme selon un mode de réalisation de l’invention ; la illustre un exemple de réseau virtuel superposé tel qu’utilisé dans des modes de réalisation de l’invention la illustre un scénario simplifié selon un mode de réalisation de l’invention. les figures 4a, 4b et 4c schématisent des automates, ou machines à états, finis, selon des modes de réalisation de l’invention. DESCRIPTION DETAILLEE DE MODES DE REALISATION DE L’INVENTION L’invention vise à permettre la communication entre un ou plusieurs utilisateurs et un service mis en œuvre, ou déployé, sur un serveur, au moyen d’un réseau de télécommunication. Par souci de simplicité et clarté, on appelle ici réseau de télécommunication toute connexion d’équipements de réseau, permettant de mettre en communication des équipements distants. Un tel réseau est en général une interconnexion de plusieurs sous-réseaux (réseaux d’accès, réseau de cœur, etc.). Un exemple d’un tel réseau de télécommunication est le réseau communément appelé Internet. Un équipement est un objet physique adapté pour communiquer sur le réseau de télécommunication. Il peut s’agir d’un terminal destiné à un utilisateur (ordinateur, téléphone mobile intelligent, ou « smartphone » en anglais, tablette numérique, objet connecté, etc.) ou d’un serveur. Typiquement, un équipement comporte un système d’exploitation, comportant lui-même les éléments permettant de mettre en œuvre la pile protocolaire adaptée à la communication avec le réseau de télécommunication, et une ou plusieurs applications. Les applications mises en œuvre sur le serveur permettre de fournir un service aux utilisateurs qui se connecte dessus. Les applications mises en œuvre par les équipements des utilisateurs peuvent être généralistes ou adaptées à l’interaction avec les services fournis par le serveur. À titre d’exemple de services, on peut mentionner de façon non exhaustive, les services marchands permettant des achats en ligne, les services de gestion de comptes bancaires, les services d’accès à l’administration officielle (permettant le paiement des impôts, l’accès aux comptes de sécurité sociale …), etc. Les applications mises en œuvre sur les équipements des utilisateurs peuvent être des navigateurs Web, permettant de se connecter aux services via les protocoles HTTP ou HTTPS. Il peut également s’agir d’applications dédiées, ce mode de fonctionnement étant plus habituel sur des équipements de type « smartphone » fonctionnant avec un système d’exploitation Android ou iOS. Les utilisateurs sont typiquement des êtres humains utilisant les équipements. Mais certaines applications peuvent avoir un comportement automatique de sorte qu’elles puissent être elles-mêmes considérées comme « utilisatrices » des services auxquelles elles sont connectées ; comme par exemple dans le cas des communications entre machines (« machine-to-machine », M2M, en anglais) ou de l’Internet des objets (« Internet of Thing s »,IoT, en anglais). Dans la suite, on nommera « entités », les utilisateurs et les services. Les entités sont déployées sur des équipements que l’on appellera serveur dans le cas des services et terminal dans le cas des utilisateurs. L’organigramme de la illustre un enchainement d’étapes selon un mode de réalisation de l’invention. Cet enchainement particulier permet essentiellement la clarté de l’exposé, mais dans un cas réel, l’ordre peut être distinct, puisque les différents acteurs (utilisateurs, services…) interagissent de façon indépendante. Selon ce mode de réalisation, une première étape S1 consiste en l’enregistrement du service. Cet enregistrement peut se faire auprès d’un opérateur qui gère tout ou partie des différents services sous-jacents aux mécanismes de l’invention. En particulier cet opérateur gère la création et le cycle de vie de réseaux virtuels superposés (ou « overlay network » en anglais). Cet enregistrement peut se faire au moyen d’un portail dédié accessible au fournisseur de service, par exemple un portail Web. Selon un mode de réalisation, le fournisseur de service peut indiquer un nom pour le service permettant à celui-ci d’être indentifiable par les utilisateurs, par exemple trouvable par un moteur de recherche. Il peut également indiquer un nom du fournisseur de service et/ou toute autre information utile pour les utilisateurs de son service. L’enregistrement comprend la création d’un réseau virtuel superposé (étape S11) pour le service, au-dessus du réseau de télécommunication. Selon un mode de réalisation, le fournisseur de service peut indiquer un nom pour le réseau virtuel superposé. Un réseau virtuel superposé, ou « overlay network » en anglais, est un réseau formé par des équipements qui établissement entre eux des connexions au niveau de la couche 3 du modèle de l’OSI ou au-delà. Ce réseau et ces connexions peuvent être appelés « virtuels » car situés au-dessus de la couche 2 du modèle OSI (liaison de données). Les connexions virtuelles jouent le rôle de liens virtuels entre les équipements. Les équipements qui possèdent plus d’un lien peuvent jouer le rôle de relai (ou de « routeur ») pour les flux de paquets de données. Les pages Wikipedia suivantes donnent d’autres détails sur les réseaux superposés ou « overlay » : https://fr.wikipedia.org/wiki/Réseau_superposé https://en.wikipedia.org/wiki/Overlay_network La représente un exemple de réseau virtuel superposé tel qu’utilisé dans des mises en œuvre de l’invention. Selon ce mode de réalisation, le réseau virtuel superposé N S est constitué uniquement d’équipements terminaux ou serveurs (équipements d’utilisateurs ou de services) E 1 , E 2 , E 3 , E 4 , E 5 , E 6 . Les équipements de réseaux (commutateurs, routeurs, etc.) R 1 , R 2 , R 3 , R 4 , R 5 , R 6 ne font pas partie du réseau virtuel superposé N S . Un tel réseau virtuel superposé est de type pair-à-pair, ou « peer to peer » en anglais. Les liens, ou connexions virtuelles du réseau superposé N S sont illustrés en pointillées sur la . Elles sont supportées par les connexions physiques (figurant en traits pleins) connectant les équipements de réseaux et les équipements terminaux ou serveurs, mais l’acheminement logique des paquets de données s’effectuent au niveau des connexions virtuelles. Un réseau virtuel superposé est un réseau flexible dans la mesure où il offre une vue indépendante de l’infrastructure physique. Ainsi, lorsqu’un équipement terminal apparaît, disparaît ou se connecte à d’autres équipements du réseau (« handover » en téléphonie mobile, par exemple), le réseau virtuel logique peut s’adapter dynamiquement à son comportement. La création du réseau virtuel superposé, étape S11, comprend le démarrage de nœuds constituant ce réseau parmi les nœuds du réseau de télécommunication. Le démarrage de nœud consiste à installer et/ou démarrer des modules logiciels spécifiques (appelés « routeurs virtuels ») sur des équipements serveurs situés à divers endroits du réseau afin de mettre en œuvre les protocoles et machines à états correspondants permettant le fonctionnement des mécanismes selon l’invention. La illustre un scénario simplifié selon un mode de réalisation de l’invention. Un service 21 déployé sur un équipement 11 s’est enregistré, ce qui a provoqué la création d’un réseau virtuel superposé 30. Ce réseau superposé est composé des équipements terminaux 11, 12, 13, 14. Dans la réalité, en général, un plus grand nombre d’équipements peut être impliqué. La ne montre pas le réseau de télécommunication sous-jacent et les équipements de réseau qui le constitue. Ceux-ci supportent toutefois le réseau virtuel superposé 30 et permettent son fonctionnement. L’enregistrement du service comprend également une étape S12 d’assignation d’un identifiant du service 412, d’un identifiant du serveur et d’une adresse virtuelle du serveur au sein du réseau virtuel superposé ainsi créé. L’identifiant du service est unique. Selon un mode de réalisation, un nom peut être associé à cet identifiant afin de permettre sa recherche par un utilisateur et la compréhension de ce qu’en quoi le service consiste. Des informations explicatives supplémentaires, destinées aux utilisateurs, peuvent également être associés à l’identifiant du service. Il est ici à noter que cet identifiant est propre au service et non pas au serveur sur lequel celui-ci est mis en œuvre : ainsi, si un service migre d’un serveur à un autre, son identifiant demeurera identique. L’identifiant 411 du serveur (ou équipement) 11 sur lequel le service 21 est déployé est également un identifiant unique. Si ce même serveur appartient à plusieurs réseaux virtuels superposés (overlay), il peut obtenir autant d’identifiants d’équipement que de réseaux auquel il appartient. L’adresse virtuelle 413 est une adresse unique, au sein du réseau virtuel superposé 30, qui permet aux paquets de données d’être acheminés de bout en bout. Cette adresse virtuelle peut être topologique, c’est-à-dire dépendre de la topologie du réseau virtuel superposé et de la position de rattachement du serveur à ce réseau virtuel superposé. Cette caractéristique permet un routage efficace de voisin à voisin au sein du réseau. La structure même de l’adresse virtuelle (et de l’espace d’adressage) peut donc dépendre de cette topologie du réseau. En outre, dans la mesure où un équipement peut être amené à changer ses connexions aux nœuds du réseau auprès duquel/desquels il est connecté, la topologie du réseau et l’attachement de l’équipement au réseau sont dynamiques, et l’adresse virtuelle d’un équipement est donc également dynamique. Ainsi, si un équipement est mobile, il peut se déconnecter d’un nœud et se connecter à un autre nœud (opération dite de « handover »). Auquel cas, son adresse virtuelle va évoluer afin de prendre en compte ce changement topologique. Il en va de même en cas de rupture accidentelle d’une connexion engendrant une nouvelle connexion avec un nœud différent. Selon un mode de réalisation, un équipement obtient son adresse virtuelle auprès du nœud du réseau virtuel superposé auquel il se connecte. La topologie du réseau virtuel superposé peut être vue comme un graphe, et selon un mode de réalisation, la détermination de l’adresse virtuelle peut être effectuée selon les enseignements de l’article « Geographic routing using hyperbolic space » , de R. Kleinberg in Proceedings of the 26th IEEE INFOCOM, 2007, pp. 1902-1909. Ce mécanisme attribue des adresses équivalentes à des coordonnées adéquatement prises dans un plan hyperbolique (représenté par le modèle du disque de Poincaré). Sa méthode crée un encastrement glouton (ou « greedy embedding » en anglais) sur un arbre couvrant d'adressage. Cet arbre est un arbre régulier. Toutefois, dans la méthode de Kleinberg, la construction de l’encastrement nécessite une pleine connaissance de la topologie du graphe qui doit être statique. Ce requis provient du fait que le degré de l’arbre doit être fixé au plus haut degré trouvé dans le réseau. Dans l’article « Overlay addressing and routing system based on hyperbolic geometry » de C. Cassagnes, T. Tiendrebeogo, D. Bromberg et D. Magoni, in Proceedings of the 16th IEEE Symposium on Computers and Communications, 2011, pp. 294-301, les auteurs ont amélioré la méthode de Kleinberg afin de gérer une topologie dynamique qui peut croitre et décroitre au cours du temps. Cette méthode est adaptée aux réseaux superposés. Du fait de la mise en œuvre d’un tel réseau virtuel superposé, il devient possible de fixer le degré de l’arbre d’adressage à une valeur arbitraire fixe tout en n’ayant plus de borne sur le plus haut degré des nœuds du réseau contrairement à la méthode de Kleinberg originale. Le degré arbitrairement fixé est un paramètre du réseau virtuel superposé et correspond au nombre maximum d’adresses virtuelles qu’un nœud donné peut attribuer. Il est à noter que, selon cette mise en œuvre, les adresses virtuelles sont suffisantes pour acheminer les paquets de données à chaque saut dans le réseau, sans nécessiter de tables de routage au sein de ceux-ci. Elle permet donc un déploiement efficace dans les nœuds sans monopoliser leurs ressources en mémoire. Selon un mode de réalisation de l’invention, cette étape d’enregistrement S1 du service comprend des étapes de sécurisation qui conditionnement les étapes de création S11 d’un réseau virtuel superposé, et d’assignation S12 d’un identifiant du service 412, d’un identifiant du serveur 411 et d’une adresse virtuelle du serveur 413 au sein de ce réseau virtuel superposé. Ces étapes de sécurisation peuvent comprendre la création d’un certificat C 21 pour le service 21. Selon un mode de réalisation, lors de l’enregistrement du service 21 auprès de l’opérateur, le fournisseur de service génère une paire de clés cryptographiques comportant une clé publique et une clé privée, et fournit à l’opérateur cette clé publique. Cette fourniture peut se faire en même temps qu’il fournit le nom du réseau virtuel superposé et le nom du service, par exemple. Le certificat peut alors être créé et transmis au fournisseur de service. Il est signé par la clé publique de l’opérateur qui joue le rôle d’autorité de certification. Selon un mode de réalisation, ce certificat peut contenir : l’identifiant du service, le nom du service le nom du fournisseur de service la clé publique du service Ce certificat peut être utilisé pour sécuriser toutes communications entre l’équipement (ici serveur) 11 sur lequel le service 21 est déployé et les utilisateurs situés dans le réseau virtuel superposé 30. En effet, de façon similaire, un utilisateur possède un certificat attribué et signé par le fournisseur de service afin d’assurer l’authentification de son identité (voir plus loin). Lors de l’établissement d’une connexion sécurisée, les certificats du service (côté serveur) et de l’utilisateur (côté client) sont conjointement utilisés pour échanger des valeurs éphémères signées permettant à chacun de générer une clé secrète commune selon un algorithme de type Diffie-Hellman (par exemple à courbes elliptiques – ECDHE). Cette clé, dite « pre-master secret », permet de dériver des clés, dites de session, qui permettront de chiffrer symétriquement tout le trafic échangé au sein de la connexion (typiquement avec un algorithme de type AES - GCM par exemple). L’étape S1 d’enregistrement du service comprend également une étape S13 de mémorisation d’une association entre l’identifiant 412 du service et l’identifiant 411 du serveur et d’une association entre l’identifiant 411 du serveur et l’adresse virtuelle 413 du serveur, au sein d’une table de hachage distribuée 40 sur des nœuds dudit réseau virtuel superposé 30. Ainsi, deux associations distinctes peuvent être mémorisées au sein de la table de hachage, chacune correspondant à une ligne du tableau suivant : Clé Valeur Identifiant du service 412 Identifiant du serveur 411 Identifiant du serveur 411 Adresse virtuelle du serveur 413 Ces associations sont représentées sur la , ainsi que celles relatives aux utilisateurs, sous la forme d’un tableau. Ces associations peuvent toutefois être mémorisées de façon indépendante au sein de différents nœuds de la table de hachage distribuée 40. (Sur la figure, les associations ne sont pas associées à un nœud en particulier mais à la table de hachage en général). Une table de hachage distribuée THD (ou DHT pour « Distributed Hash Table » en anglais) est une technologie permettant la mise en place d’une table de hachage dans un système réparti de type pair-à-pair. Une table de hachage est fonctionnellement identique à un annuaire permettant le stockage de couples (clé, valeur). Un réseau pair-à-pair ou, en anglais, « peer-to-peer network » est un réseau composé de nœuds (correspondants à des machines physiques ou virtuelles) distincts sur lesquels s’exécutent une instance identique d’une application. Chaque nœud possède donc un comportement programmé identique : chaque nœud peut interagir avec tout autre nœud et il n’y a ni rôle spécifique, ni hiérarchie. La table de hachage distribuée permet de mémoriser des paires (clé, valeur) de façon efficace sur un ensemble de nœuds. Chaque donnée est accessible par sa clé, moyennant une requête effectuant en moyenne O (log n ) sauts dans le réseau, n étant le nombre de nœuds constituant la THD. La clé correspond à l’application d’une fonction de hachage qui permet de projeter l’espace des valeurs qu’elle peut prendre vers un espace d’adressage des nœuds de la table de hachage distribuée. Dans le cas présent, pour chaque service : un premier enregistrement dans la table de hachage distribuée peut correspondre à la première ligne du tableau ci-dessus et correspondre à la valeur de l’identifiant de serveur 411 associée à une clé constituée à partir de l’identifiant de service 412, et, un second enregistrement peut correspondre à la second ligne du tableau et correspondre à la valeur de l’adresse virtuelle du serveur 413 associée à une clé constituée à partir de l’identifiant de serveur 411. Cette table de hachage distribuée est supportée par tout ou partie des nœuds du réseau virtuel superposé 30. Selon un mode de réalisation, l’ensemble des nœuds de ce dernier est membre de la table de hachage distribuée. Selon un mode de réalisation, la table de hachage distribuée est sécurisée par la mémorisation redondante d’une même paire (clé, valeur) sur au moins deux nœuds distincts. Si le service n’est plus accessible à la même adresse virtuelle, alors une nouvelle adresse virtuelle doit a minima être redéterminée et la ou les associations correspondantes doivent être modifiées dans la table de hachage distribuée. Deux cas de figure au moins peuvent se présenter, durant une communication : le serveur change de rattachement au réseau virtuel superposé, le service est redéployé sur un serveur différent. Si le service 21 doit être redéployé sur un nouvel équipement 12 (distinct du précédent), un nouvel identifiant de serveur sera déterminé pour ce service. Un nœud du réseau virtuel superposé (qui est informé de ce redéploiement) initie donc la mise à jour de l’association mémorisée dans la table de hachage distribuée, c’est-à-dire : l’association entre l’identifiant du service et l’identifiant du nouveau serveur. Comme on le verra plus loin, un nœud devant acheminer un paquet de données peut être informé que l’équipement, qui précédemment supportait le service, n’est plus accessible ou ne supporte plus ce service. Dans ce cas, connaissant l’identifiant du service, il peut interroger la table de hachage distribuée et obtenir en réponse la valeur de l’identifiant du nouvel équipement qui supporte désormais le service. Puis, une seconde requête, en utilisant cet identifiant d’équipement mis à jour, lui permet de récupérer l’adresse virtuelle de cet équipement, et d’acheminer le paquet de données. Dans le cas où un même équipement 11 change sa connexion au réseau virtuel superposé, une nouvelle adresse virtuelle doit éventuellement être déterminée afin de rendre compte de ce changement topologique. Auquel cas, un nœud du réseau virtuel superposé (qui est informé de ce changement) initie donc la mise à jour de l’association entre l’identifiant de l’équipement et l’adresse virtuelle de l’équipement dans la table de hachage distribuée. Comme on le verra plus loin, un nœud devant acheminer un paquet de données peut être informé que l’équipement qui supporte le service n’est plus pareillement connecté et a éventuellement changé d’adresse. Dans ce cas, connaissant l’identifiant de l’équipement, il peut interroger la table de hachage distribuée et obtenir en réponse la valeur de l’adresse virtuelle de l’équipement, et ainsi acheminer le paquet de données. Dans cette situation, donc, une seule requête à la THD est nécessaire. Une étape S2 consiste en l’enregistrement d’un utilisateur auprès du service. Dans le cas général où plusieurs utilisateurs s’enregistrent auprès d’un même service, cette étape S2 est itérée pour chacun de ces utilisateurs. Cette étape S2 est typiquement postérieure à l’étape S1 d’enregistrement du service. Cet enregistrement comporte en premier lieu, dans une sous-étape S11, la connexion de l’utilisateur sur une interface Web (ou portail) ou similaire. Cette interface peut être gérée par l’opérateur qui gère tout ou partie des différentes fonctions sous-jacentes aux mécanismes de l’invention. Elle peut permettre à l’utilisateur de créer un compte et d’obtenir l’accès aux différents services déployés et préalablement enregistrés auprès de cet opérateur. Une fois enregistré, l’utilisateur peut avoir accès aux services disponibles soit par une connaissance préalable de leurs noms ou identifiants, soit par l’utilisation d’un moteur de recherche accessible à partir de ce portail, soit par l’utilisation d’une liste, éventuellement hiérarchisée, des services disponibles, soit par d’autres moyens encore. La création d’un compte permet à l’utilisateur de se connecter sur l’interface, celle-ci étant adaptée pour alors déclencher une sous-étape d’assignation d’un identifiant de l’utilisateur, 422. Dans une sous-étape S22, l’utilisateur 23 se connecte via un équipement 13, ce qui déclenche l’assignation d’un identifiant d’équipement 421 et d’une adresse virtuelle d’équipement 423 au sein dudit réseau virtuel superposé. Selon un mode de réalisation, l’équipement 11 peut se connecter à un nœud du réseau virtuel superposé. Ce nœud, ou bien un pair dans le réseau superposé, peut être alors responsable de cette assignation. Ces étapes d’enregistrement et d’assignation d’identifiants et d’adresses virtuelles sont similaires, mutatis mutandis , à celles précédemment explicitées pour le service et le serveur sur lequel celui-ci est déployé. Certains aspects et détails de mise en œuvre ne seront donc pas répétés ici. Notamment, de la même façon que pour le service, l’identifiant de l’utilisateur est unique et permet de l’identifier de façon univoque au sein du réseau. Il est propre à l’utilisateur lui-même et non pas à l’équipement que celui-ci peut utiliser. Ainsi, si l’utilisateur change d’équipement (par exemple, sortant de chez lui, passe de son ordinateur à un terminal mobile de télécommunication), son identifiant d’utilisateur restera le même. L’identifiant 421 de l’équipement 13 que l’utilisateur 23 utilise est également un identifiant unique. Si cet équipement appartient à plusieurs réseaux virtuels superposés (« overlay »), il peut obtenir autant d’identifiants d’équipements que de réseaux auquel il appartient. L’adresse virtuelle 423 de l’équipement 13 est une adresse unique au sein du réseau virtuel superposé 30, qui permet aux paquets de données d’être acheminés de bout en bout (c’est-à-dire entre l’utilisateur et le service). Cette adresse virtuelle est de même nature et structurée de la même façon que celle du serveur, puisqu’elles font toutes deux parties d’un même espace d’adressage et font l’objet des mêmes algorithmes d’assignation et de routage des paquets de données. Comme vu précédemment, l’adresse virtuelle est une adresse topologique et dynamique : elle est donc assujettie au rattachement de l’équipement 13 au réseau de télécommunication. Elle est donc déterminée en fonction de la topologie du réseau virtuel superposé et du rattachement de l’équipement à ce réseau virtuel superposé. Lorsque ce rattachement évolue au cours du temps (par exemple, à la suite d’un « handover » (ou basculement) d’un point d’accès WLAN à une station de base en téléphonie cellulaire), une nouvelle adresse virtuelle sera assignée pour prendre en compte la modification de la position topologique sous-jacente de l’équipement. Selon un mode de réalisation de l’invention, cette étape d’enregistrement S2 de l’utilisateur comprend des étapes de sécurisation qui conditionnement les étapes d’assignation d’un identifiant de l’utilisateur 422, d’un identifiant de l’équipement 421 et d’une adresse virtuelle 423 de l’équipement au sein de ce réseau virtuel superposé. Ces étapes de sécurisation peuvent comprendre la création d’un certificat C 23 pour l’utilisateur 23. Selon un mode de réalisation, lors de l’enregistrement de l’utilisateur 23 auprès de l’opérateur, celui-ci génère une paire de clés cryptographiques comportant une clé publique et une clé privée, et fournit à l’opérateur cette clé publique. Le certificat peut alors être créé et transmis à l’utilisateur, signé par la clé publique de l’opérateur faisant office d’autorité de certification. Selon un mode de réalisation, ce certificat peut contenir : l’identifiant de l’utilisateur, le nom de l’utilisateur, la clé publique de l’utilisateur. Ce certificat peut être utilisé pour sécuriser toutes communications entre l’équipement 13 utilisé par l’utilisateur 23 et le réseau virtuel superposé 30 qui contient le serveur supportant le service souhaité. En effet, un service possède un certificat attribué et signé par le fournisseur de service ou l’opérateur afin d’assurer l’authentification de son identité (voir précédemment). Lors de l’établissement d’une connexion sécurisée, les certificats du service (côté serveur) et de l’utilisateur (côté client) sont conjointement utilisés pour échanger des valeurs éphémères signées permettant à chacun de générer une clé secrète commune selon un algorithme de type Diffie-Hellman (par exemple à courbes elliptiques – ECDHE). Cette clé, dite « pre-master secret », permet de dériver des clés, dites de session, qui permettront de chiffrer symétriquement tout le trafic échangé au sein de la connexion (typiquement avec un algorithme de type AES - GCM par exemple). L’étape S2 d’enregistrement de l’utilisateur comprend également une étape S23 de mémorisation au sein de la table de hachage distribuée : d’une première association entre l’identifiant d’utilisateur 422 et l’identifiant d’équipement 421 et d’une seconde association entre l’identifiant d’équipement 421 et l’adresse virtuelle d’équipement 423. Comme pour le service, deux associations distinctes peuvent être mémorisées au sein de la table de hachage distribuée, pour chaque utilisateur. Chaque association correspond à une ligne du tableau ci-dessous, donné en exemple illustratif : Clé Valeur Identifiant d’utilisateur 422 Identifiant d’équipement 421 Identifiant d’équipement 421 Adresse virtuelle de l’équipement 423 Si un utilisateur change d’équipement, un nouvel identifiant d’équipement est déterminé. Un nœud du réseau virtuel superposé (informé de ce changement) initie donc la mise à jour de l’association mémorisée dans la table de hachage distribuée, c’est-à-dire l’association entre l’identifiant de l’utilisateur et l’identifiant du nouveau terminal. Par ailleurs, un nœud devant acheminer un paquet de données peut être informé que l’équipement destinataire (précédemment utilisé par l’utilisateur) n’est plus accessible ou n’est plus utilisé par l’utilisateur. Dans ce cas, connaissant l’identifiant d’utilisateur 422, le nœud peut interroger la table de hachage distribuée et obtenir en réponse la valeur de l’identifiant d’équipement 421. Puis, une seconde requête lui permet, en utilisant cet identifiant d’équipement, d’obtenir l’adresse virtuelle 423 et d’ainsi pouvoir acheminer le paquet de données jusqu’à la nouvelle destination. Dans le cas où un même équipement 13 change sa connexion et éventuellement son point de rattachement au réseau virtuel superposé, une nouvelle adresse virtuelle doit être déterminée afin de rendre compte de ce changement topologique. Auquel cas, un nœud du réseau virtuel superposé (qui est informé de ce changement) initie la mise à jour de l’association identifiant d’équipement / adresse virtuelle d’équipement, au sein de la table de hachage distribuée. Un nœud devant acheminer un paquet de données peut être informé que l’équipement utilisé par l’utilisateur destinataire n’est plus pareillement connecté. Dans ce cas, connaissant l’identifiant de l’équipement, il peut effectuer une unique interrogation de la table de hachage distribuée et obtenir en réponse la valeur de l’adresse virtuelle de cet équipement et ainsi acheminer le paquet de données. Une seule requête est ici donc nécessaire. Selon un mode de réalisation de l’invention, le procédé comporte également une étape S3 de création et de mémorisation d’informations de session liant l’utilisateur 23 et le service 21. La session peut être définie comme un conteneur qui stocke toutes les informations nécessaires au déroulement de la communication durant sa vie. Cette session est implémentée dans tous les équipements des participants à la communication (par exemple ceux supportant le service 21 et un ou plusieurs utilisateurs 23 du service), mais en plus, elle peut également être stockée de façon sécurisée dans certains équipements du réseau virtuel (i.e. sur des routeurs virtuels) ou encore sur des jetons de sécurité matériels (e.g. clé USB, carte SD, carte à puce, etc.) attachés à un connecteur dudit terminal, afin d’en assurer sa fiabilité en cas de panne d’un équipement. Une session fait le lien entre les entités (services, utilisateurs), les équipements et les applications qui sont impliquées dans la communication. Une session possède un identifiant unique dans le réseau virtuel où elle se situe. Cet identifiant peut être libéré à la fin de la session. Les informations de session peuvent être utilisées lorsqu’un membre de la communication est déconnecté et souhaite se reconnecter : les informations de session peuvent permettre de mémoriser l’état de la communication au moment de la déconnexion et de permettre la reconnexion. De même si l’ensemble des membres a été accidentellement déconnectée, les informations de session peuvent également permettre la reconnexion de tous les membres si la session a été stockée sur certains nœuds du réseau qui sont restés opérationnels (par exemple, un routeur virtuel, cf. supra) ou bien si elle a été stockée sur un jeton de sécurité (cf. supra). Ces informations de sessions peuvent être mémorisées au sein de la table de hachage distribuée. Ainsi que précédemment évoqué, le procédé comporte également une étape S4 d’acheminement de paquets de données entre l’utilisateur 23 et le service 21 via une connexion virtuelle établie au sein dudit réseau virtuel superposé, sur la base des adresses virtuelles respectives. Les adresses virtuelles de la source et du destinataire (ou des destinataires dans le cas d’une transmission en multicast) peuvent être insérés dans un entête des paquets de données. Selon un mode de réalisation, afin de faciliter l’acheminement d’un paquet de données lorsque le destinataire n’est plus accessible à l’adresse virtuelle indiquée, les identifiants des équipements (e.g., terminal, serveur) et les identifiants des entités (e.g., utilisateur, service) peuvent également être insérés dans cet entête. Dans le cas général où plusieurs réseaux virtuels cohabitent au-dessus d’un même réseau, on peut également insérer l’identifiant de ce réseau virtuel superposé. Les adresses virtuelles ont du sens uniquement dans le réseau virtuel superposé correspondant. Les tableaux ci-dessous illustrent un exemple de paquet de données selon un mode de réalisation de l’invention : Ethernet IP TCP INV HTTP Données Séquence de contrôle Ethernet Le premier tableau illustre un paquet de données. Classiquement, celui-ci comporte plusieurs entêtes correspondant à un empilement protocolaire. On trouve ainsi les entêtes correspondant aux protocoles Ethernet™, IP, TCP et HTTP. Le champ « Données » correspond aux données véhiculées (comportant éventuellement d’autres entêtes correspondant à des protocoles de niveau plus élevé que le protocole HTTP). Le champ « Séquence de contrôle de trame Ethernet » (ou « Frame Check Sequence », FCS, en anglais) correspond à une somme de contrôle basée sur la redondance cyclique (ou « Cyclic Redundancy Code », CRC, en anglais) utilisée par le protocole Ethernet pour détecter des erreurs de transmission dans la trame. Le champ « INV » correspond à un entête spécifique selon un mode de réalisation de l’invention. Celui-ci correspond à un protocole situé entre le protocole de transport (par exemple TCP ou UDP) et le protocole applicatif (par exemple HTTP). Ce champ « INV » est détaillé dans le tableau suivant : Source AV Dest. AV RV ID Source Eq. ID Dest. Eq. ID Session ID Source Ent. ID Dest. Ent. ID etc. Un champ « Source AV » correspond à l’adresse virtuelle source (par exemple 423, pour un paquet transmis depuis l’utilisateur 23 vers le service 13). Un champ « Dest. AV » correspond à l’adresse virtuelle de destination (par exemple 413). Un champ « RV ID » contient un identifiant du réseau virtuel superposé. Un champ « Source Eq. ID » correspond à l’identifiant de l’équipement (terminal, respectivement serveur), source (par exemple l’identifiant 421). Un champ « Dest. Eq. ID » correspond à l’identifiant de l’équipement (terminal, respectivement serveur), destinataire (par exemple l’identifiant 411) Un champ « Session ID » peut correspondre à l’identifiant de la session. Un champ « Source Ent. ID » correspond à l’identifiant de l’utilisateur, respectivement service, source (par exemple l’identifiant 412). Un champ « Dest. Ent. ID » correspond à l’identifiant de l’utilisateur, respectivement service, destinataire (par exemple l’identifiant 422). D’autres champs encore, « etc. », peuvent être inclus dans cet entête. Comme il a été vu précédemment, les adresses virtuelles peuvent, selon un mode de réalisation, être topologiques. Cela signifie que chaque nœud peut acheminer un paquet vers le nœud suivant sur le chemin menant au nœud destination, sans même nécessiter une table de routage. De proche en proche, le paquet de données peut ainsi être transmis depuis la source vers la destination. Si un nœud du chemin est informé que : soit l’adresse virtuelle n’est plus valide, soit le destinataire (c’est-à-dire l’utilisateur ou le service) ne correspond plus à cette adresse virtuelle, le nœud peut consulter les autres champs de l’entête « INV » afin d’en déduire la nouvelle adresse. Comme vu précédemment, selon les cas, les champs « Dest Eq ID » et « Dest Ent ID » permettent de recouvrer l’adresse virtuelle effective en interrogeant la table de hachage distribuée qui mémorise les différentes associations entre ces identifiants et adresses virtuelles. Selon un mode de réalisation, les équipements disposent de modules logiciels pour mettre en œuvre les parties qui les concernent dans les étapes précédemment décrites. Notamment ces modules logiciels, appelées « intergiciels », permettent d’assurer l’interface entre le réseau virtuel superposé 30 et les applications exécutées sur les équipements (terminaux et serveurs). Par exemple, sur un équipement d’utilisateur, des applications telles que des navigateurs Web, des applications de visio-conférence, etc. peuvent être installées et exécutées afin d’établir une connexion avec un service (instancié également par une ou plusieurs applications) déployé sur un serveur. Sur le serveur déployant le service, les applications peuvent comprendre un serveur Web, un serveur de visio-conférence, etc. Tant côté utilisateur que côté service, les intergiciels peuvent, si besoin, permettre de gérer tous les aspects propres à l’invention afin que les applications n’aient pas à être modifiées. Ainsi, un serveur Web classique peut être utilisé, de même qu’une application de visio-conférence classique. Les applications contiennent des modules (bibliothèques) implémentant les interfaces des piles protocolaires de télécommunication (TCP/IP) situées dans les systèmes d’exploitation. Selon un mode de réalisation, ces modules sont modifiés pour utiliser une API permettant d’aiguiller les appels à la pile protocolaire vers l’intergiciel, qui lui aussi peut s’exécuter sur l’équipement. Dans ce cas, les applications doivent être modifiées. La communication avec l’intergiciel peut typiquement être mise en œuvre à l’aide d’appels inter-processus (ou « Inter Process Communication », IPC, selon la terminologie en langue anglaise). L’intergiciel peut utiliser l’API d’une bibliothèque TLS (e.g. OpenSSL, GnuTLS, mbedTLS, etc.) afin de transporter les flux de données vers les nœuds du réseau virtuel superposé. Le mécanisme TLS (pour « Transport Layer Security » en anglais, ou « Sécurité de la couche de transport »), et son prédécesseur SSL (pour « Secure Sockets Layer » ou « Couche de sockets sécurisée ») sont des protocoles de sécurisation des échanges par réseau informatique, notamment par Internet. Le protocole SSL a été développé à l'origine par Netscape Communications Corporation pour son navigateur. L'organisme de normalisation IETF en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS. La bibliothèque TLS effectue des appels systèmes afin de créer des « sockets » sécurisés lui permettant de se connecter aux nœuds du réseau virtuel. Selon un mode de réalisation, l’acheminement des paquets de données peut ainsi être sécurisé au moyen d’une clé de session (ou « master secret » selon la terminologie du protocole TLS) déterminée à partir des certificats du service et de l’utilisateur (via, notamment des échanges de valeurs éphémères signées permettant de générer une clé secrète dite « pre master secret »). Ces aspects sont décrits dans les spécifications du protocole TLS, ou, par exemple, de façon plus sommaire, dans la page Wikipedia : https://fr.wikipedia.org/wiki/Transport_Layer_Security Si l’intergiciel est implémenté sous la forme d’un service s’exécutant en tâche de fond sans interface utilisateur (i.e. démon Unix ou service Windows), alors une application gestionnaire est nécessaire pour contrôler et surveiller l’intergiciel. Celle-ci communique avec l’intergiciel par appels IPC. Dans le cas contraire, l’application gestionnaire n’est pas requise et peut être fusionnée dans l’intergiciel lui-même. On voit donc que les entités peuvent communiquer selon deux modes différents : via des interfaces ou portails Web lors des étapes d’enregistrement afin d’obtenir notamment les identifiants d’entités et les certificats correspondants, puis via les intergiciels pour les étapes ultérieures comprenant la transmission des paquets de données relevant du domaine applicatif. On a donc une communication externe au réseau virtuel dans un premier temps, puis interne au réseau virtuel ensuite. L’ensemble des mécanismes et des modules intergiciels correspondants peuvent être décrits par des machines à états finis (ou « Finite State Machine », FSM, en anglais). Les intergiciels situés sur chaque équipement (e.g. terminaux, serveurs) et les logiciels situés sur les nœuds du réseau virtuel superposé (i.e. routeurs virtuels) peuvent mettre en œuvre une ou plusieurs machines à états. Rappelons que, s’agissant d’un réseau pair à pair, les nœuds sont les équipements supportant les routeurs virtuels et les équipements des différents utilisateurs et services. Selon un mode de réalisation de l’invention, plusieurs machines à états sont mises en œuvre, correspondant à certains aspects des mécanismes précédemment décrits. Les machines à états fonctionnent en parallèle de façon asynchrone, mais interagissent et leur intrication particulière, selon ce mode de réalisation, apporte la fonctionnalité générale de l’invention. Une machine à états, ou automate fini, est un modèle mathématique de calcul, utilisé dans de nombreuses circonstances, allant de la conception de programmes informatiques et de circuits en logique séquentielle aux applications dans des protocoles de communication, en passant par le contrôle des processus, la linguistique et même la biologie. Un automate fini est une construction mathématique abstraite, qui possède un nombre fini d'états, mais qui ne peut se trouver que dans un seul état à la fois à tout instant. Le passage d'un état à un autre est activé par un événement ou une condition ; ce passage est appelé une « transition ». Un automate particulier est défini par l'ensemble de ses états et l'ensemble de ses transitions. La illustre une première machine à états selon un mode de réalisation de l’invention. Cette machine à états est mise en œuvre par les équipements (y compris par le serveur dans le cas d’un service), par exemple sous la forme d’un intergiciel. Au départ, une entité (c’est-à-dire un utilisateur ou un service) souhaitant intégrer un réseau virtuel superposé s’enregistre auprès de l’opérateur du réseau afin de se voir attribuer un identifiant unique (d’utilisateur ou de service), ainsi qu’un nom unique associé à cet identifiant. Cette étape correspond à l’état e1-1. Une fois ces identifiants et noms déterminés, l’automate passe dans un état e1-2 consistant en la génération d’une paire de clés privée/publique par l’entité. Le nom et la clé publique sont insérés dans un certificat signé par l’autorité de certification de l’opérateur. Si l’opérateur valide cet enregistrement (transition « 1 »), il remet un certificat à l’entité, dans un état e1-3. Dans le cas contraire (transition « 0 »), l’automate se termine dans un état final e1-f. Dans l’état e1-4, l’entité peut installer l’intergiciel et le configurer afin de se connecter au réseau virtuel superposé. L’entité sélectionne un nom et un identifiant pour son équipement et soumet ses informations au réseau virtuel superposé via une requête à la table de hachage distribuée. Si le nom et l’identifiant sont disponibles (transition « 1 »), l’automate peut passer dans l’état e1-5 dans lequel l’entité génère une paire de clés privée/publique, puis créé un certificat pour son équipement. Dans l’état e1-6 suivant, il le signe avec sa clé privée d’entité. Si le nom et/ou l’identité n’est pas disponible (transition « 0 »), l’automate reboucle sur l’état e1-4 pour solliciter à nouveau un nom et un identifiant. L’entité (via l’intergiciel associé) envoie une requête à la table de hachage distribuée pour mémoriser l’association entre l’identifiant de l’entité et l’identifiant de l’équipement (état e1-7) Lorsque l’entité change d’équipement, cette association est mise à jour (boucle sur l’état e1-7 de mémorisation de l’association). Comme vu précédemment, la mémorisation de cette association permet au réseau de savoir à tout moment sur quel équipement se trouve une entité donnée. Il est à noter que les états e1-4 à e1-7 sont inclus dans l’état e3-4 de la qui décrit la gestion de l’adressage de l’équipement. Lorsque l’équipement obtient une adresse virtuelle dans le réseau virtuel superposé, son automate passe dans l’état e1-8 (qui correspond à l’état e3-5 de la ). Lorsqu’il reçoit une adresse virtuelle l’équipement envoie une requête à la table de hachage distribuée pour mémoriser l’association entre son identifiant et son adresse virtuelle (état e1-9). Lorsque l’équipement se déplace et change ainsi son rattachement au réseau virtuel superposé, son adresse virtuelle change également et cette association est mise à jour (boucle sur l’état e1-9). Ainsi, le réseau peut connaître à tout moment où se trouve l’équipement dans le réseau. La illustre un automate simplifié gérant les états pris par les équipements. Au départ, l’intergiciel est démarré sur l’équipement. Il vérifie qu’il peut accéder au réseau sous-jacent, c’est-à-dire Internet, par exemple (état initial e2-i). Si l’équipement possède des interfaces réseau ayant accès à Internet, l’automate passe dans l’état e2-1. L’intergiciel mettant en œuvre l’automate vérifie ensuite s’il possède une liste de pairs du réseau virtuel superposé, c’est-à-dire une liste d’équipements supportant des routeurs virtuels (nœuds) se trouvant déjà dans le réseau. Si oui (transition « 1 »), l’équipement les contacte et détermine quel est le meilleur pair auquel se connecter (état e2-3). Les critères de sélection peuvent être le débit disponible, la latence (ou gigue), la stabilité de la connexion, etc. Il envoie alors une demande de connexion à celui-ci. En cas de refus, l’équipement envoie une demande à un deuxième équipement de la liste, et ainsi de suite. À noter qu’il peut, selon des modes de réalisation, se connecter à plusieurs paris afin de renforcer la fiabilité de son maintien dans le réseau virtuel superposé. Le ou les pair(s) auquel(s) l’équipement est directement connecté sont appelés des voisins. Si non (transition « 0 »), l’équipement s’adresse hors bande à un serveur d’amorçage (« bootstrap » en anglais) qui peut lui envoyer une liste appropriée de pairs voisins potentiels (état e2-2), afin de passer à l’état e2-3 précédemment décrit (transition « 1 »). Tant qu’il n’a pas reçu cette liste, il peut reboucler sur l’état e2-2 (transition « 0 »). Une fois connecté à un ou plusieurs équipements voisins situés dans le réseau virtuel superposé (état e2-4), l’équipement demande ensuite une adresse virtuelle au meilleur voisin selon des critères qui peuvent être similaires à ceux décrits ci-dessus. Si l’équipement reçoit une adresse virtuelle (transition « 1 »), l’automate passe à l’état e2-5. Le voisin qui lui a fourni une adresse est nommé son parent. L’équipement effectue alors la requête à la table de hachage distribuée décrite à l’état e1-9, afin de mémoriser l’association entre son identifiant d’équipement et l’adresse virtuelle qui lui a été attribuée. S’il ne reçoit pas d’adresse (transition « 0 »), l’automate revient dans l’état e2-4 et demande au meilleur voisin suivant, et ainsi de suite. Si aucun de ses voisins ne peut lui fournir une adresse, alors l’équipement se connecte à des pairs supplémentaires jusqu’à trouver un pair voisin capable de lui fournir une adresse. Lorsque l’équipement perd la connexion qui le lie à son parent (transition « 1 »), il devient « orphelin » et l’automate passe dans l’état e2-6. Tant que la connexion n’est pas perdue, l’automate reste en l’état e2-5 (transition « 0 »). Dans l’état e2-6, l’équipement tente de se reconnecter à son parent. S’il réussit, l’automate revient dans l’état e2-5. Sinon, l’équipement tente de demander une adresse à l’un des ascendants auquel il est connecté. Il peut aussi essayer de se connecter à de nouveaux ascendants afin de leur demander une adresse. Selon le mécanisme d’adressage basé sur la topologie précédemment décrit, on peut appeler « ascendant » les nœuds qui possèdent une adresse incluse dans celle du nœud (ou équipement) considéré. De même, les descendants d’un nœud dans la topologie sont les nœuds qui possède une adresse dérivée du nœud considérée (c’est-à-dire dont l’adresse comprend celle du nœud considéré). S’il réussit à se connecter à un ascendant (transition « 1 »), l’automate passe dans un état e2-7 : il diffuse un message de mise à jour d’adresse à tous ses descendants, puis passe dans l’état e2-5. S’il échoue, il passe dans un état e2-8, dans lequel il diffuse un message de purge d’adresse à tous ses descendants (dont les automates respectives passent donc dans l’état e2-6), puis il repasse dans l’état e2-4. À tout moment, l’équipement peut quitter le réseau virtuel superposé et retourner dans l’état e2-1. La illustre un troisième automate, ou machine à états, relatif aux sessions et interactions. On appelle ici interaction une action applicative exécutée au sein d’une session donnée. Un exemple d’action peut être la réalisation d’un appel vocal entre deux entités de la session. Une interaction peut se traduire par la mise en place d’un ou plusieurs flux de données applicatifs, par exemple un flux de signalisation (selon le protocole SIP par exemple) et deux flux de données vocales (selon le protocole RTP par exemple). Chaque interaction peut disposer d’un identifiant propre et univoque au sein de la session qui l’accueille. Au départ l’automate est dans un état initial e3-i. Il passe dans l’état e3-1 correspondant au démarrage de l’intergiciel sur l’équipement et le rattachement de celui-ci à un ou plusieurs réseaux virtuels superposés. On suppose que (du fait des processus associés aux automates précédemment décrits) dans cet état, une ou plusieurs entités sont définies et valides dans chaque réseau virtuel superposé. De même au moins un équipement est défini et valide dans chaque réseau virtuel superposé. On suppose qu’une entité (utilisateur ou service), au travers d’une application ou d’un intergiciel, créé une session et lui attribue un identifiant de session, ou bien reçoit un message d’invitation pour participer à une session (associée à un identifiant de session) et l’accepte. L’automate passe alors dans l’état e3-2. L’automate vérifie si l’intergiciel possède le certificat de l’autorité de certification racine du réseau virtuel superposé auquel il appartient. S’il ne l’a pas (transition « 0 »), il passe dans l’état e3-4 pour effectuer une requête afin de récupérer ce certificat. Lorsqu’il possède ce certificat (transition « 1 » ou suite à l’état e3-4), il passe à l’état e3-3. Puis, à l’état e3-5, il ajoute un ou plusieurs destinataires à la session. Dans l’état e3-6, l’automate envoie une requête à la table de hachage distribuée afin de récupérer l’identifiant, le nom et l’adresse de l’équipement sur lequel se trouve l’entité destinataire. S’il ne reçoit pas les certificats d’entité et d’équipement du destinataire (transition « 0 »), l’automate passe en état e3-7, correspondant à la fermeture de la session. S’il reçoit les certificats (transition « 1 »), l’intergiciel vérifie leur validité dans l’état e3-8. S’ils ne sont pas valables (transition « 0 »), l’automate passe en l’état e3-7 de fermeture de la session. S’ils sont valables (transition « 1 »), l’intergiciel peut générer une clé de session partagée afin de chiffrer les échanges de données (état e3-9), puis la session passe à l’état « actif », e3-10. Une fois la session active, l’application ou l’intergiciel peut créer une ou plusieurs interactions, dans un état e3-11. Une interaction contrôle un ou plusieurs flux transportant des données émises / reçues par des protocoles applicatifs (SIP, RTP…) s’exécutant dans l’application. Si c’est l’intergiciel qui créé l’interaction, il va alors lancer l’exécution d’une application permettant de prendre en charge ces flux de données (i.e. cette application implémente les protocoles applicatifs de ces flux). Une interaction possède l’identifiant de l’application ainsi que les identifiants des flux qu’elle contrôle. Une interaction donnée peut être démarrée (état e3-12), mise en pause (état e3-13) et arrêtée (état e3-11). À noter qu’une session peut également être mise en pause (état e3-14). Dans ce cas, toutes les interactions qui appartiennent à cette session sont mises en pause également. Une session peut être transférée vers un autre équipement. Cet autre équipement devra être démarré et devra exécuter l’intergiciel afin de se mettre dans l’état e3-1. Il essaie alors de récupérer la session située sur l’équipement initial. S’il y parvient (transition « 1 »), il peut passer dans l’état e3-16. Sinon (transition « 0 »), il reste dans l’état e3-1. Si l’équipement qui supporte la session tombe en panne, la session est perdue (état e3-15) si un jeton de sécurité n’est pas utilisé (cf. supra). Il faut alors utiliser un autre équipement et interroger la table de hachage distribuée ou bien le destinataire pour récupérer la session perdue. Si un jeton de sécurité était utilisé sur l’équipement défaillant, il suffit de le brancher sur un nouvel équipement pour récupérer la session. L’utilisation d’un jeton est facultative mais utile en cas de panne de l’équipement support. Il est à noter que la mémorisation des données de session dans la table de hachage distribuée est facultative. Celle-ci peut être réalisée dans l’état e3-10, selon un mode de réalisation. Les automates illustrés par les figures 3a, 3b, 3c sont des exemples d’implémentation des principes de l’invention, mais d’autres modes de réalisation sont bien évidemment possibles. Notamment, ces automates sont susceptibles de nombreuses variantes. Il est également à noter que leurs représentations dans les figures sont simplifiées et qu’il est possible de diviser certains états en plusieurs états, ou, au contraire d’en regrouper certains : dans certains cas, en effet, le choix des états peut être arbitraire ou conduit par des considérations distinctes de celles de l’invention. Comme évoqué précédemment, ces automates peuvent être mis en œuvre, selon des modes de réalisation de l’invention, par un ou des modules d’un intergiciel installé et exécuté sur les équipements prenant parti à la communication ou encore, en ce qui concerne les routeurs virtuels, par des équipements matériels contenant des puces ayant des circuits électroniques spécifiques à ces automates (i.e. puce ASIC) ou ayant des circuits électroniques programmables implémentant ces automates (i.e. puce FPGA). En particulier, les équipements sont donc adaptés pour déployer de tels intergiciels, ainsi que des applications, tant pour des serveurs (i.e. équipements des services) que pour des terminaux (i.e. équipements des utilisateurs), ainsi qu’il a été expliqué précédemment. Ces équipements disposent notamment des moyens techniques de communication permettant une connexion pour la transmission d’information à travers un réseau de télécommunication, et disposent également des circuits (notamment au moins un processeur et un composant mémoire permettant de stocker des instructions informatiques) adaptés au déploiement d’un système d’exploitation, de modules logiciels mettant en œuvre les piles protocolaires, de l’intergiciel et des différentes applications. Un tel équipement peut comprendre les terminaux mobiles de télécommunication, notamment de type « smartphone », les ordinateurs portables ou fixes, les tablettes, les objets connectés de tout type, etc. Les moyens de communication peuvent permettre la connexion à différents types de réseau d’accès : réseaux cellulaires, notamment de 4 e ou 5 e génération, réseaux locaux sans fil, notamment WiFi, ou réseaux de proximité tels que Bluetooth ou NFC (Near Field Communication), etc. Ainsi, l’invention, selon ses modes de réalisation, permet de coupler simultanément la sécurité (authentification, intégrité et confidentialité) des flux de données échangés entre des applications et la mobilité des équipements et des entités. Les connexions applicatives basées sur les identifiants pérennes des utilisateurs et des services peuvent être maintenues lorsque les connexions sous-jacentes sont brisées puis rétablies, entrainant de ce fait des changements d’adresses IP. De plus, les certificats associés à ces identifiants sont gérés au sein du réseau virtuel superposé et les clés privées associées à ces identifiants sont gérées et conservées par l’utilisateur dans un porte-document numérique (« wallet » en anglais) intégré à l’intergiciel ou bien stocké dans un jeton de sécurité matériel (« hardware security token » en anglais). Ces éléments respectent donc les principes de l’identité auto-souveraine selon lesquels l’utilisateur conserve et gère ses clés privées. En outre, au sein du réseau virtuel, les communications sont autonomes : elles ne requièrent pas de faire appel à des services externes (en particulier, ni appels à la PKI, ni appels au DNS, ne sont requis pour que l’invention fonctionne). Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais est définie par les revendications. Elle est notamment susceptible de nombreuses variantes accessibles à l'homme de l'art. Procédé d’établissement d’une communication entre un utilisateur (23) et un service (21) mis en œuvre par au moins un serveur (11), au moyen d’un réseau de télécommunication, comportant l’enregistrement (S1) dudit service comportant la création (S11) d’un réseau virtuel superposé (30) pour ledit service, au-dessus dudit réseau de télécommunication, l’assignation (S12) d’un identifiant du service (412), d’un identifiant du serveur (411) et d’une adresse virtuelle du serveur (413) au sein dudit réseau virtuel superposé, et la mémorisation (S13) d’une association entre ledit identifiant du service et ledit identifiant dudit serveur et d’une association entre ledit identifiant du serveur et ladite adresse virtuelle du serveur, au sein d’une table de hachage (40) distribuée sur des nœuds dudit réseau virtuel superposé ; l’enregistrement (S2) dudit utilisateur auprès dudit service et dudit réseau virtuel superposé (30), comportant la connexion (S21) dudit utilisateur sur une interface Web adaptée à déclencher l’assignation d’un identifiant dudit utilisateur (422), ainsi que la connexion (S22) d’un terminal (13) utilisé par ledit utilisateur déclenchant l’assignation d’un identifiant du terminal (421) et d’une adresse virtuelle du terminal (423) au sein dudit réseau virtuel superposé, et la mémorisation (S23) d’une association entre ledit identifiant d’utilisateur et ledit identifiant du terminal et d’une association entre ledit identifiant du terminal et ladite adresse virtuelle du terminal, au sein de ladite table de hachage (40); l’acheminement (S4) de paquets de données entre ledit utilisateur et ledit service via une connexion virtuelle établie au sein dudit réseau virtuel superposé, sur la base desdites adresses virtuelles Procédé selon la revendication précédente, dans lequel l’adresse virtuelle du serveur et l’adresse virtuelle du terminal sont déterminées en fonction de la topologie dudit réseau virtuel superposé et du rattachement, respectivement, dudit serveur et dudit terminal audit réseau virtuel superposé. Procédé selon la revendication précédente, comportant en outre une étape de modification d’une association dans ladite table de hachage distribuée, si pendant ladite communication, ledit utilisateur ou ledit service n’est plus accessible à la même adresse virtuelle, et, une étape d’interrogation de ladite table de hachage distribuée par au moins un nœud dudit réseau virtuel superposé pour ledit acheminement de paquets de données. Procédé selon la revendication précédente dans lequel si ledit serveur ou ledit terminal change de rattachement audit réseau virtuel superposé durant ladite communication, on détermine à nouveau l’adresse virtuelle pour ledit serveur, respectivement ledit terminal, et on modifie l’association entre l’adresse virtuelle et l’identifiant dudit serveur, respectivement dudit terminal. Procédé selon la revendication 3, dans lequel si ledit service ou ledit utilisateur est redéployé sur un nouveau serveur, respectivement un nouveau terminal, distinct du précédent, on détermine à nouveau l’identifiant dudit serveur, respectivement dudit terminal, et on modifie l’association entre l’identifiant dudit service, respectivement dudit utilisateur, et l’identifiant dudit serveur, respectivement dudit terminal. Procédé selon l’une des revendications précédentes comportant en outre une étape (S3) de création et mémorisation d’information de session liant ledit utilisateur et ledit service, au sein d’un au moins parmi ledit terminal, ledit serveur, ladite table de hachage distribuée et un jeton de sécurité attaché à un connecteur dudit terminal. Procédé selon l’une des revendications précédentes, dans lequel lesdits paquets de donnés contiennent un entête dans lesquels au moins lesdites adresses virtuelles dudit serveur et dudit terminal sont insérées. Procédé selon la revendication précédente, dans lequel ledit entête comprend également ledit identifiant dudit terminal (421), ledit identifiant dudit serveur (411), ledit identifiant dudit utilisateur (422) et ledit identifiant dudit service (412). Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé selon l’une des revendications précédentes. Équipement adapté pour l’établissement d’une communication entre un utilisateur (23) utilisant ledit terminal et un service (21) mis en œuvre par au moins un serveur (11), au moyen d’un réseau de télécommunication, comportant un intergiciel adapté pour : l’enregistrement dudit utilisateur auprès dudit service, comportant la connexion dudit utilisateur sur une interface Web adaptée à déclencher l’assignation d’un identifiant dudit utilisateur (422), ainsi que la connexion d’un terminal (13) utilisé par ledit utilisateur déclenchant l’assignation d’un identifiant du terminal (421) et d’une adresse virtuelle du terminal (423) au sein d’un réseau virtuel superposé, et la mémorisation d’une association entre ledit identifiant d’utilisateur et ledit identifiant du terminal et d’une association entre ledit identifiant du terminal et ladite adresse virtuelle du terminal, au sein d’une table de hachage (40) distribuée sur des nœuds dudit réseau virtuel superposé; l’acheminement de paquets de données entre ledit utilisateur et ledit service via une connexion virtuelle établie au sein dudit réseau virtuel superposé, sur la base de ladite adresse virtuelle.