Brevet FR3121813A1 — publié le 20221014

Procédé mis en œuvre par un serveur de gestion (VNF-le) d’un fournisseur d’une pluralité de services (MNO), de gestion de profils de service, les profils étant attribuables à des terminaux de communication accédant à un réseau de communication supportant ledit service, le procédé comprenant: a) une réception d’un premier message de mise à jour du serveur de gestion (VNF-le) en provenance d’un gestionnaire d’accès (SM) comprenant au moins une mise à jour d’un premier nombre total (N_SM) de profils de service actifs sur le réseau de communication, b) une réception d’un second message de mise à jour du serveur de gestion (VNF-le) en provenance d’un serveur d’authentification (HSS) et comprenant au moins une mise à jour d’un second nombre total (N_HSS) de profils de service actifs sur le réseau de communication, c) une gestion d’accès au service par au moins une comparaison entre le premier nombre total (N_SM) de profils de service actifs sur le réseau de communication et le second nombre total (N_HSS) de profils de service actifs sur le réseau de communication. Figure de l’abrégé : Figure 1 Gestion de profils de terminaux de communication La présente divulgation relève du domaine de la gestion d’opérations de réseaux de télécommunications et plus particulièrement de gestion d’opérations de réseaux utilisant des fonctions logicielles régies par des licences d’exploitation associées. La sécurité des réseaux de communications d’entreprises industrielles clientes requiert souvent le déploiement de réseaux non publics (dits NPN) par des fournisseurs de services. Afin d’offrir au client une panoplie complète et modulable de services au sein du réseau déployé, les fournisseurs de services intègrent des fonctions logicielles virtuelles à l’architecture du réseau, de telles fonctions ayant des conditions d’exploitation des services déployés spécifiées par des licences de droit d’usage associées à ces fonctions logicielles. Ces conditions d’exploitation des services peuvent par exemple concerner le nombre maximal de connexions simultanées à un service tel que supporté par le réseau déployé. L’exploitation du réseau déployé passe notamment par le rattachement au réseau des différents terminaux constituant la flotte d’équipements du client. Ce rattachement peut notamment être souscrit par le client via une offre permettant au client de bénéficier d’un contrat unique tout en autorisant les différents terminaux de la flotte d’équipements du client à être associés à ce contrat. Une telle d’offre implique alors au fournisseur de services de fournir plusieurs profils de service pour un même contrat, chaque profil pouvant être téléchargé sur un processeur de sécurité électronique (dit Embedded Subscriber Identity Module , embedded SIM ou eSIM) le plus souvent solidaire d’un terminal. Ainsi, plusieurs terminaux du client peuvent être actifs et connectés simultanément au réseau déployé. Cependant, lorsque le client gère les associations entre les profils de service souscrits et les terminaux accédant au réseau (notamment lors d’un ajout ou d’une suppression d’association entre un profil et un terminal donnés), ce même client manque de visibilité sur la bonne correspondance entre profils et terminaux actifs associés au sein du système d’information du réseau déployé. Par conséquent, la gestion d’opérations au sein du réseau déployé comporte des potentiels problèmes de correspondance passés inaperçus pour le client (comme par exemple la présence de profils dits « fantômes » qui sont connectés au réseau sans autorisation du client). De plus, le client manque également de visibilité sur l’exploitation du réseau déployé au regard des conditions d’usage des fonctions logicielles utilisées pour la construction du réseau déployé telles que spécifiées par les licences d’exploitation, ce qui conduit potentiellement à une surexploitation ou au contraire à une sous-exploitation des capacités réelles du réseau déployé. Résumé La présente divulgation vient améliorer la situation. Il est proposé un procédé mis en œuvre par un serveur de gestion d’un fournisseur d’une pluralité de services, de gestion de profils de service relatifs à un service de la pluralité, les profils étant attribuables à des terminaux de communication accédant à un réseau de communication supportant ledit service, le procédé comprenant: a) une réception d’un premier message de mise à jour du serveur de gestion en provenance d’un gestionnaire d’accès, ledit premier message comprenant au moins une mise à jour d’un premier nombre total de profils de service actifs sur le réseau de communication, b) une réception d’un second message de mise à jour du serveur de gestion en provenance d’un serveur d’authentification, ledit second message comprenant au moins une mise à jour d’un second nombre total de profils de service actifs sur le réseau de communication, c) une gestion d’accès au service par au moins une comparaison entre le premier nombre total de profils de service actifs sur le réseau de communication et le second nombre total de profils de service actifs sur le réseau de communication. Par conséquent, le procédé permet à la fois à un client exploitant les services d’un réseau de communication et au fournisseur des services du réseau de gérer l’accès et l’utilisation des services du réseau. En effet, une telle gestion d’accès et d’utilisation consiste notamment à régulièrement s’assurer que le nombre de profils de service enregistrés par le fournisseur et autorisés à être activés sur le réseau est identique au nombre de profils de service effectivement actifs et utilisés sur le réseau par le client. Cela permet de détecter d’éventuels profils actifs sur le réseau sans autorisation du client (ces profils étant qualifiés de « profils fantômes ») ou d’éventuels problèmes de correspondance entre les systèmes d’information du client et du fournisseur. Ainsi, le procédé proposé consiste à mettre à jour un serveur de gestion permettant d’assurer une visibilité de l’accès et de l’utilisation du réseau, notamment dans le cadre d’une gestion de profils de service souscrits pour une flotte d’équipements terminaux du client. Le serveur de gestion permet donc de centraliser d’une part, des informations d’utilisation des services du réseau par le client, via la mise à jour opérée par le gestionnaire d’accès, et d’autre part, des informations d’authentification enregistrées par le fournisseur, via la mise à jour opérée par le serveur d’authentification. Une telle centralisation d’informations par le serveur de gestion offre une visibilité d’ensemble sur un niveau d’utilisation des services du réseau par le client et permet, au client comme au fournisseur, de contrôler la cohérence d’exploitation des services du réseau. Le gestionnaire d’accès peut correspondre à une plateforme de gestion des profils de services activés sur des terminaux de communication, et plus particulièrement sur des modules de sécurité de type cartes « eSIM » (ou embedded S ubscriber Identity Module ») permettant à un terminal de communication de télécharger des profils de service dans le cadre d’une offre de connectivité virtualisée. Le gestionnaire d’accès est alors capable de créer, sur demande du fournisseur de services, des profils de service téléchargeables sur des cartes eSIM de terminaux de communication. Le gestionnaire d’accès peut notamment communiquer directement avec un terminal de communication du client, par exemple lorsque le terminal souhaite activer son profil créé par le gestionnaire d’accès. Le gestionnaire d’accès peut notamment répertorier les profils de service qu’il a créés et effectivement activés sur des cartes eSIM des terminaux de communication. Ainsi, le premier message de mise à jour du serveur de gestion en provenance du gestionnaire d’accès peut contenir des informations relatives aux profils de service effectivement activés et permet de refléter un état d’utilisation réel des services du réseau par le client. Le serveur d’authentification est principalement rattaché à une base de données d’authentification permettant d’enregistrer les profils de service souscrits par le client, leur état d’activation et d’autres informations notamment liées aux différents terminaux de communication utilisant les profils enregistrés. La base de données d’authentification du serveur d’authentification contient ainsi l’ensemble des informations relatives aux profils de service tels qu’enregistrés par le fournisseur. Ainsi, le second message de mise à jour du serveur de gestion en provenance d’un serveur d’authentification peut contenir des informations relatives aux profils de service enregistrés par le fournisseur sous un statut d’activation de type « actif » et permet de refléter les profils autorisés par le fournisseur à accéder au réseau. Les mises à jour des profils de service enregistrés par le serveur d’authentification d’une part, et par le gestionnaire d’accès d’autre part, sont faites a priori sans contrôle mutuel de cohérence entre le serveur d’authentification et le gestionnaire d’accès, de sorte que les informations enregistrées par le serveur d’authentification peuvent différer des informations enregistrées par le gestionnaire d’accès. La gestion d’accès aux services du réseau par le serveur de gestion permet alors notamment de vérifier une telle cohérence d’informations enregistrées. Un tel procédé peut être mis en œuvre de façon périodique, par exemple dans le cadre d’un audit du système d’information du fournisseur de services, de sorte à avoir une visibilité à intervalles réguliers sur la gestion d’accès aux services du fournisseur par chaque client. Selon un mode de réalisation, le procédé est mis en œuvre après acceptation d’une requête d’un terminal courant de modification d’attribution d’un profil courant parmi les profils de service souscrits. Par conséquent, un tel procédé de gestion d’accès par mise à jour du serveur de gestion peut également être initié à la suite d’une requête de modification d’attribution d’un profil courant reçue et validée par le système d’information du fournisseur, de sorte que chaque nouvelle mise à jour reçue et enregistrée par le fournisseur de services peut déclencher une mise à jour du serveur de gestion selon le procédé décrit. Une requête de modification d’attribution d’un profil courant peut être initiée par un terminal courant parmi les terminaux de communication du client et peut concerner un profil courant parmi les profils de service souscrits par le client. Un profil courant est défini comme un profil de service faisant l’objet de la requête et étant alloué au client dans le cadre d’une offre de connectivité souscrite par le client auprès du fournisseur de services par exemple. Un tel profil courant peut avoir été activé par le client (par exemple lors d’une précédente requête) ou peut également être inactif (si le client n’a pas encore activé le profil courant par exemple). Un terminal courant est défini comme un terminal de communication faisant partie de la flotte d’équipements du client, ces équipements pouvant être attachés au réseau de communication de sorte à utiliser les services fournis par le fournisseur dans le cadre d’une offre de connectivité souscrite par le client. Le terminal de communication concerné par la requête est qualifié de « terminal courant ». Un tel terminal courant peut, au moment d’initier une requête, déjà être attaché au réseau déployé par un profil de service actif (qui peut être le profil courant ou non) ou être non connecté au réseau (par exemple si le terminal courant n’a pas encore de profil de service actif associé). Une requête de modification d’attribution du profil courant par le terminal courant peut alors consister à demander l’activation du profil courant sur le terminal courant afin d’attacher ce terminal courant au réseau et ainsi d’enregistrer un ajout du profil courant à l’ensemble des profils de service activés sur le réseau. La requête de modification d’attribution du profil courant par le terminal courant peut également consister à demander la désassociation entre le profil courant et le terminal courant initialement en correspondance, et ainsi d’enregistrer une suppression du profil courant à l’ensemble des profils de service activés sur le réseau. La requête peut être traitée selon des procédures existantes d’installation et de désinstallation de profils de service de sorte à aboutir à une acceptation ou non de la requête entraînant une modification d’accès des profils de service souscrits au réseau. Ainsi, le procédé de mise à jour du serveur de gestion et de gestion d’accès aux services du réseau peut être déclenché lorsque le fournisseur de services reçoit, par l’intermédiaire d’une interface homme-machine par exemple, une requête d’un terminal courant demandant la modification d’attribution d’un profil courant par un terminal courant et que cette requête est validée par le fournisseur, par exemple après exécution de procédures de vérification existantes permettant de valider la requête. Les étapes du procédé proposé sont alors initiées par exemple lorsque le fournisseur de services détermine que le profil courant peut être associé au terminal courant (dans le contexte d’une requête d’ajout) ou encore que le profil courant peut être supprimé du terminal courant (dans le contexte d’une requête de suppression) et que le fournisseur déclenche l’enregistrement de la modification en conséquence. Dans le contexte de l’invention, le serveur de gestion peut notamment recevoir une notification, une activation ou tout autre signal émis par exemple par le gestionnaire d’accès, par le serveur d’authentification ou plus généralement par le fournisseur de services, afin de signaler l’acceptation d’une nouvelle requête de modification d’attribution par le fournisseur et une nouvelle mise à jour imminente du serveur de gestion, ce qui déclenche le procédé proposé. Selon un autre aspect, il est proposé un serveur de gestion d’un fournisseur d’une pluralité de services, ledit serveur de gestion comportant au moins : - une unité mémoire, - un processeur, ledit serveur de gestion étant adapté pour mettre en œuvre le procédé tel que décrit. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé tel que décrit lorsque ce programme est exécuté par un processeur. Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre, indépendamment les unes des autres ou en combinaison les unes avec les autres : Selon un mode de réalisation, le serveur de gestion comporte en outre au moins une valeur relative à un nombre maximal de profils de service activables simultanément sur le réseau de communication. Par conséquent, la gestion d’accès aux services du réseau permet de vérifier que l’exploitation des services du réseau est en conformité avec des conditions d’exploitation du réseau, ces conditions étant définies à la construction du réseau dans des licences de droit d’usage. En effet, des fonctions logicielles peuvent être utilisées par le fournisseur pour la construction du réseau et des termes d’utilisation de ces fonctions sont négociés par le fournisseur avec des vendeurs de fonctions logicielles dans des licences de droit d’usage. Un droit d’usage peut par exemple être relatif à un nombre maximal de d’utilisateurs simultanément connectés au réseau. Lors de l’exploitation des services du réseau et notamment de la gestion des profils de service souscrits, le client manque généralement de visibilité sur les limites d’accès du réseau imposées par de telles licences et peut difficilement garantir la cohérence entre la gestion de sa souscription et les capacités du réseau telles que décrites par les droits d’usage. Ainsi, en comprenant une valeur relative à un nombre maximal de profils de service activables simultanément sur le réseau de communication, le serveur de gestion permet notamment de comparer le nombre de profils de service actifs sur le réseau tel qu’enregistré par le serveur d’authentification, le nombre total de profils de service actifs sur le réseau tel qu’enregistré par le gestionnaire d’accès et le nombre maximal de profils de service activables simultanément sur le réseau, de sorte à contrôler l’utilisation des services du réseau par le client par rapport aux conditions d’exploitation de ce réseau. Le procédé de gestion d’accès décrit peut alors consister à procéder à plusieurs comparaisons : d’une part, une ou plusieurs comparaisons de cohérence des informations enregistrées par le serveur d’authentification et par le gestionnaire d’accès, et d’autre part, une comparaison de ces informations (par exemple, si ces informations sont cohérentes) avec les conditions d’usage des services du réseau. Le serveur de gestion permet ainsi une centralisation d’informations, ce qui offre une visibilité au client (par exemple par un accès en lecture directe du serveur de gestion à tout moment) sur son niveau d’utilisation des services auxquels il a souscrit. Cette centralisation d’informations au niveau du serveur de gestion permet potentiellement au fournisseur d’identifier un besoin de mise à jour de l’offre de souscription du client afin que le dimensionnement du réseau tel que souscrit par ce dernier (par exemple, en termes de nombre de profils maximal supportés simultanément par le réseau) soit en cohérence avec son utilisation réelle du réseau (par exemple, en termes de nombre de profils effectivement actifs simultanément sur le réseau). Le serveur de gestion peut également comprendre plusieurs valeurs relatives à plusieurs nombres maximaux différents de profils de service activables simultanément sur le réseau de communication. C’est notamment le cas lorsque plusieurs fonctions logicielles sont utilisées par le fournisseur dans la construction du réseau et que chaque fonction logicielle correspond à une licence d’exploitation distincte. Selon un mode de réalisation, le serveur de gestion est lisible par au moins un client du fournisseur de service par l’intermédiaire d’une interface homme-machine. Par conséquent, le procédé offre une visibilité en temps réel de l’utilisation des services du réseau par le client et permet une gestion d’accès aux services du réseau visible par le client. La lecture du serveur de gestion dans le contexte du procédé permet au client de détecter un éventuel problème de correspondance entre les systèmes d’information du fournisseur et du client et de détecter toute anomalie d’utilisation comme la présence de profils actifs sur le réseau sans autorisation du client ou censés avoir été retirés du réseau par le client. Par ailleurs, la lecture du serveur de gestion permet au client de vérifier, dans le cadre de la gestion de profils de service souscrits et de l’exploitation générale des services du réseau, que les capacités du réseau ne sont pas dépassées conformément aux conditions d’utilisation souscrites par le client et plus généralement, que le réseau est exploité au plus juste par le client dans ses capacités et son dimensionnement. La lecture du serveur de gestion centralisant l’ensemble des informations, notamment concernant les droits d’usage du réseau, permet potentiellement au client d’identifier un besoin éventuel d’adapter le dimensionnement du réseau à l’utilisation réelle qui en est faite par le client, par exemple par un changement d’offre souscrit par le client auprès du fournisseur. Selon un mode de réalisation, le nombre maximal de profils de service activables simultanément sur le réseau de communication est prédéfini par au moins une licence d’exploitation du réseau de communication. Par conséquent, le procédé permet de mettre en relation, via le serveur de gestion, des informations sur l’exploitation du réseau par le client et le contenu des licences d’exploitation du réseau définissant les droits d’usage relatifs au réseau, ces droits d’usage étant classiquement méconnus et peu corrélés à l’utilisation réelle du réseau par le client. En effet, lors de la construction du réseau de communication, le fournisseur de services (correspondant par exemple à un opérateur de réseau mobile) achète un ensemble de fonctions logicielles à des vendeurs de fonctions logicielles et les intègre à l’architecture du réseau selon des conditions d’utilisation (ou droits d’usage) spécifiquement négociées entre les vendeurs de fonctions logicielles et le fournisseur. Ces conditions d’utilisation sont détaillées dans des licences d’exploitation du réseau et peuvent concerner divers aspects de l’utilisation du réseau par le client du fournisseur. Entre autres, un droit d’usage du réseau peut concerner un nombre maximal de profils de service activables simultanément sur le réseau de communication. Ainsi, lorsque le client souscrit à une offre de communication auprès du fournisseur, le client souscrit à autant de licences d’exploitation que de nombre d’utilisateurs potentiels du réseau (ce nombre d’utilisateurs correspondant typiquement au nombre de terminaux de communication que le client souhaite rattacher au réseau). Cependant, lors de l’exploitation effective du réseau, le client et le fournisseur manquent généralement de visibilité sur la cohérence d’utilisation du réseau par rapport aux licences d’exploitation souscrites. Ainsi, le procédé permet à la fois au client et au fournisseur de s’assurer que les licences d’exploitation telles que souscrites par le fournisseur pour la construction du réseau soient respectées par le client. En particulier, la gestion d’accès des profils via le serveur de gestion peut permettre de contrôler que le nombre maximal de profils de service activables simultanément sur le réseau de communication n’est pas dépassé, notamment à chaque modification d’attribution d’un profil de service par le client (en particulier à chaque ajout d’un profil activé au réseau). Cette gestion d’accès permet alors éventuellement au client et/ou au fournisseur d’adapter l’offre souscrite par le client afin que les capacités du réseau correspondent au mieux avec les besoins d’utilisation du client. Selon un mode de réalisation, le premier message comprend en outre au moins une mise à jour d’une association entre : - un identifiant d’un profil courant parmi les profils de service attribuables, - un identifiant d’un terminal courant parmi les terminaux de communication accédant au réseau, et - un identifiant du réseau de communication. Selon un mode de réalisation, le second message comprend en outre une mise à jour d’une association entre : - un identifiant d’un profil courant parmi les profils de service attribuables, - un identifiant d’un terminal courant parmi les terminaux de communication accédant au réseau, et - un identifiant du réseau de communication. Par conséquent, la gestion d’accès au réseau permet non seulement de vérifier la cohérence du nombre de profils de service actifs sur le réseau mais également les différentes associations entre chaque profil de service actif et chaque terminal attaché au réseau de communication. Cela permet en particulier au client comme au fournisseur de s’assurer que les profils activés parmi l’ensemble des profils de service souscrits par le client sont bien les profils effectivement demandés et utilisés par le client (et donc d’identifier un éventuel problème de traitement d’une requête d’ajout d’un profil de service par le fournisseur en activant un profil à la place d’un autre exemple) et que chaque profil activé est bien associé à un terminal de communication désigné par le client. Selon un mode de réalisation, à l’issue de l’étape c), le serveur de gestion comporte une donnée signalant une anomalie si le premier nombre total de profils de service actifs sur le réseau de communication et le second nombre total de profils de service actifs sur le réseau de communication ne sont pas égaux. Par conséquent, le procédé permet de notifier le client, via le serveur de gestion, (que le client peut par exemple lire directement via un écran d’un terminal de communication) que l’accès au réseau et son utilisation comportent une irrégularité du fait que le nombre de profils recensés par le fournisseur via le serveur d’authentification est différent du nombre de profils effectivement utilisés par le client et recensé par le gestionnaire d’accès. Cela permet alors au client de régulariser l’accès au réseau (par exemple en demandant la suppression d’un profil activé par erreur par le fournisseur et non utilisé par le client) afin de remettre à jour le serveur de gestion et de s’assurer à nouveau de la cohérence des informations contenues dans le registre de contrôle. Par ailleurs, le procédé peut également permettre au fournisseur d’être averti, via le serveur de gestion, d’une irrégularité dans l’exploitation du réseau du fait que le nombre de profils recensés par le fournisseur via le serveur d’authentification est différent du nombre de profils effectivement utilisés par le client et recensé par le gestionnaire d’accès. Le fournisseur peut alors contacter le client ou par exemple momentanément suspendre toute nouvelle requête d’ajout de profils de service du client jusqu’à régularisation de la situation d’irrégularité (par exemple, jusqu’à ce que le client demande la suppression d’un profil activé par erreur par le fournisseur et non utilisé par le client). Selon un mode de réalisation, la gestion d’accès au service comprend en outre une comparaison du premier nombre total et/ou du second nombre total de profils de service actifs sur le réseau de communication avec au moins le nombre maximal de profils de service activables simultanément sur le réseau de communication. Par conséquent, la gestion d’accès des services du réseau telle que proposée permet de vérifier que les licences d’exploitation du réseau sont bien respectées dans l’utilisation qui en est faite par le client. Le procédé permet effectivement de contrôler régulièrement que les capacités du réseau en termes de nombre maximal d’’utilisateurs connectés au réseau ne sont pas dépassées. La gestion du réseau peut en outre comprendre plusieurs comparaisons entre le premier nombre total et/ou du second nombre total de profils de service actifs sur le réseau de communication et plusieurs nombres maximaux d’utilisateurs connectés au réseau correspondant à des licences d’exploitation différentes. Selon un mode de réalisation, la licence d’exploitation est mise à jour si, à l’issue de la comparaison du premier nombre total et/ou du second nombre total de profils de service actifs sur le réseau de communication avec le nombre maximal de profils de service activables simultanément sur le réseau de communication, le premier nombre total et/ou le second nombre total de profils de service actifs sur le réseau de communication ne correspond pas au nombre maximal de profils de service activables simultanément sur le réseau de communication, ladite mise à jour de la licence d’exploitation consistant à modifier le nombre maximal de profils de service activables simultanément sur le réseau de communication. Par conséquent, le procédé permet a minima d’identifier un besoin d’adapter l’offre de connectivité souscrite par le client auprès du fournisseur de façon « intelligente », en fonction du niveau d’exploitation réel des capacités du réseau par le client. La mise à jour de la licence d’exploitation peut consister à augmenter le nombre de licences associées à l’offre souscrite par le client, de sorte à augmenter le nombre maximal de profils de service activables simultanément sur le réseau de communication si la gestion d’accès aux services du réseau reflète une surexploitation du réseau, à savoir que le client active simultanément un nombre de profils de service supérieur au nombre maximal de profils de service activables simultanément sur le réseau de communication. Dans ce cas, le serveur de gestion peut déclencher une demande de mise à jour de l’offre de connectivité du client, par exemple par exécution d’une mise à jour du contrat de souscription de type smart contract . La mise à jour des licences d’exploitation du réseau est exécutée par les vendeurs des fonctions logicielles concernées, par exemple en procédant à une mise à jour logicielle du réseau. Le procédé proposé permet ainsi au fournisseur de services ainsi qu’au client de gérer les accès aux services du réseau par le client et d’adapter au mieux l’offre de connectivité souscrite par le client à son besoin d’utilisation réel. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 montre une opération de mise à jour d’un serveur de gestion permettant une gestion du réseau selon un mode de réalisation. Fig. 2 montre une succession d’étapes mise en œuvre par un serveur de gestion permettant une gestion d’accès et d’utilisation du réseau selon un mode de réalisation. Fig. 3 illustre schématiquement une structure matérielle d’un serveur de gestion selon un mode de réalisation. Il est maintenant fait référence à la . La illustre une opération mise en œuvre au sein d’un système informatisé d’un fournisseur de services MNO déployant un réseau de communication à disposition d’un client CL. Cette opération permet, par exemple suite à une requête reçue de la part d’un terminal courant UE1 concernant une modification d’attribution d’un profil courant P1 souscrit par le client CL, de mettre à jour un serveur de gestion VNF-le assurant entre autres, à la fois une gestion d’accès au réseau déployé et un contrôle de cohérence d’exploitation du réseau déployé. Dans le contexte de la présente description, le client CL peut être une entreprise par exemple une entreprise industrielle, souscrivant à une offre de communication auprès d’un fournisseur de services de communication MNO pour l’utilisation de l’un ou de plusieurs de ses services, un tel fournisseur de services MNO correspondant par exemple à un opérateur de réseau mobile (« Mobile Network Operator » ou MNO). La souscription comprend alors le déploiement d’un réseau de communication supportant le ou les services souscrits, par exemple un réseau non public (« Non Public Network » ou NPN) déployé par l’opérateur MNO auquel l’entreprise cliente CL peut connecter sa flotte d’équipements terminaux comprenant le terminal courant UE1. Un équipement terminal UE1 peut aussi bien correspondre à un équipement d’utilisateur de type smartphone qu’à tout type d’objet mobile connecté ou module dans le cadre de l’Internet des Objets (« Internet of Things » ou IoT). La communication des équipements terminaux du client CL est assurée par une connexion au réseau déployé par le fournisseur de services MNO conforme à des profils de service (ou profils d’accès) souscrits par le client CL auprès de l’opérateur MNO. La souscription de profils de service peut se faire via une offre dite classique utilisant des processeurs de sécurité physiques ou via une offre de connectivité dite virtualisée utilisant des processeurs de sécurité électroniques ou eSIM. Le processeur de sécurité physique d’un équipement terminal, communément appelé « carte SIM » pour « Subscriber Identity Module » est un support physique insérable et retirable d’un équipement terminal permettant d’embarquer un ensemble de données et d’applications associées, cet ensemble de données et d’applications associées constituant un profil de service. Cependant, de plus en plus de terminaux ne comportent plus directement un processeur de sécurité physique, de type carte SIM, mais plutôt un processeur de sécurité sous la forme d’un module logiciel directement implanté dans le terminal. Il s’agit de la carte SIM électronique ( « embedded SIM ») ou eSIM. L’ensemble des données et des services associés constituant un profil de service est alors téléchargeable sur l’eSIM de chaque terminal dans le cadre d’une offre de connectivité virtualisée impliquant une flotte de terminaux. Dans le contexte de la présente description, les équipements terminaux du client CL contiennent chacun un module de sécurité et sont compatibles avec la souscription d’une offre de connectivité d’une flotte de terminaux. Le module de sécurité est typiquement une carte de type « eSIM », également appelée « eUICC » (« embedded Universal Integrated Circuit Card ») ou carte SIM inamovible. Aucune limitation n’est attachée à ce type de carte. Dans un mode de réalisation particulier, le module de sécurité est une carte à puce avec un système d’exploitation offrant les fonctionnalités d’une carte de type eUICC. Dans un autre mode de réalisation particulier, le module de sécurité est intégré dans chaque terminal formant ainsi une seule entité. Plus généralement, le module de sécurité est une plateforme dédiée inviolable, comprenant du matériel et du logiciel, apte à héberger de manière sécurisée des applications et leurs données confidentielles et cryptographiques et fournissant un environnement d’exécution d’applications sécurisé, ces applications et données formant par exemple un profil de service téléchargeable de manière réversible sur le module de sécurité du terminal. Lors de la souscription à une telle offre de connectivité, le client CL souscrit à un certain nombre de profils de services (dont le profil courant P1) auprès du fournisseur de services MNO, le nombre de profils souscrits dépendant par exemple du nombre de terminaux de la flotte d’équipements du client CL à attacher au réseau déployé. Chaque profil de service souscrit est alors téléchargeable et actif sur un seul terminal de la flotte d’équipements du client CL à la fois. Dans le cadre de la présente description, la gestion des profils de service souscrits et des terminaux connectés au réseau déployé est gérable, au moins partiellement, par le client CL. Autrement dit, le client CL peut demander l’ajout, la suppression ou la modification d’un profil de service et peut également modifier les associations entre un profil de service et un terminal donné, par exemple en désassociant un profil de service actif sur un terminal donné ou au contraire en associant un profil de service activable sur un terminal donné. Ces modifications peuvent notamment être gérées par le fournisseur de services MNO sous la forme de requêtes adressées par le client CL et traitées par le fournisseur de services MNO. La présente description se place dans le contexte des spécifications techniques de la GSMA notamment décrites dans les sections 3.1.1 et 3.1.4 du document RSP Technical Specification, Version 2.0 ( 14 October 2016 ). En particulier, une requête de modification d’attribution d’un profil courant P1 à un terminal UE1 représentée par les étapes S1, S2a et S2b, S3 et S4 de la peut être traitée selon des procédures existantes telles que mentionnées dans les spécifications techniques. Ainsi, en référence à la , à l’étape S1, un terminal courant UE1 appartenant à la flotte d’équipements du client CL effectue une requête de modification d’attribution d’un profil courant P1 appartenant aux profils de service souscrits par le client CL via l’offre de connectivité. La se place dans une situation courante dans laquelle une offre de connectivité a déjà été souscrite par le client CL et un nombre fixe de profils de service activables a été préalablement alloué au client CL par le fournisseur MNO. La définition de l’offre de connectivité du client CL peut impliquer, selon des méthodes existantes, la création d’identifiants de type «codes d’activation » mis en correspondance avec les profils de service alloués au client CL et reconnaissables ultérieurement par le fournisseur MNO et par exemple par le gestionnaire d’accès SM. Ces codes d’activation sont alors envoyés au client CL afin que les différents terminaux de la flotte d’équipements du client CL effectuent des requêtes d’activation des profils de service alloués en renseignant par exemple les codes d’activation fournis. Dans la situation courante considérée, un certain nombre de profils de service souscrits ont été activés et associés à de terminaux connectés au réseau déployé, par exemple, lors de précédentes requêtes effectuées par le client CL auprès du fournisseur MNO et non représentées sur la . La représente alors une nouvelle requête de modification d’attribution d’un profil courant P1 effectuée par un terminal courant UE1 parmi la flotte d’équipements du client CL. Une telle requête de modification d’attribution peut par exemple consister à demander une désassociation entre le profil courant P1 et le terminal courant UE1 dans le cas où une association préalablement demandée (lors d’une précédente requête) existe entre le profil courant P1 et le terminal courant UE1. La requête de modification d’attribution peut également consister à ajouter le nouveau profil courant P1 en l’associant au terminal courant UE1, de sorte à ajouter une nouvelle connexion au réseau déployé par le fournisseur MNO, par exemple dans le cas où le profil courant P1 a été souscrit et n’a jamais encore été téléchargé sur un terminal de la flotte d’équipements du client CL. En référence à la , la requête de modification d’attribution d’un profil courant P1 est effectuée à l’étape S1 par le terminal courant UE1 en communiquant avec le système d’information de l’opérateur MNO, par exemple via une interface homme-machine IHM du système d’information de l’opérateur MNO. Le contenu d’une telle requête de modification d’attribution de profil courant P1 transmise au fournisseur MNO par le terminal courant UE1 peut comprendre : - un identifiant du réseau permettant d’identifier le réseau concerné par la requête, par exemple un identifiant NID (« Network Identifier »), - un identifiant IMEI1 permettant d’identifier le terminal courant UE1 de façon unique, par exemple un identifiant IMEI (« International Mobile Equipment Identity ») ou un identifiant EID1 d’un processeur de sécurité intégré au terminal courant UE1 du type identifiant EID (« Embedded Identity Document »), - un identifiant rattaché au profil courant P1 faisant l’objet de la requête du terminal courant UE1. Cet identifiant permet de définir l’identité du profil concerné de manière unique et peut correspondre par exemple au code d’activation ou code d’authentification communiqué par le fournisseur MNO au client CL lors de la souscription à l’offre et attribué de façon unique à un profil souscrit (en l’occurrence, le profil courant P1). Un tel code d’activation peut par exemple comprendre une donnée de type « Matching ID » permettant au fournisseur MNO de reconnaître le profil courant P1 concerné par la requête. Dans un autre mode de réalisation, cet identifiant peut correspondre à toute autre valeur permettant au client CL de désigner, de façon unique ou non, un profil visé par la requête du terminal courant UE1 parmi l’ensemble des profils de service souscrits, par exemple l’ International Mobile Subscriber Identity (IMSI) dans le cadre de réseaux de deuxième, troisième ou quatrième génération (2G, 3G ou 4G) ou le Subscription Permanent Identifier (SUPI) dans le cadre de réseaux de cinquième génération (5G). - optionnellement, un identifiant de l’offre de connectivité souscrite auquel le profil courant P1 est rattaché, un tel identifiant de l’offre de connectivité pouvant être communiqué par le fournisseur MNO au client CL lors de la souscription à l’offre, - optionnellement, des détails concernant l’objet de la requête de type « nouvelle association», « désassociation », « changement d’association » etc. par exemple. Après réception d’une telle requête de modification d’attribution du profil courant P1, le système d’information du fournisseur MNO identifie le profil courant P1 concerné par la requête, par exemple par association du « Matching ID » reçu par le terminal courant UE1 lors de la requête avec un identifiant IMSI1 connu du fournisseur MNO et associé de façon unique au profil courant P1. Le profil courant P1 activable peut également être créé par le fournisseur MNO à l’issue de l’étape S1, par exemple dans le cas où la requête de modification d’attribution consiste à demander l’activation du profil courant P1 sur le terminal courant UE1 et que le profil courant P1 n’a pas été créé par le fournisseur MNO lors de la souscription de l’offre. À une étape S2a, un enregistrement concernant le profil courant P1 est effectué dans la base de données d’authentification BDD_HSS du serveur d’authentification HSS. Le serveur d’authentification HSS est un serveur de type « Home Subscriber Server » et comprend principalement une base de données d’authentification BDD_HSS enregistrant des informations relatives aux différentes souscriptions auprès du fournisseur MNO, les différents profils de services souscrits pour une souscription client donnée et leur statut d’activation notamment. Le serveur d’authentification HSS correspond notamment au serveur UDR (« User Data Registry ») pour les réseaux mobiles de 5 ème génération (5G) et anciennement appelé serveur HLR (« Home Location Register »). Le serveur d’authentification HSS permet en particulier au fournisseur de services MNO d’enregistrer les profils de service de terminaux autorisés à se connecter au réseau. Ainsi, à l’étape S2a, le serveur d’authentification HSS comprend une mise à jour concernant le profil courant P1 et le terminal courant UE1 concernés par la requête de modification d’attribution du profil courant P1. Par exemple, si la requête de modification d’attribution du profil courant P1 consiste à désassocier le profil courant P1 du terminal courant UE1, la base de données d’authentification BDD_HSS prend notamment en compte, à l’issue de l’étape S2a : - une suppression d’une correspondance existante entre le réseau d’identifiant NID, le terminal courant UE1 d’identifiant EID1 et le profil courant P1 d’identifiant IMSI1, et - une décrémentation du nombre total N_HSS de profils de service enregistrés sur le réseau par le serveur d’authentification HSS, le profil courant P1 n’étant plus enregistré et actif sur le réseau. Le fournisseur MNO enregistre alors via la base de données BDD_HSS du serveur d’authentification HSS que le profil courant P1 est de nouveau activable par un terminal de communication du client CL et que le terminal courant UE1 est de nouveau capable d’accueillir un nouveau profil de service pour se connecter au réseau. Si la requête de modification d’attribution du profil courant P1 reçue par le fournisseur MNO à l’étape S1 consiste à associer le profil courant P1 au terminal courant UE1, la base de données d’authentification BDD_HSS prend notamment en compte, à l’issue de l’étape S2a : - un ajout d’une correspondance nouvellement créée à l’étape S2a entre le réseau d’identifiant NID, le terminal courant UE1 d’identifiant EID1 et le profil courant P1 d’identifiant IMSI1, et - une incrémentation du nombre total N_HSS de profils de service enregistrés sur le réseau par le serveur d’authentification HSS. Le fournisseur MNO enregistre alors via la base de données BDD_HSS du serveur d’authentification HSS que le profil courant P1 est activé et associé au terminal courant UE1. Le serveur d’authentification HSS enregistre donc le nouveau statut d’activation du profil courant P1 ainsi que d’autres informations relatives au profil courant P1. Ainsi, dans le cas d’une requête d’association d’un nouveau profil courant P1 avec le terminal courant UE1, l’étape S2a assure que le profil courant P1 est créé par le fournisseur MNO de façon sécurisée et qu’un tel profil courant P1 est activable et utilisable par le terminal courant UE1. La mise à jour de la base de données d’authentification BDD_HSS du serveur d’authentification HSS à l’étape S2a peut notamment avoir lieu après une procédure de validation de la requête par le fournisseur MNO (non représentée sur la ), par exemple afin de s’assurer que le profil courant P1 n’est pas déjà activé et associé à un autre terminal de communication ou encore que le terminal courant UE1 ne contient pas déjà un autre profil de service actif par exemple. Différentes méthodes existantes permettent au fournisseur MNO de déterminer si la requête du terminal courant UE1 est acceptable ou non. Des méthodes peuvent ainsi consister, dans le cas d’une requête d’association entre le terminal courant UE1 et le profil courant P1, à automatiquement désassocier une éventuelle association existante entre le terminal courant UE1 et un autre profil de service pour remplacer ce dernier par le profil courant P1. Dans le cas d’une requête de modification d’association du profil courant P1 refusée par le fournisseur MNO, le fournisseur MNO transmet un message de refus de la requête au terminal courant UE1, par exemple via un message de refus adressé par le gestionnaire d’accès SM à l’étape S4. En particulier, dans le cas d’une requête d’association entre le profil courant P1 et le terminal courant UE1 refusée par le fournisseur MNO, la base de données d’authentification BDD_HSS n’est pas mise à jour à l’étape S2a et aucun nouveau profil courant P1 n’est créé par le gestionnaire d’accès SM à une étape S2b. À l’étape S2b, le fournisseur MNO transmet les informations relatives à la requête de modification d’attribution du profil courant P1 (comprenant notamment le « Matching ID » relatif au profil courant P1 et l’identifiant EID1 du terminal courant UE1) au gestionnaire d’accès SM afin que ce dernier SM crée le profil courant P1 à spécifiquement télécharger sur le module de sécurité eSIM d’identifiant EID1 du terminal courant UE1. Le gestionnaire d’accès SM correspond dans ce contexte à une plateforme de gestion des modules eSIM déployée par le fournisseur MNO de type « Subscriber Manager eSIM » qui correspond au serveur SMDP (« Subscription Manager Data Preparation ») dans les spécifications techniques définies par l’association GSMA (« Global System for Mobile Communications Association ») ou au regroupement du serveur SMDP et du SM-SR (« Subscription Manager Secure Routing ») dans le cadre du Machine-To-Machine (M2M) par exemple. Le gestionnaire d’accès SM permet alors d’enregistrer les profils de service souscrits par le client CL dans les cartes eSIM des terminaux de communication du client CL. À l’étape S2b, dans le cas d’une requête d’ajout du profil courant P1 au terminal courant UE1 par exemple, le gestionnaire d’accès SM prépare alors les données de téléchargement du profil courant UE1 activable par le terminal courant UE1 en encapsulant ces données de profil courant P1 dans un message à transmettre au terminal courant UE1 à une étape S4, par exemple sous la forme d’un QR code. À une étape S3 entre les étapes S2b et S4, le gestionnaire d’accès SM peut également vérifier dans la base de données d’authentification BDD_HSS du serveur d’authentification HSS que le profil courant P1 est bien enregistré et activable par le terminal courant UE1. Dans le cas d’une requête de suppression du profil courant P1 du terminal courant UE1 reçue à l’étape S1, le gestionnaire d’accès SM peut vérifier à l’étape S3 que la désassociation du profil courant P1 et du terminal courant UE1 est bien enregistrée dans la base de données d’authentification BDD_HSS. À l’étape S4, le gestionnaire d’accès SM transmet alors la confirmation de la modification d’association requise au terminal courant UE1. Dans le cas d’une requête d’association entre le terminal courant UE1 et le profil courant P1, le gestionnaire d’accès SM encapsule effectivement les données liées au profil courant P1 d’identifiant IMSI1 et transmet les données sous forme chiffrée permettant l’installation du profil courant P1 et son contenu dans un message adressé au terminal courant UE1 à l’étape S4. Ce message peut correspondre à un code digital de type « QR code » ou tout autre type de message encapsulant les données du profil courant P1 et lisible par le terminal courant UE1 via un capteur graphique intégré au terminal courant UE1 par exemple. Le message transmis par le gestionnaire d’accès SM au terminal courant UE1 à l’étape S4 contient alors le profil courant P1 à télécharger par le terminal courant UE1 sur son module de sécurité eSIM. Dans le cas d’une requête de désassociation entre le terminal courant UE1 et le profil courant P1 par exemple, le gestionnaire d’accès SM peut simplement transmettre la confirmation que la désassociation a bien été validée par le fournisseur MNO, notamment en vérifiant à l’étape S3 qu’une telle désassociation est bien enregistrée par le fournisseur MNO dans la base de données d’authentification BDD_HSS. À l’issue de l’étape S4 et après respect d’un éventuel délai prédéfini durant lequel le client pourrait signaler un éventuel problème de traitement de sa requête, le gestionnaire d’accès SM enregistre dans une base de données BDD_SM ou dans une mémoire locale propre au gestionnaire d’accès SM la modification d’association concernant le réseau d’identifiant NID, le terminal courant UE1 d’identifiant EID1 (correspondant ici à l’identifiant d’un module eSIM solidaire du terminal courant UE1) et le profil courant P1. Dans un autre mode de réalisation, le gestionnaire d’accès SM attend, à l’issue de l’étape S4, un message retour du terminal courant UE1 avant de mettre à jour sa base de données BDD_SM. Ce message retour, non représenté sur la , peut être un message confirmant la bonne réception par le terminal courant UE1 du message adressé par le gestionnaire d’accès SM à l’étape S4 ou encore confirmant le bon déroulement du téléchargement des données d’installation du profil courant P1 dans le cas d’une requête d’installation de profil par exemple. Ainsi, dans le cas d’une requête d’association entre le terminal courant P1 et le profil courant P1, lorsque le gestionnaire d’accès SM reçoit, à l’issue de l’étape S4, une confirmation du client CL (par exemple via le terminal UE1) du bon déroulement du téléchargement des données du profil courant P1 sur le terminal courant UE1, le gestionnaire d’accès SM met à jour sa base de données BDD_SM en enregistrant à son tour que : - le nombre total N_SM de profils de service activés sur un module eSIM d’un terminal client CL sur le réseau a augmenté avec un nouveau profil téléchargé (à savoir le profil courant P1), - une nouvelle association entre le terminal courant UE1 et le profil courant P1 existe pour le réseau considéré (correspondant à une association entre les identifiants EID1, IMSI1 et NID par exemple). Si la requête acceptée consiste au contraire à demander la désassociation entre le terminal courant UE1 et le profil courant P1, lorsque le gestionnaire d’accès SM reçoit, à l’issue de l’étape S4, une confirmation du client CL (par exemple via le terminal UE1) que la désassociation a bien été prise en compte (par exemple que le module eSIM du terminal courant UE1 est bien à nouveau libre pour une nouvelle association à un profil de service), le gestionnaire d’accès SM met à jour sa base de données BDD_SM en enregistrant à son tour que : - le nombre total N_SM de profils de service activés sur un module eSIM d’un terminal client CL sur le réseau a diminué avec un nouveau profil de service détaché du réseau et à nouveau activable (à savoir le profil courant P1), - une association existante entre le module eSIM du terminal courant UE1 et le profil courant P1 pour le réseau considéré est supprimée (correspondant à une désassociation entre les identifiants EID1, IMSI1 et NID par exemple). Le nombre total N_SM de profils de service activés sur un module eSIM et/ou les associations enregistrées par le gestionnaire d’accès SM peut potentiellement différer du nombre total N_HSS de profils de service enregistrés par le serveur d’authentification HSS et/ou les associations enregistrées par le serveur d’authentification HSS dans le cas d’éventuels problèmes de traitement de la requête signalés par le client CL à l’issue de l’étape S4, le message retour reçu par le gestionnaire d’accès SM indiquant par exemple que le profil courant P1 n’a pas pu être téléchargé sur le module eSIM du terminal courant UE1 (le QR code n’étant pas lisible par le terminal courant UE1 par exemple). Dans ce cas, le nombre total N_SM de profils de service activés sur un module eSIM enregistré par le gestionnaire d’accès SM ne sera pas incrémenté et sera de ce fait inférieur au nombre total N_HSS de profils de service enregistrés par le serveur d’authentification HSS. L’association entre les identifiants NID, EID1 et IMSI1 correspondant à une association entre le terminal courant UE1 et le profil courant P1 sera existante dans la base de données d’authentification BDD_HSS du serveur d’authentification HSS mais absente de la base de données BDD_SM du gestionnaire d’accès SM. Lors des étapes S5 et S6, le gestionnaire d’accès SM et le serveur d’authentification HSS centralisent entre autres les informations contenues dans leurs bases de données respectives BDD_SM et BDD_HSS telles que mises à jour à l’issue de la requête traitée. Cette centralisation d’informations est effectuée au sein d’un serveur de gestion VNF-le. Le serveur de gestion VNF-le est un registre propre au réseau déployé et contenant notamment des informations relatives aux droits d’usage associés aux licences d’exploitation respectives des fonctions logicielles utilisées dans l’architecture du réseau, comme le serveur d’authentification HSS par exemple. Ainsi, le serveur de gestion VNF-le contient par exemple une information relative à un nombre maximal N_max de profils de service activables simultanément par le serveur d’authentification HSS sur le réseau déployé, conformément aux conditions d’utilisation du serveur d’authentification HSS tel que souscrit par le serveur d’authentification HSS. Le cœur du réseau déployé par le fournisseur MNO contenant généralement différentes fonctions logicielles ayant chacune une licence d’exploitation potentielle et concernant entre autres un nombre maximal d’utilisateurs simultanés sur le réseau, le serveur de gestion VNF-le peut comprendre plusieurs nombres maximaux d’utilisateurs simultanés sur le réseau, chaque nombre maximal étant spécifique à chaque fonction logicielle du réseau. À l’étape S5, le gestionnaire d’accès SM envoie ainsi un premier message au serveur de gestion VNF-le, ce premier message contenant notamment des informations contenues dans la base de données BDD_SM ou la mémoire du gestionnaire d’accès SM telle que mise à jour par ce dernier après l’étape S4 (par exemple, après réception d’un message de confirmation du bon traitement de la requête par le terminal courant UE1). Ces informations mises à jour concernent par exemple: - le nombre total N_SM de profils de service activés sur le réseau tel que mis à jour dans la base de données BDD_SM du gestionnaire d’accès SM, et/ou - les associations entre profils de service et terminaux activés sur le réseau tel que mis à jour dans la base de données BDD_SM du gestionnaire d’accès SM. Un tel premier message envoyé par le gestionnaire d’accès SM au serveur de gestion VNF-le à l’étape S5 permet au serveur de gestion VNF-le d’inclure les informations à jour liées aux profils de service tels qu’effectivement activés et associés aux modules eSIM respectifs des terminaux de communication des clients CL. À l’étape S6, le serveur d’authentification HSS envoie un second message au serveur de gestion VNF-le, ce second message contenant notamment des informations contenues la base de données BDD_HSS du serveur d’authentification HSS telle que mise à jour par ce dernier à l’issue de l’étape S2a. Ces informations mises à jour concernent par exemple: - le nombre total N_HSS de profils de service enregistrés sur le réseau tel que mis à jour dans la base de données BDD_HSS du serveur d’authentification HSS, et/ou - les associations entre profils de service et terminaux actifs sur le réseau tel que mis à jour dans la base de données BDD_HSS du serveur d’authentification HSS. Un tel second message envoyé par le serveur d’authentification HSS au serveur de gestion VNF-le à l’étape S6 permet au serveur de gestion VNF-le d’inclure les informations à jour liées aux profils de service et à leur association avec des terminaux donnés tels qu’effectivement validés par le serveur d’authentification HSS. Dans un autre mode de réalisation, le second message peut être envoyé par le serveur d’authentification HSS au serveur de gestion VNF-le dès que la base de données d’authentification BDD_HSS du serveur d’authentification HSS est mise à jour à l’issue de l’étape S2a. Par ailleurs, le serveur de gestion VNF-le comprend également une base de données propre BDD_LE contenant les informations relatives aux droits d’usage de chaque fonction logicielle utilisée dans le réseau déployé et associée à une licence d’exploitation. Une telle base de données BDD_LE peut notamment comprendre le nombre maximal d’utilisateurs simultanés sur le réseau tel que défini par chacune des fonctions logicielles du réseau, comme par exemple le nombre maximal N_max de profils de services simultanément activés sur le réseau par le serveur d’authentification HSS. En référence à la , un exemple de structure matérielle du serveur de gestion VNF-le est illustré. Le serveur de gestion VNF-le peut comprendre : - une interface de communication COM avec le gestionnaire d’accès SM et le serveur d’authentification HSS pour recevoir les premier et second messages de mise à jour du gestionnaire d’accès SM et du serveur d’authentification HSS respectivement. L’interface de communication COM du serveur de gestion VNF-le est également reliée à une base de données BDD_LE contenant les informations relatives aux droits d’usage de chaque fonction logicielle utilisée dans le réseau déployé et associée à une licence d’exploitation, ces informations comprenant par exemple le nombre maximal N_max de profils de services activables simultanément sur le réseau par le serveur d’authentification HSS ou encore d’autres nombres maximaux d’utilisateurs simultanés sur le réseau définis par d’autres vendeurs de fonctions logicielles incluses dans le réseau. En variante, une telle base de données BDD_LE peut être directement intégrée au serveur de gestion VNF-le ; - une unité mémoire MEM stockant notamment des instructions d’un programme informatique pour l’exécution d’un procédé de gestion d’accès au réseau tel que détaillé ci-après dans la description de la . L’unité mémoire MEM stocke également les messages reçus en provenance du gestionnaire d’accès SM et du serveur d’authentification HSS. - un circuit de traitement comprenant un processeur PROC et coopérant avec l’interface de communication COMM pour l’exécution du procédé de gestion d’accès au réseau tel que détaillé ci-après dans la description de la ; et - une interface client INT permettant au serveur de gestion VNF-le d’afficher des informations résultant notamment de l’exécution du procédé de contrôle d’accès au réseau par le circuit de traitement, de sorte que ces informations soient lisibles par le client CL (par l’intermédiaire d’un ou de plusieurs terminaux de sa flotte d’équipements par exemple). Il est maintenant fait référence à la . La illustre un procédé mis en œuvre par un serveur de gestion VNF-le du fournisseur de services MNO de sorte à opérer une gestion d’accès et d’utilisation des services du réseau par le client CL. À l’étape S5, le serveur de gestion VNF-le reçoit un premier message de mise à jour en provenance du gestionnaire d’accès SM. Ce premier message, stocké dans l’unité mémoire MEM du serveur de gestion VNF-le, contient notamment : - le nombre total N_SM de profils de service actifs sur le réseau comptabilisés par le gestionnaire d’accès SM à l’issue d’une dernière mise à jour de la base de données BDD_SM du gestionnaire d’accès SM, et/ou - les profils de service activés et associés à des terminaux de communication connectés au réseau tels qu’enregistrés par le gestionnaire d’accès SM à l’issue d’une dernière mise à jour de la base de données BDD_SM du gestionnaire d’accès SM. Un tel premier message de mise à jour reçu par le serveur de gestion VNF-le en provenance du gestionnaire d’accès SM à l’étape S5 a notamment lieu lorsqu’à l’issue d’un traitement d’une requête client d’un terminal courant UE1 comme illustrée par la , le gestionnaire d’accès SM enregistre : - l’activation d’un nouveau profil courant P1 souscrit en l’associant au terminal courant UE1, ce qui augmente le nombre total N_SM (devenant N_SM+1) de profils de service actifs sur le réseau comptabilisés par le gestionnaire d’accès SM et crée une nouvelle association (NID-EID1-IMSI1) dans la base de données BDD_SM du gestionnaire d’accès SM, ou - la désassociation d’un profil courant P1 et du terminal courant UE1, ce qui diminue le nombre total N_SM (devenant N_SM-1) de profils de service actifs sur le réseau comptabilisés par le gestionnaire d’accès SM et supprime une association existante (NID-EID1-IMSI1) dans la base de données BDD_SM du gestionnaire d’accès SM. Une telle mise à jour du serveur de gestion VNF-le par le gestionnaire d’accès SM n’a a priori pas lieu (ou du moins, ne modifie pas les données existantes) lorsque le gestionnaire d’accès SM transmet une décision de rejet de la requête à l’étape S4 de la et que la base de données BDD_SM du gestionnaire d’accès SM n’est pas modifiée par exemple. Dans un autre mode de réalisation, le premier message reçu en provenance du gestionnaire d’accès SM est identique à un message précédemment reçu en provenance du gestionnaire d’accès SM. En particulier, le serveur de gestion VNF-le peut recevoir le premier message même en l’absence d’une nouvelle requête de modification d’attribution d’un profil courant P1 acceptée par le fournisseur MNO et donc d’une mise à jour des données du gestionnaire d’accès SM. Le serveur de gestion VNF-le peut recevoir le premier message dans le cadre d’une mise à jour périodique du serveur de gestion VNF-le et/ou dans le cadre d’un audit par exemple. À l’étape S6, le serveur de gestion VNF-le reçoit un second message de mise à jour en provenance du serveur d’authentification HSS. Ce second message, stocké dans l’unité mémoire MEM du serveur de gestion VNF-le, contient au moins : - le nombre total N_HSS de profils de service actifs sur le réseau tels qu’enregistrés par le serveur d’authentification HSS à l’issue d’une dernière mise à jour de la base de données BDD_HSS du serveur d’authentification HSS, et - les profils de service activés et associés à des terminaux de communication connectés au réseau tels qu’enregistrés par le serveur d’authentification HSS à l’issue d’une dernière mise à jour de la base de données BDD_HSS du serveur d’authentification HSS. Un tel second message de mise à jour reçu par le serveur de gestion VNF-le en provenance du serveur d’authentification HSS à l’étape S6 a notamment lieu lorsqu’à l’issue d’un traitement d’une requête client d’un terminal courant UE1 comme illustrée par la , le serveur d’authentification HSS valide la requête du terminal UE1 et enregistre : - l’activation d’un nouveau profil courant P1 souscrit en l’associant au terminal courant UE1, ce qui augmente le nombre total N_HSS (devenant N_HSS+1) de profils de service actifs sur le réseau comptabilisés par le serveur d’authentification HSS et crée une nouvelle association (NID-EID1-IMSI1) dans la base de données BDD_HSS du serveur d’authentification HSS, ou - la désassociation d’un profil courant P1 et du terminal courant UE1, ce qui diminue le nombre total N_HSS (devenant N_HSS-1) de profils de service actifs sur le réseau comptabilisés par le serveur d’authentification HSS et supprime une association existante (NID-EID1-IMSI1) dans la base de données BDD_HSS du serveur d’authentification HSS. Une telle mise à jour du serveur de gestion VNF-le par le serveur d’authentification HSS n’a a priori pas lieu (ou du moins, ne modifie pas les données existantes) lorsque le serveur d’authentification HSS rejette la requête du terminal courant UE1 entre les étapes S2 et S3 de la et que la base de données BDD_HSS du serveur d’authentification HSS n’est pas modifiée par exemple. Dans un autre mode de réalisation, le second message reçu en provenance du serveur d’authentification HSS est identique à un message précédemment reçu en provenance du serveur d’authentification HSS. En particulier, le serveur de gestion VNF-le peut recevoir le second message même en l’absence d’une nouvelle requête de modification d’attribution d’un profil courant P1 acceptée par le fournisseur MNO et donc d’une mise à jour des données du serveur d’authentification HSS. Le serveur de gestion VNF-le peut recevoir le second message dans le cadre d’une mise à jour périodique du serveur de gestion VNF-le et/ou dans le cadre d’un audit par exemple. Une fois les premier et second messages de mise à jour reçus aux étapes S5 et S6, le serveur de gestion VNF-le procède à une gestion d’accès et d’utilisation du réseau via une première comparaison à l’étape S7. Cette première comparaison consiste à comparer le nombre total N_SM de profils de service actifs sur le réseau comptabilisés par le gestionnaire d’accès SM avec le nombre total N_HSS de profils de service actifs sur le réseau tels qu’activés par le serveur d’authentification HSS et à vérifier que ces deux valeurs N_SM, N_HSS mises à jour séparément par le gestionnaire d’accès SM et le serveur d’authentification HSS sont égales. En effet, l’égalité des valeurs N_SM et N_HSS permet tout d’abord de garantir que le nombre de profils total N_HSS activés par le serveur d’authentification HSS et donc à la connaissance du fournisseur MNO est le même que le nombre de profils total N_SM effectivement activés sur des modules eSIM des terminaux et utilisés sur le réseau à la connaissance du client CL. Si ces deux valeurs N_SM et N_HSS sont différentes, le serveur de gestion VNF-le signale la présence d’une irrégularité d’utilisation du réseau à une étape S9. Les valeurs N_SM et N_HSS peuvent différer dans le cas d’éventuels problèmes de traitement de la requête signalés par le client CL via un message retour reçu par le gestionnaire d’accès SM indiquant par exemple que le profil courant P1 faisant l’objet de la dernière requête traitée par le fournisseur MNO n’a pas pu être téléchargé sur le module eSIM du terminal courant UE1 (le QR code n’étant pas lisible par le terminal courant UE1 par exemple) malgré l’activation du profil courant P1 par le serveur d’authentification HSS. Dans ce cas, le nombre total N_SM de profils de service activés sur un module eSIM enregistré par le gestionnaire d’accès SM ne sera pas incrémenté et sera de ce fait inférieur au nombre total N_HSS de profils de service activés par le serveur d’authentification HSS. L’association entre les identifiants NID, EID1 et IMSI1 correspondant à une association entre le terminal courant UE1 et le profil courant P1 sera existante dans la base de données d’authentification BDD_HSS du serveur d’authentification HSS mais absente de la base de données BDD_SM du gestionnaire d’accès SM. Ainsi, les valeurs N_SM et N_HSS telles que mises à jour dans le serveur de gestion VNF-le par le gestionnaire d’accès SM et le serveur d’authentification HSS aux étapes S5 et S6 différeront. Dans un mode de réalisation de l’invention, cette irrégularité d’utilisation du réseau est affichée dans l’interface client INT de sorte à être lisible par le client CL via une lecture du serveur de gestion VNF-le. Dans un mode de réalisation de l’invention (non décrit par les figures 2 et 3), le serveur de gestion VNF-le peut communiquer avec une entité de gestion du fournisseur de service MNO afin de signaler une irrégularité d’utilisation du réseau déployé de sorte à bloquer toute nouvelle demande d’ajout tant que l’irrégularité d’utilisation n’est pas résolue (par exemple par une nouvelle mise à jour du serveur de gestion VNF-le aux étapes S5 et S6, une telle mise à jour présentant des valeurs N_HSS et N_SM égales). Si les valeurs N_SM et N_HSS sont bien égales, le serveur de gestion VNF-le poursuit la gestion d’accès et d’utilisation du réseau via une seconde comparaison à l’étape S8. Cette seconde comparaison consiste à vérifier que les associations entre profils de service et terminaux de communication activés sur le réseau telles qu’enregistrées d’une part, par le gestionnaire d’accès SM et d’autre part, le serveur d’authentification HSS sont bien les mêmes. Autrement dit, cette seconde comparaison permet à la fois de vérifier que : - les profils de service actifs sur le réseau tels qu’enregistrés par le gestionnaire d’accès SM et le serveur d’authentification HSS sont bien les mêmes, et - les terminaux connectés au réseau tels qu’enregistrés par le gestionnaire d’accès SM et le serveur d’authentification HSS sont bien les mêmes, et - pour chaque profil de service actif sur le réseau, le gestionnaire d’accès SM et le serveur d’authentification HSS lui associent effectivement le même terminal de communication. En effet, si l’étape S7 permet par exemple de garantir l’absence de profils dits « fantômes » correspondant à des profils activés par le fournisseur MNO (via le serveur d’authentification HSS) mais non effectivement utilisés par le client CL, l’étape S8 permet quant à elle de garantir qu’il n’y a pas d’erreur d’association entre les terminaux de la flotte d’équipements du client CL connectés au réseau et les différents profils activés et utilisés par le client CL, de telles erreurs étant par exemple liées à des problèmes de correspondance entre les systèmes de gestion de profils du côté du fournisseur de service MNO (donc du côté du serveur d’authentification HSS) et du côté du client CL (donc du côté du gestionnaire d’accès SM). Si à l’étape S8, une erreur d’association est détectée (par exemple, un profil de service d’identifiant IMSIk donné est enregistré par le gestionnaire d’accès SM et le serveur d’authentification HSS comme étant associé à deux terminaux d’identifiants EIDa et EIDb différents par exemple), le serveur de gestion VNF-le procède à l’étape S9 et signale une irrégularité d’utilisation du réseau. Dans un mode de réalisation, les étapes S7 et S8 peuvent correspondre à une étape unique dans le cas où par exemple le serveur de gestion VNF-le détecte une différence entre les valeurs N_SM et de N_HSS en comparant les associations entre profils de service et terminaux de communication activés sur le réseau. Si à l’étape S8, aucune erreur d’association n’est détectée, le serveur de gestion VNF-le poursuit la procédure de gestion d’accès et d’utilisation du réseau par le client CL en procédant à une troisième comparaison à une étape S10. Pour cette troisième comparaison, le serveur de gestion VNF-le procède à la lecture dans la base de données BDD_LE du serveur de gestion VNF-le des informations relatives aux droits d’usage des fonctions logicielles utilisées dans le réseau et identifie notamment le nombre maximal N_max de profils de service activables simultanément par le serveur d’authentification HSS sur le réseau. La troisième comparaison du procédé consiste alors à comparer le nombre total N_SM (ou N_HSS) de profils de services actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS (l’étape S7 garantissant que ce nombre est le même pour les deux entités SM et HSS) avec le nombre maximal N_max de profils activables simultanément sur le réseau, tel que stipulé dans les termes des licences d’exploitation associées à la souscription du client CL et contenues dans la base de données BDD_LE du serveur de gestion VNF-le. L’étape S10 peut également comprendre des comparaisons entre le nombre total N_SM (ou N_HSS) de profils de services actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS et chacun des nombres maximaux d’utilisateurs simultanément autorisés sur le réseau, tels que définis par les licences d’exploitation d’autres fonctions logicielles du réseau, ces nombre maximaux étant lus par le serveur de gestion VNF-le dans la base de données BDD_LE. L’étape S10 permet ainsi de vérifier si les licences souscrites par le fournisseur de services MNO auprès d’un ou de plusieurs vendeurs de fonctions logicielles utilisées dans le réseau par le client CL présentent des capacités matérielles et logicielles telles que réellement requises et exploitées par le client CL. Si à l’étape S10, le nombre total N_SM (ou N_HSS) de profils de service actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS est égal au nombre maximal N_max de profils activables simultanément sur le réseau, cela signifie que le réseau tel que déployé par le fournisseur de services MNO est exploité à sa capacité par le client CL et que les conditions d’exploitation des licences telles que souscrites par le fournisseur MNO (et de façon sous-jacente, le client CL) auprès des vendeurs de fonctions logicielles (en l’occurrence le vendeur de la fonction logicielle du serveur d’authentification HSS) sont bien estimées. Dans ce cas, le serveur de gestion VNF-le confirme optionnellement que les licences telles que souscrites par le client CL sont bien adaptées à son utilisation du réseau par l’affichage d’un message de confirmation de type « license OK » par exemple sur l’interface client INT à une étape S101. La procédure de gestion d’accès et d’utilisation du serveur de gestion VNF-le s’achève donc à l’étape S101 sans changement des conditions de souscription du client CL auprès du fournisseur MNO. Si à l’étape S10, le nombre total N_SM (ou N_HSS) de profils de service actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS est supérieur au nombre maximal N_max de profils activables simultanément sur le réseau (ou à un des nombre maximaux définis par la licence d’exploitation d’une des fonctions logicielles du réseau), cela signifie que les conditions d’exploitation des fonctions logicielles du réseau telles qu’établies par les vendeurs des fonctions logicielles au fournisseur de services MNO ne sont pas respectées et que le client CL surexploite le réseau déployé par le fournisseur de services MNO. C’est par exemple le cas lorsque le client CL souscrit à une offre de connectivité pour N terminaux (conduisant donc à N licences d’exploitation associées à la souscription) mais que lors de l’exploitation concrète du réseau, la flotte d’équipements du client CL attachés au réseau compte plus de N terminaux de communication et/ou requiert l’activation de plus de N profils de service. Si à l’étape S10, le nombre total N_SM (ou N_HSS) de profils de service actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS est inférieur au nombre maximal N_max de profils activables simultanément sur le réseau, cela signifie que le client CL sous-exploite le réseau déployé par le fournisseur de services MNO. Possiblement, le client CL peut avoir souscrit à une offre de connectivité pour N terminaux (conduisant donc à N licences d’exploitation associées à la souscription) sans toutefois utiliser les N terminaux de communication de façon simultanée et/ou sans avoir requis l’activation simultanée des N profils de service commandés. Dans le scénario de surexploitation et éventuellement de sous-exploitation du réseau, un réajustement des licences d’exploitation du réseau peut permettre de redimensionner les capacités du réseau en cohérence avec les besoins d’utilisation du client CL (soit pour des raisons notamment légales de respect des conditions d’exploitation du réseau dans le cas d’une surexploitation du réseau, soit par exemple pour des raisons de surcoût dans le cas d’une sous-exploitation du réseau). Un tel réajustement des licences d’exploitation peut être réalisé par les vendeurs des fonctions logicielles concernées par le réajustement via par exemple une mise à jour logicielle. Le serveur de gestion VNF-le procède alors à une étape S100 visant un tel réajustement des licences d’exploitation du réseau, par exemple par l’exécution d’un contrat intelligent (« smart contract ») entre le fournisseur de services MNO et les vendeurs de fonctions logicielles concernés dont la condition d’exécution correspond à l’inégalité entre le nombre total N_SM (ou N_HSS) de profils de service actifs sur le réseau tels que dénombrés par le gestionnaire d’accès SM et le serveur d’authentification HSS et le nombre maximal N_max de profils activables simultanément sur le réseau et le résultat d’exécution conduit à une mise à jour logicielle du réseau. Dans un mode de réalisation, la mise à jour peut concerner l’ensemble des fonctions logicielles du réseau venant notamment modifier les informations des licences d’exploitation. Le serveur de gestion VNF-le affiche alors via l’interface client CL un message de type « license UPD ATED » par exemple. Dans un autre mode de réalisation, la licence d’exploitation n’est pas nécessairement mise à jour par le serveur de gestion VNF-le du fournisseur de services MNO et le serveur de gestion VNF-le affiche simplement un message de type « license KO » via l’interface client INT, de sorte à informer le client de la pertinence d’une modification des licences souscrites. Le serveur de gestion VNF-le permet alors de procéder à une gestion d’accès et d’utilisation du réseau par la flotte d’équipements terminaux d’un client CL et déployé par un fournisseur de services MNO. Il permet à la fois au client et au fournisseur de services MNO d’assurer une bonne gestion des opérations au sein du réseau de communication déployé dans le respect des conditions d’usages des fonctions logicielles associées à ce dernier. Procédé mis en œuvre par un serveur de gestion (VNF-le) d’un fournisseur d’une pluralité de services (MNO), de gestion de profils de service relatifs à un service de la pluralité, les profils étant attribuables à des terminaux de communication accédant à un réseau de communication supportant ledit service, le procédé comprenant: a) une réception d’un premier message de mise à jour du serveur de gestion (VNF-le) en provenance d’un gestionnaire d’accès (SM), ledit premier message comprenant au moins une mise à jour d’un premier nombre total (N_SM) de profils de service actifs sur le réseau de communication, b) une réception d’un second message de mise à jour du serveur de gestion (VNF-le) en provenance d’un serveur d’authentification (HSS), ledit second message comprenant au moins une mise à jour d’un second nombre total (N_HSS) de profils de service actifs sur le réseau de communication, c) une gestion d’accès au service par au moins une comparaison entre le premier nombre total (N_SM) de profils de service actifs sur le réseau de communication et le second nombre total (N_HSS) de profils de service actifs sur le réseau de communication. Procédé selon la revendication 1, dans lequel le serveur de gestion (VNF-le) comporte en outre au moins une valeur relative à un nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication. Procédé selon l’une des revendications précédentes, dans lequel le serveur de gestion (VNF-le) est lisible par au moins un client (CL) du fournisseur de service (MNO) par l’intermédiaire d’une interface homme-machine (INT). Procédé selon l’une des revendications précédentes, dans lequel le nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication est prédéfini par au moins une licence d’exploitation du réseau de communication. Procédé selon l’une des revendications précédentes, dans lequel les étapes a) à c) sont mises en œuvre après acceptation d’une requête d’un terminal courant (UE1) de modification d’attribution d’un profil courant (P1) parmi les profils de service souscrits. Procédé selon l’une des revendications précédentes, dans lequel le premier message comprend en outre au moins une mise à jour d’une association entre : - un identifiant (IMSI1) d’un profil courant (P1) parmi les profils de service attribuables, - un identifiant (eUICC1) d’un terminal courant (UE1) parmi les terminaux de communication accédant au réseau, et - un identifiant (NID) du réseau de communication. Procédé selon l’une des revendications précédentes, dans lequel le second message comprend en outre une mise à jour d’une association entre : - un identifiant (IMSI1) d’un profil courant (P1) parmi les profils de service attribuables, - un identifiant (eUICC1) d’un terminal courant (UE1) parmi les terminaux de communication accédant au réseau, et - un identifiant (NID) du réseau de communication. Procédé selon l’une des revendications précédentes, dans lequel, à l’issue de l’étape c), le serveur de gestion (VNF-le) comporte une donnée signalant une anomalie si le premier nombre total (N_SM) de profils de service actifs sur le réseau de communication et le second nombre total (N_HSS) de profils de service actifs sur le réseau de communication ne sont pas égaux. Procédé selon la revendication 2, prise en combinaison avec l’une des revendications 3 à 8, dans lequel la gestion d’accès au service comprend en outre une comparaison du premier nombre total (N_SM) et/ou du second nombre total (N_HSS) de profils de service actifs sur le réseau de communication avec au moins le nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication. Procédé selon la revendication 9 prise en combinaison avec la revendication 4, dans lequel la licence d’exploitation est mise à jour si, à l’issue de la comparaison du premier nombre total (N_SM) et/ou du second nombre total (N_HSS) de profils de service actifs sur le réseau de communication avec le nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication, le premier nombre total (N_SM) et/ou le second nombre total (N_HSS) de profils de service actifs sur le réseau de communication ne correspond pas au nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication, ladite mise à jour de la licence d’exploitation consistant à modifier le nombre maximal (N_max) de profils de service activables simultanément sur le réseau de communication. Un serveur de gestion (VNF-le) d’un fournisseur d’une pluralité de services (MNO), ledit serveur de gestion (VNF-le) comportant au moins : - une unité mémoire (MEM), - un processeur (PROC), ledit serveur de gestion (VNF-le) étant adapté pour mettre en œuvre le procédé selon l’une des revendications 1 à 10. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 10 lorsque ce programme est exécuté par un processeur (PROC).