FR 3129506 A1 20230526 FR 2112458 A 20211124 Entité applicative ayant une architecture de micro-services, entité de contrôle et procédés mis en œuvre par ces entités L’invention concerne notamment une entité applicative (NFk) ayant une architecture de micro-services et proposant au moins un service dans un réseau, ladite entité applicative comprenant : - un module de gestion configuré pour signaler à une entité de contrôle (2) gérant une pluralité d’entités applicatives du réseau, au moins un événement affectant un profil de l’entité applicative enregistré ou destiné à être enregistré auprès de ladite entité de contrôle, ledit profil comprenant une pluralité d’attributs caractérisant ladite entité applicative ; et - un module de notification configuré pour notifier chaque événement signalé par le module de gestion à l’entité de contrôle à chaque micro-service de l’entité applicative, dit micro-service concerné, ayant souscrit auprès du module de notification à une notification dudit événement. Figure 1 Entité applicative ayant une architecture de micro-services, entité de contrôle et procédés mis en œuvre par ces entités L’invention appartient au domaine général des télécommunications. Elle concerne plus particulièrement les architectures logicielles de micro-services (aussi parfois désignée dans la suite par « architecture micro-service »). De façon connue en soi, une telle architecture est couramment utilisée dans le domaine du développement des applications logicielles. Elle consiste à décomposer une application pour en isoler les fonctions principales qui peuvent s’exécuter indépendamment les unes des autres. Ces fonctions principales, désignées par « services » ou « micro-services », peuvent alors avantageusement être développées et déployées séparément, bien que fonctionnant en synergie. La responsabilité et le nombre de micro-services dépendent des choix du concepteur de l’application. L’avantage d’une architecture de micro-services par rapport à une architecture monolithique classique selon laquelle tous les composants forment une entité indissociable, est que chaque micro-service peut fonctionner (ou dysfonctionner) sans affecter les autres, ce qui facilite la structuration et les interventions des équipes de développement et de maintenance/mise à jour de l’application. Les architectures de micro-services, en raison de la flexibilité de chaque micro-service, s’intègrent de façon privilégiée (mais non limitative) dans les environnements « cloud » connus pour leur agilité et offrant des ressources partagées évolutives. La coordination et la supervision des micro-services sont assurées en temps réel par un orchestrateur, qui surveille notamment la charge de chaque instance de micro-service (aussi communément désigné par « pod » en anglais). Lorsque la charge des pods relatifs à un micro-service dépasse un seuil donné, l’orchestrateur instancie un nouveau pod dans le but de répondre à l’accroissement de la charge. Inversement, l’orchestrateur supprime un pod lorsqu’il estime que la charge courante répartie sur tous les pods descend en dessous d’un certain seuil. Cela permet de réduire la consommation de ressources (ex. CPU (pour « Central Processing Unit » en anglais), mémoire, énergie, etc.). Ce mécanisme dynamique de création et de suppression de pods est aussi connu sous le nom de scalabilité ou élasticité horizontale. Le réseau cœur ou cœur de réseau 5G (ou de 5 ème Génération) défini par le standard 3GPP (ou « Third Generation Partnership Project » en anglais) est bien adapté aux environnements cloud et peut être conçu selon une architecture de micro-services. En effet, le réseau cœur 5G exploite des technologies de virtualisation de fonctions réseau (ou NFV pour « Network Function Virtualization » en anglais), de réseau défini par logiciel (ou SDN pour « Software Defined Networking » en anglais) et de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais. Ces technologies ouvrent des perspectives d’usage inédites des réseaux de télécommunications. Elles permettent notamment aux opérateurs de créer pour leurs clients des réseaux logiques virtuels de bout-en-bout, sur mesure et indépendants, évolutifs et agiles, et ce à partir d’une même infrastructure de réseau physique (réseau(x) d’accès, réseau cœur, etc.). Par le biais de ces réseaux logiques virtuels, les opérateurs sont capables de fournir à leurs clients des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service. La virtualisation de fonctions réseau ou NFV s’appuie sur des serveurs standards pour exécuter des logiciels de services réseau (aussi appelées fonctions réseau ou NF pour « Network Functions » en anglais), tandis que le réseau défini par logiciel ou SDN centralise le contrôle du réseau 5G par logiciel plutôt que via des équipements physiques. Grâce à cette virtualisation, les fonctions réseau peuvent être déployées et reconfigurées aisément, apportant ainsi plus d’élasticité. Diverses fonctions NF d’un réseau cœur 5G peuvent être ainsi virtualisées, comme par exemple les fonctions réseau de gestion de l’accès et de la mobilité ou AMF (pour « Access Mobility Management Function » en anglais), de gestion de session ou SMF (pour « Session Management Function » en anglais), de sélection de tranche réseau ou NSSF (pour « Network Slice Selection Function » en anglais), de contrôle des politiques ou PCF (pour « Policy Control Function » en anglais), etc. Le contrôle de ces fonctions virtualisées dans le réseau cœur 5G est assuré par une autre fonction réseau appelée catalogue de fonctions réseau ou NRF (ou « Network function Repository Function » en anglais). Cette fonction NRF est chargée de fournir à une fonction réseau cliente ou consommatrice (« consumer » en anglais) les informations lui permettant d’interagir, directement ou indirectement via un équipement intermédiaire (ou SCP pour « Service Communication Proxy » en anglais) avec une fonction réseau serveur (« producer » en anglais). Chaque fonction NF du réseau cœur 5G a un rôle et une logique qui lui sont propres. Elle fournit classiquement une pluralité de services au sein du réseau 5G à d’autres fonctions du réseau cœur autorisées à y accéder, chaque service ayant lui-même un rôle et une logique qui lui sont propres, et pouvant comporter une ou plusieurs ressources (par exemple des ressources REST pour « REpresentational State Transfer » en anglais). Il en découle qu’une architecture de micro-services est particulièrement bien adaptée pour la conception des fonctions NF d’un réseau 5G (à noter que le standard 3GPP n’impose aucune architecture logicielle spécifique). Différentes approches (pas nécessairement exclusives) peuvent être envisagées : un service tel que défini par les spécifications du standard 3GPP peut être vu comme un micro-service : l’orchestrateur instancie alors un nouveau pod pour répondre à une augmentation de charge ; un service tel que défini par les spécifications du standard 3GPP est décomposé selon ses ressources (ex. REST) ou selon des sous-ensembles de ressources en fonction de choix propres aux concepteurs des fonctions réseau. Selon cette approche, un service se définit comme une entité logique, et les services sont découpés en micro-services suivant leurs ressources (ex. REST) ou en des micro-services plus fins encore définis par les concepteurs. Ainsi, selon la première approche, le service complet constitue un micro-service et est répliqué le cas échéant (i.e. instanciation d’un nouveau pod). Conformément à la seconde approche, les micro-services sont potentiellement répliqués mais il n’est pas nécessaire de répliquer le service (c’est-à-dire l’entité logique). Les fonctions NF du réseau cœur 5G présentent les services qu’elles offrent dans le contexte du cœur de réseau 5G (autrement dit leurs fonctionnalités) par l’intermédiaire d’interfaces se présentant sous forme d’APIs (pour « Application Programming Interfaces » en anglais) que les autres fonctions NF autorisées peuvent invoquer. Toutefois, au lieu d’interfaces prédéfinies entre les différentes fonctions NF pouvant interagir entre elles, un modèle de service est utilisé dans lequel les fonctions NF « consumer » interrogent la fonction réseau NRF pour découvrir les fonctions NF « producer » et communiquer avec elles sur les APIs qu’elles offrent. Ceci offre avantageusement aux opérateurs des réseaux 5G une grande flexibilité et une grande adaptabilité. La fonction réseau NRF est ainsi un catalogue gérant une pluralité de fonctions NF, et mémorisant les profils de chacune de ces fonctions NF. Chaque profil (ou « NFProfile ») comprend une pluralité d’attributs, caractérisant l’état opérationnel de la fonction NF (ex. sa disponibilité, sa charge, depuis quand elle a démarré, etc.), ses caractéristiques (ex. son identifiant, son nom de domaine pleinement qualifié ou FQDN (pour « Fully Qualified Domain Name » en anglais)), type de fonction NF, comment elle peut être jointe, etc.), les services qu’elle offre, les ressources qu’elle gère, etc. Des attributs peuvent être définis également plus spécifiquement au niveau de chaque service (sinon ce sont ceux définis au niveau de la fonction NF qui s’appliquent). Ces profils permettent aux fonctions NF « consumer » de découvrir les fournisseurs de services et de caractéristiques particuliers dans le réseau. Toutes les fonctions NF doivent donc enregistrer leur profil auprès de la fonction NRF. Le rôle de la fonction NRF est alors : de maintenir les profils des fonctions NF disponibles et leurs services ; de permettre aux fonctions NF de s’abonner et d’être notifiées de tout événement susceptible d’affecter un profil d’une fonction NF auprès de la fonction NRF (création d’un nouveau profil, suppression et/ou mise à jour d’un profil enregistré auprès de la fonction NRF) ; et d’offrir un service de découverte permettant à une fonction NF de récupérer une liste des fonctions NF correspondant à certains critères afin de consommer un ou plusieurs services fournis par ces fonctions NF. Outre les informations concernant les profils des fonctions NF dont elle souhaite consommer certains services, une fonction NF peut être amenée à utiliser les informations contenues dans son propre profil pour diverses raisons, comme par exemple : pour fournir, conformément aux spécifications 3GPP la concernant, certaines informations (par exemple des informations que la fonction NF doit valoriser à partir de valeurs d’attributs de son profil) dans des requêtes qu’elle envoie à d’autres fonctions du réseau en tant que « consumer » ou dans des réponses à des requêtes qu’elle a reçues en tant que « producer » ; pour permettre des contrôles de sécurité : par exemple, on peut envisager qu’une fonction NF ne traite pas de requête incompatible avec son profil (ex. correspondant à une tranche du réseau dont la fonction NF n’est pas en charge) ; pour définir la valeur de certains entêtes, comme par exemple de l’entête « Location ». Dans ce contexte d’architecture de micro-services pouvant être potentiellement (massivement) répliqués, le problème qui se pose alors est comment s’assurer que la fonction NF dispose d’informations à jour sur son propre profil. Il convient de noter que certaines informations du profil de la fonction NF peuvent être modifiées du fait de l’intervention d’une entité tierce du réseau (comme une entité de gestion du réseau) sans que la fonction NF ne puisse déterminer elle-même que ces modifications aient eu lieu. En outre, l’architecture de micro-services fait qu’une modification apportée à un attribut lors d’un traitement de cet attribut par un micro-service n’est pas nécessairement visible d’un autre micro-service réalisant un autre traitement sur ce même attribut, les micro-services en question étant conçus pour s’exécuter de façon indépendante. Une solution, couramment utilisée par les opérateurs de réseau, consiste à redémarrer (de façon immédiate ou différée) la fonction NF suite à un changement affectant son profil. Toutefois, l’inconvénient de cette solution est qu’elle se traduit par une interruption momentanée de service, le temps que la fonction NF soit de nouveau opérationnelle. Une telle interruption peut être préjudiciable pour le réseau et engendrer des cas d’erreur durant la phase transitoire de redémarrage, y compris lorsque l’arrêt de la fonction NF se fait dans les règles de l’art (ex. extinction avec désenregistrement). Elle est d’autant plus préjudiciable dans un environnement assez dynamique dans lequel les attributs du profil de la fonction NF sont amenés à changer de façon fréquente (pour des besoins opérationnels, ou selon le contexte d’orchestration et de gestion du réseau, etc.). Il existe donc un besoin d’une solution ne présentant pas cet inconvénient et permettant à une fonction NF de disposer de façon (quasi)-immédiate d’informations à jour sur son profil. Il convient de noter que ce besoin, bien qu’illustré dans le contexte d’un réseau cœur 5G et d’une fonction réseau, peut également exister dans d’autres contextes (ex. réseaux ad hoc, pair-à-pair (ou P2P pour « peer-to-peer » en anglais), etc.) dans lesquels on considère des entités applicatives aptes à fournir un ou plusieurs services, conçues sur la base d’une architecture de micro-services, intégrées par exemple dans un environnement de type cloud. L’invention répond notamment au besoin évoqué ci-avant en proposant une entité applicative ayant une architecture de micro-services et proposant au moins un service dans un réseau, ladite entité applicative comprenant : un module de gestion configuré pour signaler à une entité de contrôle gérant une pluralité d’entités applicatives du réseau, au moins un événement affectant un profil de l’entité applicative enregistré ou destiné à être enregistré auprès de ladite entité de contrôle, ledit profil comprenant une pluralité d’attributs caractérisant ladite entité applicative ; et un module de notification configuré pour notifier chaque événement signalé par le module de gestion à l’entité de contrôle à chaque micro-service de l’entité applicative, dit micro-service concerné, ayant souscrit auprès du module de notification à une notification dudit événement. Corrélativement, l’invention concerne aussi un procédé de notification destiné à être mis en œuvre par une entité applicative ayant une architecture micro-services et proposant au moins un service dans un réseau, ledit procédé comprenant : au moins une étape de signalement à une entité de contrôle gérant une pluralité d’entités applicatives du réseau, au moins un événement affectant un profil de l’entité applicative enregistré ou destiné à être enregistré auprès de ladite entité de contrôle, ledit profil comprenant une pluralité d’attributs caractérisant ladite entité applicative ; et une étape de notification de chaque événement signalé par le module de gestion à l’entité de contrôle à chaque micro-service de l’entité applicative ayant souscrit auprès du module de notification à une notification dudit événement. Aucune limitation n’est attachée à la nature de l’entité applicative. Par entité applicative, on entend ici toute entité communicante virtuelle ou logicielle (aussi appelée entité de communication ici), configurée pour mettre en œuvre une logique de traitement déterminée, comme par exemple une entité offrant et/ou consommant des services dans un réseau telle qu’une fonction réseau ou une instance de fonction réseau, etc., et conçue selon une architecture de micro-services. On note qu’une entité applicative peut être une entité de réseau (i.e. qui a une fonctionnalité donnée dans un réseau), mais il peut s’agir également d’un équipement situé en bordure de réseau (à l’ « edge » en anglais) ou d’un équipement utilisateur (ou UE pour « User Equipment » en anglais). Ainsi l’invention propose une solution s’appuyant d’une part sur le signalement par l’entité applicative à l’entité de contrôle à laquelle elle est rattachée, de tout événement qu’elle détecte affectant son profil, et d’autre part, sur la notification de ces événements aux micro-services de l’entité applicative qui se sont déclarés intéressés par ceux-ci (typiquement les micro-services portant des traitements associés à tout ou partie des attributs contenus dans le profil de l’entité applicative). Un tel événement est par exemple la création, la modification, ou la suppression du profil de l’entité applicative, ou la création, la modification, ou la suppression d’un ou de plusieurs attributs de ce profil. En d’autres mots, l’invention permet une mise à jour dynamique du profil de l’entité applicative auprès de l’entité de contrôle et au sein des micro-services qui la composent. Cette disponibilité en temps réel des informations relatives aux événements affectant le profil de l’entité applicative au niveau de l’entité de contrôle mais également au niveau des micro-services de l’entité applicative est avantageusement réalisée sans interruption de service. Il en résulte une meilleure gestion de ces événements au niveau de l’entité applicative et une possibilité d’intégrer dans chaque micro-service concerné les changements relatifs à ces événements, tout en évitant une interruption de service qui peut s’avérer préjudiciable pour le fonctionnement du réseau. La solution offerte par l’invention est donc particulièrement bien adaptée dans un environnement évolutif et élastique (ou « scalable » en anglais) tel que le sont les environnements de type cloud et les réseaux 5G. Elle permet d’intégrer de façon simple et efficace une mise à jour dynamique des attributs d’un profil d’une entité applicative (ex. priorité, charge, adresses IP/ports, etc.) pour quelques raisons que ce soit (besoins opérationnels, fonctionnement du réseau, mise à jour des attributs par une entité de gestion du réseau, etc.), et quelle que soit la fréquence des modifications apportées à ce profil. Divers choix d’implémentation de l’invention peuvent être faits. Par exemple, dans un mode particulier de réalisation, le module de gestion est configuré en outre pour enregistrer le profil de l’entité applicative auprès de l’entité de contrôle. On peut envisager que le module de gestion soit implémenté sous la forme d’un micro-service chargé de toute la logique de l’entité applicative avec l’entité de contrôle incluant, outre le signalement et l’enregistrement précités, d’autres opérations telles que le désenregistrement de l’entité applicative, l’envoi de messages de présence (ou « heart beat » en anglais), etc. On note que ce micro-service n’a pas a priori vocation à être répliqué au niveau de l’entité applicative. On peut toutefois, dans un contexte de haute disponibilité, envisager de répliquer ce micro-service en une instance « maître » et une instance « esclave ». Dans un mode de réalisation, le module de notification de l’entité applicative est implémenté sous la forme d’un micro-service de traitement en temps réel de flux d’événements aussi connu sous l’appellation de « event streaming » en anglais. L’implémentation d’un tel micro-service permet de faciliter la mise en œuvre de l’invention. Cela permet par exemple d’exploiter des modules existants tels que notamment le module Apache Kafka ou encore le module Redis Streams. On peut envisager différentes options pour rendre disponibles (ou de façon équivalente publier) auprès du module de notification les différents événements affectant le profil de l’entité applicative signalés à l’entité de contrôle, afin que le module de notification soit en mesure d’en informer ensuite les micro-services concernés de l’entité applicative (c’est-à-dire ceux ayant souscrit à la notification de ces événements). Ainsi, selon une première option de réalisation de l’invention, le module de gestion est configuré pour souscrire auprès de l’entité de contrôle à une notification de l’entité applicative d’au moins un événement affectant son profil auprès de l’entité de contrôle, le module de notification de l’entité applicative étant alors configuré pour notifier chaque événement notifié par l’entité de contrôle à chaque micro-service de l’entité applicative, dit micro-service concerné, ayant souscrit auprès du module de notification à une notification de cet événement. En d’autres mots, l’entité applicative souscrit auprès de l’entité de contrôle à la notification des événements affectant son propre profil (typiquement à la notification de ces événements auprès de son module de notification), ce qui permet aux micro-services ayant souscrit auprès du module de notification de l’entité applicative d’être informés à leur tour de ces événements (désignés aussi par micro-services concernés). Préférentiellement, la souscription de l’entité applicative auprès de l’entité de contrôle a lieu dès le démarrage de l’entité applicative afin de ne pas manquer d’événements. L’invention permet, selon cette option, de signaler aux micro-services des modifications affectant le profil de l’entité applicative dues à l’entité applicative elle-même ou à des entités tierces, comme par exemple à une entité des opérations, de la gestion et de l’administration du réseau connue en soi, aussi désignée par entité OAM (pour « Operations, Administration and Maintenance » en anglais), à laquelle est rattachée l’entité applicative et/ou l’entité de contrôle. Ce mode de fonctionnement est novateur et particulièrement astucieux. Dans l’état de l’art en effet, une entité applicative souscrit uniquement aux événements relatifs à d’autres entités applicatives dont elle entend consommer les services. L’invention propose d’exploiter le système de notification d’événements existant au niveau de l’entité de contrôle pour permettre aux micro-services de l’entité applicative d’être informés en temps réel, de façon relativement simple et homogène, des modifications apportées dynamiquement au profil de l’entité applicative, indépendamment de l’origine de ces modifications (autres micro-services de l’entité applicative ou entités tierces). En outre, cette première option de réalisation offre la possibilité de mettre en place des opérations de contrôle du bon fonctionnement de l’entité de contrôle, et en particulier de sa fonctionnalité de notification. En effet, si une mise à jour du profil auprès de l’entité de contrôle n’est pas suivie de la réception de la notification associée par l’entité applicative, on peut alors supposer qu’il existe un dysfonctionnement dans la chaîne des notifications à partir de l’entité de contrôle impactant la chaîne de diffusion des notifications jusqu’aux micro-services concernés de l’entité applicative. On peut envisager que le module de gestion de l’entité applicative remonte une alarme au niveau de l’entité de contrôle ou d’une entité gérant cette dernière comme par exemple une entité OAM telle qu’évoquée ci-avant. D’autres opérations pouvant être mises en place grâce à la première option de réalisation sont décrites ultérieurement. Dans un mode particulier de réalisation, le module de gestion est configuré pour souscrire auprès de l’entité de contrôle à ladite notification avant d’enregistrer auprès de l’entité de contrôle le profil de l’entité applicative. A cet effet, le module de gestion de l’entité applicative considérée peut par exemple souscrire à la notification des évènements relatifs aux entités applicatives gérées par l’entité de contrôle assurant la même fonctionnalité (ex. même fonction réseau) que ladite entité applicative. De cette sorte, l’entité applicative est notifiée de la version initiale de son profil (ou « profil initial ») enregistré auprès de l’entité de contrôle. La connaissance de ce profil initial par l’entité applicative peut s’avérer utile pour reconstruire le profil courant de l’entité applicative lorsqu’elle est notifiée d’un événement. En effet, en fonction de règles internes, l’entité de contrôle peut notifier des modifications apportées à un profil en envoyant le profil complet incluant lesdites modifications (par exemple dans le cas de l’enregistrement d’un nouveau profil) ou, si seulement quelques modifications sont apportées à un profil déjà enregistré auprès de l’entité de contrôle (ex. ajout ou suppression d’un attribut, etc.), notifier ces modifications sous la forme d’une série d’opérations de transformation conduisant à celles-ci, notamment pour économiser la bande passante. Dans ce cas, le module de notification a besoin de connaître le profil de l’entité applicative sur lequel ont été appliquées ces modifications pour reconstituer le profil courant de l’entité applicative afin de le notifier aux micro-services concernés. Il convient de noter que ce profil initial est normalement connu de l’entité applicative dès lors qu’elle l’enregistre elle-même via le module de gestion auprès de l’entité de contrôle. Toutefois, selon les choix d’implémentation qui sont faits pour l’entité applicative, le module de gestion et le module de notification peuvent être conçus comme deux micro-services distincts opérant de façon indépendante et ne communiquant pas entre eux. Ce mode de réalisation permet au module de notification d’obtenir le profil initial en bénéficiant des notifications de l’entité de contrôle. Dans un mode particulier de réalisation : au moins un événement affectant le profil de l’entité applicative notifié par l’entité de contrôle comprend un changement d’au moins un attribut dudit profil, dit profil précédent, et est notifié sous la forme d’au moins une opération de transformation conduisant audit changement ; ladite entité applicative comprend un module de traitement configuré pour obtenir un profil courant de l’entité applicative en appliquant ladite au moins une opération de transformation audit profil précédent et fournir le profil courant au module de notification, les notifications du module de notification aux micro-services concernés de l’entité applicative comprenant ledit profil courant. Ce mode de réalisation a une application privilégiée lorsque l’événement en question est par exemple une modification d’un nombre réduit d’attributs du profil (ajout, suppression ou changement d’une valeur d’un nombre réduit d’attributs). Il convient de noter que le mode de notification adopté par l’entité de contrôle (profil complet ou série d’opérations de transformation) peut être laissé à la liberté de l’entité de contrôle (ex. en fonction de règles internes) et/ou être amené à évoluer dans le temps et/ou en fonction des événements considérés. Dans un mode particulier de réalisation, le module de traitement est configuré pour mémoriser le profil courant. En cas de nouvel événement notifié par l’entité de contrôle sous la forme d’une série d’opérations de transformation, l’entité de traitement peut utiliser le profil courant obtenu lors de l’événement précédemment notifié comme profil précédent de l’entité applicative et lui appliquer les opérations de transformation pour reconstituer le profil courant de l’entité applicative qu’il convient de transmettre aux micro-services concernés. Comme évoqué précédemment, dans la première option de réalisation envisagée ici, l’entité applicative peut être notifiée d’événements affectant son profil du fait de changements internes à l’entité applicative, mais également d’événements liés à une intervention externe. Ainsi, dans un mode particulier de réalisation, au moins un événement affectant le profil de l’entité applicative notifié par l’entité de contrôle comprend un changement d’au moins un attribut du profil de l’entité applicative par l’entité de contrôle ou signalé à l’entité de contrôle par une entité tierce du réseau. Une telle entité tierce peut être par exemple une entité des opérations, de la gestion et de l’administration du réseau ou OAM comme indiqué précédemment. Ce type d’intervention par une entité tierce sur le profil de l’entité applicative n’est, dans l’état de la technique, pas directement visible par l’entité applicative et nécessite un redémarrage de celle-ci pour la prise en compte des attributs modifiés par l’entité tierce. L’invention permet avantageusement de pouvoir intégrer dynamiquement et en temps réel ces modifications dans le fonctionnement des micro-services, et donc de l’entité applicative, sans avoir besoin de la redémarrer. De même, ce mode de réalisation permet d’informer l’entité applicative de changements opérés sur son profil par l’entité de contrôle. Un tel changement est par exemple le passage de la valeur d’un attribut définissant l’état de l’entité applicative d’ « enregistré » à « suspendu ». La notification de l’entité applicative de ce changement permet de mettre en œuvre au niveau de l’entité applicative une logique spécifique visant à rétablir l’état « enregistré » de l’entité applicative, par exemple en envoyant des messages de présence (« Heart-Beat ») si le contexte d’exécution de l’entité applicative le permet. Dans la première option de réalisation qui vient d’être décrite, l’entité applicative souscrit auprès de l’entité de contrôle aux événements reportés à l’entité de contrôle affectant son propre profil. Selon une seconde option de réalisation de l’invention, la publication des événements affectant l’entité applicative est réalisée sans intervention extérieure, de façon interne à l’entité applicative. Ainsi, selon cette seconde option, le module de gestion est configuré pour informer le module de notification dudit au moins un événement après son signalement auprès de l’entité de contrôle. Cette seconde option offre la possibilité d’échanger une quantité plus importante d’informations entre le module de gestion et le module de notification, en exploitant un lien de communication interne à l’entité applicative. Elle présente toutefois l’inconvénient que l’entité applicative ne peut être informée de modifications de son profil dues à l’intervention d’une entité tierce comme par exemple une entité OAM ou à l’entité de contrôle même. Comme il apparaît dans ce qui vient d’être décrit, la première option de réalisation de l’invention s’appuie non seulement sur l’entité applicative, mais également sur l’entité de contrôle. Ainsi l’invention vise également une entité de contrôle gérant une pluralité d’entités applicatives d’un réseau, chaque entité applicative étant associée à un profil mémorisé par l’entité de contrôle comprenant une pluralité d’attributs caractérisant ladite entité applicative, ladite entité de contrôle comprenant : un module d’enregistrement, configuré pour enregistrer au moins une souscription d’une dite entité applicative à une notification d’au moins un événement affectant son profil ; et un module de notification, configuré pour envoyer une notification à ladite entité applicative lors que l’entité de contrôle détecte ledit événement. Corrélativement, l’invention vise aussi un procédé de gestion par une entité de contrôle d’une pluralité d’entités applicatives d’un réseau, chaque entité applicative étant associée à un profil mémorisé par l’entité de contrôle comprenant une pluralité d’attributs caractérisant ladite entité applicative, ledit procédé de gestion comprenant : une étape d’enregistrement d’au moins une souscription d’une dite entité applicative à une notification d’au moins un événement affectant son profil ; et une étape de notification de ladite entité applicative lorsque l’entité de contrôle détecte ledit événement. Comme mentionné précédemment, dans un mode de réalisation, au moins un dit événement affectant le profil de l’entité applicative est signalé par ladite entité applicative ou par une entité tierce du réseau ou est dû à l’entité de contrôle. L’entité de contrôle et le procédé de gestion selon l’invention bénéficient des mêmes avantages évoqués ci-avant pour l’entité applicative et le procédé de notification. Dans un mode particulier de réalisation, les procédés de gestion et de notification sont mis en œuvre par un ordinateur. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité applicative conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de notification tel que décrit ci-dessus. L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans une entité de contrôle conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de gestion tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash. D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion, d’enregistrement et de communication selon l’invention. Selon un autre aspect encore, l’invention vise un système d’un réseau comprenant une pluralité d’entités applicatives dudit réseau conformes à l’invention et une entité de contrôle gérant ladite pluralité d’entités applicatives. Dans un mode particulier de réalisation, cette entité de contrôle est conforme à l’invention. Le système bénéficie des mêmes avantages cités précédemment que les procédés de notification et de gestion, l’entité applicative et l’entité de contrôle selon l’invention. On peut également envisager, dans d'autres modes de réalisation, que les procédés de notification et de gestion, et les entités applicative et de contrôle selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la représente, dans son environnement, un système dans un réseau conforme à l’invention, dans un premier mode de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger l’une quelconque des entités selon l’invention appartenant au système de la ; la représente les modules fonctionnels d’une entité applicative conforme au premier mode de réalisation de l’invention du système de la ; la représente les modules fonctionnels d’une entité de contrôle conforme au premier mode de réalisation de l’invention du système de la ; ; les figures 5 et 6 représentent les principales étapes d’un procédé de notification et d’un procédé de gestion selon l’invention telles qu’elles sont mises en œuvre dans le premier mode par les entités du système de la ; la représente, dans son environnement, un système dans un réseau conforme à l’invention, dans un deuxième mode de réalisation ; la représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger une entité applicative appartenant au système de la , selon le deuxième mode de réalisation de l’invention ; la représente les modules fonctionnels d’une entité applicative appartenant au système de la , selon le deuxième mode de réalisation de l’invention ; la représente les principales étapes d’un procédé de notification selon le deuxième mode de réalisation de l’invention telles qu’elles sont mises en œuvre par l’entité applicative de la . Description de l’invention Préliminaires Nous allons maintenant décrire plus en détail l’invention dans deux modes de réalisation basés respectivement sur les deux options introduites ci-avant. Pour illustrer ces deux modes de réalisation, on considère un réseau cœur CN d’un réseau de communications 5G tel que défini par le standard 3GPP. Ce réseau cœur CN comprend une pluralité d’entités applicatives, qui sont ici des instances de fonctions réseau proposant chacune un ou plusieurs services dans le réseau cœur CN, telles que par exemple des fonctions réseau AMF, SMF, NSSF, PCF, etc. Par souci de simplification, les instances de fonctions réseau considérées sont ici toutes des instances virtualisées, autrement dit des entités logicielles, qui exécutent diverses logiques de service permettant d’assurer les principales fonctions du réseau cœur CN (ex. gestion de la mobilité et de l’accès au réseau cœur, définition et application de politiques réseau, facturation, sélection de tranches réseau, etc.). On suppose que ces entités logicielles sont conçues sur la base d’une architecture de micro-services, telle qu’introduite précédemment. Chaque service exécuté par une entité applicative peut comprendre une ou plusieurs opérations, et être conçu lui-même selon différents types d’architecture. Ainsi, à titre illustratif mais nullement limitatif, on considère plus spécifiquement ici qu’une entité applicative comprend au moins deux services Xk et Yk tels que : le service Xk est un micro-service qui peut, à ce titre, être répliqué, par exemple sous le contrôle d’un orchestrateur du réseau cœur CN comme évoqué ci-avant ; et le service Yk est une entité logique composée d’une pluralité de micro-services, chacun d’entre eux pouvant être répliqué, également sous le contrôle dudit orchestrateur. La réplication du service Yk n’est toutefois pas nécessaire. Chaque entité applicative s’appuie donc sur une pluralité de micro-services. Les entités applicatives considérées ici sont gérées par une entité de contrôle, qui est également ici une entité logicielle. Dans l’exemple envisagé ici d’un réseau cœur 5G, cette entité de contrôle est une fonction réseau NRF virtualisée, autrement dit un catalogue mémorisant pour chacune des entités applicatives, un profil. Chaque profil mémorisé comprend une pluralité d’attributs, caractérisant l’état opérationnel de l’entité applicative associée (ex. sa disponibilité, sa priorité par rapport aux autres entités applicatives de même type (ex. assurant la même fonction réseau dans l’exemple envisagé ici), sa charge, sa capacité, depuis quand elle a démarré, etc.), ses caractéristiques (ex. son identifiant, son nom de domaine pleinement qualifié ou FQDN (pour « Fully Qualified Domain Name » en anglais), type de fonction NF, comment elle peut être jointe (adresse(s) IP, port(s)), etc.), les services qu’elle offre (ex. Xk et Yk ici, et les priorités associées aux services), les ressources qu’elle gère, etc. Des attributs peuvent en outre être définis par service offert par l’entité applicative considérée (autrement dit, des attributs spécifiques au service Xk et/ou au service Yk dans l’exemple envisagé ici). Il convient toutefois de noter que chaque service (ex. Xk et Yk ici) offert par une entité applicative n’est défini qu’une seule fois dans son profil. Certains des attributs du profil d’une entité applicative sont susceptibles d’être modifiés en fonction de l’évolution de l’architecture de micro-services sur laquelle s’appuie l’entité applicative en question : ainsi par exemple, si l’orchestrateur instancie de nouveaux pods pour un micro-service de l’entité applicative (autrement dit réplique le micro-service en question), la charge de l’entité applicative peut évoluer, et de nouvelles adresses IP/ports peuvent être alloués à cette entité applicative. Selon d’autres exemples, l’entité de contrôle NRF peut changer l’attribut relatif à la priorité, et une entité de gestion du réseau de type OAM peut modifier la capacité de l’entité applicative (i.e. la réduire ou l’augmenter). Certains attributs du profil peuvent être également modifiés en fonction de l’évolution de l’architecture logique du réseau cœur CN, pilotée par exemple par une entité OAM telle que présentée précédemment. Cette architecture logique conditionne en effet le comportement fonctionnel de l’entité applicative (ex. ajout/suppression de tranches de réseau, etc.) et la valeur des attributs correspondants qui lui sont associés. Selon un autre exemple encore, c’est un micro-service de l’entité applicative qui peut être amené à modifier un attribut du profil de l’entité applicative qu’il traite. Quoiqu’il en soit, comme évoqué précédemment, il est important que chaque micro-service d’une entité applicative amené à traiter un ou plusieurs attributs de son profil ait à sa disposition la valeur courante de ce ou ces attributs. Un tel traitement peut consister par exemple en la fourniture de la valeur de ce ou ces attributs à d’autres entités applicatives. Ainsi, citons à titre illustratif dans le contexte d’un réseau 5G, l’opération PostSmContext du service Nsmf_PDUSession offert par la fonction réseau SMF en tant que « producer » à la fonction réseau AMF en tant que « consumer » et dont certains paramètres de la requête de service doivent être valorisés par la fonction réseau AMF à partir d’attributs de son profil. Plus spécifiquement, ce service s’appuie sur des attributs de type SmContextCreateData (et en particulier sur les attributs servingNfId et servingName) dont les valeurs proviennent du profil de la fonction réseau AMF, et qui sont ensuite utilisés par la fonction réseau SMF lorsqu’elle consomme le service Namf_Communication fourni par la fonction réseau AMF. La même logique s’applique au service Nsmf_PDUSession offert par la fonction réseau SMF qui doit valoriser dans sa réponse d’acceptation à la requête de service les attributs smfServiceInstanceId et recoveryTime à partir d’attributs de son profil et plus précisément des attributs de son service Nsmf_PDUSession . Cet exemple illustre bien qu’il existe un lien entre le service « consumer » Namf_Communication de la fonction réseau AMF et le service « producer » Nsmf_PDUSession de la fonction réseau SMF établi lors du traitement par la fonction réseau SMF de l’opération PostSmContext . Ce lien permet à l’une et l’autre partie de retrouver son « interlocuteur » pour d’autres traitements où ce lien est important. Par exemple, comme représenté notamment à la .3.2.2.1-1 du document TS 23.502 intitulé « Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 16) », v16.9.0, septembre 2021, cette opération PostSmContext entraîne un traitement asynchrone du côté de la fonction réseau SMF « producer ». A la fin de ce traitement (« potentiellement long »), la fonction réseau SMF « producer » informe spécifiquement la fonction réseau AMF « consumer » qui a initié ce traitement grâce aux attributs décrits dans le type SmContextCreateData du statut de ce traitement via une opération spécifique (opération N1N2MessageTransfer du service Namf_Communication). Un autre cas d’usage de ces attributs est par exemple le mécanisme d’association (ou « binding » en anglais) décrit notamment dans le document TS 29.500 (au paragraphe 6.12), lorsque les fonctions réseau AMF et SMF inversent leurs rôles de « consumer » et de « producer » pour le même contexte. Une indication d’association (ou « binding indication » en anglais) peut alors être fournie dans la requête de service du service « consumer » initial, comprenant l’un au moins des attributs suivants : NF Instance ID , NF Service Instance ID, NF Set ID ou NF Service Set ID qui typiquement peuvent être obtenus à partir du propre profil du service « consumer » initial. L’entité de contrôle NRF propose elle-même une pluralité de services comprenant notamment des services de découverte, de gestion (incluant les opérations d’enregistrement/désenregistrement/mise à jour), et d’amorçage, qui reprennent par exemple respectivement la logique des services Nnrf_NFDiscovery, Nnrf_NFManagement et Nnrf_Boostrapping décrits notamment dans les documents 3GPP TS 23.502 cité précédemment et TS 29.510 intitulé « Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 », v16.9.0, septembre 2021. Dans l’exemple envisagé ici, les entités applicatives considérées et l’entité de contrôle NRF sont telles que définies dans le standard 3GPP (et les spécifications idoines selon les fonctionnalités offertes par les entités applicatives, ainsi que le document de spécification TS 29.510 pour l’entité de contrôle NRF), à l’exception des ajustements nécessaires pour la mise en œuvre de l’invention décrits ci-après. Les hypothèses précédentes sont données à titre purement illustratif et ne sont pas limitatives en soi. On peut envisager d’appliquer l’invention dans d’autres contextes qu’un réseau cœur 5G (ex. environnement cloud), à d’autres entités applicatives que des fonctions réseau, exécutant un nombre différent de services, ceux-ci pouvant être conçus selon l’une ou l’autre des architectures exposées ci-avant, et à une autre entité de contrôle qu’une fonction NRF en fonction du contexte envisagé. En outre, l’invention s’applique également dans d’autres configurations dans lesquelles seulement certaines des entités applicatives considérées (au moins une) sont des entités virtualisées ayant une architecture de micro-services, les autres entités applicatives pouvant s’appuyer sur une architecture monolithique ou être des entités applicatives physiques. Premier mode de réalisation Sur la base du contexte préliminaire qui vient d’être introduit, la représente, dans son environnement, un système 1 d’un réseau, conforme à l’invention, dans un premier mode de réalisation de l’invention. Le système 1 comprend : des entités applicatives NF1,…,NFN telles qu’évoquées en préliminaire, qui sont conformes au premier mode de réalisation de l’invention ; et une entité de contrôle NRF telle qu’évoquée en préliminaire, conforme au premier mode de réalisation de l’invention, et référencée par 2. Comme indiqué précédemment, les entités du système 1 (entités NF1,…,NFN et entité NRF 2) sont des entités logicielles, conçues selon une architecture de micro-services, et hébergées par des dispositifs physiques du réseau cœur CN, comme par exemple des serveurs. Ces serveurs ont l’architecture matérielle d’un ordinateur 3, telle que représentée schématiquement sur la . L’ordinateur 3 comprend notamment un processeur 4, une mémoire vive 5, une mémoire morte 6, une mémoire non volatile 7, et des moyens de communication 8 permettant notamment aux entités du système 1 de communiquer entre elles et avec d’autres éléments le cas échéant du réseau cœur CN ou d’un autre réseau, par exemple, en référence à la , avec une entité OAM 9 d’opérations, d’administration et de maintenance, déjà évoquée précédemment. On note que par souci de simplification sur la , une seule entité OAM est représentée, toutefois, selon les choix d’implémentation retenus par l’opérateur du réseau cœur CN et des concepteurs des entités du système 1, plusieurs entités OAM peuvent être considérées. Les moyens de communication 8 s’appuient d’une part, sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles basées sur le service ou SBI. Ces interfaces logicielles sont des APIs (pour « Application Programming Interfaces » en anglais) qui utilisent ici le protocole HTTP/2. La mémoire morte 6 de l’ordinateur 3 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 4 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention. Plus spécifiquement, la mémoire morte 6 de l’ordinateur 3 comprend, lorsque ce dernier héberge une entité applicative NFk, k=1,…,N conforme à l’invention, un enregistrement d’un programme d’ordinateur PROG-NFk, comportant des instructions définissant les principales étapes d’un procédé de notification selon le premier mode de réalisation de l’invention. Ce programme PROG-NFk définit des modules fonctionnels de l’entité applicative NFk, k=1,…,N qui s’appuient ou commandent les éléments matériels 4 à 8 de l’ordinateur 3 cités précédemment. Ces modules comprennent notamment dans le premier mode de réalisation, comme illustré sur la : un module (ou agent) de gestion NFk-A comprenant ici : un sous-module NFinst-MNGR de gestion des instances des services Xk et Yk, configuré pour signaler à l’entité de contrôle NRF 2 gérant les entités applicatives NF1,…,NFN, tout événement affectant le profil, noté NF_PROFk, de l’entité applicative NFk. Un tel événement peut être l’enregistrement (ou de façon équivalente, la création) du profil NF_PROFk auprès de l’entité de contrôle NRF 2, une modification apportée à ce profil (création, changements ou suppression d’un ou plusieurs attributs), ou encore un désenregistrement (ou de façon équivalente une suppression) du profil NF_PROFk enregistré auprès de l’entité de contrôle NRF 2 ; et un sous-module SUBS-MNGR de gestion de souscription, configuré pour souscrire auprès de l’entité de contrôle NRF 2 à une notification des événements affectant le profil NF_PROFk de l’entité applicative NFk enregistré auprès cette dernière. Dans le premier mode de réalisation décrit ici, cette souscription est réalisée par le sous-module SUBS-MNGR avant l’enregistrement par le sous-module NFinst-MNGR du profil NF_PROFk auprès de l’entité de contrôle NRF 2. En outre, le sous-module SUBS-MNGR souscrit ici à tous les événements susceptibles d’affecter son profil auprès de l’entité de contrôle NRF 2 ; toutefois, en variante, on peut envisager qu’il ne souscrive qu’à des événements spécifiques (par exemple aux événements concernant un service donné fourni par l’entité applicative NFk). On note que le sous-module SUBS-MNGR de gestion de souscription peut en outre être configuré pour mettre en œuvre d’autres opérations afférentes à la souscription ainsi créée auprès de l’entité de contrôle NRF 2. En particulier, si la souscription en question a une durée ou une date de validité, il peut être configuré pour régulièrement mettre à jour cette durée ou cette date de validité auprès de l’entité de contrôle NRF 2 afin que la souscription n’expire pas ; un module de réception NFk-B, configuré pour recevoir les notifications d’événements émises par l’entité de contrôle NRF 2 correspondant à la souscription du sous-module SUBS-MNGR. Ces notifications peuvent prendre différentes formes, à la discrétion de l’entité de contrôle NRF 2. Elles peuvent en particulier comprendre le profil de l’entité applicative NFk dans son intégralité, incluant le ou les changements correspondant aux événements notifiés, ou seulement une ou plusieurs opérations de transformation qui, appliquées à la version précédente du profil de l’entité applicative, traduisent ce ou ces changements. Pour pouvoir gérer ce deuxième cas de figure, le module de réception NFk_B est configuré pour obtenir et mémoriser un profil courant (c’est-à-dire à jour) de l’entité applicative NFk en appliquant la ou les opérations de transformation au profil précédent de l’entité applicative NFk (le module de réception est ainsi un module de traitement au sens de l’invention). Lorsqu’il reçoit une nouvelle notification d’événement, le module de réception NFk-B récupère le profil mémorisé et s’en sert de profil précédent pour appliquer l’opération ou les opérations de transformation incluses le cas échéant dans la nouvelle notification. Il convient de noter que s’il ne dispose pas de profil en mémoire (typiquement au démarrage de l’entité applicative NFk ou du module de réception NFk-B), le module de réception NFk-B peut récupérer directement le profil courant auprès de l’entité de contrôle NRF 2 comme décrit plus en détail ultérieurement ; et un module de notification NFk-C, configuré pour notifier chaque événement signalé par l’entité de contrôle NRF 2 et reçu par le module de réception NFk-B à chaque micro-service de l’entité applicative NFk, dit micro-service concerné, ayant souscrit préalablement auprès du module de notification NFk-C à une notification de cet événement. La souscription des micro-services de l’entité applicative NFk auprès du module de notification NFk-C ne pose pas de difficulté en soi pour l’homme du métier et dépend de l’implémentation retenue pour le module de notification. Dans le premier mode de réalisation envisagé ici, seuls les micro-services portant un traitement sur un ou plusieurs attributs du profil de l’entité applicative NFk souscrivent aux notifications des événements affectant ce profil. En outre, on peut envisager qu’un micro-service ne souscrive qu’à la notification d’événements affectant le ou les attributs du profil le concernant. Chaque événement est notifié ici par le module de notification NFk-C aux micro-services concernés sous la forme du profil courant complet NF_PROFk de l’entité applicative NFk intégrant le(s) changement(s) correspondant à cet événement. Ce profil courant est reçu par le module de notification NFk-C du module de réception NFk-B. Dans le mode de réalisation décrit ici, le module de notification NFk-C est conçu comme un micro-service de traitement en temps réel de flux d’événements ou event-stream en anglais. Des exemples d’un tel micro-service sont par exemple les micro-services Apache Kafka et Redis Streams. On note que les micro-services de l’entité applicative NFk peuvent être configurés pour ne souscrire qu’à des événements spécifiques affectant le profil NF_PROFk de l’entité applicative NFk en fonction notamment de la fonctionnalité qu’ils exécutent (ex. affectant des attributs particuliers du profil, et/ou le service auquel ils sont rattachés dans l’exemple du service Yk). On note que dans le premier mode de réalisation décrit ici, les communications au sein de l’entité applicative NFk entre ses différents modules et sous-modules logiciels s’appuient sur le protocole HTTP/2. Toutefois cette hypothèse n’est pas limitative en soi, et d’autres protocoles de communication peuvent être envisagés, comme par exemple les protocoles QUIC, RPC (pour « Remote Procedure Call » en anglais), CORBA, etc. Par ailleurs, dans le premier mode de réalisation décrit ici, on a envisagé trois modules distincts (NFk-A, NFk-B, NFk-C) ; toutefois, ceci relève de choix d’implémentation de l’invention (par exemple trois micro-services reprenant respectivement la logique fonctionnelle de ces trois modules), et en variante, on peut envisager un autre choix d’implémentation de l’invention (par exemple, le module de notification embarquant le module de réception). Lorsque l’ordinateur 3 héberge une entité de contrôle NRF 2 conforme à l’invention, sa mémoire morte 6 comprend un enregistrement d’un programme d’ordinateur PROG-2, comportant des instructions définissant les principales étapes d’un procédé de gestion selon le premier mode de réalisation de l’invention. Ce programme PROG-2 définit des modules fonctionnels de l’entité de contrôle NRF 2 qui s’appuient ou commandent les éléments matériels 4 à 8 de l’ordinateur 3 cités précédemment. Ces modules comprennent notamment dans le premier mode de réalisation, comme illustré sur la : un module de réception 2-A, configuré pour recevoir d’entités du réseau, des signalements d’événements affectant les profils des entités applicatives que l’entité de contrôle NRF 2 gère. Un tel événement, comme indiqué précédemment, peut être un enregistrement (i.e. une création) d’un profil d’une entité applicative, une modification d’un profil existant mémorisé auprès de l’entité de contrôle NRF 2 (ex. un ajout, un changement et/ou une suppression d’un ou de plusieurs attributs) ou encore une suppression d’un profil existant mémorisé auprès de l’entité de contrôle NRF 2. On note que les événements peuvent être du fait et signalés par les entités applicatives elles-mêmes mais également du fait et signalés par des entités tierces du réseau, comme par exemple par l’entité OAM 9 évoquée précédemment ; un module d’enregistrement 2-B, configuré pour enregistrer au moins une souscription d’au moins une entité applicative NFk, k=1,…N, gérée par l’entité de contrôle NRF 2 à une notification d’au moins un événement tel que décrit ci-avant, affectant un profil enregistré ou destiné à être enregistré auprès de l’entité de contrôle NRF 2. Il convient de noter que l’entité de contrôle NRF 2 se distingue ainsi des entités NRF de l’état de la technique (et en particulier celles définies dans les spécifications actuelles du standard 3GPP) en ce que le module d’enregistrement 2-B est amené non seulement à enregistrer des souscriptions d’entités applicatives aux événements affectant des profils d’autres entités applicatives (par exemple, des entités applicatives dont elles veulent consommer les services ou avec lesquelles elles sont censées communiquer), mais également à enregistrer des souscriptions d’entités applicatives aux événements affectant leurs propres profils ; et un module de notification 2-C, configuré pour envoyer des notifications aux entités applicatives qui ont souscrit préalablement auprès du module d’enregistrement 2-B lorsque l’entité de contrôle NRF 2 détecte des événements correspondant à ces souscriptions. Ces événements peuvent lui avoir été signalés via son module de réception 2-A ou être du fait de l’entité de contrôle NRF 2 elle-même. Comme évoqué précédemment, le module de notification 2-C peut notifier ces événements sous différentes formes : il peut notifier dans son intégralité le profil de l’entité applicative concerné par l’événement incluant la ou les modifications résultant de cet événement, ou notifier seulement la ou les opérations de transformation qui ont été appliquées au profil de l’entité applicative du fait de l’événement en question. Le choix de l’une ou l’autre de ces formes est ici décidé par l’entité de contrôle NRF 2 et peut varier d’un événement à l’autre, par exemple dans un souci d’économie de la bande passante : à titre illustratif, lorsqu’un nouveau profil est créé auprès de l’entité de contrôle NRF 2, celle-ci peut notifier le profil dans son entier ; à l’inverse, lorsque seulement quelques attributs du profil sont modifiés du fait de l’événement détecté, elle peut décider de notifier uniquement les opérations de transformation à appliquer sur le profil courant de l’entité applicative pour obtenir ces modifications. Bien entendu, on peut envisager d’autres formes pour les notifications, comme par exemple la notification de la ou des nouvelles valeurs du ou des attributs ayant été modifiés par l’événement. On note que, dans l’hypothèse où une architecture de micro-services est envisagée pour implémenter également l’entité de contrôle NRF 2, la fréquence des modifications du profil d’une entité applicative auprès de l’entité de contrôle, quelle que soit l’origine de ces modifications, est en général suffisamment faible pour qu’une seule instance d’un micro-service implémentant le module de réception suffise pour traiter le trafic des signalements. Par ailleurs, le trafic induit par les notifications émises par le module de notification pour les besoins de l’invention ne devrait avoir quasiment aucun impact sur la bande passante du réseau, même multiplié par le nombre d’entités applicatives de type fonctions réseau dans un réseau cœur 5G. Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de notification et d’un procédé de gestion selon l’invention, lorsqu’ils sont mis en œuvre respectivement par l’entité applicative NFk, k entier compris entre 1 et N, et l’entité de contrôle NRF 2 du système 1, dans le premier mode de réalisation. Dans le premier mode de réalisation décrit ici, on suppose en préliminaire, que les entités applicatives NF1,…,NFN sont rattachées à l’entité de contrôle NRF 2 et ont été configurées avec une adresse de joignabilité (ex. URI pour « Uniform Resource Identifier ») de cette dernière. On suppose par ailleurs que les micro-services de chaque entité applicative NFk, k=1,…,N, portant un traitement sur un ou plusieurs attributs du profil de l’entité applicative NFk, ont souscrit préalablement auprès du module de notification NFk-C de l’entité applicative à la notification des événements affectant le profil de l’entité applicative NFk (ou éventuellement uniquement les attributs du profil en question les impactant), comme évoqué précédemment. Dès le démarrage de l’entité applicative NFk (étape E10), le sous-module SUBS-MNGR de gestion de souscription de cette dernière crée une souscription auprès de l’entité de contrôle NRF 2 via son API afin de s’abonner aux notifications de tout événement affectant son propre profil auprès de l’entité de contrôle NRF 2 (autrement dit susceptible d’entrainer un changement du profil en question auprès de l’entité de contrôle NRF 2, quelle que soit la nature de ce changement (création, modification d’attributs, suppression)) (étape E20). A cet effet, il renseigne dans la requête de souscription qu’il adresse à l’entité de contrôle NRF 2 via son API (définie dans le document 3GPP TS 29.510 introduit précédemment) : l’attribut nfInstanceIdCond (qui désigne l’instance de fonction NF visée par la souscription) avec la valeur nfInstanceId de l’entité applicative NFk (comprise dans son propre profil NF_PROFk) ; l’attribut nfStatusNotificationUri (qui désigne la ressource vers laquelle envoyer les notifications) avec la valeur de l’adresse de joignabilité, à savoir l’URI dans l’exemple envisagé ici, du module de réception NFK-B qui est destiné à recevoir les notifications de mises à jour du profil NF_PROFk ; et de façon optionnelle, l’attribut validityTime (qui caractérise la durée de validité de la souscription) avec la date de fin de validité de la souscription. Il convient de noter que dans le premier mode de réalisation décrit ici, le sous-module SUBS-MNGR est configuré pour prolonger le cas échéant cette date d’expiration afin que la souscription reste toujours active pendant le fonctionnement de l’entité applicative NFk. Il peut à cet effet utiliser une opération UpdateSubscription connue en soi. En variante, la souscription du sous-module SUBS-MNGR peut viser plus généralement des entités applicatives de même type que l’entité applicative NFk (plutôt que de désigner spécifiquement l’entité applicative NFk), par exemple assurant la même fonctionnalité ou encore correspondant à la même fonction réseau que l’entité applicative NFk, de sorte que toute modification affectant le profil d’une telle entité applicative (et donc incidemment de l’entité applicative NFk) est notifiée à l’entité applicative NFk et plus particulièrement à son module de réception NFk-B. Sur réception de la demande de souscription de l’entité applicative NFk (étape F10), l’entité de contrôle NRF 2 via son module d’enregistrement 2-B enregistre les informations relatives à cette demande de souscription (étape F20). Puis, dans le premier mode de réalisation décrit ici, une fois la souscription créée, le sous-module NFinst-MNGR de gestion enregistre auprès de l’entité de contrôle NRF 2 le profil NF_PROFk de l’entité applicative NFk, de façon connue en soi telle que décrite dans le document 3GPP TS 29.510 (paragraphe 5.2.2.2) (étape E30). Il envoie notamment ici une requête d’enregistrement HTTP PUT dans le corps de laquelle il fournit le profil NF_PROFk de l’entité applicative NFk. Ce profil NF_PROFk, comme détaillé précédemment, comprend une pluralité d’attributs caractérisant l’entité applicative NFk, et notamment, dans l’exemple illustratif envisagé ici, les attributs listés dans le document TS 29.510 dans la table 6.1.6.2.2-1 en section 6.1.6.2.2. Ces attributs comprennent, de façon non exhaustive, l’identifiant ( nfInstanceId ) de l’entité applicative NFk (qui est une instance d’une fonction réseau donnée) à créer (le même identifiant que celui fourni lors de la souscription le cas échéant), le type ( nfType ) de l’entité applicative NFk (i.e. type de la fonction réseau ici), l’état ( nfStatus ) de l’entité applicative, son nom ( nfInstanceName ), le réseau PLMN (pour « Public Land Mobile Network » en anglais) ( plmnList ) auquel elle est rattachée, ses adresses IPv4 et IPv6 ( ipv4Addresses , ipv6Addresses ), sa priorité ( priority ) par rapport aux autres entités applicatives de même type (i.e. aux autres instances de la même fonction réseau), sa capacité ( capacity ), sa charge ( load ), sa localisation ( locality ), etc. Cette demande d’enregistrement du profil NF_PROFk auprès de l’entité de contrôle NRF 2 constitue en soi un signalement d’un événement affectant le profil de l’entité applicative NFk destiné à être enregistré auprès de l’entité de contrôle NRF 2 au sens de l’invention. Sur réception de la requête d’enregistrement par le module de réception 2-A de l’entité de contrôle NRF 2 (étape F30), cette dernière enregistre l’entité applicative NFk : elle mémorise son profil NF_PROFk à l’URI indiquée dans la requête d’enregistrement et associe à l’entité applicative NFk un état « disponible » (étape F40). Elle peut dès lors publier ce profil NF_PROFk auprès d’autres entités du réseau l’interrogeant à propos des entités applicatives qu’elle gère. Par ailleurs, cet enregistrement déclenche l’envoi, par le module de notification 2-C de l’entité de contrôle NRF 2, d’une notification aux entités du réseau ayant souscrit à une notification des événements affectant le profil de l’entité applicative NFk, et en particulier, à l’entité applicative NFk elle-même (et plus spécifiquement à son module de réception NFk-B) (étape F50). Comme mentionné précédemment, le module de notification 2-C est configuré ici pour envoyer dans ses notifications soit le profil complet de l’entité NFk, soit une série d’opérations (comprenant une ou plusieurs opérations) de transformation à appliquer sur la valeur précédente du profil NF_PROFk (« profil précédent » au sens de l’invention) pour obtenir sa valeur courante (« profil courant » au sens de l’invention), autrement dit la valeur résultant de l’événement ayant déclenché la notification et intégrant les changements correspondant à cet événement. L’utilisation de l’un ou l’autre des modes de notification est à la discrétion de l’entité de contrôle NRF 2 (par exemple, en fonction de règles internes à l’entité de contrôle NRF 2), et peut être choisie par exemple en fonction de la quantité d’informations traduisant les modifications apportées au profil et devant être transmise vers les entités applicatives intéressées. En l’espèce, l’événement en question correspond à une création du profil de l’entité NF_PROFk. Le module de notification 2-C choisit alors pour la notification envoyée au cours de l’étape F50, d’envoyer le profil NF_PROFk dans son intégralité à toutes les entités applicatives et en particulier à l’entité NFk, ayant souscrit aux notifications d’événements relatifs à ce profil. On note que le module de réception NFk-B n’a pas nécessairement connaissance, avant de recevoir une notification d’événements relatifs à un profil, du format des informations contenues dans cette notification (i.e. profil complet ou série d’opérations de transformation). Dans le mode de réalisation décrit ici s’appuyant sur un réseau cœur CN 5G, comme décrit dans le document TS 29.510 (table 6.1.6.2.17-1), la notification comporte deux attributs associés respectivement à un profil complet (attribut nfProfile ) et à une série d’opérations de transformation (attribut profileChanges ), dont l’un seulement est présent c’est-à-dire, valorisé avec une valeur non nulle. De cette sorte, sur réception de la notification, le module de réception NFk-B est en mesure de savoir si cette notification contient le profil complet de l’entité applicative NFk ou seulement une série d’opérations de transformation. L’attribut nfProfile est toujours présent (i.e. valorisé à une valeur non nulle) lors de l’enregistrement d’une entité applicative. Ainsi, sur réception de la notification envoyée par le module de notification 2-C de l’entité de contrôle NRF 2 par le module de réception NFk-B (étape E40), deux possibilités sont envisageables (étape test E50) : si le profil NF_PROFk est contenu dans son intégralité dans la notification reçue (i.e. attribut nfProfile présent et valorisé à une valeur non nulle) (réponse oui à l’étape test E50, ce qui est le cas dans l’exemple envisagé ici de la création du profil NF_PROFk), le module de réception NFk-B mémorise le profil complet reçu (qui correspond au profil courant de l’entité NFk-B), par exemple dans une mémoire non volatile non partagée (étape E60) ; si la notification ne contient pas le profil NF_PROFk dans son intégralité mais seulement une série d’opérations de transformation (comprenant une ou plusieurs opérations de transformation) traduisant les changements apportés au profil précédent de l’entité applicative (i.e. attribut profileChanges présent et valorisé à une valeur non nulle) (réponse non à l’étape test E50), le module de réception NFk-B obtient le profil précédent (avant modifications liées à l’événement) et reconstitue/évalue le profil courant NF_PROFk (autrement dit obtient une version à jour de ce profil) en lui appliquant la série d’opérations de transformation contenues dans la notification (étape E70). Puis il mémorise le profil courant ainsi obtenu, dans sa mémoire non volatile non partagée, afin de pouvoir l’utiliser comme profil précédent pour traiter une prochaine notification de l’entité de contrôle NRF 2 si besoin (étape E80). Il convient de noter que lors de l’étape E70, s’il ne dispose pas en mémoire du profil précédent de l’entité applicative NFk (qui correspond en définitive au profil courant de l’entité applicative avant réception de la notification en question), le module de réception NFk-B peut alors interroger l’entité de contrôle NRF 2 pour obtenir le profil courant NF_PROFk enregistré auprès de l’entité de contrôle NRF 2, par exemple en utilisant l’opération GetNFInstance (appartenant au service Nnrf_NFManagement défini par le standard 3GPP dans le document TS 29.510 cité précédemment). Dans ce cas, exceptionnellement il ne tient pas compte du contenu de la notification et mémorise le profil courant obtenu en interrogeant l’entité de contrôle NRF 2 dans sa mémoire non volatile non partagée pour une utilisation ultérieure comme décrit ci-avant. Quelle que soit l’option qui s’applique, le module de réception NFk-B transmet ensuite le profil courant NF_PROFk de l’entité applicative NFk (telle que reçu de l’entité de contrôle ou reconstitué par le module de réception) au module de notification NFk-C (étape E90). Dans l’exemple d’un module de notification implémenté sous la forme d’un micro-service de traitement en temps réel de flux d’événements, cette transmission se traduit par la publication par le module de réception NFk-B du profil courant NF_PROFk dans le thème (ou « topic » en anglais) prévu à cet effet du micro-service event-stream, afin qu’il soit diffusé en l’état auprès des micro-services de l’entité applicative NFk concernés. Le module de notification NFk-C mémorise le profil courant NF_PROFk (ex. en remplacement du profil précédent), par exemple dans une mémoire volatile non partagée (étape E100), puis notifie les micro-services s’étant préalablement enregistrés auprès de lui pour être informés des événements affectant le profil de l’entité applicative NFk (autrement dit ayant souscrit auprès du module de notification NFk-C à la notification de ces événements), et plus particulièrement ici informés de la création du profil de l’entité applicative NFk (étape E110). La notification envoyée par le module de notification NFk-C aux micro-services concernés comprend ici le profil courant NF_PROFk dans son intégralité. La représente la gestion par l’entité applicative NFk et par l’entité de contrôle NRF2 d’autres événements affectant le profil NF_PROFk de l’entité applicative NFk que la création à proprement parler de ce profil. Un tel événement peut être dû à l’entité applicative NFk elle-même, à une entité tierce du réseau, par exemple à l’entité OAM 9, ou à l’entité de contrôle NRF 2. Il consiste typiquement en la modification d’un ou de plusieurs attributs du profil NF_PROFk ou un désenregistrement de l’entité applicative NFk auprès de l’entité de contrôle NRF 2 résultant en une suppression de son profil. Cet événement, lorsqu’il intervient (étape test 120) au niveau de l’entité applicative NFk, est signalé par le sous-module NFinst-MNGR de gestion à l’entité de contrôle NRF 2 (étape E130). Comme pour les notifications envoyées par l’entité de contrôle, l’événement peut être signalé sous la forme du profil NF_PROFk complet de l’entité applicative NFk ou sous la forme d’une série d’opérations de transformation. Sur réception du signalement de l’entité applicative NFk par le module de réception 2-A de l’entité de contrôle NRF 2 (étape F60), cette dernière met à jour le profil NF_PROFk de l’entité applicative NFk pour répercuter les modifications signalées par l’entité applicative NFk (étape F70). Cette mise à jour déclenche l’envoi, par le module de notification 2-C de l’entité de contrôle NRF 2, d’une notification aux entités du réseau ayant souscrit à une notification des événements affectant le profil de l’entité applicative NFk du type de celui signalé lors de l’étape F60, et en particulier, à l’entité applicative NFk elle-même (et plus spécifiquement à son module de réception NFk-B) (étape F80). Comme lors de l’étape F50 précédemment décrite, le module de notification 2-C est configuré ici pour envoyer dans ses notifications soit le profil de l’entité NFk complet, soit une série d’opérations (comprenant une ou plusieurs opérations) de transformation à appliquer sur le profil précédent de l’entité applicative NFk pour obtenir son profil courant NF_PROFk. S’agissant ici d’un événement correspondant à une modification d’un ou plusieurs attributs du profil ou d’une suppression du profil, le module de notification 2-C choisit d’envoyer uniquement les opérations de transformation menant à cette modification. Il convient de noter qu’au-delà d’un certain nombre d’opérations de transformation, on peut envisager que le module de notification 2-C décide de notifier le profil courant dans son intégralité à l’entité applicative NFk. S’en suivent alors au niveau de l’entité applicative NFk : par le module de réception NFk-B, des étapes E140 de réception de la notification, E150 de détection si le profil est transmis dans son intégralité ou seulement sous forme d’opérations de transformation, E160 d’enregistrement du profil courant transmis le cas échéant dans son intégralité ou E170 d’obtention et E180 d’enregistrement du profil courant de l’entité applicative lorsque la notification comprend seulement des opérations de transformation, E190 de transmission du profil courant au module de notification NFk-C de l’entité applicative NFk ; puis par le module de notification NFk-C, des étapes E200 de mémorisation du profil courant puis E210 de notification des micro-services concernés, identiques ou similaires respectivement aux étapes E40 à E110 décrites précédemment. Les mêmes étapes F60 à F80 au niveau de l’entité de contrôle NRF 2 puis E140 à E210 au niveau de l’entité applicative NFk sont exécutées lorsqu’un événement affectant le profil NF_PROFk de l’entité applicative NFk est signalé par une entité tierce du réseau, comme par exemple par l’entité OAM 9 (étape G10). Cela vaut également pour les étapes F70-F80, E140 à E210 lorsque c’est l’entité de contrôle NRF 2 qui est à l’origine de cet événement (étape F90). Comme mentionné précédemment, le premier mode de réalisation est particulièrement novateur et astucieux. Il permet de « détourner » un mécanisme de souscription/notification existant pour permettre aux différents micro-services d’une entité applicative d’être informés simultanément et en temps réel des modifications apportées dynamiquement au profil de l’entité applicative, que ce soit par un autre micro-service de l’entité applicative, l’entité de contrôle ou une autre entité tierce Ce premier mode de réalisation offre la possibilité en outre de mettre en place des opérations de contrôle du bon fonctionnement de l’entité de contrôle NRF 2, et en particulier de sa fonctionnalité de notification. En effet, si une mise à jour du profil NF_PROFk auprès de l’entité de contrôle NRF 2 n’est pas suivie de la réception de la notification associée par l’entité applicative NFk, on peut alors supposer qu’il existe un dysfonctionnement dans la chaîne des notifications à partir de l’entité de contrôle NRF 2 impactant la chaîne de diffusion des notifications jusqu’aux micro-services concernés de l’entité applicative NFk. Un tel dysfonctionnement détecté, on peut envisager l’envoi par le module de gestion NFk-A de l’entité applicative NFk d’une alarme à l’entité de contrôle NRF 2 ou à une entité gérant cette dernière comme par exemple une entité OAM 9. Le premier mode de réalisation permet également de signaler à l’entité applicative NFk un changement de son état opérationnel dans son profil mémorisé NF_PROFk auprès de l’entité de contrôle NRF 2 (par exemple, du fait de l’entité de contrôle NRF elle-même ou de l’entité OAM 9) et de déclencher au niveau de l’entité applicative NFk des actions pour rétablir son état initial. Notamment, si son état passe d’une valeur « enregistré » à « suspendu » ou « non opérationnel », l’entité applicative NFk devient indisponible pour les autres entités applicatives, ce qui peut s’avérer problématique. L’invention permet à l’entité applicative NFk, une fois informée de ce changement d’état, de mettre en œuvre des actions correctrices, comme par exemple, si son contexte d’exécution lui permet, d’envoyer immédiatement à l’entité de contrôle NRF 2 un message de présence (« heart-beat ») visant à rétablir son état « enregistré ». Ce premier mode de réalisation permet également aux micro-services de l’entité applicative NFk notifiés qui traitent des requêtes envoyées par d’autres entités du réseau, de rejeter ces requêtes tant que l’état de l’entité applicative NFk est « suspendu » ou « non opérationnel ». Dans l’état actuel du standard 3GPP, les entités applicatives « consumer » ont la responsabilité de ne plus consommer des services d’une entité applicative se trouvant dans un état « suspendu » ou « non opérationnel ». Toutefois, il se peut qu’il y ait un délai plus ou moins long entre le moment où l’état de l’entité applicative NFk passe à « suspendu » ou « non opérationnel » et le moment où les entités applicatives « consumer » en sont informées. A l’inverse, les micro-services peuvent revenir à un mode de fonctionnement nominal (traitement des requêtes), dès qu’ils sont notifiés d’un passage d’un état « suspendu » ou « non opérationnel » à un état « enregistré ». Deuxième mode de réalisation Nous allons maintenant décrire, en référence aux figures 7 à 10, un deuxième mode de réalisation de l’invention. La représente, dans son environnement, un système 1’ d’un réseau, conforme à l’invention, dans le deuxième mode de réalisation. Le système 1’ comprend : des entités applicatives NF1’,…,NFN’, telles qu’introduites en préliminaire et qui sont conformes au deuxième mode de réalisation de l’invention ; et une entité de contrôle NRF, telle qu’introduite en préliminaire et référencée dans le deuxième mode de réalisation par 2’. L’entité de contrôle NRF est, dans le deuxième mode de réalisation, telle que décrite dans le document 3GPP TS 29.510 cité précédemment. Les entités applicatives NF1’,…,NFN’ du système 1’ sont des entités logicielles, conçues selon une architecture de micro-services, et hébergées par des dispositifs physiques du réseau cœur CN, comme par exemple des serveurs. Ces serveurs ont l’architecture matérielle d’un ordinateur 3’, telle que représentée schématiquement sur la . L’ordinateur 3’ comprend notamment un processeur 4’, une mémoire vive 5’, une mémoire morte 6’, une mémoire non volatile 7’, et des moyens de communication 8’ permettant notamment aux entités du système 1’ de communiquer entre elles et avec d’autres éléments le cas échéant du réseau cœur CN ou d’un autre réseau (par exemple, en référence à la , avec une entité OAM 9’ d’opérations (ou plusieurs selon les choix d’implémentation adoptés), d’administration et de maintenance, déjà évoquée précédemment). Ces moyens de communication 8’ s’appuient d’une part, sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici, mais également sur une ou plusieurs interfaces logicielles basées sur le service ou SBI. Ces interfaces logicielles sont des APIs (pour « Application Programming Interfaces » en anglais) qui utilisent ici le protocole HTTP/2. La mémoire morte 6’ de l’ordinateur 3’ constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 4’ et sur lequel est enregistré un programme d’ordinateur conforme à l’invention. Plus spécifiquement, la mémoire morte 6’ de l’ordinateur 3’ comprend un enregistrement d’un programme d’ordinateur PROG-NFk’, comportant des instructions définissant les principales étapes d’un procédé de notification selon le deuxième mode de réalisation de l’invention. Ce programme PROG-NFk’ définit des modules fonctionnels de l’entité applicative NFk’, k=1,…,N qui s’appuient ou commandent les éléments matériels 4’ à 8’ de l’ordinateur 3’ cités précédemment. Ces modules comprennent notamment dans le deuxième mode de réalisation, comme illustré sur la : un module (ou agent) de gestion des instances NFk’-A’ des services Xk et Yk configuré pour signaler à l’entité de contrôle NRF 2’ gérant les entités applicatives NF1’,…,NFN’, tout événement affectant le profil, référencé par NF_PROFk’, de l’entité applicative NFk’. Un tel événement peut être l’enregistrement (ou de façon équivalente, la création) du profil NF_PROFk’ auprès de l’entité de contrôle NRF2’, une modification apportée à ce profil (création, changements ou suppression d’un ou plusieurs attributs), ou encore un désenregistrement (ou de façon équivalente une suppression) du profil NF_PROFk’ enregistré auprès de l’entité de contrôle NRF 2’. Conformément au deuxième mode de réalisation le module de gestion d’instances NFk’-A est en outre configuré pour notifier un tel événement en interne au sein de l’entité applicative NFk' ; un module de notification NFk’-B configuré : d’une part, pour recevoir les notifications d’événements émises en interne par le module de gestion d’instances NFk’-A après avoir signalé ces événements à l’entité de contrôle NRF 2’ (le module de notification est donc un module de réception au sens de l’invention). Dans le deuxième mode de réalisation, les notifications émises par le module de gestion NFk’-A comprennent préférentiellement le profil courant de l’entité applicative NFk’ dans son intégralité, incluant le ou les changements correspondant aux événements notifiés, pour limiter les traitements à effectuer par le module de réception NFk’-B ; et d’autre part, pour notifier chaque événement signalé par le module de gestion NFk’-A à chaque micro-service de l’entité applicative NFk’, dit micro-service concerné, ayant souscrit préalablement auprès du module de notification NFk’-B à une notification de cet événement, de façon similaire ou identique à ce qui a été décrit dans le premier mode de réalisation. L’événement est notifié ici par le module de notification NFk’-B aux micro-services concernés sous la forme du profil courant complet NF_PROFk’ de l’entité applicative NFk’ intégrant le(s) changement(s) correspondant à cet événement. Dans le deuxième mode de réalisation comme dans le premier mode de réalisation, le module de notification NFk’-B est conçu comme un micro-service de traitement en temps réel de flux d’événements (event-stream). Des exemples d’un tel micro-service sont par exemple les micro-services Apache Kafka et Redis Streams. On note que les micro-services de l’entité applicative NFk’ peuvent être configurés pour ne souscrire qu’à des événements spécifiques affectant le profil NF_PROFk’ de l’entité applicative NFk’ en fonction notamment de la fonctionnalité qu’ils exécutent (ex. affectant des attributs particuliers du profil, et/ou le service auquel ils sont rattachés dans l’exemple du service Yk’). Comme dans le premier mode de réalisation, les communications au sein de l’entité applicative NFk’ entre ses différents modules logiciels s’appuient sur le protocole HTTP/2. Toutefois cette hypothèse n’est pas limitative en soi, et d’autres protocoles de communication peuvent être envisagés, comme par exemple les protocoles QUIC, RPC, CORBA, etc. Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de notification selon le deuxième mode de réalisation de l’invention, lorsqu’il est mis en œuvre par l’entité applicative NFk’, k’ entier compris entre 1 et N. Dans le deuxième mode de réalisation décrit ici, on suppose en préliminaire, que les entités applicatives NF1’,…,NFN’ sont rattachées à l’entité de contrôle NRF 2’ et ont été configurées avec une adresse de joignabilité (ex. URI pour « Uniform Resource Identifier ») de cette dernière. Dès le démarrage de l’entité applicative NFk’ (étape E10’), le module de gestion NFk’-A enregistre auprès de l’entité de contrôle NRF 2’ le profil NF_PROFk’ de l’entité applicative NFk’, de façon connue en soi telle que décrite dans le document 3GPP TS 29.510 (paragraphe 5.2.2.2) (étape E20’). Il envoie notamment ici une requête d’enregistrement HTTP PUT dans le corps de laquelle il fournit le profil NF_PROFk’ de l’entité applicative NFk’. Ce profil NF_PROFk’, comme détaillé précédemment, comprend une pluralité d’attributs caractérisant l’entité applicative NFk’, et notamment, dans l’exemple illustratif envisagé ici, les attributs listés dans le document TS 29.510 dans la table 6.1.6.2.2-1 en section 6.1.6.2.2. Ces attributs comprennent notamment, de façon non exhaustive, l’identifiant ( nfInstanceId ) de l’entité applicative NFk’ (qui est une instance d’une fonction réseau donnée) à créer, le type ( nfType ) de l’entité applicative NFk’ (i.e. type de la fonction réseau ici), l’état ( nfStatus ) de l’entité applicative, son nom ( nfInstanceName ), le réseau PLMN (pour « Public Land Mobile Network » en anglais) ( plmnList ) auquel elle est rattachée, ses adresses IPv4 et IPv6 ( ipv4Addresses , ipv6Addresses ), sa priorité ( priority ) par rapport aux autres entités applicatives de même type (i.e. aux autres instances de la même fonction réseau), sa capacité ( capacity ), sa charge ( load ), sa localisation ( locality ), etc. Cette demande d’enregistrement du profil NF_PROFk’ auprès de l’entité de contrôle NRF 2’ constitue un signalement d’un événement affectant le profil de l’entité applicative NFk’ destiné à être enregistré auprès de l’entité de contrôle NRF 2’ au sens de l’invention. Sur réception de la requête d’enregistrement par l’entité de contrôle NRF 2’, cette dernière enregistre l’entité applicative NFk’ : elle mémorise son profil NF_PROFk’ à l’URI indiquée dans la requête d’enregistrement et associe à l’entité applicative NFk’ un état « disponible ». Elle acquitte cet enregistrement auprès de l’entité applicative NFk’. L’entité de contrôle NRF 2’ peut dès lors publier ce profil NF_PROFk’ auprès d’autres entités du réseau l’interrogeant à propos des entités applicatives qu’elle gère. La réception de l’acquittement de l’enregistrement du profil de l’entité applicative NFk’ par le module de gestion NFk’-A (étape E30’) déclenche l’envoi, par ce dernier, d’une notification au module de notification NFk’-B de l’entité applicative (étape E40’). Comme mentionné précédemment, le module de gestion NFk’-A est configuré ici pour envoyer dans sa notification le profil complet de l’entité NFk’ incluant les modifications signalées à l’entité de contrôle NRF 2’ (autrement dit le profil courant de l’entité applicative NFk’ tel qu’il est connu de l’entité de contrôle NRF 2’). Dans une implémentation de l’invention s’appuyant sur un module de notification de type micro-service event-stream, l’envoi de cette notification a pour effet de publier le profil NF_PROFk’ auprès du module de notification. Sur réception de la notification par le module de notification NFk’-B, celui-ci notifie les micro-services s’étant préalablement enregistrés auprès de lui pour être informés des événements affectant le profil de l’entité applicative NFk’, et plus particulièrement ici informés de la création du profil de l’entité applicative NFk’ (étape E50’). La notification envoyée par le module de notification NFk’-B aux micro-services concernés comprend ici le profil NF_PROFk’ dans son intégralité. Les mêmes étapes E20’ de signalement par le module de gestion NFk’-A à l’entité de contrôle NRF 2’, E30’ de réception par le module de gestion NFk’-A de l’acquittement de l’entité de contrôle NRF 2’, E40’ de notification de l’événement acquitté par le module de gestion NFk’-A au module de notification NFk’-B, et E50’ de notification par le module de notification NFk’-B aux micro-services concernés de l’entité applicative NFk’ sont réitérées pour chaque événement détecté par le module de gestion NFk’-A affectant le profil de l’entité applicative NFk’, à savoir la modification d’un ou de plusieurs attributs du profil, la suppression du profil auprès de l’entité de contrôle NRF 2’. Entité applicative (NFk, NFk’) ayant une architecture de micro-services et proposant au moins un service dans un réseau, ladite entité applicative comprenant : un module de gestion (NFk-A, NFk’-A) configuré pour signaler à une entité de contrôle (2,2’) gérant une pluralité d’entités applicatives du réseau, au moins un événement affectant un profil de l’entité applicative enregistré ou destiné à être enregistré auprès de ladite entité de contrôle, ledit profil comprenant une pluralité d’attributs caractérisant ladite entité applicative ; et un module de notification (NFk-C, NFk’-B) configuré pour notifier chaque événement signalé par le module de gestion à l’entité de contrôle à chaque micro-service de l’entité applicative, dit micro-service concerné, ayant souscrit auprès du module de notification à une notification dudit événement. Entité applicative (NFk, NFk’) selon la revendication 1 dans laquelle ledit module de gestion est configuré pour enregistrer ledit profil de l’entité applicative auprès de l’entité de contrôle. Entité applicative (NFk, NFk’) selon la revendication 1 ou 2 dans laquelle ledit module de notification est un micro-service de traitement en temps réel de flux d’événements. Entité applicative (NFk, NFk’) selon l’une quelconque des revendications 1 à 3 dans laquelle ladite entité applicative est une fonction réseau. Entité applicative (NFk) selon l’une quelconque des revendications 1 à 4 dans laquelle ledit module de gestion (NFk-A) est configuré pour souscrire auprès de l’entité de contrôle à une notification de l’entité applicative d’au moins un événement affectant son profil auprès de l’entité de contrôle, ledit module de notification (NFk-C) étant configuré pour notifier chaque événement notifié par l’entité de contrôle à chaque micro-service de l’entité applicative, dit micro-service concerné, ayant souscrit auprès du module de notification à une notification dudit événement. Entité applicative (NFk) selon la revendication 5 dans laquelle ledit module de gestion est configuré pour souscrire auprès de l’entité de contrôle à ladite notification avant d’enregistrer auprès de l’entité de contrôle ledit profil de l’entité applicative. Entité applicative (NFk) selon la revendication 5 ou 6 dans laquelle : au moins un événement affectant le profil de l’entité applicative notifié par l’entité de contrôle comprend un changement d’au moins un attribut dudit profil, dit profil précédent, et est notifié sous la forme d’au moins une opération de transformation conduisant audit changement ; ladite entité applicative comprend un module de traitement (NFk-B) configuré pour obtenir un profil courant de l’entité applicative en appliquant ladite au moins une opération de transformation audit profil précédent et fournir le profil courant au module de notification, les notifications du module de notification aux micro-services concernés de l’entité applicative comprenant ledit profil courant. Entité applicative (NFk) selon la revendication 6 ou 7 dans laquelle ledit module de traitement est configuré pour mémoriser ledit profil courant. Entité applicative (NFk) selon l’une quelconque des revendications 5 à 8 dans laquelle au moins un événement affectant le profil de l’entité applicative notifié par l’entité de contrôle comprend un changement d’au moins un attribut dudit profil, dit profil précédent, et est notifié sous la forme d’un profil courant intégrant le changement dudit au moins un attribut par rapport au profil précédent. Entité applicative (NFk) selon l’une quelconque des revendications 5 à 9 dans laquelle au moins un événement affectant le profil de l’entité applicative notifié par l’entité de contrôle comprend un changement d’au moins un attribut du profil de l’entité applicative signalé à l’entité de contrôle par une entité tierce du réseau. Entité applicative (NFk’) selon l’une quelconque des revendications 1 à 4 dans laquelle ledit module de gestion (NFk’-A) est configuré pour informer ledit module de notification (NFk’-B) dudit au moins un événement après son signalement auprès de l’entité de contrôle. Entité de contrôle (2) gérant une pluralité d’entités applicatives d’un réseau, chaque entité applicative étant associée à un profil mémorisé par l’entité de contrôle comprenant une pluralité d’attributs caractérisant ladite entité applicative, ladite entité de contrôle comprenant : un module d’enregistrement, configuré pour enregistrer au moins une souscription d’une dite entité applicative à une notification d’au moins un événement affectant son profil ; et un module de notification, configuré pour envoyer une notification à ladite entité applicative lorsque l’entité de contrôle détecte ledit événement. Entité de contrôle (2) selon la revendication 12 dans laquelle au moins un dit événement affectant le profil de l’entité applicative est signalé par ladite entité applicative ou par une entité tierce du réseau. Système d’un réseau (1,1’) comprenant une pluralité d’entités applicatives (NFk,NFk’) dudit réseau conformes à l’une quelconque des revendications 1 à 9 et une entité de contrôle (2,2’) gérant ladite pluralité d’entités applicatives. Système (1) selon la revendication 14 dans lequel ladite entité de contrôle (2) est conforme à la revendication 12 ou 13. Procédé de notification destiné à être mis en œuvre par une entité applicative (NFk,NFk’) ayant une architecture de micro-services et proposant au moins un service dans un réseau, ledit procédé comprenant : au moins une étape de signalement (E30, E130,E20’) à une entité de contrôle gérant une pluralité d’entités applicatives du réseau, au moins un événement affectant un profil de l’entité applicative enregistré ou destiné à être auprès de ladite entité de contrôle, ledit profil comprenant une pluralité d’attributs caractérisant ladite entité applicative ; et une étape de notification (E110,E210,E50’) de chaque événement signalé par le module de gestion à l’entité de contrôle à chaque micro-service de l’entité applicative ayant souscrit auprès du module de notification à une notification dudit événement. Procédé de gestion par une entité de contrôle (2) d’une pluralité d’entités applicatives d’un réseau, chaque entité applicative étant associée à un profil mémorisé par l’entité de contrôle comprenant une pluralité d’attributs caractérisant ladite entité applicative, ledit procédé de gestion comprenant : une étape d’enregistrement (F20) d’au moins une souscription d’une dite entité applicative à une notification d’au moins un événement affectant son profil ; et une étape de notification (F50,F80) de ladite entité applicative lorsque l’entité de contrôle détecte ledit événement.