FR 3153206 A1 20250321 FR 2309820 A 20230918 L’invention concerne un procédé d’établissement d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant une étape d’obtention (200) d’une information caractéristique d’au moins une interface de contrôle exposée par le réseau, une étape (202) de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue, et une étape (204) de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. Corrélativement, l’invention concerne un procédé de contrôle, par un serveur d’application, d’une communication établie selon le procédé d’établissement, ainsi que des dispositifs pour mettre en œuvre ces procédés. Figure 2. Procédés, dispositifs et système de contrôle d’une communication dans un réseau L'invention appartient au domaine des télécommunications, et plus particulièrement au domaine des services IP à valeur ajoutée. Plus précisément, l’invention concerne des procédés et des dispositifs pour appliquer un traitement différencié à des paquets de données échangés entre un terminal et un serveur par l’intermédiaire d’un réseau de communication. Art antérieur Les réseaux de communication modernes exposent des interfaces de programmation applicatives (ou API, pour « Application Program Interface » en anglais) qui permettent d’invoquer tout ou partie des services qu’ils supportent. Par exemple, les réseaux 5G supportent la fonction NEF (pour « Network Exposure Function » en anglais), qui a pour vocation d’exposer les capacités fonctionnelles des réseaux cœur 5G à des tiers, y compris à des environnements « non 3GPP » comme des réseaux fixes IP/MPLS. De telles API permettent par exemple à des développeurs (ou des fournisseurs) de services d’adapter dynamiquement la politique de qualité de service mise en place dans un réseau selon les services qu’ils proposent ou les besoins des clients qui accèdent à ces services. Les méthodes existantes pour invoquer ces API supposent généralement la mise en place préalable d’accords contractuels entre l’opérateur du réseau et les tiers souhaitant y accéder. La nécessité d’établir de tels accords a priori présente des limitations, notamment parce qu’il apparaît difficile pour un fournisseur de service de connaître a priori l’ensemble des réseaux susceptibles d’être utilisés par ses clients pour se connecter à un service. Par exemple, un opérateur d’une plateforme de vidéo à la demande peut difficilement convenir d’un accord préalable avec tous les opérateurs des réseaux susceptibles d’être utilisés par ses clients pour accéder au service. En outre, de tels accords ne permettent pas facilement de maintenir à jour une liste d’adresses permettant d’invoquer une API réseau particulière (par exemple, en cas de modification de l’alias ou de l’adresse IP pour joindre une API ou lorsque des API différentes sont utilisées selon le périmètre fonctionnel de cette API). Ainsi, il existe un besoin pour une méthode permettant à un fournisseur de service d’offrir une qualité de service personnalisée à ses clients au moyen d’API exposées par les différents réseaux qu’ils utilisent, et qui ne souffre pas les limitations évoquées ci-dessus. A cet effet, il est proposé un procédé d’établissement d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le terminal : Une étape d’obtention d’une information caractéristique de l’au moins une interface de contrôle exposée par le réseau, Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue, Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. De cette façon, un serveur (par ex. un serveur d’application ou un terminal distant) peut découvrir et invoquer une API (ou interface de contrôle) du réseau auquel se connecte un client particulier afin d’offrir à ce client un traitement différencié tel qu’une qualité de service adaptée au service exposé par ledit serveur d’application. Bien entendu, d’autres traitements différenciés peuvent être envisagés, comme une isolation du trafic caractéristique du service auquel accède un client, une protection particulière dudit trafic, un acheminement dudit trafic via des tunnels sécurisés, ou qui exploite des chemins redondants, etc. Le terminal obtient les caractéristiques d’une ou plusieurs interfaces exposées par un ou plusieurs réseaux auxquels ledit terminal est connecté et les indique à un serveur d’application auquel il souhaite accéder en transmettant ces informations dans une message. Ainsi, le serveur n’a pas à connaître au préalable les caractéristiques des API exposées par tous les réseaux susceptibles d’être utilisés pas ses clients pour le contacter. A partir des caractéristiques reçues, le serveur d’application peut invoquer une API exposée par un réseau utilisé par un client particulier et solliciter des ressources particulières offertes par ce réseau afin d’adapter la politique de qualité du service fourni par ledit serveur d’application pour ce client particulier, par exemple. Les paquets envoyés et/ou reçus par le terminal lorsqu’il communique avec le serveur bénéficient alors d’un traitement différencié par le réseau, permettant par exemple d’optimiser certaines caractéristiques de transmission (latence, débit, priorité, etc.) ou encore d’emprunter une tranche réseau particulière. Dans un mode de réalisation particulier, le terminal obtient l’information caractéristique d’au moins une interface de contrôle exposée par le réseau dans un message DHCP, un élément d’information PCO (Protocol Configuration Option) ou un message « Neighbor Discovery ». Une telle disposition permet avantageusement à un terminal d’obtenir une information caractéristique d’au moins une interface de contrôle du réseau dès son attachement au réseau ou lors de sa configuration par le réseau. L’information caractéristique de l’API exposée par le réseau peut avantageusement être transmise dans un message d'attachement au réseau, un message de configuration du terminal ou un message de découverte. De préférence, l’information est transmise dans un entête optionnel, de sorte que l’information peut être ignorée lorsqu’elle n'est pas supportée par un terminal. La transmission de l’information dans un élément d’information PCO (« Protocol Configuration Option » en anglais) d’un message NAS (« Non-Access Stratum » en anglais) tel que défini par le 3GPP (« 3rd Partnership Project ») ou la transmission de l’information dans un message de découverte IPv6 « Neighbor Discovery » tel que défini dans le standard RFC4861 permet de communiquer l’information dès l’établissement d’une session. Selon une réalisation particulière, le procédé est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants : Un identifiant d’API réseau, Au moins une adresse d’accès à une API réseau, Un type d’API réseau, Une ou plusieurs règles régissant les conditions d’applications d’une configuration, Une donnée d’identification opaque du terminal. L’identifiant, l’adresse et/ou le type d’API réseau reçue permettent au terminal de connaître les modalités d’accès à l’API. Les règles régissant les conditions d’application d’une configuration correspondent par exemple à des filtres dépendants de l’adresse destination, du protocole utilisé (par ex. UDP, TCP, QUIC, HTTP, ou SIP), etc. Le paramètre opaque est par exemple un jeton généré par le réseau permettant d’identifier le terminal dans le réseau sans pour autant divulguer à des tiers des informations propres au terminal ou à son utilisateur et donc potentiellement confidentielles. Ce faisant, l’opérateur réseau ne divulgue pas des informations qui sont susceptibles d’être utilisées par des tiers pour des besoins de traçabilité (« tracking » ou « profiling » en anglais). Les informations caractéristiques reçues peuvent être mémorisées par le terminal en association avec un identifiant du réseau et transmise à un serveur d’application en vue de configurer le réseau pour le service auquel le terminal souhaite accéder. Selon un mode de réalisation particulier, le terminal transmet l’information caractéristique d’au moins une interface de contrôle exposée par le réseau au serveur dans un champ d’option TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol), une trame QUIC, une option DCCP (Datagram Congestion Control Protocol), un entête HTTP (Hypertext Transfer Protocol) ou SIP (Session Initiation Protocol). En transmettant les informations concernant l’interface de contrôle exposée par le réseau dans un champ ou un entête d’un message d'établissement de communication selon un protocole de la couche transport, par exemple dans une option TCP, une extension UDP, une extension DCCP, une trame QUIC, ou encore un protocole de la couche application tel qu’un entête HTTP ou SIP, le terminal s’assure que le serveur d’application découvre au plus tôt les interfaces de contrôle du réseau afin de configurer l’accès au service. En outre, l’utilisation d’entêtes optionnels de messages permet de mettre en œuvre le procédé de l’invention avec des moyens techniques existants, facilitant ainsi le déploiement de la solution baptisée TANIT (pour « Terminal-Assisted dissimeNation of application programming Interfaces locaTors for network exposure » en anglais). Selon un mode particulier de réalisation, le procédé comprend en outre une étape de réception d’un message transmis par le serveur, le message comprenant au moins une consigne d’identification des paquets obtenue par le serveur via au moins une interface de contrôle du réseau dont les caractéristiques ont été transmises au serveur par le terminal, l’étape de communication comprenant la génération d’au moins un paquet de données conformément auxdites consignes d’identification. Lors de l’invocation par le serveur d’une interface de contrôle d’un réseau dont les caractéristiques ont été transmises par le terminal, le serveur obtient des consignes permettant de générer des paquets de données comprenant un identifiant à partir duquel le réseau peut appliquer auxdits paquets un traitement différencié, et transmet ces consignes au terminal. Par exemple, une consigne d’identification peut consister en un identifiant de marquage, un jeton, un tag particulier ou tout autre information adaptée pour que le réseau puisse identifier le paquet et lui appliquer un traitement particulier selon la configuration demandée par le serveur. De cette façon, le réseau peut appliquer un traitement différencié aux paquets de données transmis par le terminal à destination du serveur. De façon correspondante au procédé d’établissement d’une communication, il est également proposé un procédé de contrôle d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le serveur : Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal, Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique, Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle. De cette façon, un serveur d’application reçoit des indications lui permettant d’invoquer une API exposée par un réseau de communication particulier utilisé par le terminal pour contacter le serveur et contrôler ainsi la configuration de ce réseau pour appliquer un traitement différencié aux paquets de données échangées entre le terminal et le serveur. Ces indications sont obtenues par le terminal auprès d’une fonction dédiée du réseau, par exemple lors de son attachement au réseau, et transmises au serveur afin que le réseau puisse procéder à une configuration réseau adaptée au service que le serveur fournit à ce terminal. Le procédé permet avantageusement à un serveur d’application d’invoquer une configuration réseau particulière sans connaître à priori les caractéristiques des réseaux susceptibles d’être utilisés par les terminaux pour se connecter au service. Des paquets de données peuvent ainsi être échangés entre le terminal et le serveur en bénéficiant d’un traitement différencié. Selon un mode particulier de réalisation, le procédé de contrôle comprend en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, les paquets envoyés au cours de l’étape d’envoi étant générés conformément auxdites consignes d’identification obtenues. Le serveur obtient ainsi des consignes lui permettant de générer des paquets de données comprenant un identifiant à partir duquel le réseau peut appliquer un traitement différencié. Par exemple, une consigne d’identification peut consister en un identifiant de marquage, un jeton, un tag particulier ou tout autre information adaptée que le serveur peut insérer dans les paquets de données envoyés à destination du terminal pour qu’ils soient transmis via le réseau en sollicitant des ressources particulières invoquées via l’interface de contrôle dudit réseau. Selon un mode de réalisation particulier, le procédé de contrôle est tel qu’il comporte en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, et une étape de réception d’au moins un paquet de données transmis par le terminal en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle, les paquets reçus étant générés par le terminal conformément auxdites consignes d’identification transmises. De cette façon, le terminal dispose de la consigne d’identification lui permettant de générer des paquets comprenant une information d’identification permettant au réseau d’appliquer un traitement différencié selon l’information d’identification. Ainsi, le serveur reçoit des paquets de données auxquels le réseau a appliqué un traitement différencié sur la base de l’information d’identification insérée dans les paquets par le terminal. Selon une réalisation particulière, le procédé de contrôle est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants : Un identifiant d’API réseau, Au moins une adresse d’accès à une API réseau, Un type d’API réseau, Une ou plusieurs règles régissant les conditions d’applications d’une configuration, Une donnée d’identification opaque du terminal. Dans un mode particulier de réalisation, le procédé de contrôle est tel que l’information caractéristique d’au moins une interface de contrôle exposée par le réseau est reçue dans un champ d’option TCP ou UDP, une trame QUIC, une option DCCP, un entête HTTP ou SIP. L’information caractéristique peut ainsi être transmise dans un message d’un protocole de la couche de transport (TCP, UDP, QUIC ou DCCP par exemple) ou bien dans un message d’un protocole de la couche applicative (comme SIP ou HTTP par exemple). D’autres modes de réalisation peuvent être considérés tels que l’utilisation d’une option IPv4 ou un entête d’extension IPv6 (« Extension Header » en anglais). A noter que l’utilisation de la couche IP pour véhiculer l’information caractéristique d’au moins une interface de contrôle exposée par le réseau est plus robuste en cas de communications limitées à un seul domaine (par ex. « Limited Domains », « controlled environment », ou « managed networks »). Selon un autre aspect, l’invention concerne un dispositif d’établissement d’une communication avec un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions adaptées pour mettre en œuvre les étapes suivantes : Une étape d’obtention d’une information caractéristique de l’au moins une interface de contrôle exposée par le réseau, Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue, Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire d’une interface de contrôle indiquée par le terminal. L’invention vise aussi un terminal de communication comprenant un dispositif d’établissement d’une communication tel que décrit précédemment. Selon encore un autre aspect, l’invention concerne un dispositif de contrôle d’une communication établie avec un terminal par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur couplé à une mémoire dans laquelle sont enregistrées des instructions adaptées pour mettre en œuvre les étapes suivantes : Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par le réseau de communication, Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique, Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle. L’invention concerne aussi un serveur comprenant un dispositif de contrôle d’une communication tel que décrit ci-dessus. Il est également proposé un système de communication comprenant au moins un terminal de communication et un serveur comprenant respectivement un dispositif d’établissement de communication et un dispositif de contrôle tels que décrits ci-dessus. Dans un mode particulier de réalisation, les différentes étapes du procédé d’établissement d’une communication et du procédé de contrôle sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi un programme d’ordinateur comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de communication et/ou d’un procédé de contrôle tels que décrits ci-dessus, lorsque le programme est exécuté par un processeur. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé d’établissement d’une communication et/ou d’un procédé de contrôle. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, une mémoire flash, ou encore un moyen d'enregistrement magnétique, comme un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question. Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes des procédés d’établissement de communication et/ou de contrôle. Les dispositifs, systèmes et programmes présentent des avantages analogues à ceux des procédés auxquels ils correspondent. Brève description des figures D'autres caractéristiques et avantages apparaîtront à la lecture d’un mode de réalisation préféré décrit en référence aux dessins annexés parmi lesquels : la FIG. 1 représente un environnement adaptée pour mettre en œuvre les procédés d’établissement d’une communication et de contrôle d’une communication selon un mode particulier de réalisation, la FIG. 2 est un ordinogramme représentant les principales étapes d’un procédé d’établissement d’une communication selon un mode de réalisation particulier, la FIG. 3 est un ordinogramme représentant les principales étapes d’un procédé de contrôle d’une communication selon une réalisation particulière, la FIG. 4 est un diagramme combiné montrant les principales étapes des procédés d’établissement et de contrôle d’une communication et des échanges de messages adaptés pour mettre en œuvre ces procédés dans un mode particulier de réalisation, la FIG. 5 est un exemple de structure de données adaptée pour véhiculer des informations caractéristiques d’une interface de contrôle exposée par le réseau selon une réalisation particulière, la FIG. 6 montre un exemple de structure de données adaptée pour transmettre à un serveur une description d’une interface de contrôle exposée par le réseau selon une réalisation particulière, la FIG. 7 est un diagramme en bloc montrant une architecture d’un dispositif adapté pour mettre en œuvre le procédé d’établissement d’une communication selon une réalisation particulière, et la FIG. 8 est un diagramme en bloc montrant une architecture d’un dispositif adapté pour mettre en œuvre le procédé de contrôle d’une communication selon une réalisation particulière. Description détaillée La FIG. 1 représente une architecture réseau permettant à des terminaux d’accéder à des services. L’environnement de la FIG. 1 comprend un terminal 100 et un terminal 101 qui sont par exemple des terminaux de communication tels que des smartphones, des ordinateurs, des télévisions connectées, ou tout autres équipements adaptés pour accéder à un service. Un terminal au sens de cette description peut ainsi être un UE (« User Equipment » en anglais), une instance de fonction service, un CPE (pour «Customer Premises Equipment » en anglais), etc. Le terminal peut être mobile ou fixe. L’environnement comprend un ou plusieurs serveurs d’application AS hébergés dans un réseau de communication 103. Un serveur AS héberge par exemple un ou plusieurs services, tels que des services de diffusion audiovisuels et/ou de stockage en ligne auxquels les utilisateurs des terminaux 100 et 101 ont souscrit et peuvent accéder. Bien entendu, un AS peut héberger tout type de service sans qu’il soit nécessaire de modifier l’invention. En outre, le service peut être offert par le serveur AS qui est en contact avec le terminal ou par d'autres serveurs non visibles au client (« back-end »). Aucune hypothèse n'est faite quant à la structure du service. Dans l’exemple de la FIG. 1 , les serveurs AS sont opérés par un opérateur distinct des opérateurs des réseaux de communication 102 et 104 par l’intermédiaire desquels les terminaux 100 et 101 sont respectivement connectés. Le réseau 102 est par exemple un réseau d’accès cellulaire, tel qu’un réseau 3G, 4G, 5G ou B5G («Beyond 5G » en anglais), ou un réseau Wi-Fi® ou encore WiMax® auquel le terminal 100 peut accéder. Le réseau 104 est par exemple un réseau fixe, comme un réseau IP/MPLS (« Internet Protocol/ Multiprotocol Label Switching » en anglais). Dans l’exemple de la FIG. 1 , le terminal 100 le terminal 101 peuvent accéder au réseau 104. L’interconnexion des réseaux 102, 104 et 103 permet au terminal 100 d’accéder à un serveur d’application AS du réseau 103 par l’intermédiaire du réseau 102 et/ou du réseau 104, et permet au terminal 101 d’accéder à un serveur d’application AS du réseau 103 par l’intermédiaire du réseau d’accès 104. Les réseaux 102 et 104 offrent la possibilité à des tiers de personnaliser le service rendu par le réseau au moyen d’interfaces de contrôle (ou API, pour Application Programming Interface) par lesquelles les réseaux 102 et 104 exposent certaines de leurs capacités fonctionnelles. L’interface de contrôle permet par exemple de configurer un marquage des paquets de certaines communications au sein du réseau de façon à offrir une qualité de service différenciée, et/ou d’acheminer certains paquets via des liens sécurisés ou redondants, par exemple. Dans la suite, aucune hypothèse n’est faite quant à la nature du traitement différencié contrôlé via une API exposée par un réseau. Les réseaux 102 et 104 comprennent en outre au moins un contrôleur CTRL, par exemple un contrôleur SDN (pour « Software-Defined Network » en anglais), chargé de coordonner les actions nécessaires à la mise en œuvre d’une configuration particulière. Dans certaines réalisations, la fonction de contrôle CTRL et la fonction NEF sont une même entité. Un ou plusieurs contrôleurs peuvent être déployés dans un réseau. Lesdites fonctions CTRL/NEF ne sont pas forcément sur le chemin emprunté par les paquets de données échangés entre un terminal et un serveur. On notera que dans cette description, les termes « interface de contrôle réseau », « interface de configuration » et « API » sont indistinctement utilisés pour désigner un ensemble de fonctions mises à disposition des tiers par le réseau et accessibles à distance afin de permettre à des services, des applications ou des logiciels tiers de commander un paramétrage particulier et/ou un traitement différencié des flux par le réseau. Par exemple, lorsqu’un réseau met en œuvre des « network slices » (soit « tranches réseau » en français), l’utilisation d’une API permet par exemple d’affecter une tranche particulière à un service donné ou à l’acheminement d’une partie des paquets de données échangés pour ce service. Une tranche réseau peut être définie comme un réseau privé virtuel (RPV, ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe ou mobile. Les caractéristiques d’une tranche réseau sont essentiellement exprimées en termes de capacité (bande passante) et de qualité de service (par ex., latence, temps de transit unidirectionnel, etc.), voire de sécurité (par ex., préservation de la confidentialité des informations transmises au sein du RPV moyennant l’utilisation de techniques de chiffrement). Ainsi, et à titre d’exemple, l’opérateur du service AS peut utiliser l’API exposée par le réseau 102 pour demander qu’une politique de qualité de service particulière puisse être mise en œuvre au bénéfice de l’utilisateur du terminal 100 lorsque celui-ci accède à ses services. De même, l’opérateur du service AS peut utiliser l’API exposée par le réseau 104 pour demander qu’une politique de qualité de service particulière puisse être mise en œuvre au bénéfice de l’utilisateur du terminal 101 lorsque celui-ci accède à ses services. Cependant, comme on l’a déjà indiqué, en l’état actuel de la technique, l’opérateur du service AS doit au préalable convenir d’accords avec les opérateurs des réseaux 102 et 104 pour découvrir et utiliser les API offertes par ces réseaux. Or, l’opérateur du service AS ne connaît pas à priori les réseaux qui seront utilisés par ses clients pour accéder à ses services. Les procédés et dispositifs objets de la présente invention permettent de lever de telles limitations. Un mode de réalisation particulier du procédé d’établissement d’une communication va maintenant être décrit en référence aux figures 2 et 4. Dans la description qui suit, le terminal 100 de la FIG. 1 met en œuvre une réalisation particulière du procédé d’établissement de communication et le serveur AS représenté sur la FIG. 1 met en œuvre le procédé de contrôle selon un mode particulier de réalisation. La FIG. 2 est un ordinogramme représentant les principales étapes d’un procédé d’établissement de communication selon un mode particulier de réalisation. La FIG. 4 est un diagramme de flux combiné montrant des échanges de messages entre un terminal, un serveur d’application et différentes entités d’un réseau auquel le terminal est connecté. Ce diagramme décrit les étapes des procédés d’établissement d’une communication et de contrôle, selon une réalisation particulière. Des références identiques sont utilisées dans les figures 2, 3 et 4 pour désigner les étapes des procédés d’établissement d’une communication et de contrôle. Lors d’une première étape 200, le terminal 100 reçoit des informations caractéristiques d’une ou plusieurs interfaces de configuration du réseau auquel le terminal est connecté. Les informations reçues comprennent par exemple un ou plusieurs éléments parmi les éléments suivants : un identifiant d’API réseau, au moins une adresse d’accès à une API réseau (ou un alias, un nom de domaine), un type d’API réseau (REST, RPC, SOAP, …), une ou plusieurs règles régissant les conditions d’application d’une configuration (CRE, pour « Classification Rule Entry » en anglais, par exemple une règle de filtrage en fonction de l’adresse destination ou du protocole utilisé), une donnée d’identification opaque du terminal, telle qu’un jeton, permettant d’identifier le terminal dans le réseau sans divulguer des informations propres au terminal ou à son utilisateur. Ces informations sont transmises au terminal dans un message envoyé par une fonction réseau, par exemple un contrôleur CTRL, un serveur DHCP ou un routeur d’accès. Un tel message est par exemple envoyé suite à une sollicitation du terminal, c’est-à-dire en réponse à un message envoyé par le terminal. De plus, dans une réalisation particulière, un tel message peut également être envoyé sans sollicitation préalable, c’est-à-dire que le réseau annonce ces informations aux terminaux sans attendre une requête explicite de la part de ces terminaux. Dans une réalisation particulière, les informations sont obtenues par le terminal lors de son attachement au réseau. Pour cela, le terminal envoie par exemple une requête DHCP comprenant une option particulière vers un équipement du réseau. La réception d’une telle requête DHCP par l’équipement réseau provoque l’envoi d’une réponse DHCP comprenant, outre les données traditionnellement comprises dans un tel message, des informations caractéristiques des interfaces de configuration exposées à des tiers par le réseau. Ces informations sont par exemple transmises dans une ou plusieurs options DHCP telles que définies dans le document RFC8415. Dans une variante, les informations reçues peuvent comprendre une ou plusieurs consignes permettant au terminal de générer lui-même un identifiant opaque. Par exemple, la présence d’un paramètre « Self_Terminal_ID » valorisé à « 1 » est une indication explicite que le terminal doit générer un identifiant non persistant. Si le réseau retourne ce paramètre, alors il ne doit pas inclure « Terminal_ID » dans le même message. Cette variante est avantageuse car elle permet d’éviter d’exposer une information probablement invariable dans le temps qui pourrait être utilisée à des fins malveillantes (par exemple traçage du terminal). La FIG. 4 montre un tel échange de messages : le terminal envoie un message 400, tel qu’une requête DHCP comprenant une option particulière. L’option est particulière en ce qu’elle permet au terminal d’indiquer qu’il souhaite recevoir des indications relatives à une ou plusieurs interfaces de contrôle exposées par ce réseau. Lorsque la fonction réseau destinataire reçoit cette requête, et lorsque ladite option particulière est présente dans la requête, ladite fonction réseau insère des informations caractéristiques d’au moins une interface de contrôle dans une réponse 401, par exemple une réponse DHCP comprenant une option particulière. Bien entendu, ces informations peuvent être encodées dans un même élément d’information ou être retournées séparément sans qu’il soit nécessaire de modifier l’invention. La FIG. 5 montre un exemple d’un entête d’option DHCPv6 comprenant des informations caractéristiques d’une interface de contrôle exposée par le réseau. Dans cet exemple, le type de l’option « OPTION_V6_TANIT » et sa longueur « Length » sont encodés chacun sur 16 bits. L’option comprend en outre un champ « API_ID » de 16 bits véhiculant un identifiant d’une API exposée par le réseau précédé de sa longueur « API_ID_LENGTH », une adresse d’un serveur exposant ladite API « API_LOCATORS » également précédé de la longueur du champ « API_LOCATORS_Length », un champ comprenant un ensemble de règles d’utilisation de l’API « CRE » précédé de sa longueur « CRE_LENGTH », un type d’API « API_TYPE » et un identifiant opaque affecté au terminal « Terminal_ID ». Bien entendu, la structure de la FIG. 5 est donné à titre d’exemple non limitatif, et d’autres formats peuvent être envisagés pour transmettre ces informations. En particulier, la structure peut comprendre un nombre et des types de paramètres qui diffèrent de ceux présentés dans l’exemple de la FIG. 5 , et ces paramètres peuvent être transmis dans différentes options et/ou différents messages. Dans une réalisation particulière, le terminal 100 mémorise les informations reçues en association avec un identifiant du réseau, par exemple un NID (« Network Identifier » en anglais) obtenu dans une option « Access Network Domain Name » d’une réponse DHCP ou avec un identifiant de l’interface réseau au travers de laquelle les informations ont été reçues. Cette association est maintenue localement par le terminal 100 tant que l’attachement avec le réseau identifié par le NID est actif. Ainsi, ces informations restent disponibles tant que le terminal est attaché à ce réseau, mais sont supprimées lorsque l’interface via laquelle les informations ont été reçues est désactivée. De cette façon, les informations relatives aux interfaces exposées par le réseau peuvent être transmises par le terminal 100 à différents services auxquels il accède. Lorsque des informations relatives à au moins une interface de contrôle sont obtenues, le terminal 100 accède à un service offert par un serveur d’application AS. Le procédé d’établissement de communication comprend une étape 202 au cours de laquelle le terminal 100 transmet les informations obtenues à l’étape 200 au serveur d’application AS. Plus précisément, lorsque le terminal 100 souhaite établir une communication avec le serveur AS via un réseau auquel il est connecté, il recherche dans sa mémoire une entrée correspondant à l’identifiant de ce réseau à laquelle sont associées des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par le réseau. Si des informations relatives à une interface de contrôle sont disponibles pour l’identifiant recherché, le terminal transmet ces informations au serveur AS dans un message. Selon une réalisation particulière, cette information est encodée et transmise au serveur d’application AS sous la forme d’une option TCP, une option UDP, une option DCCP, une trame QUIC, ou un entête HTTP ou SIP. Selon un mode particulier de réalisation, l’étape 202 est précédée d’une étape optionnelle 201 au cours de laquelle le terminal 100 transmet au serveur AS un message 402 comprenant une indication selon laquelle il dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par un réseau auquel il est connecté et reçoit en retour un message 403 du serveur AS comprenant une indication relative au fait que le serveur AS est disposé à recevoir une telle information. De cette manière, le terminal sait si le serveur AS auquel il se connecte met en œuvre le procédé de contrôle objet de la présente invention et si le serveur AS est disposé à recevoir les informations obtenues par le terminal lors de l’étape 200. Dans une réalisation particulière, le message 402 est un segment TCP SYN échangé avec le serveur AS lors de la phase d’établissement de connexion TCP (« handshake » en anglais), et le message 403 est un segment SYN/ACK échangé lors de cette même phase d’établissement de connexion TCP. De cette façon, il est possible de déterminer dès l’établissement de la connexion avec le serveur, sans latence, et avec un faible surcoût de signalisation, si le serveur AS est adapté à recevoir des informations concernant les interfaces exposées par le réseau et telles que transmises par le terminal. Un message d’erreur reçu du serveur (ou d’une manière extrême la clôture de la connexion) est une indication que celui-ci n’est pas adapté pour recevoir de telles informations. Lorsque le terminal 100 reçoit du serveur AS le message 403, confirmant que le serveur AS est adapté pour recevoir des informations relatives à des interfaces de contrôle exposées par le réseau 102, il met en œuvre une étape 202 au cours de laquelle il transmet au serveur AS au moins un message 404 comprenant une annonce de l’API réseau associée au réseau via lequel la communication est établie. Le message 404 est par exemple une option TCP, une option UDP, une trame QUIC, une option DCCP, etc. La FIG. 6 montre un exemple d’une structure d’option TCP adaptée pour transmettre au serveur AS une description d’une interface de contrôle exposée par le réseau 102 selon une réalisation particulière. Ainsi, le terminal 100 envoie les informations relatives à au moins une interface de contrôle au serveur AS dans un message 404 comprenant un descripteur qui annonce l’API réseau associée au réseau via lequel la communication est établie. Dans une variante, le terminal 100 peut annoncer les informations caractéristiques des API des autres réseaux via lesquels certains flux de ladite communication peuvent transiter, et le terminal peut également inclure les API de ces autres réseaux. Par exemple, le message 404 peut comprendre des descripteurs relatifs aux interfaces de contrôle des réseaux 102 et 104. Dans ce cas, les informations caractéristiques d’une API doivent notamment préciser l’identifiant du réseau. Cet identifiant peut être un identifiant d’adresse (AddressID), une adresse IP, un numéro de système autonome (« Autonomous System Number » en anglais, ou ASN), etc. Le terminal 100 peut en outre insérer un jeton « TERMINAL_SUPPLIED_ID » pour aider le réseau à corréler l’identifiant présenté par le serveur avec un identifiant du terminal tel que connu par le réseau. Dans une variante « TERMINAL_SUPPLIED_ID » est une copie du « TERMINAL_ID ». En réponse au message 404 envoyé au serveur AS, le terminal 100 peut recevoir un message optionnel 410 lors d’une étape 203, comprenant un identifiant de marquage généré par le réseau 102. L’identifiant de marquage est destiné à être inséré dans les messages transmis par le terminal 100 à destination du serveur AS afin que les messages transmis par le terminal 100 au serveur AS puissent bénéficier d’un traitement différencié par le réseau 102 configuré suite à une demande du serveur AS à partir des informations transmises au serveur AS dans le message 404. Ainsi, selon l’identifiant indiqué par le terminal 100 dans les messages envoyés à destination du serveur AS, le réseau applique un traitement particulier à ces messages. Cet identifiant peut être par exemple, un identifiant de connexion QUIC (Source ou Destination Connection Identifier), une valeur DSCP (« Diffserv Code Point »), une valeur du champ Flow Label d’un entête de paquet IPv6, etc. L'identifiant peut être encodé dans un seul ou plusieurs champs d'un message. L’identification est typiquement effectuée par un nœud de bordure tel qu’un routeur d’accès ou un routeur d’interconnexion. Un tel nœud peut maintenir, retirer ou réécrire l’information d’identification avant d’acheminer le paquet et d’invoquer les ressources nécessaires pour appliquer un traitement différencié. A l’étape 204, le terminal 100 échange des paquets de données avec le serveur AS en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. Par exemple, le réseau peut appliquer des règles de classification de trafic particulières, ou encore transmettre les paquets de données vers une tranche réseau particulière. Une réalisation particulière du procédé de contrôle d’une communication mis en œuvre par le serveur AS de la FIG. 1 va maintenant être décrite en référence aux figures 3 et 4. La FIG. 3 est un ordinogramme représentant les principales étapes d’un procédé de contrôle selon une réalisation particulière. Dans un mode de réalisation particulier, le procédé comprend une première étape 300 au cours de laquelle le serveur AS reçoit un premier message 402 en provenance du terminal 100, le message 402 comprenant une indication selon laquelle le terminal 100 dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de contrôle exposées par le réseau 102 auquel il est connecté. Un tel message est par exemple un message de contrôle ou un message de données. Par exemple, il peut s’agir d’un segment TCP SYN échangé lors d’une phase d’établissement de connexion TCP comprenant une option TCP dans laquelle sont encodées les capacités du terminal 100 à transmettre l’information relative à des interfaces exposées par le réseau 102. D’autres exemples comprennent l’encodage de l’information dans une option UDP, une option DCCP ou un paramètre de transport QUIC. A la réception du message 402, le serveur AS détecte la présence dans ce message d’une indication selon laquelle le terminal 100 dispose d’une capacité à transmettre des informations caractéristiques d’une ou plusieurs interfaces de configuration exposées par le réseau 102. Le serveur AS répond alors au terminal 100 par un message 403 dans lequel il insère une indication particulière confirmant qu’il est adapté pour recevoir une telle information. Cette réponse est par exemple transmise dans un segment TCP SYN/ACK de la phase d’établissement de connexion TCP, ou dans une option UDP, ou dans une option DCCP ou selon un paramètre de transport QUIC. Cet échange de messages préliminaire permet au terminal 100 et au serveur AS d’échanger leurs capacités à mettre en œuvre les procédés selon l’invention. Dans certaines réalisations, il est toutefois possible de s’affranchir de cette phase sans pour autant modifier l’invention. Par exemple, le terminal et le serveur peuvent être configurés au préalable conformément à un standard imposant le support de procédés conformes à la présente invention, rendant inutile l’étape préliminaire d’échange de capacités. A l’étape 301, le serveur AS reçoit un message 404 transmis par le terminal 100, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau 102 auquel est connecté le terminal. Le message 404 comprend par exemple une option TCP, une option UDP, une trame QUIC, une option DCCP, etc. Il peut en outre s’agir d’un message de signalisation ou de données. La réception du message 404 permet ainsi au serveur de connaître les caractéristiques d’une ou plusieurs interfaces de contrôle exposée(s) par le réseau auquel est connecté le terminal 100. Selon une réalisation particulière, le message 404 comprend non seulement une information caractéristique d’une ou plusieurs interfaces de contrôle du réseau 102 auquel le terminal 100 est connecté, mais aussi un ou plusieurs descripteurs d’interface d’un autre réseau par lequel des flux sont susceptibles de transiter. Par exemple, le message 404 peut comprendre un descripteur correspondant à une première interface exposée par un réseau d’accès cellulaire auquel le terminal est connecté, et un descripteur correspondant à une deuxième interface de contrôle exposée par un réseau d’accès terrestre, par exemple un réseau d’accès optique, accessible par le terminal. De cette manière, le serveur AS peut anticiper un éventuel basculement du trafic sur l’un ou l’autre des réseaux utilisables par le terminal selon les instructions de configuration exécutées par les deux réseaux. L’étape 302 du procédé de contrôle comprend le contrôle de la configuration du réseau 102 par le serveur AS à partir des informations reçues à l’étape 301. Plus précisément, le serveur AS invoque une ou plusieurs fonctions offertes par l’interface exposée par le réseau 102 pour configurer et appliquer une politique de qualité de service particulière pour les messages échangés avec le terminal 100 au travers du réseau 102. Par exemple, le serveur AS peut configurer le réseau pour que les paquets de données échangés avec le terminal 100 utilisent une tranche réseau particulière optimisée pour le service. Le serveur AS demande une configuration spécifique du réseau en invoquant une API dont les caractéristiques sont transmises par le terminal 100 dans le message 404. Pour cela, le serveur envoie par exemple une requête HTTP POST vers un serveur NEF dont l’adresse et les paramètres d’accès ont été communiqués par le terminal 100 dans le message 404. La requête POST comprend les arguments nécessaires pour invoquer cette API. Ces arguments sont par exemple configurés pour commander au réseau la classification de certains flux au titre d’une tranche, la priorisation de tout ou partie des flux de cette communication, l’invocation d’une fonction service locale (par ex. fonction de transcodage), ou la demande de servir ce terminal depuis un cache plus proche, etc. Les arguments peuvent également inclure les informations de classification pour identifier les paquets éligibles au traitement demandé. La requête POST peut être décomposée en plusieurs requêtes. Selon une réalisation particulière, l’étape 302 de configuration comprend une sous-étape préalable d’obtention des capacités de l’API. Pour cela, le serveur AS interroge par exemple le serveur NEF dont l’adresse est consignée dans le message 404 et obtient en réponse les capacités de contrôle offertes par l’interface de contrôle (API). Plus précisément, le serveur AS envoie par exemple une requête 405, telle qu’une requête HTTP GET, pour récupérer la liste des fonctions (« capabilities » en anglais) supportées par cette API en utilisant l’adresse renseignée dans le message 404, et reçoit en retour un message de réponse 406 comprenant une liste de capacités. Dans une variante, l’API réseau peut consigner dans la réponse 406 à la requête 405 des informations de classification de trafic qui peuvent être communiquées au préalable par le serveur à des terminaux afin de faciliter l’établissement de communications futures au titre du même service. Ce mode a pour objectif d’optimiser le délai nécessaire pour la mise en place d’un traitement différencié pour ces terminaux lorsque ces derniers se connectent au service. Par exemple, sur réception du message 407 par une fonction NEF du réseau 102, cette dernière extrait les informations communiquées par le serveur AS et procède à des vérifications (par exemple, la fonction NEF vérifie la disponibilité des ressources permettant d’offrir le service différencié demandé, l’absence de consignes pour bloquer ce serveur, validité de l’identifiant du terminal). Si la fonction NEF accepte de répondre positivement à la requête 407 du serveur AS pour une communication avec le terminal 100, la fonction NEF définit les actions nécessaires à mettre en œuvre dans le réseau pour fournir un traitement différencié du trafic caractéristique de cette communication. Ces actions sont par exemple coordonnées par un contrôleur réseau CTRL (typiquement, un contrôleur SDN). Dans une variante, ledit contrôleur CTRL est l’entité NEF qui expose l’API réseau. Pour cela, la fonction NEF peut transmettre un message 409 au contrôleur réseau, comprenant le paramétrage souhaité. Lors d’une étape optionnelle 303, le serveur AS reçoit un message de confirmation 408 en réponse à la requête 407. Dans une réalisation particulière, le message de confirmation 408 comprend des informations pour faciliter l’identification des paquets éligibles au traitement différencié, par exemple des informations de marquage pour les paquets envoyés depuis le serveur AS vers le terminal 100 et/ou des informations de marquage pour les paquets envoyés depuis le terminal 100 vers le serveur AS. Selon un mode particulier de réalisation, le serveur AS transmet un message 410 au terminal 100 dans lequel sont incluses les informations de marquage reçues dans le message 408. De cette façon, le terminal 100 peut insérer une information de marquage adaptée dans les paquets envoyés à destination du serveur AS afin que le réseau 102 puisse appliquer à ces paquets le traitement différencié demandé par le serveur AS à l’étape 302. L’identification est typiquement effectuée par un nœud de bordure tel qu’un routeur d’accès ou un routeur d’interconnexion. Un tel nœud peut maintenir, retirer ou réécrire l’information d’identification avant d’acheminer le paquet et d’invoquer les ressources nécessaires pour appliquer un traitement différencié. De façon optionnelle, le serveur AS peut, lors d’une étape 305, demander au réseau 102 de mettre fin au traitement personnalisé des paquets de données échangés avec le terminal 100. Pour cela, le serveur AS transmet par exemple un message 412 à la fonction NEF, le message comprenant une commande réseau adaptée pour mettre fin au traitement différencié. La FIG. 7 représente une architecture d’un dispositif 700 adapté pour mettre en œuvre le procédé d’établissement d’une communication, selon un mode particulier de réalisation. Le dispositif 700 comprend un module de traitement de données composé d’un espace de stockage 701, par exemple une mémoire (MEM), une unité de traitement 702, équipée par exemple d'un microprocesseur (PROC), et pilotée par un programme d'ordinateur (PGR) 703 dont les instructions sont configurées pour mettre en œuvre le procédé d’établissement d’une communication tel que décrit précédemment en référence aux figures 2 et 4. A l'initialisation, les instructions de code du programme d'ordinateur 703 sont par exemple chargées dans la mémoire 701 avant d'être exécutées par le processeur de l'unité de traitement 702. Le microprocesseur de l'unité de traitement 702 met en œuvre, selon les instructions du programme d'ordinateur 703, les étapes du procédé d’établissement d’une communication tel que décrit précédemment en référence aux figures 2 et 4. Pour cela, le dispositif 700 comprend des moyens de communication 704, par exemple une interface réseau cellulaire 3G, 4G, 5G, réseau sans fil Wi-Fi® ou Wimax®, une interface optique ou encore une interface Ethernet. Les moyens de communication permettent au dispositif 700 de se connecter à un réseau de communication et échanger des données avec d’autres dispositifs. Le dispositif 700 comprend aussi un module 705 d’obtention d’informations caractéristiques d’au moins une interface de contrôle exposée par le réseau. Pour cela, le module 705 coopère avec les moyens de communication 704 pour générer et transmettre un message à une entité de contrôle d’un réseau, le message comprenant une indication adaptée pour commander à l’entité de contrôle l’insertion d’informations caractéristiques d’au moins une API exposée par ledit réseau dans une réponse au message. Le module 705 est en outre configuré pour permettre la réception d’un message en provenance de l’entité de contrôle comprenant au moins un descripteur d’une interface de contrôle exposée par le réseau comprenant au moins une adresse permettant d’invoquer ladite interface de contrôle. Le module 705 est par exemple mis en œuvre par des instructions de programme d’ordinateur configurées pour mettre en œuvre l’étape 200 du procédé d’établissement d’une communication selon une réalisation particulière. Le dispositif 700 comprend également un module de configuration 706 adapté pour transmettre une information caractéristique d’une interface de contrôle du réseau reçue par le module 705. Selon un mode de réalisation particulier, le module est mis en œuvre par des instructions de programme d’ordinateur configurées pour générer un message comprenant une structure de données particulière, par exemple un champ d’option au format TLV (Type Longueur Valeur), comprenant au moins une adresse d’une interface de contrôle obtenue par le module 705 et un identifiant du dispositif, et pour coopérer avec les moyens de communication 704 pour transmettre le message à un serveur d’application hébergeant un service auquel le dispositif souhaite accéder. Le dispositif 700 comprend en outre un module 707 de transfert de données adapté pour coopérer avec les moyens de communication afin d’échanger des données avec un serveur en sollicitant des ressources réseau invoquées par ledit serveur par l’intermédiaire de d’une interface de contrôle dont les caractéristiques ont été transmises par le module 706. Le module 707 est par exemple mis en œuvre par des instructions de programme d’ordinateur configurées pour mettre en œuvre l’étape 204 du procédé d’établissement d’une communication décrite ci-avant. Dans une réalisation particulière, le module 707 est adapté pour marquer des paquets transmis au serveur d’application par les moyens de communication 704. Selon un mode de réalisation particulier, le dispositif est intégré dans un terminal de communication, par exemple dans un équipement utilisateur (UE), un téléphone mobile, un ordinateur, un décodeur vidéo, une passerelle, un objet connecté ou tout autre dispositif susceptible d’accéder à des services hébergés par un serveur d’application. La FIG. 8 représente une architecture d’un dispositif 800 adapté pour mettre en œuvre le procédé de contrôle d’une communication, selon un mode particulier de réalisation. Le dispositif 800 comprend un module de traitement de données composé d’un espace de stockage 801, par exemple une mémoire (MEM), une unité de traitement 802, équipée par exemple d'un microprocesseur (PROC), et pilotée par un programme d'ordinateur (PGR) 803 dont les instructions sont configurées pour mettre en œuvre le procédé de contrôle d’une communication tel que décrit précédemment en référence aux figures 3 et 4. A l'initialisation, les instructions de code du programme d'ordinateur 803 sont par exemple chargées dans la mémoire 801 avant d'être exécutées par le processeur de l'unité de traitement 802. Le microprocesseur de l'unité de traitement 802 met en œuvre, selon les instructions du programme d'ordinateur 803, les étapes du procédé de contrôle d’une communication tel que décrit précédemment en référence aux figures 3 et 4. Pour cela, le dispositif 800 comprend des moyens de communication 804, par exemple une interface réseau cellulaire 3G, 4G, 5G, réseau sans fil Wi-Fi® ou Wimax®, une interface optique ou encore une interface Ethernet. Les moyens de communication permettent au dispositif 800 de se connecter à un réseau de communication et échanger des données avec d’autres dispositifs. Le dispositif 800 comprend aussi un module 805 de réception d’un message transmis par un terminal comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal. Dans un mode de réalisation particulier, le module 805 coopère avec les moyens de communication 804 pour mettre en œuvre un protocole de transmission de données, par exemple un protocole TCP, UDP, QUIC ou autre, et recevoir une structure de données, par exemple un champ TLV d’un paquet de données comprenant au moins l’adresse d’une interface de contrôle (ou API) exposée par le réseau auquel est connecté le terminal et un identifiant du terminal. Le dispositif 800 comprend également un module de configuration 806 adapté pour configurer des ressources particulières dans un réseau de communication par l’intermédiaire d’une interface exposée par ledit réseau et indiquée dans un message reçu par le module 805. Plus précisément, le module 806 peut être mis en œuvre par des instructions de programme d’ordinateur configurées pour coopérer avec les moyens de communication 804 afin d’invoquer une ou plusieurs fonctions offertes par une interface exposée par un réseau à partir de l’adresse reçue par le module 805 de sorte à mettre en place une configuration réseau particulière, et recevoir en retour au moins une information destinée à marquer les paquets de données auxquels la configuration réseau particulière doit s’appliquer. Le dispositif 800 comprend enfin un module de transmission de données 807 adapté pour marquer des paquets de données destinés au terminal ayant transmis les informations caractéristiques d’une interface de contrôle réseau reçues par le module 805. Dans un mode particulier de réalisation, le module 807 est mis en œuvre par des instructions de programme d’ordinateur et coopère avec les moyens de communication 804 pour envoyer des paquets de données vers le terminal en sollicitant des ressources du réseau invoquées via ladite interface de contrôle, les paquets envoyés étant marquée à l’aide de l’information de marquage obtenue par le module de configuration 806. Selon un mode particulier de réalisation, le dispositif 800 est intégré dans un serveur d’application. Procédé d’établissement d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le terminal : Une étape (200) d’obtention d’une information caractéristique d’au moins une interface de contrôle exposée par le réseau, Une étape (202) de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue, Une étape (204) de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. Procédé selon la revendication 1 dans lequel le terminal obtient l’information caractéristique d’au moins une interface de contrôle exposée par le réseau dans un message DHCP, un élément d’information PCO, ou un message « Neighbor Discovery ». Procédé selon l’une quelconque des revendications précédentes dans lequel l’information caractéristique d’au moins une interface de contrôle exposée par le réseau comprend au moins un élément sélectionné parmi les éléments suivants : Un identifiant d’API réseau, Au moins une adresse d’accès à une API réseau, Un type d’API réseau, Une ou plusieurs règles régissant les conditions d’applications d’une configuration, Une donnée d’identification opaque du terminal. Procédé selon l’une quelconque des revendications précédentes dans lequel le terminal transmet l’information caractéristique d’au moins une interface de contrôle exposée par le réseau au serveur dans un champ d’option d’un entête TCP ou UDP, une trame QUIC, ou une option DCCP, un entête HTTP ou SIP. Procédé selon l’une quelconque des revendications précédentes tel qu’il comprend en outre une étape de réception d’un message transmis par le serveur, le message comprenant au moins une consigne d’identification des paquets obtenue par le serveur auprès d’au moins une interface de contrôle du réseau dont les caractéristiques ont été transmise au serveur par le terminal, l’étape de communication comprenant la génération d’au moins un paquet de données conformément auxdites consignes d’identification. Procédé de contrôle d’une communication entre un terminal et un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le procédé comprenant les étapes suivantes, mises en œuvre par le serveur : Réception (301) d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal, Invocation (302) d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique, Envoi d’au moins un paquet de données (306) vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle. Procédé selon la revendication 6 tel qu’il comprend en outre une étape d’obtention, à partir de l’interface de contrôle invoquée, d’au moins une consigne d’identification des paquets échangés avec le terminal, les paquets envoyés et/ou reçus étant générés conformément auxdites consignes d’identification obtenues. Dispositif d’établissement d’une communication avec un serveur par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur (702) couplé à une mémoire (701) dans laquelle sont enregistrées des instructions (703) adaptées pour mettre en œuvre les étapes suivantes : Une étape d’obtention d’une information caractéristique d’au moins une interface de contrôle exposée par le réseau, Une étape de configuration au cours de laquelle le terminal transmet au serveur d’application au moins une partie de ladite information obtenue, Une étape de communication au cours de laquelle le terminal échange des paquets de données avec le serveur en sollicitant des ressources dudit réseau invoquées par le serveur par l’intermédiaire de l’interface de contrôle indiquée par le terminal. Terminal de communication comprenant un dispositif d’établissement d’une communication selon la revendication 8. Dispositif de contrôle d’une communication établie avec un terminal par l’intermédiaire d’un réseau de communication exposant au moins une interface de contrôle, le dispositif comprenant un processeur (803) couplé à une mémoire (801) dans laquelle sont enregistrées des instructions (803) adaptées pour mettre en œuvre les étapes suivantes : Réception d’un message transmis par le terminal, ledit message comprenant au moins une information caractéristique d’une interface de contrôle exposée par un réseau auquel est connecté le terminal, Invocation d’au moins une interface de contrôle identifiée à partir de ladite information caractéristique, Envoi d’au moins un paquet de données vers le terminal et/ou réception d’au moins un paquet de données en provenance du terminal, les paquets étant acheminés en sollicitant des ressources dudit réseau invoquées via ladite interface de contrôle. Serveur d’application comprenant un dispositif de contrôle d’une communication selon la revendication 10. Système de communication comprenant au moins un terminal selon la revendication 9 et au moins un serveur selon la revendication 11. Produit programme d’ordinateur comprenant des instructions configurées pour mettre en œuvre un procédé d’établissement d’une communication selon l’une quelconque des revendications 1 à 5 et/ou des instructions pour mettre en œuvre un procédé de contrôle d’une communication selon l’une quelconque des revendications 6 à 7, lorsque les instructions sont exécutées par un processeur. Support d’information lisible par un ordinateur sur lequel sont enregistrées des instructions de code pour mettre en œuvre un procédé d’établissement d’une communication selon l’une quelconque des revendications 1 à 5 et/ou des instructions pour mettre en œuvre un procédé de contrôle d’une communication selon l’une quelconque des revendications 6 à 7.