FR 3154893 A1 20250502 FR 2311842 A 20231031 Procédés et dispositifs pour la configuration et l’utilisation d’un réseau supportant des tranches réseau L’invention concerne un procédé de configuration d’un réseau supportant N tranches réseau, ledit procédé comportant des étapes de : - génération (1100) de M éléments de connexion, chaque élément de connexion étant configuré pour permettre l’obtention d’au moins un identifiant de connexion destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - association (1200) d’au moins un élément de connexion à au moins une tranche réseau en fonction d’un critère d’association donné, - transmission (1300) de données indiquant les associations entre éléments de connexion et tranches réseau à un ensemble E d’entités du réseau configurées pour participer à l’acheminement de paquets de données au sein du réseau. Figure pour l’abrégé : Fig. 4 Procédés et dispositifs pour la configuration et l’utilisation d’un réseau supportant des tranches réseau La présente invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement des procédés pour respectivement configurer des tranches réseau, permettre à un terminal connecté à un réseau supportant de telles tranches d’en découvrir la configuration et également permettre à des terminaux ayant ainsi procédé à une découverte des tranches réseau de communiquer entre eux via tout ou partie de ces tranches. L’invention concerne également des dispositifs et terminaux respectivement configurés pour mettre en œuvre ces procédés. L’invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le contexte de réseaux cellulaires de type 5G. De manière connue, les opérateurs de réseaux peuvent déployer à la demande des réseaux privés virtuels de bout en bout (« end-to-end virtual private network (VPN) » en anglais), entièrement (ou partiellement) dédiés à leurs clients. Cette pratique s’est développée pour aboutir au concept de découpage en tranches d’un réseau de communication, où l'architecture globale du réseau repose sur un ensemble de ressources qui peuvent être mise à contribution pour créer des partitions réseaux appelées "tranches de réseau" (plus simplement « tranches réseau » ci-après, ou « network slices » en anglais). Les caractéristiques d’une tranche réseau s’expriment notamment en termes de capacité (bande passante), de qualité de service (par ex., latence, temps de transit unidirectionnel), voire de sécurité (par ex., préservation de la confidentialité des informations transmises moyennant l’utilisation de techniques de chiffrement). Concernant ces aspects, et d’une manière générale, les travaux effectués par l’IETF (« Internet Engineering Task Force » en anglais) peuvent être avantageusement consultés, comme notamment le document « A Framework for IETF Network Slices in Networks Built from IETF Technologies », A. Farrel, J. Drake, R. Rokui, S. Homma, K. Makhijani, L.M. Contreras, J. Tantsura, 25 août 2023 On connaît en outre plusieurs types de tranches réseau. A titre d’exemple, dans sa spécification technique TS 23.501 (paragraphe 5.15.2.2), l’organisme 3GPP (« 3rd Generation Partnership Project ») définit et documente notamment les types suivants : - service mobile large bande amélioré « eMBB » (« Enhanced Mobile BroadBand » en anglais), - déploiement massif de l’Internet des Objets (« massive Internet of Things » ou « mIoT » en anglais), - communications ultra fiables et à faible latence (« Ultra Reliable Low Latency Communications » ou « URLLC » en anglais). Le choix de concevoir et de déployer par un opérateur un ou plusieurs types particuliers de tranches est notamment conditionné par la nature du trafic généré par les applications utilisées ou les services souscrits par un utilisateur du réseau. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données. Un tel le service immersif est donc un client « naturel » d’une tranche de type URLLC. De surcroît, un réseau qui supporte des tranches réseau peut lui-même être composé de plusieurs sous-réseaux (encore appelés « domaines »), chacun desdits sous-réseaux supportant une ou plusieurs tranches réseau. Un exemple de ce principe est représenté de manière schématique par la FIG. 1 , dans laquelle un réseau NET se décompose en trois sous-réseaux SS_NET_1, SS_NET_2, SS_NET_3 (chaque tranche d’un sous-réseau SS_NET_i, i étant un indice entier compris entre 1 et 3, étant représentée à titre illustratif par un parallélogramme dans la FIG. 1 ). Dès lors, les tranches des sous-réseaux SS_NET_i peuvent être associées entre elles pour fournir des services à valeur ajoutée. Par exemple, un fournisseur de service souhaitant exploiter l’infrastructure du réseau NET peut s’appuyer sur des tranches spécifiques respectivement mises en place dans les sous-réseaux SS_NET_i pour fournir un service dont le trafic sera acheminé via lesdites tranches. Les tranches ainsi exploitées forment des tranches dites « adjacentes » qui deviennent dès lors reliées entre elles de manière virtuelle pour le service proposé par ledit fournisseur. Les interfaces de raccordement entre tranches adjacentes peuvent être gérées en utilisant des mécanismes tels que ceux décrits dans le document suivant proposé par l’IETF : « YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS) », M. Boucadair, R. Roberts, O. Gonzalez de Dios, S. Barguil, B. Wu, 10 juillet 2023. Un tel exemple de raccordement entre tranches réseau est également illustré par la FIG. 1 où un fournisseur de service s’appuie sur des tranches TR_1_2, TR_2_2, TR_3_3 appartenant respectivement aux sous-réseaux SS_NET_1, SS_NET_2, SS_NET_3. Il convient de noter que ce même fournisseur peut proposer un ou plusieurs services qui exploitent une ou plusieurs desdites tranches réseau. De manière conventionnelle, ce type de configuration où des tranches réseau déployées dans des sous-réseaux sont reliées entre elles pour fournir un service spécifique est conceptuellement représenté sous la forme d’une tranche dite « tranche multi-domaines » (« stitched slice » ou « hierarchical slice » en anglais) regroupant les tranches des sous-réseaux en question. Les tranches réseau qui composent une tranche multi-domaines sont alors appelées « tranches mono-domaine ». Une telle tranche multi-domaines TR_MULTI est représentée à titre purement illustratif par la FIG. 1 , ladite tranche TR_MULTI regroupant les tranches TR_1_2, TR_2_2, TR_3_3 qui sont respectivement déployées dans les sous-réseaux SS_NET_1, SS_NET_2, SS_NET_3. Il convient de noter qu’aucune limitation n’est attachée à la nature d’un sous-réseau SS_NET_i. A titre d’exemple, il peut s’agir d’un réseau d’accès radio « RAN » (« Radio Access Network » en anglais), d’un réseau de collecte, d’un réseau cœur « CN » (« Core Network » en anglais), d’un réseau de transport « TN » (« Transport network » en anglais) ou un réseau de transit, etc. De plus, la réalisation d’une tranche multi-domaines n’est pas conditionnée par la disponibilité ou l’activation des mêmes techniques utilisées pour la réalisation des tranches mono-domaine à chaque sous-réseau. A titre illustratif, en reprenant l’exemple de la FIG. 1 : - le sous-réseau SS_NET_1 peut être configuré pour mettre en œuvre des tunnels IPsec qui sont exploités pour acheminer le trafic dans les tranches déployées dans ce sous-réseau SS_NET_1, - le sous-réseau SS_NET_2 peut être configuré pour mettre en œuvre un réseau privé virtuel de niveau réseau (« Layer 3 VPN » ou « L3VPN » en anglais) combiné avec des mécanismes d’ingénierie de trafic « TE » (« Traffic Engineering » en anglais), - le sous-réseau SS_NET_3 peut mettre en œuvre des ressources de routage par segments reposant sur le protocole IPv6 (« Segment Routing IPv6 » ou « SRv6 » en anglais) pour acheminer le trafic dans les tranches déployées dans ce sous-réseau SS_NET_3. Pour ce qui concerne plus spécifiquement la réalisation de tranches (qu’elles soient multi-domaines ou mono-domaine) dans les réseaux IP/MPLS (« Internet Protocol »/ « Multiprotocol Label Switching »), il est notamment possible de consulter le document suivant : « A Realization of IETF Network Slices for 5G Networks Using Current IP/ MPLS Technologies », K. G. Szarkowicz, R. Roberts, J. Lucek, M. Boucadair, L. M. Contreras, 23 mai 2023. Il résulte des considérations qui précèdent que l’ingénierie et le déploiement de tranches dans un réseau sont des activités complexes à mettre en œuvre, car elles nécessitent de prendre en compte de multiples paramètres de configuration. A cela s’ajoute le fait que, pour garantir l’accès d’un trafic de données à une ou plusieurs tranches réseau, ledit trafic doit faire l’objet d’une habilitation. Une telle habilitation repose typiquement sur des règles de classification de trafic. Ces règles sont appliquées à « l’entrée » (par ex. à la périphérie) d’un réseau/sous-réseau qui supporte la ou les tranches concernées, plus particulièrement par un ou plusieurs nœuds de périphérie. A titre d’exemple, un nœud de périphérie peut être situé à l’interface de raccordement d’une passerelle « PGW » (« Packet Gateway » en anglais) permettant d’accéder au réseau Internet. Selon un autre exemple, un nœud de périphérie peut être situé à l’interface de raccordement d’un terminal mobile (ou « User Equipment (UE) » en anglais) à un réseau d’accès radio « RAN ». Or, la conception et l’application de règles de classification de trafic participent aussi très largement à la complexité globale du déploiement et de l’exploitation d’un réseau supportant des tranches. En effet, et selon un premier aspect, il convient de tenir compte d’un niveau de granularité caractéristique d’une tranche réseau. Ce niveau peut en effet être macroscopique (par exemple, une tranche déployée pour acheminer le trafic à destination du réseau Internet), ou bien microscopique (par exemple dans le cas d’un trafic applicatif échangé entre deux terminaux mobiles et pour lequel une tranche dédiée a été déployée). En tout état de cause, qu’il soit macroscopique ou microscopique, ce niveau de granularité impacte la gestion de la classification du trafic car il génère des difficultés en termes d’optimisation de l’usage des ressources mises en œuvre par une ou plusieurs tranches réseau, et capables de répondre aux exigences variées des différentes tranches (exigences qui peuvent s’exprimer en termes de qualité de service, de sécurité, de résilience, etc.). De surcroît, selon un deuxième aspect, la manière dont sont actuellement identifiés des paquets destinés à être acheminés via une tranche réseau donnée est problématique. Plus particulièrement, cette identification s’appuie sur l’utilisation d’identifiants comme typiquement des adresses ou des préfixes IP. Or, dans certains environnements, plusieurs applications peuvent être joignables au moyen d’une même adresse IP alors même que ces applications peuvent être associées à des contraintes nécessitant d’acheminer les trafics respectifs via des tranches réseau distinctes. Enfin, et selon un troisième aspect, il convient de tenir compte de la variété d’usage d’une tranche réseau. Cette variété se manifeste notamment en termes de diversité de trafic, de nature de la structure qui exploite la tranche (par ex. service de comptabilité, service de R&D, service de production) ou encore de mode d’usage de la tranche (par ex. gestion des surcharges de trafic lors des heures chargées, ou principes de répartition de la charge de trafic). Cette complexité liée à la conception et à l’application de règles de classification de trafic peut en outre être aggravée par l’évolution desdites règles au cours du temps, selon la dynamique d’un ensemble de critères tels que l’évolution des besoins des utilisateurs ou la croissance de trafic. C’est par exemple le cas dans le contexte du déploiement d’une tranche pour la retransmission d’un événement sportif ou culturel, et où les règles de classification de trafic peuvent évoluer avec le nombre et le profil des utilisateurs de la tranche. En définitive, on comprend que ces différents aspects à prendre en compte dans la conception de règles de classification génèrent un risque important selon lequel une ou plusieurs de ces règles soient conçues de manière inadaptée. L’une des conséquences possibles d’une telle inadaptation est l’acheminement non-optimal des données au sein d’un réseau. La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette de gérer de manière beaucoup plus simple et efficace l’acheminement du trafic dans un réseau supportant des tranches réseau en comparaison avec les solutions de l’état de la technique. La solution proposée par l’invention permet notamment de simplifier (en termes de classification du trafic) les tâches réalisées par des nœuds d’un réseau supportant des tranches réseau, par exemple des nœuds de périphérie. A cet effet, et selon un premier aspect, l’invention concerne un procédé de configuration d’un réseau supportant N tranches réseau, N étant un nombre entier supérieur ou égal à 1, ledit procédé comportant des étapes de : - génération de M éléments de connexion, M étant un nombre entier supérieur ou égal à 1, chaque élément de connexion étant configuré pour permettre l’obtention d’au moins un identifiant de connexion destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - association d’au moins un élément de connexion à au moins une tranche réseau en fonction d’un critère d’association donné, - transmission de données indiquant les associations entre éléments de connexion et tranches réseau à un ensemble E d’entités du réseau configurées pour participer à l’acheminement de paquets de données au sein du réseau. Le fait de configurer des tranches réseau dans le réseau de cette manière se révèle particulièrement avantageux. En effet, les éléments de connexion ainsi générés sont non seulement partagés avec lesdites entités du réseau qui incluent notamment des entités en charge de la classification du trafic, notamment à la périphérie/bordure du réseau, mais sont également destinés à être partagés avec des terminaux qui souhaitent exploiter une ou plusieurs des tranches réseau pour communiquer. Plus particulièrement, lesdits éléments de connexion permettent de contrôler et de faciliter l’identification d’une ou plusieurs tranches appropriées pour acheminer des données dans le réseau, par exemple dans le cadre de l’exploitation d’une fonction applicative par un terminal. Cet acheminement optimisé de données via une ou plusieurs tranches réseau peut être réalisé en insérant dans les paquets de données des identifiants de connexion obtenus grâce auxdits éléments de connexion. Plus particulièrement, sur la base de tels identifiants de connexion, une entité du réseau, comme par exemple un nœud de périphérie, qui reçoit des paquets de données peut alors déterminer les éléments de connexion associés auxdits identifiants de connexion, et ainsi acheminer les paquets de données dans les tranches appropriées. Aucune limitation n’est attachée à la nature des identifiants de connexion pouvant être obtenus selon l’invention. En particulier, un identifiant de connexion peut être un identifiant de type « CID » (« Connection ID » en anglais) utilisé par le protocole QUIC ou le protocole DTLS (« Datagram Transport Layer Security » en anglais). Ces dispositions s’appliquent également pour ce qui concerne les éléments de connexion. Dans des modes particuliers de mise en œuvre, le procédé de configuration peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le nombre M est supérieur ou égal au nombre N. Dans des modes particuliers de mise en œuvre, au moins un élément de connexion est un motif configuré pour imposer, parmi la suite de bits formant un identifiant de connexion, la valeur d’au moins un bit ayant une position donnée au sein de ladite suite de bits. Dans des modes particuliers de mise en œuvre, au moins un élément de connexion est un ensemble comprenant au moins un identifiant de connexion donné. Dans des modes particuliers de mise en œuvre, ledit critère d’association consiste en ce qu’un élément de connexion donné est associé à une tranche réseau donnée. Dans des modes particuliers de mise en œuvre, ledit critère d’association consiste en ce que des tranches de même type sont associées à un ou plusieurs mêmes éléments de connexion. Dans des modes particuliers de mise en œuvre, le type d’une tranche est l’un quelconque parmi : - service mobile large bande amélioré, - déploiement massif de l’Internet des Objets, - communications ultra fiables et à faible latence. Dans des modes particuliers de mise en œuvre, l’ensemble E d’entités comporte au moins l’un parmi : - un serveur d’allocation d’adresses réseau, - un serveur d’allocation de préfixes réseau, - un routeur configuré pour activer une fonction de délégation de préfixes réseau, - un nœud de périphérie du réseau, comme par exemple un routeur d’accès ou un routeur « ASBR » (« Autonomous System Border Routers » en anglais). Dans des modes particuliers de mise en œuvre, au moins une tranche réseau est une tranche multi-domaines. Selon un autre aspect, l’invention concerne également un procédé de réception mis en œuvre par une entité d’un réseau supportant des tranches réseau et configuré conformément à un procédé de configuration selon l’invention, ledit procédé de réception comportant une étape de réception desdites données indiquant les associations entre éléments de connexion et tranches réseau. Selon un autre aspect, l’invention concerne un premier procédé de traitement de données mis en œuvre par un terminal connecté à au moins un réseau supportant des tranches réseau et configuré conformément à un procédé de configuration selon l’invention, ledit premier procédé de traitement de données comportant des étapes de : - transmission, à une entité dudit réseau, d’une requête d’obtention d’au moins un élément de connexion, - réception, en provenance de ladite entité, d’une réponse à ladite requête, ladite réponse comportant au moins élément de connexion associé à au moins une tranche réseau supportée par le réseau. Selon un autre aspect, l’invention concerne un deuxième procédé de traitement de données mis en œuvre par un équipement d’un réseau supportant des tranches réseau et configuré conformément à un procédé de configuration selon l’invention, ledit deuxième procédé de traitement de données comportant des étapes de : - réception, en provenance d’un terminal connecté audit réseau, d’une requête d’obtention d’au moins un élément de connexion, - transmission audit terminal d’une réponse à ladite requête, ladite réponse comportant au moins élément de connexion associé à au moins une tranche réseau supportée par le réseau. Dans des modes particuliers de mise en œuvre, le premier ou deuxième procédé de traitement de données peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, la requête d’obtention comporte au moins un paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter, la réponse à la requête comportant au moins un élément de connexion associé à une tranche elle-même associée audit identifiant ou à une tranche dudit type. Dans des modes particuliers de mise en œuvre, en l’absence dans la requête d’obtention d’un paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter, la réponse à la requête comporte au moins un élément de connexion associé à au moins une tranche à laquelle le terminal est autorisé à se connecter. Dans des modes particuliers de mise en œuvre, le type d’une tranche est l’un quelconque parmi : - service mobile large bande amélioré, - déploiement massif de l’Internet des Objets, - communication ultra fiable et à faible latence. Dans des modes particuliers de mise en œuvre, la réponse à la requête comporte en outre un identifiant dudit au moins un réseau supportant des tranches réseau. Dans des modes particuliers de mise en œuvre : - ledit terminal est un terminal utilisateur et l’entité dudit au moins un réseau est une entité dudit ensemble E, ou - ledit terminal est un serveur d’applications et l’entité dudit au moins un réseau est un dispositif d’orchestration configuré pour gérer des fonctions de service au sein dudit au moins un réseau. Selon un autre aspect, l’invention concerne un premier procédé de communication mis en œuvre par un premier terminal, dit « terminal client », pour échanger des données avec un deuxième terminal, dit « terminal serveur », le terminal client étant connecté à un réseau supportant des tranches réseau et configuré conformément à un procédé de configuration selon l’invention, et au moins un terminal, dit « terminal candidat », parmi ledit terminal client et ledit terminal serveur étant en possession d’au moins un élément de connexion dudit réseau, ledit procédé comportant des étapes de : - obtention d’une donnée désignant un terminal, dit « terminal primaire », parmi ledit au moins un terminal candidat, - si le terminal client est le terminal primaire : transmission, au terminal serveur, d’au moins un élément de connexion, dit « premier élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal client possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un premier élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - si le terminal serveur est le terminal primaire : réception, en provenance du terminal serveur, d’au moins un élément de connexion, dit « deuxième élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal serveur possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un deuxième élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau. Selon un autre aspect, l’invention concerne un deuxième procédé de communication mis en œuvre par un deuxième terminal, dit « terminal serveur », pour échanger des données avec un premier terminal, dit « terminal client », le terminal client étant connecté à un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’invention, et au moins un terminal, dit « terminal candidat », parmi ledit terminal client et ledit terminal serveur étant en possession d’au moins un élément de connexion dudit réseau, ledit procédé comportant des étapes de : - obtention d’une donnée désignant un terminal, dit « terminal primaire », parmi ledit au moins un terminal candidat, - si le terminal client est le terminal primaire : réception, en provenance du terminal client, d’au moins un élément de connexion, dit « premier élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal client possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un premier élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - si le deuxième terminal est le terminal primaire : transmission, au terminal client, d’au moins un élément de connexion, dit « deuxième élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal serveur possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un deuxième élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau. Dans des modes particuliers de mise en œuvre, le premier ou deuxième procédé de communication peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre : - si le terminal client ou le terminal serveur est l’unique terminal candidat, ledit terminal candidat est désigné comme étant le terminal primaire, ou - si le terminal client et le terminal serveur sont tous deux des terminaux candidats, la donnée désignant le terminal primaire est générée par un desdits deux terminaux candidats en fonction d’un critère de désignation donné. Dans des modes particuliers de mise en œuvre, l’obtention d’au moins un identifiant de connexion en utilisant au moins un élément de connexion comporte : - si ledit au moins un élément de connexion comporte un motif, une génération d’au moins un identifiant de connexion conforme audit motif, et/ou - si ledit au moins un élément de connexion comporte un ensemble d’identifiants de connexion donnés, une sélection d’au moins un identifiant de connexion parmi ledit ensemble. Dans des modes particuliers de mise en œuvre, le terminal client est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », et : - si le terminal client est le terminal primaire, ledit au moins un premier élément de connexion est associé à une ou plusieurs tranches actives, ou - si le terminal serveur est le terminal primaire, une liste comportant des identifiants et/ou des types desdites tranches actives est transmise par le terminal client au terminal serveur, ledit au moins un deuxième élément de connexion étant sélectionné par le terminal serveur parmi ledit au moins un élément de connexion qu’il possède et de sorte à être associé à au moins une tranche active. Dans des modes particuliers de mise en œuvre, une ou plusieurs tranches parmi les tranches actives sont configurées pour fournir une fonction applicative donnée. Dans des modes particuliers de mise en œuvre, avant l’obtention de la donnée désignant le terminal primaire, chaque terminal transmet à l’autre terminal une donnée configurée pour informer ledit autre terminal que ledit terminal transmettant ladite donnée est apte à communiquer en exploitant au moins l’une des tranches réseau supportées par le réseau. Selon un autre aspect, l’invention concerne un troisième procédé de communication par un nœud d’un réseau supportant des tranches réseau et configuré conformément à un procédé de configuration selon l’invention, ledit nœud appartenant audit ensemble E, ledit procédé de communication comportant des étapes de : - réception d’un paquet de données en provenance d’un terminal, dit « terminal émetteur », ledit paquet de données étant destiné à un autre terminal, dit « terminal récepteur », et comportant au moins un identifiant de connexion destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - acheminement du paquet de données vers le terminal récepteur en fonction dudit au moins un identifiant de connexion. Dans des modes particuliers de mise en œuvre, le troisième procédé de communication peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le paquet de données comporte un identifiant de connexion associé au terminal émetteur et un autre identifiant de connexion associé au terminal récepteur, ledit procédé comportant également des étapes de : - évaluation d’un critère de conformité en fonction desdits identifiants de connexion contenus dans le paquet de données, et - si le critère de conformité est satisfait : détermination de l’élément de connexion, dit « élément de connexion utile », associé à l’un desdits identifiants de connexion contenu dans le paquet de données, acheminement du paquet de données vers le terminal récepteur en utilisant une tranche réseau déterminée en fonction dudit élément de connexion utile, - si le critère de conformité n’est pas satisfait, acheminement du paquet de données vers le terminal récepteur en utilisant une tranche réseau désignée par défaut ou sans utiliser une tranche réseau supportée par le réseau. Dans des modes particuliers de mise en œuvre, l’évaluation du critère de conformité comporte une comparaison des valeurs d’au moins deux bits appartenant respectivement aux identifiants de connexion du terminal émetteur et du terminal récepteur contenus dans le paquet de données, chacun desdits bits ayant une position donnée au sein de la suite de bits formant l’identifiant de connexion auquel il appartient, ledit critère de conformité étant satisfait si lesdites valeurs sont identiques. Dans des modes particuliers de mise en œuvre, le terminal récepteur est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », et : - si le critère de conformité est satisfait et si la tranche associée audit élément de connexion utile est une tranche active, le paquet de données est acheminé en utilisant ladite tranche réseau associée audit élément de connexion utile, - si le critère de conformité est satisfait et si la tranche associée audit élément de connexion utile n’est pas une tranche active, le paquet de données est acheminé en utilisant une tranche réseau désignée par défaut. Dans des modes particuliers de mise en œuvre, le terminal récepteur est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », ledit procédé comportant une étape de détermination de l’élément de connexion, dit « élément de connexion utile », associé à un identifiant de connexion parmi ledit au moins un identifiant de connexion contenu dans le paquet de données, et : - si la tranche associée audit élément de connexion utile est une tranche active, le paquet de données est acheminé en utilisant ladite tranche réseau associée audit élément de connexion utile, - si la tranche associée audit élément de connexion utile n’est pas une tranche active, le paquet de données est acheminé en utilisant une tranche réseau désignée par défaut. Selon un autre aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un : - procédé de configuration selon l’invention, ou - procédé de réception selon l’invention, ou - premier procédé de traitement de données selon l’invention, ou - deuxième procédé de traitement de données selon l’invention, ou - premier procédé de communication selon l’invention, ou - deuxième procédé de communication selon l’invention, ou - troisième procédé de communication selon l’invention, lorsque ledit programme est exécuté par un ordinateur. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un autre aspect, l’invention concerne un support d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un autre aspect, l’invention concerne un dispositif de configuration comportant des moyens configurés pour mettre en œuvre un procédé de configuration selon l’invention. Selon un autre aspect, l’invention concerne une entité d’un réseau supportant des tranches réseau et comportant des moyens configurés pour mettre en œuvre : - un procédé de réception selon l’invention, et - un deuxième procédé de traitement de données selon l’invention. Selon un autre aspect, l’invention concerne un terminal comportant des moyens configurés pour mettre en œuvre : - un premier procédé de traitement de données selon l’invention, ainsi que : - un premier procédé de communication selon l’invention, ou - un deuxième procédé de communication selon l’invention. Selon un autre aspect, l’invention concerne un nœud d’un réseau supportant des tranches réseau et comportant des moyens configurés pour mettre en œuvre un troisième procédé de communication selon l’invention. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : FIG. 1 la FIG. 1 représente schématiquement un exemple de réseau supportant des tranches réseau selon l’état de la technique ; FIG. 2 la FIG. 2 représente schématiquement un système de configuration d’un réseau supportant des tranches réseau selon un mode particulier de réalisation de l’invention ; FIG. 3 la FIG. 3 représente schématiquement un exemple d’architecture matérielle d’un dispositif de configuration appartenant au système de la FIG. 2 ; FIG. 4 la FIG. 4 représente sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un premier procédé général mis en œuvre par le système de la FIG. 2 . Ledit procédé général englobe un procédé de configuration selon l’invention mis en œuvre par le dispositif de configuration de la FIG. 3 ; FIG. 5 la FIG. 5 représente schématiquement un système de traitement de données selon un mode particulier de réalisation de l’invention ; FIG. 6 la FIG. 6 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un autre procédé général mis en œuvre par le système de la FIG. 5 . Ledit autre procédé général englobe des premières variantes de premier et deuxième procédés de traitement de données selon l’invention respectivement mis en œuvre par un terminal utilisateur et un serveur DHCP ; FIG. 7 la FIG. 7 représente schématiquement un système de communication selon un mode particulier de réalisation de l’invention ; FIG. 8 la FIG. 8 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un autre procédé général mis en œuvre par le système de la FIG. 7 . Ledit autre procédé général englobe des premières variantes de premier et deuxième procédés de communication selon l’invention respectivement mis en œuvre par un terminal client et un terminal serveur ; FIG. 9 la FIG. 9 représente schématiquement un autre système de communication selon un mode particulier de réalisation de l’invention ; FIG. 10 la FIG. 10 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un autre procédé général mis en œuvre par le système de la FIG. 9 . Ledit autre procédé général englobe un procédé de communication selon l’invention mis en œuvre par un nœud (de périphérie) du réseau, ainsi que des procédés de communication respectivement mis en œuvre par un terminal émetteur et un terminal récepteur. Description de modes de réalisation La présente invention est décrite ici dans le cadre de la configuration et l’exploitation d’un réseau NET_5G de type 5G, supportant des tranches réseau et conçu pour permettre l’émission et la réception de paquets de données. Cette solution est appelée ici UMAMI (« collaborative qUic-based MAnageMent of slIced networks » en anglais). Cette configuration et cette exploitation du réseau NET_5G selon l’invention visent une gestion optimisée de l’acheminement du trafic dans ledit réseau NET_5G en comparaison avec les solutions de l’état de la technique, comme cela est décrit ultérieurement. Il convient de noter que l’invention reste applicable à d’autres types de réseaux tels que par exemple des réseaux B5G (« Beyond 5G » en anglais), mais également 6G quand cette technologie sera disponible, des réseaux IP/MPLS, etc. D’une manière générale, aucune limitation n’est attachée à la nature des réseaux de communication pouvant être considérés dans le cadre de la présente invention. Plus particulièrement, la mise en œuvre de l’invention telle que décrite ici s’effectue en quatre phases, qui correspondent à autant d’aspects distincts de l’invention. Ces quatre phases comportent : - une première phase permettant de réaliser une configuration spécifique du réseau NET_5G, de sorte qu’une tranche réseau est associée à un élément de connexion et que des entités du réseau configurées pour participer à l’acheminement de paquets de données au sein du réseau prennent connaissance de ces associations ; - une deuxième phase permettant de configurer un terminal connecté au réseau NET_5G afin qu’il découvre la configuration de ce dernier telle que déterminée lors de la première phase, plus particulièrement pour ce qui concerne le ou les élément(s) de connexion associés à la ou les tranches à laquelle/auxquelles le terminal est autorisé à se connecter ; - une troisième phase permettant à deux terminaux, dont au moins un est configuré conformément à la deuxième phase, d’établir une communication supportée par le réseau NET_5G en utilisant des éléments de connexion parmi ceux découverts lors de ladite deuxième phase, - une quatrième phase qui consiste en ce que la communication établie entre lesdits deux terminaux via le réseau NET_5G est exploitée pour leur permettre d’échanger des données. Ces différentes phases vont maintenant être décrites de manière détaillée afin d’illustrer des modes de mises en œuvre de l’invention. Il convient de noter qu’une « entité du réseau » fait ici référence de manière générale à une entité configurée pour assurer au moins une fonction dans le réseau. A ce titre, lorsque cela n’est pas explicitement indiqué, une « entité du réseau » peut indistinctement faire référence à une entité matérielle (par ex. un équipement matériel) ou à une entité logicielle (par ex. une application logicielle). Pour la suite de la description, et afin de simplifier celle-ci, on considère de manière nullement limitative que le réseau NET_5G supporte un nombre N de tranches égal à 3. Les trois tranches concernées sont respectivement notées TR_5G_1, TR_5G_2, TR_5G_3, et correspondent à trois tranches multi-domaines. Le fait de considérer des tranches multi-domaines ne constitue toutefois pas une limitation de l’invention. Ainsi, rien n’exclut d’envisager uniquement des tranches mono-domaine, ou bien une ou plusieurs tranches mono-domaine ainsi qu’une ou plusieurs tranches multi-domaines. L’invention n’est pas plus limitée par le fait d’envisager un nombre N de tranches égal à 3. D’une manière générale, l’invention peut être mise en œuvre pour tout nombre N supérieur ou égal à 1 (i.e. en d’autres termes, dès que le réseau en NET_5G comporte au moins une tranche réseau). Il importe de noter que la description est ici faite en adoptant la convention selon laquelle une tranche multi-domaines est comptabilisée pour une seule tranche, et non pas pour le nombre de tranches mono-domaine qu’elle comporte. Cette convention de comptage est cependant purement arbitraire, et rien n’exclut d’adopter une autre convention consistant à compter individuellement les tranches locales utilisées par une tranche multi-domaines. Par ailleurs, aucune limitation n’est attachée aux types respectifs desdites tranches TR_5G_1, TR_5G_2, TR_5G_3. Ainsi, le type d’une tranche TR_5G_i (i étant un indice entier compris entre 1 et 3) peut par exemple être l’un quelconque parmi : - service mobile large bande amélioré, - déploiement massif de l’Internet des Objets, - communications ultra fiables et à faible latence. De manière plus générale, l’invention peut être mise en œuvre indépendamment de toute limitation concernant les aspects suivants : nombre de sous-réseaux (domaines) par tranches multi-domaines, nombre de tranches mono-domaine d’un sous-réseau, nature d’un sous-réseau (par ex. RAN, CN ou TN), techniques utilisées pour la réalisation de tranches mono-domaine (par ex. tunnels IPsec, L3VPN + TE ou SRv6), etc. On considère également pour la suite de la description que chaque tranche TR_5G_i est associée à un identifiant ID_TR_i qui lui est propre. Cet identifiant ID_TR_i correspond par exemple à un identifiant utilisé par la tranche TR_5G_i et véhiculé dans des paquets de données (par ex. pour être ajouté dans un champ des paquets de données) qui sont acheminés via ladite tranche TR_5G_i. Selon un autre exemple, ledit identifiant ID_TR_i est distinct d’un identifiant utilisé par la tranche TR_5G_i pour acheminer des paquets de données. Première phase La FIG. 2 représente schématiquement un système SYS_1 de configuration du réseau NET_5G selon un mode particulier de réalisation de l’invention. Tel qu’illustré par la FIG. 2 , le système SYS_1 comporte une première entité 110 et une deuxième entité 120. La première entité 110 est un nœud de périphérie du réseau NET_5G. En tant que nœud de périphérie, il est notamment configuré pour classifier des paquets reçus en provenance de terminaux connectés au réseau NET_5G. Il peut s’agir par exemple d’un routeur d’accès ou d’un routeur de type « ASBR ». Dans l’exemple de la FIG. 2 , le nœud de périphérie 110 est représenté à la périphérie du réseau NET_5G, mais il apparaitra de manière évidente que cette représentation n’est qu’illustrative. En effet, ledit nœud de périphérie 110 peut être localisé ailleurs dans le réseau NET_5G, comme par exemple en bordure d’un sous-réseau appartenant à l’une des tranches TR_5G_i (par ex. raccordement à un réseau voisin). D’une manière générale, la personne du métier connait les localisations possibles pour un nœud de périphérie dans un réseau de communication, si bien que ces aspects ne sont pas davantage décrits ici. De plus, rien n’exclut de considérer d’autres types de nœuds dans la mesure où le trafic de gestion peut être injecté dans une tranche réseau via un routeur qui ne se trouve pas forcément à la périphérie d’un réseau. Cela peut par exemple concerner du trafic BFD (« Bidirectional Forwarding Detection » en anglais) acheminé dans une tranche de test déployée entre certains routeurs du réseau. La deuxième entité 120, quant à elle, est un serveur d’allocation d’adresses conforme au protocole « DHCP » (« Dynamic Host Configuration Protocol » en anglais). De manière plus générale, les entités 110 et 120 appartiennent à un ensemble d’entités, ci-après noté « ensemble E » (non représenté sur les figures), regroupant des entités du réseau NET_5G configurées pour participer à l’acheminement de paquets de données au sein dudit réseau NET_5G. Le fait de considérer, dans le présent mode de réalisation, un unique nœud de périphérie 110 ainsi qu’un unique serveur DHCP ne relève que de considérations visant à simplifier la description de l’invention. Ainsi, rien n’exclut d’envisager plusieurs nœuds de périphérie et/ou plusieurs serveurs DHCP. La liste des entités aptes à participer à l’acheminement de paquets de données au sein dudit réseau NET_5G ne se limite pas à un ou plusieurs nœuds de périphérie et/ou un ou plusieurs serveurs DHCP. Ainsi, outre les entités précitées, l’ensemble E peut comporter au moins l’un parmi : un serveur d’allocation de préfixes réseau, un routeur configuré pour activer une fonction de délégation de préfixes réseau, etc. Outre les entités de l’ensemble E, le système SYS_1 comporte un dispositif de configuration 130. Le dispositif 130 est configuré pour réaliser des traitements permettant de déterminer une configuration spécifique du réseau NET_5G, en mettant en œuvre des étapes d’un procédé de configuration selon l’invention. Il peut s’agir par exemple d’un dispositif d’orchestration, par exemple de type orchestrateur réseau ou bien de type contrôleur réseau (par ex. contrôleur SDN). Chacune des entités 110, 120 (ainsi que plus largement toute entité appartenant à l’ensemble E) est configurée pour réaliser des traitements permettant de prendre connaissance de la configuration spécifique du réseau NET_5G déterminée par le dispositif 130, en mettant en œuvre des étapes d’un procédé de réception selon l’invention. La FIG. 3 représente schématiquement un exemple d’architecture matérielle du dispositif de configuration 130 appartenant au système SYS_1 de la FIG. 2 . Tel qu’illustré par la FIG. 3 , le dispositif de configuration 130 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif de configuration 130 comporte, notamment, un processeur 131, une mémoire vive 132, une mémoire morte 133 et une mémoire non volatile 134. Il dispose en outre de moyens de communication 135. La mémoire morte 133 du dispositif de configuration 130 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 131 et sur lequel est enregistré un programme d’ordinateur PROG_136 conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de configuration. Le programme PROG_136 définit des modules fonctionnels du dispositif de configuration 130, qui s’appuient ou commandent les éléments matériels 131 à 135 du dispositif de configuration 130 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 135 permettent notamment au dispositif de configuration 130 d’échanger des données avec toute entité du réseau NET_5G, dont notamment les entités 110, 120 de l’ensemble E. A cet effet, les moyens de communication 135 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. Il importe de noter que la représentation de l’architecture matérielle du dispositif 130, suivant l’exemple de la FIG. 3 , correspond à une architecture matérielle générique d’un ordinateur. A ce titre, tou(te)s les autres dispositifs/entités/terminaux décrit(e)s ci-après en relation avec les différentes phases de l’invention et qui mettent en œuvre au moins une étape d’un procédé disposent, dans le mode de réalisation décrit ici, d’une architecture matérielle du même type que celle représentée par la FIG. 3 . En conséquence, les architectures matérielles de ces autres dispositifs/entités/terminaux ne sont pas représentées sur des figures dédiées. Le nœud de périphérie 110 dispose de l’architecture matérielle d’un ordinateur et comporte, notamment, un processeur 111, une mémoire vive 112, une mémoire morte 113 et une mémoire non volatile 114. Il dispose en outre de moyens de communication 115. La mémoire morte 113 du nœud de périphérie 110 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 111 et sur lequel est enregistré un programme d’ordinateur PROG_116 conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de réception. Le programme PROG_116 définit des modules fonctionnels du nœud de périphérie 110, qui s’appuient ou commandent les éléments matériels 111 à 115 du nœud de périphérie 110 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 115 permettent notamment au nœud de périphérie 110 d’échanger des données avec le dispositif de configuration 130. A cet effet, les moyens de communication 115 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. Le serveur DHCP 120 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le serveur DHCP 120 comporte, notamment, un processeur 121, une mémoire vive 122, une mémoire morte 123 et une mémoire non volatile 124. Il dispose en outre de moyens de communication 125. La mémoire morte 123 du serveur DHCP 120 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 121 et sur lequel est enregistré un programme d’ordinateur PROG_126 conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de réception. Le programme PROG_126 définit des modules fonctionnels du serveur DHCP 120, qui s’appuient ou commandent les éléments matériels 121 à 125 du serveur DHCP 120 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 125 permettent notamment au serveur DHCP 120 d’échanger des données avec le dispositif de configuration 130. A cet effet, les moyens de communication 125 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. La FIG. 4 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un premier procédé général 1000 mis en œuvre par le système SYS_1. Ledit procédé 1000 englobe le procédé de configuration selon l’invention mis en œuvre par le dispositif de configuration 130 de la FIG. 3 ainsi que les procédés de réception selon l’invention respectivement mis en œuvre par le nœud de périphérie 110 et le serveur DHCP 120. Tel qu’illustré par la FIG. 4 , le procédé 1000 comporte tout d’abord une étape 1100 de génération d’un nombre M d’éléments de connexion. Ladite étape 1100 est mise en œuvre par un module de génération MOD_GEN_130 équipant le dispositif de configuration 130, et fait partie du procédé de configuration. Plus particulièrement, dans le mode de mise en œuvre décrit ici, le nombre M est égal à 3. Les trois éléments de connexion sont respectivement notés ELE_CX _1, ELE_CX_2, ELE_CX_3 pour la suite de la description. Chacun desdits éléments de connexion ELE_CX_i est configuré pour permettre l’obtention d’au moins un identifiant de connexion. Il importe de noter qu’un identifiant de connexion obtenu à partir d’un élément de connexion ELE_CX_i constitue une information de joignabilité supplémentaire vis-à-vis d’informations de joignabilité usuelles telles qu’une adresse IP, une route par défaut, etc. A ce titre, un identifiant de connexion est destiné à être utilisé au niveau de la couche transport et/ou de la couche application du modèle OSI (« Open System Interconnection » en anglais) lors d’une communication via une ou plusieurs tranches réseau supportées par le réseau NET_5G (la communication concernée ici est une communication entre deux terminaux destinée à être réalisée lors de la quatrième phase mentionnée ci-avant, et étant entendu qu’un identifiant de connexion n'est donc pas spécifique à un terminal, c’est-à-dire n’est pas unique par terminal et ne permet pas non plus de joindre un terminal distant). Les identifiants de connexion pouvant être obtenus à partir de chacun desdits éléments de connexion ELE_CX _1, ELE_CX_2, ELE_CX_3 sont distincts des identifiants ID_TR_1, ID_TR_2, ID_TR_3 utilisés par les tranches pour marquer les paquets de données qui acheminés via les tranches TR_5G_1, TR_5G_2, TR_5G_3. Cette différence entre identifiant de connexion et identifiant de tranche TR_5G_i découle de l’utilisation faite des identifiants de connexion pour acheminer de manière appropriée des paquets de données entre deux terminaux, comme cela est décrit en détail ultérieurement. Aucune limitation n’est attachée à la structure ou à la taille d’un identifiant de connexion. Ainsi, chaque identifiant de connexion peut être encodé sur un nombre de bits donnés, par exemple sur 64 bits. Dans un exemple plus particulier de mise en œuvre, un identifiant de connexion est un identifiant de type « CID » (« Connection ID » en anglais) utilisé par le protocole QUIC ou le protocole DTLS (voir par exemple les informations fournies dans les RFC 9000 et 9146 pour ces deux protocoles). Ces dispositions peuvent également s’appliquer pour ce qui concerne les éléments de connexion. Au sens de la présente invention, il existe différentes configurations possibles pour un élément de connexion ELE_CX_i. Ainsi, et selon un exemple particulier de mise en œuvre, un élément de connexion ELE_CX_i est un motif configuré pour imposer, parmi la suite de bits formant un identifiant de connexion, la valeur d’au moins un bit ayant une position donnée au sein de ladite suite de bits. A titre illustratif, considérons que les identifiants pouvant être obtenus par un élément de connexion correspondent chacun à une suite de 10 bits. Considérons en outre, en tant qu’élément de connexion, un motif configuré pour imposer les valeurs 1, 1, 0 et 1 pour les bits respectivement situés de la deuxième à la cinquième position (en considérant un parcours des bits allant de la gauche vers la droite) parmi ladite suite de 10 bits formant un identifiant de connexion. De cette manière, le motif permet d’obtenir une pluralité d’identifiants de connexion, comme par exemple : 1110111111, 0110111111, etc. Aucune limitation n’est attachée au nombre de bits pour lesquels un motif impose des valeurs données, si ce n’est que ce nombre est strictement inférieur au nombre total de bits formant un identifiant de connexion. De surcroît, aucune limitation n’est attachée aux positions respectives des bits auxquels des valeurs sont imposées dans la suite de bits formant un identifiant de connexion. Selon un autre exemple particulier de mise en œuvre, un élément de connexion ELE_CX_i est un ensemble comprenant au moins un identifiant de connexion donné. Un tel ensemble peut par exemple être ordonné (suivant toute relation d’ordre connue) ou pas. Par ailleurs, dans le cas où au moins deux éléments de connexion correspondent à des ensembles d’identifiants de connexion donnés, lesdits au moins deux ensembles peuvent être contigus relativement à une relation d’ordre utilisée pour ordonner chacun d’entre eux. Il est à noter que la taille (i.e. le cardinal) d’un ensemble d’identifiants de connexion donnés ne constitue pas une limitation de l’invention. En outre, deux tels ensembles peuvent avoir des tailles identiques ou distinctes. Il ressort de ce qui précède qu’un identifiant de connexion est dit « conforme » à un élément de connexion ELE_CX_i lorsque : - la suite de bits formant ledit identifiant de connexion comporte, aux positions appropriées, les valeurs imposées par ledit élément de connexion ELE_CX_i si ce dernier est un motif, ou - ledit identifiant de connexion fait partie des identifiants listés dans un ensemble d’identifiants de connexions donnés si ledit élément de connexion ELE_CX_i est un tel ensemble. Une fois les éléments de connexion ELE_CX _1, ELE_CX_2, ELE_CX_3 générés, le procédé 1000 comporte une étape 1200 d’association d’au moins un élément de connexion à chaque tranche réseau TR_5G_1, TR_5G_2, TR_5G_3 en fonction d’un critère d’association donné. Ladite étape 1200 est mise en œuvre par un module d’association MOD_ASSO_130 équipant le dispositif de configuration 130, et fait partie du procédé de configuration. Plus particulièrement, dans le mode de mise en œuvre décrit ici, ledit critère d’association consiste en ce qu’un élément de connexion donné est associé à une tranche réseau donnée. Dit encore autrement, le critère d’association établit une correspondance bijective (biunivoque) entre les éléments de connexion ELE_CX _1, ELE_CX_2, ELE_CX_3 et les tranches réseau TR_5G_1, TR_5G_2, TR_5G_3. Pour la suite de la description, on considère que pour un indice i compris entre 1 et 3, l’élément de connexion ELE_CX_i est associé à la tranche TR_5G_i. Bien entendu, rien n’empêche d’envisager d’autres associations bijectives. De manière concrète, l’association entre éléments de connexion ELE_CX_i et tranches TR_5G_i est ici réalisée en remplissant une table TAB_1 au sein de laquelle sont indiquées les correspondances entre les éléments de connexion ELE_CX_i et les identifiants ID_TR_i respectivement associés auxdites tranches TR_5G_i. Ladite table TAB_1 est stockée par le dispositif de configuration 130, par exemple dans sa mémoire non volatile 134. Dans le présent mode de mise en œuvre, la table TAB_1 contient également les correspondances entre les identifiants ID_TR_i respectivement associés auxdites tranches TR_5G_i et les types respectifs de ces dernières. Le procédé 1000 comporte alors une étape 1300 de transmission de données indiquant les associations entre éléments de connexion ELE_CX_i et tranches réseau TR_5G_i à l’ensemble E d’entités du réseau NET_5G configurées pour participer à l’acheminement de paquets de données au sein dudit réseau NET_5G. Ladite étape 1300 est mise en œuvre par un module de transmission MOD_TX_130 équipant le dispositif de configuration 130, et fait partie du procédé de configuration. Ledit module de transmission MOD_TX_130 est plus particulièrement intégré aux moyens de communication 135. Dans le présent mode de mise en œuvre, et tel qu’illustré par la FIG. 4 , ladite transmission de données de l’étape 1300 comporte plus particulièrement une transmission de la table TAB_1 au nœud de périphérie 110 ainsi qu’au serveur DHCP 120. Par la suite, le procédé 1000 comporte une étape 1400 de réception par le nœud de périphérie 110 desdites données indiquant les associations entre éléments de connexion ELE_CX_i et tranches réseau TR_5G_i (i.e. réception de la table TAB_1). Ladite étape 1400 est mise en œuvre par un module de réception MOD_RX_110 équipant le nœud de périphérie 110, et fait partie du procédé de réception exécuté par ledit nœud de périphérie 110. Ledit module de réception MOD_RX_110 est plus particulièrement intégré aux moyens de communication 115. De manière similaire, le procédé 1000 comporte une étape 1500 de réception par le serveur DHCP 120 desdites données indiquant les associations entre les éléments de connexion ELE_CX_i et les tranches réseau TR_5G_i (i.e. réception de la table TAB_1). Ladite étape 1500 est mise en œuvre par un module de réception MOD_RX_120 équipant le serveur DHCP 120, et fait partie du procédé de réception exécuté par ledit serveur DHCP 120. Ledit module de réception MOD_RX_120 est plus particulièrement intégré aux moyens de communication 125. Une fois la table TAB_1 reçue par le nœud de périphérie 110 et le serveur DHCP 120, ces derniers la stockent dans leurs mémoires non volatiles 114, 124 respectives. Il importe de noter que le procédé 1000, et plus particulièrement le procédé de configuration, est décrit ici en considérant une association bijective entre éléments de connexion ELE_CX_i et tranches TR_5G_i, ce qui implique donc que les nombre N et M soient égaux (dans le cas présent, N = M = 3). Toutefois, il est possible d’envisager encore d’autres modes de mise en œuvre dans lesquels les nombres N et M diffèrent entre eux, ce qui a dès lors un impact sur les associations pouvant être réalisées entre éléments de connexion ELE_CX_i et tranches TR_5G_i. Ainsi, et selon une première variante, le nombre M d’éléments de connexion peut être supérieur au nombre N de tranches. De cette manière, une ou plusieurs tranches peuvent être associées à plus d’un élément de connexion. Dans ce cas, et à titre purement illustratif, le critère d’association peut par exemple consister à parcourir les N premiers éléments de connexion (à supposer qu’ils soient par exemple ordonnés entre eux suivant une relation d’ordre déterminée) pour les associer respectivement aux N tranches (à supposer également qu’elles soient ordonnées entre elles suivant une relation d’ordre déterminée). Puis, les M-N éléments de connexion restants sont par exemple associés aux M-N premières tranches. De cette manière, les M-N premières tranches sont respectivement associées à deux éléments de connexion, et les N dernières tranches sont respectivement associées à un unique élément de connexion. Par ailleurs, il convient de noter que la première phase de l’invention a été décrite jusqu’à présent en considérant que chaque tranche parmi les N tranches supportées par le réseau NET_5G est associée à au moins un élément de connexion. Toutefois, rien n’exclut d’envisager encore d’autres modes de mise en œuvre dans lesquels seule une partie des N tranches réseau fait l’objet d’une configuration selon le procédé 1000, la partie restante des tranches réseau étant quant à elle, par exemple, utilisée pour acheminer du trafic interne propre à l’opérateur du réseau (i.e. les tranches de ladite partie restante ne sont pas associées à des éléments de connexion). Il en découle alors une deuxième variante dans laquelle le nombre M d’éléments de connexion peut être inférieur au nombre N de tranches. Deuxième phase La FIG. 5 représente schématiquement un système SYS_2 de traitement de données selon un mode particulier de réalisation de l’invention. Comme cela est décrit ci-après, les traitements de données en question consistent, notamment, en la réalisation de communications permettant d’échanger des données entre différentes entités. Tel qu’illustré par la FIG. 5 , le système SYS_2 comporte un premier terminal 210 et un deuxième terminal 220. Le système SYS_2 comporte en outre le dispositif de configuration 130 de la FIG. 3 et le serveur DHCP 120. Il importe de noter que le réseau NET_5G représenté sur la FIG. 5 est celui résultant de l’exécution du procédé 1000 de la première phase. En d’autres termes, pour ce qui concerne cette deuxième phase, le réseau NET_5G est configuré de manière spécifique, c’est-à-dire de sorte que chaque tranche TR_5G_i est associée à un élément de connexion ELE_CX_i, les entités de l’ensemble E, donc en particulier le nœud de périphérie 110 et le serveur DHCP 120, ayant connaissance des associations via ladite table TAB_1. Il importe en outre de noter que cette deuxième phase est indépendante de la troisième phase d’établissement de communications par des terminaux connectés au réseau. Dit encore autrement, le déclenchement de la deuxième phase n’est pas conditionné par celui de la troisième phase. Le premier terminal 210 est un terminal utilisateur (i.e. un terminal exploité par un utilisateur). Il peut par exemple s’agir d’un téléphone fixe ou bien mobile, comme par exemple un téléphone mobile intelligent (encore dit « smartphone » en anglais), d’une tablette numérique, d’un ordinateur portable, d’un assistant personnel, d’une montre connectée, d’une liseuse électronique, etc. Il peut aussi s’agir d’une entité du type « CPE » (« Customer-Premises Equipment » en anglais). D’une manière générale, aucune limitation n’est attachée à la nature du terminal utilisateur 210. Le deuxième terminal 220, quant à lui, est un serveur d’applications. De manière connue, le serveur d’applications 220 est configuré pour fournir une ou plusieurs fonctions de service (« Service Functions » en anglais, selon la terminologie utilisée par le RFC 7665, ou « Network Functions » comme gNB (« gNodeB ») ou des fonctions UPF (« User Plane Function ») selon la terminologie utilisée par le 3GPP). Une même fonction service peut être fournie par une ou plusieurs instances de service (« Service Function Instance », en anglais). Une instance de service peut être hébergée par le SSP (Slice Service Provider, ou fournisseur de services reposant sur des tranches réseau) ou au sein d’une autre infrastructure. Il est à noter que, dans le mode de réalisation décrit ici en référence à la FIG. 5 , on considère de manière nullement limitative que le terminal utilisateur 210 et le serveur d’applications 220 sont uniquement connectés au réseau NET_5G. Ces dispositions ne sont toutefois pas limitatives de l’invention, et rien n’exclut que le terminal utilisateur 210 et/ou le serveur d’applications 220 soi(en)t connecté(s) à plusieurs autres réseaux. Ces autres réseaux peuvent notamment comporter des réseaux supportant des tranches réseau et au moins une partie d’entre eux (voire tous) peut être configurée conformément à la première phase. Le fait que le terminal utilisateur 210 et le serveur d’applications 220 soient connectés au réseau NET_5G résulte par exemple d’une souscription de ces terminaux 210, 220 à une offre de service auprès de l’opérateur réseau en charge de la gestion dudit réseau NET_5G, de sorte à pouvoir utiliser une ou plusieurs des tranches réseau supportées par ce réseau. En tout état de cause, dans le présent mode de réalisation, le terminal utilisateur 210 (respectivement le serveur d’applications 220) est autorisé (habilité) à se connecter à au moins une tranche parmi les tranches TR_5G_1, TR_5G_2, TR_5G_3. Cette autorisation (habilitation) dépend de droits d’accès du terminal utilisateur 210 (respectivement du serveur d’applications 220) au réseau NET_5G tels que configurés lors de la souscription à une offre de service. La ou les tranches auxquelles le terminal utilisateur 210 (respectivement le serveur d’applications 220) est autorisé (habilité) à se connecter sont dites « tranche(s) autorisée(s) ». Aucune limitation n’est attachée au nombre de tranches auxquelles le terminal utilisateur 210 (respectivement le serveur d’applications 220) est autorisé à se connecter, cet aspect pouvant par exemple dépendre de l’offre de service souscrite. Pour la suite de la description, on considère de manière nullement limitative que les tranches auxquelles le terminal utilisateur 210 (respectivement le serveur d’applications 220) est autorisé à se connecter sont les tranches TR_5G_1, TR_5G_2 (respectivement les tranches TR_5G_2, TR_5G_3). Le terminal utilisateur 210 est configuré pour réaliser des traitements lui permettant de découvrir la configuration spécifique du réseau NET_5G résultant de la première phase, en mettant en œuvre des étapes d’une première variante d’un premier procédé de traitement de données selon l’invention. Plus particulièrement, la découverte de cette configuration spécifique du réseau NET_5G par le terminal utilisateur 210 s’effectue grâce à des échanges de données avec le serveur DHCP 120. Aussi, outre la configuration déjà décrite ci-avant dans le cadre de la première phase, le serveur DHCP 120 est également configuré pour réaliser lesdits échanges de données avec le terminal utilisateur 210, en mettant en œuvre une première variante d’un deuxième procédé de traitement de données selon l’invention. A cet effet, le terminal utilisateur 210 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le terminal utilisateur 210 comporte, notamment, un processeur 211, une mémoire vive 212, une mémoire morte 213 et une mémoire non volatile 214. Il dispose en outre de moyens de communication 215. La mémoire morte 213 du terminal utilisateur 210 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 211 et sur lequel est enregistré un programme d’ordinateur PROG_216 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la première variante du premier procédé de traitement de données. Le programme PROG_216 définit des modules fonctionnels du terminal utilisateur 210, qui s’appuient ou commandent les éléments matériels 211 à 215 du terminal utilisateur 210 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 215 permettent notamment au terminal utilisateur 210 d’échanger des données avec des entités du réseau NET_5G, dont notamment le serveur DHCP 120. A cet effet, les moyens de communication 215 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. Par ailleurs, la mémoire morte 123 du serveur DHCP 120 stocke, outre le programme d’ordinateur PROG_126, un autre programme PROG_127 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la première variante du deuxième procédé de traitement de données. Le programme PROG_127 définit des modules fonctionnels du serveur DHCP 120, qui s’appuient ou commandent les éléments matériels 121 à 125 du serveur DHCP 120, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. De plus, les moyens de communication 125 permettent au serveur DHCP 120 d’échanger des données avec le terminal utilisateur 210 selon toutes caractéristiques techniques envisageables par la personne du métier, comme par exemple celles déjà décrites ci-avant. Sauf mention contraire, la suite de la description vise à détailler des modes de mises en œuvre desdites premières variantes des premier et deuxième procédés de traitement de données tels qu’exécutés respectivement par le terminal utilisateur 210 et le serveur DHCP 120. Il n’en reste pas moins que l’invention vise également d’autres variantes des premier et deuxième procédés de traitement de données, ces autres variantes étant exécutées respectivement par le serveur d’applications 220 et le dispositif de configuration 130. Ces aspects sont détaillés ultérieurement. La FIG. 6 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un deuxième procédé général 2000 mis en œuvre par le système SYS_2. Ledit procédé 2000 englobe les premières variantes des premier et deuxième procédés de traitement de données selon l’invention respectivement mis en œuvre par le terminal utilisateur 210 et le serveur DHCP 120. Tel qu’illustré par la FIG. 6 , le procédé 2000 comporte tout d’abord une étape 2100 de transmission, de la part du terminal utilisateur 210 au serveur DHCP 120, d’une requête REQ d’obtention d’au moins un élément de connexion. Ladite étape 2100 est mise en œuvre par un module de transmission MOD_TX_210 équipant le terminal utilisateur 210, et fait partie de la première variante du premier procédé de traitement de données. Ledit module de transmission MOD_TX_210 est plus particulièrement intégré aux moyens de communication 215. Pour obtenir au moins un élément de connexion, et selon un premier exemple de mise en œuvre, la requête REQ peut comporter au moins un paramètre PAR_CX correspondant à un identifiant de tranche ou à un type de tranche (par ex. service mobile large bande amélioré, déploiement massif de l’Internet des Objets, communications ultra fiables et à faible latence) à laquelle le terminal est autorisé à se connecter. Dans le cas présent, et si le paramètre PAR_CX correspond à un identifiant de tranche à laquelle le terminal est autorisé à se connecter, il peut s’agir de l’identifiant ID_TR_1 ou de l’identifiant ID_TR_2 étant donné que les tranches autorisées associées au terminal utilisateur 210 sont les tranches TR_5G_1, TR_5G_2. Bien entendu, rien n’exclut d’envisager que la requête comporte une pluralité de paramètres, chacun desdits paramètres correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter. Par ailleurs, aucune limitation n’est attachée quant à la manière dont ledit au moins un paramètre PAR_CX est inséré dans la requête REQ. Par exemple, ledit au moins un paramètre PAR_CX peut être inséré dans le corps ou l’en-tête de la requête REQ, par exemple dans un champ spécifique. Ladite requête REQ peut par exemple être intégrée à une requête visant à obtenir, de la part du serveur DHCP 120, une adresse IP ou un préfixe IP. En d’autres termes, ledit au moins un paramètre PAR_CX peut être vu comme une nouvelle option DHCP configurée pour être insérée dans une telle requête de demande d’attribution d’une adresse IP ou d’un préfixe IP. Dans un deuxième exemple de mise en œuvre, la requête REQ ne comporte pas de paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter. En d’autres termes, dans ce deuxième exemple de mise en œuvre, la requête REQ est une requête d’ordre général pour obtenir au moins un élément de connexion, cette requête d’ordre général ne comportant aucune indication (information, pointeur) relative aux tranches réseau supportées par le réseau NET_5G. Le serveur DHCP reçoit alors ladite requête REQ au cours d’une étape 2200 du procédé 2000. Ladite étape 2200 est mise en œuvre par le module de réception MOD_RX_120 équipant le serveur DHCP 120, et fait partie de la première variante du deuxième procédé de traitement de données. Le procédé 2000 comporte alors une étape 2300 de transmission, de la part du serveur DHCP 120 au terminal utilisateur 210, d’une réponse REP_REQ à ladite requête REQ. Ladite étape 2200 est mise en œuvre par un module de transmission MOD_TX_120 équipant le serveur DHCP 120, et fait partie de la première variante du deuxième procédé de traitement de données. Ladite réponse REP_REQ comporte au moins un élément de connexion associé à au moins une tranche du réseau NET_5G. Il est à noter que, suivant des considérations similaires à celles décrites ci-avant concernant l’insertion dudit au moins un paramètre PAR_CX dans la requête REQ, ledit au moins un élément de connexion peut être inséré dans le corps ou l’en-tête de la réponse REP_REQ, par exemple dans un champ spécifique. Ladite réponse REP_REQ peut éventuellement inclure des informations de connectivité du terminal 210 telles qu’une adresse IP ou un préfixe IP. Plus particulièrement, ledit au moins un élément de connexion inséré dans la réponse REP_REQ dépend du contenu de la requête REQ. Ainsi, si on considère le premier exemple de mise en œuvre selon lequel la requête REQ comporte au moins un paramètre PAR_CX, la réponse REP_REQ comporte alors au moins un élément de connexion associé à une tranche elle-même associée audit identifiant défini par ledit au moins un paramètre PAR_CX ou à une tranche dudit type défini par ledit au moins un paramètre PAR_CX. A titre illustratif, si la requête REQ comporte un paramètre PAR_CX correspondant à l’identifiant ID_TR_1 de la tranche TR_5G_1 autorisée pour le terminal utilisateur 210, la réponse REP_REQ comporte alors l’élément de connexion ELE_CX_1 associé à la tranche TR_5G_1 ainsi identifiée par ledit identifiant ID_TR_1. Pour retrouver ledit élément de connexion ELE_CX_1 en fonction de l’identifiant ID_TR_1, le serveur DHCP 120 utilise la table TAB_1 obtenue suite à l’exécution de la première phase. Suivant un autre cas, si le paramètre PAR_CX est un type de tranche, la réponse REP_REQ comporte alors au moins un élément de connexion ELE_CX_i associé à la ou les tranches TR_5G_i (i pouvant être égal à 1 ou 2 ici) dudit type. A titre illustratif, si les tranches TR_5G_1, TR_5G_2 sont toutes les deux du même type, et que ce type est celui désigné par le paramètre PAR_CX, la réponse REP_REQ peut comporter l’élément de connexion ELE_CX_1 et/ou l’élément de connexion ELE_CX_2. Si par contre les tranches TR_5G_1, TR_5G_2 sont de types distincts, et le type désigné par le paramètre PR_CX est celui de la tranche TR_5G_1, alors la réponse REP_REQ comporte uniquement l’élément de connexion ELE_CX_1. Pour retrouver un élément de connexion ELE_CX_i en fonction d’un type de tranche, le serveur DHCP 120 utilise la table TAB_1 obtenue suite à l’exécution de la première phase. Alternativement, si on considère désormais le deuxième exemple de mise en œuvre selon lequel la requête REQ ne comporte pas de paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal 210 est autorisé à se connecter, la réponse REP_REQ comporte alors au moins un élément de connexion associé à au moins une tranche à laquelle le terminal utilisateur 210 est autorisé à se connecter. Ledit au moins élément de connexion peut par exemple correspondre à l’ensemble des éléments de connexion ELE_CX_1, ELE_CX_2 associés aux tranches auxquelles le terminal utilisateur 210 est autorisé à se connecter. Alternativement, ledit au moins un élément de connexion peut être sélectionné par le serveur DHCP 120 en fonction d’un critère de sélection donné. A titre d’exemple nullement limitatif, ledit critère de sélection consiste en une sélection aléatoire entre les éléments de connexion ELE_CX_1, ELE_CX_2. Selon un autre exemple, le critère de sélection peut dépendre d’une politique plus spécifique de droits d’accès définie au niveau du serveur DHCP 120. D’une manière générale, aucune limitation n’est attachée à la manière dont le critère de sélection est défini. Il convient de noter que si la requête REQ comporte plusieurs paramètres dont au moins un paramètre correspondant à un identifiant d’une tranche, ainsi qu’au moins paramètre correspondant à un type de tranche, il est possible d’envisager différentes règles pour déterminer le contenu de la réponse REP_REQ. Par exemple, une règle peut consister en ce que la réponse REP_REQ comporte tous les éléments de connexion possibles (i.e. les éléments de connexion associés audit identifiant et/ou associés audit type). Selon un autre exemple, une règle peut consister en ce qu’un élément de connexion contenu dans la réponse REP_REQ est conforme à la fois audit identifiant et audit type. Le procédé 2000 comporte finalement une étape 2400 de réception, de la part du terminal utilisateur 210 et en provenance du serveur DHCP 120, de la réponse REP_REQ. Ladite étape 2400 est mise en œuvre par un module de réception MOD_RX_210 équipant le terminal utilisateur 210, et fait partie de la première variante du premier procédé de traitement de données. Ledit module de réception MOD_RX_210 est plus particulièrement intégré aux moyens de communication 215. Le contenu de la réponse REP_REQ est stocké dans la mémoire non volatile 214 du téléphone utilisateur 210, par exemple sous la forme d’une table TAB_210. Ladite table TAB_210 répertorie donc des éléments de connexion associés à des tranches réseau. Les éléments de connexion contenus dans cette table TAB_210 peuvent dès lors être partagés avec des applications logicielles hébergées par le terminal utilisateur 210, de sorte que celles-ci puissent émettre des données sur le réseau NET_5G avec des identifiants de connexion conformes aux éléments de connexion de la table TAB_210, comme décrit en détail ultérieurement. Le partage de ces éléments de connexion avec les applications logicielles s’effectue par exemple grâce à une interface de programmation d’application « API » (« Application Programming Interface » en anglais) de type connu en soi. Il convient de noter que, suivant encore d’autres modes de réalisation, la réponse REP_REQ à la requête REQ peut comporter, outre un ou plusieurs éléments de connexion, un identifiant du réseau NET_5G. Ces dispositions sont avantageuses dans la mesure où le terminal utilisateur 210 a la possibilité d’être connecté à d’autres réseaux, dont notamment d’autres réseaux supportant des tranches réseau. Dès lors, le fait d’inclure un tel identifiant du réseau NET_5G permet au terminal utilisateur 210 d’associer de manière correcte les éléments de connexion reçus aux tranches réseau appropriées. Le terminal utilisateur 210 peut par exemple maintenir la seule table TAB_210, cette dernière comprenant dès lors une entrée permettant de discriminer, à l’aide d’identifiants de réseaux, les réseaux auxquels ledit terminal utilisateur 210 peut se connecter. En variante, le terminal utilisateur 210 peut maintenir plusieurs tables, par exemple une table pour chaque réseau auquel il peut se connecter. Le procédé 2000 a été décrit jusqu’à présent en considérant que le terminal utilisateur 210 échange des données avec le serveur DHCP 120 pour obtenir des éléments de connexion associés à des tranches supportées par le réseau NET_5G. Toutefois, rien n’exclut d’envisager que le procédé 2000 soit en mis en œuvre sur la base d’échanges de données entre le terminal utilisateur 210 et une autre entité du réseau appartenant à l’ensemble E. Par ailleurs, et comme mentionné ci-avant, l’invention couvre également des deuxièmes variantes desdits premier et deuxième procédés de traitement de données, ces deuxièmes variantes étant respectivement exécutées par le serveur d’applications 220 et un dispositif d’orchestration configuré pour gérer des fonctions de service au sein dudit au moins un réseau (par ex. un orchestrateur réseau ou un contrôleur SDN), ce rôle tant ici joué par le dispositif de configuration 130. Le serveur d’applications 220 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le serveur d’applications 220 comporte, notamment, un processeur 221, une mémoire vive 222, une mémoire morte 223 et une mémoire non volatile 224. Il dispose en outre de moyens de communication 225. La mémoire morte 223 du serveur d’applications 220 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 211 et sur lequel est enregistré un programme d’ordinateur PROG_226 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la deuxième variante du premier procédé de traitement de données. Le programme PROG_226 définit des modules fonctionnels du serveur d’applications 220, qui s’appuient ou commandent les éléments matériels 221 à 225 du serveur d’applications 220 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 225 permettent notamment au serveur d’applications 220 d’échanger des données avec le dispositif de configuration 130. A cet effet, les moyens de communication 225 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. Par ailleurs, et comme illustré sur la FIG. 3 , la mémoire morte 133 du dispositif de configuration 130 stocke, outre le programme d’ordinateur PROG_136, un autre programme PROG_137 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la deuxième variante du deuxième procédé de traitement de données. Le programme PROG_137 définit des modules fonctionnels du dispositif de configuration 130, qui s’appuient ou commandent les éléments matériels 131 à 135 du dispositif de configuration 130. Ces modules fonctionnels sont également illustrés sur la FIG. 3 à titre nullement limitatif, et sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. De plus, les moyens de communication 135 permettent au dispositif de configuration 130 d’échanger des données avec le serveur d’applications 220 selon toutes caractéristiques techniques envisageables par la personne du métier, comme par exemple celles déjà décrites ci-avant. Il est dès lors possible de définir un troisième procédé général 3000 (non illustré par les figures) mis en œuvre par le système SYS_2. Ledit procédé 3000 englobe les deuxièmes variantes des premier et deuxième procédés de traitement de données selon l’invention respectivement mis en œuvre par le serveur d’applications 220 et le dispositif de configuration 130 de la FIG. 3 . La mise en œuvre du procédé 3000 est similaire à celle du procédé 2000 hormis que le serveur d’applications 220 (respectivement le dispositif de configuration 130) joue ici le rôle du terminal utilisateur 210 (respectivement du serveur DHCP 120). En conséquence, le procédé 3000 comporte : - une étape 3100 de transmission et une étape 3400 de réception respectivement similaires aux étapes 2100 et 2400. Lesdites étapes 3100 et 3400 sont respectivement mises en œuvre par un module de transmission MOD_TX_220 et un module de réception MOD_RX_220 équipant le serveur d’applications 220, et font partie de la deuxième variante du premier procédé de traitement de données ; - une étape 3200 de réception et une étape 3300 de transmission respectivement similaires aux étapes 2200 et 2300. Lesdites étapes 3200 et 3200 sont respectivement mises en œuvre par un module de réception MOD_RX_130 et le module de transmission MOD_TX_130 équipant le dispositif de configuration 130, et font partie de la deuxième variante du deuxième procédé de traitement de données. Il convient de noter que dans la mesure où le serveur d’applications 220 échange ici des données avec le dispositif de configuration 130, la requête REQ transmise au cours de l’étape 3100 n’est pas une requête visant à obtenir une adresse IP comme cela était le cas dans l’exemple du procédé 2000. Dans le cadre du procédé 3000, ladite requête REQ est par exemple une requête de souscription à un service permettant d’utiliser une ou plusieurs des tranches réseau supportées par le réseau NET_5G. De manière générale, toutes les caractéristiques techniques décrites ci-avant dans le cadre du procédé 2000 et qui sont compatibles avec la mise en œuvre du procédé 3000 s’appliquent encore dans le cadre de ce dernier. En particulier, le contenu de la réponse REP_REQ est stocké dans la mémoire non volatile 224 du serveur d’applications 220, par exemple sous la forme d’une table TAB_220 comprenant un ou plusieurs éléments de connexion. Troisième phase La FIG. 7 représente schématiquement un système SYS_3 de communication selon un mode particulier de réalisation de l’invention. Il importe de noter que le réseau NET_5G représenté sur la FIG. 7 est celui résultant de l’exécution du procédé 1000 de la première phase. En d’autres termes, pour ce qui concerne cette troisième phase, le réseau NET_5G est configuré de manière spécifique, c’est-à-dire de sorte que chaque tranche TR_5G_i est associée à un élément de connexion ELE_CX_i. Tel qu’illustré par la FIG. 7 , le système SYS_3 comporte un premier terminal 310 et un deuxième terminal 320. Plus particulièrement, on suppose ici que le terminal 310 joue le rôle de client et que le terminal 320 joue le rôle de serveur dans le cadre d’une communication destinée à être établie entre ces derniers. Cette communication a pour objectif de permettre au terminal client 310 d’exploiter, dans le cadre d’une offre de service souscrite par l’utilisateur dudit terminal client 310, une fonction applicative donnée (par ex. : exploitation d’une fonction de réalité augmentée ou virtuelle) fournie par le terminal serveur 320. Pour la suite de la description, et à titre purement illustratif, on considère que la tranche du réseau NET_5G permettant d’exploiter ladite fonction applicative sont les tranches TR_5G_1 et TR_5G_2. Plus particulièrement, la tranche TR_5G_1 (respectivement la tranche TR_5G_2) est associée à la gestion d’aspects vidéo (respectivement d’aspect voix) de ladite fonction applicative. On considère en outre que le terminal client 310 a fait l’objet d’une exécution du procédé 2000 de la deuxième phase. En d’autres termes, le terminal client 310 a mémorisé une table TAB_310 comportant des éléments de connexion relatifs à une ou plusieurs tranches supportées par le réseau NET_5G. On suppose plus particulièrement que : - à l’issue de l’exécution du procédé 2000 de la deuxième phase, le terminal client 310 a reçu les éléments de connexion ELE_CX_1, ELE_CX_2, ELE_CX_3, et - au démarrage de ladite troisième phase, le terminal client 310 est connecté aux tranches TR_5G_1, TR_5G_2, TR_5G_3. Pour ces raisons, lesdites tranches TR_5G_1, TR_5G_2, TR_5G_3 sont qualifiées ci-après de tranches « actives ». Il importe toutefois de noter que l’invention n’est pas limitée par le fait que les tranches actives correspondent à l’ensemble des tranches pour lesquelles le terminal client 310 dispose d’éléments de connexion. Ainsi, lesdites tranches actives auxquelles le terminal client 310 est connecté lors de la troisième phase peuvent correspondre à un sous-ensemble des tranches pour lesquelles le terminal client 310 dispose d’éléments de connexion. Le fait que le terminal client 310 soit connecté à telle ou telle tranche au début de la troisième phase dépend par exemple d’options auxquelles un client, utilisateur du terminal 310, a souscrit dans le cadre d’une offre de service. Pour ce qui est du terminal serveur 320, et dans la mesure où celui-ci est configuré pour fournir ladite fonction applicative, il est en possession des éléments de connexion ELE_CX_1, ELE_CX_2 respectivement associées aux tranches TR_5G_1, TR_5G_2. Il est à noter que le terminal serveur 320 peut être connecté directement au réseau NET_5G ou bien être connecté directement à un réseau autre que ledit réseau NET_5G tout en étant bien entendu joignable via ledit réseau NET_5G. Il est à noter que les dispositions selon lesquelles le terminal client 310 a fait l’objet d’une exécution du procédé 2000 de la deuxième phase ne sont pas limitatives de l’invention. En effet, rien n’exclut d’envisager que le terminal client 310 ait acquis les éléments de connexion ELE_CX_1, ELE_CX_2, ELE_CX_3 d’une autre manière. Par exemple, ces derniers peuvent avoir été inscrits dans une mémoire du terminal client 310 lors de sa fabrication. Suivant des considérations similaires, aucune limitation n’est attachée à la manière dont le terminal serveur 320 acquiert les éléments de connexion ELE_CX_1, ELE_CX_2. Pour la suite de la description, et dans la mesure où le terminal client 310 et le terminal 320 sont tous deux en possession d’éléments de connexion, lesdits terminaux sont qualifiés de terminaux « candidats ». Comme cela est détaillé ci-après, cette terminologie fait référence au fait que chacun desdits terminaux 310, 320 est un candidat potentiel pour être désigné en tant que terminal apte à imposer à l’autre terminal l’utilisation de certains éléments de connexion qui sont en sa possession pour communiquer via le réseau NET_5G. En tout état de cause, l’invention n’est pas limitée par le fait que le terminal client 310 et le terminal serveur 320 soient tous deux des terminaux candidats, comme cela est décrit ultérieurement au travers de modes de mise en œuvre alternatifs. Le terminal client 310 (respectivement le terminal serveur 320) est configuré pour réaliser des traitements permettant d’établir avec le terminal serveur 320 (respectivement avec le terminal client 310) une communication supportée par une ou plusieurs des tranches actives TR_5G_1, TR_5G_2 et TR_5G_3, en mettant en œuvre une première variante d’un premier procédé de communication selon l’invention (respectivement une première variante d’un deuxième procédé de communication selon l’invention). A cet effet, le terminal client 310 dispose de l’architecture matérielle d’un ordinateur. Le terminal client 310 comporte, notamment, un processeur 311, une mémoire vive 312, une mémoire morte 313 et une mémoire non volatile 314. Il dispose en outre de moyens de communication 315. La mémoire morte 313 du terminal client 310 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 311 et sur lequel est enregistré : - un programme d’ordinateur PROG_316 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la première variante du premier procédé de traitement de données (étant donné qu’il est supposé ici que le terminal client 310 a fait l’objet d’une exécution du procédé 2000 de la deuxième phase), - un programme d’ordinateur PROG_317 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la première variante du premier procédé de communication. Le programme PROG_317 définit des modules fonctionnels du terminal client 310, qui s’appuient ou commandent les éléments matériels 311 à 315 du terminal client 310 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 315 permettent notamment au terminal client 310 d’échanger des données avec le terminal serveur 320. A cet effet, les moyens de communication 315 peuvent par exemple comporter un bus de données informatiques apte à la transmission desdites données. Alternativement, lesdites données peuvent être transmises via une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté connu de l’homme du métier. A titre d’exemple nullement limitatif, les échanges entre le premier terminal 310 et le deuxième terminal 320, tels que décrits ci-après, sont reposent sur le protocole QUIC. Ces échanges comportent notamment l’envoi et la réception de données pouvant être encapsulées dans des trames QUIC existantes ou de nouvelles trames définies spécifiquement pour les besoins de mise en œuvre de l’invention. Le terminal serveur 320 dispose également de l’architecture matérielle d’un ordinateur. Ainsi, le terminal utilisateur 320 comporte, notamment, un processeur 321, une mémoire vive 322, une mémoire morte 323 et une mémoire non volatile 324. Il dispose en outre de moyens de communication 325. La mémoire morte 323 du terminal serveur 320 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 321 et sur lequel est enregistré un programme d’ordinateur PROG_327 conforme à l’invention, comportant des instructions pour l’exécution d’étapes de la première variante du deuxième procédé de communication. Le programme PROG_327 définit des modules fonctionnels du terminal serveur 320, qui s’appuient ou commandent les éléments matériels 321 à 325 du terminal utilisateur 320 cités précédemment, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. Les moyens de communication 325 permettent notamment au terminal serveur 320 d’échanger des données avec le terminal client 310 suivant des caractéristiques similaires à celles décrites ci-avant pour les moyens de communication 315 du terminal client 310. La FIG. 8 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un quatrième procédé général 4000 mis en œuvre par le système SYS_3. Ledit procédé 4000 englobe les premières variantes des premier et deuxième procédés de communication selon l’invention respectivement mis en œuvre par le terminal client 310 et le terminal serveur 320 de. Le procédé 4000 comporte tout d’abord une étape 4050 de transmission, de la part du terminal client 310 au terminal serveur 320, d’une donnée DATA_INFO_310 configurée pour informer le terminal serveur 320 que le terminal client 310 est apte à communiquer en exploitant au moins l’une des tranches réseau supportées par le réseau NET_5G. Ladite étape 4050 est mise en œuvre par le module de transmission MOD_TX_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Il est à noter que ladite donnée DATA_INFO_310 a pour seul but d’informer le terminal serveur 320 que le terminal client 310 a la possibilité de communiquer via une ou plusieurs tranches supportées par le réseau NET_5G, et à ce titre n’inclut pas d’éléments de connexion. Aucune limitation n’est attachée à la manière dont ladite donnée DATA_INFO_310 est transmise au terminal serveur 320. Par exemple, ladite donnée DATA_INFO_310 peut être encapsulée dans une trame, par exemple une trame de contrôle ou une trame de données. En outre, la nature de ladite donnée DATA_INFO_310 n’est pas non plus une limitation de l’invention, cette dernière pouvant être un paramètre numérique ou du texte prédéterminé représentatif du fait que le terminal client 310 supporte la communication via des tranches réseau. Le terminal serveur 320 reçoit alors ladite donnée DATA_INFO_310 au cours d’une étape 4100 du procédé 4000. Ladite étape 4100 est mise en œuvre par le module de réception MOD_RX_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Le procédé 4000 comporte alors une étape 4150 de transmission, de la part du terminal serveur 320 au terminal client 310, d’une donnée DATA_INFO_320 indiquant que le terminal serveur 320 est également apte à communiquer en exploitant au moins l’une des tranches réseau supportées par le réseau NET_5G. Ladite étape 4150 est mise en œuvre par le module de transmission MOD_TX_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Le terminal client 310 reçoit alors ladite donnée DATA_INFO_320 au cours d’une étape 4200 du procédé 4000. Ladite étape 4200 est mise en œuvre par le module de réception MOD_RX_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Il convient de noter que l’exécution desdites étapes 4050 et 4100 est optionnelle au sens de la présente invention. En effet, rien n’exclut d’envisager que les terminaux 310, 320 aient acquis la connaissance de leurs capacités respectives à communiquer via une ou plusieurs tranches supportées par le réseau NET_5G avant que le procédé 4000 ne soit exécuté. Le procédé 4000 comporte en outre une étape 4250 d’obtention, par le terminal client 310, d’une donnée DATA_PRIMARY désignant un terminal, dit « terminal primaire », parmi le terminal 310 et le terminal serveur 320 qui sont, comme mentionnés ci-avant, tous deux des terminaux candidats. Le rôle de « terminal primaire » joué par un terminal indique que c’est ce terminal qui est désigné pour imposer à l’autre terminal les éléments de connexion à utiliser pour générer des identifiants de connexion destinés à être utilisés lors d’échanges entre lesdits deux terminaux via des tranches supportées par le réseau NET_5G, comme décrit ci-après. Dans le présent mode de mise en œuvre, ladite obtention de l’étape 4250 correspond plus particulièrement à la génération, par le terminal client 310, de ladite donnée DATA_PRIMARY. En conséquence, ladite étape 4250 est mise en œuvre par un premier module de génération MOD_GEN_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Une fois générée, la donnée DATA_PRIMARY est transmise par le terminal client 310 au terminal serveur 320 au cours d’une étape 4300 du procédé 4000. Ladite étape 4300 est mise en œuvre par le module de transmission MOD_TX_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Aucune limitation n’est attachée à la manière dont ladite donnée DATA_PRIMARY est transmise au terminal serveur 320. Par exemple, ladite donnée DATA_PRIMARY peut être encapsulée dans une trame, par exemple une trame de contrôle ou une trame de données. En outre, la nature de ladite donnée DATA_PRIMARY n’est pas non plus une limitation de l’invention, cette dernière pouvant être un paramètre numérique ou du texte prédéterminé représentatif du fait que l’un parmi les deux terminaux 310, 320 est désigné en tant que terminal primaire. Par exemple, si la donnée DATA_PRIMARY est la valeur « 0x01 » (respectivement la valeur « 0x02 »), cela signifie que c’est le terminal serveur 320 (respectivement le terminal client 310) qui est désigné en tant que terminal maître. Le terminal serveur 320 reçoit alors ladite donnée DATA_PRIMARY au cours d’une étape 4350 du procédé 4000. Ladite étape 4350 est mise en œuvre par le module de réception MOD_RX_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Il est à noter que s’il est décrit ici que la donnée DATA_PRIMARY est générée par le terminal client 310 puis transmise au terminal serveur 320, rien n’exclut que ce soit le terminal serveur 320 qui génère la donnée DATA_PRIMARY et la transmette au terminal client 310. D’une manière générale, la désignation du terminal primaire peut être réalisée en fonction d’un critère de désignation donné. Etant donné que le terminal client 310 et le terminal serveur 320 sont tous deux des terminaux candidats dans le présent mode de mise en œuvre, ce critère de désignation peut par exemple correspondre à une règle (par ex. une règle imposée par une politique de service) consistant à imposer que le terminal primaire soit systématiquement le terminal client 310 ou le terminal serveur 320. Ainsi, même si un desdits terminaux candidats déclare vouloir jouer le rôle du terminal primaire, le résultat de la désignation peut en définitive dépendre de l’application d’une telle règle de sorte que cette déclaration demeure sans effet et que ce soit l’autre terminal candidat qui soit finalement désigné en tant que terminal primaire. En outre, bien qu’il soit décrit dans le présent mode de mise en œuvre que la donnée DATA_PRIMARY est générée et transmise après que les données DATA_INFO_310, DATA_INFO_320 aient été échangées entre les terminaux 310, 320, rien n’exclut d’envisager que ladite donnée DATA_PRIMARY soit transmise de manière conjointe à l’une desdites données DATA_INFO_210, DATA_INFO_320. Par exemple, lesdites données peuvent être incluses dans des champs respectifs d’un même message. De manière encore plus spécifique, si un tel message est utilisé pour transmettre lesdites données, et si le champ dédié à la donnée DATA_PRIMARY est vide, cela peut par exemple signifier qu’un terminal donné parmi les terminaux 310, 320 est désigné d’office en tant que terminal primaire. Cette désignation d’office relève par exemple d’une règle liée à une politique de service. Les premières alternatives desdits premier et deuxième procédés de communication visent plus particulièrement à ce que le terminal serveur 320 soit désigné en tant que terminal maître. En d’autres termes, c’est le terminal serveur 320 qui est désigné pour imposer au terminal client 310 l’utilisation d’identifiants de connexion conformes à certains éléments de connexion. Dès lors, le procédé 4000 comporte une étape 4400 de transmission, de la part du terminal client 310 au terminal serveur 320, d’une liste L_ACTIV comportant des identifiants et/ou des types des tranches actives (le type de la tranche pouvant également être désigné par un identifiant) auxquelles est connecté ledit terminal client 310. Ladite étape 4400 est mise en œuvre par le module de transmission MOD_TX_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Aucune limitation n’est attachée à la manière dont ladite liste L_ACTIV est transmise au terminal serveur 320. Par exemple, la liste L_ACTIV peut être encapsulée dans une trame, par exemple une trame de contrôle ou une trame de données. Dans le présent mode de mise en œuvre, et eu égard aux éléments décrits ci-avant, la liste L_ACTIV comporte les identifiants ID_TR_1, ID_TR_2 et ID_TR_3. En pratique, la transmission de cette liste L_ACTIV vise à informer explicitement le terminal serveur 320 des capacités du terminal client 310 pour communiquer via une ou plusieurs tranches supportées par le réseau NET_5G. Le terminal serveur 320 reçoit alors la liste L_ACTIV au cours d’une étape 4450 du procédé 4000. Une fois reçue, la liste L_ACTIV est mémorisée par le terminal serveur 320. Ladite étape 4450 est mise en œuvre par le module de réception MOD_RX_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Puis, le procédé 4000 comporte, pour le terminal serveur 320, une étape 4500 de sélection d’au moins un élément de connexion parmi les éléments de connexion qu’il possède. Ladite étape 4500 est mise en œuvre par un module de sélection MOD_SELECT_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Ladite sélection est réalisée parmi les éléments de connexion ELE_CX_1, ELE_CX_2 que le terminal serveur 320 possède et qui sont associés à au moins une des tranches actives TR_5G_1, TR_5G_2, TR_5G_3 identifiées dans la liste L_ACTIV qu’il a reçue lors de l’étape 4450. Dans le présent mode de mise en œuvre, on considère de manière nullement limitative que le terminal serveur 320 sélectionne les deux éléments de connexion ELE_CX_1, ELE_CX_2. Puis, le procédé 4000 comporte, pour le terminal serveur 320, une étape 4550 d’obtention d’au moins un identifiant de connexion en utilisant lesdits éléments de connexion ELE_CX_1, ELE_CX_2 sélectionnés lors de l’étape 4500. Ladite étape 4550 est mise en œuvre par un module d’obtention MOD_OBT_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Pour la suite de la description, on considère de manière nullement limitative que l’élément de connexion ELE_CX_1 est un motif, et que l’élément de connexion ELE_CX_2 est un ensemble d’identifiants de connexion donnés. On considère en outre que le terminal serveur 320 obtient un identifiant de connexion ID_CX_1_320 en utilisant l’élément de connexion ELE_CX_1(respectivement un identifiant de connexion ID_CX_2_320 en utilisant l’élément de connexion ELE_CX_2). Dans le présent mode de mise en œuvre, et conformément à ce qui a été décrit précédemment en relation avec la première phase : - l’obtention dudit identifiant de connexion ID_CX_1_320 comporte une génération dudit identifiant de connexion ID_CX_1_320 de sorte que celui-ci soit conforme au motif correspondant à l’élément de connexion ELE_CX_1, - l’obtention dudit identifiant de connexion ID_CX_2_320 comporte une sélection dudit identifiant de connexion ID_CX_2_320 parmi ledit ensemble correspondant à l’élément de connexion ELE_CX_2. Il importe toutefois de noter que l’obtention d’un identifiant de connexion conforme à un élément de connexion ne résulte pas nécessairement d’une génération (cas d’un motif) ou d’une sélection (cas d’un ensemble d’identifiants de connexion donnés). En effet, rien n’exclut que le terminal serveur 320 soit déjà en possession d’un identifiant de connexion associé à l’un des éléments de connexion ELE_CX_1, ELE_CX_2. Cela peut résulter par exemple d’une mise en œuvre précédente de l’invention, ou bien d’un enregistrement dans une mémoire du terminal serveur 320 lors de sa fabrication. Les identifiants de connexion ID_CX_1_320, ID_CX_2_320 ainsi construits sont destinés à être utilisés pour tout ou partie du trafic émis par le terminal serveur 320 et qui est habilité à être acheminé via les tranches TR_5G_1, TR_5G_2 associées aux éléments de connexion ELE_CX_1, ELE_CX_2. Il convient de noter que, dans le cas présent, deux tranches (i.e. les tranches TR_5G_1 et TR_5G_2) peuvent être sollicitées pour une même communication (du fait de la sélection des éléments de connexion ELE_CX_1, ELE_CX_2 par le terminal serveur 320). Toutefois, dans sa plus grande généralité, l’invention n’exclut pas de pouvoir envisager un nombre différent de tranches sollicitées, ce nombre pouvant être supérieur ou inférieur à 2 (par ex. dans l’étape 4500, le terminal serveur 320 peut sélectionner le seul élément de connexion ELE_CX_1 ou ELE_CX_2). Ce nombre dépend typiquement de la fonction applicative que l’on souhaite exploiter. A titre d’exemple, une connexion QUIC peut comporter une pluralité de « flux » ("streams" en anglais). Dès lors, une fonction applicative reposant sur l’utilisation de différents médias (par ex. : vidéo, audio, texte) peut associer des flux différents pour chacun de ces médias. Ainsi, les messages d'une même communication établie via un réseau supportant des tranches réseau peuvent être acheminés via plusieurs tranches, chacune d’entre elles étant optimisée pour un usage spécifique. En complément ou en alternative, le nombre de tranches sollicitées peut également dépendre d’une logique d’optimisation de service. Par exemple, si deux tranches sont configurées pour l’acheminement de contenus spécifiques (par ex. vidéo) dans le cadre d’une fonction applicative, des règles peuvent être établies pour déterminer dans quelle mesure telle ou telle tranche doit être sollicitée. Par ailleurs, l’invention couvre également des configurations selon lesquelles plusieurs identifiants de connexion peuvent être utilisés pour une même tranche pendant la durée de vie d'une même communication, ces différents identifiants étant utilisés chacun à leur tour. Le procédé 4000 comporte également une étape 4600 de transmission, de la part du terminal serveur 320 au terminal client 310, des éléments de connexion ELE_CX_1, ELE_CX_2 sélectionnés par le terminal serveur 320 lors de l’étape 4500. Ladite étape 4600 est mise en œuvre par le module de transmission MOD_TX_320 équipant le terminal serveur 320, et fait partie de la première variante du deuxième procédé de communication. Il est à noter qu’outre les éléments de connexion ELE_CX_1, ELE_CX_2, le terminal serveur 320 peut transmettre au terminal client 310 d’autres données lors de l’étape 4600. Par exemple, des identifiants de tranches spécifiques peuvent également être transmis, notamment dans des modes de mises en œuvre où plusieurs « flux » tels que mentionnés ci-avant sont utilisés en même temps. Le terminal client 310 reçoit alors les éléments de connexion ELE_CX_1, ELE_CX_2 au cours d’une étape 4650 du procédé 4000. Ladite étape 4650 est mise en œuvre par le module de réception MOD_RX_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. De manière similaire à ce qui a été décrit ci-avant pour le terminal serveur 320, le procédé 4000 comporte, pour le terminal client 310, une étape 4700 d’obtention d’au moins un identifiant de connexion en utilisant lesdits éléments de connexion ELE_CX_1, ELE_CX_2 (puisqu’il s’agit des éléments de connexion sélectionnés, et donc imposés, par le terminal serveur pour communiquer de sorte à exploiter ladite fonction applicative). Ladite étape 4700 est mise en œuvre par un module d’obtention MOD_OBT_310 équipant le terminal client 310, et fait partie de la première variante du premier procédé de communication. Pour la suite de la description, on considère de manière nullement limitative le terminal client 310 obtient un identifiant de connexion ID_CX_1_310 en utilisant l’élément de connexion ELE_CX_1 (respectivement un identifiant de connexion ID_CX_2_310 en utilisant l’élément de connexion ELE_CX_2). En définitive, à l’issue de la troisième phase, les terminaux 310, 320 sont aptes à communiquer entre eux en utilisant les tranches actives TR_5G_1, TR_5G_2, associées à la fonction applicative. Cela est rendu possible grâce aux identifiants de connexion ID_CX_1_310, ID_CX_2_310 et ID_CX_1_320, ID_CX_2_320 respectivement obtenus par le terminal client 310 et le terminal serveur 320. Ces identifiants peuvent en effet être insérés dans des paquets de données que les terminaux 310, 320 souhaitent s’échanger via les tranches appropriées, la gestion du trafic de tels paquets de données étant mise en œuvre par les nœuds de périphérie du réseau NET_5G, dont notamment le nœud de périphérie 110, comme cela est détaillé ultérieurement. Outre les premières variantes desdits premier et deuxième procédés communication décrits ci-avant, l’invention couvre également d’autres variantes desdits premier et deuxième procédés de communication. Ainsi, selon une autre variante, le terminal client 310 et le terminal serveur 320 sont tous deux des terminaux candidats. Toutefois, à la différence de ce qui a été décrit pour le procédé 4000, c’est le terminal client 310 qui est désigné comme terminal primaire. En d’autres termes, c’est le terminal client 310 qui impose au terminal serveur 320 le ou les éléments de connexion à utiliser pour générer un ou plusieurs identifiants de connexion destinés à être utilisés lors d’échanges entre lesdits deux terminaux via des tranches supportées par le réseau NET_5G. On note que dans cette autre variante, et du fait que le terminal client 310 est le terminal primaire, celui-ci n’a pas besoin de transmettre au terminal serveur 320 la liste des tranches actives auxquelles ledit terminal client 310 est connecté. En d’autres termes, le terminal client 310 transmet au terminal serveur 320 au moins un élément de connexion parmi les éléments de connexion qu’il a en sa possession. Plus particulièrement, dans la mesure où le terminal client 310 souhaite exploiter ladite fonction applicative, il transmet au terminal serveur l’élément de connexion ELE_CX_1 et/ou l’élément de connexion ELE_CX_2. Une fois la transmission effectuée, chacun desdits terminaux 310, 320 obtient un ou plusieurs identifiants de connexion sur la base des éléments de connexion qui ont été transmis, conformément à des dispositions similaires à celles décrites ci-avant dans le cadre du procédé 4000. Par ailleurs, suivant encore une autre variante, seul un des terminaux parmi le terminal client 310 et le terminal serveur 320 peut être un terminal candidat (i.e. un seul desdits terminaux 310, 320 est en possession d’éléments de connexion lorsque la troisième phase est initialisée). Dès lors, ce terminal candidat est celui désigné comme étant le terminal primaire. La donnée relative à cette désignation est par exemple générée par le terminal candidat. Rien n’exclut cependant qu’elle soit générée par l’autre terminal qui n’est pas candidat. Quatrième phase La FIG. 9 représente schématiquement un système SYS_4 de communication selon un mode particulier de réalisation de l’invention. Il importe de noter que le réseau NET_5G représenté sur la FIG. 9 est celui résultant de l’exécution du procédé 1000 de la première phase. En d’autres termes, pour ce qui concerne cette quatrième phase, le réseau NET_5G est configuré de manière spécifique, c’est-à-dire de sorte que chaque tranche TR_5G_i est associée à un élément de connexion ELE_CX_i. Tel qu’illustré par la FIG. 9 , le système SYS_4 comporte le terminal client 310 et le terminal serveur 320 dont les configurations respectives résultent de l’exécution du procédé 4000 de la troisième phase. En d’autres termes, le terminal client 310 (respectivement le terminal serveur 320) est en possession des identifiants de connexion ID_CX_1_310, ID_CX_2_310 (respectivement des identifiants de connexion ID_CX_1_320, ID_CX_2_320). Bien qu’il soit supposé ici que les configurations respectives du terminal client 310 et du terminal serveur 320 résultent de l’exécution du procédé 4000 de la troisième phase, rien n’exclut bien entendu de supposer que ces configurations résultent de toute autre alternative de mise en œuvre de la troisième phase, comme décrit précédemment. Il est à noter que les dispositions selon lesquelles le terminal client 310 et le terminal serveur 320 ont fait l’objet d’une exécution d’un procédé conforme à la troisième phase ne sont pas limitatives de l’invention. En effet, rien n’exclut d’envisager que le terminal client 310 (respectivement le terminal serveur 320) ait acquis un ou plusieurs identifiants de connexion d’une autre manière. Par exemple, ce ou ces identifiants de connexion peuvent avoir été inscrits dans une mémoire du terminal client 310 (respectivement du terminal serveur 320) lors de sa fabrication. Le système SYS_4 comporte en outre le nœud de périphérie 110 qui a connaissance des associations entre éléments de connexion ELE_CX_i et les tranches TR_5G_i via la table TAB_1 du fait de l’exécution du procédé 1000 de la première phase. Comme évoqué ci-avant, la quatrième phase est relative à un échange de données utiles entre lesdits deux terminaux. Plus particulièrement, les deux terminaux 310, 320 communiquent entre eux en s’échangeant des paquets de données, ces paquets de données transitant via une ou plusieurs tranches réseau supportées par le réseau NET_5G dans le cadre de l’exploitation de la fonction applicative attachée à l’offre de service souscrite par l’utilisateur dudit terminal client 310. Cet échange a donc lieu après que les deux terminaux aient établi entre eux ladite communication de sorte à obtenir leurs identifiants de connexion, conformément à ce qui a été décrit ci-avant dans le cadre de la troisième phase. Afin que ladite quatrième phase puisse être mise en œuvre, la mémoire morte 113 du nœud de périphérie 110 stocke, outre le programme d’ordinateur PROG_116, un autre programme PROG_117 conforme à l’invention, comportant des instructions pour l’exécution d’étapes d’un troisième procédé de communication selon l’invention. Le programme PROG_117 définit des modules fonctionnels du nœud de périphérie 110, qui s’appuient ou commandent les éléments matériels 111 à 115 du nœud de périphérie 110, et qui sont décrits plus en détails ci-après en référence à différents modes de mise en œuvre. De plus, les moyens de communication 115 permettent au nœud de périphérie 110 d’échanger des données avec les terminaux 310, 320 selon toutes caractéristiques techniques envisageables par la personne du métier, comme par exemple celles déjà décrites ci-avant. La FIG. 10 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un cinquième procédé général 5000 mis en œuvre par le système SYS_4. Ledit procédé 5000 englobe le troisième procédé de communication selon l’invention mis en œuvre par le nœud de périphérie 110, ainsi que des procédés de communication respectivement mis en œuvre par les terminaux 310, 320 et dont l’exécution s’effectue donc après que les premier et deuxième procédés de communication décrits dans le cadre de la troisième phase aient été eux-mêmes exécutés. Le procédé 5000 comporte tout d’abord une étape 5100 d’émission, par le terminal serveur 320, d’un paquet de données P_DATA_320 à destination du terminal client 310. Ladite étape 5100 est mise en œuvre par le module de transmission MOD_TX_320 équipant le terminal serveur 320, et fait partie du procédé de communication mis en œuvre par le terminal serveur 320 dans le cadre de la quatrième phase. Pour la suite de la description, on considère de manière nullement limitative que le paquet de données P_DATA_320 comporte l’identifiant ID_CX_1_320 obtenu par le terminal serveur 320 lors de la troisième phase (et donc généré au moyen de l’élément de connexion ELE_CX_1 lors de la troisième phase). Bien entendu, rien n’exclut que ce soit l’autre identifiant ID_CX_2_320 qui soit inséré dans le paquet de données P_DATA_320. Par ailleurs, on note que, dans la présente mise en œuvre, c’est le terminal serveur 320 qui émet un paquet de données à destination du terminal client 310. Pour cette raison, le terminal serveur 320 (respectivement le terminal client 310) peut encore être qualifié de « terminal émetteur » (respectivement de « terminal récepteur »). Ces dispositions ne sont toutefois pas limitatives de l’invention, et rien n’exclut bien entendu d’envisager que ce soit le terminal client 310 qui émet un paquet de données à destination du terminal serveur 320 (auquel cas les rôles de « terminal émetteur » et de « terminal récepteur » sont bien entendu inversés). Le nœud de périphérie 110 reçoit le paquet de données P_DATA_320 au cours d’une étape 5200 du procédé 5000. Ladite étape 5200 est mise en œuvre par le module de réception MOD_RX_110 équipant le nœud de périphérie 110, et fait partie du troisième procédé de communication. Le procédé 5000 comporte alors une étape 5300 d’évaluation, par le nœud de périphérie 110, d’un critère de conformité CRIT_CONF. Ladite étape 5300 est mise en œuvre par un module d’évaluation MOD_EVAL_110 équipant le nœud de périphérie 110, et fait partie du troisième procédé de communication. L’évaluation dudit critère de conformité CRIT_CONF est une étape permettant de déterminer dans quelle mesure telle ou telle tranche du réseau NET_5G va être utilisée pour acheminer le paquet de données P_DATA_320 vers le terminal client 310, comme cela est détaillé ultérieurement. Le critère de conformité CRIT_CONF est évalué en fonction au moins de l’identifiant de connexion ID_CX_1_320 contenu dans le paquet de données P_DATA_320. Plus particulièrement, dans le présent mode de mise en œuvre, le paquet de données P_DATA_320 comporte également un identifiant de connexion associé au terminal client 310. A titre illustratif, et pour la suite de la description, on considère que le paquet de données P_DATA_320 comporte également l’identifiant de connexion ID_CX_2_310. Le fait que le paquet de données P_DATA_320 comporte deux identifiants de connexion respectivement associés aux terminaux 310, 320 peut par exemple résulter d’une procédure d’échange d’identifiants de connexion ayant été mise en œuvre préalablement au procédé 5000. En outre, dans le présent mode de mise en œuvre, l’évaluation du critère de conformité CRIT_CONF comporte une comparaison des valeurs de chaque premier bit appartenant respectivement aux identifiants ID_CX_1_320 et ID_CX_2_310 contenus dans le paquet de données P_DATA_320. Il est alors considéré que le critère de conformité CRIT_CONF est satisfait si les valeurs desdits premiers bits sont identiques. Par exemple, supposons que l’identifiant de connexion ID_CX_1_320 (respectivement l’identifiant de connexion ID_CX_2_310) consiste en la suite de bits suivante : 1110111111 (respectivement 1110100001). Le critère de conformité est donc satisfait (même premier bit égal à 1). Par contre, si par exemple l’identifiant de connexion ID_CX_2_310 consiste en la suite suivante : 0110100001, le critère de conformité CRIT_CONF n’est pas satisfait. Il est à noter que le fait de considérer une comparaison des valeurs de chaque premier bit appartenant respectivement aux identifiants ID_CX_1_320 et ID_CX_2_310 ne constitue pas une limitation de l’invention. En particulier, rien n’exclut de comparer plusieurs bits appartenant à chacun de ces identifiants et/ou de comparer des bits occupant d’autres positions au sein de la suite de bits formant lesdits identifiants. Une fois l’évaluation du critère de conformité CRIT_CONF effectuée, le paquet de données P_DATA_320 peut être acheminé vers le terminal client 310 en utilisant une tranche du réseau NET_5G, l’identité de ladite tranche étant dépendante du résultat de l’étape d’évaluation 5300. Pour la suite de la description, on considère de manière nullement limitative que le critère de conformité CRIT_CONF est satisfait. On reprend en outre ici les éléments introduits à titre d’exemple lors de la description de la troisième phase et selon lesquels le terminal client 310 est connecté aux tranches TR_5G_1, TR_5G_2, TR_5G_3 qui sont ainsi qualifiées de tranches « actives », et que les tranches effectivement associées à la fonction applicative destinées à être utilisées sont les tranches TR_5G_1 et TR_5G_2. Le procédé 5000 comporte alors une étape 5400 de détermination, par le nœud de périphérie 110, de l’élément de connexion, dit « élément de connexion utile », associé à l’identifiant de connexion ID_CX_1_320 associé au terminal émetteur (i.e. au terminal serveur 320) contenu dans le paquet de données P_DATA_320. Ladite étape 5400 est mise en œuvre par un module de détermination MOD_DET_110 équipant le nœud de périphérie 110, et fait partie du troisième procédé de communication. Pour rappel, ledit identifiant ID_CX_1_320 a été généré à partir de l’élément de connexion ELE_CX_1 qui correspond, dans le présent mode de mise en œuvre, à un motif. Par exemple, ledit motif peut correspondre à une pluralité de bits consécutifs au sein de la suite de bits formant l’identifiant de connexion ID_CX_1_320. A titre illustratif, en reprenant l’exemple précédent dans lequel l’identifiant de connexion ID_CX_1_320 consiste en la suite de bits suivante : 1110111111, ledit motif peut correspondre au quatre bits consécutifs au premier bit de ladite suite (i.e. le motif correspond à la séquence de bits 1101). Bien entendu, le fait de considérer quatre bits consécutifs n’est pas limitatif de l’invention. De manière plus générale, le nœud de périphérie 110 est configuré pour identifier l’élément de connexion associé à l’identifiant de connexion du terminal émetteur contenu dans le paquet de données indépendamment du fait que ledit élément de connexion soit un motif ou un ensemble d’identifiants donnés. Cela est possible du fait de l’exécution de la première phase, et plus particulièrement de la mise en œuvre du procédé de réception par ledit nœud 110. Par la suite, et dans la mesure où la tranche TR_5G_1 associée à l’élément de connexion ELE_CX_1 est une tranche active, le procédé 5000 comporte alors une étape 5500 d’acheminement, par le nœud de périphérie 110, du paquet de données P_DATA_320 vers le terminal client 310 en utilisant ladite tranche TR_5G_1. Ladite étape 5500 est mise en œuvre par un module de transmission MOD_TX_110 équipant le nœud de périphérie 110, et fait partie du troisième procédé de communication. Finalement, le terminal client 310 reçoit le paquet de données P_DATA_320 au cours d’une étape 5600 du procédé 5000. Ladite étape 5600 est mise en œuvre par le module de réception MOD_RX_310 équipant le terminal client 310, et fait partie du procédé de communication mis en œuvre par le terminal client 310 dans le cadre de la quatrième phase. Il est à noter que le procédé 5000 n’est pas limité par le fait que le critère de conformité CRIT_CONF est satisfait et que la tranche associée à l’élément de connexion déterminé à partir de l’identifiant contenu dans le paquet de données ainsi qu’associé au terminal émetteur est une tranche active. Ainsi, si le critère de conformité CRIT_CONF est satisfait et que la tranche en question n’est pas une tranche active, l’acheminement du paquet de données peut être réalisé en utilisant une tranche désignée par défaut (par ex. la tranche TR_5G_3 est désignée pour être utilisée par défaut). De manière similaire, si le critère de conformité CRIT_CONF n’est pas satisfait (par exemple parce que les valeurs des premiers bits des identifiants contenus dans le paquet de données différent), l’acheminement du paquet de données peut être réalisé en utilisant une tranche désignée par défaut (par ex. la tranche TR_5G_3 est désignée pour être utilisée par défaut). Alternativement, l’acheminement du paquet de données peut être réalisé sans utiliser l’une quelconque des tranches réseau. Par ailleurs, le procédé 5000 n’est pas non plus limité par le fait d’évaluer un critère de conformité entre identifiants de connexion. Par exemple, il peut être envisagé de déterminer directement (i.e. sans réaliser de test de conformité) l’élément de connexion associé à l’un des identifiants contenu dans le paquet de données, puis ensuite d’acheminer le paquet données selon des dispositions similaires à celles décrites ci-avant, à savoir utiliser la tranche associée audit élément de connexion si ladite tranche est active ou bien utiliser sinon une tranche par défaut. Procéder de la sorte permet de faire en sorte que l’acheminement du trafic repose systématiquement sur un élément de connexion obtenu par le terminal émetteur ou le terminal récepteur, ce qui correspond à la mise en place d’un critère de confiance envers ce dernier. Procédé de configuration d’un réseau supportant N tranches réseau, N étant un nombre entier supérieur ou égal à 1, ledit procédé comportant des étapes de : - génération (1100) de M éléments de connexion, M étant un nombre entier supérieur ou égal à 1, chaque élément de connexion étant configuré pour permettre l’obtention d’au moins un identifiant de connexion destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - association (1200) d’au moins un élément de connexion à au moins une tranche réseau en fonction d’un critère d’association donné, - transmission (1300) de données indiquant les associations entre éléments de connexion et tranches réseau à un ensemble E d’entités du réseau configurées pour participer à l’acheminement de paquets de données au sein du réseau. Procédé selon la revendication 1, dans lequel au moins un élément de connexion est un motif configuré pour imposer, parmi la suite de bits formant un identifiant de connexion, la valeur d’au moins un bit ayant une position donnée au sein de ladite suite de bits. Procédé selon l’une quelconque des revendications 1 à 2, dans lequel l’ensemble E d’entités comporte au moins l’un parmi : - un serveur d’allocation d’adresses réseau, - un serveur d’allocation de préfixes réseau, - un routeur configuré pour activer une fonction de délégation de préfixes réseau, - un nœud de périphérie du réseau, comme par exemple un routeur d’accès ou un routeur ASBR. Procédé selon l’une quelconque des revendications 1 à 3, dans lequel un élément ou un identifiant de connexion est un identifiant de type « Connection ID » (« CID ») utilisé par le protocole QUIC ou le protocole DTLS. Procédé de réception mis en œuvre par une entité d’un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’une quelconque des revendications 1 à 4, ledit procédé de réception comportant une étape de réception (1500) desdites données indiquant les associations entre éléments de connexion et tranches réseau. Procédé de traitement de données mis en œuvre par : - un terminal connecté à au moins un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’une quelconque des revendications 1 à 4, ou - un équipement dudit au moins un réseau supportant des tranches réseau, ledit procédé de traitement de données comportant, s’il est mis en œuvre par ledit terminal, des étapes de : - transmission (2100), à ladite entité, d’une requête d’obtention d’au moins un élément de connexion, - réception (2400), en provenance de ladite entité, d’une réponse à ladite requête, ladite réponse comportant au moins élément de connexion associé à au moins une tranche réseau supportée par le réseau, ou ledit procédé de traitement de données comportant, s’il est mis en œuvre par ladite entité, des étapes de : - réception (2200), en provenance dudit terminal, d’une requête d’obtention d’au moins un élément de connexion, - transmission (2300) audit terminal d’une réponse à ladite requête, ladite réponse comportant au moins élément de connexion associé à au moins une tranche réseau supportée par le réseau. Procédé selon la revendication 6, dans lequel la requête d’obtention comporte au moins un paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter, la réponse à la requête comportant au moins un élément de connexion associé à une tranche elle-même associée audit identifiant ou à une tranche dudit type. Procédé selon l’une quelconque des revendications 6 à 7, dans lequel, en l’absence dans la requête d’obtention d’un paramètre correspondant à un identifiant de tranche ou à un type de tranche à laquelle le terminal est autorisé à se connecter, la réponse à la requête comporte au moins un élément de connexion associé à au moins une tranche à laquelle le terminal est autorisé à se connecter. Procédé de communication mis en œuvre par un premier terminal, dit « terminal client », pour échanger des données avec un deuxième terminal, dit « terminal serveur », le terminal client étant connecté à un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’une quelconque des revendications 1 à 4, et au moins un terminal, dit « terminal candidat », parmi ledit terminal client et ledit terminal serveur étant en possession d’au moins un élément de connexion dudit réseau, ledit procédé comportant des étapes de : - obtention (4250) d’une donnée désignant un terminal, dit « terminal primaire », parmi ledit au moins un terminal candidat, - si le terminal client est le terminal primaire : transmission, au terminal serveur, d’au moins un élément de connexion, dit « premier élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal client possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un premier élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - si le terminal serveur est le terminal primaire : réception (4650), en provenance du terminal serveur, d’au moins un élément de connexion, dit « deuxième élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal serveur possède, obtention (4700) d’au moins un identifiant de connexion en utilisant ledit au moins un deuxième élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau. Procédé de communication mis en œuvre par un deuxième terminal, dit « terminal serveur », pour échanger des données avec un premier terminal, dit « terminal client », le terminal client étant connecté à un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’une quelconque des revendications 1 à 4, et au moins un terminal, dit « terminal candidat », parmi ledit terminal client et ledit terminal serveur étant en possession d’au moins un élément de connexion dudit réseau, ledit procédé comportant des étapes de : - obtention (4350) d’une donnée désignant un terminal, dit « terminal primaire », parmi ledit au moins un terminal candidat, - si le terminal client est le terminal primaire : réception, en provenance du terminal client, d’au moins un élément de connexion, dit « premier élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal client possède, obtention d’au moins un identifiant de connexion en utilisant ledit au moins un premier élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - si le deuxième terminal est le terminal primaire : transmission (4600), au terminal client, d’au moins un élément de connexion, dit « deuxième élément de connexion », parmi ledit au moins un élément de connexion que ledit terminal serveur possède, obtention (4550) d’au moins un identifiant de connexion en utilisant ledit au moins un deuxième élément de connexion, ledit au moins un identifiant de connexion étant destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau. Procédé selon l’une quelconque des revendications 9 à 10, dans lequel : - si le terminal client ou le terminal serveur est l’unique terminal candidat, ledit terminal candidat est désigné comme étant le terminal primaire, ou - si le terminal client et le terminal serveur sont tous deux des terminaux candidats, la donnée désignant le terminal primaire est générée par un desdits deux terminaux candidats en fonction d’un critère de désignation donné. Procédé selon l’une quelconque des revendications 9 à 11, dans lequel l’obtention d’au moins un identifiant de connexion en utilisant au moins un élément de connexion comporte : - si ledit au moins un élément de connexion comporte un motif, une génération d’au moins un identifiant de connexion conforme audit motif, et/ou - si ledit au moins un élément de connexion comporte un ensemble d’identifiants de connexion donnés, une sélection d’au moins un identifiant de connexion parmi ledit ensemble. Procédé selon l’une quelconque des revendications 9 à 12, dans lequel le terminal client est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », et : - si le terminal client est le terminal primaire, ledit au moins un premier élément de connexion est associé à une ou plusieurs tranches actives, ou - si le terminal serveur est le terminal primaire, une liste comportant des identifiants et/ou des types desdites tranches actives est transmise par le terminal client au terminal serveur, ledit au moins un deuxième élément de connexion étant sélectionné par le terminal serveur parmi ledit au moins un élément de connexion qu’il possède et de sorte à être associé à au moins une tranche active. Procédé de communication mis en œuvre par un nœud d’un réseau supportant des tranches réseau et configuré conformément à un procédé selon l’une quelconque des revendications 1 à 4, ledit nœud appartenant audit ensemble E, ledit procédé de communication comportant des étapes de : - réception (5200) d’un paquet de données en provenance d’un terminal, dit « terminal émetteur », ledit paquet de données étant destiné à un autre terminal, dit « terminal récepteur », et comportant au moins un identifiant de connexion destiné à être utilisé au niveau d’une couche transport et/ou application lors d’une communication via une ou plusieurs tranches réseau, - acheminement (5500) du paquet de données vers le terminal récepteur en fonction dudit au moins un identifiant de connexion. Procédé selon la revendication 14, dans lequel le paquet de données comporte un identifiant de connexion associé au terminal émetteur et un autre identifiant de connexion associé au terminal récepteur, ledit procédé comportant également des étapes de : - évaluation d’un critère de conformité en fonction desdits identifiants de connexion contenus dans le paquet de données, et - si le critère de conformité est satisfait : détermination de l’élément de connexion, dit « élément de connexion utile », associé à l’un desdits identifiants de connexion contenu dans le paquet de données, acheminement du paquet de données vers le terminal récepteur en utilisant une tranche réseau déterminée en fonction dudit élément de connexion utile, - si le critère de conformité n’est pas satisfait, acheminement du paquet de données vers le terminal récepteur en utilisant une tranche réseau désignée par défaut ou sans utiliser une tranche réseau supportée par le réseau. Procédé selon la revendication 15, dans lequel l’évaluation du critère de conformité comporte une comparaison des valeurs d’au moins deux bits appartenant respectivement aux identifiants de connexion du terminal émetteur et du terminal récepteur contenus dans le paquet de données, chacun desdits bits ayant une position donnée au sein de la suite de bits formant l’identifiant de connexion auquel il appartient, ledit critère de conformité étant satisfait si lesdites valeurs sont identiques. Procédé selon l’une quelconque des revendications 15 à 16, dans lequel le terminal récepteur est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », et dans lequel : - si le critère de conformité est satisfait et si la tranche associée audit élément de connexion utile est une tranche active, le paquet de données est acheminé en utilisant ladite tranche réseau associée audit élément de connexion utile, - si le critère de conformité est satisfait et si la tranche associée audit élément de connexion utile n’est pas une tranche active, le paquet de données est acheminé en utilisant une tranche réseau désignée par défaut. Procédé selon la revendication 14, dans lequel le terminal récepteur est connecté à un ensemble de tranches réseau supportées par le réseau, dites « tranches actives », ledit procédé comportant une étape de détermination de l’élément de connexion, dit « élément de connexion utile », associé à un identifiant de connexion parmi ledit au moins un identifiant de connexion contenu dans le paquet de données, et : - si la tranche associée audit élément de connexion utile est une tranche active, le paquet de données est acheminé en utilisant ladite tranche réseau associée audit élément de connexion utile, - si la tranche associée audit élément de connexion utile n’est pas une tranche active, le paquet de données est acheminé en utilisant une tranche réseau désignée par défaut. Dispositif de configuration (130) comportant des moyens configurés pour mettre en œuvre un procédé de configuration selon l’une quelconque des revendications 1 à 4. Entité (110, 120) d’un réseau supportant des tranches réseau comportant des moyens configurés pour mettre en œuvre : - un procédé de réception selon la revendication 5, et - un procédé de traitement de données selon l’une quelconque des revendications 6 à 8. Terminal (210, 310, 320) comportant des moyens configurés pour mettre en œuvre : - un procédé de traitement de données selon l’une quelconque des revendications 6 à 8, ainsi que : - un procédé de communication selon la revendication 9 ou selon l’une quelconque des revendications 11 à 13 au moins combinée à la revendication 9, ou - un procédé de communication selon la revendication 10 ou selon l’une quelconque des revendications 11 à 13 au moins combinée à la revendication 10. Nœud (110) d’un réseau supportant des tranches réseau et comportant des moyens configurés pour mettre en œuvre un procédé de communication selon l’une quelconque des revendications 14 à 18.