Brevet FR3157612A1 — publié le 20250627

Procédé d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge de service. L’invention se rapporte à un procédé d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication. Le procédé est mis en œuvre par une entité de pré-déploiement (EPD), et il comprend, en amont d’une augmentation (AC) de ladite charge du service de communication, une phase de configuration partielle (P1) d’au moins un serveur d’un groupe de serveurs de réserve, dite phase de pré-déploiement, comprenant l’émission à destination d’une entité de déploiement (ED) d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre du service de communication. Figure d’abrégé : Figure 1 Procédé d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge de service. L’invention se situe dans le domaine de la répartition de charge sur un ensemble de ressources informatiques. Plus particulièrement la présente invention concerne les mécanismes de mise à l’échelle, selon lesquels un nombre de ressources déployées pour la mise en œuvre d’un service est adapté automatiquement en fonction de la charge de service à absorber. 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. Une architecture Kubernetes intègre notamment divers mécanismes de répartition de charge, dont des mécanismes dits de mise à l’échelle horizontale ( « horizontal scaling » , en anglais) qui permettent d’adapter automatiquement le nombre de ressources (par exemple, le nombre de nœuds de virtualisation, ou encore 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 à mettre en œuvre, c’est-à-dire un niveau de charge courant que le système doit être en capacité d’absorber afin de garantir une qualité satisfaisante du service fourni. Ainsi, en réponse à une augmentation de la charge par exemple, un nombre plus important de nœuds de virtualisation peut être déployé. Le déploiement d’une nouvelle grappe de nœuds de virtualisation (ou « cluster ») sur un serveur informatique nécessite toutefois de nombreuses opérations préalables de configuration de ce serveur qui, bien qu’elles soient automatisées, prennent du temps. Ces opérations, orchestrées par une entité de déploiement, comprennent par exemple l’installation d’un système d'exploitation adapté au contexte de mise en œuvre du service, l’installation de librairies informatiques, l’installation de composants Kubernetes, l’installation de composants logiciels complémentaires éventuellement nécessaires, etc. Ainsi, lorsqu’elles impliquent la configuration d’un nouveau serveur, on estime que quinze à vingt minutes sont actuellement nécessaires entre le moment où une décision est prise d’augmenter le nombre de ressources affectées à un service pour faire face à une hausse de charge, et le moment où les ressources supplémentaires demandées sont effectivement opérationnelles pour contribuer à la mise en œuvre du service. Durant ce temps de déploiement, le service est susceptible d’être dégradé dans la mesure où les conditions de ressources minimales pour assurer un fonctionnement nominal du service ne sont plus réunies. Par ailleurs, pour certaines applications critiques pour lesquelles un simple ralentissement du service est 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, un tel temps de déploiement est souvent rédhibitoire. Une solution classique à ce problème consiste à surdimensionner le système, en prévoyant et en maintenant actif en continu un nombre de ressources supérieur à celui nécessaire pour absorber une charge de service moyenne ou élevée du service, de manière à ce que le système soit en mesure de faire face sans délai à une augmentation temporaire plus ou moins prolongée de la charge, sans qu’il soit nécessaire de configurer de nouveaux serveurs. Une telle solution n’est cependant pas idéale. D’une part elle mobilise en continu des ressources informatiques, typiquement des serveurs, et ceci de manière stérile la plupart du temps, puisque ces ressources « de réserve » ne sont sollicitées que sur des périodes ponctuelles de hausse de charge. De ce fait, bien que non utilisées une majeure partie du temps, ces ressources ne peuvent pas être mises à disposition d’autres services qui pourraient en avoir besoin. D’autre part, un tel surdimensionnement du système a des impacts en termes de consommation énergétique, avec en particulier une augmentation de la consommation électrique. À l’heure où les enjeux d’économies de ressources – tant énergétiques que matérielles – sont devenus critiques, il existe donc un besoin pour des solutions alternatives permettant 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é d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication. Selon le principe général de l’invention proposée, un tel procédé, mis en œuvre au sein d’une entité de pré-déploiement comprend, en amont d’une augmentation de ladite charge du service de communication, une phase de configuration partielle d’au moins un serveur d’un groupe de serveurs de réserve, dite phase de pré-déploiement, comprenant l’émission à destination d’une entité de déploiement d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre dudit service de communication. De cette manière, la phase de pré-déploiement permet de réaliser de manière anticipée, c'est à dire préalablement à un éventuel besoin de montée en charge du service de communication, des opérations réputées chronophages lorsqu’il s’agit de configurer des serveurs, à savoir l’installation d’un système d'exploitation et d’une solution de déploiement automatisé d’applications conteneurisées. De cette manière, la durée de mise à l’échelle en réponse à une détection ultérieure éventuelle d’une augmentation de charge pour le service considéré est réduite à celle nécessaire pour effectuer des opérations visant à terminer une configuration déjà réalisée dans sa majeure partie. Le temps de réaction du système pour retrouver un fonctionnement nominal suite une telle hausse de charge est de ce fait considérablement réduit. Par ailleurs, les serveurs configurés de manière partielle dans la phase de pré-déploiement ne sont pas spécifiquement attachés à un service de communication particulier : leur configuration n’étant à ce stade pas finalisée, ils constituent des ressources dites de réserve, qui sont susceptibles d’être utilisées indifféremment par différents services, en fonction des besoins en charge et des caractéristiques techniques associés à ces services. De cette manière, on évite ainsi d’attacher à plein temps des ressources à un service spécifique, alors même que la probabilité est importante que de telles ressources ne soient utilisées que de façon ponctuelle par ledit service. Le procédé permet donc, outre une adaptation plus rapide d’une infrastructure virtualisée, à une montée en charge d’un ou plusieurs services de communication, de pouvoir ajuster l’infrastructure virtualisée aux besoins, préservant les ressources de communication, logicielles et énergétiques. Dans un mode de réalisation particulier, ledit au moins un composant appartient au groupe comprenant : - un utilitaire ; - une librairie informatique ; - un fichier de configuration ; - un moteur d’intelligence artificielle ; - une composante élémentaire dudit service de communication. De cette manière, les opérations de configuration partielle dudit au moins un serveur peuvent porter sur des composants variés et multiples. Ainsi, un grand nombre de composants peut faire l’objet d’une pré-configuration, de manière flexible, dans le cadre d’une phase de pré-déploiement selon la présente technique, réduisant d’autant le temps nécessaire pour finaliser leur configuration en cas de détection éventuelle d’une hausse de charge du service de communication. Dans un mode de réalisation particulier, ladite phase de pré-déploiement est mise en œuvre sur la base d’un fichier de type déclaratif préalablement obtenu par ladite entité de pré-déploiement. De cette manière, la phase de pré-déploiement est particulièrement simple à mettre en œuvre pour un opérateur de service, puisqu’il lui suffit de déclarer au sein d’un simple fichier, via des entrées de type clé-valeur, les caractéristiques des configurations partielles qu’il souhaite voir déployées. De cette manière, la phase de pré-déploiement peut également être déclenchée à l’initiative d’un système informatique tiers adapté pour générer automatiquement un tel fichier déclaratif. Selon une caractéristique particulière, ledit fichier déclaratif comprend au moins : - un type et une version dudit système d'exploitation à installer sur ledit au moins un serveur ; - un type et une version de ladite solution de déploiement automatisé d’applications conteneurisées à installer sur ledit au moins un serveur ; - un nombre de serveurs à partiellement configurer au sein dudit groupe de serveurs de réserve, pour lesdits types et versions dudit système d'exploitation et de ladite solution de déploiement automatisé d’applications conteneurisées. De cette manière, la technique proposée permet de pré-déployer différents types de configuration partielle, chacun associé à un système d'exploitation particulier et/ou une solution de déploiement automatisé d’applications conteneurisées particulière, sur un nombre prédéfini choisi de serveurs. De cette manière, il est possible de mettre en œuvre plusieurs stratégies de pré-déploiements, chacune en lien avec un sous-groupe différent d’un groupe de serveurs de réserve, permettant ainsi au procédé selon la présente technique d’être particulière adapté et flexible pour répondre à un grand nombre de situations, notamment en termes de diversité de service de communication à prendre à en charge. Dans un mode de réalisation particulier, ladite émission d’une demande d’installation est conditionnée à une vérification préalable, auprès d’un serveur de gestion d’habilitation : - que ladite entité de déploiement est autorisée à effectuer ladite installation dans le cadre de ladite phase de pré-déploiement ; et/ou - que ledit au moins un serveur dudit groupe de serveurs de réserve est autorisé à faire l’objet de ladite installation dans le cadre de ladite phase de pré-déploiement. De cette manière, des contrôles sont effectués avant d’opérer un pré-déploiement, de manière à se prémunir de tout pré-déploiement intempestif tel par exemple qu’un pré-déploiement sur un serveur qui ne serait pas destiné à de telles opérations ou de pré-déployer un trop grand nombre de serveurs par exemple. Dans un mode de réalisation particulier, ladite phase de pré-déploiement comprend : - l’obtention, au sein d’une structure de données associée audit groupe de serveurs de réserve, d’au moins une donnée identifiant un ensemble de serveurs disponibles pour la mise en œuvre dudit service de communication, au sein dudit groupe de serveurs de réserve ; - la sélection, au sein desdits serveurs disponibles identifiés, dudit au moins un serveur objet de ladite demande d’installation, en fonction du contenu dudit fichier de type déclaratif et de caractéristiques techniques associées auxdits serveurs disponibles, obtenues dans ladite structure de données. De cette manière, des contrôles sont effectués pour s’assurer qu’un serveur de réserve retenu pour faire l’objet d’une configuration partielle définie dans un fichier déclaratif est bien disponible et présente bien des caractéristiques techniques suffisantes pour une telle opération. Selon une caractéristique particulière, ladite émission d’une demande d’installation comprend le téléversement, au sein d’un système de gestion de version associé à ladite entité de déploiement, d’au moins un fichier de déploiement comprenant des informations de configuration partielle dudit au moins un serveur sélectionné, ledit au moins un fichier de déploiement étant généré en fonction du contenu dudit fichier déclaratif et desdites caractéristiques techniques associées audit au moins un serveur sélectionné. De cette manière, des mécanismes classiques proches de ceux mis en œuvre dans le cadre d’une configuration complète de serveur, incluant le téléversement de fichiers de configuration dans un système de gestion de version associé une entité de déploiement, sont exploités pour procéder aux opérations de configuration partielle des serveurs sélectionnés. La mise en œuvre de ces opérations est ainsi simplifiée. Dans un mode de réalisation particulier, ledit procédé comprend, en réponse à une augmentation de charge dudit service de communication : - la sélection, parmi ledit au moins un serveur partiellement configuré dans ladite phase de pré-déploiement, d’au moins un serveur dont la configuration partielle est compatible avec un fichier descriptif de demande de déploiement obtenu par ladite entité de pré-déploiement suite à une détection de ladite augmentation de charge ; - la finalisation de la configuration dudit au moins un serveur partiellement configuré sélectionné, délivrant un serveur opérationnel pour la mise en œuvre dudit service de communication. De cette manière, la durée entre le moment où une décision est prise d’augmenter le nombre de ressources affectées à un service pour faire face à une hausse de charge et le moment où les ressources supplémentaires demandées sont effectivement opérationnelles pour contribuer à la mise en œuvre du service est substantiellement réduite. Dans un mode de réalisation particulier, une détermination de la compatibilité de ladite configuration partielle avec ledit fichier descriptif de demande de déploiement comprend une vérification que le système d’exploitation et l’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées installés sur ledit au moins un serveur partiellement configuré sélectionné sont compatibles avec la mise en œuvre dudit service de communication. Dans un mode de réalisation particulier, ladite sélection dudit au moins un serveur comprend la prise en compte d’une localisation dudit au moins un serveur, au regard d’au moins une information de localisation comprise dans ledit fichier descriptif de demande de déploiement, déterminée en fonction d’une nature dudit service de communication. De cette manière, des caractéristiques propres au service de communication faisant face à une hausse de charge, telles que sa nature ou des caractéristiques techniques associées à ce service, sont prises en considération pour la sélection et la configuration finale des serveurs de réserve à affecter audit service pour contribuer à absorber ladite hausse de charge. Dans un mode de réalisation particulier, ladite finalisation de la configuration est conditionnée à une vérification préalable, auprès d’un serveur de gestion d’habilitation, que ledit au moins un serveur partiellement configuré sélectionné est autorisé à faire l’objet de ladite finalisation de configuration. Dans un mode de réalisation particulier, ladite finalisation de la configuration est conditionnée à une vérification préalable, au sein d’une structure de données associée audit groupe de serveurs de réserve, que ledit au moins un serveur partiellement configuré sélectionné est disponible pour la mise en œuvre dudit service de communication. De cette manière, des contrôles sont effectués avant de finaliser la configuration d’un serveur de réserve sélectionné, afin de s’assurer que ce serveur est bien toujours disponible et toujours autorisé à faire l’objet d’une telle opération. Toute modification éventuelle de disponibilité et/ou d’autorisation survenue postérieurement aux opérations de configuration partielle de ce serveur en phase de pré-déploiement peut ainsi être détectée et prise en compte. Dans un mode de réalisation particulier, ladite finalisation de la configuration comprend : - la génération, sur la base dudit fichier descriptif de demande de déploiement, d’au moins une information de configuration dudit au moins un serveur partiellement configuré sélectionné ; - la configuration, sur ledit au moins un serveur partiellement configuré sélectionné, sur la base de ladite au moins une information de configuration, d’au moins un nœud de virtualisation selon ladite solution de déploiement automatisé d’applications conteneurisées, pour la mise en œuvre dudit service de communication. De cette manière, des ressources supplémentaires adaptées pour aider à absorber la charge du service de communication sont disponibles et opérationnelles. Selon un autre aspect, l’invention se rapporte à une entité de pré-déploiement pour l’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication. Une telle entité comprend des moyens de configuration partielle d’au moins un serveur d’un groupe de serveurs de réserve, dits moyens de pré-déploiement, mis en œuvre en amont d’une augmentation de ladite charge du service de communication, lesdits moyens de pré-déploiement comprenant des moyens d’émission, à destination d’une entité de déploiement, d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre dudit service de communication. Une telle entité peut bien sûr présenter les différentes caractéristiques relatives au procédé d’optimisation selon l’invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette entité sont les mêmes que ceux du procédé d’optimisation, 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é d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge de service, dans un mode de réalisation particulier de la technique proposée ; FIG. 2 présente un diagramme de séquence illustrant une première phase, dite de pré-déploiement aussi appelée déploiement partiel, du procédé d’optimisation, 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 configurations de pré-déploiement à opérer, dans un mode de réalisation particulier de la technique proposée ; FIG. 4 présente un diagramme de séquence illustrant une deuxième phase, dite de finalisation de déploiement, du procédé d’optimisation, dans un mode de réalisation particulier de la technique proposée ; FIG. 5 décrit une architecture simplifiée d’un module de pré-déploiement d’une entité de pré-déploiement 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é d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication, mis en œuvre par une entité de pré-déploiement. La technique proposée se rapporte plus particulièrement à des techniques permettant d’optimiser la durée de mise à l’échelle automatique horizontale (« Horizontal Autoscaling » ) d’une solution de déploiement automatisé d’applications conteneurisées telle que Kubernetes par exemple. Le principe général de la technique proposée, illustré en relation avec la FIG. 1 dans un mode de réalisation particulier, consiste à configurer de manière partielle et anticipée au moins un serveur de réserve préalablement à un besoin de montée en charge AC d’un service de communication, c’est-à-dire dans une phase amont des moments où une charge de service est susceptible d’évoluer à la hausse (par exemple, avant la mise en exploitation du service de communication, ou lorsque l’infrastructure courante déployée pour la mise en œuvre du service de communication est encore en capacité d’absorber une charge de service observée). Plus particulièrement, une telle phase de configuration partielle, également dénommée phase de pré-déploiement P1 dans le cadre de la présente technique, comprend l’installation, sur un ou plusieurs serveurs de réserve, d’un système d'exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées. Le service de communication peut être un service à valeur ajoutée, c’est-à-dire un service voix, texte, ou vidéo à destination d’un ou plusieurs clients du service de communication ou il peut également s’agir d’un service propre à un opérateur de communication, par exemple un service de communication d’un plan de contrôle ou d’administration d’un réseau de communication. La montée en charge requise pour le service de communication peut correspondre à un besoin d’accès d’un nombre plus important de terminaux au service de communication ou bien encore à une plus grande richesse fonctionnelle du service de communication requérant des temps de traitement plus importants pour la gestion des données relatives au service de communication. Un service de communication pouvant plus particulièrement bénéficier du procédé d’optimisation concerne, à titre d’exemple, un jeu en réseau où il apparait très important d’une part d’adapter l’infrastructure à la diversité géographique des joueurs accédant au jeu ainsi qu’à la montée en charge induite par un nombre de joueurs se connectant simultanément au jeu en réseau. Sachant que la faible latence est un enjeu crucial pour les joueurs accédant à ce service de communication et qu’il est très important de répondre de façon très dynamique et très rapide aux exigences de montée en charge induite par une croissance potentiellement importante du nombre de joueurs dans un laps de temps assez court, le procédé permet avantageusement de pouvoir réduire le temps de montée en charge de l’infrastructure et ainsi de répondre aux exigences des utilisateurs. Le procédé est notamment adapté à la future mise en œuvre d’applications de jeux accessibles par une technologie de streaming dans des nœuds de CDN (en anglais Content Delivery Networks) tels que ceux spécifiés par l’organisation SVTA (en anglais Streaming Video Technology Alliance) Open Caching et le groupe de travail IETF CDNi (Content Delivery Networks Interconnection). Dans un mode de réalisation particulier, le système d'exploitation et les composants d’une solution de déploiement automatisé d’applications conteneurisées ainsi installés sur un serveur de réserve durant la phase de pré-déploiement P1 correspondent à des éléments logiciels dont la probabilité qu’ils soient compatibles avec des services de communication déjà déployés ou à déployer sur un réseau de communication est élevée. En d'autres termes, il est proposé selon la présente technique d’opérer une configuration en deux temps des serveurs qui sont potentiellement amenés à être utilisés pour contribuer à absorber une augmentation de charge ponctuelle d’un service de communication : - dans un premier temps, une configuration partielle P1 est effectuée par anticipation, c’est-à-dire avant même qu’une telle augmentation de charge ne soit constatée, aussi la durée d’une telle phase de pré-déploiement n’est pas un facteur critique ; - dans un deuxième temps, et seulement lorsque la situation l’exige, c’est-à-dire par exemple face à une hausse de charge AC soudaine, une finalisation P2 de la configuration, de manière à rendre le serveur opérationnel aussi rapidement que possible pour contribuer à l’absorption de la charge observée. Plus particulièrement, grâce à la présente technique, la durée de mise à l’échelle en réponse à une augmentation de charge AC est réduite à celle nécessaire pour effectuer des opérations visant à terminer une configuration déjà bien avancée dans une deuxième phase P2 dite de finalisation de configuration, les opérations de configuration les plus chronophages (par exemple l’installation d’un système d'exploitation) ayant déjà été effectuées en amont dans la phase de pré-déploiement P1. Typiquement, avec la technique proposée, moins de trois minutes (une à deux minutes dans la plupart des cas) s’écoulent entre le moment où une décision est prise d’augmenter le nombre de ressources affectées à un service pour faire face à une hausse de charge, et le moment où les ressources supplémentaires demandées sont effectivement opérationnelles pour contribuer à la mise en œuvre du service (contre dix à quinze minutes avec le mécanisme existant classique de mise à l’échelle présenté en relation avec l’art antérieur). Outre ce gain de temps de réaction substantiel, la présente technique permet par ailleurs de ne pas mobiliser en continu des serveurs en tant que serveurs de secours associés à un unique service, contrairement à la solution classique de surdimensionnement de système déjà décrite en relation avec l’art antérieur. En effet, les serveurs configurés de manière partielle dans la phase de pré-déploiement P1 selon la présente technique ne sont pas dédiés à la mise en œuvre d’un unique service prédéfini. Au contraire, ils appartiennent plus particulièrement à un groupe de serveurs dits de réserve, qui constituent des ressources qui sont susceptibles d’être utilisées indifféremment par différents services, en fonction des besoins. En d'autres termes, un serveur de réserve S1 peut être affecté à un service A durant une période temporaire de hausse de charge de ce service A, puis plus tard affecté à un service B durant une période temporaire de hausse de charge du service B. Présentation d’un mode de réalisation particulier Dans la suite du document, les phases de pré-déploiement P1 et de finalisation de déploiement P2 sont décrites de manière plus détaillée, dans divers modes de réalisation particuliers de la technique proposée, dans lequel le déploiement du service est mis en œuvre via une solution d’orchestration Kubernetes (étant entendu que le principe général présenté précédemment et les étapes ci-après décrites restent sensiblement les mêmes pour le déploiement de services via des solutions de déploiement automatisé d’applications conteneurisées autres que Kubernetes). La FIG. 2 est un diagramme de séquence illustrant la mise en œuvre d’une phase de pré-déploiement P1, dans un mode de réalisation particulier. Une telle phase de pré-déploiement est mise en œuvre au niveau d’une entité de pré-déploiement EPD. Dans une étape 201, un administrateur, éventuellement par l’intermédiaire d’un système logiciel d’administration, manifeste son souhait d’autoriser une entité de déploiement ED à effectuer des opérations de pré-configuration d’un ou plusieurs serveurs, i.e. du pré-déploiement, selon la présente technique. À cette fin, il transmet lors de cette étape 201 à un serveur de gestion d’habilitation SGH de l’entité de pré-déploiement EP une indication en ce sens, et reçoit en retour, dans une étape 202, une confirmation que l’entité de déploiement ED est maintenant identifiée au sein du serveur de gestion d’habilitation SGH comme autorisée à effectuer des opérations de pré-déploiement. Une telle entité de déploiement ED correspond par exemple à une entité apte à configurer des serveurs, y compris une configuration intégrale telle que décrite en relation avec l’art antérieur. Dans une étape 203, l’administrateur communique également au serveur de gestion d’habilitation SGH des identifiants de serveurs ou des types de serveurs qu’il souhaite autoriser à être pré-déployés, par exemple en fonction de la zone géographique où ils sont localisés. Par exemple, l’administrateur transmet au serveur de gestion d’habilitation SGH un ou plusieurs identifiants de serveurs particuliers, ou une information selon laquelle il souhaite autoriser le pré-déploiement pour des serveurs situés dans des espaces de données particuliers, tels que des serveurs SV_RC situés dans des espaces de données régionaux (« Regional Clouds » en anglais), des serveurs SV_EC situés dans des espaces de données d'extrémité (« Edge Clouds » en anglais), ou encore des serveurs SV_FEC situés dans des espaces de données de bordure ( « Far Edge Clouds » en anglais), de tels espaces étant notamment définis par l'alliance O-RAN (« Open Radio Access Network » en anglais). L’administrateur reçoit en retour, dans une étape 204, une confirmation que les serveurs ou types de serveurs choisis sont maintenant bien identifiés au sein du serveur de gestion d’habilitation SGH comme autorisés à faire l’objet d’opérations de pré-déploiement selon la présente technique. Dans le mode de réalisation particulier illustré en FIG. 2 , le pré-déploiement est initié suite au téléversement, dans une étape 205, d’un fichier de type déclaratif FD au sein d’un module de pré-déploiement MPD (par exemple mis en œuvre sous forme d’un opérateur Kubernetes) de l’entité de pré-déploiement EPD. Le fichier déclaratif FD contient des informations utiles au pré-déploiement à effectuer, relatives notamment au système d'exploitation et aux composants de la solution de déploiement à déployer sur un ou plusieurs serveurs de réserve. Un exemple d’un extrait du contenu d’un tel fichier déclaratif FD est illustré en relation avec la FIG. 3 . Plus particulièrement, le fichier FD liste une ou plusieurs opérations de pré-déploiement à mettre en œuvre, associées chacune à un type et une version de système d'exploitation 31 et de solution de déploiement 32 à installer, à une entité de déploiement 33 à utiliser pour effectuer le pré-déploiement, et à un nombre 34 de serveurs de réserve à pré-déployer. Sur l’exemple de la FIG. 3 , sont ainsi par exemple définies : - une première demande de pré-déploiement de référence name_deployment_1 , selon laquelle il est demandé à une entité de déploiement kanod_name_1 de pré-déployer dix serveurs en y installant le système d'exploitation Ubuntu en version 23.04 et les composants nécessaires de la solution de déploiement Kubernetes en version 1.15 ; - une deuxième demande de pré-déploiement de référence name_deployment_ 2 , selon laquelle il est demandé à une entité de déploiement kanod_name_ 2 de pré-déployer cinq serveurs en y installant le système d'exploitation Debian en version 12.4 et les composants nécessaires de la solution de déploiement Kubernetes en version 1.10. Le fichier déclaratif présenté en FIG. 3 est donné à titre purement illustratif et non limitatif. En particulier, des informations complémentaires autres que celles listées précédemment sont susceptibles d’être déclarées en lien avec une demande de pré-déploiement donnée. De telles informations complémentaires comprennent par exemple des informations portant sur différents types de composants à installer en relation avec une solution de déploiement automatisé d’applications conteneurisées déclarée dans le fichier déclaratif FD, telles que des informations relatives à l’installation d’utilitaires, de librairies logicielles particulières, de moteurs d’intelligence artificielle, de fichiers de configuration particuliers, de composante élémentaire associées au service de communication, etc. À détection de la présence d’un tel fichier déclaratif FD, divers mécanismes sont enclenchés au niveau du module de pré-déploiement MPD de l’entité de pré-déploiement EPD, comme illustré sur la FIG. 2 . En premier lieu, le module de pré-déploiement MPD interroge dans une étape 206 le serveur de gestion d’habilitation SGH, afin de vérifier que l’entité de déploiement associée à une opération de pré-déploiement dans le fichier déclaratif FD, par exemple l’entité de déploiement ED de la FIG. 2 , est bien autorisée à effectuer des opérations de pré-déploiement. Si tel est le cas, le module de pré-déploiement MPD obtient confirmation de cette autorisation du serveur de gestion d’habilitation SGH, dans une étape 207. Le module de pré-déploiement MPD émet ensuite, dans une étape 208, une requête à destination d’une structure de données BDD de l’entité de pré-déploiement EPD, qui contient des informations relatives aux serveurs d’un groupe de serveurs de réserve utilisables pour la mise en œuvre de services de communication. Au moins une partie de ces informations peut notamment avoir été insérée dans la structure de données BDD de manière conjointe à l’étape 203 préalablement décrite, dans laquelle des serveurs sont autorisés à faire l’objet d’une configuration partielle selon la présente technique. La requête émise en étape 208 vise plus particulièrement à déterminer une liste de serveurs actuellement disponibles pour la mise d’un service de communication. Dans une étape 209, en réponse à cette requête, la structure de données BDD transmet au module de pré-déploiement MPD une telle liste de serveurs disponibles (sous forme par exemple de données permettant d’identifier ces serveurs, par exemple des adresses IP ou tout autre identifiant tel que par exemple un identifiant DNS), ainsi que des informations associées, typiquement des caractéristiques techniques liées à ces serveurs. Dans une étape 210, en fonction des informations de configuration déclarées dans le fichier déclaratif FD obtenu en étape 205 et éventuellement des informations complémentaires associées aux serveur disponibles identifiés en étape 209, le module de pré-déploiement MPD sélectionne parmi ces serveurs disponibles ceux qui doivent faire l’objet d’un pré-déploiement, autrement dit d’une configuration partielle selon la présente technique. Par exemple, en référence à l’exemple de la FIG. 3 , dans le cadre de la demande de pré-déploiement référencée name_deployment_1 , le module de pré-déploiement MPD sélectionne dix serveurs parmi les serveurs disponibles du groupe de serveurs de réserve, qui présentent des caractéristiques techniques compatibles avec les informations de configuration déclarées dans le fichier déclaratif FD, typiquement des caractéristiques techniques suffisantes pour y installer le système d'exploitation Ubuntu en version 23.04 et la solution de déploiement Kubernetes en version 1.15. Le module de pré-déploiement MPD vérifie également auprès du serveur de gestion d’habilitation, dans une étape 211, que les serveurs sélectionnés sont bien autorisés à être déployés. Dans l’éventualité où un ou plusieurs des serveurs sélectionnés ne répondent pas à ce critère, le module de pré-déploiement MPD peut éventuellement procéder à une nouvelle sélection de serveurs parmi les serveurs disponibles, jusqu’à atteindre le nombre de serveurs souhaité tel que déclarés dans le fichier déclaratif FD. Dans une étape 212, le module de pré-déploiement MPD obtient par exemple confirmation auprès du serveur de gestion d’habilitation que les serveurs sélectionnés sont bien tous autorisés à être utilisés pour des opérations de configuration partielle dans le cadre d’une phase de pré-déploiement selon la présente technique. Dans une étape 213, une fois les habilitations vérifiées et confirmées, le module de pré-déploiement MPD téléverse des fichiers de pré-déploiement dans un système de gestion de version GIT associé à l’entité de déploiement ED identifiée dans le fichier déclaratif FD pour l’opération de pré-déploiement considérée (par exemple, pour la demande de pré-déploiement référencée name_deployment_1 dans l’exemple de la FIG. 3 , les fichiers de pré-déploiement sont téléversés dans le système de gestion de version associé à l’entité de déploiement référencée kanod_name_1 ). Ces fichiers de pré-déploiement sont par exemple construits sur la base des informations déclarées dans le fichier déclaratif FD et des caractéristiques techniques des serveurs finalement sélectionnés, et ils recensent l’ensemble des informations utiles afin qu’un module de déploiement MD de l’entité de déploiement ED puisse procéder à la configuration partielle requise de ces serveurs. Par le biais de cette transmission des fichiers de pré-déploiement, l’entité de pré-déploiement EPD émet à destination de l’entité de déploiement ED une demande d’effectuer les configurations partielles souhaitées des serveurs sélectionnés, telles que définies dans le fichier déclaratif FD. L’entité de déploiement ED effectue alors les opérations requises, selon un mécanisme classique proche de celui mis en œuvre dans le cadre d’une configuration complète de serveur selon l’art antérieur. Plus particulièrement, dans une étape 214, le module de déploiement MD détecte la présence de ces nouveaux fichiers de pré-déploiement dans le système de gestion de version GIT qui lui est associé. Le module de déploiement MD dispose dès lors des données utiles pour la mise en œuvre des pré-déploiements demandés, à savoir la liste des serveurs sur lesquels opérer ces pré-déploiements, et la manière dont ils doivent être configurés, notamment en termes de système d'exploitation et de solution de déploiement à y installer, cette solution comprenant un ou plusieurs composants. Sur cette base, les opérations de configuration partielles sont alors mises en œuvre, dans une étape 215. Dans l’exemple illustré en FIG. 2 , le module de déploiement MD procède par exemple respectivement dans des étapes 215, 215’ et 215’’ au pré-déploiement de plusieurs serveurs de réserve, comprenant notamment au moins un serveur SV-RC situé dans des espaces de données régionaux (« Regional Clouds » en anglais), au moins un serveur SV-EC situé dans des espaces de données d'extrémité (« Edge Clouds » en anglais), et au moins un serveurs SV-FEC situé dans des espaces de données de bordure FEC ( « Far Edge Clouds » en anglais). Selon une caractéristique particulière, une fois les configurations partielles finalisées, le module de déploiement MD de l’entité de déploiement ED émet une demande d’extinction ou de mise en veille à destination des serveurs concernés. Dans une étape 216, le module de déploiement MD de l’entité de déploiement ED informe également le module de pré-déploiement MPD que les opérations de pré-déploiement demandées ont bien été effectuées. Dans une étape 217, le module de pré-déploiement MPD confirme à l’administrateur (ou au système logiciel d’administration) que la configuration partielle des serveurs de réserve sélectionnés a correctement été réalisée, conformément au contenu du fichier déclaratif FD. À ce stade, la phase de pré-déploiement P1 selon la présente technique est considérée comme terminée, et le système est prêt pour la mise en œuvre, le cas échéant, d’une phase de finalisation de configuration P2, en particulier si une augmentation de la charge du service de communication est détectée. La FIG. 4 est un diagramme de séquence illustrant la mise en œuvre d’une telle phase de finalisation de configuration P2, dans un mode de réalisation particulier. Cette phase de finalisation de configuration P2 est également mise en œuvre au niveau de l’entité de pré-déploiement EPD. Dans une étape 401, le module de pré-déploiement MPD de l’entité de pré-déploiement EPD obtient un fichier descriptif d’un déploiement à réaliser, par exemple parce qu’une augmentation importante de charge, et donc la nécessité de procéder à une mise à l’échelle, a été détectée. Un tel fichier est par exemple téléversé par un administrateur ou généré et transmis automatiquement au module de pré-déploiement MPD par un système logiciel tiers ayant détecté l’augmentation de charge. Selon une caractéristique particulière, le fichier descriptif comprend, éventuellement en complément d’autres informations, au moins une information sur une localisation d’un serveur à configurer, notamment en fonction de la nature du service de communication requérant la montée en charge. La demande de déploiement peut ainsi par exemple porter sur une demande de déploiement dans un espace de données particulier parmi des espaces de données régionaux RC (« Regional Clouds » en anglais), des espaces de données d'extrémité (« Edge Clouds » en anglais), ou des espaces de données de bordure FEC (« Far Edge Clouds » en anglais). Ainsi, le fichier descriptif permet par exemple de demander à titre prioritaire un déploiement dans un espace de données de bordure FEC lorsque le service de communication considéré est associé à des exigences fortes en termes de qualité de service, notamment lorsque le fonctionnement nominal de ce service requiert une latence faible. À réception de ce fichier, le module de pré-déploiement MPD détermine dans une étape 402 si un serveur ayant précédemment fait l’objet d’une configuration partielle dans le cadre d’une phase de pré-déploiement P1 telle que déjà décrite en relation avec la FIG. 2 présente des caractéristiques compatibles avec celles requises dans le fichier descriptif reçu. Une telle détermination de compatibilité comprend notamment une vérification que le système d’exploitation et que l’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées installés sur ce serveur partiellement configuré sont bien compatibles avec une mise en œuvre du service de communication considéré. Dans la négative, si aucun serveur ne répond à ces critères, le module de pré-déploiement MPD envoie un fichier de déploiement classique, c’est dire sans pré-déploiement P1, au système de gestion de version GIT associé à l’entité de déploiement ED, afin de déclencher un déploiement classique selon l’art antérieur (i.e. une configuration intégrale d’un nouveau serveur par un module de déploiement classique). Dans l’affirmative, lorsque le module de pré-déploiement MPD identifie au contraire au moins un serveur de configuration déjà partiellement configuré en phase de pré-déploiement P1 et de caractéristiques compatibles avec le fichier descriptif de demande de déploiement, par exemple le serveur SV_EC de la FIG. 4 , ce module MPD procède dans un mode de réalisation particulier à diverses vérifications permettant de s’assurer que ce serveur peut effectivement être utilisé dans le cadre d’une opération de mise à l’échelle visant à absorber l’augmentation de charge que subi le service. Le module de pré-déploiement MPD émet par exemple, dans une étape 403, une requête à destination de la structure de données BDD associée au groupe de serveurs de réserve, afin de s’assurer que le serveur SV_EC en question est toujours disponible (c’est-à-dire, par exemple, qu’il n’a pas déjà été réquisitionné pour contribuer à la mise en œuvre d’un autre service faisant potentiellement également face à un pic de charge). À réception, dans une étape 404, d’une confirmation de la structure de données BDD que le serveur identifié est bien disponible, le module de pré-déploiement MPD interroge, dans une étape 405, le serveur de gestion d’habilitation SGH de l’entité de pré-déploiement EPD, afin de vérifier que le serveur de réserve compatible et disponible SV_EC identifié est bien autorisé à faire l’objet d’une opération de finalisation de configuration selon la deuxième phase P2. Lorsque le module de pré-déploiement MPD obtient, dans une étape 406, confirmation du serveur de gestion d’habilitation SGH que c’est bien le cas, il émet dans une étape 407 une nouvelle requête à destination de la structure de données BDD, afin de réserver ce serveur SV_EC, c’est-à-dire de le retirer de la liste des serveurs de réserve disponibles maintenue dans cette base. Une fois cette information de réservation enregistrée dans la structure de données BDD, le module de pré-déploiement MPD reçoit dans une étape 408 confirmation en provenance de la structure de données BDD que le serveur identifié comme compatible a bien été retiré de la liste des serveurs disponibles. Le module de pré-déploiement MPD génère alors, sur la base du fichier descriptif de demande de déploiement, au moins une information de configuration permettant de finaliser la configuration du serveur compatible sélectionné, qu’il transmet à un module de finalisation de déploiement MFD de l’entité de pré-déploiement EPD, dans une étape 409. Le module de finalisation de déploiement MFD procède alors aux opérations de finalisation de la configuration du serveur SV_EC sélectionné, ces opérations comprenant au moins la configuration d’au moins un nœud de virtualisation selon la solution de déploiement automatisé d’applications conteneurisées préconfigurée dans ce serveur, pour la mise en œuvre dudit service. Dans un mode de réalisation particulier de la technique proposée, de telles opérations de finalisation de la configuration comprennent par exemple une séquence de différentes étapes, selon lesquelles : - le module de finalisation de déploiement MFD démarre le serveur SV_EC dont il convient de finaliser la configuration, dans une étape 410 ; - le module de finalisation de déploiement MFD installe un nœud de gestion MK (par exemple un nœud maître Kubernetes ou « Kubernetes master node ») au sein de ce serveur SV_EC, dans une étape 411 ; - le module de finalisation de déploiement MFD configure le nœud de gestion MK installé, dans une étape 412, afin que celui-ci instancie un ou plusieurs nœuds de calcul (« Kubernetes worker node ») ; - le module de finalisation de déploiement MFD vérifie l’état des nœuds instanciés, dans une étape 413 ; - de manière optionnelle, dans des étapes 414 à 416, le module de finalisation de déploiement MFD requiert (étape 414) auprès du nœud de gestion MK qu’il déploie (étape 415) sur le serveur SV_EC une application contribuant au service de communication déployé, puis le module de finalisation de déploiement MFD vérifie (étape 416) l’état de l’application ainsi déployée. À l’issue des opérations de finalisation de déploiement, et plus particulièrement lorsqu’il a été vérifié qu’elles ont été effectuées avec succès, le module de finalisation de déploiement MFD confirme au module de pré-déploiement MPD, dans une étape 417, que le serveur de réserve SV_EC est maintenant complètement configuré et opérationnel pour la mise en œuvre dudit service, et qu’il peut notamment contribuer à l’absorption de l’augmentation de la charge de service détectée. Le module de pré-déploiement MPD relaie cette information à l’administrateur (ou au système logiciel d’administration) dans une étape 418. Dispositif Selon un autre aspect, la technique proposée se rapporte également à une entité de pré-déploiement, adaptée pour réaliser le procédé d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication, tel que précédemment décrit dans l’un quelconque de ses modes de réalisation. Une telle entité comprend des moyens de configuration partielle d’au moins un serveur d’un groupe de serveurs de réserve, dits moyens de pré-déploiement, mis en œuvre en amont d’une augmentation de ladite charge du service de communication. Selon la présente technique, ces moyens de pré-déploiement comprenent des moyens d’émission, à destination d’une entité de déploiement, d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre dudit service de communication. La FIG. 5 représente, de manière schématique et simplifiée, la structure d’un module de pré-déploiement d’une telle entité de pré-déploiement, dans un mode de réalisation particulier. Le module de pré-déploiement selon la technique proposée comprend par exemple une mémoire 51 constituée d’une mémoire tampon M, une unité de traitement 52, équipée par exemple d’un microprocesseur μP, et pilotée par le programme d’ordinateur Pg 53, mettant en œuvre des étapes du procédé d’optimisation 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 éléments de l’entité de déploiement, ou d’éléments tiers tels que par exemple un système logiciel d’administration, ou encore une entité de déploiement. À l’initialisation, les instructions de code du programme d’ordinateur 53 sont chargées dans la mémoire tampon avant d’être exécutées par le processeur de l’unité de traitement 52. L’unité de traitement 52 détecte en entrée E par exemple la présence d’un fichier de type déclaratif, dont le contenu décrit des informations utiles à la mise en œuvre d’opérations de pré-déploiement souhaitées, comprenant notamment des informations relatives à un système d'exploitation et à des composants d’une solution de déploiement automatisé d’applications conteneurisées à déployer sur un ou plusieurs serveurs de réserve. Le microprocesseur de l’unité de traitement 52 réalise alors les étapes du procédé d’optimisation, selon les instructions du programme d’ordinateur 53. Plus particulièrement, sur la base des données contenues dans le fichier déclaratif reçu en entrée E, et de données complémentaires éventuellement obtenues en provenance d’autres éléments de l’entité de pré-déploiement – tels qu’un serveur de gestion d’habilitation ou une structure de données associée à un groupe de serveurs de réserve – l’unité de traitement 52 sélectionne au moins un serveur de réserve retenu pour faire l’objet d’une configuration partielle. L’unité de traitement 52 émet alors, en sortie S, une demande d’installation, sur ledit au moins un serveur, du système d’exploitation et de l’au moins un composant de la solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre du service de communication d’après le fichier déclaratif, de manière à réduire significativement la durée d’opérations ultérieures éventuelles de finalisation de la configuration de ces serveurs, notamment en cas de détection d’une augmentation de la charge du service de communication. Procédé d’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication, ledit procédé étant mis en œuvre par une entité de pré-déploiement (EPD), ledit procédé étant caractérisé en ce qu'il comprend, en amont d’une augmentation (AC) de ladite charge du service de communication, une phase de configuration partielle (P1) d’au moins un serveur d’un groupe de serveurs de réserve, dite phase de pré-déploiement, comprenant l’émission à destination d’une entité de déploiement (ED) d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre dudit service de communication. Procédé selon la revendication 1, caractérisé en ce que ledit au moins un composant appartient au groupe comprenant : - un utilitaire ; - une librairie informatique ; - un fichier de configuration ; - un moteur d’intelligence artificielle ; - une composante élémentaire dudit service de communication. Procédé selon la revendication 1, caractérisé en ce que ladite phase de pré-déploiement est mise en œuvre sur la base d’un fichier de type déclaratif préalablement obtenu par ladite entité de pré-déploiement. Procédé selon la revendication 3, caractérisé en ce que ledit fichier déclaratif comprend au moins : - un type et une version dudit système d'exploitation à installer sur ledit au moins un serveur ; - un type et une version de ladite solution de déploiement automatisé d’applications conteneurisées à installer sur ledit au moins un serveur ; - un nombre de serveurs à partiellement configurer au sein dudit groupe de serveurs de réserve, pour lesdits types et versions dudit système d'exploitation et de ladite solution de déploiement automatisé d’applications conteneurisées. Procédé selon la revendication 1, caractérisé en ce que ladite émission d’une demande d’installation est conditionnée à une vérification préalable, auprès d’un serveur de gestion d’habilitation : - que ladite entité de déploiement est autorisée à effectuer ladite installation dans le cadre de ladite phase de pré-déploiement ; et/ou - que ledit au moins un serveur dudit groupe de serveurs de réserve est autorisé à faire l’objet de ladite installation dans le cadre de ladite phase de pré-déploiement. Procédé selon la revendication 3, caractérisé en ce que ladite phase de pré-déploiement comprend : - l’obtention, au sein d’une structure de données associée audit groupe de serveurs de réserve, d’au moins une donnée identifiant un ensemble de serveurs disponibles pour la mise en œuvre dudit service de communication, au sein dudit groupe de serveurs de réserve ; - la sélection, au sein desdits serveurs disponibles identifiés, dudit au moins un serveur objet de ladite demande d’installation, en fonction du contenu dudit fichier de type déclaratif et de caractéristiques techniques associées auxdits serveurs disponibles, obtenues dans ladite structure de données. Procédé selon la revendication 6, caractérisé en ce que ladite émission d’une demande d’installation comprend le téléversement, au sein d’un système de gestion de version associé à ladite entité de déploiement, d’au moins un fichier de déploiement comprenant des informations de configuration partielle dudit au moins un serveur sélectionné, ledit au moins un fichier de déploiement étant généré en fonction du contenu dudit fichier déclaratif et desdites caractéristiques techniques associées audit au moins un serveur sélectionné. Procédé selon la revendication 1, caractérisé en ce qu'il comprend, en réponse à une augmentation de charge dudit service de communication : - la sélection, parmi ledit au moins un serveur partiellement configuré dans ladite phase de pré-déploiement, d’au moins un serveur dont la configuration partielle est compatible avec un fichier descriptif de demande de déploiement obtenu par ladite entité de pré-déploiement suite à une détection de ladite augmentation de charge ; - la finalisation de la configuration dudit au moins un serveur partiellement configuré sélectionné, délivrant un serveur opérationnel pour la mise en œuvre dudit service de communication. Procédé selon la revendication 8, caractérisé en ce qu’une détermination de la compatibilité de ladite configuration partielle avec ledit fichier descriptif de demande de déploiement comprend une vérification que le système d’exploitation et l’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées installés sur ledit au moins un serveur partiellement configuré sélectionné sont compatibles avec la mise en œuvre dudit service de communication. Procédé selon la revendication 8, caractérisé en ce que ladite sélection dudit au moins un serveur comprend la prise en compte d’une localisation dudit au moins un serveur, au regard d’au moins une information de localisation comprise dans ledit fichier descriptif de demande de déploiement, déterminée en fonction d’une nature dudit service de communication. Procédé selon la revendication 8, caractérisé en ce que ladite finalisation de la configuration est conditionnée à une vérification préalable, auprès d’un serveur de gestion d’habilitation, que ledit au moins un serveur partiellement configuré sélectionné est autorisé à faire l’objet de ladite finalisation de configuration. Procédé selon la revendication 8, caractérisé en ce que ladite finalisation de la configuration est conditionnée à une vérification préalable, au sein d’une structure de données associée audit groupe de serveurs de réserve, que ledit au moins un serveur partiellement configuré sélectionné est disponible pour la mise en œuvre dudit service de communication. Procédé selon la revendication 8, caractérisé en ce que ladite finalisation de la configuration comprend : - la génération, sur la base dudit fichier descriptif de demande de déploiement, d’au moins une information de configuration dudit au moins un serveur partiellement configuré sélectionné ; - la configuration, sur ledit au moins un serveur partiellement configuré sélectionné, sur la base de ladite au moins une information de configuration, d’au moins un nœud de virtualisation selon ladite solution de déploiement automatisé d’applications conteneurisées, pour la mise en œuvre dudit service de communication. Entité de pré-déploiement pour l’optimisation du dimensionnement d’une infrastructure de virtualisation à une charge d’un service de communication, ladite entité étant caractérisée en ce qu'elle comprend des moyens de configuration partielle d’au moins un serveur d’un groupe de serveurs de réserve, dits moyens de pré-déploiement, mis en œuvre en amont d’une augmentation de ladite charge du service de communication, lesdits moyens de pré-déploiement comprenant des moyens d’émission, à destination d’une entité de déploiement, d’une demande d’installation, sur ledit au moins un serveur, d’un système d’exploitation et d’au moins un composant d’une solution de déploiement automatisé d’applications conteneurisées estimés adaptés à la mise en œuvre dudit service de communication. 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 à 13, lorsqu’il est exécuté par un ordinateur.