FR 3157755 A1 20250627 FR 2314761 A 20231221 L’invention se rapporte à un procédé de fourniture à une application (APP) installée sur un terminal (Terminal), par un système d’exploitation (OS) dudit terminal (Terminal), d’un accès à une fonction du système d’exploitation. Le procédé comprend une étape d’établissement d'au moins un canal de communication avec au moins une entité (NEAT) d'un réseau (Network) hébergeant pour un dispositif de gestion du système d’exploitation (OVI) au moins une fonction dite fonction déportée (F’ j ) du système d’exploitation (OS) ; une étape d’exposition (Expo_F’ j ) à l'application (APP) de ladite fonction déportée (F’ j ) comme une fonction mise en œuvre localement par le système d’exploitation (OS) ; sur réception d'un message (Call_F’ j ) de l'application (APP) invoquant ladite fonction déportée (F’ j ), une étape de transfert du message (Call_F’ j ) vers l’entité (NEAT) du réseau hébergeant ladite fonction déportée (F’ j ), via le canal de communication établi avec cette entité (NEAT) du réseau. Figure pour l’abrégé : Fig. 3 Procédé de fourniture à une application d’un accès à une fonction d’un système d’exploitation d’un terminal La présente invention se rapporte au domaine des télécommunications, et plus particulièrement de celui de services IP à valeur ajoutée. Art Antérieur La FIG. 1 représente un exemple de structure interne simplifiée d’un terminal. Un tel terminal embarque différentes applications associées à différents services et un système d’exploitation OS (« Operating System », en anglais) adapté pour supporter ces différentes applications. L’accès à certains services nécessite le support et l’activation de fonctions spécifiques également appelées primitives ou API (pour « Application Programming Interface » en anglais) dans le terminal, telles que des fonctions de priorisation, d’accélération de trafic ou de chiffrement des données caractéristiques de l’usage de tels services. Ces fonctions spécifiques sont hébergées dans le terminal. Or, il y a un besoin de permettre à un utilisateur d’accéder à de nouveaux services utilisant de nouvelles fonctions sans qu’il soit nécessaire de changer de terminal. En outre, des applications dédiées peuvent être utilisées pour accéder à un service depuis un terminal. Ces applications peuvent solliciter des traitements spécifiques des fonctions exposées par l’OS du terminal. Or, l’accès à certaines fonctions peut être limité par l’OS. Par exemple, une application de socket réseau peut être limitée à la recherche de points d’accès Wi-Fi pour la connexion d’un terminal au réseau ou interdire les communications IPv6. L’invention propose une procédure collaborative entre un terminal, un réseau et des plateformes de service qui permet notamment de répondre au besoin et de remédier aux inconvénients précités. Cette procédure s’affranchit des limitations éventuellement imposées par l’OS, pour optimiser la fourniture et l’accès aux services depuis des terminaux connectés à ce réseau, que ces services soient ou non de nouveaux services. Plus spécifiquement, un objet de l’invention concerne un procédé de fourniture à une application installée sur un terminal, par un système d’exploitation dudit terminal, d’un accès à une fonction du système d’exploitation, ledit procédé comprenant : une étape d’établissement d'au moins un canal de communication avec au moins une entité d'un réseau hébergeant pour un dispositif de gestion du système d’exploitation au moins une fonction dite fonction déportée du système d’exploitation, ladite étape d’établissement utilisant au moins une information fournie par le dispositif de gestion du système d’exploitation ; - une étape d’exposition à l'application de ladite fonction déportée comme une fonction mise en œuvre localement par le système d’exploitation; et - sur réception d'un message de l'application invoquant ladite fonction déportée, une étape de transfert du message vers l’entité du réseau hébergeant ladite fonction déportée, via le canal de communication établi avec cette entité du réseau. L’invention propose d’émuler une fonction du système d’exploitation, dite fonction déportée, ailleurs que dans un terminal utilisateur et de mettre en place des mécanismes adéquats pour encapsuler/transporter les messages d’invocation de cette fonction. Cette fonction déportée est alors localisée dans une entité d’un réseau et peut être présentée et être accessible, aux applications du terminal comme si elle était embarquée dans le terminal. L’invention propose ainsi un mécanisme collaboratif destiné à utiliser un réseau de communication pour permettre une extension des fonctions offertes par un système d’exploitation du terminal. Les capacités fonctionnelles du terminal utilisateur sont également augmentées par ces fonctions déportées qui sont fournies depuis un réseau de communication via un ou plusieurs canaux dédiés. Ce mécanisme permet d’augmenter la durée d’utilisation du terminal, celui-ci pouvant accéder à de nouvelles fonctions voire des fonctions avancées traditionnellement non-supportées par le terminal (pour des contraintes matérielles, coûts, etc.) sans qu’il soit nécessaire de le remplacer par un terminal de génération plus récente. En outre, les opérations de gestion et de maintenance du terminal sont simplifiées en raison notamment de mises à jour logicielles moins fréquentes grâce à l’invention. L’invention présente ainsi des perspectives d’économie substantielles pour des utilisateurs toujours plus nombreux à être sensibilisés aux enjeux d’une économie durable capable de tenir compte des ressources limitées de la planète tout en permettant l’accès à de nouveaux services. Dans une variante de réalisation, avant l’établissement d’un dit canal de communication avec ladite entité du réseau, le procédé comprend une étape d’authentification du terminal auprès de cette entité. On améliore ainsi la sécurité globale du procédé de fourniture de l’accès à une fonction du système d’exploitation. Dans une variante de réalisation, le procédé comprend une étape de réception, en provenance de ladite entité du réseau, d’une liste de fonctions déportées hébergées par cette entité du réseau, pour exposition à ladite application. Le terminal dispose ainsi de l’ensemble des fonctions déportées hébergées par l’entité du réseau. Dans une variante de réalisation, le procédé comprend une étape de réception en provenance de ladite entité du réseau d’au moins une indication de marquage destinée à être appliquée à au moins un paquet de données émis par l’application avant d’être transféré par le système d’exploitation vers cette entité du réseau. Cette étape de réception d’une indication de marquage facilite le traitement du paquet de données par l’entité réseau et éventuellement l’identification par le système d’exploitation des messages qui sont éligibles au transfert vers l’entité réseau. Dans une variante de réalisation, le procédé de fourniture comprend : - une étape d’identification d’au moins un paquet de données émis par l'application destiné à être transmis via ledit canal de communication établi vers ladite entité du réseau; et - une étape de transfert dudit au moins un paquet identifié vers ladite entité du réseau via ledit canal de communication. Il est ainsi possible de transférer à l’entité réseau le paquet de données à traiter par une fonction déportée au lieu d’un traitement local au niveau du terminal. Dans une variante de réalisation, le procédé comprend une étape de transfert à l’application d’un message reçu en provenance de l’entité du réseau hébergeant la fonction déportée invoquée par l’application. L’OS transmet ainsi les données traitées par la fonction déportée à l’application. L’appel d’une fonction déportée est ainsi transparent pour l’application. Dans une variante de réalisation, sur réception du message provenant de l’application invoquant une fonction requise pour le service, le procédé comprend une étape préalable de vérification si cette fonction est hébergée localement par le système d’exploitation ou déportée sur l’entité du réseau. Cette étape de vérification conditionne le transfert du message ou le traitement en local de ce message par un terminal. Un autre objet de l’invention concerne un procédé de communication mis en œuvre par un dispositif de gestion d’un système d’exploitation d’un terminal connecté à un réseau, ledit procédé comprenant : - une étape d’obtention auprès d’un contrôleur du réseau d’au moins une information permettant d’accéder à au moins une entité du réseau, sélectionnée par ledit contrôleur du réseau pour le dispositif de gestion pour héberger au moins une fonction dite fonction déportée dudit système d’exploitation ; - une étape d’envoi au contrôleur du réseau de données permettant d’activer ladite fonction déportée dudit système d’exploitation sur l’entité du réseau sélectionnée ; et - suite à une réception d’un message en provenance du système d’exploitation du terminal, une étape d’envoi audit système d’exploitation de l’information pour permettre au terminal d’établir un canal de communication avec l’entité du réseau hébergeant ladite fonction déportée. Ces étapes préalables de communication permettent un fonctionnement optimal du procédé de fourniture de l’accès à une fonction déportée du système d’exploitation. Dans une variante de réalisation, l’étape d’obtention fait suite à une étape d’envoi d’un message au contrôleur indiquant au moins une contrainte à satisfaire par l’entité du réseau. Ces contraintes sont, par exemple, un délai de transit IP, un temps d’invocation, une contrainte de localisation, etc. Un autre objet de l’invention concerne un procédé de contrôle par un contrôleur d’un réseau, comprenant : - une étape d’envoi à un dispositif de gestion d’un système d’exploitation d’un terminal connecté au réseau, d’au moins une information permettant d’accéder à au moins une entité du réseau sélectionnée par le contrôleur pour le dispositif de gestion pour héberger au moins une fonction dite fonction déportée du système d’exploitation ; et - une étape d’activation de ladite fonction déportée sur ladite entité du réseau en utilisant des données reçues du dispositif de gestion permettant cette activation. Ces étapes préalables de contrôle permettent un fonctionnement optimal du procédé de fourniture de l’accès à une fonction déportée du système d’exploitation. Dans une variante de réalisation, l’entité du réseau sélectionnée vérifie au moins une contrainte indiquée par le dispositif de gestion. Ces contraintes sont, par exemple, un délai de transit IP, un temps d’invocation, une contrainte de localisation, etc. Un autre objet de l’invention concerne un procédé d’hébergement d’au moins une fonction dite fonction déportée d’un système d’exploitation d’un terminal connecté à un réseau, ledit procédé étant mis en œuvre par une entité du réseau, sélectionnée par un contrôleur du réseau pour héberger ladite fonction déportée pour un dispositif de gestion du système d’exploitation, ledit procédé comprenant : - une étape d’établissement d’un canal de communication avec ledit système d’exploitation du terminal sur la base d’au moins une information reçue du terminal et fournie par le dispositif de gestion audit terminal pour lui permettre d’établir ledit canal de communication ; - une étape de vérification que ledit terminal est autorisé à invoquer la fonction déportée hébergée par l’entité du réseau ; - suite à la réception via ledit canal de communication d'un message d’une application embarquée sur le terminal invoquant la fonction déportée, une étape d’exécution de ladite fonction déportée si ladite fonction déportée est autorisée pour le terminal. Il est ainsi possible d’introduire un mécanisme qui permet d’émuler une fonction du système d’exploitation, dite fonction déportée, ailleurs que dans le terminal via la mise en place de mécanismes adéquats pour encapsuler/transporter les message d’invocation de l’application invoquant cette fonction. Cette fonction déportée est localisée dans une entité d’un réseau et peut être présentée, et donc accessible, aux applications du terminal utilisateur comme si elle était embarquée dans le terminal de l’utilisateur. L’invention propose ainsi un mécanisme collaboratif destiné à utiliser une entité d’un réseau de communication comme une extension d’un système d’exploitation du terminal. Dans une variante de réalisation suite à l’étape de vérification, le procédé d’hébergement comprend une étape d’envoi au système d’exploitation du terminal d’une liste de fonctions déportées hébergées par l’entité du réseau et autorisées pour le terminal. Il est ainsi possible au système d’exploitation du terminal d’accéder à la liste de fonctions déportées hébergées par l’entité du réseau. Dans une variante de réalisation, si au moins une fonction déportée hébergée par l’entité du réseau est autorisée pour le terminal, le procédé d’hébergement comprend une étape de mémorisation d’au moins un élément parmi : - au moins un paramètre d'invocation de la fonction déportée compris dans un message invoquant cette fonction déportée, - au moins une information descriptive du canal de communication ; et/ou - au moins une information envoyée au terminal suite à l’étape de vérification. Cette étape de mémorisation permet à l’entité réseau d’exécuter la fonction déportée sur le paquet de données en utilisant un ou plusieurs éléments mémorisés. Dans une variante de réalisation, le procédé d’hébergement comprend, suite à la réception d’un paquet de données en provenance de l’application embarquée sur le terminal via ledit canal de communication ou d’un paquet de données destiné à ladite application, une étape d’exécution de la fonction déportée sur ledit paquet de données en utilisant au moins un élément mémorisé lors de l’étape de mémorisation. On permet ainsi d’émuler une fonction du système d’exploitation ailleurs que dans le terminal. Un autre objet de l’invention concerne un terminal pour la fourniture à une application installée sur ledit terminal d’un accès à une fonction d’un système d’exploitation appartenant audit terminal, ledit terminal comprenant : - un module pour établir au moins un canal de communication avec au moins une entité d'un réseau hébergeant pour un dispositif de gestion du système d’exploitation au moins une fonction dite fonction déportée du système d’exploitation, ladite étape d’établissement utilisant au moins une information fournie par le dispositif de gestion du système d’exploitation ; - un module pour exposer à l'application de ladite fonction déportée comme une fonction mise en œuvre localement par le système d’exploitation ; et - sur réception d'un message de l'application invoquant ladite fonction déportée, un module pour transférer le message vers l’entité du réseau hébergeant ladite fonction déportée, via le canal de communication établi avec cette entité du réseau. Un tel terminal permet la mise en œuvre du procédé de fourniture d’un accès à une fonction déportée du système d’exploitation objet de l’invention. Un autre objet de l’invention concerne un dispositif de gestion d’un système d’exploitation d’un terminal connecté à un réseau, ledit dispositif de gestion comprenant : - un module d’obtention auprès d’un contrôleur du réseau d’au moins une information permettant d’accéder à au moins une entité du réseau, sélectionnée par ledit contrôleur du réseau pour le dispositif de gestion pour héberger au moins une fonction dite fonction déportée dudit système d’exploitation ; - un module d’envoi au contrôleur du réseau de données permettant d’activer ladite fonction déportée dudit système d’exploitation sur l’entité du réseau sélectionnée ; et - suite à une réception d’un message en provenance du système d’exploitation du terminal, un module d’envoi audit système d’exploitation de l’information pour permettre au terminal d’établir un canal de communication avec l’entité du réseau hébergeant ladite fonction déportée. Un tel dispositif de gestion permet la mise en œuvre d’un procédé de communication objet de l’invention. Un autre objet de l’invention concerne un contrôleur réseau comprenant : - un module d’envoi à un dispositif de gestion d’un système d’exploitation d’un terminal connecté au réseau, d’au moins une information permettant d’accéder à au moins une entité du réseau sélectionnée par le contrôleur pour le dispositif de gestion pour héberger au moins une fonction dite fonction déportée du système d’exploitation ; et - un module d’activation de ladite fonction déportée sur ladite entité du réseau en utilisant des données reçues du dispositif de gestion permettant cette activation. Un tel contrôleur réseau permet la mise en œuvre d’un procédé de contrôle objet de l’invention. Un autre objet de l’invention concerne une entité réseau pour l’hébergement d’au moins une fonction dite fonction déportée d’un système d’exploitation d’un terminal connecté audit réseau, ladite entité étant sélectionnée par un contrôleur du réseau pour héberger ladite fonction déportée pour un dispositif de gestion du système d’exploitation, ladite entité de réseau comprenant : - un module d’établissement d’un canal de communication avec ledit système d’exploitation du terminal sur la base d’au moins une information reçue du terminal et fournie par le dispositif de gestion audit terminal pour lui permettre d’établir ledit canal de communication ; - un module de vérification que ledit terminal est autorisé à invoquer la fonction déportée hébergée par l’entité du réseau ; - suite à la réception via ledit canal de communication d'un message d’une application embarquée sur le terminal invoquant la fonction déportée, un module d’exécution de ladite fonction déportée si ladite fonction déportée est autorisée pour le terminal. Une telle entité réseau permet la mise en œuvre d’un procédé d’hébergement d’au moins une fonction déportée objet de l’invention. Un autre objet de l’invention concerne un programme d’ordinateur comportant des instructions de code de programme pour l’exécution des étapes d’un procédé de fourniture d’un accès à une fonction d’un système d’exploitation d’un terminal. Un autre objet de l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de fourniture d’un accès à une fonction d’un système d’exploitation d’un terminal, lorsque ledit programme est exécuté par un processeur. Description des figures D’autres caractéristiques et avantages de l’invention apparaîtront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés dans lesquels : La FIG. 1 illustre un exemple de structure interne simplifiée d’un terminal selon l’art antérieur ; La FIG. 2 illustre un système de communication pour la fourniture d’un accès à une fonction déportée d’un système d’exploitation ; La FIG. 3 illustre des étapes d’un procédé de fourniture d’un accès à la fonction déportée mis en œuvre par tout ou partie de l’architecture de communication de la FIG. 2 ainsi que des étapes d’un procédé d’hébergement de ladite fonction déportée ; La FIG. 4 illustre un terminal qui met en œuvre le procédé de fourniture illustré par FIG. 3 ; La FIG. 5 illustre une entité réseau utilisée pour la mise en œuvre du procédé d’hébergement illustré par la FIG. 3 ; La FIG. 6 illustre des étapes d’un procédé de communication mis en œuvre par tout ou partie de l’architecture de communication de la FIG. 2 ainsi que des étapes d’un procédé de contrôle ; La FIG. 7 illustre un dispositif de gestion pour la mise en œuvre du procédé de communication illustré par la FIG. 6 ; La FIG. 8 illustre un contrôleur réseau pour la mise en œuvre du procédé de contrôle illustré par la FIG. 6 . Description de modes de réalisation La FIG. 2 illustre un système de communication SYS permettant la mise en œuvre d’un procédé de fourniture à une application d’un accès à une fonction distante (« déportée ») d’un système d’exploitation (c’est-à-dire d’un OS) installé sur un terminal utilisateur. Ce procédé de fourniture est également appelé ici procédure NECTARINE (pour « NEtwork-Coordinated Terminal Access to Remote, INtelligent and Emulated OS APIs »). Le système de communication SYS illustré par la FIG. 2 comporte notamment les éléments suivants : - un terminal Terminal ; - une entité réseau NEAT et un contrôleur réseau Controller localisés dans un réseau Network ; et - un dispositif de gestion OVI (OS Vendor Infrastructure) de systèmes d’exploitation. Le terminal Terminal est adapté pour être contrôlé par un utilisateur qui souhaite accéder à des services. Comme il a déjà été exposé, ce terminal comprend un système d’exploitation OS, géré par le dispositif de gestion OVI, et une ou plusieurs applications APP dont une seule est ici représentée. Le terminal Terminal peut être un équipement d’utilisateur ou UE (pour « User Equipment » en anglais), une instance de service, un CPE (pour « Customer Premises Equipment »), etc. Ce terminal peut être mobile ou fixe. Un seul terminal est représenté sur la FIG. 2 . Cependant, le système de communication SYS est adapté pour gérer plusieurs terminaux. Le terminal Terminal est connecté à un unique réseau Network selon la FIG. 2 . Ce réseau est un réseau de communication. Il peut être, par exemple, un réseau mobile 5G, un réseau sans fil WLAN (pour « Wireless Local Area Network ») ou un réseau fixe. Dans un autre mode de réalisation, le terminal peut être connecté à plusieurs réseaux Network. Ces réseaux peuvent être de même nature ou de nature différente. En outre, le réseau Network peut supporter une pluralité de tranches réseau (« network slice » en anglais). Un réseau physique peut être organisé en plusieurs réseaux distincts qui peuvent être considérés comme autant de domaines d’exploitation (par exemple, un réseau de communication peut être décomposé en un réseau d’accès, un réseau de collecte, un réseau cœur et un réseau de transit). Chacun de ces domaines peut supporter des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine (par exemple, une tranche déployée sur un réseau cœur mobile 5G fera appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G). Ainsi, chaque domaine peut utiliser des technologies déployées dans ce domaine pour la réalisation des tranches réseau. Par exemple, des tranches dans un réseau mobile (5G) peuvent reposer sur la mise en place de tranches dans les différents domaines suivants : Radio Access Network (RAN), Core Network (CN) et Transport Network (TN). L’entité réseau NEAT (pour « NW_EMULATED_API_TERMINAL » en anglais) est adaptée, c’est-à-dire configurée, pour héberger une ou plusieurs fonctions du système d’exploitation OS du terminal mais qui ne sont pas présentes localement dans l’OS du terminal. De telles fonctions sont, par exemple, des fonctions de priorisation, d’accélération de trafic ou de chiffrement des données caractéristiques de l’usage de services. Ces fonctions sont dites alors fonctions déportées. Une seule entité réseau NEAT est ici représentée. En variante, le réseau Network peut intégrer plusieurs entités réseau NEAT. Chaque entité réseau NEAT est apte à héberger une ou plusieurs fonctions déportées. Des fonctions déportées peuvent être communes à plusieurs entités réseau NEAT. Aucune hypothèse n’est faite quant au réseau qui héberge une entité NEAT. Le contrôleur Controller du réseau Network a la capacité d’activer une ou plusieurs fonction(s) déportée(s) sur une entité réseau NEAT. Le dispositif de gestion OVI illustré par la FIG. 2 est responsable de la distribution des mises à jour logicielles des OS des terminaux, des correctifs de sécurité, etc. Ce dispositif OVI est associé à un fournisseur du terminal ou de l’OS de ce terminal (dit « OS Vendor » en anglais). Plusieurs modèles de terminaux peuvent être gérés par un même dispositif OVI. La structure organique et fonctionnelle d’un OVI est interne et caractéristique de l’organisation du fabricant du terminal utilisateur ou du fournisseur de l’OS. Le dispositif de gestion OVI peut être composé d’un ou plusieurs serveurs frontaux et d’un ou plusieurs serveurs « back-end ». Les serveurs frontaux sont adaptés pour gérer des canaux de communication établis avec les terminaux dont les OS sont gérés par le dispositif de gestion OVI. Par ailleurs, la gestion des connexions avec les terminaux peut être distribuée. Par exemple, la gestion de la fonction de terminaison des connexions TLS (pour « Transport Layer Security » en anglais) peut être distincte de la gestion de la fonction de terminaison applicative. Ces gestions peuvent faire appel à des ressources localisées dans des endroits différents. Cette répartition de fonctions n’est pas visible des terminaux. Dans le cas où la terminaison applicative n’est pas en frontal des terminaux, l’adresse IP et le numéro de port source d’un message reçu d’un terminal doivent être communiqués au point de terminaison applicative en utilisant des mécanismes tels que HOST_ID décrit dans le document IETF RFC 7974 édité par B. Williams et al. et intitulé « An Experimental TCP Option for Host Identification », octobre 2016. Le dispositif de gestion OVI est externe à un terminal. Il est cependant joignable par ce terminal en utilisant un nom de domaine, une adresse IP, etc. D’autres informations (par exemple, un certificat de sécurité) comme celles nécessaires pour établir des associations de sécurité (« Secure Association » en anglais) entre un terminal et un serveur frontal du dispositif de gestion OVI peuvent être configurées dans le terminal utilisateur. Les informations de joignabilité d’un OVI sont appelées ici OVI_FRONTAL_CONTACT_TERMINAL (OFCT). Ces informations sont typiquement configurées dans le terminal avant sa commercialisation. Cependant, d’autres modes de configuration dynamique peuvent être considérés (par ex. « OMA Device Management »). Dans l’exemple de la FIG. 2 , le système de communication SYS ne comporte qu’un seul dispositif de gestion OVI. En variante, le système de communication SYS comporte plusieurs dispositifs de gestion OVI. Différents terminaux peuvent alors être gérés par différents dispositifs de gestion OVI. Le dispositif de gestion OVI est directement connecté au réseau Network. En variante, le dispositif de gestion OVI est connecté au réseau Network via un ou plusieurs réseau(x) intermédiaire(s) (par ex. réseau de transit). La FIG. 6 illustre les étapes d’un procédé de communication mis en œuvre par le dispositif de gestion OVI illustré à la FIG. 2 . Ce procédé de communication permet l’activation de la procédure NECTARINE. Dans un premier temps, le dispositif de gestion OVI négocie dynamiquement avec le réseau Network, par exemple selon le protocole CPNP (pour « Connectivity Provisioning Negotiation Protocol » en anglais), tel que décrit dans le document IETF RFC 8921, édité par M. Boucadair et al. intitulé « Dynamic Service Negotiation : The Connectivity Provisioning Negotiation Protocol (CPNP) », octobre 2020. Cette négociation comprend la transmission par le dispositif de gestion OVI d’un message « Subscribe() » à destination du contrôleur réseau Controller. Ce message « Subscribe() » comporte une information d’identification de l’OVI, appelée OVI_ID. Cet identifiant est unique. Le message de souscription peut également inclure des instructions de placement des entités réseau pour exposer les fonctions déportées (par exemple afin d’optimiser un temps d’invocation ou un délai de transit IP). En réponse à ce message « Subscribe() », le contrôleur réseau retourne à l’OVI au moins une adresse IP (et éventuellement un numéro de port) pour invoquer la fonction déportée. Cette adresse IP est codée dans un champ « NTW_API_Locator (NAL) ». Le message contient également un identifiant d’authentification (ADN pour « Authentification Domain Name » en anglais) appelé « NTW_API_ADN (NAA) ». Les informations échangées lors de la procédure de négociation/souscription sont enregistrées par le contrôleur réseau et l’OVI. Le contrôleur réseau utilise une table « OVI_NECTARINE_SUBSCRIBERS » à cet effet (et qui consigne notamment l’identifiant de chacune des OVI ayant souscrit au service), alors que l’OVI consigne les informations NAL, NAA, ainsi que l’identifiant du réseau (noté NWID) dans une table appelée : « ACTIVE_NW_NECTARINE ». Des modules logiciels API_PACKAGES (notés ici « S/W Package Locator (SPL) et « S/W Package ADN (SPA) ») sont ensuite communiqués au contrôleur réseau Controller pour être installés dans tout ou partie des entités réseau NEAT sélectionnées pour exposer les fonctions déportées. Le réseau peut décider d’installer ces modules dans certaines régions, par exemple en fonction de la couverture de l’opérateur. Ces modules logiciels peuvent être mis à jour par l’OVI pendant la durée de vie du service NECTARINE tel que souscrit par l’OVI. Il est à noter qu’une procédure de sécurité peut être nécessaire car les mises à jour logicielles sont susceptibles de générer un trafic qui peut constituer un vecteur d’attaques potentiel. Le contrôleur réseau sélectionne les entités réseaux NEAT qui exposeront les fonctions déportées pour cette OVI selon par exemple des contraintes indiquées par l’OVI (tels qu’un délai de transit IP, un temps d’invocation, une contrainte de localisation, etc.). Une ou plusieurs entités NEAT peuvent être activées pour une même OVI. Par exemple, l’activation peut dépendre de la distribution géographique des terminaux associés à cette OVI. Une même entité NEAT peut exposer des fonctions déportées qui correspondent à des OVI distinctes. Les informations utilisées pour installer les modules API_PACKAGES (« S/W Package Locator (SPL) et « S/W Package ADN (SPA) ») sont typiquement différentes des informations NAL/NAA destinées à être présentées aux terminaux, puisqu’elles correspondent à deux usages distincts (accès à des fonctions déportées par les terminaux et installation de modules logiciels). Nous supposons maintenant que le terminal indique au contrôleur réseau Controller sa capacité à mettre en œuvre la procédure NECTARINE. Pour ce faire, un élément d’information, appelé NECTARINE_CAPABLE, est inséré dans un message d’établissement d’une connexion avec le contrôleur réseau envoyé par le terminal. Une telle étape a pour avantage de permettre la configuration de filtres réseau pour préparer l’établissement de canaux sécurisés avec une entité NEAT, l’activation à la demande de nouvelles entités NEAT pour des besoins de dimensionnement, etc. Quand le terminal utilisateur est connecté au réseau, il envoie ainsi un message à l’OVI en utilisant les informations OFCT préconfigurées. Ce message peut être formé en utilisant une primitive HTTP PUT, POST ou GET. Le message indique l’identité du réseau de communication auquel il est connecté (NWID). Cet identifiant est par exemple un identifiant « Network Access Identifier » tel que décrit dans le document IETF RFC 7542 édité par A. DeKok intitulé « The Network Access Identifier », mai 2015, ou un identifiant « Access Network Domain Name » tel que décrit dans le document IETF RFC 5986, édité par M. Thomson et al. et intitulé « Discovering the Local Location Information Server (LIS) », septembre 2010. Si le terminal est éligible au service NECTARINE, alors l’OVI retourne au système d’exploitation des informations appelées OVI_SUPPLIED_NECTARINE_INFO (OSNI). Ces informations comprennent notamment ici une adresse IP de l’entité réseau NEAT, un identifiant OVI_ID du dispositif de gestion OVI, des informations d’authentification telles que les informations NAA, les informations NAL (pour « NTW_API_Locator » en anglais), ainsi qu’un jeton d’authentification (ou « token » en anglais) appelé ici Token. L’OVI détermine si un terminal est éligible au service NECTARINE en prenant en compte par exemple le modèle du terminal, les services à valeur ajoutée fournis par le réseau auquel ledit terminal est connecté, les limitations logicielles ou matérielles du terminal, etc. D’autres paramètres peuvent être communiqués tels qu’un filtre sur les fonctions déportées, au moins un identifiant de service particulier, un ou plusieurs noms de réseau de données ou « Data Network Names » en anglais (DNN), etc. L’invocation par le terminal des fonctions déportées est alors conditionnée par ces filtres. Par exemple, si un DNN a été retourné, alors seules les connexions impliquant ce DNN sont éligibles au service NECTARINE. Dans une variante, le paramètre NECTARINE_ENABLE peut être omis. La présence des informations NAL et NAA est alors une indication implicite de la mise en place du service NECTARINE pour ce réseau de communication. Une fois récupérées les informations OSNI par le terminal, ce dernier peut établir au moins un canal sécurisé (message Req Canal et message Rep Canal ) avec l’entité réseau NEAT qui héberge la ou les fonctions déportées, comme décrit ultérieurement en référence à la FIG. 3 . Les informations OSNI sont utilisées pour établir ce canal sécurisé. Dans une variante, les fonctions déportées peuvent être supportées par plusieurs entités NEAT du réseau. Un canal sécurisé est établi avec chacune de ces entités NEAT. L’entité réseau NEAT procède à l’authentification du terminal utilisateur et à la validation des informations OVI_ID et Token. Si le terminal est autorisé à utiliser le service NECTARINE, alors ladite entité NEAT renvoie une liste des fonctions déportées (API, typiquement) qui peuvent être exposées par l’OS du terminal aux applications comme étant des fonctions locales. Un argument « Type=Local/Remote » peut être utilisé par le terminal (l’OS plus précisément) pour distinguer les fonctions locales (Type=Local) de celles émulées (c.-à-d. accessibles via le réseau) (Type=Remote). Les fonctions d’une telle liste correspondent à l’habilitation du terminal et de ses applications à les invoquer. Par ailleurs, le nombre de fonctions hébergées par une entité NEAT peut évoluer au cours du temps : ainsi, l’ajout d’une nouvelle fonction qu’un terminal authentifié par l’entité NEAT est habilité à invoquer pourrait susciter une nouvelle procédure de vérification. De même, en cas de retrait d’une fonction déportée, ce retrait pourrait faire l’objet d’une notification envoyée par l’entité NEAT à l’ensemble des terminaux qu’elle sert et qui sont habilités à invoquer ladite fonction. Cette notification pourrait comprendre également une indication pour joindre une autre entité NEAT qui continue d’héberger ladite fonction déportée. Si l’autorisation à utiliser le service NECTARINE ou l’authentification du terminal échouent, alors l’entité NEAT rejette la demande d’accès au service NECTARINE pour ce terminal. Sinon, si l’autorisation est validée, le terminal (son OS plus spécifiquement) expose aux applications les fonctions déportées reçues d’une entité NEAT de la même façon qu’il expose des fonctions qu’il met en œuvre localement. Le cas échéant, le terminal utilisateur applique les filtres mentionnés précédemment pour contrôler l’exposition de ces primitives aux applications. La FIG. 3 illustre des étapes d’un procédé de fourniture d’un accès à une fonction déportée F’ j mis en œuvre par tout ou partie des éléments du système de communication SYS illustré à la FIG. 2 , suite à l’activation de la procédure NECTARINE par le procédé de la FIG. 6 . Comme évoqué précédemment, dans une étape d’authentification, l’OS du terminal envoie une requête Req Auth pour une authentification auprès de l’entité réseau NEAT. En retour, l’entité réseau NEAT transmet une réponse Rep Auth validant ou non cette authentification. Dans une étape d’établissement d’un canal de communication, l’OS du terminal envoie une requête Req canal auprès de l’entité réseau NEAT. Cette requête Req Canal comprend au moins les informations OSNI. En réponse à la requête Req Canal , l’entité réseau NEAT envoie une réponse Rep Canal au terminal comprenant les données d’identification du canal de communication. Dans un mode de réalisation préférentiel, la réponse Rep Canal comprend en outre des éléments pour la sécurisation dudit canal et l’établissement de ce canal. L’OS du terminal peut exposer, ici, des fonctions locales F i , avec i allant de 1 à n, n étant un entier naturel non nul. Ces fonctions locales F i sont directement hébergées par l’OS. L’OS du terminal peut également exposer des fonctions déportées F’ j , avec j allant de 1 à m, m étant un entier naturel non nul. Ces fonctions déportées F’ j sont hébergées par l’entité NEAT (ou par plusieurs entités NEAT). Pour découvrir les fonctions déportées F’ j hébergées par l’entité NEAT, l’OS transmet, dans le mode de réalisation décrit ici, une requête Req List à ladite entité NEAT en vue d’acquérir une liste des fonctions déportées F’ j hébergées par ladite entité. Dans une réponse Rep List , l’entité réseau NEAT fournit au terminal cette liste List. En variante, l’entité NEAT peut envoyer de façon spontanée la liste List à l’OS, sans sollicitation explicite de ce dernier. Dans un mode de réalisation particulier, à chaque fonction déportée F’ j présente dans la liste List correspond une indication de marquage IM j associée. Une telle indication de marquage IM j est utilisée par l’OS pour marquer des paquets de données destinés à être traités par ladite fonction déportée F j hébergée par l’entité NEAT. Cette indication de marquage IM j est, dans un mode de réalisation particulier, fournie par l’entité réseau NEAT avec la liste List. Suite à l’obtention de la liste des fonctions déportées, dans une étape d’exposition de fonction, l’OS expose à l’application APP l’ensemble des fonctions F i , avec i allant de 1 à n hébergées localement par l’OS et l’ensemble des fonctions F ’j , avec j allant de 1 à m hébergées par l’entité NEAT. Conformément à l’invention, les fonctions Fi et F’j locales et déportées de l’OS sont exposées à l’application APP par l’OS de façon identique ou similaire de sorte que l’application APP n’est pas en mesure de distinguer les fonctions qui sont hébergées localement par l’OS des fonctions hébergées par l’entité NEAT. On suppose maintenant que l’OS reçoit un message « Call_F i » provenant de l’application APP invoquant la fonction F i . A la réception de ce message « Call_F i », l’OS détermine que la fonction F i invoquée est hébergée localement. Il exécute alors la fonction F i sur le message « Call_F i » de façon connue en soi. Si une réponse est requise pour ce message « Call_F i », l’OS transmet à l’application APP une réponse Rep_Call_F i associée. On suppose maintenant que l’OS reçoit un message « Call_F’ j » provenant de l’application APP invoquant la fonction F’ j . A la réception de ce message « Call_F’ j », l’OS détermine que la fonction F’ j invoquée est déportée. L’OS relaye le message reçu à l’entité réseau NEAT via le canal de communication préétabli tel que décrit ci-dessus. L’entité réseau NEAT exécute alors la fonction F’ j invoquée sur le message reçu. Si une réponse est requise pour le message « Call_F’ j », après exécution de la fonction F’ j par l’entité NEAT, cette dernière envoie une Rep_Call_F’ j à l’OS du terminal via le canal de communication. La réponse Rep_Call_F’ j est communiquée par l’OS à l’application APP. L’entité NEAT enregistre localement, par exemple dans une table, les informations récupérées dans l’appel de la fonction « Call_F’ j », le canal de communication et le cas échéant, les informations retournées au terminal en réponse à l’appel de la fonction « Call_F’j ». Les informations ainsi enregistrées dans la table peuvent être utilisées ultérieurement par l’entité NEAT lorsqu’un traitement de paquets de données est nécessaire suite à l’appel de la fonction F’j. Le terminal peut par ailleurs utiliser l’information de marquage IMj pour marquer les paquets de données envoyés pour traitement par la fonction F’j afin de faciliter l’identification d’une entrée de la table à utiliser pour ce traitement. Il convient de noter que l’appel d’une fonction par la transmission du message « Call_Fi » ou « Call_F’ j » n’est pas nécessairement associé à l’échange de données. Par exemple, une fonction peut être une fonction de découverte des adresses externes, de configuration de règles de classification, etc. Dans une variante de réalisation, il existe plusieurs entités NEAT avec lesquelles le terminal est susceptible de communiquer pour activer et exploiter des fonctions déportées. Dès lors, l’étape de découverte via la requête Req List consiste à découvrir ces entités NEAT et les fonctions qu’elles hébergent. La liste List ainsi constituée comporte un ensemble de fonctions déportées F’ k j où k représente la k ième entité NEAT hébergeant la j ième fonction déportée F’ j . On notera également que l’étape d’exposition de la ou des fonctions déportées F’ j et le cas échéant, des fonctions locales F i , peut se faire avant ou après l’étape d’établissement du canal de communication entre le terminal Terminal et l’entité réseau NEAT. La FIG. 4 illustre le terminal Terminal pour la mise en œuvre du procédé de fourniture de la FIG. 3 . Ce terminal comprend : – au moins une interface entrée/sortie E/S Term ; - une mémoire de stockage Mem Term ; – un processeur Proc Term . La au moins une interface entrée/sortie E/S Term est adaptée pour permettre au terminal de recevoir et de transmettre des messages, par exemple avec le réseau Network. La mémoire de stockage Mem Term est adaptée pour stocker des données telles que des données associées à l’application APP. Le processeur Proc Term est adapté pour mettre en œuvre les étapes du procédé de fourniture comme il est décrit ci-dessus. La FIG. 3 illustre également des étapes d’un procédé d’hébergement d’une fonction déportée mis en œuvre par l’entité réseau NEAT. Cette entité réseau NEAT est sélectionnée par un contrôleur réseau pour héberger la fonction déportée pour le dispositif de gestion OVI. Ce procédé d’hébergement comprend l’étape d’établissement du canal de communication (message Req canal et message Rep canal ) avec le système d’exploitation OS du terminal. Cette étape d’établissement est réalisée sur la base d’au moins une information reçue du terminal et fournie par le dispositif de gestion OVI audit terminal pour lui permettre d’établir le canal de communication. Le procédé d’hébergement comprend également une étape de vérification selon laquelle le terminal est autorisé à invoquer la fonction déportée hébergée par l’entité réseau NEAT. Suite à cette étape de vérification, le procédé d’hébergement comprend une étape d’envoi au système d’exploitation de la liste de fonctions déportées hébergées par l’entité du réseau et que le terminal est autorisé à invoquer (message Req List et message Rep List ). S’il y a au moins une fonction déportée hébergée par l’entité réseau NEAT et que le terminal est autorisé à invoquer, le procédé d’hébergement comprend une étape de mémorisation d’au moins un élément parmi : - au moins un paramètre d'invocation de la fonction déportée compris dans un message invoquant cette fonction déportée ; - au moins une information descriptive du canal de communication ; et/ou - au moins une information envoyée au terminal suite à l’étape de vérification. Suite à la réception via le canal de communication du message « Call_F’ j » invoquant la fonction déportée, le procédé d’hébergement comprend une étape d’exécution de ladite fonction déportée. Suite à la réception d’un paquet de données en provenance de l’application APP embarquée dans le terminal via ledit canal de communication ou d’un paquet de données destiné à ladite application APP, le procédé d’hébergement comprend une étape d’exécution de la fonction déportée sur ledit paquet de données en utilisant au moins un élément mémorisé lors de l’étape de mémorisation. La FIG. 5 illustre l’entité réseau NEAT pour procéder à l’hébergement et à l’exécution de fonctions déportées. Cette entité réseau NEAT comprend : - une interface entrée/sortie E/S N EAT ; - une mémoire de stockage Mem N EAT ; - un processeur Proc N EAT . L’interface entrée/sortie E/S N EAT est adaptée pour permettre à l’entité Neat de communiquer avec le système d’exploitation du terminal. La mémoire de stockage Mem N EAT est adaptée pour stocker des données telles que celles caractéristiques d’une ou plusieurs fonctions déportées. Le processeur Proc N EAT est adapté pour mettre en œuvre les étapes du procédé d’hébergement comme il est décrit ci-dessus. La FIG. 7 illustre le dispositif de gestion OVI pour la mise en œuvre du procédé de communication illustré par la FIG. 6 . Ce dispositif de gestion OVI comprend : - une interface entrée/sortie E/S OVI ; - une mémoire de stockage Mem OVI ; - un processeur Proc OVI . L’interface entrée/sortie E/S OVI est adaptée pour permettre au dispositif de gestion OVI de recevoir et de transmettre des messages, par exemple avec le système d’exploitation OS et le contrôleur Controller. La mémoire de stockage Mem Term est adaptée pour stocker des données telles que les données OSNI c’est-à-dire les informations OVI_ID, NAL, NAA, et le Token. Le processeur Proc Term est adapté pour mettre en œuvre les étapes du procédé de communication comme il est décrit ci-dessus. La FIG. 6 illustre également des étapes d’un procédé de contrôle par le contrôleur réseau Controller. Ce procédé comprend une étape d’envoi au dispositif de gestion OVI de l’information NAL/NAA permettant d’accéder à l’entité réseau NEAT pour héberger la fonction déportée F’ j du système d’exploitation OS. Le procédé comprend également une étape d’activation de la fonction déportée F’ j sur l’entité réseau NEAT en utilisant les données SPA/SPL reçues du dispositif de gestion OVI permettant cette activation. La FIG. 8 illustre le contrôleur réseau Controller pour la mise en œuvre du procédé de contrôle de la FIG. 6 . Ce contrôleur réseau Controller comprend : - une interface entrée/sortie E/S Cont ; - une mémoire de stockage Mem Cont ; - un processeur Proc Cont . L’interface entrée/sortie E/S Cont est adaptée pour permettre au contrôleur Controller de recevoir et de transmettre des messages, par exemple avec le dispositif de gestion OVI et l’entité réseau NEAT. La mémoire de stockage Mem Cont est adaptée pour stocker des données telles que les données SPA et SPL. Le processeur Proc Cont est adapté pour mettre en œuvre les étapes du procédé de contrôle comme il est décrit ci-dessus. L’invention permet ainsi un traitement particulier d’un appel pour l’accès à une fonction déportée par un OS d’un terminal : - l’application utilise les informations relayées par le terminal. Cette utilisation est identique à celle d’un appel d’une fonction locale. L’application génère un paquet de données qui utilise un marquage relayé par l’OS ; - l’OS intercepte les données de l’application et les associe à un canal puis envoie si besoin dans un canal de communication sécurisé (par exemple un tunnel IPsec) établi avec l’entité NEAT concernée. L’OS les marque éventuellement avant de les envoyer vers le canal de communication sécurisé adéquat ; - l’entité réseau NEAT exécute la fonction correspondante puis envoie le paquet, notamment lorsque ce paquet est un paquet de données. On notera que l’appel d’une fonction n’est pas nécessairement associé à l’échange de données. Par exemple, une fonction de découverte des adresses externes, configuration de règles de classification, etc. Dans un autre exemple, l’entité réseau NEAT peut mettre en place une table URSP (pour « UE Route Selection Policy ») déportée dans le réseau pour associer un flux application à une tranche réseau, lorsque ce réseau comporte plusieurs tranches. Les paquets envoyés vers le terminal qui transitent par l’entité réseau NEAT sont acheminés après traitement associé en utilisant la tranche réseau ad hoc. Procédé de fourniture à une application (APP) installée sur un terminal (Terminal), par un système d’exploitation (OS) dudit terminal (Terminal), d’un accès à une fonction du système d’exploitation, ledit procédé comprenant : - une étape d’établissement d'au moins un canal de communication avec au moins une entité (NEAT) d'un réseau (Network) hébergeant pour un dispositif de gestion du système d’exploitation (OVI) au moins une fonction dite fonction déportée (F’ j ) du système d’exploitation (OS), ladite étape d’établissement utilisant au moins une information (OSNI) fournie par le dispositif de gestion du système d’exploitation (OVI) ; - une étape d’exposition (Expo_F’ j ) à l'application (APP) de ladite fonction déportée (F’ j ) comme une fonction mise en œuvre localement par le système d’exploitation (OS) ; et - sur réception d'un message (Call_F’ j ) de l'application invoquant ladite fonction déportée (F’ j ), une étape de transfert du message (Call_F’ j ) vers l’entité (NEAT) du réseau hébergeant ladite fonction déportée (F’ j ), via le canal de communication établi avec cette entité (NEAT) du réseau. Procédé de fourniture selon la revendication 1 comprenant en outre, avant l’établissement d’un dit canal de communication avec ladite entité (NEAT) du réseau, une étape d’authentification du terminal (Terminal) auprès de cette entité (NEAT). Procédé de fourniture selon la revendication 1 ou 2 comprenant en outre une étape de réception, en provenance de ladite entité (NEAT) du réseau, d’une liste (List) de fonctions déportées hébergées par cette entité (NEAT) du réseau, pour exposition à ladite application (APP). Procédé de fourniture selon l’une quelconque des revendications 1 à 3 comprenant une étape de réception en provenance de ladite entité (NEAT) du réseau d’au moins une indication de marquage (IM j ) destinée à être appliquée à au moins un paquet de données (Pack) émis par l’application (APP) avant d’être transféré par le système d’exploitation (OS) vers cette entité (NEAT) du réseau. Procédé de fourniture selon l’une quelconque des revendications 1 à 4 comprenant : - une étape d’identification d’au moins un paquet de données (Pack) émis par l'application (APP) destiné à être transmis via ledit canal de communication établi vers ladite entité (NEAT) du réseau; et - une étape de transfert dudit au moins un paquet identifié (Pack _IM j ) vers ladite entité (NEAT) du réseau via ledit canal de communication. Procédé de fourniture selon l’une quelconque des revendications 1 à 5 comprenant une étape de transfert à l’application (APP) d’un message reçu (Rep_Call_F’ j ) en provenance de l’entité (NEAT) du réseau hébergeant la fonction déportée (F’ j ) invoquée par l’application (APP). Procédé de fourniture selon l’une quelconque des revendications 1 à 6 comprenant, sur réception du message (Call_F i ; Call_F’ j ) provenant de l’application (APP) invoquant une fonction requise (F i ; F’ j ), une étape préalable de vérification si cette fonction est hébergée localement (F i ) par le système d’exploitation (OS) ou déportée (F’ j ) sur l’entité (NEAT) du réseau. Procédé de communication mis en œuvre par un dispositif de gestion (OVI) d’un système d’exploitation (OS) d’un terminal (Terminal) connecté à un réseau (Network), ledit procédé comprenant : - une étape d’obtention, d’un contrôleur du réseau, d’au moins une information (NAL/NAA) permettant d’accéder à au moins une entité (NEAT) du réseau, sélectionnée par ledit contrôleur du réseau pour le dispositif de gestion (OVI) pour héberger au moins une fonction dite fonction déportée (F’ j ) dudit système d’exploitation ; - une étape d’envoi au contrôleur du réseau de données (SPA, SPL) permettant d’activer ladite fonction déportée dudit système d’exploitation (OS) sur l’entité (NEAT) du réseau sélectionnée ; et - suite à une réception d’un message en provenance du système d’exploitation (OS) du terminal (Terminal), une étape d’envoi audit système d’exploitation (OS) de l’information (OSNI) pour permettre au terminal (Terminal) d’établir un canal de communication avec l’entité (NEAT) du réseau hébergeant ladite fonction déportée (F’ j ). Procédé de communication selon la revendication 8 dans lequel l’étape d’obtention fait suite à une étape d’envoi d’un message au contrôleur indiquant au moins une contrainte à satisfaire par l’entité (NEAT) du réseau. Procédé de contrôle par un contrôleur (Controller) d’un réseau, comprenant : - une étape d’envoi à un dispositif de gestion (OVI) d’un système d’exploitation (OS) d’un terminal (Terminal) connecté au réseau, d’au moins une information (NAL/NAA) permettant d’accéder à au moins une entité (NEAT) du réseau sélectionnée par le contrôleur pour le dispositif de gestion (OVI) pour héberger au moins une fonction dite fonction déportée (F’ j ) du système d’exploitation (OS) ; et - une étape d’activation de ladite fonction déportée (F’ j ) sur ladite entité (NEAT) du réseau en utilisant des données (SPA, SPL) reçues du dispositif de gestion (OVI) permettant cette activation. Procédé de contrôle selon la revendication 10 dans lequel ladite entité (NEAT) du réseau sélectionnée vérifie au moins une contrainte indiquée par le dispositif de gestion (OVI). Procédé d’hébergement d’au moins une fonction dite fonction déportée (F’ j ) d’un système d’exploitation (OS) d’un terminal (Terminal) connecté à un réseau (Network), ledit procédé étant mis en œuvre par une entité (NEAT) du réseau, sélectionnée par un contrôleur (Controller) du réseau pour héberger ladite fonction déportée (F’ j ) pour un dispositif de gestion (OVI) du système d’exploitation (OS), ledit procédé comprenant : - une étape d’établissement d’un canal de communication avec ledit système d’exploitation (OS) du terminal (Terminal) sur la base d’au moins une information reçue du terminal (Terminal) et fournie par le dispositif de gestion (OVI) audit terminal (Terminal) pour lui permettre d’établir ledit canal de communication ; - une étape de vérification que ledit terminal (Terminal) est autorisé à invoquer la fonction déportée (F’ j ) hébergée par l’entité (NEAT) du réseau ; - suite à la réception via ledit canal de communication d'un message (Call_F’ j ) d’une application (APP) embarquée sur le terminal (Terminal) invoquant la fonction déportée (F’ j ), une étape d’exécution de ladite fonction déportée (F’ j ) si ladite fonction déportée (F’ j ) est autorisée pour le terminal (Terminal). Procédé d’hébergement selon la revendication 12 comprenant, suite à l’étape de vérification, une étape d’envoi au système d’exploitation (OS) du terminal (Terminal) d’une liste (List) de fonctions déportées hébergées par l’entité (NEAT) du réseau et autorisées pour le terminal (Terminal). Procédé d’hébergement selon la revendication 12 ou 13 comprenant si au moins une fonction déportée (F’ j ) hébergée par l’entité (NEAT) du réseau est autorisée pour le terminal (Terminal), une étape de mémorisation d’au moins un élément parmi : - au moins un paramètre d'invocation de la fonction déportée (F’ j ) compris dans un message invoquant cette fonction déportée, - au moins une information descriptive du canal de communication ; et/ou - au moins une information envoyée au terminal (Terminal) suite à l’étape de vérification. Procédé d’hébergement selon la revendication 14 comprenant, suite à la réception d’un paquet de données (Packet) en provenance de l’application (APP) embarquée sur le terminal (Terminal) via ledit canal de communication ou d’un paquet de données (Data) destiné à ladite application (APP), une étape d’exécution de la fonction déportée (F’ j ) sur ledit paquet de données (Packet) en utilisant au moins un élément mémorisé lors de l’étape de mémorisation. Terminal pour la fourniture à une application (APP) installée sur ledit terminal (Terminal) d’un accès à une fonction d’un système d’exploitation appartenant audit terminal, ledit terminal comprenant : - un module pour établir au moins un canal de communication avec au moins une entité (NEAT) d'un réseau (Network) hébergeant pour un dispositif de gestion du système d’exploitation (OVI) au moins une fonction dite fonction déportée (F’ j ) du système d’exploitation (OS), ladite étape d’établissement utilisant au moins une information (OSNI) fournie par le dispositif de gestion du système d’exploitation (OVI) ; - un module pour exposer (Expo_F’ j ) à l'application (APP) de ladite fonction déportée (F’ j ) comme une fonction mise en œuvre localement par le système d’exploitation (OS) ; et - sur réception d'un message (Call_F’ j ) de l'application invoquant ladite fonction déportée (F’ j ), un module pour transférer le message (Call_F’ j ) vers l’entité (NEAT) du réseau hébergeant ladite fonction déportée (F’ j ), via le canal de communication établi avec cette entité (NEAT) du réseau. Dispositif de gestion d’un système d’exploitation (OS) d’un terminal (Terminal) connecté à un réseau (Network), ledit dispositif de gestion (OVI) comprenant : - un module d’obtention, d’un contrôleur du réseau, d’au moins une information (NAL/NAA) permettant d’accéder à au moins une entité (NEAT) du réseau, sélectionnée par ledit contrôleur du réseau pour le dispositif de gestion (OVI) pour héberger au moins une fonction dite fonction déportée (F’ j ) dudit système d’exploitation ; - un module d’envoi au contrôleur du réseau de données (SPA, SPL) permettant d’activer ladite fonction déportée (F’ j ) dudit système d’exploitation (OS) sur l’entité (NEAT) du réseau sélectionnée ; et - suite à une réception d’un message en provenance du système d’exploitation (OS) du terminal (Terminal), un module d’envoi audit système d’exploitation (OS) de l’information (OSNI) pour permettre au terminal (Terminal) d’établir un canal de communication avec l’entité (NEAT) du réseau hébergeant ladite fonction déportée (F’ j ). Contrôleur d’un réseau, ledit contrôleur (Controller) comprenant : - un module d’envoi à un dispositif de gestion (OVI) d’un système d’exploitation (OS) d’un terminal (Terminal) connecté au réseau, d’au moins une information (NAL/NAA) permettant d’accéder à au moins une entité (NEAT) du réseau sélectionnée par le contrôleur pour le dispositif de gestion (OVI) pour héberger au moins une fonction dite fonction déportée (F’ j ) du système d’exploitation (OS) ; et - un module d’activation de ladite fonction déportée (F’ j ) sur ladite entité (NEAT) du réseau en utilisant des données (SPA/SPL) reçues du dispositif de gestion (OVI) permettant cette activation. Entité d’un réseau (Network) pour l’hébergement d’au moins une fonction dite fonction déportée (F’ j ) d’un système d’exploitation (OS) d’un terminal (Terminal) connecté audit réseau (Network), ladite entité (NEAT) étant sélectionnée par un contrôleur (Controller) du réseau pour héberger ladite fonction déportée (F’ j ) pour un dispositif de gestion (OVI) du système d’exploitation (OS), ladite entité (NEAT) de réseau comprenant : - un module d’établissement d’un canal de communication avec ledit système d’exploitation (OS) du terminal (Terminal) sur la base d’au moins une information reçue du terminal (Terminal) et fournie par le dispositif de gestion (OVI) audit terminal (Terminal) pour lui permettre d’établir ledit canal de communication ; - un module de vérification que ledit terminal (Terminal) est autorisé à invoquer la fonction déportée (F’ j ) hébergée par l’entité (NEAT) du réseau ; - suite à la réception via ledit canal de communication d'un message (Call_F’ j ) d’une application (APP) embarquée sur le terminal (Terminal) invoquant la fonction déportée (F’ j ), un module d’exécution de ladite fonction déportée (F’ j ) si ladite fonction déportée (F’ j ) est autorisée pour le terminal (Terminal).