Brevet FR3155932A1 — publié le 20250530

Procédé de déploiement d’un service dans un environnement distribué . L’invention se rapporte à un procédé de déploiement d’un service dans un environnement distribué, comprenant le déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation. Le procédé, mis en œuvre au sein d’un nœud de gestion, comprend : - l’instanciation (E1), au sein des unités de virtualisation, de composants de surveillance configurés pour délivrer des métriques associées aux unités de virtualisation et/ou aux composants logiciels déployés ; - l’enregistrement (E2), au sein d’un fichier de configuration, de données d’interconnexion entre certains desdits composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - l’instanciation (E3), au sein du nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’itérations de contrôle du respect de critères techniques prédéfinis, en fonction desdites métriques et desdites données d’interconnexion. Figure d’abrégé : Figure 1 Procédé de déploiement d’un service dans un environnement distribué. L’invention se situe dans le domaine du déploiement automatisé de services sur un ensemble de ressources informatiques. Plus particulièrement la présente invention se rapporte à des techniques de déploiement automatisé dans un environnement distribué, qui permettent de garantir de manière continue le respect de spécifications techniques prédéfinies lors de l’exploitation du service, afin d’en assurer un fonctionnement nominal. Art antérieur De nombreux réseaux de communication utilisent des fonctions virtualisées instanciées sur des nœuds de virtualisation hébergés dans des machines virtuelles ou dans des serveurs regroupés en grappes, ou « clusters » au sein de centres de données. Dans la suite du document, il est fait mention de nœuds de virtualisation hébergés dans des serveurs mais il est entendu que l’enseignement du présent document s’applique également au cas de nœuds de virtualisation hébergés dans des machines virtuelles. Un exemple de gestion d’instanciation de fonctions virtualisées est connu sous l’appellation « Kubernetes ». Une architecture Kubernetes comprend au moins une grappe de nœuds de virtualisation. Une telle grappe de nœuds de virtualisation comprend au moins un premier nœud dit nœud de gestion, ou « Kubernetes master node », et une pluralité de nœuds de calcul, ou « Kubernetes worker node » destinés à instancier des fonctions virtualisées. Le nœud de gestion comprend, entre autres, une base de données dite ETCD qui consiste en un registre dynamique de configuration des nœuds de calculs. Un nœud de calcul comprend une pluralité d’unités de virtualisation ou « pods ». Chaque unité de virtualisation est dotée de ressources permettant l’exécution d’un ou plusieurs composants logiciels. Un composant logiciel, lorsqu’il est exécuté, contribue à la mise en œuvre d’un service ou d’une fonction virtualisée. La base de données ETCD embarquée dans le nœud de gestion mémorise dans des fichiers de référence une liste d’unités de virtualisation à instancier ainsi que des paramètres à prendre en compte lors de l’instanciation d’un service ou des fonctions virtualisées. Le nœud de gestion vient lire régulièrement le contenu de ces fichiers, le compare avec les unités de virtualisation en cours d’instanciation et ajoute ou retire des unités de virtualisation afin d’adapter leur quantité à celle indiquée dans ces fichiers de référence. La base de données ETCD étant également accessible par une entité de déploiement des nœuds de virtualisation, cette dernière vient lire régulièrement le contenu de ces fichiers, compare la capacité des nœuds de virtualisation déployés avec la capacité requise par les unités de virtualisation en cours d’instanciation et ajoute ou retire des nœuds de virtualisation afin d’adapter leur quantité aux besoins. Le déploiement d’un nœud de virtualisation sur un serveur informatique consiste par exemple à télécharger sur un serveur informatique un fichier contenant un système d’exploitation ainsi qu’un ensemble d’applicatifs nécessaires au déploiement du nœud de virtualisation, puis à démarrer le serveur informatique en utilisant le fichier téléchargé. Il est également possible de déployer plusieurs nœuds de virtualisation sur un même serveur informatique grâce à l’utilisation de machines virtuelles. Dans ce cas, une fois le fichier téléchargé sur le serveur informatique, c’est une machine virtuelle qui est démarrée en utilisant le fichier téléchargé. Dans un souci de réduction des coûts d’exploitation et d’amélioration de la flexibilité des infrastructures réseaux, les architectures d’informatique en nuage sont le plus souvent des architectures distribuées ou multisites dans lesquelles les serveurs hébergeant les nœuds de virtualisation appartenant à une même grappe de nœuds peuvent être situés sur des sites géographiques distincts et distants. Ainsi, certaines fonctions virtualisées requérant, par exemple, une faible latence, ont plutôt tendance à être exécutées par des unités de virtualisation déployées dans des serveurs situés en périphérie des réseaux de communications, c’est-à-dire au plus proche des terminaux utilisateurs requérant un service donné, tandis que des fonctions virtualisées moins exigeantes en termes de latence mais traitant de gros volumes de données sont plutôt instanciées dans des centres de données centralisés, généralement de taille plus importante. Si elles intègrent généralement des mécanismes de répartition de charge (tels que par exemple un mécanisme connu sous le nom de « Horizontal Pod Autoscaling » , qui permet d’adapter automatiquement le nombre d’unités de virtualisation installées sur l’ensemble des nœuds de virtualisation en fonction d’un niveau de charge courant associé au service déployé), l’architecture Kubernetes et les autres solutions existantes de déploiement automatisés de services n’offrent cependant actuellement pas de moyens de garantir en continu la satisfaction de contraintes techniques prédéfinies (e.g. imposées à l’avance par un utilisateur opérateur du service), en termes par exemple de ressources minimales à allouer ou de performance réseau à respecter en phase d’exploitation du service, notamment lorsque ce service est amené à être déployé dans un environnement distribué, avec des composants logiciels répartis sur des infrastructures potentiellement localisées sur des sites géographiques distincts et distants. Pour certaines applications critiques, le respect de telles contraintes techniques peut pourtant s’avérer essentiel, une défaillance voire un simple ralentissement du service étant parfois susceptible d’avoir des conséquences indésirables importantes, notamment lorsque la sécurité des utilisateurs dépend d’un bon fonctionnement du service. Même pour des applications moins critiques, il existe un risque que les utilisateurs se détournent d’un service en cas de dégradation répétée de l’expérience utilisateur, si les ressources minimales pour assurer un fonctionnement nominal du service ne sont pas garanties en continu. La présente invention a pour objet de résoudre tout ou partie des inconvénients précédemment cités. La présente technique permet de proposer une solution visant à remédier à certains inconvénients de l’art antérieur. Selon un aspect, la présente technique se rapporte en effet à un procédé de déploiement automatisé d’un service dans un environnement distribué, comprenant le déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation au sein dudit environnement distribué. Selon le principe général de l’invention proposée, un tel procédé, mis en œuvre au sein d’un nœud de gestion de l’environnement distribué, comprend : - l’instanciation, au sein d’au moins une desdites unités de virtualisation, d’au moins un composant de surveillance configuré pour délivrer au moins une métrique associée à ladite unité de virtualisation et/ou à au moins un desdits composants logiciel déployé sur ladite unité de virtualisation ; - l’enregistrement, au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels de ladite pluralité de composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - l’instanciation, au sein dudit nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’au moins une itération de contrôle du respect d’au moins un critère technique prédéfini, en fonction desdites métriques délivrées par au moins un desdits composants de surveillance et desdites données d’interconnexion enregistrées au sein dudit fichier de configuration. De cette manière, les conditions sont réunies pour permettre la mise en œuvre d’une boucle de contrôle dans un environnement distribué, grâce à une solution perfectionnée de déploiement automatisé d’applications conteneurisées qui comprend des mécanismes complémentaires permettant d’une part d’obtenir, via des composants de surveillance, des métriques au niveau des différents conteneurs déployés dans l’environnement distribué, mais également d’autre part de faire le lien entre ces différents conteneurs et donc ces différentes métriques, au moyen de données d’interconnexions enregistrées au niveau d’un fichier de configuration commun. De cette manière, la boucle de contrôle dispose ainsi de l’ensemble des informations lui permettant de contrôler le respect de spécifications techniques prédéfinies en phase d’exploitation du service, quand bien même ce service est déployé dans un environnement distribué. Dans un mode de réalisation particulier, ladite instanciation d’au moins un composant de surveillance au sein d’au moins une desdites unités de virtualisation est mise en œuvre conjointement ou concomitamment au déploiement d’au moins un desdits composants logiciels sur ladite unité de virtualisation. De cette manière, la boucle de contrôle est fonctionnelle dès que le service est déployé, et le contrôle en continu du respect des critères techniques prédéfinis est opérationnel dès l’origine, c’est-à-dire dès que le service devient disponible pour ses utilisateurs. Dans un mode de réalisation particulier, lesdits composants logiciels, lesdites interconnexions entre composants logiciels, et lesdits critères techniques sont définis au sein d’un fichier de type déclaratif, ledit déploiement étant effectué en fonction du contenu dudit fichier de type déclaratif. De cette manière, le déploiement du service et d’une boucle de contrôle associée est particulièrement simple à mettre en œuvre pour un opérateur dudit service, puisqu’il lui suffit de déclarer au sein d’un simple fichier, via des entrées de type clé-valeur, les conteneurs à déployer, les liens qui existent entre certains de ces conteneurs, et les objectifs à garantir pour des critères techniques choisis (exprimés par exemple sous la forme de valeurs minimales et/ou maximales à respecter) en relation avec les conteneurs et les liens déclarés. Dans un mode de réalisation particulier, ledit enregistrement de données d’interconnexion au sein du fichier de configuration et ladite instanciation de la boucle de contrôle sont initiés sur requête d’une application dédiée, en fonction de données collectées par ladite application dédiée suite au déploiement desdits composants logiciels et à l’instanciation desdits composants de surveillance sur lesdites unités de virtualisation. De cette manière, les opérations d’obtention, de sélection et de formatage de données pertinentes pour le fonctionnement de la boucle de contrôle sont facilitées, grâce à l’utilisation d’une application spécifiquement développée à cette fin. Dans un mode de réalisation particulier, au moins une itération mise en œuvre par ladite boucle de contrôle comprend un contrôle du respect d’au moins un critère technique représentatif d’au moins une ressource allouée pour la mise en œuvre d’au moins un desdits composant logiciels. Selon une caractéristique particulière de ce mode de réalisation, ledit au moins un critère technique représentatif d’au moins une ressource allouée appartient au groupe comprenant : - une quantité d’espace disque minimale ; - une quantité de mémoire vive minimale ; - une quantité de disponibilité processeur minimale. Dans un mode de réalisation particulier, au moins une itération mise en œuvre par ladite boucle de contrôle comprend un contrôle du respect d’au moins un critère technique représentatif d’au moins une performance cible pour la mise en œuvre d’au moins un lien d’interconnexion entre lesdits composant logiciels. Selon une caractéristique particulière de ce mode de réalisation, ledit au moins un critère technique représentatif d’au moins une performance cible appartient au groupe comprenant : - une latence maximale sur ledit lien d’interconnexion entre lesdits composant logiciels ; - une gigue maximale sur ledit lien d’interconnexion entre lesdits composant logiciels ; - un taux maximal de perte de données sur ledit lien d’interconnexion entre lesdits composant logiciels. De cette manière, il est possible de s’assurer que des ressources et des performances minimales sont garanties pour un fonctionnement optimal du service, tant à un niveau intra-conteneur (i.e. au sein de chaque conteneur) qu’à un niveau inter-conteneurs (i.e. dans les interactions entre conteneurs). Dans un mode de réalisation particulier, ledit procédé comprend, préalablement ou au début de chaque itération de contrôle de ladite boucle de contrôle, une étape de vérification, au sein dudit fichier de configuration, par lesdits composants de surveillance, d’une validité courante desdites données d’interconnexion entre composants logiciels. De cette manière, toute modification de la configuration du service déployé est détectée rapidement, ce qui permet d’opérer le cas échéant et au besoin un reparamètrage à la volée de la boucle de contrôle et des composants de surveillance. Un fonctionnement continu optimal de la boucle de contrôle est ainsi assuré. Dans un mode de réalisation particulier, ledit procédé comprend, lorsque au moins un desdits critères techniques prédéfinis n’est pas respecté, l’exécution d’une action correctrice en lien avec au moins un desdits composants logiciels et/ou au moins une desdites unités de virtualisation. De cette manière, toute détection du non-respect d’un des critères techniques prédéfinis entraine une réaction immédiate du système, visant à rétablir au plus vite le respect dudit critère. Ainsi, les conditions d’un fonctionnement nominal du service sont garanties en continu. Dans un mode de réalisation particulier, au moins un desdits critères prédéfinis est associé au fonctionnement dudit service. Dans un mode de réalisation particulier, ledit service est un réseau d’accès radio en nuage (CRAN), et lesdits composants logiciels comprennent au moins une unité radio (RU), au moins une unité distribuée (DU), et au moins une unité centralisée (CU). De cette manière, la mise en œuvre de mécanismes permettant le respect des exigences de performances élevées associées au fonctionnement d’un réseau d’accès radio en nuage est grandement facilitée, et les risques de défaillance ou de désynchronisation des différents éléments d’un tel service sont significativement réduits. Selon un autre aspect, l’invention se rapporte à un dispositif de déploiement d’un service dans un environnement distribué, comprenant des moyens de déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation au sein dudit environnement distribué. Un tel dispositif implémente un nœud de gestion dudit environnement distribué et comprend : - des moyens d’instanciation, au sein d’au moins une desdites unités de virtualisation, d’au moins un composant de surveillance configuré pour délivrer au moins une métrique associée à ladite unité de virtualisation et/ou à au moins un desdits composants logiciels déployé sur ladite unité de virtualisation ; - des moyens d’enregistrement, au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels de ladite pluralité de composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - des moyens d’instanciation, au sein dudit nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’au moins une itération de contrôle du respect d’au moins un critère technique prédéfini, en fonction desdites métriques délivrées par au moins un desdits composants de surveillance et desdites données d’interconnexion enregistrées au sein dudit fichier de configuration. Un tel dispositif peut bien sûr présenter les différentes caractéristiques relatives au procédé de déploiement selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux du procédé de déploiement et ne sont pas détaillés plus amplement. Selon un autre aspect, l’invention proposée se rapporte également à un produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour l’exécution du procédé tel que décrit précédemment dans l’un quelconque de ses modes de réalisation, lorsque ce procédé est exécuté sur un ordinateur. L’invention proposée vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé tel que décrit précédemment, dans l’un quelconque de leurs modes de réalisation. Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une clé USB ou un disque dur. D’autre part, un tel support 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 radio ou par d’autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau, par exemple le réseau Internet. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention. Figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : FIG. 1 présente de manière schématique les principales étapes d’un procédé de déploiement d’un service, dans un mode de réalisation particulier de la technique proposée ; FIG. 2 présente un diagramme de séquence illustrant le déploiement d’un service de réseau d’accès en nuage au sein d’une architecture Kubernetes, dans un mode de réalisation particulier de la technique proposée ; FIG. 3 présente un exemple de contenu d’un fichier déclaratif de critères techniques à garantir en phase d’exploitation d’un service, dans un mode de réalisation particulier de la technique proposée ; FIG. 4 décrit une architecture simplifiée d’un nœud de gestion pour la mise en œuvre de la technique proposée, dans un mode de réalisation particulier de la technique proposée. Description détaillée de l’invention Principe général La technique décrite ci-après permet de remédier à certains des inconvénients précités. Sur toutes les figures du présent document, les éléments et étapes de même nature sont désignés par une même référence numérique. Selon un premier aspect, la présente technique se rapporte à un procédé de déploiement automatisé d’un service dans un environnement distribué. Le terme « service » est entendu ici au sens large, et englobe par exemple, à titre illustratif et non limitatif, la mise à en œuvre d’une ou plusieurs applications et/ou fonctions virtualisées permettant la mise à disposition d’un ensemble de fonctionnalités. Par « environnement distribué », on entend par ailleurs dans le cadre du présent document un environnement dans lequel les différentes ressources qui servent de support à la mise en œuvre du service considéré sont réparties dans une pluralité de serveurs, de grappes de serveurs et/ou de centres de données non nécessairement localisés dans un même lieu géographique (dans le cadre d’une architecture Kubernetes, un tel environnement peut être qualifié de « multi-cluster »). De manière classique, le déploiement du service dans un tel environnement comprend le déploiement d’une pluralité de composants logiciels de ce service sur une pluralité d’unités de virtualisation au sein de l’environnement distribué. Cette distribution des composants logiciels, et donc des traitements, rend toutefois plus complexe les opérations de contrôle de performance, les solutions classiques de déploiement automatisé d’applications conteneurisées, telles que Kubernetes par exemple, n’intégrant pas de manière native de mécanismes pour garantir à tout instant la disponibilité des ressources (CPU, RAM, etc.) allouées à chaque unité de virtualisation ou des performances minimales (par exemple des performances réseau, des performances énergétiques, etc.) à respecter pour les échanges de données entre les différents composants logiciels du service. La technique proposée se rapporte plus particulièrement à des perfectionnements de ces solutions existantes de déploiement automatisé d’applications conteneurisées, permettant de pallier ces inconvénients. Ainsi, le principe général de la technique proposée, illustré en relation avec la FIG. 1 , repose sur un processus de déploiement amélioré, enrichi de nouvelles étapes introduites ci-après, comprenant, au niveau d’un nœud de gestion de l’environnement distribué : - l’instanciation E1, dans les unités de virtualisation au sein desquelles les différents composants logiciels du service à déployer sont mis en œuvre, de composants de surveillance configurés pour délivrer au moins une métrique associée à l’unité de virtualisation et/ou au composant logiciel considérés ; - l’enregistrement E2, au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels interconnectés pour la mise en œuvre du service à déployer, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - l’instanciation E3, au sein du nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation du service, d’au moins une itération de contrôle du respect de critères techniques prédéfinis associés au fonctionnement du service, en fonction des métriques délivrées par les composants de surveillance et des données d’interconnexion enregistrées au sein du fichier de configuration. En d'autres termes, des mécanismes sont prévus non seulement pour mettre en place une boucle de contrôle permettant de garantir le respect de spécifications techniques imposées par exemple par un utilisateur opérateur du service, mais également pour assurer que cette boucle de contrôle dispose bien de l’ensemble des données nécessaires pour réaliser ce contrôle, à savoir : - des données (e.g. des mesures) associées au fonctionnement de chaque composant logiciel ou unité de virtualisation au sein duquel il est déployé, grâce à l’instanciation dans chacune de ces unités de virtualisation de composants de surveillance dédiés pour délivrer de telles métriques ; et - des données qui peuvent être qualifiées de données de synchronisation, en ce qu’elles permettent de faire le lien entre des composants logiciels qui, bien qu’interconnectés pour la mise en œuvre du service, n’ont pas nécessairement de connaissance de leur existence respective, de l’existence d’autres composants de surveillance que le leur, et/ou des ressources sur lesquels ils sont déployés, grâce à une mise en commun d’au moins une partie de ces informations au sein d’un fichier de configuration partagé disponible au niveau d’un nœud de gestion. Selon le principe général précédemment décrit, la boucle de contrôle a ainsi accès à des informations corrélées reçues des différents composants logiciels et composants de surveillance dépendants les uns des autres et interconnectés, ce qui lui permet de fonctionner dans un environnement distribué. Selon une caractéristique particulière, les mécanismes précédemment décrits peuvent être mis en œuvre dès le déploiement du service dans l’environnement distribué, autrement dit de manière conjointe ou concomitante au déploiement des composants logiciels de ce service dans l’environnement distribué. De manière alternative, selon une autre caractéristique particulière, leur mise en œuvre peut également être disjointe de la phase de déploiement des composants logiciels. Les étapes E1, E2 et E3 introduites précédemment sont alors mises en œuvre dans une phase ultérieure, en relation avec un service déjà déployé voire potentiellement déjà exploité, éventuellement sur requête d’une entité tierce habilitée – par exemple par délégation d’une autorité de certification – à requérir auprès du nœud de gestion le déploiement de tels mécanismes de contrôle. Présentation d’un mode de réalisation particulier Dans la suite du document, l’invention est décrite de manière plus détaillée sur l’exemple du déploiement automatisé d’un réseau d’accès radio en nuage, ou Cloud-RAN (« Cloud Radio Access Network » en anglais), d’un réseau de communication. La solution proposée est en effet particulièrement intéressante dans le cadre du déploiement d’un tel service, pour plusieurs raisons. En premier lieu, le déploiement d’un réseau d’accès radio en nuage est généralement mis en œuvre à la périphérie d’un réseau de communication, ce qui implique de s’écarter des architectures classiques souvent mises en œuvre sur un seul site géographique, au profit d'architectures distribuées sur un territoire plus vaste, ce qui correspond à un type d’architecture visé par la technique proposée. Les composants logiciels du réseau d’accès radio en nuage – qui comprennent au moins une unité radio RU, au moins une unité distribuée DU, et au moins une unité centralisée CU – sont ainsi généralement amenés à être déployés sur des sites distribués. En outre, une association unique entre un CU et un DU ainsi qu'entre un DU, un RU et une antenne doit être instanciée. L’introduction et la prise en compte de données d’interconnexion, tel que proposé avec la présente technique, permet une gestion simplifiée de ce type d’architecture distribuée, en permettant, via le partage d’un fichier de configuration commun, l'échange de données de configurations entre les différents conteneurs permettant le déploiement du réseau d'accès en nuage, et plus particulièrement le partage des informations d'adressage des conteneurs comprenant les entités CU, DU et RU. De cette manière, le DU est en mesure de connaître l'adresse IP du RU, le DU est en mesure de connaître l'adresse IP du CU, etc. En deuxième lieu, pour un fonctionnement optimal d’un tel réseau d’accès radio en nuage, soumis à des exigences de performances élevées, le respect de contraintes techniques rigoureuses est requis. À titre d’exemple, sur le plan des performance réseau, il est nécessaire pour l'unité distribuée DU de maintenir en permanence une connexion avec une latence inférieure à une milliseconde (pour un aller simple) avec une unité radio RU, une latence plus importante étant susceptible d’entrainer une désynchronisation des différents éléments du réseau d’accès radio en nuage, et donc de compromettre le bon fonctionnement de ce service. De manière similaire, il est nécessaire de garantir le respect d’une allocation de ressources minimale pour la mise en œuvre des différents éléments constitutifs du réseau d’accès radio en nuage, afin d'éviter toute défaillance du service. La FIG. 2 illustre un diagramme de séquence correspondant à un mode de réalisation particulier de la présente technique, dans lequel le déploiement DEP d’un tel réseau d’accès radio en nuage est mis en œuvre via une solution d’orchestration Kubernetes (étant entendu que le principe général présenté et les étapes ci-après décrites restent sensiblement les mêmes pour le déploiement de services autres qu’un Cloud-RAN et/ou via des solutions de déploiement automatisé d’applications conteneurisées autres que Kubernetes). Dans le mode de réalisation particulier illustré, le déploiement DEP du réseau d'accès en nuage est initié suite au téléversement ou à la détection, au sein d’un nœud de gestion NG de l’environnement distribué, dans une étape 1, d’un fichier de type déclaratif FD, dont le contenu décrit les composants logiciels à déployer, les interconnexions entre certains de ces composants logiciels, et des critères (ou spécifications) techniques à garantir lorsque ces composants logiciels sont en fonctionnement, c’est-à-dire dans une phase ultérieure d’exploitation EXP du service. Un exemple d’un extrait du contenu d’un tel fichier pour le déploiement d’un Cloud-RAN est illustré en relation avec la FIG. 3 . Plus particulièrement, un tel fichier FD liste des composants logiciels 31 à déployer (en l’espèce, pour le déploiement d’un réseau d'accès en nuage, des CU, DU et RU) ainsi que des caractéristiques techniques à garantir en relation avec ces composants logiciels. Selon une caractéristique particulière, ces critères techniques peuvent être répartis dans deux catégories principales : une première catégorie 32 comprenant des critères représentatifs de ressources allouées à garantir pour la mise en œuvre du composant logiciel considéré (ou de l’unité de virtualisation sur lequel il est instancié), et une deuxième catégorie 33 comprenant des critères représentatifs de performances cibles à garantir pour la mise en œuvre d’au moins un lien d’interconnexion entre le composant logiciel considéré et un au moins un autre composant logiciel ou une autre entité (par exemple une antenne) impliqués dans la mise en œuvre du service à déployer. À titre d’exemples non limitatifs, la première catégorie 32 comprend au moins un des critères suivants : - une quantité de disponibilité processeur 321 minimale à garantir ; - une quantité de mémoire vive 322 minimale à garantir ; - une quantité d’espace disque 323 minimale à garantir. À titre d’exemples non limitatifs, la deuxième catégorie 33 comprend par exemple au moins un des critères suivants : - une latence maximale 341 à garantir sur le lien d’interconnexion considéré ; - une gigue maximale 342 à garantir sur le lien d’interconnexion considéré ; - un taux maximal de perte de données 343 à garantir sur le lien d’interconnexion considéré. Outre les exemples 341, 342 et 343 précédents se rapportant plus particulièrement à des critères représentatifs de performances réseau cibles, la deuxième catégorie 33 peut également comprendre des critères de performances d’autres type, non représentés sur la FIG. 3 , tels que par exemple : - une consommation énergétique maximale à garantir (par exemple une consommation électrique maximale en watt par heure) pour les échanges de données sur le lien d’interconnexion considéré ; - un rendement énergétique à garantir pour les échanges de données sur le lien d’interconnexion considéré ; - un taux d’occupation maximal à garantir pour au moins une zone tampon de paquets ou de requêtes utilisée pour les échanges de données sur le lien d’interconnexion considéré ; - une taille de zone tampon de paquets ou de requêtes minimale et/ou maximale à garantir pour les échanges de données sur le lien d’interconnexion considéré ; - une valeur minimale et/ou maximale à garantir pour au moins un paramètre associé au support d’une sous-fonction de transport (par exemple un nombre de contextes HARQ sur un lien satellite, ou de chemins multiples « multipath », etc.) sur le lien d’interconnexion considéré. Le fichier déclaratif décrit également les liens d’interconnexions 34 auxquels les critères techniques de la deuxième catégorie 33 sont rattachés. Ainsi, dans l’exemple de l’extrait du fichier FD pour le déploiement d’un service de type réseau d'accès en nuage, des liens d’interconnexion 34 entre CU et DU, entre DU et RU, et entre RU et antenne sont déclarés. Comme illustré sur la FIG. 3 , plusieurs interconnexions avec un même composant logiciel peuvent être déclarées au sein d’un tel fichier FD : ainsi, dans l’extrait de fichier FD fourni en exemple, le CU est déclaré comme étant interconnecté avec un DU, mais également avec une autre entité identifiée par un identifiant « Other -Target-ID », des critères techniques de performance réseau différents pouvant être associés à chacun de ces liens d’interconnexion. Dans le cadre d’un déploiement orchestré par Kubernetes, le fichier déclaratif FD prend par exemple la forme d’un fichier de définition de ressources personnalisées (« Custom R esource s »), dont le contenu est injecté dans la base de données ETCD par le nœud de gestion NG, dans une étape 2 de la FIG. 2 . À détection, dans une étape 3, de ces ressources personnalisées dans la base ETCD, divers mécanismes sont enclenchés par un opérateur Kubernetes OP1 mis en œuvre au sein du nœud de gestion NG dans le cadre de la présente technique. Plus particulièrement, l’opérateur OP1, dit opérateur de déploiement, crée un fichier de configuration FC, dans une étape 4. Ce fichier de configuration, sensiblement vide à ce stade du procédé, est destiné à servir d’emplacement d’enregistrement d’informations de configuration au cours de la phase de déploiement DEP, qui seront par la suite utilisées en phase d’exploitation EXP du service pour corréler les différentes données reçues et réaliser les différentes opérations de contrôle des critères techniques à garantir. Dans le cadre d’un déploiement Kubernetes, un tel fichier peut par exemple prendre la forme d’un objet de type « ConfigMap ». Dans des étapes 5, 5’ et 5’’, l’opérateur de déploiement OP1 procède ensuite non seulement au déploiement des différents composants logiciels CL du service sur des unités de virtualisation UV de l’environnement distribué, mais également, de manière concomitante ou conjointe à ce déploiement, à l’instanciation, au sein de ces unités de virtualisation des composants de surveillance CS associés. Typiquement, pour le déploiement d’un service de type réseau d'accès en nuage (Cloud-RAN), des composants logiciels CL de type CU, DU et RU et des composants de surveillance CS associés sont déployés sur des unités de virtualisation UV_CU, UV_DU et UV_RU au sein de nœuds de calculs NC situés dans trois zones géographiques distinctes, i.e. respectivement dans des espaces de données régionaux RC (« Regional Cloud s » en anglais), des espaces de données d'extrémité EC (« Edge Clouds » en anglais), et des espaces de données de bordure FEC ( « F ar Edge Clouds » en anglais), de tels espaces étant notamment définis par l'alliance O-RAN (« Open Radio Access Network » en anglais). Lors de leur instanciation, les différents composants de surveillance CS sont notamment configurés de manière à pouvoir accéder en lecture/écriture au fichier de configuration FC précédemment créé à étape 4. Dans des étapes 6, 6’ et 6’’, des informations d’installation et/ou de déploiement générées par Kubernetes suite au déploiement des composants logiciels CL et des composants de surveillance CS sur les différentes unités de virtualisation UV_CU, UV_DU et UV_RU sont collectées par une application dédiée APP. De telles informations, transmises par les composants de surveillance CS à l’application APP, comprennent par exemple des données associées aux nœuds de calcul NC, aux unités de virtualisation UV_CU, UV_DU et UV_RU, aux composants logiciels et/ou aux composants de surveillance eux-mêmes. Ces données comprennent par exemple des identifiants générés pour ces différentes entités, des adresses IP (éventuellement associées à des ports) qui leur sont attribuées et auxquelles elles peuvent être contactées, etc. L’application dédiée APP se charge alors de filtrer et formater les données pertinentes pour la mise en œuvre d’une boucle de contrôle parmi ces informations collectées, puis de requérir auprès du nœud de gestion NG l’enregistrement dans le fichier de configuration FC précédemment créé de ces données pertinentes dans une étape 7. Le filtrage consiste par exemple à effectuer un tri dans les informations collectées pour ne conserver que celles en relation avec les critères techniques à contrôler, et le formatage à retranscrire ces données pertinentes dans un format compatible avec le fichier de configuration FC et interprétable ultérieurement par les différentes entités sollicitées pour le contrôle (opérateur de boucle de contrôle, composants de surveillance, etc.). De cette manière, des informations générés consécutivement au déploiement des composants logiciels CU, DU et RU sont associées et centralisées dans un emplacement unique, ce qui permet d’opérer une synchronisation entre ces informations, utiles à la mise en œuvre d’une boucle de contrôle BC créée ultérieurement, notamment pour effectuer un contrôle inter-entités (les différents composants déployés n’ayant pas par eux-mêmes connaissance de leurs existences mutuelles, par exemple le composant de surveillance CS du CU n’a pas la connaissance de l’existence du composant de surveillance CS du DU, le composant de surveillance CS du DU n’a pas la connaissance de l’existence du composant de surveillance CS du RU etc.). Aussi, l’étape 7 permet par exemple d’associer au moins un identifiant d’une unité de virtualisation, d’un composant logiciel et/ou d’un composant de surveillance avec au moins un identifiant respectivement d’une autre unité de virtualisation, d’un autre composant logiciel et/ou d’un autre composant de surveillance, au moins une partie desdits identifiants étant attribués consécutivement au déploiement du service. Dans une étape 8, l’application dédiée APP requiert également auprès du nœud de gestion NG la création de la boucle de contrôle BC. La boucle de contrôle BC est par exemple implémentée au moyen d’un objet Kubernetes de type « ClosedLoop » dont les paramètres sont enregistrés dans une étape 9 dans la base ETCD. Ces paramètres comprennent typiquement des paramètres de dépendances entre les unités de virtualisation (i.e. les liens d’interconnexion) et une liste des critères techniques à contrôler (i.e. les ressources allouées et/ou performances cibles à garantir). Dans une étape 10, un opérateur Kubernetes OP2 de boucle de contrôle mis en œuvre au sein du nœud de gestion NG détecte ces paramètres (qui peuvent prendre la forme de ressources personnalisées Kubernetes) dans la base ETCD, ce qui finalise les opérations d’instanciation de la boucle de contrôle BC, qui est alors opérationnelle. À ce stade, la phase initiale de déploiement DEP selon la présente technique peut être considérée comme terminée, et une phase d’exploitation EXP du service peut débuter, correspondant à une utilisation du service en question sous contrôle continu de la boucle de contrôle BC. Dans cette phase d’exploitation EXP, la boucle de contrôle BC met en œuvre de manière répétée des itérations de contrôle du respect des critères prédéfinis déclarés dans le fichier déclaratif FD, en fonction des métriques délivrées par les composants de surveillance et des données d’interconnexion enregistrées au sein du fichier de configuration FC. Chaque itération de contrôle comprend plus particulièrement les étapes 11 à 16 de la FIG. 2 , détaillées ci-après. En premier lieu, dans des étapes 11, 11’ et 11’’, les différents composants de surveillance CS procèdent à une vérification, au sein du fichier de configuration FC, d’une validité courante des données d’interconnexion entre composants logiciels. Une telle vérification vise à s’assurer que la configuration est bien toujours celle attendue, notamment que les affiliations faites entre CU, DU, RU, et d’autres éléments, par exemple de type antenne A, restent valides. En effet, un évènement en lien avec un composant déployé – par exemple un problème logiciel ou matériel – a pu entrainer la nécessité de redéployer ce composant, et donc d’entrainer une modification de sa configuration, auquel cas il est nécessaire de reparamétrer la boucle de contrôle BC avant de pouvoir l’utiliser. En d'autres termes, dans ces étapes 11, 11’ et 11’’, les composants de surveillance CS utilisent le fichier de configuration FC pour configurer ou éventuellement reconfigurer leurs processus de surveillance. Afin de s’adapter à ces éventuels changements de paramétrage, dans une étape 12, l’opérateur de boucle de contrôle OP2 surveille en continu les modifications faites sur l’objet de type « ClosedLoop » dans la base ETCD. Une fois ces vérifications et éventuelles adaptations effectuées, le contrôle effectif des critères techniques prédéfinis est mis en œuvre. En premier lieu, dans des étapes 13, 13’ et 13’’, les composants de surveillance CS mesurent et/ou collectent différentes données, afin de délivrer diverses métriques associées aux unités de virtualisation ou aux composants logiciels. Comme illustrée sur la FIG. 3 , ces métriques peuvent être de type intra-entité ou inter-entités, les métriques intra-entité étant par exemple relatives à des ressources actuellement allouées (RAM, CPU, espace disque, etc.) au sein d’une entité (typiquement une unité de virtualisation UV_CU ou UV_DU ou UV_RU), et les métriques inter-entités étant par exemple relatives à des performances actuelles sur un lien d’interconnexion entre entités (typiquement entre deux unités de virtualisation, entre UV_CU et UV_DU, ou entre UV_DU et UV_RU ou bien encore entre UV_RU et Antenne A). Dans des étapes 14, 14’ et 14’’, les composants de surveillance CS remontent ces différentes métriques en mettant à jour leurs données dans l'objet « ClosedLoop » de la base ETCD. Sur la base de ces métriques, l’opérateur de boucle de contrôle OP2 peut évaluer si l’ensemble des critères techniques prédéfinis dans le fichier déclaratif FD est respecté. Dans la négative (i.e. si au moins un de ces critères n’est pas respecté), l’opérateur de boucle de contrôle OP2 déclenche, dans des étapes 15, 15’ et 15’’, au moins une action correctrice en lien avec au moins un desdits composants logiciels et/ou au moins une desdites unités de virtualisation, de manière à ce que le respect de l’ensemble des critères techniques soit à nouveau vérifié. De telles actions correctrices comprennent, à titre d’exemples purement illustratifs et non limitatifs, une augmentation de la mémoire vive ou de la capacité processeur disponibles sur une unité de virtualisation, une augmentation du nombre de nœuds de calcul et/ou d’unités de virtualisation, une redistribution des composants logiciels sur les différentes infrastructures disponibles pour réduire d’éventuelles problématiques liées à des accès concurrents au processeur ou à la mémoire vive, notamment lorsque plusieurs services sont déployés et exploités de manière concomitante, etc. Dans un mode de réalisation particulier, dans une étape 16 optionnelle, l’opérateur de boucle de contrôle OP2 transmet à l’application dédiée APP des données de traces des opérations de contrôle effectuées (e.g. les valeurs de certaines métriques clés, les actions correctrices engagées, etc.), pour la mise en œuvre d’éventuels traitements complémentaires ultérieurs. L'application dédiée APP peut ainsi par exemple exposer ces données via une ou plusieurs interfaces de programmation d'application (API), afin qu’elles puissent être exploitées par des outils tiers. Bien qu’elle soit décrite précédemment dans des modes de réalisation en lien avec le déploiement d’un réseau d'accès en nuage, la présente technique n’est cependant pas limitée à une telle utilisation, qui est donnée uniquement à titre illustratif. La technique proposée présente en effet un intérêt particulier pour le déploiement dans un environnement distribué de toute application conteneurisée devant répondre à des exigences élevées de performance. Ainsi, de nombreux cas d’usage sont envisageables, notamment dans des systèmes industriels impliquant de nombreux équipements interconnectés, dans lesquels le temps de réaction du système est un facteur critique pour assurer la sécurité des personnes, et pour lesquels des temps de traitements rapides et des latences très faibles sont donc requis à tout instant. Il peut s’agir par exemple de couper en urgence le fonctionnement d’une ou plusieurs machines-outils en cas de détection, par un organe décisionnaire potentiellement distant, sur la base de données remontées par un réseau de caméras et autres capteurs, que l’intégrité physique d’un utilisateur est menacée. La technique proposée, dans son principe général et ses différents modes de réalisation, peut également être mis en œuvre en lien avec d’autres solutions de déploiement automatisé d’applications conteneurisées que Kubernetes. Par ailleurs, des alternatives pour la mise en œuvre de certaines des étapes décrites en relation avec la FIG. 2 peuvent être envisagées, dans d’autres modes de réalisation de la présente technique. Par exemple, une saisie directe via une interface homme-machine mise à disposition d’un utilisateur opérateur peut être envisagée en lieu et place de l’utilisation du fichier déclaratif FD introduit en relation avec l’étape 1, pour communiquer au nœud de gestion les informations relatives aux composants logiciels à déployer, aux interconnexions éventuelles entre certains de ces composants logiciels, et aux critères techniques à garantir. De façon similaire, des alternatives au recours à une application dédiée (l’application APP de la FIG. 2 ) peuvent être envisagées en relation avec les étapes 6, 6’, 6’’, 7 et 8 précédemment décrites, les opérations mises en œuvre dans le cadre de ces étapes pouvant, selon une caractéristique particulière, être gérées directement par le nœud de gestion NG, par exemple au moyen d’un nouvel opérateur Kubernetes de synchronisation. Dans certains modes de réalisation, les étapes 11, 11’ et 11’’ de vérification, au sein du fichier de configuration FC, d’une validité courante des données d’interconnexion entre composants logiciels peuvent éventuellement être optionnelles, ou à tout le moins ne pas être mise en œuvre à chaque itération de la boucle de contrôle BC mais à une fréquence moins élevée (par exemple toutes les deux, dix, ou cent itérations). Dispositif Selon un autre aspect, la technique proposée se rapporte également à un dispositif de déploiement d’un service dans un environnement distribué, apte à réaliser le procédé précédemment décrit dans l’un quelconque de ses modes de réalisation. Un tel dispositif comprend des moyens de déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation au sein dudit environnement distribué, ces moyens de déploiement étant mis en œuvre via un nœud de gestion dudit environnement distribué implémenté dans ledit dispositif. Ce dispositif comprend en outre les moyens suivants, mise en œuvre par ledit nœud de gestion : - des moyens d’instanciation, au sein d’une desdites unités de virtualisation, d’un composant de surveillance configuré pour délivrer au moins une métrique associée à ladite unité de virtualisation et/ou audit composant logiciel déployé sur ladite unité de virtualisation ; - des moyens d’enregistrement, au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels de ladite pluralité de composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - des moyens d’instanciation, au sein dudit nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’au moins une itération de contrôle du respect d’au moins un critère technique prédéfini, en fonction desdites métriques délivrées par au moins un desdits composants de surveillance et desdites données d’interconnexion enregistrées au sein dudit fichier de configuration. La FIG. 4 représente, de manière schématique et simplifiée, la structure d’un tel dispositif, dans un mode de réalisation particulier. Le dispositif selon la technique proposée comprend par exemple une mémoire 41 constituée d’une mémoire tampon M, une unité de traitement 42, équipée par exemple d’un microprocesseur μP, et pilotée par le programme d’ordinateur Pg 43, mettant en œuvre des étapes du procédé de déploiement automatisé d’un service dans un environnement distribué selon au moins un mode de réalisation de l’invention. À cette fin, le dispositif comprend également au moins une interface de communication (par exemple une interface de communication Ethernet), lui permettant de recevoir et d’émettre des messages en provenance et à destination d’autres équipements présents dans l’environnement distribué et contribuant à la mise en œuvre d’un service à déployer. À l’initialisation, les instructions de code du programme d’ordinateur 43 sont chargées dans la mémoire tampon avant d’être exécutées par le processeur de l’unité de traitement 42. L’unité de traitement 42 détecte en entrée E par exemple la présence d’un fichier de type déclaratif, dont le contenu décrit des composants logiciels à déployer pour la mise en œuvre d’un service dans un environnement distribué, des interconnexions éventuelles entre certains de ces composants logiciels, et des critères techniques à garantir lorsque ces composants logiciels sont en fonctionnement, c’est-à-dire dans une phase ultérieure d’exploitation du service. Le microprocesseur de l’unité de traitement 42 réalise alors les étapes du procédé de déploiement automatisé du service dans l’environnement distribué, selon les instructions du programme d’ordinateur 43. Plus particulièrement, sur la base des données contenues dans le fichier déclaratif reçu en entrée E, l’unité de traitement 42 effectue des opérations complémentaires au déploiement brut dudit service, comprenant l’instanciation de composants de surveillance associés aux composants logiciels du service, l’enregistrement de données d’interconnexion entre lesdits composants logiciels dans un fichier de configuration. L’unité de traitement 42 instancie finalement, en sortie S, une boucle de contrôle pour la mise en œuvre, dans une phase ultérieure d’exploitation dudit service, d’au moins une itération de contrôle du respect de critères techniques prédéfinis associés au fonctionnement dudit service, réalisée sur la base de métriques délivrées par lesdits composants de surveillance et en fonction des données d’interconnexion enregistrées dans ledit fichier de configuration. Procédé de déploiement d’un service dans un environnement distribué, comprenant le déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation au sein dudit environnement distribué, ledit procédé étant mis en œuvre au sein d’un nœud de gestion dudit environnement distribué et caractérisé en ce qu'il comprend : - l’instanciation (E1), au sein d’au moins une desdites unités de virtualisation, d’au moins un composant de surveillance configuré pour délivrer au moins une métrique associée à ladite unité de virtualisation ou à au moins un desdits composants logiciels déployé sur ladite unité de virtualisation ; - l’enregistrement (E2), au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels de ladite pluralité de composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - l’instanciation (E3), au sein dudit nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’au moins une itération de contrôle du respect d’au moins un critère technique prédéfini, en fonction de ladite au moins une métrique délivrée par au moins un desdits composants de surveillance et de ladite au moins une donnée d’interconnexion enregistrée au sein dudit fichier de configuration. Procédé selon la revendication 1 caractérisé en ce que ladite instanciation d’au moins un composant de surveillance au sein d’au moins une desdites unités de virtualisation est mise en œuvre conjointement ou concomitamment au déploiement d’au moins un desdits composants logiciels sur ladite unité de virtualisation. Procédé selon la revendication 1 caractérisé en ce que lesdits composants logiciels, lesdites interconnexions entre composants logiciels, et lesdits critères techniques sont définis au sein d’un fichier de type déclaratif, ledit déploiement étant effectué en fonction du contenu dudit fichier de type déclaratif. Procédé selon la revendication 1, caractérisé en ce que ledit enregistrement de données d’interconnexion au sein du fichier de configuration et ladite instanciation de la boucle de contrôle sont initiés sur requête d’une application dédiée, en fonction de données collectées par ladite application dédiée suite au déploiement desdits composants logiciels et à l’instanciation desdits composants de surveillance sur lesdites unités de virtualisation. Procédé selon la revendication 1, caractérisé en ce qu’au moins une itération mise en œuvre par ladite boucle de contrôle comprend un contrôle du respect d’au moins un critère technique représentatif d’au moins une ressource allouée pour la mise en œuvre d’au moins un desdits composant logiciels. Procédé selon la revendication 1, caractérisé en ce qu’au moins une itération mise en œuvre par ladite boucle de contrôle comprend un contrôle du respect d’au moins un critère technique représentatif d’au moins une performance cible pour la mise en œuvre d’au moins un lien d’interconnexion entre lesdits composant logiciels. Procédé selon la revendication 5, caractérisé en ce que ledit au moins un critère technique représentatif d’au moins une ressource allouée appartient au groupe comprenant : - une quantité d’espace disque minimale ; - une quantité de mémoire vive minimale ; - une quantité de disponibilité processeur minimale. Procédé selon la revendication 6, caractérisé en ce que ledit au moins un critère technique représentatif d’au moins une performance cible appartient au groupe comprenant : - une latence maximale sur ledit lien d’interconnexion entre lesdits composant logiciels ; - une gigue maximale sur ledit lien d’interconnexion entre lesdits composant logiciels ; - un taux maximal de perte de données sur ledit lien d’interconnexion entre lesdits composant logiciels. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, préalablement ou au début de chaque itération de contrôle de ladite boucle de contrôle, une étape de vérification, au sein dudit fichier de configuration, par lesdits composants de surveillance, d’une validité courante desdites données d’interconnexion entre composants logiciels. Procédé selon la revendication 1 caractérisé en ce qu'il comprend, lorsque au moins un desdits critères techniques prédéfinis n’est pas respecté, l’exécution d’une action correctrice en lien avec au moins un desdits composants logiciels et/ou au moins une desdites unités de virtualisation. Procédé selon la revendication 1 caractérisé en ce que au moins un desdits critères prédéfinis est associé au fonctionnement dudit service. Procédé caractérisé en ce que ledit service est un réseau d’accès radio en nuage (CRAN), et en ce que lesdits composants logiciels comprennent au moins une unité radio (RU), au moins une unité distribuée (DU), et au moins une unité centralisée (CU). Dispositif de déploiement d’un service dans un environnement distribué, comprenant des moyens de déploiement d’une pluralité de composants logiciels dudit service sur une pluralité d’unités de virtualisation au sein dudit environnement distribué, ledit dispositif implémentant un nœud de gestion dudit environnement distribué et étant caractérisé en ce qu'il comprend : - des moyens d’instanciation, au sein d’au moins une desdites unités de virtualisation, d’au moins un composant de surveillance configuré pour délivrer au moins une métrique associée à ladite unité de virtualisation et/ou à au moins un desdits composants logiciels déployé sur ladite unité de virtualisation ; - des moyens d’enregistrement, au sein d’un fichier de configuration, d’au moins une donnée d’interconnexion entre des composants logiciels de ladite pluralité de composants logiciels, associant au moins un identifiant d’une unité de virtualisation et au moins un identifiant d’une autre unité de virtualisation ; - des moyens d’instanciation, au sein dudit nœud de gestion, d’une boucle de contrôle pour la mise en œuvre, dans une phase d’exploitation dudit service, d’au moins une itération de contrôle du respect d’au moins un critère technique prédéfini, en fonction de ladite au moins une métrique délivrée par au moins un desdits composants de surveillance et de ladite au moins une donnée d’interconnexion enregistrée au sein dudit fichier de configuration. Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l'une quelconque des revendications 1 à 12, lorsqu’il est exécuté par un ordinateur.