FR 3131648 A1 20230707 FR 2114678 A 20211230 Orchestrateur de services d’un système d’orchestration d’u n réseau de communication militaire ; Système d’orchestration et programme d’ordinateur associés Cet orchestrateur (161) génère des commandes vers une pluralité de contrôleurs comportant un contrôleur de réseau (162), un contrôleur de système d’information (163) et un contrôleur de sécurité (165). Il comporte un module d’intelligence artificielle – AI (180) et un serveur d’interface de programmation d'application – API (166), le module d’AI comportant : une unité (182) pour l’acquisition d’une pluralité de variables d’entrées de description d’une situation opérationnelle ; une unité de réseau de neurones – NN (184) pour déterminer, à partir de la pluralité de variables d’entrées, au moins un scénario, un scénario étant un modèle de fichier de configuration ; et une unité de moteur d’inférence (186) pour instancier des paramètres du scénario, pour déterminer un fichier de configuration prêt à être exécuté par le serveur d’API, le fichier de configuration comportant des commandes selon les composantes de réseau, de système d’information et de sécurité du réseau de communication militaire. Figure pour l'abrégé : Figure 2 Orchestrateur de services d’un système d’orchestration d’un réseau de communication militaire ; Système d’orchestration et programme d’ordinateur associés La présente invention concerne les réseaux de radiocommunication militaires déployés sur le théâtre d’opération. Dans le déploiement de centre de données de théâtre (« theatre cloud » en anglais) ou de réseaux de bordure (« Far Edge »), l’orchestration de services a besoin de déployer des configurations adaptées à la situation opérationnelle courante, tout en répondant aux usages des utilisateurs attendus. Actuellement, la tâche de sélection d’un modèle de fichier de configuration (« template » ou « blue print » en anglais), puis celle de paramétrisation du modèle sélectionné pour obtenir le fichier de configuration, sont laissées à un opérateur de pilotage (« floor control ») de l’orchestration de services. Une fois un fichier de configuration préparé, celui-ci est exécuté par un système d’orchestration du réseau de manière à réaliser le déploiement correspondant à ce fichier. Pour permettre à l’opérateur de pilotage de sélectionner le modèle de fichier de configuration le plus adapté pour répondre à une situation opérationnelle particulière, un arbre de diagnostic est couramment utilisé. Cependant, les arbres de diagnostic proposés sont complexes : ils peuvent atteindre plus de 1000 ramifications. De plus, malgré cette complexité, les modèles de fichier de configuration proposés ne couvrent que la composante réseau du déploiement, sans prendre en compte d’autres composantes cruciales pour un réseau de théâtre, comme les composantes de système d’information – IT et de sécurité. Ils ne prennent également pas en compte la situation opérationnelle effectivement rencontrée affectant les usages, les utilisateurs, et la priorisation des flux. Par exemple, dans une situation opérationnelle où un lien sur le réseau est rompu, on comprend que la reconfiguration du réseau pour router les flux par d’autres chemins est nécessaire. Mais il faut aussi prendre en compte les besoins applicatifs des utilisateurs et si certaines applications génèrent un flux trop important, il est préférable de les supprimer ou de les déployer dans un autre centre de données du réseau. Il faut également prendre en compte les contraintes de sécurité. Par exemple, les réseaux militaires sont cloisonnés en différents niveaux de sécurité, comme les architectures Rouges/Noire des réseaux militaires. Certains chemins sont alors interdits à certains types de flux. Le but de la présente invention est par conséquent de résoudre ce problème. Pour cela l’invention a pour objet un orchestrateur de services d’un système d’orchestration d’un réseau de communication militaire, capable de générer des commandes vers une pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau un contrôleur de système d’information et un contrôleur de sécurité, caractérisé en ce qu’il comporte un module d’intelligence artificielle – AI et un serveur d’interface de programmation d'application – API, le module d’AI comportant : une unité d’acquisition de données, adaptée pour acquérir une pluralité de variables d’entrées de description d’une situation opérationnelle ; une unité de réseau de neurones – NN, capable, à partir de la pluralité de variables d’entrées acquises par l’unité d’acquisition de données, de déterminer au moins un scénario, un scénario étant un modèle de fichier de configuration ; et une unité de moteur d’inférence, capable d’instancier des paramètres du scénario fourni par le module NN, pour déterminer un fichier de configuration prêt à être exécuté par le serveur d’API, le fichier de configuration comportant des commandes selon les composantes de réseau, de système d’information et de sécurité du réseau de communication. Suivant des modes particuliers de réalisation, le système d’orchestration comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - la situation opérationnelle est décrite par des variables d’entrée quantitatives sur l’état courant de la composante réseau, sur l’état courant de la composante système d’information et sur l’état courant de la composante sécurité du réseau de communication. - la situation opérationnelle est décrite par des variables d’entrée provenant d’un système de support opérationnel – OSS, d’un système de support fonctionnel – BSS, et/ou de dispositifs externes. - le module NN met en œuvre un algorithme du type réseau de neurones artificiels, de préférence un perceptron multicouche, de préférence encore du type totalement connecté. - le module NN est capable d’associer un score à chaque scénario d’une pluralité de scénarios prédéfinis, et de produire une liste de scénarios, la liste de scénarios comportant N scénarios présentant les meilleurs scores pour la situation opérationnelle courante. - l’unité de moteur d’inférence utilise des données fournies par un système de support opérationnel – OSS et/ou par un système de support fonctionnel – BSS, pour instancier les valeurs des paramètres d’un scénario et obtenir le fichier de configuration associé. - l’orchestrateur de services comporte, en outre, une interface homme / machine permettant à un opérateur de choisir de transmettre un fichier de configuration préparé par l’unité de moteur d’inférence, au serveur d’API pour réaliser un déploiement dans le réseau de communication. L’invention a également pour objet un système d’orchestration comportant une pluralité de contrôleurs et un orchestrateur de services supervisant la pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau un contrôleur de système d’information et un contrôleur de sécurité, l’orchestrateur de services étant conforme à l’orchestrateur précédent. L’invention a également pour objet un programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un orchestrateur de services, fournissent les unités d’acquisition de données, de réseaux de neurones et de moteur d’inférence, de sorte que l’orchestrateur de services soit conforme à l’orchestrateur précédent. L’invention a également pour objet un produit programme d’ordinateur permettant de programmer convenablement un système d’orchestration pour qu’il soit conforme au système d’orchestration précédent. L’invention et ses avantages seront mieux compris à la lecture de la description détaillée qui va suivre d’un mode de réalisation particulier, donné uniquement à titre d’exemple non limitatif, cette description étant faite en se référant aux dessins annexés sur lesquels : La est une représentation schématique d’un exemple d’infrastructure intégrant un système d’orchestration de services selon l’invention ; et, La est une représentation sous forme de blocs fonctionnels d’un mode de réalisation du système d’orchestration de la . Infrastructure En se référant à la , l’infrastructure 1 comporte un premier réseau 100 et un second réseau 200, destinés à être fédérés au travers un réseau sous-jacent 20. Le réseau 20 est un réseau étendu – WAN (« Wide area network » en anglais). Le premier réseau 100 comporte par exemple : - un premier réseau radio 110, intégrant notamment une pluralité de points d’accès ou eNB (« e-Node B » en 4G) 112. Sur la deux eNB sont représentés et référencés 112a et 112b. Un eNB permet à un équipement utilisateur - UE, tel que l’UE 2, de se connecter, au moyen d’une liaison radio, au premier réseau 100. Le premier réseau radio est de préférence un réseau de bordure embarqué par exemple dans un premier véhicule blindé, les utilisateurs de ce réseau étant des fantassins évoluant sur une première zone du théâtre d’opération. - un second réseau radio 140, intégrant notamment une pluralité de points d’accès ou eNB (« e-Node B » en 4G) 142. Sur la deux eNB sont représentés et référencés 142a et 142b. Un eNB permet à un UE, tel que l’UE 3, de se connecter, au moyen d’une liaison radio, au premier réseau 100. Le second réseau radio est de préférence un réseau de bordure embarqué par exemple dans un second véhicule blindé, les utilisateurs de ce réseau étant des fantassins évoluant sur une seconde zone du théâtre d’opération. - un réseau d’accueil 102. Le réseau d’accueil comporte : - un réseau hôte 120. De manière schématique et particulièrement simple, le réseau d’accueil 120 comporte une passerelle SGW 121 avec le premier réseau radio 110, une seconde passerelle SGW 124 avec le second réseau radio 140, et une passerelle PGW 126 avec le réseau 20. La liaison de communication entre le réseau hôte 120 et les premier et second réseau radio 110 et 140 est par exemple une liaison sans fil, par exemple satellitaire. - un réseau privé de théâtre constituant un centre de données ou SDDC (« Software-defined data center ») 130 qui est un réseau sécurisé comportant plusieurs machines virtuelles VM 132. Sur la , trois machines virtuelles sont représentées et référencées 132a, 132 b et 132c respectivement. - un pare-feu FW (« Firewall ») 150 constituant une interface entre le réseau d’accueil 120 et le SDDC 130, d’une part, et le réseau 20, d’autre part. Le premier réseau 100 comporte en outre un système d’orchestration 160 comportant une pluralité de contrôleurs et un orchestrateur de services 161 supervisant la pluralité de contrôleurs. La pluralité de contrôleurs comporte un contrôleur de réseau 162, un contrôleur de sécurité 165 et un contrôleur IT 163. Cette répartition est effectuée selon les trois composantes de configuration du réseau d’accueil 102. Le contrôleur de réseau 162 contrôle les machines du réseau hôte 120 pour les configurer selon des commandes de réseau reçues de l’orchestrateur de services 161. Il s’agit par exemple de paramétrer le routage d’un certain type de flux de données d’un utilisateur identifié pour assurer une certaine bande passante. Le contrôleur de technologie d’information - IT 163 contrôle les machines du SDDC 130 pour les configurer selon des commandes d’application reçues de l’orchestrateur de services 161. Il s’agit par exemple d’instancier une application particulière en fonction d’un besoin utilisateur identifié, réserver à l’exécution de cette application une certaine ressource mémoire et de calcul d’une VM du SDDC 130, éventuellement décommissionner cette application lorsqu’elle n’est plus utilisée ou lorsque la situation opérationnelle le nécessite. Le contrôleur de sécurité 165 contrôle le pare-feu 150, pour le configurer selon des commandes de sécurité reçues de l’orchestrateur de services 161. Il s’agit par exemple de filtrer la circulation des données d’un utilisateur authentifié en fonction de ses privilèges, stockés dans un profil d’abonné de cet utilisateur. Plus généralement, l’orchestrateur de services 161 permet donc, à travers les contrôleurs, l’affectation de ressources physiques et/ou virtuelles disponibles en fonction des besoins des utilisateurs. Les ressources physiques comprennent par exemple des capacités de calcul du SDDC, des capacités mémoire de travail du SDDC, des capacités de bande passante sur le réseau, des capacités de translation d'adresse réseau (« Network Address Translation - NAT) du pare-feu, etc. Les ressources virtuelles comprennent par exemple des briques virtualisées correspondant chacune à une application permettant d’effectuer un traitement particulier sur des données spécifiques, tel que par exemple une application d’inspections en profondeur de paquets (« Deep Packet Inspection – DPI ») par le pare-feu, une application de traitement d’images par le SDDC, ou encore une application de compression d’un flux de données par le réseau hôte 120. Adossé au système d’orchestration 160, le premier réseau 100 comporte un système de support opérationnel – OSS (« Operations Support System ») 172 et un système de support fonctionnel – BSS (« Business Support System ») 174. Le second réseau 200 est par exemple un central de commande des opérations. Orchestrateur de services Comme illustré plus en détail sur la , l’orchestrateur de services 161 comporte un serveur d’interface de programmation d'application – API (« Application Programming Interface ») 166, une interface homme / machine – IHM 168 et un module d’intelligence artificielle – AI 180. Le serveur d’API 166 offre un ensemble de définitions et de protocoles qui facilitent la création et l'intégration d’applications de gestion du réseau 100. Le module d’AI 180 est capable, à partir d’une pluralité de variables d’entrée, de générer au moins un fichier de configuration permettant de réaliser, via le serveur d’API 166, un déploiement qui répond au contexte opérationnel. Le module d’AI 180 comporte une unité d’acquisition de données 182, une unité de réseau de neurones – NN 184 et une unité de moteur d’inférence 186. L’unité d’acquisition de données 182 est responsable de l’acquisition d’une pluralité de variables d’entrées de description de la situation opérationnelle. L’unité 182 peut recevoir automatiquement des données à intervalles réguliers, ou lors de l’occurrence d’un évènement particulier, ou encore interroger des dispositifs du réseau 100 pour, en retour, recevoir des données. La pluralité de variables d’entrée comporte au moins des variables quantitatives sur l’état courant de la composante réseau, sur l’état courant de la composante IT et sur l’état courant de la composante sécurité. Il s’agit par exemple d’une pluralité d’indicateurs de performance clés - KPIs (« key performance indicators »). Les variables quantitatives sur l’état courant de la composante réseau sont remontées par le contrôleur 162 pour les données du réseau local LAN, mais également par l’orchestration de service du second réseau 200 pour les données du réseau étendu WAN. Elles comprennent par exemple : - la qualité de service – QoS sur les réseaux 110 et 140 ; - la qualité de service – QoS sur le réseau 120 et sur le SDDC 130 ; et, - la qualité de service – QoS sur le réseau 20 ; Plus généralement, les protocoles de routage, comme BGP-LS (« Border Gateway Protocol Link-State ») et OSPF-TE (« Open Shortest Path First Traffic Engineering »), fournissent des informations de trafic permettant d’obtenir des données sur l’état des liens : bandes passantes, latences, QoS, etc. Les variables quantitatives sur l’état courant de la composante sécurité sont remontées par le contrôleur 165. Elles comprennent par exemple : - indicateurs générés par une ou plusieurs sonde(s) de gestion de l'information et des événements de sécurité - SIEM (« security information and event management »). Ce sont toutes les sondes placées dans le réseau permettant de détecter d’éventuelles attaques informatiques, comme une attaque par déni de service – DDoS (« distributed denial of service»), une usurpation d’identité, une intrusion détectée par un dispositif IDS (« intrusion detection system »), une fuite de donnée détectée par un dispositif DLP (« data loss prevention »), une analyse des journaux d’évènement ou fichiers « Logs », une identification de menace par détection des signatures d’attaques, une surcharge d’un port de communication, etc. Les variables quantitatives sur l’état courant de la composante système d’information - IT sont remontées par le contrôleur 163. Elles comprennent par exemple : - indicateurs sur l’état (CPU, mémoire…) de chaque VM du SDDC : CPU restant / alloué, mémoire RAM restante / allouée, capacité de stockage sur les disques restante / allouée, la charge de chaque port virtuel associé à chaque VM, etc. - Pour le SDDC dans son ensemble, il faut prendre en compte l’ensemble du CPU, de la mémoire RAM, des capacités de stockage, des charges des ports, etc. des VM, ainsi que l’état du bus de communication entre les VM. Avantageusement, des variables quantitatives sur l’état courant du système d’information peuvent être fournies directement par les VM du SDDC 130, par exemple via une interface du type N5. Il s’agit d’une interface 3GPP qui permet, dans son usage standard, aux applications de communiquer avec la fonction de contrôle de politique (« Policy Control). Elle est ici avantageusement détournée afin de permettre aux applications de communiquer avec le service d’orchestration afin de demander l’allocation dynamique de ressources additionnelles, suite par exemple à une situation d’urgence. Cette allocation de ressources est octroyée par l’orchestrateur de service et déployée via le contrôleur IT qui contrôle le SDDC. Par exemple, une application peut demander une qualité de service - QoS spécifique (composée par exemple d’un taux de bits garanti – GBR (« guaranteed bit rate »), d’une bande passante et d’une latence) pour un utilisateur donné durant un certain intervalle temporel suite à une urgence. Avantageusement, la pluralité de variables d’entrée comporte en outre des variables supplémentaires. Ainsi, le module 182 reçoit des informations du BSS, c’est-à-dire les objectifs ou contraintes métiers, c’est-à-dire l’utilisation recherchée du réseau 100. Elles comprennent par exemple : - indicateurs d’usage : nombre d’utilisateur du réseau 100 et leurs profils d’abonné (définissant notamment la priorité des communications entre utilisateurs) ; - indicateurs de priorisation ou type de mission planifiée et importance ; et, - liste des applications nécessaires à la mission (Service Reconnaissance imagerie, aide au tir, …) En plus de ces informations, des variables d’ordre de service du réseau peuvent être fournies telles que par exemple un profil d’abonné de chaque utilisateur comportant par exemple : un niveau de priorité permettant de prioriser ses communications ; des droits d’accès permettant d’autoriser l’accès à certains contenus ; des privilèges permettant de définir les applications que cet utilisateur peut utiliser, etc. Le module 182 reçoit également des informations de l’OSS, c’est-à-dire des variables d’ordre opérationnel sur le réseau 100, comme par exemple : les plages d’adressage IP d’un groupe d’utilisateurs, d’un point d’accès ; les adresses IP de chaque VM et port virtuel ; les capacités physiques de chaque serveurs, commutateur, routeur… ; les capacités maximum en termes de bande passante des liens, de taille CPU, mémoires RAM, capacité de stockage des équipements... Enfin, le module 182 reçoit avantageusement des données de description externe de la situation opérationnelle, permettant de l’appréhender. Elles comprennent par exemple : - des informations météorologiques ; - un type d’attaque ; - un type d’ennemis. Par exemple, des capteurs connectés (référencés de manière générale par le chiffre 176 sur les figures) comportent tout ou parties des capteurs suivants : capteurs de gaz, capteurs d’incendies, capteurs de bruits, capteurs chimique, capteurs vidéo, capteurs de température, capteurs d’humidités, capteurs de détection d’intrusion mécanique (ouverture de portes, fenêtres…), centre d’information (suite à appels aux services de secours ou autres). En fait, il s’agit ici de toutes les informations externes au réseau permettant d’intégrer la dimension opérationnelle, aux dimension réseaux, IT, et sécuritaire. L’unité de réseau de neurone – NN 184 met en œuvre un algorithme du type réseau de neurones artificiels, de préférence un perceptron multicouche (« multilayer perceptron »), de préférence encore du type totalement connecté (« fully connnected »). L’unité 184 est capable, à partir des données acquises par l’unité 182, de déterminer au moins un scénario. Un scénario est un modèle (« template » en anglais) de fichier de configuration. Il comporte des commandes selon les trois composantes IT, réseau, et sécurité du réseau. L’algorithme du type réseau de neurones artificiels réalise une opération de classification de la situation opérationnelle du premier réseau 100 décrite par les variable d’entrée. Avantageusement, pour une situation opérationnelle, l’algorithme est capable d’associer un score à chaque scénario d’une pluralité de scénarios prédéfinis. Les scénarios prédéfinis résultent d’un travail d’expertise. L’algorithme est alors capable de produire une liste de scénarios. Cette liste comporte par exemple les N scénarios présentant les meilleurs scores pour la situation opérationnelle rencontrée. N est un entier qui vaut par exemple 3. La phase d’apprentissage permettant de paramétrer l’algorithme de réseau de neurones artificiels est fondée sur l’utilisation de lots d’ensembles de données étiquetées. Un ensemble de données étiquetées associe une pluralité de valeurs des données d’entrée décrivant une situation opérationnelle avec le meilleur scénario permettant de configurer le réseau pour répondre à cette situation opérationnelle. La phase d’apprentissage a par conséquent pour but que la sortie calculée par l’algorithme de réseau de neurones permettent de retrouver ce meilleur scénario. Avantageusement, la phase d’apprentissage peut être répétée en adaptant les scénarios prédéfinis à partir d’un retour d’expérience. L’unité de moteur d’inférence 186 est capable, pour chaque scénario de la liste fournie par l’unité 184, de déterminer un fichier de configuration prêt à être exécuté par le serveur d’API 166 pour réaliser le déploiement correspondant dans le réseau 100. L’unité 186 utilise les données fournies par le BSS et/ou l’OSS pour instancier les valeurs des paramètres d’un scénario et obtenir le fichier de configuration associé. Ainsi, le fichier obtenu tient compte des contraintes opérationnelles de chaque utilisateur et matériel. Un fichier de configuration comporte des commandes selon les trois dimensions réseau, IT et sécurité. Avantageusement, l’unité de moteur d’inférence 186 propose à l’opérateur, via l’IHM 168, les N meilleurs scénarios indiqués dans la liste (ou les N fichiers de configuration associés). C’est alors à l’opérateur de choisir le scénario devant être déployé, c’est-à-dire le fichier de configuration devant être transmis au serveur d’API 166. En variante, c’est l’unité de réseau de neurones 184 qui propose les N meilleurs scénarios à l’opérateur. Parallèlement, ces N scénarios sont transmis à l’unité de moteur d’inférence 186 pour finaliser les fichiers de configuration associés. Seul le fichier du scénario effectivement retenu par l’opérateur sera transmis au serveur d’API 166 pour exécution. Cette variante présente l’avantage de laisser à l’opérateur un certain temps pour sélectionner un scénario parmi les N scénarios qui s’affichent sur l’IHM 168, les fichiers de configuration étant préparés pendant ce temps. Avantageusement, les scénarios sont affichés sur l’IHM 168 avec une description ou un justificatif de leur intérêt vis-à-vis de la situation opérationnelle rencontrée afin d’éclairer le choix de l’opérateur. Exemple de cas d’usage On peut par exemple considérer le cas d’un attentat dans un métro. Les services d’urgence reçoivent un appel décrivant le déclenchement d’un bombe dans le métro avec dégagement de fumée. L’information est relayée par les services d’urgence vers les forces de l’ordre, qui lancent une intervention dans le métro. Les forces de l’ordres envoient des équipes de secours sur place, mais sans connaître la situation réelle et la nature de l’attaque. Il peut par exemple s’agir d’une attaque au gaz sarin plutôt qu’une bombe. L’exécution du module d’AI 180 permet de déployer quasiment instantanément une première configuration du réseau telle que : Le service critique de gestion de crise puisse recevoir les images des caméras de surveillance du métro : le système d’orchestration met en place des routes sécurisées avec le bon débits et des QoS permettant l’acheminement d’un flux vidéo prioritaire ; Le service critique de gestion de crise puisse recevoir les mesures des capteurs de mesure de la qualité de l’air du métro : mise en place d’une route spécifique prioritaire pour récupérer les mesures, modifier la fréquences d’acquisition des mesures. Suite aux résultats de l’analyse des images et de la qualité de l’air permettant d’avoir de nouvelles variables d’entrée, le module d’AI propose une seconde configuration du réseau telle que : les pompiers qui interviennent dans le métro, bénéficient prioritairement de l’ensemble des ressources de communication en sous-sol (par exemple du type WiFi) ; Quant aux autres équipes de secours, en surface, les policiers qui sécurisent le périmètre et facilitent l’acheminement des secours bénéficient de 70 % de la capacité du réseau de radiocommunication (par exemple 4G) alors que le SAMU, pour l’évacuation des blessés, bénéficie de 25 % de la capacité de ce même réseau. Au cours des opérations, on s’aperçoit qu’il est nécessaire de mettre en place un hôpital de campagne sur le terrain avec des moyens de diagnostique poussés. Une troisième configuration du réseau est proposée par le module d’AI et déployée telle que : Déploiement d’une application d’analyse de radiographies X sur une VM du SDDC, réallocation d’une part des ressources de communication initialement allouées aux policiers vers l’hôpital de campagne permettant aux médecins d’accéder à l’application d’analyse de radiographies X. En fin de crise, une fois la situation opérationnelle normal retrouvée, le module d’AI- propose un déploiement permettant de configurer l’ensemble des dimensions du réseau (IT, Sécu, Réseau) pour revenir dans un état nominal. Avantages L’orchestrateur de services venant d’être présenté permet le déploiement instantané et automatique du meilleur scénario au sein du réseau qu’il contrôle pour faire face à une modification du contexte opérationnel. L’orchestrateur de services lorsqu’il nécessite l’intervention d’un opérateur peut être vu comme un système d’aide à la prise de décision. Les applications militaires des réseaux de communication entrainent un changement de paradigme et nécessitent de pouvoir s’adapter rapidement et intelligemment aux différentes situations opérationnelles rencontrées. Le présent orchestrateur de service, en prenant en compte d’un très grand nombre d’indicateurs, qui plus est selon toutes les dimensions d’un réseau de communication militaire, permet de répondre à ce besoin d’adaptation. C’est également un outil permettant de réduire le temps réponse entre l’occurrence d’une situation opérationnelle nouvelle (notamment une situation de crise) et le déploiement d’une configuration particulière du réseau permettant une adaptation à cette situation. Orchestrateur de services (161) d’un système d’orchestration (160) d’un réseau de communication (100) militaire, capable de générer des commandes vers une pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau (162), un contrôleur de système d’information (163) et un contrôleur de sécurité (165), caractérisé en ce qu’il comporte un module d’intelligence artificielle – AI (180) et un serveur d’interface de programmation d'application – API (166), le module d’AI comportant : - une unité d’acquisition de données (182), adaptée pour acquérir une pluralité de variables d’entrée de description d’une situation opérationnelle ; - une unité de réseau de neurones (184), capable, à partir de la pluralité de variables d’entrée acquises par l’unité d’acquisition de données (182), de déterminer au moins un scénario, un scénario étant un modèle de fichier de configuration ; et, - une unité de moteur d’inférence (186), capable d’instancier des paramètres du scénario fourni par l’unité de réseau de neurones (184), pour déterminer un fichier de configuration prêt à être exécuté par le serveur d’API (166), le fichier de configuration comportant des commandes selon les composantes de réseau, de système d’information et de sécurité du réseau de communication (100). Orchestrateur de services (161) selon la revendication 1, dans lequel la situation opérationnelle est décrite par des variables d’entrée quantitatives sur l’état courant de la composante réseau, sur l’état courant de la composante système d’information et sur l’état courant de la composante sécurité du réseau de communication (100). Orchestrateur de services (161) selon la revendication 2, dans lequel la situation opérationnelle est, en outre, décrite par des variables d’entrée provenant d’un système de support opérationnel – OSS (172), d’un système de support fonctionnel – BSS (174), et/ou de dispositifs externes. Orchestrateur de services (161) selon l’une quelconque des revendications 1 à 3, dans lequel l’unité de réseau de neurones (184) met en œuvre un algorithme du type réseau de neurones artificiels, de préférence un perceptron multicouche, de préférence encore du type totalement connecté. Orchestrateur de services (161) selon la revendication 4, dans lequel l’unité de réseau de neurones (184) est capable d’associer un score à chaque scénario d’une pluralité de scénarios prédéfinis, et de produire une liste de scénarios, la liste de scénarios regroupant les N scénarios présentant les meilleurs scores pour la situation opérationnelle courante. Orchestrateur de services (161) selon l’une quelconque des revendications 1 à 5, dans lequel l’unité de moteur d’inférence (186) utilise des données fournies par un système de support opérationnel – OSS (172) et/ou par un système de support fonctionnel – BSS (174), pour instancier les valeurs des paramètres d’un scénario et obtenir le fichier de configuration associé. Orchestrateur de services (161) selon l’une quelconque des revendications 1 à 6, comportant, en outre, une interface homme / machine (168) permettant à un opérateur de choisir de transmettre un fichier de configuration préparé par l’unité de moteur d’inférence (186), au serveur d’API (166) pour réaliser un déploiement dans le réseau de communication (100). Système d’orchestration (160) comportant une pluralité de contrôleurs et un orchestrateur de services supervisant la pluralité de contrôleurs, la pluralité de contrôleurs comportant au moins un contrôleur de réseau (162), un contrôleur de système d’information (163) et un contrôleur de sécurité (165), caractérisé en ce que l’orchestrateur de services est conforme à l’une quelconque des revendications 1 à 7. Programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un orchestrateur de services d’un réseau de communication (100), fournissent les unités d’acquisition de données, de réseaux de neurones et de moteur d’inférence, de sorte que l’orchestrateur de services soit conforme aux revendications 1 à 7.