Brevet FR3157042A1 — publié le 20250620

Procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic et dispositif associé L’invention concerne un de gestion d'un accès à une fonction (111) de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal (100) connecté à un réseau de télécommunication (200), le procédé comprenant les étapes suivantes, mises en œuvre par un système d'exploitation (110) de ce terminal (100) : une vérification qu'une application informatique (120) du terminal (100) souhaitant accéder à la fonction (111) de gestion d'une politique de trafic est autorisée à invoquer cette fonction, en utilisant une procédure d’autorisation mise en œuvre via le réseau de télécommunication et sélectionnée par un contrôleur (210) du réseau de télécommunication (200) ; et, une autorisation d'accès à la fonction (111) par ladite application informatique, en fonction d’un résultat de la vérification. Figure pour l’abrégé : Fig. 1. Procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic et dispositif associé La présente invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement un procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic, un procédé d'accès à une fonction de gestion d'une politique de trafic, et un terminal configuré pour mettre en œuvre de tels procédés. Elle concerne également un procédé de contrôle d'un accès à une fonction de gestion d'une politique de trafic, et un contrôleur d'un réseau de télécommunication configuré pour mettre en œuvre ce procédé de contrôle d'accès. La présente invention concerne également un procédé général d'accès à une fonction de gestion d'une politique de trafic, ainsi qu'un système d'accès à une fonction de gestion d'une politique de trafic comprenant le terminal et le contrôleur. L'invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le cas d'un réseau de télécommunication de cinquième génération (5G). Afin de s'adapter à la croissance continue et toujours plus rapide du trafic de données émises par les systèmes de télécommunication, différentes technologies sont mises en œuvre pour améliorer l'efficacité des réseaux de télécommunication. Ces mécanismes font encore l'objet de perfectionnements en vue d'une exploitation optimale dans les années à venir. Parmi les différentes technologies mises en œuvre, le "traitement différencié du trafic d'un réseau de télécommunication" (nommé "traitement différencié" ci-après) vise notamment à prévenir voire à mieux gérer une congestion du réseau. Une telle congestion peut typiquement survenir lorsque des paquets de données transitant sur ce réseau sont en concurrence avec d'autres paquets cherchant également à accéder aux ressources de ce réseau. Le traitement différencié peut également être appliqué pour garantir que des accords de niveau de service ("Service Level Agreement" selon la terminologie anglo-saxonne) sont respectés. Différentes actions peuvent être mises en œuvre dans ce cadre, telles que l'ordonnancement de paquets, la sélection d'un ou plusieurs chemins qui minimisent le délai de transmission, ou la sélection d'un chemin garantissant un certain niveau de service (incluant, un niveau de sécurité). De manière plus générale, le traitement différencié inclut différentes façons dont des paquets de données peuvent être traités différemment les uns des autres pendant leur acheminement vers leurs destinataires respectifs à travers un ou plusieurs réseaux de télécommunication. Ainsi, le champ d'application du traitement différencié englobe les techniques classiques d'ordonnancement, de mise en forme et de gestion de files d'attente par lesquelles les paquets de données sont traités par exemple au niveau du nœud d'un réseau, mais également les techniques par lesquelles des flux de données sont séparés et/ou acheminés au travers de différents chemins physiques ou logiques du réseau. Les opérateurs de réseaux de télécommunication utilisent couramment ce traitement différencié, par exemple pour adapter la qualité de service offerte à un client en fonction d'un niveau de souscription, pour gérer le trafic d'un nombre important de clients susceptible d'entraîner une congestion du réseau, pour prioriser la transmission de données de contrôle ou de signalisation sur le réseau, pour garantir la fourniture d'un service selon une certaine qualité de service par exemple définie dans le cadre d'un accord de niveau de service, ou encore pour assurer un équilibre entre la signalisation, la voix et les données multimédia, de sorte à garantir une certaine expérience utilisateur ("Quality of Experience" selon la terminologie anglo-saxonne). Pour ce faire, les opérateurs définissent des politiques de service qui incluent des politiques de classification de flux ou de paquets, des politiques d'ordonnancement et/ou des politiques de routage qui sont typiquement formalisées sous la forme de règles. Il n'en reste pas moins que ces règles définies et mises en place par les opérateurs ne sont pas nécessairement adaptées aux besoins d'un terminal particulier souhaitant accéder à une application distante particulière. En effet, ces besoins peuvent notamment dépendre de caractéristiques du terminal, de l'application elle-même (par ex. selon qu'elle s'appuie ou pas sur des communications vocales, la diffusion de vidéo en continu et/ou l'utilisation d'un navigateur Web), d'options souscrites ou pas auprès du gestionnaire ou fournisseur de cette application, etc. Il existe donc un besoin d'améliorer les solutions existantes en termes de traitement du trafic, afin d'optimiser la qualité de service offerte, mais également l'expérience telle que perçue par un utilisateur. 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 à une application informatique d'un terminal d'accéder à une fonction de gestion d'une politique de trafic, et ce, sous le contrôle de l'opérateur de télécommunication. À cet effet, et selon un premier aspect, l’invention concerne un procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal connecté à un réseau de télécommunication (une telle fonction étant typiquement exposée via une API locale). Le procédé comprend les étapes suivantes, mises en œuvre par un système d'exploitation dudit terminal : – une vérification qu'une application informatique du terminal souhaitant accéder à la fonction de gestion d'une politique de trafic est autorisée à invoquer cette fonction, en utilisant une procédure d’autorisation mise en œuvre via le réseau de télécommunication et sélectionnée par un contrôleur du réseau de télécommunication; et, – une autorisation d'accès à la fonction par ladite application informatique, en fonction d’un résultat de la vérification. 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 notion de succession temporelle. Comme évoqué précédemment, par "gestion d'une politique de trafic", on entend une adaptation de la manière dont des paquets de données sont traités différemment les uns des autres pendant leur acheminement vers leurs destinataires respectifs à travers un ou plusieurs réseaux de télécommunication (aussi désigné par "politique de trafic différenciée"). Cette adaptation inclut notamment l'ordonnancement des paquets, la gestion de files d'attente par lesquelles les paquets de données sont traités, la séparation de flux de données, l'acheminement de flux de données au travers de différents chemins physiques ou logiques du réseau de télécommunication, l’invocation d’une fonction d’accélération ou d’encodage supportée par le matériel (« hardware »), la sélection d’une classe ou d’une tranche réseau, etc. De façon connue en soi, une "application informatique" est un programme informatique utilisé pour fournir un service ou une pluralité de services. Généralement, les applications sont déployées selon un modèle client/serveur. Les applications sont déployées sur un dispositif électronique (tel qu'un terminal utilisateur ou un serveur), et s'exécutent en utilisant les services du système d'exploitation du dispositif sur lequel elles sont déployées, pour utiliser les ressources logicielles et/ou matérielles de ce dispositif. L’application embarquée dans un dispositif est généralement la partie « client » mais le mode serveur est aussi couvert (par ex. serveur de diffusion de contenus vidéo). Aucune hypothèse n’est faite quant à la nature de l’application. Le "système d'exploitation", souvent appelé "OS" (acronyme de la terminologie anglo-saxonne "operating system") est un ensemble de programmes qui sert d'intermédiaire entre les ressources du dispositif électronique et les applications informatiques de ce dispositif. Le système d'exploitation gère notamment l'utilisation des ressources de stockage (par exemple des accès à la mémoire vive et/ou aux mémoires de masse), des ressources de calcul, et/ou des ressources en termes de communication vers des périphériques ou via le réseau de télécommunication. Au sens de l'invention, ce système d'exploitation est considéré comme étant de confiance par l'opérateur du réseau de télécommunication. Ainsi, ce système d'exploitation répond à certaines normes de sécurité requises par cet opérateur, qui sont par exemple conformes aux certifications "critères communs" ("Common Criteria" selon la terminologie anglo-saxonne). Ces critères communs sont un ensemble de standards (ISO/IEC 15408) internationalement reconnus dont l'objectif est d'évaluer de façon impartiale la sécurité des systèmes et des logiciels informatiques. Le "contrôleur du réseau de télécommunication" est un module logiciel déployé sur un dispositif électronique du réseau de télécommunication, ou qui est fourni ou localisé avec un élément du réseau de télécommunication. Ainsi, lorsque le réseau de télécommunication considéré correspond à un réseau 5G, ce contrôleur est par exemple fourni par l'entité SMF (acronyme de "Session Management Funtion") qui est typiquement responsable de la gestion du plan de contrôle du réseau, et plus spécifiquement du contrôle des sessions PDU (acronyme de "Packet Data Unit"). Cette entité SMF est notamment décrite dans la spécification technique 3GPP TS 29.502, 5G System; Session Management Services; Stage 3, v18.4.0, publiée en septembre 2023. En variante, ce contrôleur du réseau de télécommunication est intégré à un contrôleur de réseau SDN (acronyme de "Software-Defined Networking"). De façon connue en soi, un contrôleur de réseau SDN est une entité d'un réseau de télécommunication qui permet d'optimiser les ressources réseau et d'adapter rapidement le réseau aux besoins changeants des entreprises, des applications et du trafic. Un contrôleur de réseau SDN fournit des fonctions d'orchestration, de gestion, de collecte de statistiques et d'automatisation du réseau. La procédure d'autorisation est sélectionnée par le réseau de télécommunication, et mise en œuvre au moins en partie par ce même réseau de télécommunication, ce qui permet ainsi à l'opérateur du réseau de contrôler – c'est-à-dire d'autoriser ou pas – l'application informatique à accéder à cette fonction de gestion d'une politique de trafic. Comme évoqué plus en détail ci-après, cette procédure d'autorisation peut comprendre un ou plusieurs mécanismes d'autorisation distincts, tels qu'une vérification basée sur une donnée d'identification de cette application informatique et/ou une vérification que l'application informatique est valablement authentifiée auprès du réseau de télécommunication. Si cette application informatique est effectivement autorisée à invoquer (ou appeler) cette fonction, par exemple parce qu'elle a été identifiée comme étant une application de confiance sur la base de son identifiant et/ou qu'elle est valablement authentifiée auprès du réseau de télécommunication, le système d'exploitation, qui joue alors en quelque sorte un rôle de pare-feu, autorise l'accès à cette fonction de gestion de la politique de trafic. De façon plus précise, le système d'exploitation permet alors à cette application d'invoquer des fonctionnalités (ou primitives) de cette fonction de gestion d'une politique de trafic, mais également d'obtenir un résultat représentatif d'une mise en œuvre de ces fonctionnalités. Si par contre cette application n'est pas autorisée à accéder à cette fonction, le système d'exploitation va alors bloquer l'accès à la fonction de gestion d'une politique de trafic par l'application informatique. En outre, cette interdiction d'accès peut également engendrer un refus d'invocation de cette fonction par le système d'exploitation. Dans ce cas, en réponse à une nouvelle invocation de la fonction de gestion d'une politique de trafic par cette même application informatique, le système d'exploitation ignore cette nouvelle invocation, voire bloque toute nouvelle tentative d'invocation de la fonction. Dans des modes particuliers de mise en œuvre, le procédé de gestion d'un accès 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 procédé de gestion d'un accès comprend en outre une réception, par le système d'exploitation et en provenance du contrôleur du réseau de télécommunication, d'une donnée représentative d'applications informatiques autorisées ou pas à gérer la politique de trafic, et d'une donnée représentative d'un mécanisme d'authentification d'une application informatique souhaitant accéder à la fonction de gestion d'une politique de trafic auprès dudit réseau de télécommunication ; et la vérification que l'application informatique est autorisée à gérer la politique de trafic est mise en œuvre en fonction desdites données reçues. Dans des modes particuliers de mise en œuvre, la "donnée d'identification d'applications informatiques autorisées ou pas à gérer la politique de trafic" comprend ou permet de déterminer des identifiants d'applications informatiques du terminal qui sont autorisées à gérer la politique de trafic, et la vérification que ladite application informatique est autorisée à gérer la politique de trafic comprend une comparaison entre l'identifiant de ladite application informatique et les identifiants d'applications informatiques du terminal qui sont autorisées à gérer la politique de trafic. Dans des modes particuliers de mise en œuvre, la vérification est mise en œuvre en réponse à un appel de la fonction de gestion d'une politique de trafic par l'application informatique dudit terminal. De façon plus précise, la vérification peut être conditionnée par la détection, par le système d'exploitation, d'un appel à cette fonction de gestion. Dans des modes particuliers de mise en œuvre, la fonction de gestion d'une politique de trafic et, le cas échant, la ou les fonctionnalités ou primitives de cette fonction, sont présentées par le système d'exploitation à l'application informatique au travers d'une interface de programmation d’application (ou API, acronyme de "application programming interface"). Selon un deuxième aspect, l’invention concerne un procédé d'accès à une fonction de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal connecté à un réseau de télécommunication, le procédé comprenant les étapes suivantes mises en œuvre par une application informatique dudit terminal : – une invocation de la fonction de gestion d'une politique de trafic ; – une transmission, à un système d'exploitation du terminal, d'un élément d'authentification reçu d'un système d'authentification du réseau de télécommunication et requis par une procédure d'autorisation sélectionnée et mise en œuvre via le réseau de télécommunication ; et, – un accès à ladite fonction de gestion d'une politique de trafic, en fonction d'un résultat de la procédure d'autorisation. Au sens de l'invention, le système d'authentification peut comprendre uniquement le contrôleur du réseau de télécommunication précédemment évoqué, ou le contrôleur du réseau de télécommunication couplé à un gestionnaire d'authentification. Un ou plusieurs contrôleurs peuvent être déployés. Il importe également de rappeler que les étapes d’un procédé ne doivent pas être interprétées comme étant liées à une notion de succession temporelle. Aussi, l'étape de transmission précédemment évoquée peut être mise en œuvre avant l'étape d'invocation de la fonction de gestion d'une politique de trafic, et vice versa . Par ailleurs, comme évoqué plus en détail ci-après, ces deux étapes d'invocation et de transmission peuvent également correspondre à une seule et même étape. Ainsi, dans des modes particuliers de mise en œuvre, l'élément d'authentification inclut un jeton d'authentification transmis au système d'exploitation lors de l'invocation de la fonction. Dans des modes particuliers de mise en œuvre, le procédé d'accès comprend en outre une transmission, à destination du système d'exploitation, d'une donnée d'identification du terminal et/ou d'une estampille temporelle. Cette transmission de la donnée d'identification du terminal et/ou de l'estampille temporelle peut correspondre à une transmission distincte de l'invocation et de la transmission précédemment évoquées, ou correspondre à une seule et même étape. Dans ce dernier cas, la donnée d'identification du terminal et/ou l'estampille temporelle peuvent alors être transmises comme un paramètre de l'invocation de la fonction. Dans des modes particuliers de mise en œuvre, l'élément d'authentification inclut une réponse associée à un défi transmise au système d'exploitation suite à une réception du défi en provenance du système d'exploitation. Dans des modes particuliers de mise en œuvre, la fonction de gestion d'une politique de trafic comprend un ajout, une suppression et/ou une modification d'une règle de classification de trafic générée par un gestionnaire du réseau de télécommunication. Ce gestionnaire correspond par exemple à l'opérateur de télécommunication ou à un gestionnaire de service du réseau de télécommunication. Dans des modes particuliers de mise en œuvre, la fonction de gestion d'une politique de trafic comprend l'ajout d'une règle d'association d'au moins un flux d'une communication avec le terminal à au moins une tranche réseau du réseau de télécommunication accessible par ledit terminal. Les récents développements dans le domaine des réseaux de cinquième génération permettent désormais de créer des sous-réseaux logiques sur mesure, et qui reposent sur une même infrastructure de réseau physique. Ces sous-réseaux logiques sont appelés "tranches réseau" ("network slices" selon la terminologie anglo-saxonne) et 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. Ainsi, l'ajout une règle relative à l'utilisation d'une tranche réseau spécifique pour au moins un flux d'une communication entre le terminal et un service accessible au travers du réseau de télécommunication permet avantageusement d'offrir la qualité de service requise par ce service, et a fortiori une expérience utilisateur adaptée à ce service. Dans des modes particuliers de mise en œuvre, le procédé comprend en outre un échange, entre le terminal et le réseau de télécommunication, de leurs capacités respectives à contrôler l'accès à la fonction de gestion d'une politique de trafic dudit terminal. Dans des modes particuliers de mise en œuvre, l'échange comprend les étapes suivantes mises en œuvre par le terminal : – une transmission, à destination du contrôleur du réseau de télécommunication, d'une indication selon laquelle ledit terminal est configuré pour contrôler l'accès d'applications informatiques dudit terminal à la fonction de gestion d'une politique de trafic ; – une réception, en provenance du contrôleur du réseau de télécommunication, d'une indication selon laquelle ledit terminal est autorisé ou pas à permettre l'accès d'applications informatiques dudit terminal à la fonction de gestion d'une politique de trafic. Dans des modes particuliers de mise en œuvre, la procédure d'autorisation comprend une authentification par jeton d'authentification ou une authentification défi-réponse. Dans des modes particuliers de mise en œuvre, le jeton d'authentification est un "jeton d'authentification éphémère" qui est typiquement utilisable qu'une seule fois, un "jeton d'authentification à durée de vie longue", ou un "jeton persistant" sans durée de vie. Dans des modes particuliers de mise en œuvre, la procédure d’autorisation comprend une authentification par jeton d'authentification, et le procédé comprend en outre une étape mise en œuvre par le système d'exploitation du terminal de transmission, à destination dudit contrôleur, d'une requête d’authentification de l'application informatique incluant un jeton d'authentification préalablement généré par un système d'authentification et fourni au système d’exploitation par l'application informatique. Dans des modes particuliers de mise en œuvre, la requête d'authentification inclut en outre une donnée d'identification de l'application informatique, ladite donnée d'identification étant contrôlée par le système d'exploitation du terminal. Le fait que cette donnée d'identification de l'application informatique soit contrôlée par le système d'exploitation du terminal puis transmise au contrôleur de réseau plutôt que d'être directement transmise par l'application informatique à destination du contrôleur de réseau permet au contrôleur de s'assurer que l'application appelant la fonction de gestion d'une politique de trafic n'est pas malicieuse. Ainsi, cette caractéristique offre l'avantage d'améliorer la sécurité de l'accès à cette fonction de gestion, en prévenant une attaque par usurpation d'identité d'une application informatique malicieuse. Dans des modes particuliers de mise en œuvre, la requête d'authentification inclut en outre une donnée d'identification du terminal préalablement communiquée par le système d'authentification et fournie au système d’exploitation par l'application informatique. Cette donnée d'identification du terminal vise à permettre au contrôleur de vérifier si ledit terminal est malicieux ou pas. A fortiori , cette caractéristique offre l'avantage d'améliorer la sécurité de l'accès à cette fonction de gestion, en prévenant une attaque par usurpation d'identité d'un terminal malicieux. En effet, cette donnée d'identification du terminal, qui correspond par exemple à un identifiant dudit terminal au sein du réseau de télécommunication, est par exemple générée par le système d'authentification précédemment évoqué en réponse à la réception d'une requête en obtention d'un jeton d'authentification, avant d'être retransmise à l'application informatique. C'est cette dernière application informatique qui, en appelant la fonction de gestion d'une politique de trafic, transmet également cette donnée d'identification du terminal au système d'exploitation. Ce dernier génère alors la requête en authentification et y inclus cette donnée d'identification du terminal. En recevant la requête, le contrôleur du réseau de télécommunication est alors en mesure de comparer cette donnée d'identification du terminal avec un ensemble de données d'identification de terminaux autorisés à permettre une gestion de la politique de trafic par une de ses applications informatiques. Dans des modes particuliers de mise en œuvre, la requête d'authentification inclut en outre une estampille temporelle préalablement communiquée par le système d'authentification et fournie au système d’exploitation par l'application informatique. Cette estampille temporelle vise à permettre au contrôleur de vérifier si la requête en authentification est malicieusement répétée ou pas. De façon plus précise, l'estampille temporelle est par exemple générée par le système d'authentification précédemment évoqué en réponse à une requête en obtention d'un jeton d'authentification, avant d'être retransmise à l'application informatique. C'est cette dernière application informatique qui, en appelant la fonction de gestion d'une politique de trafic, transmet également cette estampille temporelle au système d'exploitation. Ce dernier génère alors la requête en authentification et y inclus cette estampille temporelle. En recevant la requête, le contrôleur du réseau de télécommunication sera alors en mesure de vérifier la validité de la requête, par exemple en comparant la différence entre une valeur représentative du temps courant et la valeur de l'estampille temporelle avec un intervalle de temps prédéterminé. Si cette estampille temporelle n'est pas comprise dans cet intervalle, cela signifie alors que la requête en authentification est probablement rejouée. Dans des modes particuliers de mise en œuvre, l'authentification est une authentification par jeton d'authentification à durée de vie longue, et si l'authentification de ladite application informatique est valide, un résultat de l'authentification fourmi par le contrôleur au système d'exploitation inclut une durée au cours de laquelle un nouvel accès à la fonction de gestion d'une politique de trafic doit être autorisé par le système d'exploitation sans qu'une nouvelle authentification de ladite application informatique auprès du réseau de télécommunication ne soit nécessaire. En comparaison avec une authentification par jeton éphémère, cette caractéristique offre l'avantage de réduire le nombre d'échanges entre le terminal et le service d'authentification. Dans des modes particuliers de mise en œuvre, le procédé comprend en outre une réception, en provenance dudit contrôleur, d'un résultat de l'authentification de l'application informatique. Dans des modes particuliers de mise en œuvre, la procédure d'autorisation est une authentification défi-réponse, et le procédé comprend en outre les étapes suivantes, mises en œuvre par le système d'exploitation : – une transmission, à destination de l'application informatique, d'un défi ; – une transmission, à destination dudit contrôleur, de données de paramétrage incluant le défi et une première réponse associée au défi ; – une réception d'une deuxième réponse préalablement fournie à ladite application informatique par le contrôleur en réponse à une réception d'une requête en obtention d'une réponse émise par l'application informatique et incluant ledit défi ; et l'accès à la fonction de gestion d'une politique de trafic est autorisé si les première et deuxième réponses sont égales. Dans des modes particuliers de mise en œuvre, le procédé de gestion d'un accès comprend en outre une étape de comparaison, par le système d'exploitation du terminal, des première et deuxième réponses. Dans des modes particuliers de mise en œuvre, les données de paramétrage et la requête en obtention d'une réponse incluent en outre une donnée d'identification de ladite application informatique contrôlée par le système d'exploitation du terminal. Dans des modes particuliers de mise en œuvre, la procédure d'autorisation est une authentification défi-réponse, et le procédé d'accès comprend en outre les étapes suivantes, mises en œuvre par l'application informatique : – une transmission, à destination du contrôleur, d'une requête en obtention d'une réponse incluant un défi fourni à l'application informatique par le système d'exploitation ; et, – une transmission, à destination du système d'exploitation, d'une deuxième réponse fournie à l'application informatique par le contrôleur suite à la réception de la requête en obtention d'une réponse. Selon un troisième aspect, l'invention concerne un procédé de contrôle d'un accès à une fonction de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal connecté à un réseau de télécommunication, le procédé comprenant les étapes suivantes mises en œuvre par un contrôleur du réseau de télécommunication : – une détermination que ledit terminal est autorisé à permettre l'accès par des applications informatiques dudit terminal à la fonction de gestion d'une politique de trafic ; et, – une transmission, à destination du terminal, d'une donnée d'identification d'applications informatiques autorisées ou pas à gérer la politique de trafic, et d'une donnée représentative d'un mécanisme d'authentification, auprès dudit réseau de télécommunication (200), d'une application informatique souhaitant accéder à la fonction de gestion d'une politique de trafic. Dans des modes particuliers de mise en œuvre, le procédé de contrôle d'un accès peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, la détermination précédemment évoquée est mise en œuvre en réponse à une réception d'une indication, en provenance du terminal, selon laquelle ledit terminal est configuré pour contrôler l'accès d'applications informatiques dudit terminal à la fonction de gestion d'une politique de trafic. Dans des modes particuliers de mise en œuvre, le mécanisme d'authentification est une authentification par jeton d'authentification, et le procédé comprend en outre les étapes suivantes, mises en œuvre par un système d'authentification du réseau de télécommunication : – en réponse à une réception d'une requête en obtention d'un jeton d'authentification émise par l'application informatique du terminal et incluant une donnée d'identification de ladite application informatique, une vérification, en fonction de ladite donnée d'identification, si ladite application peut obtenir un jeton d'authentification ; et, – une transmission, à destination de l'application informatique, d'un jeton d'authentification généré en fonction de la vérification. Dans des modes particuliers de mise en œuvre, le procédé de contrôle d'un accès comprend en outre les étapes suivantes, mises en œuvre par le système d'authentification : – une génération d'une donnée d'identification dudit terminal (100) ; et, – une transmission de la donnée d'identification dudit terminal à destination de l'application informatique. Comme évoqué précédemment, cette donnée d'identification dudit terminal permet au contrôleur de vérifier si c'est un terminal malicieux ou pas qui émet une requête en authentification d'une application informatique. Selon un quatrième aspect, l'invention concerne un terminal configuré pour mettre en œuvre le procédé de gestion d'un accès et/ou le procédé d'accès précédemment évoqués. Selon un cinquième aspect, l'invention concerne un contrôleur d'un réseau de télécommunication configuré pour mettre en œuvre le procédé de contrôle précédemment évoqué. Selon un sixième aspect, l'invention concerne un système d'accès à une fonction de gestion d'une politique de trafic comprenant le terminal et le contrôleur précédemment évoqués. Selon un septième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic, lorsque ledit programme est exécuté par un ordinateur. Selon un huitième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d'accès à une fonction de gestion d'une politique de trafic, lorsque ledit programme est exécuté par un ordinateur. Selon un neuvième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de contrôle d'un accès à une fonction de gestion d'une politique de trafic, lorsque ledit programme est exécuté par un ordinateur. Selon un dixième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré le programme d’ordinateur conformément au septième, au huitième, et/ou au neuviè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 dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : FIG. 1 La FIG. 1 est un exemple de système d'accès dans lequel un procédé général d'accès à une fonction de gestion d'une politique de trafic différenciée est mis en œuvre ; FIG. 2 la FIG. 2 représente schématiquement des modules embarqués dans un terminal, selon un exemple simplifié de mise en œuvre de l’invention ; FIG. 2 la FIG. 2 représente un exemple d’architecture matérielle d’un terminal ; FIG. 3 la FIG. 3 représente schématiquement des modules embarqués dans un contrôleur d'un réseau de télécommunication, 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 contrôleur d'un réseau de télécommunication ; FIG. 4 la FIG. 4 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à une fonction de gestion d'une politique de trafic différenciée, selon un exemple de mise en œuvre de l’invention ; FIG. 5 la FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un premier exemple de mise en œuvre de l’invention ; FIG. 5 la FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un deuxième exemple de mise en œuvre de l’invention ; FIG. 5 la FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un troisième exemple de mise en œuvre de l’invention ; FIG. 6 la FIG. 6 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification à durée de vie longue, selon un exemple de mise en œuvre de l’invention ; FIG. 7 la FIG. 7 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par défi-réponse, selon un exemple de mise en œuvre de l’invention. 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, 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é. La FIG. 1 est un exemple de système d'accès dans lequel un procédé général d'accès à une fonction de gestion d'une politique de trafic est mis en œuvre. La procédure proposée par l’invention est appelée dans la suite de la description IMURIG (pour « Innovative Management of UnpRecedented collaborative API Gating control »). Ce système comprend un terminal 100 connecté à un réseau de télécommunication 200. Le terminal 100 supporte par exemple le protocole de communication IP, et 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, un décodeur TV, etc. Tel qu'illustré par la FIG. 1 , ce terminal 100 comprend un système d'exploitation 110 incluant un module IMURIG 112 configuré pour mettre en œuvre un procédé de gestion d'un accès à une fonction 111 de gestion d'une politique de trafic (typiquement une politique de trafic différenciée), cette fonction 111 étant elle-même mise en œuvre par le système d'exploitation 110, ainsi qu'une interface de programmation d'application (ou API) au travers de laquelle les fonctionnalités (ou "primitives") de la fonction 111 de gestion d'une politique de trafic sont présentées à une ou plusieurs applications informatiques 120 du terminal 100. L'utilisation d'une API est avantageuse puisqu'elle permet à l'application informatique 120 du terminal 100 de communiquer avec la fonction 111 de gestion d'une politique de trafic, sans avoir à connaître les détails de mise en œuvre des fonctionnalités de cette fonction. Tel qu'illustré par la FIG. 1 , le système comprend en outre un serveur distant 300 également connecté au réseau de télécommunications 200 au travers d'un réseau de données DN tel que l’Internet ou un réseau local/privé, et configuré pour fournir un service S. De façon connue en soi, un service est 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. Dans le présent mode de réalisation, et à des fins de simplification de la description, il est considéré que le système d'accès comporte un unique terminal 100, ainsi qu’un unique serveur distant 300 offrant un unique service S, ces deux dispositifs étant connectés au travers d'un réseau de télécommunication incluant un unique contrôleur IMURIG_CTRL 210. Il convient cependant de noter qu'aucune hypothèse n’est faite quant au nombre de terminaux, de serveurs distants et de services déployés, au nombre de réseaux et de contrôleurs 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 terminal, plus d’un serveur distant, plus d'un service S, plus d'un réseau de télécommunication et/ou plus d'un contrôleur sont considérés. Tel qu’illustré par la FIG. 1 , le réseau de télécommunication 200 comprend dans cet exemple un réseau d’accès radio RAN et un réseau cœur CN connectés entre eux. Autrement dit, les réseaux radio RAN et cœur CN composent, dans le mode de réalisation décrit ici, le réseau de télécommunications 200 auquel est connecté le terminal 100, 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 200 est un réseau mobile de type 5G. Il convient toutefois de préciser que l'invention reste applicable à d'autres types de réseau de télécommunications 200, 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. 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. Le réseau cœur CN comprend un contrôleur IMURIG_CTRL 210 du réseau de télécommunication module configuré pour mettre en œuvre un procédé de contrôle d'un accès à la fonction 111 de gestion d'une politique de trafic. Tel qu'illustré par la FIG. 1 , ce contrôleur 210 est déployé sur un dispositif électronique 2100 du réseau cœur CN. En variante, ce contrôleur 210 est fourni ou co-localisé avec un élément du réseau de télécommunication. Ainsi, ce contrôleur est par exemple fourni par l'entité SMF (acronyme de "Session Management Funtion") qui est typiquement responsable de la gestion du plan de contrôle du réseau, et plus spécifiquement du contrôle des sessions PDU (acronyme de "Packet Data Unit"). Cette entité SMF est notamment décrite en sections 4 ("Overview") et 5 ("Services offered by the SMF") de la spécification technique 3GPP TS 29.502, "5G System; Session Management Services; Stage 3", v18.4.0, publiée en septembre 2023. En variante, ce contrôleur 210 du réseau de télécommunication 200 est intégré à un contrôleur de réseau SDN. De façon connue en soi, un contrôleur de réseau SDN est une entité d'un réseau de télécommunication qui permet d'optimiser les ressources réseau et d'adapter rapidement le réseau aux besoins changeants des entreprises, des applications et du trafic, et qui offre à cet effet des fonctions d'orchestration, de gestion, de statistiques et d'automatisation dudit réseau. Dans des modes particuliers de mise en œuvre, le réseau cœur CN comprend en outre un gestionnaire d'authentification AUTH_MNG 220 connecté au contrôleur IMURIG_CTRL 210, et notamment configuré pour générer des éléments d’authentification tels que des jetons d'authentification. Dans des modes particuliers de mise en œuvre, les réseaux d’accès radio RAN et cœur CN supportent une ou plusieurs tranches réseau. 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. La FIG. 2 représente schématiquement des modules embarqués dans un terminal, tel que le terminal 100 de la FIG. 1 , selon un exemple simplifié de mise en œuvre de l’invention. Tel qu’illustré par la FIG. 2 , le terminal 100 comprend un système d'exploitation 110 et au moins une application informatique 120 souhaitant accéder à la fonction de gestion d'une politique de trafic (différenciée) et référencée 111 dans la FIG. 1 . Le système d'exploitation 110 comprend un module MOD_CHK de vérification et un module MOD_AUTH d'autorisation d'un accès dont les fonctionnalités sont décrites en référence à la FIG. 2 . L'application informatique 120 comprend, quant-à-elle, un module MOD_CALL d'invocation et de transmission, et un module MOD_ACC d'accès dont les fonctionnalités sont également décrites en référence à la FIG. 2 . La FIG. 2 représente un exemple d’architecture matérielle d’un terminal 100. Tel qu’illustré par la FIG. 2 , le terminal 100 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le terminal 100 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 ou la mémoire non-volatile 4 du terminal 100 constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un premier programme d’ordinateur PROG exécuté par le système d'exploitation 110, comportant des instructions pour l’exécution d’étapes du procédé de gestion d'un accès tel que proposé ci-après. Le programme PROG définit un ou plusieurs sous-modules fonctionnels du système d'exploitation 110, 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_CHK de vérification que l'application informatique 120 souhaitant accéder à la fonction 111 de gestion d'une politique de trafic est autorisée à invoquer cette fonction, en utilisant une procédure d’autorisation mise en œuvre via le réseau de télécommunication 200 et sélectionnée par un contrôleur 210 du réseau de télécommunication 200 ; et, – un module MOD_AUTH d'autorisation d'accès à la fonction 111 de gestion d'une politique de trafic par cette application informatique 120, en fonction d’un résultat de la vérification. La mémoire morte 3 ou la mémoire non-volatile 4 du terminal 100 constitue également un support d’enregistrement d'un deuxième programme d’ordinateur PROG_APP exécuté par l'application informatique 120, et comportant des instructions pour l’exécution d’étapes du procédé d'accès tel que proposé ci-après. Le programme PROG_APP définit un ou plusieurs sous-modules fonctionnels, 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_CALL d'invocation de la fonction 111 de gestion d'une politique de trafic et de transmission, à un système d'exploitation 110 du terminal 100, d'un élément d'authentification reçu d'un système d'authentification 210, 220 du réseau de télécommunication 200 et requis par une procédure d'autorisation sélectionnée et mise en œuvre via le réseau de télécommunication 200 ; et, – un module MOD_ACC d'accès à ladite fonction de gestion d'une politique de trafic, en fonction d'un résultat de la procédure d'autorisation. Par ailleurs, le terminal 100 peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de gestion d'un accès, comme cela est décrit plus en détail ultérieurement. La FIG. 3 représente schématiquement des modules embarqués dans un contrôleur 210 d'un réseau de télécommunication 200, selon un exemple de mise en œuvre de l’invention. Tel qu’illustré par la FIG. 3 , le dispositif électronique 2100 du réseau cœur CN comprend un contrôleur 210 d'un réseau de télécommunication incluant un module MOD_DET de détermination et un module MOD_TX de transmission dont les fonctionnalités sont décrites en référence à la FIG. 3 . La FIG. 3 représente un exemple d’architecture matérielle d’un dispositif électronique 2100 comprenant un contrôleur 210. Tel qu’illustré par la FIG. 3 , le dispositif électronique 2100 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif électronique 2100 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 ou la mémoire non-volatile 4 du 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_CTRL comportant des instructions pour l’exécution d’étapes du procédé de contrôle d'un accès tel que proposé ci-après. Le programme PROG_CTRL définit un ou plusieurs sous-modules fonctionnels du dispositif électronique 2100, 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_DET de détermination que le terminal 100 est autorisé à permettre l'accès à la fonction 111 de gestion d'une politique de trafic par ses propres applications informatiques ; et, – un module MOD_TX de transmission d'une donnée d'identification d'applications informatiques autorisées ou pas à gérer la politique de trafic, et d'une donnée représentative d'un mécanisme d'authentification, auprès dudit réseau de télécommunication 200, d'une application informatique souhaitant accéder à la fonction de gestion d'une politique de trafic différencié. Par ailleurs, le dispositif électronique 2100 peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de contrôle d'un accès, comme cela est décrit plus en détail ultérieurement. La FIG. 4 illustre, sous forme d’ordinogramme, les principales étapes d’un procédé général d'accès à une fonction de gestion d'une politique de trafic, selon un exemple de mise en œuvre de l’invention. Ce procédé général inclut un procédé de gestion d'un accès à une fonction de gestion d'une politique de trafic (politique de trafic différenciée dans l’exemple envisagé ici) incluant les étapes S100 à S190 mises en œuvre par le système d'exploitation 110 du terminal 100, et les étapes S300 et S310 mises en œuvre par une application informatique 120 du terminal 100, ainsi qu'un procédé de contrôle d'un accès à une fonction de gestion d'une politique de trafic (politique de trafic différenciée dans l’exemple envisagé ici) mis en œuvre par un contrôleur 210 d'un réseau de télécommunication 200 et incluant les étapes S200 à S250. Dans la suite, on considère que les messages échangés entre le terminal 100 et le contrôleur 210 du réseau de télécommunication sont mutuellement authentifiés conformément à un procédé d'authentification bien connu de l'art antérieur, tel que l'authentification par certificat ou à l'aide de clefs cryptographiques pré-partagées ("Pre-Shared Keys", PSK, selon la terminologie anglo-saxonne). L'authentification des messages échangés permet avantageusement d'éviter que des actions malveillantes soient réalisées par des logiciels malveillants installés sur le terminal 100 en usurpant par exemple l’identité du module IMURIG 112. Le procédé général d'accès à une fonction de gestion d'une politique de trafic (politique de trafic différenciée dans l’exemple envisagé ici) comprend une première étape S100 au cours de laquelle le terminal 100, et plus spécifiquement le module IMURIG 112 du système d'exploitation 110, transmet à destination du contrôleur 210 du réseau de télécommunication 200, une indication IMURIG_CAPABLE(UE_STATUS) selon laquelle ledit terminal 100 est configuré pour contrôler l'accès d'applications informatiques dudit terminal 100 à la fonction 111 de gestion d'une politique de trafic. Selon une implémentation particulière, cette indication IMURIG_CAPABLE(UE_STATUS) est transmise dans le cadre de l'attachement au réseau de télécommunication 200, au travers d'un message comprenant un élément d'information ("information element" selon la terminologie anglo-saxonne) spécifique. Un élément d'information correspond à un champ d'une trame de gestion IEEE 802.11 ou d'un message échangé au sein d'un réseau de téléphonie mobile entre une station de base et un terminal utilisateur. Un élément d'information utilise généralement un schéma de codage type-longueur-valeur ("type-length-value" selon la terminologie anglo-saxonne). Selon une implémentation particulière, le réseau de télécommunication 200 est de type 5G, et l'élément d'information est inséré par exemple dans le champ "Extended protocol configuration option" du message "PDU Session Establishment Request". Ce message correspond à une demande d'établissement d'une session permettant l'échange de données entre un terminal utilisateur et un réseau de données, tel que le réseau Internet ou un réseau privé. Il est par exemple conforme à la section 5.6 de la norme 3GPP TS 23.501, "System architecture for the 5G System (5GS)", version 18.3.0, publiée le 19 septembre 2023. En variante, cette indication IMURIG_CAPABLE(UE_STATUS) est transmise au contrôleur 210 comme une option du protocole de configuration dynamique DHCPv6 (pour "Dynamic Host Configuration Protocol version 6"), ce protocole étant par exemple défini dans le document RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", publiée en novembre 2018 par l'IETF (acronyme de "Internet Engineering Task Force"). En variante, cette indication IMURIG_CAPABLE(UE_STATUS) est transmise au contrôleur 210 sous la forme d'une valeur d'un champ du message "Neighbor Advertissement" du protocole de découverte d'hôtes voisins ("Neighbor Discovery protocol" selon la terminologie anglo-saxonne), ce protocole étant par exemple défini dans le document RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", publié en septembre 2007 par l"IETF. Selon une implémentation particulière, cette indication IMURIG_CAPABLE(UE_STATUS) comprend un drapeau UE_STATUS indiquant si le ledit terminal 100 est configuré ou pas pour contrôler l'accès d'applications informatiques dudit terminal 100 à la fonction 111 de gestion d'une politique de trafic. Ainsi, si le drapeau UE_STATUS est par exemple égal à "1", cela signifie par exemple que le terminal 100 est configuré pour contrôler l'accès de ses propres applications informatiques à la fonction 111 de gestion d'une politique de trafic. Si le drapeau UE_STATUS est par exemple égal à "0", cela signifie que ledit terminal 100 ne peut pas contrôler l'accès de ses propres applications informatiques à la fonction 111 de gestion d'une politique de trafic, et qu'il n'autorise donc pas à ses applications informatiques à accéder à cette fonction 111 de gestion d'une politique de trafic. Dans ce dernier cas, les fonctionnalités offertes par la fonction 111 de gestion d'une politique de trafic ne sont alors pas exposées par le système d'exploitation au travers d'une API. En variante, les fonctionnalités (ou "primitives") sont exposées au travers d'une API, mais le système d'exploitation ne répond pas aux appels (ou invocations) des applications informatiques souhaitant accéder à ces fonctionnalités. Cette indication IMURIG_CAPABLE(UE_STATUS) est reçue par le contrôleur 210 du réseau de télécommunication 200 lors d'une étape S200. Le procédé comprend en outre une étape S210 au cours de laquelle le contrôleur 210 extrait les informations du message reçu. Lors d'une étape S220, le contrôleur 210 vérifie si le réseau de télécommunication 200 offre la possibilité d'autoriser un terminal à contrôler l'accès à la fonction de gestion d'une politique de trafic conformément à la procédure IMURIG. Si ce n'est pas le cas (choix "N"), le contrôleur met en œuvre une étape S225. Selon un premier exemple de mise en œuvre de l’étape S225, le message 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, seule l'indication IMURIG_CAPABLE(UE_STATUS) est ignorée par le contrôleur 210. Si par contre le réseau de télécommunication 200 offre la possibilité d'autoriser un terminal à contrôler l'accès à la fonction de gestion d'une politique de trafic conformément à la procédure IMURIG (choix "Y"), une étape S230 est mise en œuvre par le contrôleur 210 au cours de laquelle ce dernier vérifie si le terminal 100 ayant transmis cette indication IMURIG_CAPABLE(UE_STATUS) peut être autorisé ou pas à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à au moins une de ses applications informatiques. Cette autorisation accordée ou pas au terminal dépend par exemple des conditions de congestion dans le réseau de télécommunication, ou de restrictions liées aux offres de service souscrites par l'utilisateur dudit terminal 100. Si le terminal 100 n'est pas autorisé par le contrôleur 210 à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à au moins une de ses applications informatiques (choix "N"), le contrôleur met alors en œuvre une étape S240 au cours de laquelle une indication IMURIG_CAPABLE(NWK_STATUS) représentative du fait que le réseau 200 n'autorise pas le terminal 100 à permettre l'accès à la fonction 111 de gestion d'une politique de trafic est transmise au système d'exploitation 110. Selon une implémentation particulière, cette indication IMURIG_CAPABLE(NWK_STATUS) est transmise au travers du message "PDU Session Establishment Accept". En variante, cette indication IMURIG_CAPABLE(NWK_STATUS) est transmise au travers du message "PDU Session Establishment Reject". Ces messages sont par exemple conformes à la norme 3GPP TS 23.501, "System architecture for the 5G System (5GS)", version 18.3.0, publiée le 19 septembre 2023. Selon une implémentation particulière, dans le cas où la demande d'établissement de la session PDU est rejetée, le message "PDU Session Establishment Reject" comprend un code de cause ("5GSM cause") spécifique dont la valeur est représentative du fait que le terminal 100 n'est pas autorisé à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à ses applications. Les codes de cause jusqu'à présent normalisés dans le cadre du 3GPP sont par exemple définis dans la norme TS 29.524, "5G System; Cause codes mapping between 5GC interfaces; Stage 3", version 17.3.0, publiée en décembre 2021. Ce message est reçu par le système d'exploitation 110 lors d'une étape S110. De retour à l'étape S230, si au contraire le terminal 100 est effectivement autorisé par le contrôleur 210 à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à au moins une de ses applications informatiques (choix "Y"), une étape S250 est mise en œuvre par le contrôleur 210 au cours de laquelle ce dernier transmet un message incluant une donnée IMURIG_CAPABLE(LIST;GRANT_M) représentative du fait que ce terminal 100 est autorisé à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à au moins une de ses applications. Selon une implémentation particulière, cette donnée IMURIG_CAPABLE(LIST,GRANT_M) est transmise au travers d'un élément d'information spécifique du champ "Extended Protocol Configuration Options" du message "PDU Session Establishment Accept". Selon une implémentation particulière, cette donnée IMURIG_CAPABLE(LIST,GRANT_M) comprend une donnée d'identification d'applications informatiques autorisées ou pas par le contrôleur 210 à accéder à la fonction 111 de gestion d'une politique de trafic. Cette donnée d'identification correspond par exemple à une liste LIST d'identifiant(s) d'applications informatiques autorisées par le contrôleur 210 à accéder à la fonction 111 de gestion d'une politique de trafic. En variante, cette donnée d'identification correspond à une liste LIST d'identifiant(s) d'applications informatiques qui ne sont pas autorisées à accéder à la fonction 111 de gestion d'une politique de trafic. Ainsi, en comparant les identifiants des applications informatiques qui ne sont pas autorisées à accéder à la fonction 111 de gestion d'une politique de trafic et ceux des applications informatiques installées sur le terminal 100, le système d'exploitation 110 est alors en mesure de déterminer la ou les applications informatiques installées sur ledit terminal 100 et également autorisées par le contrôleur 210 à accéder à la fonction 111 de gestion d'une politique de trafic. En variante, cette donnée d'identification {APP_FILTER , OP} correspond à au moins un couple incluant un filtre APP_FILTER sur lequel est appliqué un opérande OP. Le filtre APP_FILTER permet d'identifier une ou plusieurs applications informatiques, par exemple à l'aide d'un identifiant d’application ("APP_ID",) ou d'un ensemble d'applications ("group_id"), un nom de domaine, etc. L'opérande OP caractérise l'opération à appliquer sur le filtre APP_FILTER, et fait soit référence à une correspondance exacte, soit à l'opérateur logique "Non" ("Not" selon la terminologie anglo-saxonne). Cet opérande OP prend par exemple la valeur "0" lorsqu'il est fait référence à une correspondance exacte et "1" lorsqu'il est fait référence à l'opérateur "Non". Si l'opérande OP fait référence à une correspondance exacte, seules les applications informatiques identifiées par le filtre APP_FILTER sont autorisées à accéder à la fonction 111 de gestion d'une politique de trafic. Par exemple, la donnée d'identification {4234d49b, 0} est retourné par le contrôleur 210 pour indiquer à au terminal 100 que seule l’application ayant pour identifiant "4234d49b" est habilitée à accéder à la fonction 111 de gestion d'une politique de trafic, et les appels des autres applications sont systématiquement refusés par le système d'exploitation 110. Si par contre l'opérande OP fait référence à l'opérateur logique "Non", cela signifie que toutes les applications informatiques à l'exception de celle(s) identifiée(s) par le filtre APP_FILTER sont autorisées à accéder à la fonction 111 de gestion d'une politique de trafic. Par exemple, la donnée d'identification {4234d49b; 1} est retourné par le réseau pour indiquer au terminal 100 que toutes les applications exceptée celle ayant pour identifiant "4234d49b" sont habilitées à accéder à la fonction 111 de gestion d'une politique de trafic. Il importe également de noter que plusieurs couples {APP_FILTER , OP} peuvent être transmis au terminal 100 par le contrôleur 210 du réseau de télécommunication sous la forme d'une liste ordonnée LIST. Typiquement, ces couples ont la même valeur d’opérande. Si les couples de la liste LIST comprennent des opérandes distincts, alors les filtres sont appliqués conformément à l’ordre dans lequel ils sont listés. Selon une implémentation particulière, cette donnée IMURIG_CAPABLE(LIST , GRANT_M) comprend en outre une donnée GRANT_M représentative d'un mécanisme d'authentification auprès dudit réseau de télécommunication d'une application informatique souhaitant accéder à la fonction de gestion d'une politique de trafic . Autrement dit, cette donnée GRANT_M caractérise le mécanisme d'authentification devant être initié par le système d'exploitation 110 du terminal 100 auprès du réseau de télécommunication afin qu'une de ses applications informatiques souhaitant accéder à la fonction 111 de gestion d'une politique de trafic s'authentifie auprès du réseau de télécommunication. Cette donnée "GRANT_M" prend ici par exemple la valeur "0" lorsque le mécanisme d'authentification est une authentification par jeton éphémère, "1" lorsque le mécanisme d'authentification est une authentification par jeton à durée de vie longue, et "2" lorsqu'il s'agit d'une authentification défi-réponse. Ces différents mécanismes d'authentification sont décrits plus en détail en référence aux figures 5A-C, 6 et 7. Bien entendu, d’autres mécanismes d’authentification ou plus généralement d’autorisation peuvent être envisagés. La donnée IMURIG_CAPABLE(LIST , GRANT_M) représentative du fait que ce terminal 100 est autorisé à permettre l'accès à la fonction 111 de gestion d'une politique de trafic à au moins une de ses applications est reçue par le système d'exploitation 110 lors d'une étape S120. Puis, lors d'une étape S130, le système d'exploitation 110 extrait les informations du message reçu à l'étape S120, puis les enregistre dans une table dédiée OIG. Ces informations sont associées, dans la table OIG, à une donnée d'identification du réseau de télécommunication 200 ayant émis cette donnée IMURIG_CAPABLE(LIST , GRANT_M). La donnée d'identification du réseau de télécommunication 200 correspond par exemple à un identifiant de l’interface locale d’un terminal utilisée pour communiquer avec ledit réseau, un nom de domaine, ou à un identifiant de réseau mobile terrestre public ("Public Land Mobile Network", PLMN, selon la terminologie anglo-saxonne). Le procédé général d'accès comprend en outre une étape S300, mise en œuvre par une application informatique 120 du terminal 100, d'appel ou d'invocation de la fonction 111 de gestion d'une politique de trafic. Cette étape S300 est par exemple mise en œuvre par le module MOD_CALL précédemment évoqué. Cet appel est détecté par le système d'exploitation 110 au cours d'une étape S140. Puis, lors d'une étape S150, le système d'exploitation 110 détermine si cette application informatique (120) souhaitant accéder à la fonction 111 de gestion est autorisée, par le réseau de télécommunication 200, à y accéder. Cette étape est par exemple mise en œuvre par le module MOD_CHK de vérification précédemment évoqué. Pour ce faire, le système d'exploitation 110 détermine s'il existe une correspondance entre l'identifiant de l'application informatique 120 souhaitant accéder à la fonction 111 de gestion et une des règles de la liste LIST telles que maintenues dans la table OIG. Autrement dit, le système d'exploitation 110 vérifie, grâce à son identifiant, si cette application informatique 120 souhaitant accéder à la fonction 111 de gestion est listée comme étant autorisée à accéder à cette fonction ou n'est pas listée comme une application dont l'accès à cette fonction ne doit pas être permis. Si cette application informatique n'est pas autorisée (choix "N"), le système d'exploitation 110 met en œuvre une étape S160 au cours de laquelle il rejette l'appel détecté à l'étape S140. Si par contre cette application informatique 120 est autorisée à accéder à la fonction 111, le système d'exploitation 110 met en œuvre une étape S170 au cours de laquelle il détermine le mécanisme d'authentification à initier afin que cette application informatique 120 soit authentifiée auprès du réseau de télécommunication, par exemple en consultant la table OIG, et initie ce mécanisme d'authentification. Cette étape est par exemple également mise en œuvre par le module MOD_CHK de vérification précédemment évoqué. Si l'authentification de l'application informatique 120 auprès du réseau de télécommunication est valide, le procédé général d'accès comprend en outre une étape S180 au cours de laquelle l'accès à la fonction 111 de gestion d'une politique de trafic est autorisé à cette application informatique 120. Cette étape est par exemple mise en œuvre par le module MOD_AUTH d'autorisation d'accès précédemment évoqué. De manière plus précise, le système d'exploitation 110 autorise l'application informatique 120 à appeler une ou plusieurs fonctionnalités (ou "primitives") de la fonction 111 de gestion d'une politique de trafic. Selon une implémentation particulière, ces fonctionnalités incluent un ajout, une suppression et/ou une modification d'une règle de classification de trafic générée par le gestionnaire du réseau de télécommunication 200. Cette ou ces règles de classification de trafic sont par exemple stockées en mémoire du terminal 100. Selon une implémentation particulière, la fonctionnalité appelée correspond à l'ajout d'une règle d'association d'au moins un flux d'une communication avec le terminal 100 à au moins une tranche réseau du réseau de télécommunication 200 accessible par ledit terminal 100. Puis le système d'exploitation 110 transmet, à destination de l'application 120, un accusé de réception CALL_ACK de l'appel CALL lors d'une étape S190. Cet accusé de réception comprend un résultat de l'accès à la fonctionnalité de la fonction de gestion d'une politique de trafic, et est reçu par l'application informatique 120 lors d'une étape S310. Cette étape S310 est par exemple mise en œuvre par le module MOD_ACC précédemment évoqué. La FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un premier exemple de mise en œuvre de l’invention. Dans ce premier exemple, un système d'authentification est envisagé qui inclut d'une part un gestionnaire d'authentification AUTH_MNG 220 du réseau de télécommunication 200 notamment configuré pour générer un jeton d'authentification, et d'autre part le contrôleur 210 précédemment évoqué pour vérifier la validité de ce jeton d'authentification. Tel qu'illustré par la FIG. 5 , ce mécanisme d'authentification par jeton éphémère comprend une première étape S400-1, mise en œuvre par l'application informatique 120, au cours de laquelle cette application informatique 120 obtient une donnée d'identification telle qu'utilisée par le système d'exploitation 110 pour identifier cette application informatique 120. Typiquement, cette donnée d'identification correspond à un identifiant d’application choisi par le développeur de l’application informatique selon une nomenclature spécifique. En variante, l'identifiant de l'application est instancié par le système d'exploitation 110, par exemple au moment de l'installation de cette application 120, et le système d'exploitation 110 transmet alors cet identifiant à l'application informatique 120, ou présente à l'application informatique 120 une API lui permettant d'obtenir cet identifiant d'application. Le mécanisme d'authentification comprend en outre une étape S410-1 de transmission, par l'application informatique 120 et à destination d'un gestionnaire d'authentification AUTH_MNG 220 du réseau de télécommunication 200, d'une requête en obtention d'un jeton d'authentification GET_TOKEN incluant l'identifiant APP_ID de l'application informatique 120. Cette requête est reçue par le gestionnaire d'authentification 220 lors d'une étape S500-1. Lors d'une étape S510-1, le gestionnaire d'authentification 220 extrait l'identifiant APP_ID de l'application informatique 120 du message reçu, puis vérifie, à partir de l'identifiant extrait, si cette application informatique 120 peut effectivement recevoir un jeton d'authentification (étape S520-1). Si tel est le cas (choix "Y"), le gestionnaire d'authentification 220 met en œuvre une étape S530-1 au cours de laquelle un jeton d'authentification éphémère TKN, une estampille temporelle TS, et un identifiant UE_ID du terminal 100 sont générés. En variante, l'identifiant UE_ID du terminal 100 est généré par un dispositif électronique distinct du contrôleur 210 et du gestionnaire d'authentification 220. Lors d'une étape S540-1, le gestionnaire d'authentification 220 transmet, à destination du contrôleur 210, le jeton d'authentification éphémère TKN, l'estampille temporelle TS, et l'identifiant UE_ID du terminal 100 générés. Ces données sont reçues par le contrôleur 210 lors d'une étape S600-1, et sont par exemple enregistrées dans une table ACTIVE_TOKENS. Ces données sont également transmises par le gestionnaire d'authentification 220 à destination de l'application informatique 120, lors d'une étape S550-1, et reçues par cette même application informatique 120 lors d'une étape S420-1. Le mécanisme d'authentification par jeton éphémère comprend en outre un appel (c’est-à-dire une invocation) S430-1 de la fonction 111 de gestion d'une politique de trafic, qui est détecté par le système d'exploitation 110 lors d'une étape S700-1. Cet appel CALL comprend notamment le jeton d'authentification éphémère TKN, l'estampille temporelle TS, et l'identifiant UE_ID du terminal 100. Les étapes S430 et S700 correspondent respectivement aux étapes S300 et S140 précédemment décrites en référence à la FIG. 4 . Puis, lors d'une étape S710-1, le système d'exploitation 110 extrait les données du message reçu, et détermine la donnée d'identification (APP_ID) de l'application informatique 120 ayant réalisé cet appel. Lors d'une étape S720-1, le système d'exploitation 110 transmet, à destination du contrôleur 210, une requête en authentification CHECK_TOKEN incluant le jeton d'authentification éphémère TKN, l'estampille temporelle TS, l'identifiant UE_ID du terminal 100 et l'identifiant APP_ID de l'application informatique ayant émis l'appel à la fonction 111 de gestion d'une politique de trafic. Cette requête en authentification CHECK_TOKEN est reçue par le contrôleur 210 lors d'une étape S610-1. Puis, lors d'une étape S620-1, le contrôleur 210 extrait les informations de la requête, et compare ces informations avec les données enregistrées dans la table ACTIVE_TOKENS lors d'une étape S630-1. Si une entrée valide est trouvée dans la table ACTIVE_TOKENS, le contrôleur 210 met alors en œuvre une étape S640-1 au cours de laquelle une confirmation ACK de la validité de l'authentification est transmise au système d'exploitation 110, et reçue par ce système d'exploitation 110 lors d'une étape S730-1. Si par contre aucune entrée valide n'est trouvée (choix "N"), le contrôleur 210 met alors en œuvre une étape S650-1 au cours de laquelle une indication NACK selon laquelle l'authentification de l'application informatique 120 n'est pas valide est transmise au système d'exploitation 110, et reçue par ce système d'exploitation 110 lors d'une étape S740-1. La FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un deuxième exemple de mise en œuvre de l’invention. Ce deuxième exemple correspond à une variante des étapes S400-1 à S420-1, S500-1 à S550-1, et S600-1 en pointillés dans la FIG. 5 . Dans ce deuxième exemple, un système d'authentification est envisagé qui inclut d'une part le gestionnaire d'authentification AUTH_MNG 220 du réseau de télécommunication 200 notamment configuré pour générer un jeton d'authentification, et d'autre part le contrôleur 210 pour vérifier la validité de ce jeton d'authentification, mais à la différence du premier exemple, l'application informatique 120 n'interagit plus directement avec le gestionnaire d'authentification 220, mais avec le contrôleur 210 qui se charge alors de communiquer avec le gestionnaire d'authentification 220. Tel qu'illustré par la FIG. 5 , ce mécanisme d'authentification par jeton éphémère comprend une première étape S400-2, mise en œuvre par l'application informatique 120, au cours de laquelle cette application informatique 120 obtient une donnée d'identification APP_ID telle qu'utilisée par le système d'exploitation pour identifier cette application informatique 120. Cette étape est similaire à l'étape S400-1 précédemment évoquée en référence à la FIG. 5 . Le mécanisme d'authentification comprend en outre une étape S410-2 de transmission, par l'application informatique 120 et à destination du contrôleur 210 du réseau de télécommunication 200, d'une requête GET_TOKEN en obtention d'un jeton d'authentification TKN incluant l'identifiant APP_ID de l'application informatique 120. Cette requête est reçue par le contrôleur 210 lors d'une étape S600-2. Lors d'une étape S610-2, le contrôleur 210 extrait l'identifiant APP_ID de l'application informatique 120 du message reçu, puis vérifie, à partir de l'identifiant APP_ID extrait, si cette application informatique 120 peut effectivement recevoir un jeton d'authentification (étape S620-2). Si tel est le cas (choix "Y"), le contrôleur 210 transmet, lors d'une étape S630-2, une requête GET_TOKEN en obtention d'un jeton d'authentification, qui est reçue par le gestionnaire d'authentification 220 lors d'une étape S500-2. Le gestionnaire d'authentification 220 met en œuvre une étape S510-2 au cours de laquelle un jeton d'authentification éphémère TKN, une estampille temporelle TS et un identifiant UE_ID du terminal 100 sont générés. En variante, l'identifiant UE_ID du terminal 100 est généré par un dispositif électronique distinct du contrôleur 210 et du gestionnaire d'authentification 220. Lors d'une étape S520-2, le gestionnaire d'authentification 220 transmet, à destination du contrôleur 210, le jeton d'authentification éphémère TKN, l'estampille temporelle TS, et l'identifiant UE_ID du terminal 100 générés. Ces données sont reçues par le contrôleur 210 lors d'une étape S640-2, et sont par exemple enregistrées dans une table ACTIVE_TOKENS. Ces données sont ensuite transmises par le contrôleur 210 et à destination de l'application informatique 120 lors d'une étape S650-2, et reçues par cette même application informatique 120 lors d'une étape S420-2. Le mécanisme d'authentification comprend en outre les étapes S430-1, S700-1 et suivantes préalablement décrites en référence à la FIG. 5 , et qui ne sont donc pas répétées ici, par souci de concision. La FIG. 5 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification éphémère, selon un troisième exemple de mise en œuvre de l’invention. Ce troisième exemple correspond à une variante des étapes S400-1 à S420-1, S500-1 à S550-1, et S600-1 en pointillés dans la FIG. 5 . Dans ce troisième exemple, le système d'authentification comprend uniquement le contrôleur 210. Tel qu'illustré par la FIG. 5 , ce mécanisme d'authentification par jeton éphémère comprend une première étape S400-3, mise en œuvre par l'application informatique 120, au cours de laquelle cette application informatique 120 obtient une donnée d'identification APP_ID telle qu'utilisée par le système d'exploitation pour identifier cette application informatique 120. Cette étape est similaire à l'étape S400-1 précédemment évoquée en référence à la FIG. 5 . Le mécanisme d'authentification par jeton éphémère comprend en outre une étape S410-3 de transmission, par l'application informatique 120 et à destination du contrôleur 210 du réseau de télécommunication 200, d'une requête GET_TOKEN en obtention d'un jeton d'authentification TKN incluant l'identifiant APP_ID de l'application informatique 120. Cette requête est reçue par le contrôleur 210 lors d'une étape S600-3. Lors d'une étape S610-3, le contrôleur 210 extrait l'identifiant APP_ID de l'application informatique 120 du message reçu, puis vérifie, à partir de l'identifiant APP_ID extrait, si cette application informatique 120 peut effectivement recevoir un jeton d'authentification (étape S620-3). Si tel est le cas (choix "Y"), le contrôleur 210 met en œuvre une étape S630-3 au cours de laquelle un jeton d'authentification éphémère TKN, une estampille temporelle TS, et un identifiant UE_ID du terminal 100 sont générés. En variante, l'identifiant UE_ID du terminal 100 est généré par un dispositif électronique distinct du contrôleur 210 et du gestionnaire d'authentification 220. Puis, lors d'une étape S640-3, le contrôleur 210 transmet, à destination de l'application informatique 120, le jeton d'authentification éphémère TKN, l'estampille temporelle TS, et l'identifiant UE_ID du terminal 100 générés. Ces données sont reçues par cette même application informatique 120 lors d'une étape S420-3. Le mécanisme d'authentification comprend en outre les étapes S430-1, S700-1 et suivantes préalablement décrites en référence à la FIG. 5 , et qui ne sont donc pas réitérées ici, par souci de concision. La FIG. 6 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par jeton d'authentification à durée de vie longue, selon un exemple de mise en œuvre de l’invention. Tel qu'illustré par la FIG. 6 , ce mécanisme d'authentification par jeton à durée de vie longue comprend une première étape S400-4, mise en œuvre par l'application informatique 120, au cours de laquelle cette application informatique 120 obtient une donnée d'identification telle qu'utilisée par le système d'exploitation pour identifier cette application informatique 120. Typiquement, cette donnée d'identification correspond à un identifiant d’application APP_ID choisi par le développeur de l’application informatique selon une nomenclature spécifique. En variante, l'identifiant de l'application APP_ID est instancié par le système d'exploitation 110, par exemple au moment de l'installation de cette application, et le système d'exploitation 110 transmet alors cet identifiant APP_ID à l'application informatique 120, ou présente à l'application informatique 120 une API lui permettant d'obtenir cet identifiant d'application APP_ID. Le mécanisme d'authentification comprend en outre une étape S410-4 de transmission, par l'application informatique 120 et à destination du contrôleur 210 du réseau de télécommunication 200, d'une requête GET_TOKEN en obtention d'un jeton d'authentification incluant l'identifiant APP_ID de l'application informatique 120. Cette requête est reçue par le contrôleur 210 lors d'une étape S600-4. Lors d'une étape S610-4, le contrôleur 210 extrait l'identifiant APP_ID de l'application informatique 120 du message reçu, puis vérifie, à partir de l'identifiant extrait, si cette application informatique 120 peut effectivement recevoir un jeton d'authentification (étape S620-4). Si tel est le cas (choix "Y"), le contrôleur 210 met en œuvre une étape S630-4 au cours de laquelle un jeton d'authentification à durée de vie longue TKN et un identifiant UE_ID du terminal 100 sont générés. Ces données sont alors par exemple enregistrées dans une table ACTIVE_TOKENS accessible par ce contrôleur 210. Lors d'une étape S640-4, le contrôleur 210 transmet, à destination de l'application informatique 120, le jeton d'authentification TKN et l'identifiant UE_ID du terminal 100, qui sont reçus par l'application informatique 120 lors d'une étape S420-4. Le mécanisme d'authentification par jeton à durée de vie longue comprend en outre une étape S430-4 d'appel (d’invocation) de la fonction 111 de gestion d'une politique de trafic, cet appel CALL étant alors détecté par le système d'exploitation 110 lors d'une étape S700-4. L'appel comprend notamment le jeton d'authentification TKN et l'identifiant UE_ID du terminal 100 préalablement reçus à l'étape S420-4. Puis, lors d'une étape S710-4, le système d'exploitation 210 extrait les données du message reçu, et détermine la donnée d'identification APP_ID de l'application informatique 120 ayant réalisé cet appel. Puis, lors d'une étape S720-4, le système d'exploitation 110 transmet, à destination du contrôleur 210, une requête en authentification CHECK_TOKEN incluant le jeton d'authentification TKN, l'identifiant UE_ID du terminal 100 et l'identifiant APP_ID de l'application informatique ayant émis l'appel à la fonction 111 de gestion d'une politique de trafic. Cette requête en authentification CHECK_TOKEN est reçue par le contrôleur 210 lors d'une étape S650-4. Lors d'une étape S660-4, le contrôleur 210 extrait les informations de la requête, et compare ces informations avec les données enregistrées dans la table ACTIVE_TOKENS lors d'une étape S630-1. Si aucune entrée valide est trouvée dans la table ACTIVE_TOKENS (choix "N"), le contrôleur 210 met alors en œuvre une étape S670-1 au cours de laquelle une indication NACK selon laquelle l'authentification de l'application informatique 120 n'est pas valide est transmise au système d'exploitation 110, et reçue par ce système d'exploitation 110 lors d'une étape S730-4. Si par contre une entrée valide est trouvée (choix "Y"), le contrôleur 210 met alors en œuvre une étape S680-4 au cours de laquelle une confirmation ACK de la validité de l'authentification de l'application informatique 120 est transmise au système d'exploitation 110, et reçue par ce système d'exploitation 110 lors d'une étape S740-4. Cette confirmation ACK inclut une valeur P représentative d'une durée au cours de laquelle un nouvel accès à la fonction 111 de gestion d'une politique de trafic doit être autorisé par le système d'exploitation 110 sans qu'une nouvelle authentification de ladite application informatique 120 auprès dudit réseau de télécommunication 200 ne soit nécessaire. En réponse à la réception de cette confirmation ACK, le système d'exploitation 110 met en œuvre une étape S750-4 au cours de laquelle il autorise l'accès à la fonction 111 de gestion d'une politique de trafic par l'application informatique 120. Au cours de cette même étape S750-4, le système d'exploitation 110 enregistre le jeton d'authentification TKN, l'identifiant UE_ID du terminal 100, l'identifiant APP_ID de l'application informatique, ainsi que la valeur de la durée P dans une table "LOCAL_TOKENS". Enfin, le mécanisme d'authentification comprend une étape S760-4, mise en œuvre par le système d'exploitation 110 après que la durée P soit découlée, et au cours de laquelle le système d'exploitation 110 retire l’entrée correspondante de la table LOCAL_TOKENS. Ainsi, dans le cadre de ce mode de réalisation, dès qu'un appel à la fonction 111 de gestion d'une politique de trafic est détecté par le système d'exploitation 110, ce dernier consulte la table LOCAL_TOKENS et vérifie si elle contient une entrée incluant l'identifiant de l'application informatique appelante. Si tel est le cas, cela signifie qu'une nouvelle authentification de l'application informatique appelante auprès du réseau de télécommunication 200 n'est pas nécessaire, et l'accès à la fonction 111 est alors autorisé par le système d'exploitation 110. Le mécanisme d'authentification par jeton d'authentification à durée de vie longue a jusqu'à présent été décrit dans le cas où le système d'authentification ne comprend que le contrôleur 210. Il n'en reste pas moins applicable dans le cas où le système d'authentification comprend le contrôleur 210 et le gestionnaire d'authentification, tels que présentés en référence aux figures 5A et 5B. La FIG. 7 illustre, sous forme d’ordinogramme, un mécanisme d'authentification d'une application informatique auprès d'un réseau de télécommunication par défi-réponse, selon un exemple de mise en œuvre de l’invention. Tel qu'illustré par la FIG. 7 , le mécanisme d'authentification d'une application informatique par défi-réponse comprend une première étape S400-5, mise en œuvre par une application informatique 120, d'appel (ou d’invocation) à la fonction 111 de gestion d'une politique de trafic. Cet appel CALL est détecté par le système d'exploitation 110 lors d'une étape S700-5. En réponse à cette détection, le système d'exploitation 110 transmet, à destination de l'application, un message CHALLENGE incluant un défi CHAL ainsi qu'une estampille temporelle TS, et qui est reçu par l'application 120 lors d'une étape S410-5. Lors d'une étape S720-5, le système d'exploitation 110 détermine la donnée d'identification APP_ID de l'application informatique 120 ayant réalisé cet appel CALL. Puis il transmet, à destination du contrôleur 210, des données de paramétrage SHARE_CHALLENGE d'une authentification incluant le défi CHAL, une réponse RESP – dite première réponse – associée au défi CHAL, et l'estampille temporelle TS. Ces données de paramétrage sont reçues par le contrôleur 210 lors d'une étape S600-5. Puis, lors d'une étape S610-5, le contrôleur 210 extrait les données de paramétrage SHARE_CHALLENGE, et les enregistre dans une table ACR. En réponse à la réception S410-5 du message CHALLENGE par l'application informatique 120, cette dernière transmet, lors d'une étape S430-5, une requête SEEK_RESPONSE en obtention d'une réponse ayant comme paramètres le défi CHAL, l'estampille temporelle TS, ainsi que l'identifiant de l'application APP_ID à destination du contrôleur 210. Cette requête SEEK_RESPONSE est reçue par le contrôleur 210 lors d'une étape S620-5, qui vérifie alors lors d'une étape S630-5 si une entrée est présente dans la table ACR. Si tel est le cas, le contrôleur met en œuvre une étape S640-5 de transmission, à destination de l'application informatique 120, d'un accusé de réception ACK incluant une réponse RESP* – dite deuxième réponse –, qui correspond à la réponse associée au défi CHAL dans la table ACR. Cet accusé de réception ACK est reçu par l'application informatique 120 lors d'une étape S440-5. Le mécanisme d'authentification comprend en outre une étape S450-5 de transmission de cette réponse RESP* au système d'exploitation 110. Cette réponse RESP* est reçue par le système d'exploitation 110 lors d'une étape S740-5, et ce dernier compare les première et deuxième réponses, et vérifie si elles sont égales ou pas. Si tel est le cas (choix "Y"), l'accès à la fonction 111 de gestion d'une politique de trafic est accordé à l'application informatique 120. Il importe de noter que l'étape S710-5 et les deux étapes S720-5 et S730-5 ne sont pas liées à une notion de succession temporelle. En effet, l'étape S710-5 et les deux étapes S720-5 et S730-5 peuvent être mises en œuvre de manière simultanée, mais les deux étapes S720-5 et S730-5 peuvent également être mises en œuvre avant l'étape S710-5. Le mécanisme d'authentification par défi-réponse a jusqu'à présent été décrit dans le cas où le système d'authentification ne comprend que le contrôleur 210. Il n'en reste pas moins applicable dans le cas où le système d'authentification comprend le contrôleur 210 et le gestionnaire d'authentification, tels que présentés en référence aux figures 5A et 5B. Procédé de gestion d'un accès à une fonction (111) de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal (100) connecté à un réseau de télécommunication (200), le procédé comprenant les étapes suivantes, mises en œuvre par un système d'exploitation (110) dudit terminal (100) : une vérification (S150, S170) qu'une application informatique (120) du terminal (100) souhaitant accéder à la fonction (111) de gestion d'une politique de trafic est autorisée à invoquer cette fonction, en utilisant une procédure d’autorisation mise en œuvre via le réseau de télécommunication et sélectionnée par un contrôleur (210) du réseau de télécommunication (200) ; et, une autorisation d'accès (S180) à la fonction (111) par ladite application informatique, en fonction d’un résultat de la vérification. Procédé de gestion d'un accès selon la revendication 1, comprenant en outre, une réception (S120), par le système d'exploitation (110) et en provenance du contrôleur (210) du réseau de télécommunication (200), d'une donnée représentative d'applications informatiques autorisées ou pas à gérer la politique de trafic, et d'une donnée représentative d'un mécanisme d'authentification d'une application informatique souhaitant accéder à la fonction (111) de gestion d'une politique de trafic auprès dudit réseau de télécommunication (200) ; la vérification que l'application informatique (120) est autorisée à gérer la politique de trafic étant mise en œuvre en fonction desdites données reçues. Procédé d’accès à une fonction (111) de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal (100) connecté à un réseau de télécommunication (200), le procédé comprenant les étapes suivantes mises en œuvre par une application informatique dudit terminal (100) : une invocation (S300) de la fonction (111) de gestion d'une politique de trafic ; une transmission, à un système d'exploitation (110) du terminal (100), d'un élément d'authentification reçu d'un système d'authentification (210, 220) du réseau de télécommunication (200) et requis par une procédure d'autorisation sélectionnée et mise en œuvre via le réseau de télécommunication (200) ; et, un accès (S310) à ladite fonction (111) de gestion d'une politique de trafic, en fonction d'un résultat de la procédure d'autorisation. Procédé d’accès selon la revendication 3, dans lequel l'élément d'authentification inclut un jeton d'authentification (TKN) transmis au système d'exploitation (110) lors de l'invocation de la fonction. Procédé d’accès selon la revendication 3 ou 4, comprenant en outre une transmission, à destination du système d'exploitation (110), d'une donnée d'identification (UE_ID) du terminal (100) et/ou d'une estampille temporelle. Procédé d’accès selon la revendication 3, dans lequel l'élément d'authentification inclut une réponse (RESP*) associée à un défi (CHAL) transmise (S450-5) au système d'exploitation (110) suite à une réception (S410-5) du défi (CHAL) en provenance du système d'exploitation (110). Procédé selon l'une des revendications 1 à 6, dans lequel la fonction (111) de gestion d'une politique de trafic comprend un ajout, une suppression et/ou une modification d'une règle de classification de trafic générée par un gestionnaire du réseau de télécommunication (200). Procédé selon la revendication 7, dans lequel la fonction (111) de gestion d'une politique de trafic comprend l'ajout d'une règle d'association d'au moins un flux d'une communication avec le terminal (100) à au moins une tranche réseau du réseau de télécommunication (200) accessible par ledit terminal (100). Procédé selon l'une des revendications 1 à 8, dans lequel la procédure d’autorisation comprend une authentification par jeton d'authentification ou une authentification de type défi-réponse. Procédé selon l'une des revendications 1 à 9, dans lequel la procédure d’autorisation comprend une authentification par jeton d'authentification, et le procédé comprend en outre une étape mise en œuvre par le système d'exploitation (110) du terminal (100) de transmission (S720-1, S720-4), à destination dudit contrôleur (210), d'une requête d’authentification (CHECK_TOKEN) de ladite application informatique (120) incluant un jeton d'authentification (TKN) préalablement généré par un système d'authentification (210, 220) et fourni au système d’exploitation (110) par l'application informatique (120). Procédé selon la revendication 10, dans lequel la requête d'authentification (CHECK_TOKEN) inclut en outre une donnée d'identification (APP_ID) de ladite application informatique (120), ladite donnée d'identification (APP_ID) étant contrôlée par le système d'exploitation (110) du terminal (100). Procédé selon la revendication 10 ou 11, dans lequel la requête d'authentification (CHECK_TOKEN) inclut en outre une donnée d'identification (UE_ID) du terminal (100) préalablement communiquée par le système d'authentification (210, 220) et fournie au système d’exploitation par l'application informatique (120). Procédé selon l'une des revendications 10 à 12, dans lequel la requête d'authentification (CHECK_TOKEN) inclut en outre une estampille temporelle (TS) préalablement communiquée par le système d'authentification (210, 220) et fournie au système d’exploitation (110) par l'application informatique (120). Procédé selon l'une des revendications 10 à 12, dans lequel l'authentification est une authentification par jeton d'authentification à durée de vie longue, et si l'authentification de ladite application informatique (120) est valide, un résultat de l'authentification fourmi par le contrôleur (210) au système d'exploitation (110) inclut une durée (P) au cours de laquelle un nouvel accès à la fonction (111) de gestion d'une politique de trafic doit être autorisé par le système d'exploitation (110) sans qu'une nouvelle authentification de ladite application informatique (120) auprès du réseau de télécommunication (200) ne soit nécessaire. Procédé de gestion d'un accès selon l'une des revendications 1 ou 2, dans lequel la procédure d'autorisation est une authentification défi-réponse, et le procédé comprend en outre les étapes suivantes, mises en œuvre par le système d'exploitation (110) : une transmission (S710-5), à destination de l'application informatique (120), d'un défi (CHAL) ; une transmission (S730-5), à destination dudit contrôleur (210), de données de paramétrage incluant le défi (CHAL) et une première réponse (RESP) associée au défi (CHAL) ; une réception (S740-5) d'une deuxième réponse (RESP*) préalablement fournie à ladite application informatique (120) par le contrôleur (210) en réponse à une réception (S620) d'une requête (SEEK_RESPONSE) en obtention d'une réponse, émise par l'application informatique (120) et incluant ledit défi (CHAL) ; et l'accès (S760-5) à la fonction (111) de gestion d'une politique de trafic est autorisé si les première et deuxième réponses sont égales. Procédé d'accès selon l'une des revendications 3 à 9 en combinaison avec la revendication 3, dans lequel la procédure d'autorisation est une authentification défi-réponse, et le procédé comprend en outre les étapes suivantes, mises en œuvre par l'application informatique (120) : une transmission (S430-5), à destination du contrôleur (210), d'une requête (SEEK_RESPONSE) en obtention d'une réponse incluant un défi (CHAL) fourni à l'application informatique (120) par le système d'exploitation (110) ; et, une transmission (450-5), à destination du système d'exploitation (110), d'une deuxième réponse (RESP*) fournie à l'application informatique (120) par le contrôleur (210) suite à la réception (S620-5) de la requête (SEEK_RESPONSE) en obtention d'une réponse. Procédé de contrôle d'un accès à une fonction (111) de gestion d'une politique de trafic, la fonction étant mise en œuvre par un terminal (100) connecté à un réseau de télécommunication (200), le procédé comprenant les étapes suivantes mises en œuvre par un contrôleur (210) du réseau de télécommunication (200) : une détermination (S230) que ledit terminal (100) est autorisé à permettre l'accès par des applications informatiques dudit terminal (100) à la fonction (111) de gestion d'une politique de trafic ; et, une transmission (S250), à destination du terminal (100), d'une donnée d'identification d'applications informatiques autorisées ou pas à gérer la politique de trafic, et d'une donnée représentative d'un mécanisme d'authentification, auprès dudit réseau de télécommunication (200), d'une application informatique souhaitant accéder à la fonction (111) de gestion d'une politique de trafic. Procédé de contrôle d'un accès selon la revendication 17, dans lequel le mécanisme d'authentification est une authentification par jeton d'authentification, le procédé comprenant en outre les étapes suivantes, mises en œuvre par un système d'authentification (210, 220) du réseau de télécommunication (200) : en réponse à une réception (S500-1, S600-2, S600-3, S600-4) d'une requête en obtention d'un jeton d'authentification émise par l'application informatique (120) du terminal (100) et incluant une donnée d'identification (APP_ID) de ladite application informatique (120), une vérification (S520-1, S620-2, S620-3, S620-4), en fonction de ladite donnée d'identification, si ladite application (120) peut obtenir un jeton d'authentification ; et, une transmission (S550-1, S650-2, S640-3, S640-4), à destination de l'application informatique (120), d'un jeton d'authentification (TKN) généré en fonction de la vérification (S520-1, S620-2, S620-3, S620-4). Procédé de contrôle d'un accès selon la revendication 18, comprenant en outre les étapes suivantes, mises en œuvre par le système d'authentification (210, 220): une génération (S530-1, S510-2, S630-3, S630-4) d'une donnée d'identification (UE_ID) dudit terminal (100) ; et, une transmission (S550-1, S650-2, S640-3, S640-4) de la donnée d'identification (UE_ID) dudit terminal (100) à destination de l'application informatique (120). Terminal (100) configuré pour mettre en œuvre le procédé selon l'une des revendications 1 à 16. Contrôleur (210) d'un réseau de télécommunication (200) configuré pour mettre en œuvre le procédé de contrôle selon l'une des revendications 17 à 19.