FR 3155398 A1 20250516 FR 2312513 A 20231115 Procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service, et dispositifs électroniques associés L’invention concerne un procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service entre un premier dispositif électronique et un deuxième dispositif électronique via un réseau de télécommunication supportant une pluralité de tranches réseau. Le procédé comprend les étapes suivantes mises en œuvre par le deuxième dispositif électronique : une obtention d’une donnée représentative de tranches réseau supportées par le réseau et accessibles par le premier dispositif électronique ; une sélection de tranches réseau accessibles par les premier et deuxième dispositifs électroniques et compatibles avec une fourniture du service, et d’une politique de gestion des flux de la communication ; et, une transmission, à destination du premier dispositif électronique, d'une donnée représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées pour application, par le premier dispositif électronique, à cette communication. Figure pour l’abrégé : Fig. 1A. Procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service, et dispositifs électroniques associés La présente invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service entre un premier dispositif électronique et un deuxième dispositif électronique. Elle concerne également un procédé de configuration d’une communication entre les premier et deuxième dispositifs électroniques, ainsi que ces premier et deuxième dispositifs électroniques. Afin de s'adapter à la croissance continue et toujours plus rapide du trafic de données émises par les systèmes de télécommunications, différentes technologies sont aujourd'hui mises en œuvre, et font encore l'objet de perfectionnements en vue d'une exploitation optimale dans les années à venir. L’architecture des réseaux de télécommunications mobiles actuellement déployés ou en cours de déploiement est en particulier définie par le consortium de standardisation connu sous le nom de 3GPP (Third Generation Partnership Project). C’est le cas notamment des réseaux mobiles dits de deuxième génération ("2G ou GSM"), de troisième génération ("3G"), de quatrième génération ("4G") et de cinquième génération ("5G"). Jusqu’à la quatrième génération, les architectures de réseaux mobiles définies par le consortium 3GPP reposent le plus souvent sur des équipements spécifiques, dédiés à des fonctions précises, que ce soit au niveau du réseau d’accès ou du cœur de réseau, notamment en ce qui concerne la transmission de paquets en provenance ou à destination d’un terminal mobile. Le manque de flexibilité et d’évolutivité inhérent à ce type d’architecture a conduit le consortium 3GPP à envisager l’adoption d’architectures plus flexibles pour la génération dite « 5G » (pour cinquième génération) de réseaux mobiles, notamment afin de pouvoir répondre rapidement à des demandes extrêmement diverses en termes de trafic et/ou de qualité de service. Pour répondre à ces contraintes diverses, une architecture de réseaux mobiles 5G peut reposer notamment sur le concept de SBA ("Service-Based Architecture", en anglais), sur la virtualisation de fonctions réseaux et sur un découpage du réseau de télécommunications 5G en sous-réseaux logiques ("network slicing" selon la terminologie anglo-saxonne). Cette technique de découpage d'un réseau est notamment décrite dans la spécification technique 3GPP TS 23.501 v18.3.0, publiée en septembre 2023. Elle permet à l’opérateur d’un réseau de créer des sous-réseaux logiques sur mesure, généralement dédiés à l'acheminement du trafic émis et reçu par des terminaux mobiles, et reposant sur une même infrastructure de réseau physique. Ces sous-réseaux logiques appelés "tranches réseau" ("network slices" selon la terminologie anglo-saxonne) permettent à un client d’accéder à un service en s’appuyant à la fois sur des fonctions réseaux virtualisées qui peuvent être activées, désactivées et paramétrées en fonction des besoins, mais également en s'appuyant sur des fonctions réseaux déployées sur une infrastructure de réseau physique. Pour chaque tranche réseau, ces différents types de fonctions réseaux sont alors configurés pour pouvoir satisfaire les exigences des services supportés par la tranche réseau qui supporte de telles fonctions et qui correspondent typiquement aux services souscrits par les utilisateurs de cette tranche. A priori, les tranches réseau sont contrôlées de manière indépendante. Chaque tranche est généralement adaptée à une utilisation spécifique, et présente donc des caractéristiques propres en matière de qualité de service (par exemple en termes de latence, de débit, de temps de transit unidirectionnel), de sécurité et/ou de capacité. Ce découpage permet à un opérateur de télécommunications d’offrir différents niveaux de service répondant à différents accords de niveau de service ("Service Level Agreement" selon la terminologie anglo-saxonne). Ainsi, le consortium 3GPP a défini des types de tranches susceptibles de répondre à autant de besoins différents tels que le domaine des services mobiles à large bande passante ("enhanced Mobile Broadband", eMBB), le domaine de l’Internet des objets (IoT), le domaine des communications ultra-fiables à faible latence ("UltRa-Reliable Low Latency Communications, URLLC) et celui des véhicules connectés (Vehicle-to-Everything, V2X). Le choix de concevoir et de déployer un ou plusieurs types particuliers de tranches est notamment conditionné par la nature du trafic généré par les applications utilisées ou les services souscrits par un utilisateur du réseau supportant des tranches. Par exemple, un service dit "immersif" qui exploite des techniques de réalité augmentée ou de réalité virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données. Un tel service immersif est donc un client "naturel" d’une tranche de type URLLC. La conception et le déploiement de tranches réseau, est une activité complexe à mettre en œuvre, car elle nécessite de prendre en compte de multiples paramètres de configuration. En outre, pour garantir qu’un trafic de paquets de données soit acheminé correctement au sein d’une ou plusieurs tranches réseau, ledit trafic doit faire l’objet d’une habilitation. Une telle habilitation repose typiquement sur des règles de classification de trafic. Ces règles sont appliquées en entrée d’un réseau/sous-réseau qui supporte la ou les tranches concernées, plus particulièrement par un ou plusieurs nœuds de périphérie). Or la conception de telles règles de classification de trafic et leur application par ces nœuds de périphérie participent aussi très largement à la complexité globale de réalisation et de bonne exploitation d’un réseau supportant des tranches réseau. La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permet à des dispositifs de s’accorder sur les tranches réseau qu’ils peuvent utiliser pour établir une communication. À cet effet, et selon un premier aspect, l’invention concerne un procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service entre un premier dispositif électronique et un deuxième dispositif électronique via au moins un réseau de télécommunication supportant une pluralité de tranches réseau, le procédé comprenant les étapes suivantes mises en œuvre par le deuxième dispositif électronique : une obtention d’une donnée représentative de tranches réseau supportées par ledit au moins un réseau et accessibles par le premier dispositif électronique ; une sélection de tranches réseau accessibles par les premier et deuxième dispositifs électroniques et compatibles avec une fourniture du service, et d’une politique de gestion des flux de la communication via les tranches réseau sélectionnées ; une transmission, à destination du premier dispositif électronique, d'une donnée représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées pour application, par le premier dispositif électronique, à cette communication. Ce procédé de contrôle d’une communication offre l'avantage de permettre à l’un des dispositifs impliqués dans une communication en vue d'accéder à un service, de contrôler la ou les tranches réseau devant être utilisées pour accéder à ce service, mais également de négocier une politique de gestion des flux de cette communication. De cette manière, il n'est plus nécessaire d'établir de règles de trafic relatives à une quelconque habilitation qui soient cohérentes les unes avec les autres. Par "communication", on entend tout échange d'information entre deux dispositifs électroniques, par exemple un émetteur ou un dispositif source à l’origine de la communication et un récepteur ou un dispositif destinataire, à l'aide de signaux produits par les dispositifs électroniques. Cette information est typiquement échangée au travers d'un ou plusieurs flux de données, chaque flux correspondant à une séquence de signaux cohérents codés numériquement pour transmettre cette information sous forme de paquets de données. Une communication peut engendrer l'établissement d'une ou plusieurs sessions. De façon générale, une session est définie comme une association identifiée généralement par le 4-uplet (adresse source, numéro de port source, adresse destination, numéro de port destination) ou par des identifiants de connexion (CID, « Connection Identifier ») au cours de laquelle les deux dispositifs communicants échangent des données (par ex. un dispositif électronique réalise des opérations au service d'un client). Plusieurs sessions peuvent être utilisées au titre d’une même communication. Dans certains contextes tels que MPTCP (acronyme de Multi-Path TCP), ces sessions sont appelées des « sous-sessions » (encore appelées « subflows »). Aucune hypothèse n’est faite quant au dispositif (premier ou deuxième dispositif) à l’origine de la communication permettant d’accéder au service. Ainsi, dans des modes particuliers de mise en œuvre, le premier dispositif est le dispositif à l’origine de la communication pour accéder au service, désigné ci-après par « dispositif de demande d’accès au service » (resp. un dispositif intermédiaire auquel est connecté un tel dispositif), et le deuxième dispositif électronique est un dispositif impliqué dans la gestion du service, désigné ci-après par « dispositif de gestion du service », configuré pour contrôler la communication au cours de laquelle sont échangées des données relatives à ce service. En variante, dans d’autres modes particuliers de mise en œuvre, le premier dispositif correspond au dispositif de gestion du service, le deuxième dispositif électronique correspond au dispositif à l’origine de la communication pour accéder au service, dit « dispositif de demande d’accès au service », (resp. à un dispositif intermédiaire auquel est connecté un tel dispositif), et c'est ce dispositif à l’origine de la communication (resp. à ce dispositif intermédiaire) qui est alors configuré pour contrôler la communication au cours de laquelle sont échangées des données relatives à ce service. Par "contrôle de la communication", on entend l'application, à un ou plusieurs des flux de cette communication, de paramètres ou de traitements particuliers, telle que l'utilisation de tranches réseaux spécifiques pour échanger des données, tout en appliquant une politique de gestion de flux. Comme évoqué ci-après, cette politique de gestion de flux est définie en fonction des capacités du premier dispositif électronique, mais également en fonction de contraintes propres au service auquel ce premier dispositif électronique souhaite accéder. Ainsi, l’invention permet un accès au service de façon adaptée, c'est-à-dire en considérant les exigences en termes de qualité de service requise pour la fourniture de ce service, mais également en considérant les contraintes propres au(x) dispositif(s) souhaitant accéder à ce service (nommé ci-après "dispositif de demande d'accès au service"). Dans des modes particuliers de mise en œuvre, ce service est fourni par le deuxième dispositif électronique. En variante, ce service est fourni par un troisième dispositif distinct des premier et deuxième dispositifs électroniques. Dans ce cas, la communication selon l'invention inclut un premier échange entre les premier et deuxième dispositifs (par exemple au travers d'une première sous-session), puis un deuxième échange entre les premier et troisième dispositifs (par exemple au travers d'une deuxième sous-session). De manière générale, on considère que les étapes d’un procédé ne doivent pas être interprétées comme étant liées à une chronologie particulière. Dans des modes particuliers de mise en œuvre, le procédé de contrôle d’une communication peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le premier dispositif est un dispositif de demande d’accès à un service, le deuxième dispositif électronique est un dispositif de gestion du service, et l'obtention de la donnée représentative de tranches réseau accessibles par le premier dispositif inclut la réception, par le dispositif de gestion, de ladite donnée en provenance du dispositif de demande d’accès à un service. Dans des modes particuliers de mise en œuvre, le procédé selon l'invention comprend en outre un échange, entre les premier et deuxième dispositifs, de leurs capacités respectives à utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau et à appliquer une politique de gestion des flux caractéristiques de communications et qui sont acheminés dans ladite au moins tranche réseau sélectionnée. Dans des modes particuliers de mise en œuvre, le premier dispositif est un dispositif de demande d’accès à un service ou un dispositif intermédiaire auquel est connecté le dispositif de demande d’accès à un service, le deuxième dispositif électronique est un dispositif de gestion du service, et le procédé comprend en outre les étapes suivantes, mises en œuvre par le deuxième dispositif électronique : une réception d’une donnée, dite première donnée, en provenance du premier dispositif électronique et représentative d’une capacité du premier dispositif électronique à utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau et à appliquer une politique de gestion des flux de la communication sélectionnée ; et, une transmission, à destination du premier dispositif électronique, d'une donnée, dite deuxième donnée, représentative d’une capacité du deuxième dispositif électronique à sélectionner au moins une tranche réseau compatible pour accéder au service et une politique de gestion des flux de la communication. Ces échanges entre les premier et deuxième dispositifs électroniques leur permettent de s'assurer qu'ils sont conformes à l'invention, et plus précisément que le premier dispositif électronique est en mesure de configurer une communication conformément aux instructions du deuxième dispositif électronique, et que le deuxième dispositif électronique est en mesure de sélectionner une configuration adaptée en fonction du service auquel souhaite accéder le premier dispositif, mais également en fonction des capacités du premier dispositif électronique. Dans des modes particuliers de mise en œuvre, la première donnée est transmise au travers d’un message, dit premier message, correspondant à une demande d’établissement d’une communication ou à une demande d’ajout d’une sous-session additionnelle à une session préétablie. Dans des modes particuliers de mise en œuvre, la politique de gestion des flux comprend au moins un protocole de transport supporté par le premier dispositif électronique et permettant d’établir la communication sur des chemins multiples. Dans ce cas, l'utilisation des tranches réseau et l’application de la politique de gestion comprend une utilisation d'au moins une des tranches réseau sélectionnées et repose sur ce au moins un protocole de transport permettant d’établir une communication sur des chemins multiples pour accéder audit service. Ainsi, l'accès audit service est mis en œuvre en exploitant le protocole de transport sélectionné pour une communication empruntant la ou les tranches réseau sélectionnées, et ce, entre le premier dispositif et le deuxième dispositif. Dans des modes particuliers de mise en œuvre, le au moins un protocole de transport utilisé est un parmi : le protocole TCP assorti de l'option "Multipath TCP", le protocole UDP assorti d'une extension "Multipath UDP", le protocole QUIC assorti de l'extension "Multipath QUIC" et le protocole MDCCP "Multipath Datagram Congestion Control Protocol". Dans des modes particuliers de mise en œuvre, le premier dispositif est un dispositif de demande d’accès à un service ou un dispositif intermédiaire auquel est connecté le dispositif de demande d’accès à un service, le deuxième dispositif électronique est un dispositif de gestion du service, et le procédé comprend en outre : une transmission, par le dispositif de demande d’accès à un service ou le dispositif intermédiaire, et à destination du dispositif de gestion, de données relatives à une pluralité de protocoles de transport permettant d’établir une communication sur des chemins multiples et pouvant être exploités par ledit dispositif de demande d’accès à un service ou par ledit dispositif intermédiaire ; une sélection, par le dispositif de gestion et parmi la pluralité de protocoles de transport permettant d’établir une communication sur des chemins multiples, d’au moins un protocole de transport adapté à la fourniture dudit service, la politique de gestion des flux sélectionnée incluant ledit au moins un protocole de transport ; et, une transmission, par le dispositif de gestion et à destination du dispositif de demande d’accès à un service ou du dispositif intermédiaire, d’une donnée d’identification dudit au moins un protocole de transport sélectionné pour accéder audit service. Dans des modes particuliers de mise en œuvre, la politique de gestion des flux comprend au moins un mécanisme d'ordonnancement de paquets de données à appliquer par le premier dispositif électronique à ladite communication. Dans ce cas, l'utilisation des tranches réseau et l’application de la politique de gestion comprend une utilisation d'au moins une des tranches réseau sélectionnées et dudit au moins un mécanisme d'ordonnancement de paquet de données pour accéder audit service. Dans des modes particuliers de mise en œuvre, le premier dispositif est un dispositif de demande d’accès à un service ou un dispositif intermédiaire auquel est connecté le dispositif de demande d’accès à un service, le deuxième dispositif électronique est un dispositif de gestion du service, et le procédé comprend en outre : une transmission, par le dispositif de demande d’accès à un service ou le dispositif intermédiaire et à destination du dispositif de gestion, de données relatives à une pluralité de mécanismes d'ordonnancement de paquets de données applicables par ledit dispositif de demande d’accès à un service ou ledit dispositif intermédiaire ; une sélection, par le dispositif de gestion et parmi la pluralité de mécanismes d'ordonnancement de paquets de données, d’au moins un mécanisme d'ordonnancement de paquets de données adapté à la fourniture dudit service, la politique de gestion des flux sélectionnée incluant ledit au moins un mécanisme d'ordonnancement de paquets de données ; et une transmission, par le dispositif de gestion et à destination du dispositif de demande d’accès à un service ou du dispositif intermédiaire, d’une donnée d’identification dudit au moins un mécanisme d'ordonnancement de paquets de données sélectionné pour accéder audit service. Dans des modes particuliers de mise en œuvre, la politique de gestion des flux comprend une contrainte sur une direction d'au moins un flux de la communication au travers d'au moins une des tranches réseau sélectionnées. Dans des modes particuliers de mise en œuvre, la politique de gestion des flux comprend une contrainte d'utilisation d'une unique tranche ou d'une pluralité de tranches réseaux connectées entre elles (par exemple des tranches multi-domaines ou « stitched slices » évoquées ci-après). Dans des modes particuliers de mise en œuvre, la donnée représentative des tranches réseau supportées par ledit au moins un réseau et accessibles par ledit premier dispositif électronique inclut au moins un type de tranche réseau et/ou au moins un identifiant de tranche réseau. Dans des modes particuliers de mise en œuvre, la donnée représentative des tranches réseau de la pluralité accessibles par ledit premier dispositif électronique inclut en outre au moins une donnée parmi : un identifiant de réseau, un identifiant de flux, un identifiant d’adresse, un nombre maximal de flux par tranche, une donnée représentative d’une contrainte sur une direction de flux. Dans des modes particuliers de mise en œuvre, le procédé comprend en outre une sélection, par le deuxième dispositif, d'au moins une tranche réseau accessible par ledit deuxième dispositif, et adaptée à la fourniture du service (S), et/ou d’au moins une politique de gestion de flux de la communication à appliquer par ledit deuxième dispositif. Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle précédemment évoqué, lorsque ledit programme est exécuté par un processeur. Selon un troisième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré le programme d’ordinateur selon le deuxième aspect. Selon un quatrième aspect, l'invention concerne un procédé de configuration d’une communication au cours de laquelle sont échangées des données relatives à un service entre un premier dispositif électronique et un deuxième dispositif électronique via au moins un réseau de télécommunication supportant une pluralité de tranches réseau, le procédé comprenant les étapes suivantes mises en œuvre par le premier dispositif électronique : une réception d’une donnée représentative d’au moins une tranche réseau accessible par les premier et deuxième dispositifs électroniques et compatible avec une fourniture du service, en provenance du deuxième dispositif électronique, ladite donnée étant en outre représentative d'une politique de gestion de flux de la communication via ladite au moins une tranche réseau ; et, une application de ladite au moins une tranche réseau et de ladite politique de gestion des flux à la communication. Comme évoqué précédemment, le service peut alors être accédé de façon adaptée, c'est-à-dire en considérant les exigences en termes de qualité de service requise pour la fourniture de ce service, mais également en considérant les contraintes propres au(x) dispositif(s) souhaitant accéder à ce service. Dans des modes particuliers de mise en œuvre, le premier dispositif est un dispositif intermédiaire auquel est connecté un dispositif de demande d’accès au service, et le procédé de configuration comprend en outre, sur requête du dispositif de demande d'accès au service, une étape de transmission, par le dispositif intermédiaire et à destination dudit dispositif de demande d'accès au service, de la donnée représentative des tranches réseau et de ladite politique de gestion des flux. Dans des modes particuliers de mise en œuvre, le procédé de configuration comprend en outre les étapes suivantes mises en œuvre par le dispositif intermédiaire : une réception d'au moins une règle de classification de trafic visant à répartir des données de ladite communication au travers d'au moins une des tranches sélectionnées ; et, une application de ladite au moins une règle, de sorte à associer au moins un flux de ladite communication avec au moins une desdites tranches. Cette caractéristique permet avantageusement d'associer des flux, sous-sessions, etc. avec des tranches. Selon un cinquième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre du procédé de configuration précédemment évoqué, lorsque ledit programme est exécuté par un processeur. Selon un sixième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré le programme d’ordinateur selon le cinquième aspect. Selon un septième aspect, l'invention concerne un dispositif électronique, dit deuxième dispositif électronique, configuré pour mettre en œuvre le procédé de contrôle d’une communication selon le premier aspect. Selon un huitième aspect, l'invention concerne un dispositif électronique, dit premier dispositif électronique, configuré pour mettre en œuvre le procédé de configuration d’une communication selon le quatrième aspect. Dans des modes particuliers de mise en œuvre, ce premier dispositif correspond à un dispositif intermédiaire auquel est connecté un dispositif de demande d'accès à un service. Selon un neuvième aspect, l'invention concerne un système de communication comprenant un premier dispositif électronique selon le huitième aspect, et un deuxième dispositif électronique selon le septième aspect. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux figures annexées qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : FIG. 1 la FIG. 1 est un premier exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre ; FIG. 1 la FIG. 1 est un deuxième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre est mis en œuvre ; FIG. 1 la FIG. 1 est un troisième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre ; FIG. 1 la FIG. 1 est un quatrième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre ; FIG. 2 la FIG. 2 est une vue détaillée d’un réseau mobile 5G supportant des tranches réseau ; FIG. 3 la FIG. 3 représente des modules embarqués dans un deuxième dispositif électronique, selon un exemple de mise en œuvre de l’invention ; FIG. 3 la FIG. 3 représente un exemple d’architecture matérielle d’un deuxième dispositif électronique ; FIG. 4 la FIG. 4 représente des modules embarqués dans un premier dispositif électronique, selon un exemple de mise en œuvre de l’invention ; FIG. 4 la FIG. 4 représente un exemple d’architecture matérielle d’un premier dispositif électronique ; FIG. 5 la FIG. 5 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à un service, selon un premier exemple de mise en œuvre de l’invention ; FIG. 5 la FIG. 5 est une vue détaillée de l’étape d'application des tranches réseau et de la politique de gestion des flux sélectionnées de la FIG. 5 , selon un exemple de mise en œuvre de l’invention ; FIG. 6 la FIG. 6 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à un service, selon un deuxième exemple de mise en œuvre de l’invention ; FIG. 7 la FIG. 7 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de contrôle d'un dispositif intermédiaire impliqué dans une communication au cours de laquelle sont échangées des données relatives à un service, selon un exemple de mise en œuvre de l’invention ; FIG. 8 la FIG. 8 est un exemple de format d’une option PCP (Port Control Protocol) pour transmettre des paramètres relatifs aux tranches réseau accessibles par le dispositif de demande d'accès à un service ; et, FIG. 9 la FIG. 9 est un exemple de format d’une option PCP pour transmettre des règles de classification de trafic. Les termes "premier(s)" (ou première(s)), "deuxième(s)", etc. sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des messages, des dispositifs, etc.) considérés dans les modes de réalisation décrits ci-après, et n’impliquent pas de séquençage particulier, sauf lorsque cela est explicitement indiqué. Les figures 1A à 1D illustrent différentes configurations d’un système de communication comprenant au moins un premier dispositif et un deuxième dispositif conformes à l’invention, et dans lequel un procédé général d'accès à un service est mis en œuvre. Ce procédé d’accès à un service s’appuie sur un procédé de configuration et un procédé de contrôle selon l’invention mis en œuvre respectivement par le premier et par le deuxième dispositif, comme expliqué plus en détail ultérieurement. La FIG. 1 est un premier exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre. Ce système comprend un dispositif (20) de demande d'accès à un service (S) connecté à un réseau de télécommunications (10-1). Le dispositif (20) de demande d'accès à un service (S) supporte le protocole de communication IP. Ce dispositif peut être un terminal utilisateur – prenant par exemple la forme d’un ordinateur portable, d’un assistant personnel, d’un objet connecté, ou un téléphone mobile de type "smartphone" – un routeur, une passerelle domestique, ou encore un décodeur TV, etc. Le système comprend en outre un dispositif (30) de gestion du service (S) prenant par exemple la forme d'un terminal ou d'un serveur distant, et également connecté au réseau de télécommunications (10-1). Tel qu'illustré par la FIG. 1 , ce dispositif (30) de gestion du service (S) est configuré pour fournir un service S. Ce service peut être défini comme un programme informatique directement utilisé pour réaliser une tâche, ou un ensemble de tâches élémentaires d'un même domaine. Il s’agit par exemple d’un service de fourniture d’un contenu multimédia (telle que la vidéo à la demande), un service d’accès à un réseau social ou un service de paiement. Selon un autre mode de réalisation, le service n’est pas déployé sur le dispositif (30) de gestion du service, mais sur un troisième dispositif distinct des dispositifs de demande d’accès à un service et de gestion du service (S). Dans ce cas, le service est par exemple une "fonction service" ou l’une des fonctions service (« Service Function » en anglais) d’une chaîne de fonctions service (« Service Function Chain » en anglais), tel qu’illustré par la FIG. 2 . Dans le cas où le service (S) est fourni par ce troisième dispositif, dans un mode particulier de mise en œuvre, le dispositif (30) de gestion agit comme un relais entre le dispositif (20) de demande d'accès au service, et le troisième dispositif qui fournit le service (S). Le dispositif (30) de gestion peut également agir comme un dispositif de sécurité qui bloque ou autorise sélectivement des paquets de données à accéder au du troisième dispositif. Selon un autre mode de réalisation, le service (S) est déployé sur le dispositif (20) de demande d'accès à un service. Dans le présent mode de réalisation, et à des fins de simplification de la description, il est considéré que le système de communication comporte un unique dispositif (20) de demande d’accès à un service, ainsi qu’un unique dispositif (30) de gestion offrant un unique service ( ), ces deux dispositifs étant connectés au travers d'un réseau. Il convient cependant de noter qu'aucune hypothèse n’est faite quant au nombre de dispositifs (20) de demande d’accès à un service, au nombre de dispositifs (30) de gestion, au nombre de services ( ), ou au nombre de réseaux considérés. Les développements qui suivent sont en effet généralisables sans difficulté par la personne du métier au cas où plus d’un dispositif (20) de demande d’accès à un service, plus d’un dispositif (30) de gestion, plus d'un service ( ) et plus d'un réseau sont considérés. Tel qu’illustré par la FIG. 1 , les dispositifs (20, 30) de demande d’accès à un service et de gestion sont tous les deux connectés à un réseau de télécommunications 10-1. Le réseau de télécommunication 10-1 comprend dans cet exemple plusieurs sous-réseaux (ou "segments" ou "domaines") : un réseau d’accès radio (RAN), un réseau cœur (CN), et un réseau de transit (TN) connecté au réseau d’accès radio (RAN) et au réseau cœur (CN). Les réseaux radio (RAN), de transit (TN) et cœur (CN) composent, dans le mode de réalisation décrit ici, le réseau de télécommunications 10-1 auquel est connecté le dispositif (20) de demande d’accès à un service, et sont aptes à communiquer entre eux. Pour la suite de la description, on considère de manière non limitative que ce réseau de télécommunications 10-1 est un réseau mobile de type 5G. Le réseau d’accès radio (RAN) supporte une ou plusieurs tranches réseau RAN_SL, le réseau de transit (TN) une ou plusieurs tranches TN_SL, et le réseau cœur (CN) une ou plusieurs tranches TN_CN. De façon générale, il importe de noter qu’aucune hypothèse n’est faite quant à la nature des tranches déployées dans un réseau, leur nombre, et les chemins entre des instances ou sous-instances de tranches. Les fonctions utilisées par ces tranches sont décrites plus en détail en référence à la FIG. 2 . Le réseau d’accès radio (RAN) est par exemple un réseau virtuel V-RAN ("Virtual-RAN"). Un réseau d'accès radio virtuel (V-RAN) est un réseau d’accès radio (RAN) dont les fonctions réseau sont déployées comme des instances virtualisées situées à différents endroits du réseau, par exemple en fonction d’une stratégie de déploiement de l’opérateur de télécommunications. Cette approche offre l’avantage de limiter l’utilisation d’équipements coûteux, et facilite la création des tranches réseau qui coexistent simultanément sur les mêmes équipements matériels. Il convient toutefois de préciser que l'invention reste applicable à d'autres types de réseau de télécommunications 10-1, comme par exemple un réseau mobile 4G, un réseau B5G (acronyme de "Beyond 5G"), un réseau 6G, un réseau WLAN (tel qu’un réseau Wi-Fi), un réseau IP/MPLS, etc. La FIG. 1 est un deuxième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre. Ce système comprend un dispositif (20) de demande d’accès à un service (S) ainsi qu'un dispositif (30) de gestion du service (S). À la différence du système de la FIG. 1 , les dispositifs (20, 30) de demande d’accès à un service et de gestion du service (S) sont connectés entre eux au travers d'une pluralité de réseaux de télécommunications, 10-1, 10-2. Le premier réseau de télécommunication 10-1 correspond par exemple à celui précédemment décrit en référence à la FIG. 1 , et le deuxième réseau de télécommunications 10-2 est un réseau informatique local sans fil ("Wireless Local Area Network", WLAN, selon la terminologie anglo-saxonne) qui supporte également une pluralité de tranches. Les dispositifs (20, 30) de demande d’accès à un service et de gestion d'un service (S) sont donc capables d’activer et d’exploiter plusieurs interfaces réseau logiques liées à une ou plusieurs interfaces réseau physiques. De tels dispositifs sont généralement dits "multi-interfaces" ("Multi-InterFace", MIF, selon la terminologie anglo-saxonne). Plusieurs adresses IP peuvent ainsi être attribuées à un dispositif MIF pour qu’il puisse se connecter simultanément ou pas à plusieurs réseaux de télécommunication (par exemple accessibles via une interface Wi-Fi, une interface optique ou une interface 5G du dispositif). Ces adresses IP peuvent : appartenir à une même famille d’adresses ou à des familles d'adresses distinctes (ex. IPv4, IPv6 ou les deux) ; avoir des durées de vie différentes. Ainsi, une adresse IPv6 n’est par exemple utilisée par le dispositif (20) de demande d’accès à un service que le temps d’une communication, alors qu’une adresse IPv4 peut être affectée de manière permanente à l’interface de raccordement du dispositif (20) de demande d’accès à un service à un réseau de télécommunication, par exemple une interface de type Ethernet ; avoir des portées (ou "scope" selon la terminologie anglo-saxonne) différentes. Ainsi, une première adresse IPv4 privée n’est par exemple utilisée que dans un environnement domestique parce que non routable sur l’Internet, une deuxième adresse est de type IPv6 unique de portée locale ("Unique Local Address"), et une troisième adresse est de type IPv6 de portée globale ("Global Unicast Address") ; et être affectées à une même interface réseau logique ou à différentes interfaces réseau logiques. Il importe également de noter que l’aspect "multi-interfaces" d’un dispositif électronique est volatile, car la capacité à utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de la localisation du dispositif électronique, ou d’autres facteurs. Le dispositif électronique "multi-interfaces" peut notamment exploiter la pluralité d’interfaces dont il dispose lors de l’établissement d’une communication simple (c’est-à-dire, une communication établie le long d’un chemin unique avec un correspondant donné), voire après l’établissement d’une communication simple. On notera également qu’un dispositif électronique "multi-interfaces" ne sait pas a priori s’il lui est possible d’utiliser plusieurs chemins distincts pour établir une communication avec un correspondant donné. Les dispositifs (20, 30) de demande d’accès à un service et de gestion d'un service (S) étant "multi-interfaces", ils bénéficient d’un accès "hybride" puisque différentes technologies d’accès aux réseaux peuvent être exploitées, par exemple pour lui permettre d’agréger la bande passante ou d’améliorer la disponibilité de l’accès à ce(s) réseau(x). On rappelle à cet égard que, dans le domaine des réseaux, la notion "d’agrégation" se réfère au regroupement de plusieurs chemins associés à autant d’interfaces réseau logiques d'un dispositif MIF, comme s'il s'agissait d'un seul chemin associé à une seule interface réseau. Les flux d'une même communication peuvent alors transiter à travers cette pluralité de chemins. L'agrégation de chemins est par exemple réalisée dans le but d'accroître le débit au-delà des limites d'un seul chemin, mais également afin d’appliquer les mêmes procédures d’exploitation à l’ensemble des chemins ainsi agrégés (notion de "fate sharing" en anglais). L’agrégation de chemins permet également de faire en sorte que d’autres interfaces réseau prennent le relais si l’un des chemins devient indisponible, par exemple en cas de rupture de câble ou de panne de liaison radio, en vertu d’un principe de résilience qui permet d’améliorer la disponibilité de l’accès au réseau. L’agrégation de chemins peut s’appliquer à tout ou partie du trafic acheminé le long de ces chemins, y compris du trafic IP. L'agrégation de chemins peut également être utilisée pour répartir le trafic sur plusieurs chemins. Dans ce cas, la répartition de trafic entre les chemins qui font l’objet d’un agrégat dépend de divers paramètres. La répartition de trafic dépend par exemple du type de trafic, tel que le trafic TCP (initiales des mots anglais "Transmission Control Protocol" signifiant "Protocole de Contrôle de Transmission") ou le trafic UDP (initiales des mots anglais "User Datagram Protocol" signifiant "Protocole de Datagramme Utilisateur"), ou encore d’un ensemble de politiques d’ingénierie de trafic, de qualité de service et/ou de sécurité mises en place par le ou les opérateurs en charge du ou des réseaux de télécommunication supportant ces chemins agrégés. Ainsi, divers modes d’agrégation peuvent être envisagés, parmi lesquels les trois modes suivants : le mode de repli ("backup" en anglais) qui consiste à utiliser des chemins secondaires en cas d’indisponibilité des chemins primaires, et ce, afin d’améliorer la disponibilité du réseau et de facto des services accessibles au travers du réseau, la robustesse et la fiabilité des communications IP établies sur les différents chemins; le mode associatif ("bonding" en anglais) qui consiste à utiliser les ressources associées à tout ou partie des chemins disponibles, les flux IP associés à un même service (ou application) pouvant être répartis entre plusieurs chemins. Le choix d’exploiter l’intégralité des chemins, ou seulement une partie d’entre eux, peut par exemple être conditionné par la nature du trafic ou les caractéristiques de disponibilité ou de fiabilité associées à chaque chemin, lesquelles peuvent varier fortement d’un chemin à l’autre ; et le mode dit de "confort" qui est similaire au mode associatif, si ce n’est que le trafic caractéristique d’un service donné n’est pas réparti entre plusieurs chemins, mais envoyé sur un unique chemin. Ces différents modes ne sont pas mutuellement exclusifs. Ils ne sont pas non plus spécifiques à un type particulier de trafic. Ainsi, l’un ou l’autre de ces modes peut être mis en place indépendamment de la nature du trafic qui est acheminé le long des chemins agrégés. Le dispositif (20) de demande d’accès à un service (S) peut également être configuré pour s’abstenir d’exploiter un mécanisme d’agrégation de chemins déployé dans certains réseaux de télécommunication. En effet, pour éviter de trop solliciter un premier réseau tel que le réseau mobile 10-1, le dispositif (20) de demande d’accès à un service (S) est par exemple configuré pour ne passer des communications vocales que via un deuxième réseau, tel que le réseau sans fil local WLAN (10-2), à certaines heures de la journée. Selon un autre exemple, le dispositif (20) de demande d’accès à un service (S) est configuré pour ne pas activer d’agrégation dans certaines conditions de fonctionnement, par exemple en cas de surcharge des concentrateurs réseau, tels que des équipements OLT ("Optical Line Termination") dans un réseau d’accès fibre reposant sur une architecture PON ("Passive Optical Network" ou "réseau optique passif"). La FIG. 1 est un troisième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre. Le système de communication comprend un dispositif (20) de demande d’accès à un service (S) et connecté à un dispositif intermédiaire (50). Ce dispositif intermédiaire (50) de type MIF, dans l’exemple envisagé ici, est connecté à un dispositif (30) de gestion d'un service au travers d'une pluralité de réseaux, tels que les réseaux 10-1 et 10-2 décrits en référence à la FIG. 1 . Le système de communication de la FIG. 1 se distingue donc de celui de la FIG. 1 par le fait que le dispositif (20) de demande d’accès à un service (S) n’est pas directement connecté aux réseaux de télécommunication 10-1 et 10-2, mais qu'il est indirectement connecté à ces réseaux au travers dudit dispositif intermédiaire (50). Ainsi, le dispositif (20) de demande d’accès à un service (S) ne nécessite pas d'activer une pluralité d'interfaces réseaux pour qu'une communication multi-chemins soit établie. Au sens de l’invention, on appelle "dispositif intermédiaire" un équipement localisé dans le réseau et agissant au nom d’un ou de plusieurs autres dispositifs. Ce "dispositif intermédiaire" correspond par exemple à un terminal utilisateur – tel qu'un ordinateur portable, un assistant personnel, un objet connecté, ou un téléphone mobile de type "smartphone" –, ou à un équipement installé dans l’environnement d'un client (particulier, entreprise) et qui est raccordé à l'infrastructure d'un opérateur/fournisseur de service (désigné par "Customer Premises Equipment", CPE, selon la terminologie anglo-saxonne), tel qu'un routeur ou une passerelle domestique. Le déploiement d’un ou plusieurs dispositifs intermédiaires dans le réseau permet au(x) dispositif(s) connecté(s) à ce(s) dispositif(s) intermédiaire(s) de bénéficier d’un usage optimisé des ressources réseau disponibles. Ce déploiement de dispositifs intermédiaires permet également d’établir des communications sur des chemins multiples dans un délai réduit, sans préjuger des capacités du ou des destinataires avec lesquels un dispositif électronique souhaite communiquer. La FIG. 1 est un quatrième exemple de système de communication dans lequel un procédé général d'accès à un service est mis en œuvre. La FIG. 1 se distingue de la FIG. 1 par le fait que le dispositif (20) de demande d’accès à un service est un dispositif "multi-interfaces" à la fois connecté au dispositif intermédiaire (50), mais également connecté au dispositif (30) de gestion du service (S) au travers d'un réseau de télécommunications 10-3 supportant plusieurs tranches réseau. Ainsi, dans ce quatrième exemple, le dispositif (20) de demande d'accès à un service, le dispositif (30) de gestion et le dispositif intermédiaire (50) sont tous les trois des dispositifs multi-interfaces. Bien entendu ces exemples ne sont donnés qu’à titre illustratif et d’autres configurations peuvent être envisagées. La FIG. 2 est une vue détaillée d'un réseau mobile 5G supportant des tranches réseau, tel que le réseau 10-1 des figures 1A-1D. Comme évoqué précédemment, pour répondre à des contraintes diverses par exemple en termes de qualité de service, le consortium 3GPP a notamment spécifié comment un réseau de télécommunications 5G peut supporter des "tranches réseau". En particulier, le consortium 3GPP a défini la notion "d’instance de tranche réseau". Chaque instance se décompose en sous-instances ("Sub-Network Instance" selon la terminologie anglo-saxonne). Ainsi, une instance de tranche réseau est par exemple composée d’une sous-instance de réseau d’accès RAN et d’une sous-instance de réseau cœur CN. De cette manière, un fournisseur de service peut s’appuyer sur des tranches (notamment des sous-instances de tranches) mises en place dans différents réseaux (RAN, CN) pour fournir un service dont le trafic sera acheminé dans une instance de tranche de réseau composée de sous-instances de tranches déployées dans les différents réseaux précédemment évoqués. De façon plus générale, lorsque des tranches réseau (par ex. des instances de tranches réseau) s'appuient sur d’autres tranches réseau (par ex. des sous-instances de tranches réseau) par exemple afin d’offrir des services à valeur ajoutée, on parle alors parfois de "tranche multi-domaines" (ou "stitched slices" ou "hierarchical slices" en anglais). Les interfaces de raccordement entre tranches adjacentes ("Attachment Circuits" en anglais) sont par exemple gérées en utilisant des mécanismes tels que ceux décrits dans le document "YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)", draft-boro-opsawg-teas-attachment-circuit-07, M. Boucadair, Ed. & Al., publié le 10 juillet 2023 par l’IETF (acronyme de "Internet Engineering Task Force"). Chacun des sous-réseaux (par ex. RAN, CN) supporte des tranches réseau dont l’ingénierie et l’exploitation sont propres audit sous-réseau. Ainsi, une tranche ( ) déployée sur un réseau cœur (CN) fait appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G. Autrement dit, chaque sous-réseau (ou "domaine") utilise des technologies déployées dans ce sous-réseau pour la réalisation des tranches réseau qui le composent. La réalisation d’une tranche réseau (par ex. d’une instance de tranche réseau) qui s’étend sur plusieurs sous-réseaux (ou domaines) n’est pas conditionnée par la disponibilité ou l’activation des mêmes technologies utilisées pour la réalisation des sous-instances de tranches propres à chaque sous-réseau. À titre d’exemple, un premier sous-réseau peut gérer des communications établies selon la suite de protocoles IPsec (acronyme de "Internet Protocol Security"), un deuxième sous-réseau peut utiliser une ingénierie de réseau privé virtuel de niveau réseau ("Layer 3 VPN", L3VPN, selon la terminologie anglo-saxonne) combiné avec des mécanismes d’ingénierie de trafic ("Traffic Engineering", TE, selon la terminologie anglo-saxonne), et un troisième sous-réseau peut utiliser les ressources du routage par segments reposant sur le protocole IPv6 ("Segment Routing IPv6", SRv6, selon la terminologie anglo-saxonne) pour acheminer le trafic dans les tranches déployées dans ce troisième sous-réseau. La figure 2 illustre un exemple de réseau de communication comprenant un réseau d’accès RAN supportant trois sous-instances de tranches réseau et un réseau cœur CN supportant également trois sous-instances tranches réseau . Dans le présent mode de réalisation illustré par la FIG. 2 , et à des fins de simplification de la description, il est considéré que le réseau de télécommunication ne comprend qu’un réseau d’accès (RAN) et un réseau cœur (CN), mais les développements qui suivent sont généralisables sans difficulté par l'homme du métier au cas où le réseau de télécommunication comprend également un ou plusieurs réseaux de transit (TN). Ainsi, les mécanismes décrits dans le document "A Realization of IETF Network Slices for 5G Networks Using Current IP/ MPLS Technologies", draft-ietf-teas-5g-ns-ip-mpls-00, Krzysztof Grzegorz Szarkowicz & Al., publié par l’IETF le 27 juin 2023 peuvent par exemple être mis en œuvre pour déployer des tranches de réseau dans ce réseau de transit (TN). Par ailleurs, il importe également de rappeler qu’aucune hypothèse n’est faite quant à la nature des tranches (par ex. des instances de tranche et des sous-instances de tranches) déployées dans un réseau, leur nombre, et les liens entre des sous-instances de tranches (par ex. entre RAN et TN, ou entre TN et CN). Tel qu’illustré par la figure 2, la sous-instance du réseau d’accès RAN, et les sous-instances et du réseau cœur (CN) appartiennent à une même instance de tranche réseau à laquelle est connectée un terminal utilisateur 20-1. Cette instance de tranche réseau est par exemple dédiée à des opérateurs de réseau mobile virtuel ("Mobile Virtual Network Operators", MVNO, selon la terminologie anglo-saxonne) qui ne possèdent pas de concession de spectre de fréquences ni d'infrastructure de réseau radio propres, et qui, pour offrir des services de communications mobiles à leurs clients, s’appuient sur les infrastructures d’un ou plusieurs opérateurs de réseau mobile. Le réseau de communication comprend en outre une instance de tranche réseau à laquelle est connecté un terminal utilisateur 20-2. Cette instance de tranche réseau est par exemple dédiée aux services à large bande passante pour une connectivité sans fil (eMBB). Cette instance comprend une sous-instance du réseau d’accès RAN, ainsi que la sous-instance instance précédemment évoquée. Autrement dit, la sous-instance est partagée entre l’instance de tranche de réseau et l’instance de tranche réseau . Enfin, le réseau de télécommunication comprend une instance de tranche réseau à laquelle est connecté un capteur 20-3. Cette instance de tranche réseau est par exemple dédiée aux objets et terminaux équipés de capteurs et configurés pour émettre et recevoir des données. Cette instance comprend une sous-instance du réseau d’accès RAN, ainsi qu’une sous-instance instance du réseau cœur CN. Une tranche réseau peut impliquer une ou plusieurs "fonctions service" ("Service Functions" selon la terminologie utilisée dans le document "Service Function Chaining (SFC) Architecture", RFC7665, publié en octobre 2015 par l’IETF) également nommées fonctions réseaux ("Network Functions" selon la terminologie utilisée par le consortium 3GPP). Une sous-instance de tranche réseau d’un réseau d‘accès (RAN) implique par exemple : une fonction DU ("Distributed Unit" ou "unité distribuée") configurée pour gérer les sous-couches de la couche liaison de données, soit la sous-couche MAC (acronyme de l’anglais "Media Access Control") et la sous-couche RLC (acronyme de l’anglais "Radio Link Control") ; et une fonction CU ("Centralized Unit" ou "unité centralisée") configurée pour gérer les sous-couches PDCP (acronyme de l’anglais "Packet Data Convergence Protocol"), SDAP (acronyme de l’anglais "Service Data Adaptation Protocol") et RRC (acronyme de l’anglais "Radio Resource Control"). Une sous-instance de tranche réseau d’un réseau cœur (CN) implique une fonction UPF (acronyme de l’anglais "User Plane Function"), telle que par exemple définie par la spécification 3GPP TS 23.501 "System architecture for the 5G System (5GS)", version 18.2.2, publiée le 7 juillet 2023. Cette fonction UPF agit en quelque sorte comme une passerelle entre le réseau d’accès radio (RAN) et un réseau de données, tel que l’Internet ou un réseau local/privé. Il importe également de noter qu’une même fonction service peut être fournie par une ou plusieurs instances de service. Par ailleurs, des chaînes de service ("Service Function Chain", SFC, selon la terminologie anglo-saxonne) peuvent être mises en place afin de faciliter l’acheminement de trafics de différentes natures au sein d’une tranche. Tel qu’illustré par la figure 2, chaque sous-instance de tranche réseau et comprend une chaîne de service SFC. La sous-instance de tranche réseau comprend une chaîne composée de fonctions réseau virtuelles ("Virtual Network Function", , selon la terminologie anglo-saxonne), et la sous-instance de tranche réseau comprend une chaîne composée notamment de fonctions réseau virtuelles . Dans la suite, aucune hypothèse n’est faite quant à la structuration en chaînes de service du service S ou aux tranches réseau sollicitées. La FIG. 3 représente des modules embarqués dans un deuxième dispositif électronique, selon un exemple de mise en œuvre de l’invention. Ce deuxième dispositif électronique correspond par exemple au dispositif (30) de gestion d'un service, au dispositif (20) de demande d’accès à un service ou au dispositif intermédiaire (50) et comprend notamment un module MOD_OBT, un module MOD_SEL et un module MOD_TX dont les fonctions sont décrites ci-après en référence à la FIG. 3 . La FIG. 3 représente un exemple d’architecture matérielle d’un deuxième dispositif électronique. Tel qu’illustré par la FIG. 3 , le deuxième dispositif électronique dispose de l’architecture matérielle d’un ordinateur. Ainsi, le deuxième dispositif électronique comporte notamment un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre un module de communication 5. La mémoire morte 3 du deuxième dispositif électronique constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de contrôle d’une communication tel que proposé ci-après. Le programme PROG_M définit un ou plusieurs modules fonctionnels du deuxième dispositif électronique, qui s’appuient sur ou commandent les éléments matériels 1 à 5 cités précédemment, et qui comprennent notamment : un module MOD_OBT d'obtention d’une donnée représentative de tranches réseau supportées par un réseau et accessibles par un premier dispositif électronique souhaitant accéder à un service S ; un module MOD_SEL de sélection de tranches réseau accessibles par les premier et deuxième dispositifs électroniques et compatibles avec la fourniture du service S, et d’une politique de gestion des flux de la communication via les tranches réseau sélectionnées ; un module MOD_TX de transmission, à destination du premier dispositif électronique, d'une donnée représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées pour qu’elles soient appliquées, par le premier dispositif électronique, à cette communication. Par ailleurs, le deuxième dispositif électronique peut également comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de contrôle d’une communication, comme cela est décrit plus en détail ultérieurement. La FIG. 4 représente des modules embarqués dans un premier dispositif électronique, selon un exemple de mise en œuvre de l’invention. Ce premier dispositif électronique correspond par exemple au dispositif (20) de demande d’accès à un service, ou au dispositif intermédiaire (50) connecté au dispositif (20) de demande, et comprend notamment un module MOD_RX et un module MOD_APP dont les fonctions sont décrites ci-après en référence à la FIG. 4 . La FIG. 4 représente un exemple d’architecture matérielle d’un premier dispositif électronique. Tel qu’illustré par la FIG. 4 , le premier dispositif électronique dispose de l’architecture matérielle d’un ordinateur. Ainsi, le premier dispositif électronique comporte notamment un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre un module de communication 5. La mémoire morte 3 du premier dispositif électronique constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG_S conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de configuration d’une communication tel que proposé ci-après. Le programme PROG_S définit un ou plusieurs modules fonctionnels du premier dispositif électronique, qui s’appuient sur ou commandent les éléments matériels 1 à 5 cités précédemment, et qui comprennent notamment : un module MOD_RX de réception, en provenance du deuxième dispositif, d'une donnée représentative de tranches réseau accessibles par les premier et deuxième dispositifs électroniques et compatibles avec une fourniture du service (S), ladite donnée étant en outre représentative d'une politique de gestion de flux de la communication via lesdites tranches de réseau ; et, un module MOD_APP d'application desdites tranches réseau et de ladite politique de gestion des flux à la communication. Par ailleurs, le premier dispositif électronique peut également comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers d'un procédé de configuration d’une communication, comme cela est décrit plus en détail ultérieurement. La FIG. 5 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à un service, selon un premier exemple de mise en œuvre de l’invention. Ce procédé comprend un procédé de contrôle d'une communication incluant les étapes S200, S210 à S290 et mis en œuvre par un dispositif (30) de gestion du service (S) (qui est ainsi un deuxième dispositif au sens de l’invention dans ce premier exemple de mise en œuvre), ainsi qu'un procédé de configuration d'une communication incluant les étapes S10, S100, S110 à S160 et mis en œuvre par un dispositif (20) de demande d'accès du service (S) (qui est ainsi un premier dispositif au sens de l’invention dans ce premier exemple de mise en œuvre). Le procédé général d'accès à un service comprend une première étape S10 d’initialisation au cours de laquelle le dispositif (20) de demande d’accès à un service obtient une liste de tranche(s) auxquelles il peut accéder pour envoyer ou recevoir du trafic (c’est-à-dire qu’il est habilité à utiliser les ressources de la ou des tranches listées). Selon une implémentation particulière, cette liste est communiquée (par ex. transmise) par le ou les fournisseurs de tranches de réseau ("Slice Service Provider", SSP, selon la terminologie anglo-saxonne) auxquels le dispositif (20) de demande d'accès à un service est connecté, et reçue par ce dispositif (20) de demande d’accès à un service. Cette étape est par exemple conforme à la section 4.9.2 "Network Slice as a Service" de la spécification TS 28.801, "Telecommunication management; Study on management and orchestration of network slicing for next generation network", version 15.1.0, publiée le 4 janvier 2018 par le consortium 3GPP. En variante, c’est un service du dispositif (20) de demande d'accès qui met en œuvre les étapes S10, S100 à S160 de ce procédé – le dispositif (20) de demande d'accès à un service correspondant alors par exemple à une ressource matérielle d’un réseau de télécommunications –, et la liste des tranches que ledit dispositif est susceptible d’utiliser pour envoyer ou recevoir du trafic est obtenue à l’issue d’une configuration dudit service, laquelle suppose de configurer l'ensemble des tranches que le premier dispositif est susceptible d'utiliser pour envoyer ou recevoir du trafic. Une telle configuration est par exemple intégrée dans l’applicatif client utilisé pour accéder au service. Pour chaque tranche réseau, son type est obtenu par le dispositif (20) de demande d’accès à un service. Il importe également de noter que plusieurs types de tranches peuvent être associés à une même tranche. Dans ce cas, pour une tranche donnée, plusieurs types sont obtenus par le dispositif (20) de demande d’accès à un service. Cette caractéristique s’avère particulièrement avantageuse lorsqu’une même tranche (ou instance de tranche) est conçue pour agréger plusieurs autres sous-tranches (ou sous-instances de tranche). Le type d’une tranche réseau correspond par exemple à l’un des types de tranches définis par le consortium 3GPP (par ex. eMBB, IoT, URRLLC ou V2X), ou à d’autres types préalablement définis par le fournisseur de tranches réseau. En variante, plutôt que d’obtenir un type particulier de tranche réseau, des identifiants de tranche réseau ("Slice Identifier", SID, selon la terminologie anglo-saxonne) ou marqueurs idoines ("tags") sont obtenus par le dispositif (20) de demande d’accès à un service. Selon une implémentation particulière, le dispositif (20) de demande d’accès à un service obtient en outre tout ou partie des données suivantes : un identifiant de réseau ("Network IDentifier", NID). Cet identifiant peut être utilisé pour déterminer si les deux dispositifs 20 et 30 sont connectés au même réseau. Dans ce cas, cet identifiant de réseau peut être utilisé pour marquer les paquets d’une sous-session. L’échange de cet identifiant de réseau permet également de vérifier la corrélation entre les identifiants de réseau des dispositifs (20, 30) de demande d’accès à un service et de gestion ; un nombre maximum de sous-sessions par tranche donnée ("MAX_SubFlow_Slice"). Ce paramètre peut être fourni comme un paramètre système ou être un paramètre configuré par défaut dans une application ou un service. Ce paramètre peut également être configuré par un utilisateur (par exemple, un administrateur d’une instance de service). Tel qu’illustré par la FIG. 5 , le procédé général d'accès à un service comprend en outre une étape de transmission S100 au cours de laquelle un message MSG1 est transmis par le dispositif (20) de demande d'accès à un service à destination du dispositif (30) de gestion du service. Ce premier message MSG1 inclut, dans l’exemple d’implémentation envisagé ici, une donnée SLICE_CAPABLE_1 représentative d'une capacité du dispositif (20) de demande d’accès à un service à utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau d’un réseau de télécommunications supportant des tranches réseau, et à appliquer une politique de gestion des flux de la communication sélectionnée par le dispositif (30) de gestion du service. Selon une implémentation particulière, ce message MSG1 correspond à une demande d’établissement de communication. Un protocole de transport incluant TCP et son option MPTCP sont par exemple considérés, et ce message MSG1 correspond à un message SYN TCP. Toujours en considérant l'option MPTCP, ce message MSG1 correspond par exemple à une demande d’initialisation d’une sous-session TCP supplémentaire. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_1 correspond à une valeur d’un champ (ou "attribut") (par ex. un champ ou attribut appelé ici SLICE_CAPABLE) du message MSG1, ce champ étant alors dédié à la représentation d'une capacité d’un dispositif électronique à utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau d’un réseau de télécommunications, et à appliquer une politique de gestion des flux de la communication sélectionnée par un autre dispositif. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_1 comprend en outre une indication selon laquelle le dispositif (20) de demande d’accès à un service est capable d’échanger des données dans le cadre d’une communication établie sur des chemins multiples au sein de ce réseau de télécommunications supportant des tranches réseau. Ainsi, si la valeur du champ SLICE_CAPABLE du message MSG1 est par exemple égale à "1", cela signifie que le dispositif ayant émis cette trame est capable d'utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau d’un réseau de télécommunications, d'appliquer une politique de gestion des flux de la communication sélectionnée par un autre dispositif, et d’échanger des données dans le cadre d’une communication établie sur des chemins multiples au sein de ce réseau. Ce message MSG1 est reçu par le dispositif (30) de gestion du service lors d’une étape S200. Au cours d’une étape S210, le dispositif (30) de gestion extrait des données du message reçu à l’étape S200. Le procédé général d'accès au service comprend en outre une étape S220 au cours de laquelle il est déterminé si le dispositif (30) de gestion est capable ou pas de sélectionner au moins une tranche réseau parmi une pluralité de tranches réseau du réseau de télécommunications, en fonction des contraintes ou exigences du service (S) mais également en fonction des capacités du dispositif de demande d’accès à un service (20), et de sélectionner une politique de gestion des flux appropriée. Selon une implémentation particulière, cette étape S220 vise également à déterminer si le dispositif (30) de gestion est capable ou pas d'utiliser une communication établie sur des chemins multiples au sein de ce réseau de télécommunications supportant des tranches réseau. Si le dispositif (30) de gestion n’en est pas capable (choix "N"), il met en œuvre l’étape S230. Selon un premier exemple de mise en œuvre de l’étape S230, le message MSG1 reçu à l’étape S200 est ignoré et il est mis fin à la procédure d’établissement de la communication. Selon un deuxième exemple de mise en œuvre, la donnée SLICE_CAPABLE_1 est ignorée par le dispositif (30) de gestion du service. Dans ce cas, si le protocole de transport utilisé est le protocole TCP qui utilise l'option MPTCP, un deuxième message est émis par le dispositif (30) de gestion à destination du dispositif (20) de demande d'accès au service, qui correspond par exemple au message SYN/ACK tel que défini par le standard RFC 9293. Si par contre le dispositif (30) de gestion d'un service est capable de sélectionner au moins une tranche réseau parmi une pluralité de tranches réseau d’un réseau de télécommunications en fonction des exigences du service (S) mais également de contraintes du dispositif (20) de demande d’accès à un service, et de sélectionner une politique de gestion des flux (choix "Y"), il met alors en œuvre une étape S240. Lors de cette étape S240, un deuxième message, MSG2, est transmis par le dispositif (30) de gestion à destination du dispositif de demande d’accès à un service (20), qui inclut une donnée SLICE_CAPABLE_2 représentative d’une capacité du dispositif (30) de gestion à sélectionner au moins une tranche réseau compatible pour accéder au service (S), ainsi qu'une politique de gestion des flux de la communication. Selon une implémentation particulière, ce message MSG2 correspond à un accusé de réception ACK de la demande d’établissement de communication. En alternative, si le protocole de transport utilisé est le protocole TCP qui utilise l'option MPTCP et que le message MSG1 porte sur l'initialisation d'une sous-session TCP, ce message MSG2 correspond à un accusé de réception de la demande d’initialisation d’une sous-session TCP supplémentaire. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_2 correspond à une valeur d’un champ (appelé par exemple SLICE_CAPABLE) du message MSG2, ce champ étant alors dédié à représenter une capacité d’un dispositif électronique à sélectionner au moins une tranche réseau compatible pour accéder au service (S), ainsi qu'une politique de gestion des flux de la communication. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_2 comprend en outre une indication selon laquelle le dispositif (30) de gestion d'un service est capable d'utiliser une communication établie sur des chemins multiples au sein de ce réseau de télécommunications supportant des tranches réseau. Ainsi, si la valeur du champ SLICE_CAPABLE du message MSG2 est par exemple égale à "1", cela signifie que le dispositif ayant émis ce message est capable de sélectionner au moins une tranche réseau compatible ainsi qu'une politique de gestion des flux, et d’utiliser une communication établie sur des chemins multiples au sein de ce réseau. Le deuxième message MSG2 est reçu par le dispositif (20) de demande d’accès à un service lors d’une étape S110. Le procédé général d'accès à un service comprend en outre une étape S120 au cours de laquelle les données sont extraites du message MSG2 reçu. De manière plus précise, le dispositif (20) de demande d’accès à un service vérifie la présence de la donnée SLICE_CAPABLE_2. En effet, l’absence de cette donnée dans une réponse à une demande d’établissement de communication (MSG1) qui contient la donnée SLICE_CAPABLE_1 signifie que le dispositif (30) de gestion ne supporte pas la méthode selon l’invention. Si le deuxième message MSG2 comprend la donnée SLICE_CAPABLE_2, l’étape S130 est alors mise en œuvre. Au cours de cette étape S130, un troisième message MSG3 est émis par le dispositif (20) de demande d’accès à un service à destination du dispositif (30)de gestion du service, qui inclut une donnée SLICE_SET représentative de tranches réseau supportées par ledit au moins un réseau et accessibles par le dispositif (20) de demande d'accès à un service. Cette donnée SLICE_SET inclut au moins un type de tranche réseau et/ou au moins un identifiant de tranche réseau obtenus lors de l’étape S10. Selon une implémentation particulière, cette donnée SLICE_SET inclut en outre au moins une donnée parmi les données suivantes : un identifiant de réseau obtenu à l’étape S10 ; un nombre maximum de sous-sessions par tranche donnée ("MAX_SubFlow_Slice") par exemple obtenu à l’étape S10 ; un ou plusieurs identifiants d’adresse ("Address Identifier", Address ID). Cet identifiant est utilisé pour associer les tranches joignables via une même adresse. Ce paramètre est par exemple généré par le dispositif (20) de demande d'accès à un service selon un mécanisme similaire à celui de l’option MPTCP ADD_ADDR. une indication de support de sous-sessions asymétriques. Cette indication correspond par exemple à un champ spécifique prenant l’une des valeurs suivantes : IN, OUT ou BOTH. Ce paramètre indique explicitement la capacité d’associer le trafic sortant (OUT) ou entrant (IN) d’une même sous-session à des tranches réseau distinctes. La valeur BOTH est utilisée pour indiquer qu’une même tranche doit être utilisée pour le trafic entrant et sortant d’une même sous-session. Cependant, les sous-sessions d’une même communication peuvent être associées à des tranches distinctes. Selon une implémentation particulière, le troisième message MSG3 comprend en outre des données, OTHER_TSV, relatives au ou aux protocoles de transport applicables, par le dispositif (20) de demande d’accès à un service, à la communication entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion du service (S). Ces protocoles de transport permettent par exemple d’établir une communication sur des chemins multiples. Pour cela, le message comprend par exemple un champ dédié dont les valeurs « protocol#i » correspondent à des identifiants de protocoles de transport. Les données OTHER_TSV peuvent s’appliquer à une communication de bout en bout, à une sous-session, ou à une tranche spécifique. Dans ce dernier cas, le ou les protocoles listés ne sont éligibles que pour des communications ou sous-sessions via cette tranche spécifique. Selon une implémentation particulière, le troisième message comprend en outre des données SCHEDULER relatives au(x) mécanisme(s) d’ordonnancement de trafic supportés par le dispositif (20) de demande d'accès à un service (S) et le dispositif (30) de gestion du service (S). Pour cela, le message comprend par exemple un champ dédié dont les valeurs sc#j correspondent à des identifiants de mécanismes d’ordonnancement de trafic applicables (e.g. la valeur "0" pour le Round-Robin (ou "tourniquet" en français), "1" pour le "Lowest Round-Trip-Time First", "2" pour le "Round-Trip-Time Threshold", et "3" pour le "Priority-based"). Les données SCHEDULER peuvent s’appliquer à une communication de bout-en-bout, à une sous-session, ou à une tranche spécifique. Dans ce dernier cas, le ou les mécanismes d’ordonnancement listés ne sont éligibles que pour l’établissement de communications ou sous-sessions via cette tranche spécifique. Le procédé général d'accès à un service comprend en outre une étape S250 au cours de laquelle le message MSG3 est reçu par le dispositif (30) de gestion. Cette étape est par exemple mise en œuvre par le module MOD_OBT du dispositif (30) de gestion du service. A l'issue de la réception de ce message MSG3, le dispositif (30) de gestion du service extrait les données du message MSG3 et les enregistre dans un cache local (étape S260). Lors d’une étape S270, le dispositif (30) de gestion d'un service sélectionne des tranches réseau accessibles par le dispositif (30) de demande d’accès à un service et compatibles avec la fourniture du service S, ainsi qu'une politique de gestion des flux de la communication via les tranches réseau sélectionnées. Cette étape est par exemple mise en œuvre par le module MOD_SEL du dispositif (30) de gestion du service. La sélection d'une politique de gestion des flux précédemment évoquée comprend tout ou partie des éléments suivants : un mécanisme d'ordonnancement de trafic à appliquer par le dispositif (20) de demande d’accès à un service à la communication; un protocole de transport permettant d’établir des communications sur des chemins multiples à appliquer, par le dispositif (20) de demande d’accès à un service, à la communication ; une contrainte sur une direction d'au moins un flux de la communication au travers d'au moins une des tranches réseau sélectionnées ; une répartition spécifique des flux de la communication (ou le cas échéant des sous-sessions sur lesquelles s’appuie la communication) et dont le trafic est acheminé dans la ou les tranches réseau sélectionnées, et, une contrainte d’utilisation d’une unique tranche ou d’une pluralité de tranches réseaux connectées entre elles. Bien entendu, d’autres éléments peuvent être envisagés dans la politique de gestion en variante ou en complément des éléments précités. L'étape S270 comprend une comparaison, par le dispositif (30) de gestion, des données extraites avec ses propres informations et instructions de service. Ces instructions de service correspondent à des exigences (par ex. un type de tranche réseau donné, un mécanisme d’ordonnancement de trafic, un protocole de transport spécifique, une répartition spécifique des flux, une contrainte d'utilisation de tranches) requises pour pouvoir accéder de manière optimale au service S. L’étape S270 permet de déterminer si au moins une tranche réseau est à la fois accessible par le dispositif (20) de demande d’accès à un service et compatible avec les contraintes ou exigences du service (S) et/ou avec celles du dispositif sur lequel est déployé ce service. Selon une implémentation particulière, cette étape inclut une comparaison entre le ou les types de tranches réseau du message MSG2, et celui ou ceux compatibles avec le service (S). Selon une implémentation particulière, cette étape S270 comprend en outre une sélection d'un ou plusieurs protocoles de transport permettant au dispositif (20) d’envoyer une demande d’accès à un service et compatibles avec les contraintes ou exigences du service (S). Ces protocoles de transport sont par exemple des protocoles de transport qui permettent d’établir des communications sur des chemins multiples, tels que le protocole TCP assorti de l'option "Multipath TCP", le protocole UDP assorti d'une extension "Multipath UDP", le protocole QUIC assorti de l'extension "Multipath QUIC" et le protocole MDCCP "Multipath Datagram Congestion Control Protocol". MPTCP est une option du protocole TCP bien connu en soi, qui permet donc d'établir une communication TCP dont les flux empruntent plusieurs chemins du réseau. L'option MPTCP définit la notion de sous-session ("subflow" selon la terminologie anglo-saxonne) pour désigner une session TCP reposant sur l’utilisation de l’une des adresses IP/numéros de port disponibles. Aussi, une communication MPTCP correspond à un agrégat de sous-sessions TCP. L'option MPTCP est spécifiée par le standard RFC8684, "TCP Extensions for Multipath Operation with Multiple Addresses", publiée en mars 2020 par l’IETF. L'extension Multipath du protocole UDP permet d’établir des communications UDP sur des chemins multiples. L'extension Multipath du protocole QUIC est décrite dans la spécification "Multipath Extensions for QUIC (MP-QUIC)", draft-ietf-quic-multipath, version 06, publiée en octobre 2023 par l’IETF. Enfin, MPDCCP est une extension du protocole de transport DCCP, qui est particulièrement adaptée aux services ayant des exigences élevées en termes de latence. Cette option est définie dans la spécification "DCCP Extensions for Multipath Operation with Multiple Addresses", version 11, publiée en octobre 2023 par l'IETF. Selon une implémentation particulière, si le message MSG3 comprend des données SCHEDULER relatives au(x) mécanisme(s) d’ordonnancement de trafic applicables, par le dispositif (20) de demande d’accès à un service, à la communication entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion du service (S), l’étape S270 comprend également la sélection d’au moins un mécanisme d’ordonnancement parmi les mécanismes d’ordonnancement identifiés dans le message MSG3, qui soit également compatible avec les exigences du service (S) et/ou du dispositif sur lequel est déployé ce service. Selon une implémentation particulière, cette étape S270 comprend en outre une sélection, par le dispositif (30) de gestion, d'au moins une tranche réseau accessible par ce même dispositif (30) de gestion, et adaptée à la fourniture du service (S) (par exemple ici au dispositif (20) de demande d'accès audit service). Cette tranche réseau accessible par ce dispositif (30) de gestion est par exemple identique à celle sélectionnée pour le dispositif (20) de demande d'accès au service. Selon une implémentation particulière, cette étape S270 comprend en outre une sélection, par le dispositif (30) de gestion, d'une politique de gestion applicable, par ce même dispositif (30) de gestion, à la communication entre le dispositif (20) de demande d'accès et ce dispositif (30) de gestion, et adaptée à la fourniture du service (S) (par exemple ici, au dispositif (20) de demande d'accès audit service). Cette politique de gestion applicable par ce dispositif (30) de gestion est par exemple identique à celle sélectionnée pour le dispositif (20) de demande d'accès au service. Si une tranche réseau à la fois accessible par le dispositif (20) de demande d’accès à un service et compatible avec les contraintes ou exigences du service (S) est identifiée, l’étape S280-1 est mise en œuvre au cours de laquelle la tranche identifiée est associée au trafic sortant de la communication ou de la sous-session. Le procédé selon l'invention comprend en outre une étape S290-1 au cours de laquelle le dispositif (30) de gestion transmet, à destination du dispositif (20) de demande d'accès au service, un quatrième message MSG4 incluant une donnée SLICE_SET_SELECT représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées lors de l'étape S270. Selon une mise en œuvre particulière, ces données sont consignées dans le champ SLICE_SET, et d’une manière optionnelle, dans les champs OTHER_TSV et SCHEDULER du quatrième message MSG4. Cette étape est par exemple mise en œuvre par le module MOD_TX du dispositif (30) de gestion. Si par contre aucune tranche réseau n’est à la fois accessible par le dispositif (20) de demande d’accès à un service (S) et compatible avec les exigences de ce service (S), alors le dispositif (30) de gestion du service met en œuvre une étape S280-2. Au cours de cette étape S280-2, le dispositif de gestion (30) sélectionne un protocole de transport alternatif à celui jusqu’à présent utilisé par le dispositif (20) de demande d’accès à un service. Selon une implémentation particulière, ce protocole de transport alternatif est un protocole par défaut. En variante, ce protocole de transport alternatif est sélectionné à partir des données OTHER_TSV relatives aux protocoles de transport incluses dans le message MSG3. Puis, lors d'une étape S290-2, le dispositif (30) de gestion transmet, à destination du dispositif (20) de demande d'accès, un quatrième message MSG4' incluant une donnée représentative du protocole de transport sélectionné lors de l'étape S280-2. Ce quatrième message (MSG4, MSG4') est reçu par le dispositif (20) de demande d’accès à un service lors d’une étape S140. Cette étape est par exemple mise en œuvre par le module MOD_RX du dispositif (20) de demande d’accès à un service. Le procédé selon l'invention comprend en outre une étape S150 au cours de laquelle les données sont extraites du quatrième message (MSG4, MSG4') reçu, et enregistrées dans un cache local. Enfin, le dispositif (20) de demande d’accès à un service met en œuvre une étape S160 au cours de laquelle les tranches réseau et la politique de gestion des flux sélectionnées lors de l'étape S270 sont appliquées à la communication établie entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion de ce service (S). Cette étape S160 est par exemple mise en œuvre par le module MOD_APP du dispositif (20) de demande d’accès à un service. Cette étape S160 est décrite plus en détail en référence à la FIG. 5 . Selon une variante, le procédé selon l'invention ne comprend pas les étapes S100, S200 à S240, S110 et S120. Dans ce cas particulier, les premier et deuxième messages MSG1, MSG2 ne sont donc pas échangés entre les premier et deuxième dispositifs électroniques, et le troisième message MSG3 comprend alors la donnée SLICE_CAPABLE_1 représentative d’une capacité du dispositif (20) de demande d’accès à un service à utiliser au moins une tranche réseau sélectionnée parmi une pluralité de tranches réseau d’un réseau de télécommunications, et à appliquer une politique de gestion des flux de la communication sélectionnée par le dispositif (30) de gestion du service. La FIG. 5 est une vue détaillée d'un exemple de mise en œuvre de l’étape S160 au cours de laquelle les tranches réseau et la politique de gestion des flux sélectionnées sont appliquées à la communication entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion de ce service (S). Tel qu’illustré par la FIG. 5 , l’étape S160 comprend une première étape S5110 au cours de laquelle le dispositif (20) de demande d’accès à un service (S) détermine si les données extraites au cours de l'étape S150 incluent des données relatives à des tranches réseau sélectionnées. Si tel est le cas, l’étape S5120 est mise en œuvre au cours de laquelle les tranches de réseau sélectionnées sont associées à la communication ou à la sous-session établie entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion de ce service (S). Puis, lors d’une étape S1540, la politique de gestion des flux sélectionnée par le dispositif (30) de gestion est obtenue. De façon plus précise, il est par exemple déterminé si les données extraites incluent un protocole de transport à utiliser, par exemple en vérifiant si le champ OTHER_TSV du quatrième message MSG4 est vide ou pas, et s'il n’est pas vide, en vérifiant si la valeur dudit champ correspond à l’une des valeurs identifiant les protocoles de transport transmises au travers du troisième message MSG3. Si tel est le cas (par ex. si le champ OTHER_TSV comprend l’identifiant « protocol#i » d’au moins un protocole de transport pouvant être appliqué par le dispositif (20) de demande d’accès à un service), le dispositif (20) de demande d'accès utilise le protocole de transport identifié par « protocol#i » pour l’envoi de paquets de données via la tranche sélectionnée dans le cadre de la communication entre ce dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion dudit service. De façon relativement similaire, il est par exemple déterminé si les données extraites incluent un mécanisme d’ordonnancement de trafic spécifique à appliquer, en vérifiant si le champ SCHEDULER du quatrième message MSG4 est vide ou pas, et s’il n’est pas vide, en vérifiant si la valeur dudit champ correspond à l’une des valeurs identifiant les mécanismes d’ordonnancement de trafic transmises au travers du troisième message MSG3. Si tel est le cas (par ex. si le champ SCHEDULER comprend l’identifiant sc#j d’au moins un mécanisme d’ordonnancement de trafic pouvant être appliqué par le dispositif (20) de demande d’accès à un service), le dispositif (20) de demande d’accès à un service utilise le mécanisme d’ordonnancement de trafic identifié par sc#j pour l’envoi de paquets de données via la tranche sélectionnée dans le cadre de la communication établie entre ce dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion dudit service Enfin, lors d’une étape S5140, le dispositif (20) de demande d’accès à un service associe le trafic sortant de la communication (ou sous-session) avec la tranche sélectionnée par le dispositif (30) de gestion. Le marquage du trafic est celui associé à la tranche ainsi sélectionnée. Des tranches distinctes par direction de trafic peuvent également être utilisées. De retour à l’étape S5110, si les données extraites n’incluent pas de données relatives aux tranches réseau sélectionnées, alors il est déterminé, lors d’une étape S5150, si les données extraites incluent un protocole de transport alternatif à celui jusqu’à présent utilisé par le dispositif (20) de demande. Si tel est le cas (choix "Y"), les étapes S5160 et S5170 sont mises en œuvre. Lors de l’étape S5160, le dispositif (20) de demande d’accès à un service détecte la clôture de la communication établie entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion d'un service. Selon un premier exemple, la clôture de la communication établie entre le dispositif (20) de demande d'accès à un service et le dispositif (30) de gestion d'un service est déclenchée de façon immédiate. Selon un deuxième exemple, la communication établie entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion d'un service est maintenue et n’est donc pas immédiatement clôturée, et l’étape S5160 comprend la détection d’un évènement relatif à la clôture de la communication en cours. L’attente de la détection d’un tel évènement est par exemple déclenchée à l’issue de la réception du quatrième message MSG4, et ce, pendant une période de temps prédéterminée (par ex. 24 heures). Enfin, l’étape S5170 est mise en œuvre au cours de laquelle une nouvelle communication est établie en utilisant le protocole de transport « protocol#i ». De retour à l’étape S5150, si les données extraites n’incluent pas de protocole de transport alternatif à celui jusqu’à présent utilisé par le dispositif (20) de demande d'accès à un service (choix "N"), alors la communication courante est clôturée (étape S5180). La FIG. 6 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à un service, selon un deuxième exemple de mise en œuvre de l’invention. La FIG. 6 illustre une variante dans laquelle la sélection des tranches compatibles et de la politique de gestion des flux est mise en œuvre par le dispositif (20) de demande d’accès à un service plutôt que par le dispositif (30) de gestion d'un service. Le procédé général d'accès à un service comprend une première étape (S10) d’initialisation au cours de laquelle le dispositif (20) de demande d’accès à un service obtient une liste de tranches auxquelles il peut accéder pour envoyer ou recevoir du trafic. Cette étape est par exemple mise en œuvre par le module MOD_OBT du dispositif (20) de demande d'accès à un service. Tel qu’illustré par la FIG. 6 , le procédé général d'accès à un service comprend en outre une étape S6100 de transmission au cours de laquelle un message MSG1 est transmis par le dispositif (20) de demande d’accès à un service à destination du dispositif (30) de gestion du service. Ce message inclut, dans l’exemple d’implémentation envisagé ici, une donnée SLICE_CAPABLE_3 représentative d’une capacité du dispositif (20) de demande d’accès à un service à sélectionner au moins une tranche réseau compatible pour accéder au service (S), ainsi qu'une politique de gestion des flux de la communication. Selon une implémentation particulière, ce message MSG1 correspond à une demande d’établissement de communication. Un protocole de transport tel que TCP et son option MPTCP sont par exemple considérés, et ce message MSG1 correspond à un message SYN TCP. Toujours en considérant l'option MPTCP, ce message MSG1 correspond par exemple à une demande d’initialisation d’une sous-session TCP supplémentaire. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_3 correspond à une valeur d’un champ (ou "attribut") (par ex. un champ ou attribut appelé ici SLICE_CAPABLE) du message MSG1, ce champ étant alors dédié à la représentation d'une capacité d’un dispositif électronique à sélectionner au moins une tranche réseau compatible pour accéder à un service, ainsi qu'une politique de gestion des flux de la communication. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_3 comprend en outre une indication selon laquelle le dispositif (20) de demande d'accès à un service est capable d’échanger des données dans le cadre d’une communication établie sur des chemins multiples au sein de ce réseau de télécommunications supportant des tranches réseau. Ainsi, si la valeur du champ SLICE_CAPABLE du message MSG1 est par exemple égale à "1", cela signifie que le dispositif ayant émis le message MSG1 est capable de sélectionner au moins une tranche réseau parmi une pluralité de tranches réseau déployées au sein d’un réseau de télécommunications, ainsi qu'une politique de gestion des flux de la communication, et d’échanger des données dans le cadre d’une communication établie sur des chemins multiples au sein de ce réseau. Ce message MSG1 est reçu par le dispositif (30) de gestion du service lors d’une étape S6200. Au cours d’une étape S6210, le dispositif (30) de gestion du service extrait des données du message reçu à l’étape S6200. Le procédé général d'accès au service comprend en outre une étape S6220 au cours de laquelle il est déterminé si le dispositif (30) de gestion est capable ou pas d'utiliser une tranche réseau sélectionnée par le dispositif (20) de demande d’accès à un service parmi une pluralité de tranches réseau du réseau de télécommunications, et d'appliquer une politique de gestion des flux également sélectionnée par le dispositif de demande (20). Selon une implémentation particulière, cette étape S6220 vise également à déterminer si le dispositif (30) de gestion est capable ou pas d'utiliser une communication établie sur des chemins multiples au sein de ce réseau de télécommunications. Si le dispositif (30) de gestion n’en est pas capable (choix "N"), il met en œuvre l’étape S6230. Selon un premier exemple de mise en œuvre de l’étape S6230, le message MSG1 reçu à l’étape S6200 est ignoré et il est mis fin à la procédure d’établissement de la communication. Selon un deuxième exemple de mise en œuvre, la donnée SLICE_CAPABLE_3 est ignorée par le dispositif (30) de gestion d'un service. Si le dispositif (30) de gestion (30) d'un service est par contre capable d'utiliser une tranche réseau sélectionnée par le dispositif (20) de demande d'accès à un service parmi une pluralité de tranches réseau du réseau de télécommunications, et d'appliquer une politique de gestion des flux également sélectionnée par le dispositif (20) de demande d'accès à un service, il met en œuvre une étape S6240. Lors de cette étape S240, un deuxième message MSG2 est transmis par le dispositif (30) de gestion et à destination du dispositif (20) de demande d’accès à un service, qui inclut une donnée SLICE_CAPABLE_4 représentative d’une capacité du dispositif (30) de gestion à utiliser au moins une tranche réseau compatible ainsi qu'à appliquer une certaine politique de gestion des flux de la communication. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_4 correspond à une valeur d’un champ (appelé par exemple SLICE_CAPABLE) du message MSG2, ce champ étant alors dédié à représenter une capacité d’un dispositif électronique à utiliser au moins une tranche réseau compatible ainsi qu'à appliquer une politique de gestion des flux de la communication sélectionnées par un autre dispositif électronique. Selon une implémentation particulière, cette donnée SLICE_CAPABLE_4 comprend en outre une indication selon laquelle le dispositif (30) de gestion d'un service est capable d'utiliser une communication établie sur des chemins multiples au sein de ce réseau de télécommunications supportant des tranches réseau. Ainsi, si la valeur du champ SLICE_CAPABLE du message MSG2 est par exemple égale à "1", cela signifie que le dispositif ayant émis ce message est capable d'utiliser au moins une tranche réseau et d'appliquer une politique de gestion des flux de la communication sélectionnées par un autre dispositif électronique, et d’utiliser une communication établie sur des chemins multiples au sein de ce réseau. Ce deuxième message comprend en outre une donnée SLICE_SET représentative de tranches réseau supportées par le réseau de communication, et accessibles par le dispositif (30) de gestion du service. Selon une implémentation particulière, ce deuxième message MSG2 comprend en outre des données OTHER_TSV relatives au (x) protocoles de transport utilisables pour accéder au service (S), et/ou des données SCHEDULER relatives au(x) mécanisme(s) d’ordonnancement de trafic applicables pour accéder au service (S). Ces données OTHER_TSV et SCHEDULER correspondent par exemple à celles préalablement décrites en référence à la FIG. 5 . Le deuxième message MSG2 est reçu par le dispositif (20) de demande d’accès à un service lors d’une étape S6110. Le procédé général d'accès à un service comprend en outre une étape S6120 au cours de laquelle les données sont extraites du message MSG2 reçu. De manière plus précise, le dispositif (20) de demande d’accès à un service vérifie la présence de la donnée SLICE_CAPABLE_4. En effet, l’absence de cette donnée dans une réponse à une demande d’établissement de communication (MSG1) qui contient la donnée SLICE_CAPABLE_3 signifie que le dispositif (30) de gestion d'un service ne supporte pas la procédure selon l’invention. Si le deuxième message MSG2 comprend la donnée SLICE_CAPABLE_4, l’étape S6125 est alors mise en œuvre. Au cours de cette étape, le dispositif (20) de demande d'accès à un service sélectionne des tranches réseau auxquelles il peut accéder et qui sont également compatibles avec la fourniture du service, ainsi qu'une politique de gestion des flux de la communication via les tranches réseau sélectionnées. Cette étape est similaire à l'étape S270 décrite en référence à la FIG. 5 , et est par exemple mise en œuvre par le module MOD_SEL du dispositif (20) de demande d'accès à un service. Le procédé comprend en outre une étape S6130 au cours de laquelle un troisième message MSG3 est transmis par le dispositif (20) de demande d’accès à un service à destination du dispositif (30) de gestion du service. Cette étape est par exemple mise en œuvre par le module MOD_TX du dispositif (20) de demande d’accès à un service. Ce troisième message MSG3 comprend une donnée, SLICE_SET_SELECT, représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées lors de l'étape S6125. Selon une mise en œuvre particulière, ces données sont consignées dans le champ SLICE_SET, et d’une manière optionnelle, dans les champs OTHER_TSV et SCHEDULER du troisième message MSG3. Le procédé d'accès à un service comprend en outre une étape S6250 au cours de laquelle le message MSG3 est reçu par le dispositif (30) de gestion d'un service. A l'issue de la réception de ce message MSG3, le dispositif (30) de gestion extrait les données du message MSG3 et les enregistre dans un cache local lors d'une étape S6260. Une étape S6280 est ensuite mise en œuvre au cours de laquelle la tranche identifiée est associée au trafic sortant de la communication (ou de la sous-session) entre le dispositif (20) de demande d’accès à un service et le dispositif (30) de gestion de ce service (S). Le procédé selon l'invention comprend en outre une étape S6290 au cours de laquelle le dispositif (30) de gestion transmet, à destination du dispositif (20) de demande d’accès à un service, un quatrième message MSG4 incluant un acquittement ACK. Ce quatrième message MSG4 est reçu par le dispositif (20) de demande d’accès à un service lors d’une étape S6140. Le procédé selon l'invention comprend en outre une étape S6150 au cours de laquelle le dispositif (20) de demande d’accès à un service extrait les données du quatrième message reçu. Enfin, le dispositif (20) de demande d’accès à un service met en œuvre une étape S6160 similaire à l'étape S160 de la FIG. 5 . La FIG. 7 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé de contrôle d'un dispositif intermédiaire impliqué dans une communication au cours de laquelle sont échangées des données relatives à un service, selon un exemple de mise en œuvre de l’invention. Ce procédé est mis en œuvre dans le cas où le premier dispositif correspond au dispositif intermédiaire (50), et ce, après l'étape S150 au cours de laquelle les données du quatrième message sont reçues, et enregistrées dans un cache local par le dispositif intermédiaire (50). Le procédé de contrôle d'un dispositif intermédiaire comprend alors, dans l’exemple envisagé ici, une première étape S7100, mise en œuvre par le dispositif (20) de demande d'accès à un service, au cours de laquelle une requête REQ visant à obtenir une donnée (par ex. SLICE_SET_SELECT) représentative des tranches réseau et de la politique de gestion des flux sélectionnées. Cette requête est reçue par le dispositif intermédiaire (50) lors d'une étape S7500. Le procédé de contrôle comprend en outre une étape S7510, mise en œuvre par le dispositif intermédiaire (50), de transmission au dispositif (20) de demande d’accès au service, de la donnée SLICE_SET_SELECT représentative des tranches réseau et de la politique de gestion de flux sélectionnées. Le message incluant cette donnée SLICE_SET_SELECT est par exemple conforme au format décrit en référence à la FIG. 8 . Cette donnée est reçue par le dispositif (20) de demande d’accès à un service lors d'une étape S7110. Puis, lors d'une étape S7120, le dispositif (20) de demande d’accès à un service transmet, à destination du dispositif intermédiaire (50), une ou plusieurs règles R de classification de trafic visant à répartir des données de ladite communication au travers d'au moins une des tranches sélectionnées. Une règle de classification peut être élaborée à partir de plusieurs critères tels que l’adresse destination du trafic, le couple [adresse source ; adresse destination], un identifiant de protocole, des numéros de port, ou n’importe quelle combinatoire de ces différents critères. Un sélecteur de trafic (« trafic selector ») est défini et il a la responsabilité d’associer le trafic à l’une ou l’autre de ces règles, selon le contenu des entêtes des paquets de données, par exemple. Le message incluant ces règles R est par exemple conforme au format décrit en référence à la FIG. 9 . Ces règles R sont reçues par le dispositif intermédiaire (50) lors d'une étape S7520. Enfin, l'étape S160 d'application des tranches réseaux et de la politique de gestion des flux sélectionnées est mise en œuvre, en appliquant, lors d'une étape S7530, les règles R reçues. La FIG. 8 est un exemple de format d’une option PCP pour échanger, entre le dispositif (20) de demande d'accès à un service et le dispositif intermédiaire (50), des paramètres relatifs aux tranches réseau et à la politique de gestion de flux sélectionnées, dans un exemple particulier de mise en œuvre. Ce format est par exemple conforme à la section 7.3 ("Options") de la spécification "Port Control Protocol (PCP) ", RC6887, publiée en Avril 2013 par l’IETF. Tel qu’illustré par la FIG. 8 , le champ "Option" comprend : un champ "Option Code" codé sur 8 bits et dont le bit de poids le plus fort indique si cette option est obligatoire ou optionnelle ; un champ "Reserved" codé sur 8 bits, habituellement valorisé à "0" en transmission, et ignoré en réception ; un champ "Option Length" codé sur 16 bits qui indique la longueur de la donnée relative à ladite option ; un champ "SLICE SET Count" codé sur 16 bits et qui indique le nombre d’objets SLICE_SET contenus dans cette option ; un champ "Slice SET Length" codé sur 16 bits et qui indique la taille d’un objet SLICE_SET ; un champ "Slice Type" codé sur 16 bits et qui indique le type de la tranche sélectionnée par le deuxième dispositif électronique ; un champ "SID Count" codé sur 8 bits et qui indique le nombre d’identifiants de tranche réseau ("Slice Identifier", SID) inclus dans un objet SLICE_SET. un champ "NID Count" codé sur 8 bits et qui indique le nombre d’identifiants de réseau ("Network IDentifier", NID) inclus dans un objet SLICE_SET. Selon une implémentation particulière, lorsque les champs "SID Count" ou "NID Count" ont pour valeur "0", ceci signifie qu’aucun SID ou NID n’est présent dans le message. La FIG. 9 est un exemple de format d’une option PCP pour transmettre des règles de classification de trafic. Tel qu’illustré par la FIG. 9 , le champ "Option" comprend notamment : un champ "SLICE Binding Count" codé sur 16 bits et incluant un nombre de règles de classification de trafic ; pour chaque règle, un champ "Binding Rule Length" codé sur 16 bits et délimitant les informations descriptives de la règle. pour chaque règle, un champ "Slice Type" ; pour chaque règle, un champ "Slice Count". La présence de SID étant optionnelle dans une règle, si champ "Slice Count" prend pour valeur "0", ceci signifie qu’aucun SID n’est présent dans le message. pour chaque règle, un champ "Traffic Selector" par exemple structuré conformément à la spécification "Dissemination of Flow Specification Rules", RFC8955, publiée par l’IETF en décembre 2020, ou conformément à la spécification "Dissemination of Flow Specification Rules for IPv6", RFC8956, également publiée par l’IETF en décembre 2020. Bien entendu, d’autres protocoles que le protocole TCP peuvent être envisagés pour échanger des paramètres relatifs aux tranches réseau et à la politique de gestion de flux sélectionnées entre le dispositif (20) de demande d'accès à un service et le dispositif intermédiaire (50), tels que le protocole UPnP (acronyme de "Universal Plug and Play"), le protocole IGD (acronyme de "Internet Gateway Device"), le protocole HTTPS (acronyme de "Hyper Text Transfer Protocol Secure"), le protocole CoAP (acronyme de "Constrained Application Protocol") ou le protocole NETCONF. Procédé de contrôle d’une communication au cours de laquelle sont échangées des données relatives à un service (S) entre un premier dispositif électronique et un deuxième dispositif électronique via au moins un réseau de télécommunication supportant une pluralité de tranches réseau, le procédé comprenant les étapes suivantes mises en œuvre par le deuxième dispositif électronique : une obtention (S250, S10) d’une donnée (SLICE_SET) représentative de tranches réseau supportées par ledit au moins un réseau et accessibles par le premier dispositif électronique ; une sélection (S270, S5100) de tranches réseau accessibles par les premier et deuxième dispositifs électroniques et compatibles avec une fourniture du service, et d’une politique de gestion des flux de la communication via les tranches réseau sélectionnées ; une transmission (S290, S5110), à destination du premier dispositif électronique (20), d'une donnée (SLICE_SET_SELECT) représentative des tranches réseau et de ladite politique de gestion des flux sélectionnées pour application, par le premier dispositif électronique, à cette communication. Procédé de contrôle selon la revendication 1, dans lequel la politique de gestion des flux comprend au moins un protocole de transport supporté par le premier dispositif électronique et permettant d’établir la communication sur des chemins multiples. Procédé de contrôle selon la revendication 1, dans lequel la politique de gestion des flux comprend au moins un mécanisme d'ordonnancement de paquets de données à appliquer par le premier dispositif électronique à ladite communication. Procédé de contrôle selon l'une des revendications 1 à 3, dans lequel la politique de gestion des flux comprend une contrainte sur une direction d'au moins un flux de la communication au travers d'au moins une des tranches réseau sélectionnées. Procédé de contrôle selon l'une des revendications 1 à 4, dans lequel la donnée (SLICE_SET) représentative des tranches réseau supportées par ledit au moins un réseau et accessibles par ledit premier dispositif électronique inclut au moins un type de tranche réseau et/ou au moins un identifiant de tranche réseau. Procédé de contrôle selon l'une des revendications 1 à 5, dans lequel la donnée (SLICE_SET) représentative des tranches réseau de la pluralité accessibles par ledit premier dispositif électronique inclut en outre au moins une donnée parmi : un identifiant de réseau, un identifiant de flux, un identifiant d’adresse, un nombre maximal de flux par tranche, une donnée représentative d’une contrainte sur une direction de flux. Procédé de contrôle selon l'une des revendications 1 à 6, comprenant en outre une sélection, par le deuxième dispositif, d'au moins une tranche réseau accessible par ledit deuxième dispositif, et adaptée à la fourniture du service (S), et/ou d’au moins une politique de gestion de flux de la communication à appliquer par ledit deuxième dispositif. Procédé de configuration d’une communication au cours de laquelle sont échangées des données relatives à un service (S) entre un premier dispositif électronique et un deuxième dispositif électronique via au moins un réseau de télécommunication supportant une pluralité de tranches réseau, le procédé comprenant les étapes suivantes mises en œuvre par le premier dispositif électronique : une réception (S140, S6250), en provenance du deuxième dispositif électronique, d'une donnée (SLICE_SET_SELECT) représentative d’au moins une tranche réseau accessible par les premier et deuxième dispositifs électroniques et compatible avec une fourniture du service (S), ladite donnée (SLICE_SET_SELECT) étant en outre représentative d'une politique de gestion de flux de la communication via ladite au moins une tranche réseau ; et, une application (S160, S6280) de ladite au moins une tranche réseau et de ladite politique de gestion des flux à la communication. Procédé de configuration selon la revendication 8, dans lequel le premier dispositif est un dispositif intermédiaire (50) auquel est connecté un dispositif (20) de demande d’accès au service (S), et le procédé comprend, sur requête du dispositif (20) de demande d'accès au service, une étape de transmission, par le dispositif intermédiaire (50) et à destination dudit dispositif (20) de demande d'accès au service, de la donnée (SLICE_SET) représentative des tranches réseau et de ladite politique de gestion des flux. Procédé de configuration selon la revendication 9 comprenant en outre les étapes suivantes, mises en œuvre par le dispositif intermédiaire (50) : une réception (S7520) d'au moins une règle de classification de trafic visant à répartir des données de ladite communication au travers d'au moins une des tranches sélectionnées ; et, une application (S7530) de ladite au moins une règle, de sorte à associer au moins un flux de ladite communication avec au moins une desdites tranches. Dispositif électronique, dit deuxième dispositif électronique, configuré pour mettre en œuvre le procédé de contrôle d’une communication selon l'une quelconque des revendications 1 à 7. Dispositif électronique, dit premier dispositif électronique, configuré pour mettre en œuvre le procédé de configuration d’une communication selon l'une des revendications 8 à 10. Dispositif électronique selon la revendication 12, ledit dispositif correspondant à un dispositif intermédiaire (50) auquel est connecté un dispositif (20) de demande d'accès à un service (S). Système de communication comprenant un premier dispositif électronique selon la revendication 12 ou 13, et un deuxième dispositif électronique selon la revendication 11.