FR 3154270 A1 20250418 FR 2310967 A 20231012 Procédés de sélection de tranches réseau adaptées à un service, de gestion d’au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés Le procédé de sélection selon l’invention est mis en œuvre par un proxy se trouvant sur un chemin de données relatives à service échangées entre deux dispositifs lors d’une communication et comprend : la sélection (F60) pour chaque dispositif d’au moins une tranche réseau adaptée audit service et utilisable par ce dispositif lors de ladite communication ; si un dit dispositif n’est pas raccordé à au moins une dite tranche réseau sélectionnée ou susceptible d’être sélectionnée pour ce dispositif, l’envoi (F80) à au moins un contrôleur réseau gérant cette tranche réseau d’une demande de raccordement dudit dispositif à cette tranche réseau ; et l’envoi (F110) d’un message à chaque dispositif lui indiquant ladite au moins une tranche réseau sélectionnée utilisable par ce dispositif lors de la communication. Figure pour l’abrégé : Fig. 5. Procédés de sélection de tranches réseau adaptées à un service, de gestion d’au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un procédé et un système permettant d’optimiser la gestion des communications dans un environnement exploitant le concept de tranches réseau (ou « network slices » en anglais). Un tel concept est typiquement envisagé aujourd’hui dans les infrastructures mobiles 5G (5 ème génération) telles que définies par plusieurs standards 3GPP. Toutefois, il peut être utilisé également dans d’autres contextes, comme par exemple dans le contexte d’une infrastructure réseau partagée entre plusieurs opérateurs, d’une architecture réseau s’appuyant sur une virtualisation des fonctions réseaux (ou NFV pour « Network Functions Virtualization » en anglais), ou encore d’une architecture SD-WAN (pour « Software-Defined Wide Area Network » en anglais), etc. Une tranche réseau peut être définie comme un réseau privé virtuel (RPV ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure réseau fixe ou mobile ou les deux, et visant à assurer un ensemble de performances spécifiques. Elle peut être vue comme un réseau logique offrant une connectivité à ses utilisateurs et ayant ses propres caractéristiques en termes de capacité (bande passante), de qualité de service (latence, débit, temps de transit unidirectionnel, gigue (ou variation du délai inter-paquets, « inter-packet delay variation » en anglais, etc.) et de sécurité (par exemple, préservation de la confidentialité des informations transmises au sein d’un RPV moyennant l’utilisation de techniques de chiffrement). Le découpage en tranches réseau (ou « network slicing » en anglais) est en principe facilité par l’usage de techniques avancées de réseau défini par logiciel (ou SDN pour « Software-Defined Network » en anglais) et/ou de virtualisation de fonctions réseau (NFV), non décrites en détail ici. Il peut être appliqué à différents niveaux d’un réseau ; par exemple, pour un réseau 5G, au niveau du réseau d’accès radio pour une allocation dynamique des ressources radio, au niveau des ressources de calcul périphériques (ou MEC pour « Multi-access Edge Computing »), ou encore au niveau du cœur de réseau, notamment pour isoler le trafic et assurer la sécurité. Un tel découpage en tranches réseau permet avantageusement à diverses applications ou services réseau ayant des besoins spécifiques de coexister sur une même infrastructure réseau partagée, physique ou virtuelle. Chaque tranche réseau se voit ainsi allouer un ensemble de ressources (par ex. ressources de calcul, de stockage, ressources réseau, ou spectre de fréquences radio) pour satisfaire les besoins spécifiques d’un service ou d’un type de service auquel elle est associée. Le découpage en tranches réseau s’appuie à cet effet sur la définition d’un ensemble de politiques (qui peuvent prendre notamment la forme de règles de classification du trafic) et de mécanismes qui permettent d’identifier les flux de trafic associés à chaque tranche réseau. Ainsi, par exemple, une tranche réseau peut être optimisée pour des applications de jeu ou de réalité virtuelle sensibles à la latence. Une autre tranche réseau peut être optimisée pour des applications requérant une large bande passante telles que des applications de diffusion vidéo ou d’informatique en nuage (ou « cloud computing » en anglais). A titre illustratif, le standard 3GPP TS 23.501 intitulé « Technical Specification Group Services and System Aspects ; System architecture for the 5G System (5GS) ; Stage 2 (Release 17) », v17.9.0, juin 2023, au paragraphe 5.15.2.2, définit plusieurs types de tranches réseau permettant de gérer différentes catégories de services, et associés respectivement à des valeurs SST (pour « Service/Slice Type » en anglais). Ainsi, ce standard 3GPP considère : un type de tranches réseau dit eMBB pour « enhanced Mobile BroadBand » en anglais (« service mobile large bande amélioré » en français), correspondant à une valeur SST=1 : ce type de tranches réseau est adapté par exemple pour des services s’appuyant sur des débits de données très élevés permettant de proposer de nouvelles expériences aux utilisateurs (par ex. diffusion vidéo Haute Définition (HD)) ; un type de tranches réseau dit URLLC pour « Ultra Reliable Low Latency Communications » en anglais (« communication ultra fiable et à faible latence » en français), correspondant à une valeur SST=2 : ce type de tranches réseau est adapté par exemple pour des services ayant des exigences strictes en matière de latence et de fiabilité des échanges de données (par ex. services de gestion à distance, robots industriels ou télé-chirurgie) ; un type de tranches réseau dit mIoT pour « massive Internet of Things » en anglais (déploiement massif de l’Internet des Objets en français), correspondant à une valeur SST=3 : ce type de tranches réseau est adapté par exemple pour des services ayant des exigences élevées en matière de densité de déploiement (par ex. ville connectée, agriculture connectée) ; un type de tranches réseau dit V2X pour « Vehicular to Everything» en anglais (« véhicule vers tout » en français), correspondant à une valeur SST=4 : ce type de tranches réseau est adapté par exemple pour des services de communication impliquant des véhicules (par ex. service d’aide à la conduite, service de conduite autonome ou service de gestion du trafic routier) ; et un type de tranches réseau dit HMTC pour « High performance Machine Type Communications » en anglais (« communications de type machine à haute performance » en français), correspondant à une valeur SST=5 : ce type de tranches réseau est adapté par exemple pour des services ayant également des exigences élevées en termes de densité de déploiement, de faible latence et de débits de transmission élevés. Chacun de ces types est associé à un ensemble de caractéristiques documentées par les standards 3GPP. Ceci n’est qu’un exemple illustratif et d’autres types de tranches réseau, de même que d’autres indicateurs de types de tranches réseau que des valeurs SST peuvent être envisagés. Ainsi, le choix de concevoir et de déployer un type de tranche particulier est conditionné par la nature du trafic caractéristique des applications utilisées ou des services souscrits par les utilisateurs du réseau. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou réalité virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données, de sorte qu’il est un client naturel pour une tranche de type URLLC. Il convient de noter que les standards 3GPP actuels permettent à un équipement utilisateur (ou UE pour « User Equipment » en anglais) d’un réseau 5G de se connecter simultanément à 8 tranches réseau et donc d’accéder simultanément à autant de services requérant des besoins de connectivité distincts. Comme évoqué précédemment, le routage du trafic associé à un UE vers telle ou telle tranche réseau autorisée pour l’UE s’appuie sur des règles de classification du trafic, appliquées au niveau de l’UE mais également du réseau. Dans l’exemple d’un réseau 5G, ces règles de classification du trafic, aussi connues sous le nom de règles URSP (pour « UE Route Selection Policy » en anglais) sont transmises à l’UE au niveau du plan de contrôle par la fonction de contrôle de politiques (ou PCF pour « Policy Control Function » en anglais) du réseau ou pré-configurées au niveau de l’UE. Les règles URSP indiquent pour un type de trafic donné, quelle(s) tranche(s) de réseau l’UE peut utiliser. Les règles de classification du trafic peuvent être extrêmement complexes en raison des différents niveaux de granularité envisagés pour l’ingénierie et le déploiement des tranches réseau (par ex. une tranche réseau déployée pour acheminer le trafic à destination du réseau Internet ou une tranche réseau dédiée déployée pour acheminer le trafic applicatif échangé entre deux UE donnés). En outre, l’édiction et l’application de telles règles de classification du trafic sont susceptibles d’évoluer dans le temps, parfois avec une fréquence élevée, avec la diversité des trafics et leur changement, la dynamicité des besoins de l’UE, l’apparition de nouveaux services, les critères de sélection des tranches réseau appliqués et/ou les modes d’usage des tranches réseau, etc. Il en résulte également une difficulté de configuration de telles règles et un risque d’erreurs. Il existe donc un besoin d’un mécanisme qui permet d’optimiser l’accès à un service par un dispositif client (UE ou autre tel qu’un routeur, une passerelle résidentielle (ou CPE pour « Customer Premises Equipment » en anglais), un décodeur TV, etc.) via une ou plusieurs tranches réseau qui ne présente pas ces inconvénients. L’invention répond notamment à ce besoin en proposant un procédé de sélection de tranches réseau adaptées à un service et destinées à être utilisées lors d’une communication entre deux dispositifs via au moins un réseau, ce procédé étant mis en œuvre par un « proxy » se trouvant sur un chemin de données relatives au service et échangées entre les dispositifs impliqués dans la communication. Le procédé de sélection comprend : une étape de sélection, en fonction d’une politique de sélection donnée, pour chaque dispositif, d’au moins une tranche réseau adaptée au service utilisable par ce dispositif lors de la communication ; si un dit dispositif n’est pas raccordé à au moins une dite tranche réseau sélectionnée ou susceptible d’être sélectionnée pour ce dispositif, une étape d’envoi à au moins un contrôleur réseau dudit au moins un réseau gérant ladite au moins une tranche réseau d’une demande de raccordement du dispositif à ladite au moins une tranche réseau ; et une étape d’envoi d’un message à chaque dispositif lui indiquant ladite au moins une tranche réseau sélectionnée pour ce dispositif utilisable par ledit dispositif lors de la communication. Corrélativement, l’invention vise un proxy se trouvant sur un chemin de données relatives à un service et échangées via au moins un réseau lors d’une communication entre deux dispositifs impliqués dans une communication, ce proxy comprenant : un module de sélection, configuré pour sélectionner en fonction d’une politique de sélection donnée, pour chaque dispositif, au moins une tranche réseau adaptée au service utilisable par ce dispositif lors de la communication ; un module de communication, activé si un dit dispositif n’est pas raccordé à au moins une dite tranche réseau sélectionnée ou susceptible d’être sélectionnée pour ce dispositif, ce module de communication étant configuré pour envoyer à au moins un contrôleur réseau dudit au moins un réseau gérant ladite au moins une tranche réseau une demande de raccordement de ce dispositif à ladite au moins une tranche réseau ; et un module d’envoi, configuré pour envoyer un message à chaque dispositif lui indiquant ladite au moins une tranche réseau sélectionnée pour ce dispositif utilisable par ledit dispositif lors de la communication. Par « au moins une tranche réseau utilisable lors de la communication », on entend que le dispositif doit utiliser l’une au moins des tranches réseau indiquées par le proxy durant la communication, dès lors qu’il a été informé de cette sélection (en d’autres termes, suite à la réception du message du proxy). Aucune limitation n’est attachée à la nature du service dans le cadre duquel sont échangées des données dans le contexte de l’invention ni au nombre de dispositifs « terminaux » impliqués dans une communication. Il peut s’agir de tout type d’offre proposée par un fournisseur de services s’appuyant sur l’orchestration d’un ensemble de ressources d’un ou plusieurs réseaux (ressources réseau, de calcul, de stockage, etc.), comme par exemple un service de voix sur IP, un service de télémédecine, un service de diffusion de vidéos HD, un service de conférence, etc. Par ailleurs, aucune hypothèse n’est faite quant à la nature de chaque dispositif impliqué dans la communication. Il peut s’agir d’un terminal, tel qu’un téléphone intelligent, une tablette numérique, un ordinateur portable, mais également un routeur, un CPE, un décodeur TV, etc. Il peut être mono-interface ou multi-interface (ou MIF pour « Multi-InterFace » en anglais), c’est-à-dire capable d’activer et d’exploiter simultanément plusieurs interfaces logiques liées à une ou plusieurs interfaces physiques de connexion, telles que par exemple une interface de connexion à un réseau fixe, une interface de connexion à un réseau mobile ou encore une interface de connexion à un réseau local sans fil ou WLAN (pour « Wireless Local Area Network » en anglais). Cette caractéristique MIF présente de nombreux avantages pour l’UE, comme la possibilité d’agréger la bande passante de différents réseaux, une meilleure disponibilité de l’accès au(x) réseau(x), une répartition du trafic sur plusieurs liens de communication, etc. Il convient toutefois de noter que cette caractéristique MIF est volatile, car la capacité d’un dispositif à utiliser plusieurs interfaces (et ainsi à agréger plusieurs liens de communication c’est-à-dire à communiquer en empruntant des chemins multiples) dépend de différents facteurs, comme de ses conditions de raccordement au(x) réseau(x), de sa localisation, etc. De même, les tranches réseau envisagées dans le contexte de l’invention peuvent être supportées par un ou plusieurs réseaux (on parle de tranches « multi-domaines » ou « stitched slices » en anglais), se situer à différents niveaux (par exemple au niveau d’un réseau d’accès, d’un réseau de collecte, du cœur de réseau, d’un réseau de transit ou d’un réseau de transport), être associées à d’autres tranches réseau, etc., et une même tranche réseau peut être utilisée pour transporter le trafic d’un ou plusieurs services. L’invention propose ainsi un mécanisme de sélection, par un proxy, de tranches réseau permettant d’optimiser, au regard de critères donnés (participant à la définition d’une « politique de sélection » au sens de l’invention), un service de bout-en-bout entre un dispositif émetteur et un dispositif récepteur. Il convient de noter qu’à cet effet, le procédé de sélection selon l’invention peut être mis en œuvre par un ou plusieurs proxies situés sur le chemin des données échangées dans le cadre du service entre le dispositif émetteur et le dispositif récepteur. En d’autres termes, les deux dispositifs envisagés dans le procédé de sélection peuvent être le dispositif émetteur et le dispositif récepteur, ou le dispositif émetteur et un proxy associé au dispositif récepteur, ou encore le dispositif récepteur et un proxy associé au dispositif émetteur. Le proxy selon l’invention dispose conformément à l’invention d’une visibilité sur les tranches réseau accessibles par les dispositifs « terminaux » en coupure de flux desquels il se trouve et a la capacité de communiquer avec un ou plusieurs contrôleurs réseau pour déclencher éventuellement (et si besoin négocier) le raccordement de ces dispositifs à d’autres tranches réseau si celles-ci s’avèrent pertinentes au regard de sa politique de sélection pour fournir le service de façon optimale aux dispositifs. Un tel raccordement peut être demandé par le proxy en amont de la sélection des tranches réseau pour les dispositifs (pour des tranches réseau susceptibles d’être sélectionnées par le proxy pour les dispositifs), ou après avoir sélectionné les tranches réseau (on peut alors se limiter à demander le raccordement des tranches réseau qui ont été sélectionnées et auxquelles ne sont pas déjà raccordés les dispositifs). Le proxy est par ce biais en mesure d’établir une correspondance entre un service et les tranches réseau permettant de fournir ce service de manière optimale, et est assisté à cette fin par le ou les réseaux supportant les tranches réseau en question. Le proxy se trouvant dans le plan des données échangées entre les deux dispositifs, il peut avantageusement sélectionner des tranches réseau différentes pour chacun des dispositifs, y compris des tranches réseau supportées par des réseaux différents : sa position dans le plan de données lui permet d’être en mesure de réaliser l’interconnexion entre de telles tranches réseau différentes, et marquer en conséquence les paquets de données transitant par lui ou modifier leurs entêtes pour qu’ils soient orientés convenablement vers les tranches réseau adéquates. La politique de sélection appliquée par le proxy peut avantageusement tenir compte, outre la qualité du service, de contraintes imposées par le fournisseur de service, ou par l’opérateur ou les opérateurs du ou des réseaux sur lesquels s’appuient les tranches réseau, de l’habilitation (autorisation) des dispositifs à accéder à une ou plusieurs tranches réseau, d’une complexité de mise en œuvre, etc. Par exemple, la politique de sélection applique au moins une règle parmi les règles suivantes : une première règle selon laquelle, lorsque les dispositifs sont raccordés à au moins une tranche réseau d’un même type (par exemple associée à une même valeur SST dans le contexte d’un réseau 5G conforme aux standards 3GPP) adaptée au service, ladite au moins une tranche réseau d’un même type est sélectionnée pour les dispositifs ; et/ou une deuxième règle selon laquelle au moins une tranche réseau sélectionnée pour au moins un dit dispositif est une tranche réseau à laquelle est déjà raccordé ce dispositif ; et/ou une troisième règle selon laquelle les tranches réseau sélectionnées pour les dispositifs optimisent une qualité du service. Bien entendu, la politique de sélection appliquée par le proxy peut comprendre d’autres règles en plus ou en remplacement de tout ou partie des règles mentionnées ci-avant. La première règle favorise la sélection de tranches réseau auxquelles sont déjà raccordés les dispositifs et qui sont compatibles entre elles, dès lors que ces tranches réseau sont adaptées au service. Ceci permet d’accélérer la fourniture du service et de limiter la complexité d’implémentation de l’invention. De plus, la présence du proxy et son implication dans l’établissement des communications permet de préserver un même niveau de service. La deuxième règle peut être pertinente lorsque l’un des dispositifs ne supporte pas la procédure proposée par l’invention. Cette procédure est appelée dans la suite de la demande « SLALOM » en référence à la possibilité qu’elle offre de « slalomer » entre les tranches réseau offertes par un ou plusieurs réseaux lors d’une communication entre deux dispositifs. La troisième règle permet avantageusement de choisir les tranches réseau qui optimisent la qualité du service relatif aux données échangées entre les dispositifs. A cet effet, différents éléments peuvent être pris en compte comme le type de service envisagé, les paramètres de qualité déterminants pour ce service (la latence, le débit, etc.), les garanties offertes par les tranches réseau « visibles » du proxy (c’est-à-dire qui peuvent être sélectionnées par celui-ci), etc. On note qu’une telle troisième règle peut, dans certains cas, être une instanciation de la première règle. L’invention offre donc une plus grande granularité dans le choix des tranches réseau pouvant être utilisées pour satisfaire les besoins d’un service, des tranches réseau différentes pouvant être utilisées sur différents segments de la communication, et sur un même segment de communication, sur des chemins multiples mis en œuvre sur ce segment (autrement dit, sur différentes « sous-connexions » ou « sous-sessions » (« subflow », en anglais) selon les protocoles considérés). Elle permet en outre de tenir compte des tranches réseau ou des types de tranche réseau disponibles pour les deux dispositifs impliqués dans la communication, c’est-à-dire qu’ils sont habilités à utiliser. Au contraire, dans l’état de la technique évoqué précédemment, un UE ne dispose que de la connaissance des tranches réseau qui lui sont autorisées par le réseau pour sélectionner la tranche réseau qu’il va utiliser pour accéder à un service. Il n’a pas de visibilité sur les tranches réseau disponibles pour le dispositif distant avec lequel il établit une communication pour accéder au service. Chaque dispositif (UE ou dispositif distant) n’a qu’une visibilité réduite sur les tranches réseau susceptibles de satisfaire les besoins d’un service auquel il accède, et ne peut utiliser que les tranches réseau qui lui sont communiquées par le réseau auquel il est connecté. Il n’a pas de visibilité non plus sur d’autres tranches disponibles au sein d’un réseau pour fournir le service, et encore moins sur celles qui sont accessibles par l’autre dispositif, de sorte que quand il choisit au regard des règles URSP qui lui sont communiquées une tranche réseau pour accéder à un service, c’est cette même tranche réseau qui est utilisée de bout-en-bout jusqu’au dispositif distant. Par ailleurs, conformément à l’invention, le proxy est impliqué dans l’accès au service : il sélectionne pour un service donné les tranches réseau à utiliser par les dispositifs lors de la communication et les informe de cette sélection. Il en résulte une configuration dynamique (ajout, suppression, etc.) des règles de classification de trafic appliquées par les dispositifs, dès lors qu’ils peuvent être en mesure d’utiliser de nouvelles tranches réseau auxquelles ils n’étaient pas initialement raccordés. L’invention permet ainsi aux dispositifs de découvrir de façon automatique et sécurisée des tranches réseau déployées réservées à (ou optimisées pour) l’usage d’un service donné. En outre, le proxy se trouvant sur les chemins des données relatives au service et échangées lors de la communication entre les dispositifs, on peut envisager de mettre en place au niveau du proxy un contrôle visant à s’assurer que les dispositifs lors de cette communication accèdent effectivement au service prétendu et utilisent les tranches de réseau qu’il a sélectionnées pour eux pour ce service. L’invention permet ainsi de se prémunir contre des procédures d’usurpation mises en œuvre par des applications malveillantes et visant à utiliser des privilèges non autorisés dans le réseau. Dans un mode particulier de réalisation, le procédé de sélection comprend une étape d’obtention en provenance d’au moins un dit dispositif, d’au moins une information représentative d’au moins une tranche réseau à laquelle est raccordé ce dispositif. Une telle information comprend par exemple au moins un élément parmi : un type de ladite tranche réseau ; un identifiant de ladite tranche réseau ; un identifiant de réseau auquel est rattachée ladite tranche réseau ; au moins un identifiant d’adresse IP (Internet Protocol) associée à ladite tranche réseau. Elle permet notamment au proxy d’appliquer les règles de sélection évoquées précédemment dans sa politique de sélection. En outre, dans un mode particulier de réalisation du procédé de sélection, l’étape d’envoi d’une demande de raccordement concerne une tranche réseau susceptible d’être sélectionnée pour ledit dispositif et est mise en œuvre avant l’étape de sélection. Ce mode de réalisation permet une utilisation plus rapide de la ou des tranches sélectionnées pour le dispositif à compter de sa/leur sélection et ainsi de réduire le délai d’accès au service. Ainsi, le raccordement à d’autres tranches réseau pour un dispositif peut être demandé par le proxy avant ou après la sélection des tranches réseau adaptées à un service pour ce dispositif. Ceci offre une flexibilité en matière d’implémentation de l’invention. Dans un mode particulier de réalisation, le procédé de sélection selon l’invention comprend en outre une étape d’envoi à au moins un dit dispositif d’au moins une information représentative d’au moins une tranche réseau à laquelle est raccordé le proxy. Ce mode de réalisation permet une découverte automatique par les dispositifs des proxies capables d’optimiser leurs communications de sorte à inclure ces « proxies » sur le chemin de ces communications. D’autres informations peuvent être acquises par les dispositifs, comme par exemple au moins un protocole de communication mis en œuvre par le proxy. Le dispositif peut ainsi aisément inclure sur le chemin de sa communication avec un autre dispositif un proxy raccordé à une tranche réseau à laquelle lui-même est raccordé ou qui est accessible via cette tranche réseau. L’annonce du protocole de communication peut en outre permettre au dispositif de choisir un proxy mettant en œuvre un protocole supportant des extensions permettant d’établir des communications via des chemins multiples, un proxy pouvant jouer le rôle de concentrateur de chemins multiples ce qui peut s’avérer avantageux quand l’un des dispositifs ne connaît pas les capacités à cet égard de l’autre dispositif, ou un proxy qui permet d’utiliser des fonctions de transport avancées sans que de telles fonctions soient effectivement supportées par tous les dispositifs impliqués dans une communication. Un tel protocole de communication est par exemple le protocole de transport TCP (Transmission Control Protocol) et son option multi-chemins MPTCP (pour « Multipath TCP »), le protocole de transport QUIC et son extension multi-chemins MPQUIC (pour « Multipath QUIC ») ou encore le protocole de transport DCCP (pour « Datagram Congestion Control Protocol ») et son extension multi-chemins MPDCCP (pour « Multipath DCCP »), ou encore le protocole de conversion « 0-RTT Convert Protocol ». En outre, les différentes informations échangées entre dispositifs et proxy dans le cadre de l’invention peuvent l’être via des extensions de ces protocoles définies à cet effet. Dans un mode particulier de réalisation, le procédé de sélection selon l’invention comprend, suite à l’étape d’envoi du message à chaque dispositif indiquant la ou les tranches de réseau sélectionnées pour lui, une étape de maintien du proxy sur au moins un dit chemin de données relatives audit service échangées entre lesdits dispositifs lors de ladite communication via au moins une tranche réseau sélectionnée pour lesdits dispositifs. En d’autres termes, le proxy reste impliqué dans la communication entre les deux dispositifs jusqu’à la fin de cette communication. Ce mode de réalisation présente un avantage lorsque tout ou partie des tranches réseau sélectionnées pour les deux dispositifs diffèrent, le proxy permettant de réaliser l’interconnexion entre des tranches réseau différentes utilisées par les deux dispositifs pour une même communication. Il convient de noter que ce mode de réalisation ne s’oppose pas à ce que les communications futures relatives au même service soient établies directement entre les deux dispositifs (sans l’intervention du proxy) via la ou les tranches sélectionnées par le proxy. Ceci permet de simplifier l’établissement des connexions entre les deux dispositifs. Dans un autre mode de réalisation, suite à l’étape d’envoi dudit message à chaque dispositif, une étape de retrait dudit proxy d’au moins un dit chemin de données relatives audit service échangées entre lesdits dispositifs lors de ladite communication via une même tranche réseau sélectionnée pour lesdits dispositifs. Comme il apparaît au regard de ce qui vient d’être décrit, l’invention s’appuie sur un proxy, mais également sur les dispositifs échangeant des données relatives à un service lors d’une communication, et sur le ou les contrôleurs réseau aptes à déclencher le raccordement d’un dispositif à une tranche réseau qu’ils gèrent sur demande du proxy. Ainsi, selon un deuxième aspect, l’invention vise un procédé de gestion d’au moins une tranche réseau par un contrôleur réseau d’un réseau, ledit procédé comprenant : une étape de réception, en provenance d’au moins un proxy se trouvant sur un chemin de données relatives à un service et échangées via au moins ledit réseau lors d’une communication entre deux dispositifs impliqués dans la communication, d’une demande de raccordement d’au moins un des dispositifs à au moins une tranche réseau gérée par ledit contrôleur réseau ; et une étape de déclenchement dudit raccordement. Corrélativement, l’invention vise également un contrôleur réseau d’un réseau comprenant : un module de réception, apte à recevoir en provenance d’au moins un proxy se trouvant sur un chemin de données relatives à un service et échangées via au moins ledit réseau lors d’une communication entre deux dispositifs impliqués dans la communication, une demande de raccordement d’au moins un desdits dispositifs à au moins une tranche réseau gérée par ledit contrôleur ; et un module de déclenchement du raccordement, configuré pour déclencher ledit raccordement. Selon un troisième aspect, l’invention vise un procédé de communication par un premier dispositif avec un proxy se trouvant sur un chemin de données relatives à un service et échangées via au moins un réseau avec un deuxième dispositif lors d’une communication, ledit procédé comprenant une étape de réception, en provenance dudit proxy, d’un message indiquant au premier dispositif au moins une tranche réseau adaptée au service utilisable par ledit premier dispositif lors de la communication et sélectionnée par le proxy en fonction d’une politique de sélection donnée. Corrélativement, l’invention concerne un dispositif de communication, dit premier dispositif de communication, comprenant : un module de réception, configuré pour recevoir en provenance d’un proxy se trouvant sur un chemin de données relatives à un service et échangées via au moins un réseau avec un deuxième dispositif de communication lors d’une communication impliquant le premier et le deuxième dispositif, un message indiquant audit dispositif de communication au moins une tranche réseau adaptée au service utilisable par ledit premier dispositif lors de la communication et sélectionnée par le proxy en fonction d’une politique de sélection donnée ; et un module de communication, configuré pour utiliser lors de la communication au moins une dite tranche réseau indiquée par le proxy. Le premier dispositif de communication selon l’invention et le contrôleur réseau, ainsi que les procédés de communication et de gestion mis en œuvre respectivement par ces équipements, bénéficient des mêmes avantages cités précédemment que le proxy et le procédé de sélection selon l’invention. Dans un mode particulier de réalisation, le procédé de communication comprend en outre, préalablement à l’étape de réception, une étape d’envoi via ledit proxy d’une demande d’établissement d’une connexion avec le deuxième dispositif pour la communication, la demande d’établissement comprenant au moins une information représentative d’au moins une tranche réseau à laquelle est raccordé le premier dispositif. Dans un mode particulier de réalisation, le procédé de communication comprend en outre : une étape de réception d’une demande d’établissement d’une connexion avec ledit deuxième dispositif pour ladite communication relayée par ledit proxy ; et une étape d’envoi audit proxy d’un message comprenant au moins une information représentative d’au moins une tranche réseau à laquelle est raccordée ledit premier dispositif. Ces modes de réalisation s’appuient sur des messages existants pour véhiculer diverses informations favorisant la mise en œuvre de l’invention. En outre, ils permettent d’impliquer le proxy dès la phase d’accès au service par les dispositifs. Dans un autre mode de réalisation, le procédé de communication comprend, préalablement à l’étape d’envoi, une étape de découverte d’au moins un proxy raccordé à au moins une tranche réseau à laquelle est raccordé le premier dispositif et mettant en œuvre au moins un protocole de communication utilisé lors de la communication, le proxy étant sélectionné par le premier dispositif parmi ledit au moins un proxy découvert lors de l’étape de découverte. Comme évoqué précédemment, ce mode de réalisation permet une découverte automatique par les dispositifs des proxies disponibles pour la mise en œuvre de l’invention. Dans un mode particulier de réalisation, les procédés de sélection, de gestion et de communication sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un proxy conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de sélection tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un contrôleur réseau conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de gestion tel que décrit ci-dessus. L’invention vise aussi un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif de communication conforme à l’invention et comportant des instructions adaptées à la mise en œuvre d’un procédé de communication tel que décrit ci-dessus. Chacun de ces programmes 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. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. 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, ou une mémoire flash. D'autre part, le support d'information 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 lien radio, par lien optique sans fil 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'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de sélection, de gestion, et de communication selon l’invention. Selon un quatrième aspect, l’invention vise également un système comprenant : au moins deux dispositifs de communication selon l’invention, échangeant des données relatives à un service lors d’une communication via au moins un réseau ; au moins un proxy selon l’invention situé sur un chemin de tout ou partie desdites données ; et au moins un contrôleur réseau dudit au moins un réseau selon l’invention. Les deux dispositifs de communication peuvent être le dispositif à l’origine de la communication et le dispositif distant avec lequel la communication est établie. En variante, l’un des dispositifs peut être un proxy conforme à l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de sélection, de gestion et de communication, le proxy, le contrôleur réseau, les dispositifs de communication et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. 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, dans son environnement, un système conforme à l’invention, dans un mode de réalisation ; FIG. 2 la FIG. 2 représente l’architecture matérielle d’un ordinateur sur laquelle s’appuient les différents éléments du système de la FIG. 1 (dispositifs de communication, contrôleurs réseau et proxies conformes à l’invention), dans un mode particulier de réalisation ; FIG. 3 les figures 3A et 3B représentent les principales étapes d’un procédé de communication selon l’invention, telles qu’elles sont mises en œuvre respectivement par un dispositif de communication UE1 et un dispositif de communication UE2 du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 4 la FIG. 4 représente les principales étapes d’un procédé de sélection selon l’invention, telles qu’elles sont mises en œuvre par un proxy du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 5 la FIG. 5 représente les principales étapes d’un procédé de gestion selon l’invention, telles qu’elles sont mises en œuvre par un contrôleur réseau du système de la FIG. 1 , dans un mode particulier de réalisation ; FIG. 6 les figures 6A, 6B et 6C illustrent des exemples de messages au format TLV (Type, Length, Value) permettant de véhiculer des informations échangées dans un mode particulier de réalisation de l’invention ; FIG. 7 les figures 7A et 7B illustrent des échanges d’information entre un dispositif de communication et un proxy du système de la FIG. 1 , durant une phase de découverte, dans un mode particulier de réalisation, dans lequel le protocole TCP est utilisé ; et FIG. 8 la FIG. 8 illustre des échanges d’information entre des dispositifs de communication et un proxy du système de la FIG. 1 , dans un mode particulier de réalisation, dans lequel le protocole TCP est utilisé ; et FIG. 9 la FIG. 9 représente, dans son environnement, un système conforme à l’invention, dans un autre mode de réalisation. Description de l’invention La FIG. 1 représente, dans son environnement, un système 1 conforme à l’invention, dans un mode de réalisation, dans lequel un ou plusieurs réseaux de communication NW1, NW2,…, NWN, N désignant un entier supérieur ou égal à 1, mettent en œuvre des tranches réseau pour la fourniture de divers services. Chaque réseau NWn, n=1,…,N supporte une pluralité de tranches réseau SLn1, SLn2,…, SLnK(n), K(n) désignant un entier supérieur à 1, et pouvant varier d’un réseau NWn à un autre. La pluralité de tranches réseau SLn1,…, SLnK(n) supportées par un réseau NWn, n=1,…,N est gérée par un ou plusieurs contrôleurs réseau ou NSC (pour « Network Slice Controller » en anglais), conformes à l’invention, et appartenant au système 1. Un contrôleur NSC d’un réseau NWn est typiquement une logique de calcul en charge de l’ingénierie et du déploiement de tranches réseau ; il s’agit par exemple d’un contrôleur SDN. Par souci de simplification ici, on envisage un unique contrôleur NSCn pour chaque réseau NWn, n=1,…,N, dans le système 1. Aucune limitation n’est attachée à la nature des réseaux de communication NW1,…, NWN. Il peut s’agir par exemple de réseaux mobiles 5G, de réseaux SD-WAN, de réseaux mettant en œuvre une architecture SDN ou NFV, etc., et qui utilisent, de façon connue en soi, des plans de contrôle et de données séparés. Un même réseau NWn, n=1,…,N, peut être segmenté en plusieurs réseaux distincts (on parle également de « segments de réseau »), qui composent autant de domaines (non représentés sur la FIG. 1 ). Par exemple, un réseau NWn de communication mobile 5G tel que défini par l’organisme 3GPP peut être composé d’un réseau d’accès radio (ou RAN pour « Radio Access Network » en anglais), d’un réseau cœur (ou CN pour « Core Network » en anglais) et d’un réseau de transport (ou TN pour « Transport Network » en anglais) assurant la connectivité au sein et entre le réseau cœur et le réseau d’accès radio. Chacun des domaines supporte des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine. Par exemple, une tranche déployée sur un réseau cœur mobile 5G fait appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G. Ainsi, une tranche réseau utilisée pour fournir un service via un réseau NWn, n=1,…,N peut s’étendre sur plusieurs domaines et être constituée de plusieurs tranches réseau « locales » déployées dans les différents domaines. La façon de concevoir et de déployer des tranches réseau pour offrir des services est connue en soi et n’est pas décrite en détail ici. A titre illustratif, le document de K.G. Szarkowicz intitulé “A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies”, draft-ietf-teas-5g-ns-ip-mpls, publié par l’IETF le 27 juin 2023, décrit une telle façon pour un réseau IP/MPLS (exemple de réseau de transport). Une telle tranche réseau s’étendant sur plusieurs domaines est dite « multi-domaines » (ou « stitched slice » ou encore « hierarchical slice » en anglais). Des interfaces de raccordement (ou « Attachment circuits » en anglais) sont prévues entre les tranches réseau locales et gérées en utilisant par exemple des mécanismes tels que décrits dans le document de M. Boucadair et al. intitulé « YANG Data Models for ‘Attachment Circuits’-as-a-Service (ACaas) », draft-boro-opsawg-teas-attachment-circuit-07, publié le 10 juillet 2023 par l’IETF. L’association entre les tranches réseau locales déployées dans les différents domaines et une tranche réseau multi-domaines est typiquement réalisé dans le plan de contrôle, à la périphérie de chaque domaine. Il convient de noter que les tranches réseau locales à chaque domaine ne s’appuient pas nécessairement sur les mêmes technologies. Par exemple : un premier domaine peut mettre en place des tunnels IPsec pour acheminer le trafic dans les tranches réseau déployées dans ce premier domaine ; un deuxième domaine peut utiliser une ingénierie de réseau privé virtuel de niveau réseau (L3VPN pour « Layer 3 VPN » en anglais) combiné avec des mécanismes d’ingénierie de trafic (ou TE pour « Traffic Engineering » en anglais) ; et un troisième domaine peut utiliser les ressources du routage par segments reposant sur le protocole IPv6 (SRv6 pour « Segment Routing IPv6 » en anglais) pour acheminer le trafic dans les tranches réseau déployées dans ce domaine. En outre, chaque tranche réseau (locale ou multi-domaines) peut impliquer une ou plusieurs fonctions service (ou « Service Functions » en anglais) aussi appelées fonctions réseau (ou « Network Functions » en anglais) dans le contexte 3GPP. De telles fonctions service/réseau sont par exemple des fonctions stations de base ou gNB (pour « gNodeB » en anglais), des fonctions du plan utilisateur ou UPF (pour « User Plane Function » en anglais), des fonctions de marquage, de classification et d’ordonnancement du trafic, etc. Une même fonction service/réseau peut être fournie par une ou plusieurs instances de service (ou « Service Fonction Instances » en anglais) ou instances de fonctions réseau. Des chaînes de service ou SFC (pour « Service Function Chains » en anglais) peuvent être mises en place afin de faciliter l’acheminement de trafics de différentes natures et présentant des profils différents pour les besoins de la réalisation (c’est-à-dire conception et du déploiement) d’une tranche réseau ou au sein d’une tranche réseau. Dans l’exemple de la FIG. 1 , on envisage deux fournisseurs de services reposant sur des tranches réseau (ou SSP pour « Service Slice Provider » en anglais), SSP1 et SSP2. Les tranches réseau en question (référencées par SSP1-SL1,… et SSP2-SL1,… sur la FIG. 1 ) sont déployées sur un ou plusieurs réseaux parmi les réseaux NW1,…, NWN. Aucune hypothèse n’est faite quant à la nature ni au nombre de services fournis par chacun d’entre eux, ni au nombre de tranches réseau ou aux réseaux sur lesquel(le)s s’appuient ces services, ni encore à la configuration des tranches réseau (mono ou multi-domaines). Conformément à l’invention, le système 1 comprend au moins deux dispositifs de communication UE1 et UE2, conformes à l’invention. Dans le mode de réalisation, ces deux dispositifs de communication UE1 et UE2 sont des équipements utilisateurs (ou UE) multi-interfaces, susceptibles d’être connectés à plusieurs réseaux d’accès comme par exemple un réseau WLAN et un réseau mobile cellulaire 5G. On suppose que les dispositifs de communication UE1 et UE2 utilisent le protocole de transport TCP et son option MPTCP pour la gestion de chemins multiples établis le cas échéant via leurs multiples interfaces. Les dispositifs de communication UE1 et UE2 peuvent être des téléphones intelligents (ou « smartphones » en anglais), des ordinateurs personnels, des serveurs, etc. Ils peuvent accéder, via les réseaux d’accès auxquels ils sont connectés, à un ou plusieurs fournisseurs SSP de services reposant sur des tranches réseau auprès desquels ils ont souscrit à un ou plusieurs services. Dans l’exemple envisagé dans la FIG. 1 , on suppose notamment que les dispositifs de communication UE1 et UE2 sont connectés au fournisseur de services SSP1 et ont souscrit au service S. Ces hypothèses ne sont pas toutefois limitatives en soi, et l’invention peut s’appliquer à d’autres dispositifs de communication, logiciels ou matériels, fixes ou mobiles, comme par exemple à une passerelle résidentielle ou CPE, à une instance de service, à un proxy, etc. Ces dispositifs de communication pouvant être mono ou multi-interfaces, utiliser d’autres protocoles de transport tels que QUIC et le cas échéant son extension MPQUIC, ou DCCP et le cas échéant son extension MPDCCP, etc. L’homme du métier n’aura aucune difficulté à transposer ce qui est décrit ci-après en référence à des segments TCP à d’autres types de paquets de données ou plus généralement à d’autres messages selon le protocole de transport envisagé. Dans le mode de réalisation, le système 1 comprend également au moins un proxy ou dispositif relais, P1, …, PM, M désignant un entier supérieur ou égal à 1, conformes à l’invention. Ces proxies P1,…,PM se trouvent typiquement dans les réseaux d’accès auxquels les dispositifs de communication UE1 et UE2 sont connectés ou sont joignables via de tels réseaux d’accès. En variante, ils peuvent être hébergés dans des infrastructures cloud publiques, privées ou hybrides, pouvant exploiter (ou pas) des ressources MEC (pour « Multi-access Edge Computing » en anglais) de réseaux de périphérie. Ils intègrent, dans l’exemple de la FIG. 1 exploitant des chemins multiples, des concentrateurs de chemins multiples et mettent en œuvre le protocole de conversion « 0-RTT TCP Convert Protocol » (aussi connu sous le nom de « MPTCP Plain Mode ») décrit dans le document RFC 8803 édité par l’IETF (juillet 2020). Dans la suite, on désigne ce protocole par souci de simplification par protocole Convert. Un tel concentrateur permet, de façon connue en soi, d’établir des communications simples ou à chemins multiples entre deux dispositifs de communication, y compris lorsque l’un et/ou l’autre de ces dispositifs de communication ne disposent pas de capacités MIF et/ou ne supportent pas de protocoles de transport à chemins multiples. L’utilisation du protocole Convert permet avantageusement l’établissement d’une connexion TCP qui permet d’échanger immédiatement des données utiles entre les deux dispositifs de communication via le concentrateur sans attendre le résultat de l’exécution du mécanisme « 3-way handshake » (3WHC) caractéristique du protocole TCP (c’est-à-dire que les dispositifs de communication peuvent échanger des données utiles dès l’échange d’un premier message visant à établir une connexion entre les dispositifs de communication) ; de façon connue en soi, dans le contexte du protocole TCP, l’établissement d’une connexion se fait au moyen du mécanisme 3WHC en trois étapes qui s’appuie sur l’échange de segments (c’est-à-dire de messages) TCP SYN, SYN+ACK et ACK. Il convient de noter que le protocole de conversion « 0-RTT Convert Protocol » est un protocole de conversion générique qui peut être appliqué pour d’autres protocoles de transport que le protocole TCP et son option MPTCP. L’utilisation de ce protocole est avantageuse ici car elle permet de véhiculer dans la charge utile des segments TCP des données applicatives et des données de contrôle. Bien entendu, ces différentes hypothèses ne sont pas limitatives en soi, et d’autres configurations du système 1 peuvent être envisagées. On peut envisager d’utiliser d’autres protocoles que le protocole Convert comme par exemple MASQUE (pour « Multiplexed Application Substrate over QUIC Encryption » en anglais) ou SOCKS, et/ou de véhiculer les données de contrôle relatives à l’invention dans un canal dédié. On peut également envisager un mode de réalisation dans lequel uniquement des communications simples (c’est-à-dire établies sur un seul chemin) sont mises en œuvre et/ou les proxies P1,…,PM n’agrègent pas plusieurs sous-connexions (chemins) d’un même dispositif ou ne les utilisent pas. Dans le mode de réalisation décrit ici, les dispositifs de communication UE1 et UE2, les proxies P1,…, PM et les contrôleurs réseau NSC1,…, NSCN ont chacun l’architecture matérielle d’un ordinateur 2 telle qu’illustrée à la FIG. 2 . Cette architecture matérielle comprend notamment un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication. La mémoire non volatile NVM constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré un programme conforme à l’invention. Ce programme, noté PROG-P lorsque l’architecture matérielle de l’ordinateur 2 est celle d’un proxy conforme à l’invention tel que les proxies P1,…, PM, est enregistré dans la mémoire non volatile NVM et comporte des instructions définissant les principales étapes d’un procédé de sélection selon l’invention tel qu’il est mis en œuvre par chaque proxy Pm, m=1,…,M. Il définit plus spécifiquement les modules fonctionnels de chacun des proxies Pm, m=1,…,M (représentés sur la FIG. 1 uniquement pour le proxy Pm0 par souci de simplification), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 2 cités précédemment. Ces modules fonctionnels comprennent, dans le mode de réalisation décrit ici, lorsque le proxy Pm se trouve sur le chemin de données relatives à un service « S » fourni par un fournisseur de services SSP reposant sur des tranches réseau (par exemple le fournisseur de service SSP1) et échangées lors d’une communication COM entre deux dispositifs de communication tels que les dispositifs de communication UE1 et UE2 : un module 3A de sélection, configuré pour sélectionner en fonction d’une politique POL de sélection donnée, pour chaque dispositif de communication au moins une tranche réseau adaptée au service « S » utilisable par ce dispositif de communication lors de la communication COM. Par « utilisable par le dispositif de communication », on entend que le dispositif de communication doit utiliser l’une au moins de ces tranches réseau pour la communication dès lors qu’il a été informé de la sélection du proxy. La politique POL de sélection est par exemple une politique locale stockée dans la mémoire NVM de l’ordinateur 2 ; un module 3B de communication, activé si un dit dispositif de communication n’est pas raccordé à au moins une dite tranche réseau adaptée au service « S » et sélectionnée ou destinée à être sélectionnée par le module 3A de sélection pour ce dispositif de communication. Le module 3B de communication est configuré pour envoyer à au moins un contrôleur réseau gérant ladite au moins une tranche réseau parmi les contrôleurs de réseau NCS1,…, NSCN, une demande de raccordement du dispositif de communication en question à ladite au moins une tranche réseau ; et un module 3C d’envoi, configuré pour envoyer un message à chaque dispositif de communication (UE1, UE2 dans l’exemple envisagé ici) lui indiquant la ou les tranches réseau qui ont été sélectionnées pour lui par le module 3A de sélection, et qui sont utilisables par le dispositif de communication lors de la communication COM. Dans le mode de réalisation décrit ici, le programme PROG-P définit également les modules fonctionnels suivants de chaque proxy Pm, m=1,…,M : un module 3D d’annonce, configuré pour annoncer à chaque dispositif de communication (UE1 et UE2 dans l’exemple envisagé ici) la ou les tranches réseau auxquelles il est raccordé. Le module 3D d’annonce peut également être configuré pour annoncer au moins un protocole de communication supporté par le proxy Pm et qui peut être utilisé pour véhiculer diverses informations exploitées pour la mise en œuvre de l’invention. Un tel protocole peut être notamment un protocole de transport donné, tel que, dans l’exemple envisagé ici, TCP et son option MPTCP, complété par de nouvelles extensions définies pour la mise en œuvre de l’invention, comme décrit plus en détail ultérieurement. D’autres protocoles peuvent en variante être envisagés, comme par exemple d’autres protocoles de transport tels que QUIC et le cas échéant son extension MPQUIC ou DCCP et le cas échéant son extension MPDCCP, ou des protocoles applicatifs tels qu’HTTP (pour « HyperText Transfer Protocol » en anglais) ou encore des protocoles mis en œuvre au niveau de la couche IP tels que GRE (pour « Generic Routing Encapsulation » en anglais) ; et un module 3E de réception, configuré pour recevoir des dispositifs de communication (et en particulier des dispositifs UE1 et UE2 dans l’exemple envisagé ici) des informations relatives aux tranches réseau auxquelles sont raccordés ces dispositifs de communication. Dans un autre mode de réalisation, le proxy Pm peut obtenir ces informations d’une autre entité, par exemple des contrôleurs NSC1,…, NSCN. Le fonctionnement des modules 3A à 3E d’un proxy Pm, m=1,…,M est décrit plus en détail ultérieurement en référence aux étapes du procédé de sélection. Lorsque l’architecture matérielle de l’ordinateur 2 est celle d’un dispositif de communication conforme à l’invention (dans l’exemple envisagé, du dispositif UEi avec i=1 ou 2), le programme d’ordinateur stocké dans la mémoire NVM est un programme PROG-UE, comportant des instructions définissant les principales étapes d’un procédé de communication selon l’invention tel qu’il est mis en œuvre par le dispositif de communication en question. Il définit plus spécifiquement les modules fonctionnels du dispositif de communication, qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 2 cités précédemment. Ces modules fonctionnels comprennent, dans le mode de réalisation décrit ici, pour le dispositif de communication considéré (par exemple UE1, respectivement UE2) : un module 4A de réception, configuré pour recevoir en provenance d’un proxy Pm conforme à l’invention se trouvant sur un chemin de tout ou partie des données relatives à un service (par exemple le service S fourni par le fournisseur de services SSP1) échangées lors d’une communication (par exemple la communication COM introduite précédemment) avec un autre dispositif de communication impliqué dans la communication (par exemple avec UE2, respectivement UE1), un message lui indiquant au moins une tranche réseau adaptée à ce service utilisable par le dispositif de communication lors de la communication et sélectionnée par le proxy pour ce dispositif de communication en fonction d’une politique de sélection donnée (par exemple ici la politique POL de sélection) ; et un module 4B de communication, configuré pour utiliser au moins une tranche réseau indiquée par le proxy lors de ladite communication. Dans le mode de réalisation décrit ici, le programme PROG-UE définit également un module 4C de découverte, configuré pour découvrir un ou des proxies conformes à l’invention qui supportent un protocole de communication donné (typiquement ici le protocole TCP et son option MPTCP pour la gestion des chemins multiples) et qui sont raccordés à une ou plusieurs tranches réseau auxquelles le dispositif de communication est lui-même raccordé ; et un module 4D d’envoi, configuré pour envoyer à l’un des proxies découverts, la ou les tranches réseau auxquelles le dispositif de communication est raccordé. Le fonctionnement des modules 3A à 3E d’un dispositif de communication selon l’invention est décrit plus en détail ultérieurement en référence aux étapes du procédé de communication. Lorsque l’architecture matérielle de l’ordinateur 2 est celle d’un contrôleur réseau conforme à l’invention, par exemple un contrôleur NSCn, n=1,…,N du réseau NWn dans l’exemple envisagé ici, le programme d’ordinateur stocké dans la mémoire NVM est un programme PROG-NSC, comportant des instructions définissant les principales étapes d’un procédé de gestion selon l’invention tel qu’il est mis en œuvre par le contrôleur réseau NSCn en question. Il définit plus spécifiquement les modules fonctionnels du contrôleur réseau NSCn (représentés uniquement sur la FIG. 1 pour le contrôleur NSC1 par souci de simplification), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 2 cités précédemment. Ces modules fonctionnels comprennent, dans le mode de réalisation décrit ici : un module 5A de réception, apte à recevoir en provenance d’un proxy conforme à l’invention (par exemple Pm) se trouvant sur un chemin de tout ou partie des données relatives à un service (par exemple le service S fourni par le fournisseur de services SSP1) et échangées lors d’une communication (par exemple la communication COM précitée) via le réseau NWn notamment, entre deux dispositifs de communication (par exemple UE1 et UE2) impliqués dans la communication, une demande de raccordement d’au moins un desdits dispositifs à au moins une tranche réseau gérée par le contrôleur NSCn ; et un module 5B de déclenchement, configuré pour déclencher le raccordement demandé. On note que le module 5B de déclenchement est configuré pour initier au moins ce raccordement ; il n’est néanmoins pas nécessairement le seul module actif pour raccorder effectivement la tranche réseau en question au dispositif de communication, et une ou plusieurs autres entités que le contrôleur réseau NSCn peuvent être impliquées pour réaliser ce raccordement à l’initiative du contrôleur réseau NSCn. Le fonctionnement des modules 5A et 5B d’un contrôleur NSCn, n=1,…,N est décrit plus en détail ultérieurement en référence aux étapes du procédé de gestion. Nous allons maintenant décrire, en référence aux figures 3 à 5 , les principales étapes des procédés mis en œuvre par chacun des dispositifs précités (dispositifs de communication, proxies et contrôleurs réseau) conformes à l’invention dans le mode de réalisation de l’invention. On se place à titre illustratif, pour décrire ce mode de réalisation, dans le contexte de la communication COM entre les dispositifs de communication UE1 et UE2, introduite précédemment, et au cours de laquelle des données applicatives relatives au service « S » fourni par le fournisseur de services SSP1 sont échangées entre les dispositifs de communication UE1 et UE2 impliqués dans la communication COM. Dans l’exemple envisagé ici où les dispositifs de communication UE1 et UE2 sont multi-interfaces et implémentent le protocole TCP et son option MPTCP, la communication COM peut s’appuyer sur une ou plusieurs connexions TCP « simples » entre les dispositifs de communication UE1 et UE2, empruntant un ou plusieurs chemins (ou liens) de communication. On parle d’agrégation de liens lorsque la communication COM résulte de l’agrégation de plusieurs connexions TCP simples ; la communication COM est alors dite à chemins multiples. On note que l’agrégation de liens peut en variante intervenir au niveau du concentrateur embarqué dans un proxy Pm, m=1,… M. Dans ce contexte, les figures 3A et 3B représentent les principales étapes du procédé de communication selon l’invention telles qu’elles sont mises en œuvre respectivement par les dispositifs de communication UE1 et UE2 ; la FIG. 4 représente les principales étapes du procédé de sélection tel qu’il est mis en œuvre par le ou les proxies du système 1 impliqués dans la communication COM (et qui se trouvent sur un chemin emprunté par les données applicatives échangées lors de la communication COM entre les dispositifs de communication UE1 et UE2), et la FIG. 5 représente les principales étapes du procédé de gestion mis en œuvre par le ou les contrôleurs réseau sollicités dans le contexte de l’invention. Comme évoqué précédemment, on désigne par « SLALOM », la procédure globale proposée par l’invention pour accéder de façon optimale à un service fourni par un fournisseur de services SSP. En référence aux figures 3A et 3B, chaque dispositif de communication UE1, UE2 négocie avec chaque fournisseur de services SSP avec lequel il est connecté une liste de tranches réseau qu’il est susceptible d’utiliser pour envoyer ou recevoir du trafic (c’est-à-dire des données applicatives) lorsqu’il accède à un service donné (étape E10). Dans l’exemple envisagé ici, les dispositifs UE1 et UE2 négocient notamment avec le fournisseur de services SSP1, une liste de tranches réseau qu’ils peuvent utiliser pour accéder aux services auxquels ils ont souscrit auprès du fournisseur de services SSP1, et en particulier au service S, et leur raccordement à ces tranches réseau. Cette liste identifie les tranches réseau en question ainsi que les types de ces tranches réseau. Par exemple, on considère ici les types de tranches réseau correspondant aux valeurs SST définies dans le document 3GPP TS 23.501 cité précédemment. On désigne par LIST1 et LIST2 les listes de tranches réseau obtenues respectivement par les dispositifs de communication UE1 et UE2. En variante, ces listes peuvent être communiquées aux dispositifs de communication UE1 et UE2 par les réseaux auprès desquels les dispositifs de communication UE1 et UE2 sont enregistrés. Selon une autre variante encore, si l’un de dispositifs de communication UE1 ou UE2 est un décodeur TV ou une « set-top box », une telle liste peut être obtenue auprès d’une plateforme gérant le décodeur ou la set-top-box, connectée au réseau, et exploitée par le fournisseur du service (par ex. un service IPTV ou VoD pour « Video on Demand »). Puis, dans le mode de réalisation décrit ici, chaque dispositif de communication UE1, UE2 découvre, par l’intermédiaire de son module 4C de découverte, les proxies conformes à l’invention se trouvant dans un réseau auquel il est connecté ou joignables via un tel réseau et raccordés à au moins une tranche réseau à laquelle est raccordé le dispositif de communication UE1, UE2 (étape E20). On suppose, dans le mode de réalisation décrit ici, que les proxies Pm, m=1,…,M sont configurés (ou déclarés) au niveau de chaque dispositif de communication UE1, UE2 explicitement par l’utilisateur du dispositif de communication UE1, UE2 ou par l’opérateur d’un réseau d’accès auquel le dispositif de communication UE1, UE2 est connecté. Chaque dispositif de communication UE1, UE2 obtient alors la liste des tranches réseau auxquelles est raccordé chaque proxy Pm, m=1,…,M en établissant une connexion avec lui, via une tranche réseau définie par défaut. A cet effet, dans le mode de réalisation décrit ici, le dispositif de communication UE1, UE2 (et plus particulièrement son module 4C de découverte) utilise pour communiquer avec le proxy Pm le protocole Convert complété par deux nouvelles extensions définies pour les besoins de l’invention permettant d’échanger entre les dispositifs de communication UE1, UE2 et le proxy Pm diverses informations (et plus particulièrement ici, diverses informations de contrôle, c’est-à-dire des données caractéristiques d’un échange qui se situe dans le plan de contrôle telles qu’une route empruntant une tranche réseau). Plus spécifiquement, une première extension, appelée ici PC-SC (pour « Proxy Control Slalom Capable » en anglais) permet de signaler la capacité d’un dispositif (dispositif de communication UE1, UE2 ou proxy Pm) à supporter la procédure SLALOM ; une deuxième extension, appelée ici PC-SS (pour « Proxy Control Slice Set » en anglais), permet de signaler les tranches réseau auxquelles le dispositif en question est raccordé. Conformément au protocole Convert, ces extensions prennent ici la forme de messages au format TLV. Dans la suite, les messages de contrôle Convert sont désignés indifféremment par « TLV », « message TLV », ou encore « message au format TLV ». A noter qu’un ou plusieurs messages TLV Convert peuvent être inclus dans un même message TLV. La figure 6A illustre un exemple de message TLV PC-SC. Dans l’exemple illustré par la figure 6A, le champ « Value » du TLV PC-SC est valorisé à « 0 », toutefois toute autre valeur peut être envisagée en variante. La présence du TLV PC-SC dans un message envoyé par le dispositif considéré est suffisant en soi pour indiquer la capacité du dispositif à supporter la procédure SLALOM. La figure 6B représente un exemple de message TLV PC-SS pouvant être inséré dans un message envoyé par un dispositif de communication UE1, UE2 à un proxy Pm (m=1,..,M) en vue d’obtenir des informations représentatives des tranches réseau auxquelles le proxy Pm est raccordé. La partie « Value » du message est alors valorisée à « 0 » (ou à toute autre valeur prédéfinie). La figure 6C représente un exemple de message TLV PC-SS pouvant être inséré dans un message envoyé en réponse au dispositif de communication par le proxy Pm (par son module 3D d’annonce par exemple), suite à la réception du TLV PC-SS de la figure 6B. Sur la figure 6C, la première ligne L1 fournit le type de TLV (PC-SS), sa longueur, et le nombre d’ensembles de tranches réseau fournies (« Slice Set Count ») dans le TLV PC-SS, chaque ensemble correspondant à un type de tranches réseau (« Slice Type »). La deuxième ligne L2 indique le début du premier ensemble, « SID Count » désignant le nombre de tranches réseau dans le premier ensemble, et « Slice Type » le type des tranches réseau du premier ensemble. Les lignes suivantes référencées par SID#1, …, SID#n, … fournissent les informations relatives aux tranches réseau du premier ensemble, identifiées respectivement par les identifiants de tranches réseau ou SID (pour « Slice IDentifier » en anglais). La ligne L3 indique le début d’un second ensemble de tranches réseau, dont les informations sont fournies dans les lignes succédant à la ligne L3, identifiées par les identifiants SID#1, …, SID#m, …. On peut bien entendu envisager d’autres protocoles que le protocole Convert pour véhiculer les informations illustrées par les figures 6A à 6C. Les figures 7A et 7B illustrent des exemples d’utilisation des messages au format TLV PC-SC et TLV PC-SS s’appuyant sur le protocole TCP. Dans ces exemples, les TLV PC-SC et PC-SS sont insérés dans la charge utile de segments TCP, et plus particulièrement de segments SYN, SYN+ACK et ACK échangés lors de l’établissement d’une connexion. Ce ne sont toutefois que des exemples illustratifs et non limitatifs en soi. Ainsi, sur la figure 7A, le TLV PC-SC est inséré dans un segment TCP SYN envoyé au proxy Pm par le dispositif de communication UE1, UE2 pour établir une connexion avec lui et lui signaler qu’il supporte la procédure SLALOM. Dans un mode de réalisation particulier, le dispositif de communication UE1, UE2 peut également signaler à cette occasion au proxy Pm, via l’option MPTCP MP_CAPABLE, qu’il supporte les communications à chemins multiples. Si le proxy Pm supporte également la procédure SLALOM, il répond au dispositif de communication UE1, UE2 en insérant un TLV PC-SC dans un segment TCP SYN+ACK. S’ensuit un segment ACK envoyé par le dispositif de communication UE1, UE2 au proxy Pm accusant réception du segment SYN+ACK (et du TLV PC-SC) envoyé par le proxy Pm. Si le proxy Pm ne supporte pas la procédure SLALOM, il n’insère pas de TLV PC-SC dans son segment SYN+ACK. Suite à l’établissement de la connexion entre le dispositif de communication UE1, UE2 et le proxy Pm, le dispositif de communication UE1,UE2 envoie au proxy Pm dans un segment TCP (noté généralement TCP-PKT) un TLV PC-SS tel que représenté par la figure 6B avec le champ Value valorisée à « 0 » (noté PC-SS(0) sur la figure 7A), demandant au proxy Pm les tranches réseau auxquelles il est raccordé. Le proxy Pm répond en insérant un TLV PC-SS tel que représenté à la figure 6C et identifiant les différentes tranches réseau auxquelles il est raccordé (noté PC-SS(Pm) sur la figure 7A), dans un segment TCP. Puis le dispositif UE1, UE2 clôture la connexion. La figure 7B illustre une variante de réalisation dans laquelle le proxy Pm envoie au dispositif de communication UE1, UE2 un TLV PC-SS identifiant les tranches réseau auxquelles il est raccordé (c’est-à-dire tel que représenté à la figure 6C), dans le segment SYN+ACK qu’il envoie au dispositif de communication UE1, UE2 lors de l’établissement de la connexion. La présence d’un tel TLV PC-SS indique implicitement que le proxy Pm supporte la procédure SLALOM. Puis le dispositif UE1, UE2 clôture la connexion. Dans une variante de réalisation, les messages PC-SC et PC-SS peuvent être échangés entre le module 4C de découverte du dispositif de communication UE1, UE2 et le module 3D d’annonce du proxy Pm dans d’autres segments TCP que les segments SYN et SYN+ACK, ou en utilisant un autre protocole de transport que TCP. Dans une autre variante encore, les informations de contrôle relatives au support de la procédure SLALOM et aux tranches réseau auxquelles le proxy Pm est raccordé peuvent être échangés entre chaque dispositif de communication UE1, UE2 et le proxy Pm par l’intermédiaire d’un canal de contrôle dédié. Dans un autre mode de réalisation, la découverte des proxies par les dispositifs de communication UE1, UE2 est réalisée en utilisant le mécanisme DNS SVCB décrit dans le document de B. Schwartz et al. édité par l’IETF, intitulé « Service binding and parameter specification via the DNS », draft-ietf-dnsop-svcb-https-12, 11 mars 2023, . Ce mécanisme définit un type d’enregistrement SVCB RR (pour « Resource Record SVBC » en anglais) au niveau des serveurs de noms utilisés lors de la résolution de noms (aussi appelés plus communément serveurs DNS pour « Domain Name System » en anglais) offrant la possibilité à un dispositif client d’obtenir, lorsqu’il interroge un serveur DNS, diverses informations permettant de faciliter l’accès à un service, et notamment des informations de configuration du protocole de transport à utiliser pour accéder à ce service (cette information est typiquement indiquée dans le paramètre de service « ALPN » d’un enregistrement SVBC RR). On peut envisager d’introduire un nouveau champ SvcParam dans l’enregistrement SCVB RR d’un proxy Pm, m=1,…,M, appelé par exemple ici, à titre illustratif, « slicehint », et défini pour les besoins de l’invention, dans lequel est annoncée la liste des tranches réseau auxquelles le proxy Pm est raccordé. Cette liste peut comprendre par exemple les identifiants et/ou les types de ces tranches réseau. Il convient de noter que les dispositifs de communication UE1 et UE2 peuvent découvrir lors de l’étape E20 les mêmes proxies ou des proxies différents. Par souci de simplification ici, on suppose que les mêmes proxies Pm, m=1,…,M sont découverts par les deux dispositifs de communication. Une fois les proxies Pm, m=1,…,M et les tranches réseau auxquels ils sont raccordés découverts par le dispositif de communication UE1, UE2, celui-ci (via par exemple son module 4C de découverte) mémorise les informations obtenues dans un cache, et effectue un filtrage parmi les proxies découverts pour ne retenir que celui ou ceux qui mettent en œuvre un protocole de communication PROT donné utilisé par le dispositif de communication UE1, UE2, et qui sont raccordés à une tranche réseau à laquelle lui-même est raccordé. Par exemple ici, le protocole de communication PROT est un protocole de transport déterminé, à savoir le protocole TCP et son option MPTCP, supporté par le dispositif de communication UE1, UE2. Mais comme évoqué précédemment, d’autres protocoles de transport, applicatifs ou œuvrant au niveau de la couche IP peuvent être envisagés en variante moyennant la définition d’extensions appropriées pour la mise en œuvre de l’invention. De telles extensions peuvent prendre différentes formes selon le protocole considéré. Par exemple, pour le protocole TCP/MPTCP elles peuvent prendre la forme de nouvelles options ou nouveaux « flags » TCP. Pour le protocole QUIC/MPQUIC, elles peuvent prendre la forme d’un nouveau paramètre de transport, d’une nouvelle trame QUIC, d’un message d’erreur, etc. Lorsque le protocole Convert est considéré en plus du protocole TCP, de nouveaux messages au format TLV peuvent être définis. L’homme du métier transposera aisément les extensions décrites ici pour la mise en œuvre de l’invention dans l’exemple particulier des protocoles Convert, TCP et de son option MPTCP, à d’autres protocoles de communication en tenant compte de leurs spécificités. Le filtrage opéré par le dispositif de communication UE1, UE2 peut être réalisé globalement, ou pour chaque communication, ou encore pour chaque service, le protocole PROT pouvant différer à chaque filtrage. En outre, le dispositif de communication UE1, UE2 peut maintenir des listes de proxies découverts par protocole (par exemple une liste de proxies pour le protocole de transport TCP/MPTCP, une pour le protocole de transport QUIC/MPQUIC) et sélectionner pour une communication un protocole PROT de transport donné et la liste de proxies correspondante. On suppose maintenant que le dispositif de communication UE1 souhaite échanger des données applicatives lors d’une communication COM avec le dispositif de communication UE2 dans le cadre du service « S » (« données relatives au service « S » » au sens de l’invention), en utilisant le protocole PROT (PROT = TCP/MPTCP ici) et en s’appuyant sur la procédure SLALOM. Dans le mode de réalisation décrit ici, la procédure SLALOM est avantageusement déclenchée concomitamment à l’établissement de la connexion entre les dispositifs de communication UE1 et UE2, et certaines informations utiles à cette mise en œuvre sont véhiculées dans les messages échangés lors de cet établissement. Typiquement dans l’exemple du protocole TCP, de telles informations peuvent être véhiculées dans les segments TCP SYN, SYN+ACK et ACK échangés lors de la procédure en trois étapes « 3WHS » évoquée précédemment permettant d’établir une connexion, comme illustré dans un exemple par la FIG. 8 . Toutefois en variante, on peut envisager un autre mode de réalisation dans lequel des messages dédiés (par exemple des segments TCP dédiés) sont prévus pour la mise en œuvre de l’invention. En référence à la figure 3A, le dispositif de communication UE1 sélectionne un proxy parmi les proxies découverts et filtrés lors de l’étape E20 supportant le protocole PROT, par exemple le proxy Pm0 (étape E30), puis envoie, via le proxy Pm0 sélectionné, une demande M1 d’établissement de connexion conformément au protocole PROT au dispositif de communication UE2 (étape E40). Ainsi, le proxy Pm0 se trouve sur le chemin des données applicatives relatives au service S (c’est-à-dire le plan de données) échangées lors de la communication COM entre les dispositifs de communication UE1 et UE2 impliqués dans la communication COM (il convient de noter que la demande M1 d’établissement de connexion peut, éventuellement déjà véhiculer des données applicatives relatives au service « S »). La demande M1 de connexion est envoyée par le dispositif de communication UE1, par l’intermédiaire de son module 4D d’envoi, en utilisant une tranche réseau à laquelle le proxy Pm0 et le dispositif de communication UE1 sont tous les deux raccordés, et qui est adaptée au service « S » auquel le dispositif de communication UE1 souhaite accéder (le dispositif de communication UE1 sélectionne cette tranche réseau en fonction par exemple de son type et des contraintes associées au service « S », de façon connue en soi). Elle prend la forme ici d’un segment TCP comprenant l’option MPTCP supportée par le dispositif de communication UE1, et incluant dans sa charge utile, conformément au protocole Convert, un message au format TLV Connect de demande d’établissement d’une connexion avec le proxy Pm0. Le message Connect véhicule un TLV PC-SS tel qu’illustré par la figure 6C, référencé sur les figures par PC-SS(UE1), indiquant au proxy Pm0 les tranches réseau auxquelles le dispositif de communication UE1 est raccordé. Tout ou partie des éléments relatifs aux tranches réseau, indiqués dans le TLV PC-SS(UE1) peuvent avoir été fournis au dispositif de communication UE2 lors de l’étape E10, par exemple dans la liste LIST1. Par ailleurs, dans le mode de réalisation décrit ici, le message TLV Connect comprend également les informations complémentaires suivantes pour chaque tranche réseau indiquée dans le TLV PC-SS(UE1) : un identifiant de réseau ou NID (pour « Network IDentifier en anglais) auquel est associée la tranche réseau (pour permettre typiquement de distinguer deux tranches réseau portant le même identifiant mais rattachées à des réseaux différents), et/ou un ou plusieurs identifiants AddressID (pour « Address IDentifier » en anglais) d’adresses IP allouées à cette tranche réseau pour le dispositif de communication UE1, pouvant être utilisés notamment en présence d’un dispositif NAT (pour « Network Address Translation » en anglais) entre le dispositif de communication UE1 et le proxy Pm0, de façon connue en soi. Ces informations complémentaires peuvent être transmises dans le TLV PC-SS(UE1), par exemple de façon similaire aux identifiants SID, ou dans un autre message au format TLV prévu à cet effet. Les identifiants NID peuvent avoir été fournis au dispositif de communication UE1 lors de l’étape E10, par exemple dans la liste LIST1, quand le dispositif de communication UE1 s’est connecté au fournisseur de services SSP1, ou peuvent avoir été configurés au niveau du dispositif de communication UE1, de façon similaire ou identique aux éléments du TLV PC-SS(UE1). Les identifiants AddressID sont générés par le dispositif de communication UE1, par exemple selon le même mécanisme que celui utilisé pour l’option MPTCP ADD_ADDR. A titre illustratif sur la FIG. 8 , la demande M1 correspond à un segment TCP SYN(PC-SS(UE1)) envoyé par le dispositif de communication UE1 au proxy Pm0. On note que lors de l’étape de découverte des proxies, dans le mode de réalisation décrit ici, le dispositif de communication UE1 et le proxy Pm0 se sont déjà signalés leur support respectif de la procédure SLALOM via le TLV PC-SC. Néanmoins, si ce n’est pas le cas, par exemple parce que la découverte des proxies s’est appuyée sur le mécanisme DNS SVCB, on peut envisager un tel échange avant que le dispositif de communication UE1 envoie au proxy Pm0 le TLV PC-SS(UE1) identifiant les tranches réseau auxquelles il est raccordé. En référence à la FIG. 4 , sur réception de la demande M1 par son module 3E de réception (étape F10), le proxy Pm0 extrait le TLV Connect lui étant destiné, et au sein de ce message, les informations contenues dans le TLV PC-SS(UE1) et le cas échéant, les informations complémentaires relatives aux identifiants NID et/ou AddressID (étape F20). Il mémorise ces informations en association avec le dispositif de communication UE1, par exemple dans un cache de sa mémoire NVM. Puis le proxy Pm0 relaye vers le dispositif de communication UE2 la demande d’établissement de connexion du dispositif de communication UE1 (étape F30). Il enrichit auparavant cette demande avec diverses informations, et plus particulièrement, dans le mode de réalisation décrit ici avec un attribut SC (pour « Slalom Capable »), traduisant le fait qu’il supporte la procédure SLALOM (et est donc un proxy conforme à l’invention). Cet attribut prend la forme par exemple d’une nouvelle extension du protocole PROT définie pour les besoins de l’invention. Ainsi, dans le mode de réalisation décrit ici, il s’agit d’une nouvelle option TCP. Toutefois, en variante, d’autres formes sont possibles en fonction du protocole considéré. Par ailleurs, le proxy Pm0 peut enrichir la demande d’établissement de connexion avec d’autres informations, comme par exemple l’option MPTCP MP_CAPABLE traduisant le cas échéant sa capacité à supporter des communications TCP à chemins multiples. La demande d’établissement de connexion enrichie est désignée par M1’. Elle est envoyée par le proxy Pm0 au dispositif de communication UE2 en utilisant comme adresse de transport source (celle-ci comprenant une adresse IP et un numéro de port sources), l’adresse de transport du proxy Pm0 (étape F30). A titre illustratif sur la FIG. 8 , la demande M1’ correspond à un segment TCP SYN(SC) envoyé par le proxy Pm0 au dispositif de communication UE2. Sur réception de la demande M1’ d’établissement d’une connexion (étape E30’, figure 3B), si le dispositif de communication UE2 supporte la procédure SLALOM (et donc est un dispositif de communication conforme à l’invention), il répond au proxy Pm0 en insérant dans son message M2 de réponse (par l’intermédiaire de son module 4D d’envoi), des informations relatives aux tranches réseau auxquelles le dispositif de communication UE2 est raccordé, c’est-à-dire aux tranches réseau de la liste LIST2 fournie par le fournisseur de services SSP1 à l’étape E10) (étape E40’). Ces informations sont incluses, dans le mode de réalisation décrit ici, dans un attribut SS (pour « Slice Set ») référencé par SS(UE2). A titre illustratif sur la FIG. 8 , le message M2 est par exemple un segment TCP SYN+ACK(SS(UE2)). L’attribut SS peut prendre la forme d’une nouvelle extension du protocole PROT, c’est-à-dire TCP et son option MPTCP ici, définie pour les besoins de l’invention. L’attribut SS comprend ici, pour chaque tranche réseau : un type ST (pour « Slice Type » en anglais) de la tranche réseau. Ce type ST correspond par exemple à une valeur SST définie par les standards 3GPP. Bien entendu, d’autres indicateurs de type de tranche réseau peuvent être envisagés dès lors qu’ils sont interprétables par les fournisseurs de service SSP. Ainsi, des types standardisés ou spécifiques (par exemple décidés dans des accords de gré-à-gré entre les fournisseurs SSP) peuvent être envisagés. Par ailleurs, une même tranche réseau peut être associée à plusieurs types de tranche, notamment lorsque cette tranche réseau agrège plusieurs tranches réseau locales ; et un identifiant de la tranche réseau ou SID (pour « Slice IDentifier » en anglais). L’attribut SS peut en outre comprendre, pour chaque tranche réseau, d’autres informations comme par exemple un identifiant de réseau NID auquel est associée la tranche réseau (pour permettre typiquement de distinguer deux tranches réseau portant le même identifiant mais rattachées à des réseaux différents), et/ou un ou plusieurs identifiants AddressID d’adresses IP allouées au dispositif de communication UE2 pour cette tranche réseau, pouvant être utilisés notamment en présence d’un dispositif NAT (pour « Network Address Translation » en anglais) entre le dispositif de communication UE2 et le proxy Pm0, de façon connue en soi. Tout ou partie des informations ST, SID et NID peuvent avoir été fournies au dispositif de communication UE2 lors de l’étape E10, par exemple dans la liste LIST2, quand le dispositif de communication UE2 s’est connecté au fournisseur de services SSP1, ou peuvent avoir été configurés au niveau du dispositif de communication UE2. Les identifiants AddressID sont générés par le dispositif de communication UE2, par exemple selon le même mécanisme que celui utilisé pour l’option MPTCP ADD_ADDR. Sur réception du message de réponse M2 par son module 3E de réception (étape F40, FIG. 4 ), le proxy Pm0 extrait les informations contenues dans l’attribut SS(UE2) et les mémorise en association avec le dispositif de communication UE2, par exemple dans un cache de sa mémoire NVM (étape F50). Puis le proxy Pm0, par l’intermédiaire de son module 3A de sélection, sélectionne pour chaque dispositif de communication UE1, UE2, en fonction de la politique POL de sélection stockée localement dans sa mémoire NVM, au moins une tranche réseau adaptée au service « S » utilisable par le dispositif de communication UE1,UE2 pour la communication COM (étape F60). Dans la suite de la description, on désigne par SL(UE1) la ou les tranches réseau sélectionnées pour le dispositif de communication UE1 et par SL(UE2), la ou les tranches réseau sélectionnées pour le dispositif de communication UE2. Dans l’exemple envisagé ici, la politique POL de sélection comprend plusieurs règles de sélection, qui sont hiérarchisées entre elles, c’est-à-dire destinées à être appliquées dans un certain ordre : - une première règle R1 dite de compatibilité selon laquelle lorsqu’une condition de compatibilité est vérifiée selon laquelle les dispositifs de communication UE1 et UE2 sont raccordés à au moins une tranche réseau d’un même type qui est adaptée au service « S », ladite au moins une tranche réseau d’un même type est sélectionnée pour ces dispositifs de communication pour être utilisée lors de la communication COM ; - une deuxième règle R2 selon laquelle au moins une tranche réseau sélectionnée pour au moins un dit dispositif correspond à une tranche réseau à laquelle est déjà raccordé ce dispositif. On peut, lors de l’application de cette deuxième règle R2, privilégier l’un des deux dispositifs. Par exemple, on sélectionne une tranche réseau à laquelle est déjà raccordé le dispositif de communication UE2 ; ceci peut s’avérer pertinent par exemple si le dispositif de communication UE2 ne supporte pas la procédure SLALOM. En variante, on peut privilégier le dispositif de communication qui est raccordé à la tranche réseau qui optimise la qualité du service « S », au regard d’un critère déterminé qui dépend du service « S » ou du type du service « S » (par ex. la latence, le débit, le taux d’erreur, le temps d’établissement des connexions de la communication ou la bande passante) ; et - une troisième règle R3 selon laquelle les tranches réseau sélectionnées pour les dispositifs de communication UE1 et UE2 optimisent la qualité du service « S », par exemple au regard d’un critère donné qui dépend du service « S » ou du type du service « S » (latence, débit, taux d’erreur, temps d’établissement des connexions de la communication, bande passante, etc.). Il convient de noter que cette règle R3 peut être appliquée globalement de sorte à optimiser la qualité globale du service « S » entre les deux dispositifs de communication UE1 et UE2 sur les deux tranches réseau, ou par segment de communication, le critère étant appliqué une première fois pour sélectionner la tranche SL(UE1) de sorte à optimiser la qualité du service « S » entre le dispositif de communication UE1 et le proxy Pm0, et une deuxième fois pour sélectionner la tranche SL(UE2) de sorte à optimiser la qualité du service « S » entre le dispositif de communication UE2 et le proxy Pm0. Comme mentionné précédemment, ces règles sont hiérarchisées au sein de la politique POL de sélection, c’est-à-dire appliquées dans un certain ordre. Par exemple ici, les première, deuxième et troisième règles sont hiérarchisées de la façon suivante : - on teste en premier lieu si la condition de compatibilité de la première règle R1 est vérifiée. Le cas échéant, les tranches réseau compatibles sont sélectionnées, et si plusieurs tranches réseau vérifient cette condition, on utilise la troisième règle R3 pour opérer une sélection parmi les tranches réseau compatibles ; et - si la condition de compatibilité n’est pas vérifiée, la deuxième règle R2 est appliquée, en privilégiant une tranche réseau à laquelle le dispositif de communication UE2 est déjà raccordé. Si plusieurs tranches réseau vérifient cette condition, la troisième règle R3 est utilisée pour procéder à la sélection finale. On note que pour identifier les tranches réseau adaptées au service « S » dans chacune des règles, le proxy Pm0 peut utiliser les objectifs de niveau de service ou SLO (pour « Service Level Objectives » en anglais) connus pour ces tranches réseau, qu’il compare aux exigences du service « S ». Il peut à cet effet être configuré avec ces SLO (par exemple par type de tranche) ou les obtenir auprès des contrôleurs NSC1,…, NSCN gérant les tranches réseau en question. Par ailleurs, l’application de la troisième règle R3 peut utiliser un ou plusieurs critères de qualité disponibles dans les SLO. Bien entendu, d’autres politiques de sélection peuvent être envisagées, hiérarchisant de façon différente les règles énoncées ci-dessus, ou contenant une règle ou plus parmi les règles ci-dessus, et/ou contenant d’autres règles. Par exemple, on peut envisager une quatrième règle consistant à sélectionner pour au moins l’un des dispositifs de communication, une tranche réseau adaptée au service à laquelle est raccordé le proxy Pm0, ou encore une cinquième règle portant sur des paramètres autres que la qualité de service comme notamment un niveau de sécurité. Ainsi, conformément à la politique POL de sélection, le proxy Pm0 examine tout d’abord si, parmi les tranches réseau auxquelles sont raccordées les dispositifs de communication UE1 et UE2, il existe des tranches réseau compatibles, c’est-à-dire identiques ou de même type, qui sont adaptées au service « S ». Il peut à cet effet comparer les informations PC-SS(UE1) relatives aux différentes tranches réseau auxquelles est raccordé le dispositif de communication UE1 avec les informations SS(UE2) relatives aux différentes tranches réseau auxquelles est raccordé le dispositif de communication UE2 dont il dispose dans sa mémoire non volatile NVM, et le cas échéant, vérifier que les tranches réseau compatibles sont adaptées au service « S » en considérant leurs SLO respectifs (l’ordre dans lequel procède le proxy Pm0 est sans importance). En variante, lorsqu’il identifie des tranches réseau compatibles, le proxy Pm0 peut comparer, s’il dispose de telles informations, les identifiants SID des tranches réseau combinés aux identifiants NID des réseaux auxquelles sont rattachés les tranches réseau. En effet, on peut envisager qu’un dispositif de communication UE1, UE2 annoncent des identifiants SID de tranches réseau distincts par réseau. Dans ce cas, l’association entre un identifiant SID d’une tranche réseau et un type de tranche réseau dépend de l’identifiant NID correspondant à cette tranche réseau. Si le proxy Pm0 identifie au moins deux tranches réseau compatibles parmi les tranches réseau auxquelles les dispositifs de communication UE1 et UE2 sont raccordés, il sélectionne pour les dispositifs de communication UE1 et UE2 les tranches réseau SL(UE1) et SL(UE2) correspondantes (application de la première règle R1). Dans l’hypothèse où plusieurs paires de tranches réseau compatibles deux à deux sont identifiés par le proxy Pm0, il peut, selon sa configuration, sélectionner tout ou partie de ces paires pour les dispositifs de communication UE1 et UE2. Par exemple, il peut sélectionner une unique paire correspondant aux tranches réseau SL(UE1) et SL(UE2) qui optimisent (ou dont les types optimisent) la qualité du service « S » au regard du ou des critères considérés dans la troisième règle R3 (en d’autres termes, la sélection opérée par le proxy Pm0 résulte de l’application de la première règle R1 puis de la troisième règle R3). Si c’est le type de tranches réseau qui est considéré, le proxy Pm0 sélectionne ensuite, parmi les paires de tranches réseau compatibles, une paire de tranches réseau SL(UE1) et SL(UE2) de ce type. S’il n’existe aucune compatibilité entre les tranches réseau auxquelles sont raccordés les dispositifs de communication UE1 et UE2, alors, dans l’exemple envisagé ici, conformément à la deuxième règle R2, le proxy Pm0 sélectionne pour le dispositif de communication UE2, au moins une tranche réseau SL(UE2) à laquelle le dispositif de communication UE2 est déjà raccordé et qui est adaptée au service « S ». Si plusieurs tranches réseau sont possibles, le proxy Pm0 peut sélectionner tout ou partie de ces tranches. Par exemple, il sélectionne la tranche réseau SL(UE2) qui optimise la qualité du service « S » entre le proxy Pm0 et le dispositif de communication UE2 au regard du ou des critères considérés dans la troisième règle R3. On note que des tranches réseau différentes ou de types différents peuvent être sélectionnées pour des réseaux d’accès distincts. Puis le proxy Pm0 sélectionne pour le dispositif de communication UE1 au moins une tranche réseau SL(UE1) adaptée au service S qui optimise la qualité du service S au regard du ou des critères considérés dans la troisième règle R3. A cet effet, le proxy Pm0 peut avoir été configuré au préalable (ou de façon dynamique) avec l’ensemble des tranches réseau disponibles supportées par les réseaux NW1,…, NWN, ainsi qu’avec des informations lui permettant d’identifier et de contacter les contrôleurs NSC1,…, NSCN gérant ces tranches réseau. Il peut par ailleurs avoir été configuré avec les SLO associés à ces tranches réseau, ou les obtenir en interrogeant les contrôleurs NSC1,…, NSCN. Il convient de noter que, selon la politique POL de sélection appliquée, les tranches réseau SL(UE1) et SL(UE2) sélectionnées pour les dispositifs de communication UE1, UE2 pour la communication COM peuvent être identiques ou de même type, ou au contraire, être différentes ou de types différents. Il est ainsi possible au proxy Pm0 de sélectionner des tranches réseau qui optimisent la communication COM sur chaque segment de la connexion supportant cette communication. Le proxy Pm0 n’est pas nécessairement contraint de sélectionner une même tranche réseau (ou un même type de tranche réseau) de bout en bout. Par souci de simplification, on suppose dans la suite qu’une seule tranche réseau est sélectionnée pour chaque dispositif de communication UE1, UE2. Si plusieurs tranches réseau sont sélectionnées pour un dispositif de communication UE1, U2, le proxy Pm0 procède de façon identique ou similaire à ce qui est décrit ci-après pour chaque tranche réseau sélectionnée. Suite à la sélection de la tranche réseau SL(UE1), le proxy Pm0 examine si le dispositif de communication UE1 est déjà raccordé à cette tranche réseau en utilisant les informations PC-SS(UE1) stockées dans sa mémoire non volatile NVM (étape test F70). Si ce n’est pas le cas (réponse non à l’étape test F70), il envoie au contrôleur NSC gérant la tranche réseau SL(UE1), par l’intermédiaire de son module 3B de communication, une demande M3 de raccordement du dispositif de communication UE1 à cette tranche réseau SL(UE1) (étape F80). On suppose ici que c’est le contrôleur NSCn0 (n0 étant un entier parmi 1,…,N) qui gère la tranche réseau SL(UE1). En référence à la FIG. 5 , sur réception de la demande M3 de raccordement du proxy Pm0 par son module 5A de réception (étape G10), le contrôleur NSCn0 vérifie dans le mode de réalisation décrit ici, si le dispositif de communication UE1 est habilité (c’est-à-dire autorisé) à utiliser la tranche réseau SL(UE1) (étape test G20). Il peut également procéder à d’autres vérifications, comme par exemple contrôler que le proxy Pm0 est bien habilité à lui demander un tel raccordement pour le dispositif de communication UE1. Ces contrôles sont connus en soi et ne sont pas détaillés ici. Si ce n’est pas le cas (réponse non à l’étape test G20), la demande de raccordement est rejetée (étape G30). Si le dispositif de communication UE1 est habilité à utiliser la tranche réseau SL(UE1) (réponse « oui » à l’étape test G20), le contrôleur NSCn0 déclenche le raccordement demandé par l’intermédiaire de son module 5B de déclenchement (étape G40), et envoie un message M4 de confirmation de ce raccordement au proxy Pm0 (étape G50). En référence à la FIG. 4 , le message M4 de confirmation est reçu par le proxy Pm0 (étape F90). Il convient de noter que le contrôleur NSCn0 n’est pas nécessairement la seule entité du réseau impliquée dans le raccordement du dispositif de communication UE1 à la tranche réseau SL(UE1) ; il est à l’origine (c’est-à-dire initie) du raccordement, mais d’autre(s) entité(s) peu(ven)t venir en support du contrôleur NSCn0 pour rendre ce raccordement effectif. Le contrôleur NSCn0 peut communiquer directement avec le dispositif de communication UE1 en vue de son raccordement à la tranche réseau SL(UE1), ou une autre entité du réseau NWn0 peut s’en charger, par exemple un centre de support client. L’utilisateur du dispositif de communication UE1 peut par ailleurs être informé de ce raccordement, par exemple via un message de notification de type SMS (pour « Short Message Service » en anglais) éventuellement assorti d’informations descriptives de la nouvelle tranche réseau SL(UE1) à laquelle le dispositif de communication UE1 est raccordé, telles que la qualité de la connexion attendue via cette tranche réseau SL(UE1), etc. Il convient de noter que si le proxy Pm0 n’est pas raccordé à l’une et/ou l’autre des tranches réseau SL(UE1) et SL(UE2), il peut demander de façon similaire son propre raccordement aux contrôleurs NSC gérant ces tranches réseau. Par ailleurs, dans le mode de réalisation, le raccordement du dispositif de communication UE1 à la tranche réseau SL(UE1) est demandé au contrôleur NSCn0 suite à la sélection de la tranche réseau SL(UE1) pour le dispositif de communication SL(UE1). En variante, on peut envisager que le proxy Pm0 demande ce raccordement pour les tranches réseau susceptibles d’être sélectionnées pour la communication COM avant l’étape de sélection F50, c’est-à-dire avant même d’appliquer la politique POL de sélection. De telles tranches réseau peuvent être identifiées par le proxy Pm0 en fonction des caractéristiques du service « S » (déterminé par exemple à partir de l’adresse de destination ou autres identifiants de service indiqués dans les messages d’accès au service S envoyés par les dispositifs de communication UE1, UE2), des capacités des dispositifs de communication UE1, UE1, etc. De cette sorte, la politique POL de sélection est appliquée sur des tranches réseau auxquelles les dispositifs de communication UE1, UE2 sont raccordés. En référence à la figure 3A, suite au raccordement du dispositif de communication UE1 à la tranche réseau SL(UE1) (réponse « oui » à l’étape test E50), le dispositif de communication UE1 envoie, par l’intermédiaire de son module 4D d’envoi, un message M5 au proxy Pm0 lui indiquant la nouvelle tranche réseau SL(UE1) à laquelle il est raccordé (étape E60). Le message M5 est par exemple un segment TCP incluant dans sa charge utile, dans un TLV PC-SS référencé par PC-SS(UE1)’, l’ensemble des tranches réseau auxquelles le dispositif de communication UE1 est raccordé. Le TLV PC-SS(UE1)’ est donc une mise à jour du TLV PC-SS(UE1) précédemment envoyé par le dispositif de communication UE1 au proxy Pm0, qui inclut d’une part les tranches réseau identifiées dans la liste LIST1 reçue du fournisseur de services SSP1 à l’étape E10, et d’autre part, la nouvelle tranche réseau SL(UE1). En variante, le message M5 peut ne contenir que la nouvelle tranche réseau SL(UE1). Par exemple, la nouvelle tranche réseau SL(UE1) peut être incluse dans une nouvelle extension du protocole Convert, appelée ici TLV PC-SS-UPD, apte à indiquer au proxy Pm0 que son contenu est une mise à jour des informations précédemment transmises dans le message PC-SS(UE1). En référence à la FIG. 4 , sur réception du message M5 par son module 3E de réception (étape F100), le proxy Pm0 extrait les informations contenues dans le message PC-SS(UE1)’ et les mémorise dans le cache de sa mémoire non volatile NVM en association avec le dispositif de communication UE1 (étape F110). Si le message PC-SS(UE1)’ contient les informations relatives à toutes les tranches réseau auxquelles le dispositif de communication UE1 est raccordé, ces informations sont mémorisées dans le cache en remplacement des informations précédemment mémorisées ; si elles concernent uniquement la nouvelle tranche réseau SL(UE1), alors elles sont mémorisées en complément des informations précédemment mémorisées. Si lors de l’étape test F70, le proxy Pm0 détermine que le dispositif de communication UE1 est déjà raccordé à la tranche réseau SL(UE1) sélectionnée pour le dispositif de communication UE1 (réponse « oui » à l’étape test E70), ou à l’issue de l’étape F110, le proxy Pm0 envoie, par l’intermédiaire de son module 3C d’envoi, un message M6, M7 à chaque dispositif de communication UE1, UE2 pour lui indiquer ladite au moins une tranche SL(UE1), SL(UE2) sélectionnée pour lui par le proxy Pm0 et utilisable par le dispositif de communication UE1, UE2 lors de la communication COM (étape F120). Ces tranches réseau peuvent être indiquées respectivement dans les messages M6 et M7 dans un TLV PC-SS (noté PC-SS(UE1)’’’) et un attribut SS (noté SS(UE2)’) respectivement. Ces tranches réseau permettent d’optimiser la qualité du service « S » lors de la communication COM. En référence aux figures 3A et 3B, sur réception par son module 4A de réception de ce message M6 (étape E70), M7 (étape E50’), chaque dispositif de communication UE1, UE2 bascule la communication COM vers au moins une des tranches réseau SL(UE1), SL(UE2) indiquées si elle(s) est/sont différente(s) de celle(s) qu’il utilise (étapes E80, E60’). Lorsque plusieurs tranches réseau sont indiquées, un algorithme de répartition de charge (par ex. ECMP pour « Equal-Cost Multi-Path » en anglais) peut être utilisé entre les tranches réseau. Les différentes tranches réseau indiquées par le proxy Pm0 peuvent également être associées à des réseaux distincts, de sorte que le dispositif de communication UE1, UE2 peut basculer la communication vers la ou les tranches réseau associées au réseau via lequel il a décidé d’envoyer des données relatives au service « S ». En tout état de cause, le dispositif de communication UE1, UE2 doit utiliser lors de la communication COM l’une au moins des tranches réseau qui lui a été indiquée par le proxy Pm0. Les dispositifs de communication UE1 et UE2, par l’intermédiaire de leurs modules 4B d’application respectif, sont maintenant configurés pour utiliser la ou les tranches de réseau SL(UE1), SL(UE2) lors de la communication COM : ils associent le trafic sortant lié à la communication COM avec les tranches SL(UE1) et SL(UE2), et le marquage du trafic est celui associé aux tranches SL(UE1) et SL(UE2). A titre illustratif sur la FIG. 8 , un exemple d’utilisation des segments TCP SYN+ACK et ACK pour véhiculer les messages M5 à M7 est représenté. Selon cet exemple, si le proxy Pm0 détermine lors de l’étape test F70 que le dispositif de communication UE1 n’est pas raccordé à la tranche réseau SL(UE1), il lui envoie un segment SYN+ACK(PC-SS(UE1)’’) où le TLV PC-SS(UE1)’’ contient la tranche réseau, notée SL0, utilisée par le dispositif de communication UE1 pour envoyer le message M1 au proxy Pm0. Le dispositif de communication UE1 répond en envoyant un segment ACK(PC-SS(UE1)’’)). Suite au raccordement du dispositif de communication UE1 à la tranche réseau SL(UE1), le message M5 envoyé par le dispositif de communication UE1 au proxy Pm0 prend la forme d’un segment ACK(PC-SS(UE1)’). Comme introduit précédemment, le TLV PC-SS(UE1)’ identifie toutes les tranches réseau auxquelles sont raccordées le dispositif de communication UE1, incluant la tranche réseau SL(UE1). Le message M6 alors envoyé par le proxy Pm0 prend la forme d’un segment ACK(PC-SS(UE1)’’’) contenant la tranche réseau SL(UE1) sélectionnée par le proxy Pm0 pour la communication COM pour le dispositif de communication UE1. De même, le message M7 envoyé par le proxy Pm0 au dispositif de communication UE2 prend la forme d’un segment ACK(SS(UE2)’’), dans lequel l’attribut SS(UE2)’’ contient la tranche réseau SL(UE2) sélectionnée par le proxy Pm0 et utilisable pour la communication COM par le dispositif de communication UE2. Il convient de noter que d’autres implémentations que celles représentée sur la FIG. 8 sont possibles. Par exemple, le proxy Pm0 peut différer l’envoi du message SYN+ACK au dispositif de communication UE2 jusqu’à recevoir la confirmation de ce raccordement par le dispositif de communication UE1. Selon une autre implémentation encore, le raccordement peut être demandé en amont de la sélection, de sorte que le segment SYN+ACK envoyé au dispositif de communication UE2 identifie dans le TLV PC-SS(UE1)’’ la ou les tranches réseau SL(UE1) sélectionnées pour le dispositif de communication UE1 et utilisables pour la communication COM. Suite au basculement de la communication sur les tranches réseau SL(UE1) et SL(UE2), le proxy Pm0 peut, selon le contexte, rester ou non impliqué dans l’échange de données entre les dispositifs de communication UE1 et UE2, c’est-à-dire rester ou non sur le chemin des données échangées entre les dispositifs de communication UE1 et UE2 et assurer sa fonction de relais des données entre les dispositifs de communication UE1 et UE2. Plus particulièrement, si les tranches réseau SL(UE1) et SL(UE2) utilisées respectivement par les dispositifs de communication UE1 et UE2 sont identiques, le proxy Pm0 peut décider de se retirer du chemin des données échangées entre les dispositifs de communication UE1 et UE2 et laisser les dispositifs de communication UE1 et UE2 gérer la communication COM de bout en bout. A cet effet, le proxy Pm0 envoie par exemple un message de retrait à chaque dispositif de communication UE1, UE2 ; ce message de retrait utilise par exemple l’option MPTCP REMOVE_ADDR véhiculant l’adresse du proxy Pm0 et l’extension PC-SS ou SS véhiculant la tranche réseau pour laquelle le proxy Pm0 se retire. Les dispositifs de communication UE1 et UE2 se signalent respectivement leurs adresses, par exemple au moyen de l’option MPTCP ADD_ADDR ou de l’option MP_JOIN. On note que le proxy Pm0 peut décider de se retirer pour certaines tranches réseau seulement et de rester actif pour d’autres. Cette décision dépend le cas échéant d’instructions fournies au proxy par un opérateur. Le proxy Pm0 peut à l’inverse rester impliqué dans la communication COM, notamment quand les tranches réseau SL(UE1) et SL(UE2) diffèrent. Il réalise alors l’interconnexion entre les tranches réseau SL(UE1) et SL(UE2), et sa position dans le plan des données échangées entre les dispositifs de communication UE1 et UE2 lui permet d’accéder au marquage des paquets de données ou aux informations contenues dans leurs entêtes qu’il peut alors modifier pour pouvoir les adapter à des tranches réseau SL(UE1) et SL(UE2) différentes et orienter correctement les paquets de données vers les bonnes tranches réseau. Par exemple, le proxy peut modifier le marquage des tranches conformément aux tranches sélectionnées pour une communication. Par ailleurs, les dispositifs de communication UE1 et UE2 peuvent mémoriser les tranches réseau SL(UE1) et SL(UE2) sélectionnées pour eux pour le service « S », et lors d’un futur accès au service « S », utiliser directement ces tranches réseau sans solliciter le proxy Pm0. Dans le mode de réalisation décrit ici, la procédure SLALOM est déclenchée par le dispositif de communication UE1 lors de l’établissement de la connexion avec le dispositif de communication UE2. On peut envisager en variante, qu’elle soit déclenchée par le dispositif de communication UE2. Son déroulement est alors identique à celui qui vient d’être décrit pour le dispositif de communication UE1. Dans un autre mode de réalisation, on peut également envisager que chaque dispositif de communication UE1, UE2 utilise un proxy différent, chacun de ces proxies se trouvant sur le chemin de tout ou partie des données échangées lors de la communication COM entre les deux dispositifs de communication UE1 et UE2. La FIG. 9 illustre un système 1’ conforme à l’invention correspondant à une telle situation. Sur cette figure, le dispositif de communication UE1 sélectionne le proxy Pm0 et le dispositif de communication UE2 sélectionne le proxy Pk0, m0 et k0 désignant deux entiers distincts. La procédure SLALOM, lorsqu’elle est déclenchée par le dispositif de communication UE1, est alors mise en œuvre de façon similaire ou identique à ce qui vient d’être décrit entre le dispositif de communication UE1 et le proxy Pk0, puis entre le proxy Pm0 et le dispositif de communication UE2. En d’autres termes, le proxy Pm0 sélectionne pour le dispositif de communication UE1 et pour le proxy Pk0 les tranches réseau à utiliser par ces deux équipements pour la communication COM, puis le proxy Pk0 sélectionne pour le proxy Pm0 et pour le dispositif de communication UE2 les tranches réseau à utiliser pour la communication COM par ces deux équipements. Les proxies Pm0 et Pk0 sont donc tour à tour des proxies et des dispositifs de communication conformes à l’invention. Par ailleurs, dans ce qui vient d’être décrit, les dispositifs de communication UE1 et UE2 communiquent directement avec les proxies. On peut envisager, dans un autre mode de réalisation, que les dispositifs de communication UE1 et/ou UE2 soient connectés à un équipement tel qu’une passerelle résidentielle ou CPE. Dans ce cas, la passerelle résidentielle est un dispositif de communication conforme à l’invention et la procédure SLALOM s’applique de façon similaire ou identique à ce qui vient d’être décrit entre la passerelle résidentielle et le dispositif de communication distant ou la passerelle résidentielle à laquelle ce dispositif de communication distant est connecté le cas échéant. Chaque dispositif de communication UE1, UE2 se trouvant le cas échéant derrière une passerelle résidentielle communique avec elle pour obtenir les informations relatives aux tranches réseau à laquelle la passerelle est connectée (typiquement les informations transmises par la passerelle au proxy dans les messages/attributs PC-SS ou SS) et lui envoie les règles de classification de trafic pour associer les flux sortants avec une ou plusieurs tranches réseau idoines correspondant aux tranches réseau auxquelles la passerelle est raccordée. Le dispositif de communication UE1, UE2 peut à cette fin utiliser de nouvelles options ou messages défini(e)s pour les besoins de l’invention en fonction du protocole utilisé pour communiquer ces éléments. Par exemple, on peut envisager d’utiliser les protocoles PCP (pour « Port Control Protocol » en anglais), DHCP (pour « Dynamic Host Configuration Protocol » en anglais), ou un message RA (pour « Router Advertisement » en anglais), etc. Procédé de sélection de tranches réseau adaptées à un service et destinées à être utilisées lors d’une communication via au moins un réseau entre deux dispositifs (UE1, UE2) impliqués dans ladite communication, ledit procédé étant mis en œuvre par un proxy (Pm0) se trouvant sur au moins un chemin de données relatives audit service et échangées entre lesdits dispositifs lors de ladite communication, ledit procédé comprenant : une étape (F60) de sélection, en fonction d’une politique de sélection donnée, pour chaque dispositif (UE1,UE2), d’au moins une tranche réseau (SL(UE1),SL(UE2)) adaptée audit service utilisable par ce dispositif lors de ladite communication ; si un dit dispositif (UE1) n’est pas raccordé à au moins une dite tranche réseau (SL(UE1)) sélectionnée ou susceptible d’être sélectionnée pour ce dispositif, une étape (F80) d’envoi à au moins un contrôleur réseau (NSCn0) dudit au moins un réseau gérant ladite au moins une tranche réseau d’une demande de raccordement dudit dispositif à ladite au moins une tranche réseau ; et une étape (F110) d’envoi d’un message à chaque dispositif lui indiquant ladite au moins une tranche réseau sélectionnée pour ledit dispositif utilisable par ledit dispositif lors de la communication. Procédé de sélection selon la revendication 1 comportant en outre une étape (F20, F40) d’obtention en provenance d’au moins un dit dispositif, d’au moins une information représentative d’au moins une tranche réseau à laquelle est raccordé ce dispositif. Procédé de sélection selon la revendication 1 ou 2 dans lequel l’étape d’envoi d’une demande de raccordement concerne une tranche réseau susceptible d’être sélectionnée pour ledit dispositif et est mise en œuvre avant l’étape de sélection. Procédé de sélection selon l’une quelconque des revendications 1 à 3 dans lequel la politique de sélection applique au moins une règle parmi les règles suivantes : les tranches réseau sélectionnées pour lesdits dispositifs optimisent une qualité dudit service ; et/ou au moins une tranche réseau sélectionnée pour au moins un dit dispositif est une tranche réseau à laquelle est déjà raccordé ce dispositif ; et/ou lorsque lesdits dispositifs sont raccordés à au moins une tranche réseau d’un même type adaptée au service, ladite au moins une tranche réseau d’un même type est sélectionnée pour lesdits dispositifs. Procédé de sélection selon l’une quelconque des revendications 1 à 4 comprenant en outre une étape d’envoi à au moins un dit dispositif d’au moins une information représentative d’au moins une tranche réseau à laquelle est raccordé le proxy. Procédé de sélection selon l’une quelconque des revendications 1 à 5 comprenant, suite à l’étape d’envoi dudit message à chaque dispositif, une étape de maintien dudit proxy sur au moins un dit chemin de données relatives audit service échangées entre lesdits dispositifs lors de ladite communication via au moins une tranche réseau sélectionnée pour lesdits dispositifs. Procédé de sélection selon l’une quelconque des revendications 1 à 5 comprenant, suite à l’étape d’envoi dudit message à chaque dispositif, une étape de retrait dudit proxy d’au moins un dit chemin de données relatives audit service échangées entre lesdits dispositifs lors de ladite communication via une même tranche réseau sélectionnée pour lesdits dispositifs. Procédé de sélection selon l’une quelconque des revendications 1 à 7 dans lequel ladite au moins une information représentative d’une dite tranche réseau comprend au moins un élément parmi : un type de ladite tranche réseau ; un identifiant de ladite tranche réseau ; un identifiant de réseau auquel est rattachée ladite tranche réseau ; au moins un identifiant d’adresse IP (Internet Protocol) associée à ladite tranche réseau. Procédé de gestion d’au moins une tranche réseau par un contrôleur réseau (NSCn0) d’un réseau, ledit procédé comprenant : une étape (G10) de réception, en provenance d’au moins un proxy (Pm0) se trouvant sur un chemin de données relatives à un service et échangées via au moins ledit réseau lors d’une communication (COM) entre deux dispositifs (UE1,UE2) impliqués dans ladite communication, d’une demande de raccordement d’au moins un des dispositifs (UE1) à au moins une tranche réseau (SL(UE1)) gérée par ledit contrôleur réseau ; et une étape (G40) de déclenchement dudit raccordement. Procédé de communication par un premier dispositif (UE1,UE2) avec un proxy (Pm0) se trouvant sur un chemin de données relatives à un service et échangées avec un deuxième dispositif (UE2,UE1) lors d’une communication (COM) impliquant le premier et le deuxième dispositif, ledit procédé comprenant une étape (E80,E50’) de réception, en provenance dudit proxy (Pm0), d’un message indiquant audit premier dispositif (UE1,UE2) au moins une tranche réseau (SL(UE1), SL(UE2)) adaptée audit service utilisable par ledit premier dispositif lors de ladite communication et sélectionnée par ledit proxy (Pm0) en fonction d’une politique de sélection donnée. Procédé de communication selon la revendication 10 comprenant en outre, préalablement à l’étape (E80) de réception, une étape (E40) d’envoi via ledit proxy (Pm0) d’une demande d’établissement d’une connexion avec ledit deuxième dispositif (UE2) pour ladite communication, ladite demande d’établissement comprenant au moins une information (PC-SS(UE1)) représentative d’au moins une tranche réseau à laquelle est raccordé ledit premier dispositif (UE1). Procédé de communication selon la revendication 11 comprenant en outre, préalablement à l’étape (E80) d’envoi, une étape (E20) de découverte d’au moins un proxy (Pm0) raccordé à au moins une tranche réseau à laquelle est raccordé ledit premier dispositif (UE1) et mettant en œuvre au moins un protocole de communication donné utilisé lors de ladite communication, ledit proxy (Pm0) étant sélectionné par le premier dispositif parmi ledit au moins un proxy découvert lors de l’étape de découverte. Procédé de communication selon la revendication 10 comprenant en outre : une étape (E30’) de réception d’une demande (M1’) d’établissement d’une connexion avec ledit deuxième dispositif (UE1) pour ladite communication relayée par ledit proxy (Pm0) ; et une étape (E40’) d’envoi audit proxy (Pm0) d’un message (M2) comprenant au moins une information (SS(UE2)) représentative d’au moins une tranche réseau à laquelle est raccordée ledit premier dispositif (UE2). Proxy (Pm0) se trouvant sur un chemin de données relatives à un service et échangées via au moins un réseau lors d’une communication entre deux dispositifs (UE1,UE2) impliqués dans la communication, ledit proxy (Pm0) comprenant : un module (3A) de sélection, configuré pour sélectionner en fonction d’une politique de sélection donnée, pour chaque dispositif (UE1,UE2), au moins une tranche réseau (SL(UE1),SL(UE2)) adaptée audit service utilisable par ce dispositif lors de ladite communication ; un module (3B) de communication, activé si un dit dispositif (UE1) n’est pas raccordé à au moins une dite tranche réseau adaptée sélectionnée ou susceptible d’être sélectionnée pour ledit dispositif, configuré pour envoyer à au moins un contrôleur réseau (NSCn0) dudit au moins un réseau gérant ladite au moins une tranche réseau d’une demande (M3) de raccordement dudit dispositif à ladite au moins une tranche réseau ; et un module (3C) d’envoi, configuré pour envoyer un message à chaque dispositif lui indiquant ladite au moins une tranche réseau sélectionnée pour ledit dispositif et utilisable lors de la communication. Contrôleur réseau (NSCn0) d’un réseau comprenant : un module (5A) de réception, apte à recevoir en provenance d’au moins un proxy (Pm0) se trouvant sur un chemin de données relatives à un service et échangées via au moins ledit réseau entre un premier et un deuxième dispositif (UE1,UE2) lors d’une communication impliquant lesdits premier et deuxième dispositifs, une demande (M3) de raccordement d’au moins un desdits dispositifs (UE1) à au moins une tranche réseau (SL(UE1)) gérée par ledit contrôleur réseau (NSCn0) ; et un module (5B) de déclenchement, configuré pour déclencher ledit raccordement. Dispositif (UE1,UE2) de communication, dit premier dispositif de communication, comprenant : un module (4A) de réception, configuré pour recevoir en provenance d’un proxy (Pm0) se trouvant sur un chemin de données relatives à un service et échangées via au moins un réseau avec un deuxième dispositif (UE2,UE1) de communication lors d’une communication impliquant lesdits premier et deuxième dispositif, un message (M6,M7) indiquant audit premier dispositif de communication au moins une tranche réseau (SL(UE1),SL(UE2)) adaptée audit service utilisable par ledit premier dispositif lors de ladite communication et sélectionnée par ledit proxy (Pm0) en fonction d’une politique de sélection donnée ; un module (4B) de communication, configuré pour utiliser au moins une dite tranche réseau (SL(UE1),SL(UE2)) indiquée par le proxy lors de ladite communication avec ledit deuxième dispositif de communication (UE2,UE1). Système (1) comprenant : au moins deux dispositifs (UE2,UE1) de communication selon la revendication 16, échangeant des données relatives à un service lors d’une communication via au moins un réseau ; au moins un proxy (Pm0) selon la revendication 14 situé sur un chemin de tout ou partie desdites données ; et au moins un contrôleur réseau (NSCn0) dudit au moins un réseau selon la revendication 15. Système (1) selon la revendication 17 dans lequel au moins un dit dispositif de communication est un proxy (Pk0) selon la revendication 14.