Brevet FR3108754A1 — publié le 20211001

La présente divulgation concerne le domaine des réseaux informatiques de périphérie à accès multiple. Spécifiquement, la divulgation se rapporte à un procédé de délégation d’une application de service (APP1) entre une pluralité de réseaux informatiques de périphérie à accès multiple connectés entre eux, le procédé comprenant: - fournir (S2) l’application de service d’un premier réseau (MEC1) à un deuxième réseau (MEC2) de la pluralité ; et - configurer (S3), par le premier réseau, une politique de délégation de l’application de service en fonction d’au moins une contrainte d’interaction avec le premier et/ou le deuxième réseau. Figure de l’abrégé : Figure 4 Procédé de délégation entre réseaux informatiques de périphérie à accès multiple Arrière-plan de l’invention La présente description se rapporte au domaine des réseaux informatiques de périphérie à accès multiple et, plus précisément, à des procédés de délégation entre de tels réseaux informatiques de périphérie à accès multiple. Les domaines de la santé, des transports, de l’énergie, de l’industrie sont en cours de devenir des domaines majeurs d’utilisation des standards 5G en télécommunications. Ces standards 5G vont considérablement améliorer les débits, la connectivité, la latence ainsi que la fiabilité des communications dans le domaine de la production industrielle, dite « industrie 4.0 », par exemple pour commander des dispositifs connectés, piloter des systèmes cyber-physiques (ou « Cyber Physical System », en anglais) tels qu’un robot industriel, coordonner plusieurs machines-outils, ou encore transmettre et partager des données ou des services entre différents opérateurs. Les standards 5G vont également permettre de perfectionner de nombreuses technologies dans le domaine de l’Internet des objets et de la virtualisation. Dans ce contexte, une difficulté rencontrée est de pouvoir disposer d’architectures réseaux répondant aux contraintes exigées par les acteurs d’une industrie donnée lorsque ces acteurs échangent entre eux des données, des applications, par exemple des applications de service, ainsi que des autorisations d’accès à de telles applications afin de pouvoir piloter des opérations à distance. De telles contraintes sont nécessaires notamment pour partager l’utilisation de systèmes communs entre différents donneurs d’ordre, tout en garantissant un niveau de sécurisation conforme aux exigences de chacun de ces acteurs. Pour ce faire, il est connu différents types de domaines industriels, parmi lesquels des réseaux informatiques de périphérie à accès multiples, aussi dits réseaux MEC (pour « Multi-Access Edge Computing », en anglais). Le groupe ETSI (« European Telecommunications Standards Institute », en anglais) a défini des spécifications techniques précises et relatives à des architectures réseau compatibles avec les standards de l’informatique de périphérie multi-accès, et en particulier, les spécifications techniques de ces réseaux MEC. Selon ces spécifications techniques, un réseau MEC fournit un système apte à héberger des applications de services en une localisation très proche de l’utilisateur (« end user », en anglais) et/ou de terminaux externes au système. Ceci permet de stocker et de traiter des données avec un temps de réponse plus rapide que les infrastructures et les réseaux traditionnels. En outre, un réseau MEC est conçu pour être compatible avec différents types d’accès mobiles ou fixes, ce qui lui permet d’être installé physiquement et directement en différentes localisations d’un réseau fourni par un opérateur, et par exemple dans des stations de base ou à proximité de celles-ci, ou dans des infrastructures appartenant à des utilisateurs ou à des industries spécifiques. Les données collectées ou utilisées auprès de ces utilisateurs et industries peuvent ensuite être communiquées via un réseau d’interconnexion, éventuellement dématérialisé. A titre d’exemple, des réseaux MEC permettent le déploiement de services réseaux de l’industrie 4.0 sur des infrastructures connectées à des réseaux en nuage (en anglais Cloud) hétérogènes, c’est-à-dire reposant sur différentes technologies d’accès et différents types de ressources distribuées. Dans les présentes, un réseau de périphérie peut être un réseau en nuage. Etant donné que l’architecture des réseaux MEC définit un espace d’échange et de contrôle de données permettant aux industries une meilleure flexibilité dans la mise en commun de leurs ressources, les réseaux MEC permettent d’améliorer considérablement le partage de données sur un site industriel. Toutefois, les procédés et les systèmes connus présentent plusieurs inconvénients majeurs. Tout d’abord, au sein d’une industrie donnée, plusieurs lignes de production sont souvent exploitées, par exemple deux lignes d’assemblage fonctionnent en parallèle dans une usine. Ceci implique qu’une pluralité de systèmes cyber-physiques de même type peut être utilisée sur un même site de production, ces systèmes cyber-physiques pouvant être connectés à un réseau MEC et/ou commandés par un ou plusieurs réseaux MEC qui sont déployés sur ce site de production. Or, les spécifications techniques actuelles de tels réseaux MEC ne permettent pas d’exploiter une pluralité de lignes de production de manière optimale. En effet, les réseaux MEC et les procédés de commande connus ne sont actuellement prévus que pour déployer et utiliser une application d’un client sur une seule ligne de production ou au sein d’un seul et même domaine. En outre, les spécifications techniques des architectures MEC connues ne définissent pas comment exploiter plusieurs lignes de production, par exemple pour en augmenter les capacités de production. Il n’est donc pas possible actuellement d’exploiter les architectures MEC pour étendre l’empreinte et la capacité d’un réseau industriel associé, pallier des problèmes de passage à l’échelle ou de s’affranchir de contraintes d’extensibilité. Par ailleurs, les spécifications des réseaux et des architectures MEC ne permettent pas d’autoriser ou de configurer l’utilisation d’une ou de plusieurs applications, par exemple une ou plusieurs applications de service, entre plusieurs domaines ou réseaux industriels, par exemple entre des lignes de production appartenant à un même réseau industriel voire à des réseaux industriels distincts. En d’autres termes, les réseaux MEC ne permettent pas de déployer une application d’un client sur différentes lignes de production ou selon un mode « inter-domaine MEC », sous l’autorisation et éventuellement le contrôle de ce client. Objet et résumé de l’invention Afin d’améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé selon un premier objet des présentes un procédé de délégation d’une application de service entre une pluralité de réseaux informatiques de périphérie à accès multiple connectés entre eux, ladite application de service étant configurée pour commander un système cyber-physique, le procédé comprenant: - fournir l’application de service d’un premier réseau à un deuxième réseau de la pluralité ; et - configurer, par le premier réseau, une politique de délégation de l’application de service en fonction d’au moins une contrainte d’interaction avec le premier et/ou le deuxième réseau. Dans les présentes, et de manière générale, un module désigne un composant informatique matériel ou logiciel intégré au réseau. Dans les présentes, et de manière générale, les appellations « domaine industriel » et « réseau MEC » sont utilisées de manière interchangeable, les appellations « informatique de périphérie à accès multiple » et « MEC » sont utilisées de manière interchangeable, et - les appellations « entité » et « architecture » sont utilisées de manière interchangeable. Ainsi, une entité d’un réseau informatique de périphérie à accès multiple est une architecture MEC. Dans une réalisation, en particulier, un réseau informatique de périphérie à accès multiple est un domaine industriel, et de préférence, un réseau non public, dit réseau NPN (ou « Non Public Network », en anglais). Un réseau NPN, par exemple un réseau non public 5G, peut être déployé industriellement et, contrairement aux réseaux offrant des services de réseau mobile au grand public, permet de fournir des services de réseau 5G à un groupe d'utilisateurs ou à un groupe d’opérateurs clairement définis. Dans les présentes, un service exécuté par une application est un service d’application, et de préférence, un service réseau tel qu’un service DNS ou un proxy d’application déployé dans une entité que comprend le réseau. Des exemples de services d’application comprennent, entre autres, des services de contrôle de systèmes cyber-physiques, des services de gestion de conditions environnementales, des services de communication entre des terminaux connectés, des services de collecte de mesures physiques, des services de partage d’informations entre des sites industriels, etc. Ceci permet d’autoriser par délégation le téléchargement et/ou l’utilisation d’une application de service au sein d’un réseau MEC, par exemple pour commander un ou plusieurs systèmes cyber-physiques situés sur des lignes de production différentes. Il est ainsi possible de déployer une application entre deux réseaux industriels pour, avantageusement, étendre l’empreinte et la capacité de l’un des réseaux. Ce procédé est utile pour qu’une application de service d’un client donné, suite à l’autorisation de ce client, voie son utilisation partagée sur différentes lignes de production. Dans une réalisation, la politique de délégation configurée est transmise d’un premier module plateforme à un deuxième module plateforme, le premier module plateforme et le deuxième module plateforme se situant respectivement dans le premier réseau et dans le deuxième réseau. Ceci permet de requérir une délégation de l’application de service par le premier réseau au deuxième réseau, en particulier lorsque réseaux informatiques de périphérie à accès multiple connectés entre eux. Dans une réalisation, la configuration de la politique de délégation comprend : - émettre, par le deuxième module plateforme à destination du premier module plateforme, une requête de configuration comprenant ladite au moins une contrainte d’interaction ; et - sélectionner, par le premier module plateforme, une méthode de délégation à mettre en œuvre en fonction de l’au moins une contrainte d’interaction. Ceci permet de mettre en œuvre la configuration de la délégation de l’application de service sur la base d’un échange de données entre les modules plateforme des deux réseaux. Dans une réalisation, le procédé comprend en outre localiser le premier réseau parmi ladite pluralité, ledit premier réseau comprenant l’application de service. Ceci permet d’identifier une présence de l’application de service et de déterminer un identifiant réseau du réseau, ici le premier réseau, qui comprend l’application de service. La connaissance de la localisation de l’application de service facilite alors la mise en œuvre de la délégation. Dans une réalisation, la localisation du premier réseau comprend recevoir, par le deuxième module plateforme, une requête de fourniture émise par un système de support d’opérations du deuxième réseau. Dans une réalisation, la localisation du premier réseau comprend autoriser, par un module gestionnaire de plateforme du deuxième réseau, un accès du deuxième réseau à l’application de service que comprend le premier réseau. Ceci permet de garantir que l’autorisation d’accès à l’application de service est bien fournie par le deuxième réseau, ce qui augmente la sécurisation de la délégation. Dans une réalisation, la localisation du premier réseau est mise en œuvre sur réception, par un dispositif propriétaire connecté à la pluralité de réseaux, d’une requête d’accès à l’application de service que comprend le premier réseau, ladite requête d’accès étant émise par le deuxième réseau. Ceci permet de déclencher l’identification de la présence de l’application de service, et donc de la délégation, à partir dudit dispositif tiers plutôt que par le premier ou le deuxième réseau. Avantageusement, ledit dispositif tiers est un dispositif client tel qu’un espace industriel et/ou un propriétaire initial de l’application de service, et disposant éventuellement de droits d’accès à ladite application. Dans une réalisation, la fourniture de l’application de service est mise en œuvre sur émission d’une requête de fourniture, par un système de support d’opérations du deuxième réseau audit dispositif propriétaire. Ceci permet de conditionner un provisionnement de l’application de service à une requête dudit système de support d’opérations, qui est configuré pour surveiller, contrôler, analyser et gérer les services sur le deuxième réseau. Dans une réalisation, le procédé comprend en outre, sur réception, par le deuxième réseau, de la politique de délégation configurée, exécuter, une commande du système cyber-physique au moyen de l’application de service fournie au deuxième réseau. Ceci permet de mettre en œuvre un pilotage du système cyber-physique par le deuxième réseau au moyen d’une utilisation déléguée de l’application de service. Dans une réalisation, la fourniture de l’application de service comprend au moins l’un parmi un téléchargement de l’application de service, un clonage de l’application de service et/ou un partage à distance d’une utilisation de l’application de service. Ceci permet une délégation d’une utilisation d’une partie de l’application de service, par exemple pour utiliser une ou plusieurs fonctions particulières de l’application de service. Un exemple d’application est une mise en œuvre d’un clonage entre plusieurs réseaux MEC. Il est également possible de copier seulement une partie de l’application de service qui est présente dans le premier réseau, vers le deuxième réseau. Dans les présentes, un clonage comprend une duplication, à partir d’un dispositif donné, de la configuration de ce dispositif et/ou de ses paramètres sur plusieurs autres dispositifs. Il est donc aussi possible de mettre en œuvre un clonage de machine(s) entre différentes lignes de production et/ou entre différentes usines interconnectées qui coopèrent pour l’exécution d’une tâche. Dans une réalisation, la configuration de la politique de délégation comprend au moins un protocole de délégation choisi parmi un protocole ACME/STAR, un protocole PKCS #11, un protocole SubCerts et un protocole LURK. Ceci permet d’augmenter la sécurisation de la délégation au moyen d’interactions et de déploiements automatisés de l'infrastructure à l’aide de clés publiques et/ou de certificats, l’utilisation de ces clés et/ou certificats pouvant être limitée à distance. Dans une réalisation la configuration de la politique de délégation comprend l’intégration d’au moins un paramètre de délégation, d’un cryptage et/ou d’un certificat de sécurité dans ladite politique de délégation. Dans une réalisation particulière, la configuration est mise en œuvre par ledit premier module plateforme sur réception d’une requête de configuration émise par le deuxième réseau. Dans une réalisation particulière, la requête de configuration et/ou la politique de délégation configurée est transmise par l’intermédiaire d’un point de référence connectant le premier réseau au deuxième réseau. Dans une réalisation, l’au moins une contrainte d’interaction est choisie parmi une priorité d’utilisation de protocole de délégation, une contrainte de configuration, une durée de délégation, une contrainte de terminal, une contrainte de connectivité réseau, un type d’application, une politique d’un opérateur et une contrainte de sécurité. Dans les présentes, ou dans une réalisation particulière, une priorité d’utilisation de protocole de délégation comprend une instruction de prioriser l’un ou plusieurs autres protocoles parmi un protocole STAR, un protocole ACME, un protocole LURK. Par exemple, une possibilité de prioriser des protocoles serait de prioriser l’utilisation d’un protocole ACME/STAR avant celle d’un protocole LURK, etc. Dans les présentes, ou dans une réalisation particulière, une contrainte de configuration est par exemple une instruction d’amorçage (ou « bootstrap », en anglais) ou une instruction de mettre en œuvre une phase d’éxécution. Dans les présentes, ou dans une réalisation particulière, une durée de délégation est par exemple une valeur de temps, un nombre d’utilisation ou une unité d’énergie, ladite unité d’énergie pouvant être exprimée en kilowattheures. Dans les présentes, ou dans une réalisation particulière, une contrainte de terminal est par exemple un protocole supporté par un terminal tel qu’une version de la sécurité de la couche de transport (dite version TLS, pour « Transport Layer Security », en anglais) de ce terminal, ou le(s) format(s) de certificats employés par ce terminal. Dans les présentes, ou dans une réalisation particulière, une contrainte de connectivité réseau est par exemple une indication ou une instruction d’une connexion mise en œuvre par un réseau privé, par un réseau public tel qu’un réseau public de type 5G, ou une connexion mise en œuvre par fibre. Dans les présentes, ou dans une réalisation particulière, un type d’application dépend du type de système cyber-physique dont une commande est souhaitée. Dans les présentes, ou dans une réalisation particulière, une politique d’un opérateur dépend par exemple d’une collaboration entre deux fournisseurs d’équipement, de contraintes de consommation ou d’une entente de niveau de service (dite SLA, pour « Service Level Agreement », en anglais) Dans les présentes, ou dans une réalisation particulière, une contrainte de sécurité est par exemple une indication ou une instruction d’une sécurisation, par exemple pour protéger une interface ou non, ou encore une disponibilité d’une clé publique de serveur lorsqu’un protocole LURK est mis en œuvre. Dans une réalisation, la fourniture de l’application de service du premier réseau localisé au deuxième réseau et/ou la configuration de la politique de délégation de l’application de service par le premier réseau est mise en œuvre sur réception, par le deuxième réseau, d’une requête correspondante émise par le système cyber-physique. Ceci permet d’automatiser la mise en œuvre de la délégation à partir du système cyber-physique lui-même, c’est-à-dire en la déclenchant sur la base d’une demande émise directement par celui-ci. Dans une réalisation particulière, la localisation du premier réseau et/ou l’exécution de la commande du système cyber-physique au moyen de l’application de service est mise en œuvre sur réception, par le deuxième réseau, d’une requête correspondante par le système cyber-physique. Selon un autre objet des présentes, il est aussi proposé un programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des réalisations du premier objet, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique. Selon encore un autre objet des présentes, il est aussi proposé un support de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des réalisations du premier objet. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : , la figure 1 représente une vue schématique d’un exemple d’architecture de réseau informatique de périphérie à accès multiple, selon une réalisation ; , la figure 2, représente une vue schématique d’un exemple d’interface entre plusieurs réseaux informatiques de périphérie à accès multiple, selon une réalisation ; , la figure 3, représente une vue schématique d’une mise en œuvre d’un procédé de délégation entre plusieurs réseaux informatiques de périphérie à accès multiple, selon une réalisation ; , la figure 4, représente sous forme d’organigramme, des étapes d’un procédé de délégation, selon une réalisation; , la figure 5, représente sous forme de diagramme de flux des étapes d’un procédé de délégation, selon une réalisation ; , la figure 6, représente un bloc-diagramme schématique d'un circuit de traitement informatique, selon une réalisation. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant. Il est maintenant fait référence à la figure 1, qui représente un exemple d’architecture MEC, c’est-à-dire un exemple d’architecture d’un réseau informatique de périphérie à accès multiple. Dans les présentes, les termes « architecture » MEC, « réseau » MEC et « domaine » MEC sont utilisés de manière interchangeable. Différents éléments fonctionnels que comprend un domaine MEC, ici représenté par MEC1, sont ici illustrés de manière détaillée. Ces éléments fonctionnels sont regroupés en plusieurs niveaux, ou couches, parmi lesquelles un niveau système SL correspondant à une couche supérieure et un niveau hôte HL correspondant à une couche intermédiaire et prévu pour être proche d’un niveau utilisateur. Le niveau hôte HL comprend au moins un module hôte du réseau de périphérie, dit module hôte MECH (ou « Mobile Edge Computing Host », en anglais). Ce module hôte MECH fournit, notamment, un moyen de stockage et de traitement d’informations. Le module hôte MECH comprend au moins une plateforme de périphérie, dite module plateforme MEP (ou « Mobile Edge Platform », en anglais), une infrastructure de virtualisation de réseau virtuel, dite infrastructure VI (ou « Virtual Network Function Infrastructure », en anglais), ainsi qu’au moins une application de périphérie, dite application MEA (ou « Mobile Edge Applications », en anglais). Typiquement, une application MEA est exécutable en tant que machine virtuelle sur l'infrastructure VI. Lorsqu’elle est exécutée, l’application MEA interagit avec le module plateforme MEP via au moins un point de référence Mp1, qui peut également être utilisé pour la mise en œuvre de procédures de support supplémentaires. Le point Mp1 fournit en outre une interface connectant une ou plusieurs applications MEA à un module plateforme MEP, ce qui permet de contrôler l’état de ces applications. Ce contrôle est mis en œuvre de manière internalisée par rapport à un serveur qui héberge cette ou ces applications. Un exemple d’application MEA est une application de service configurée pour indiquer les besoins en ressources ou en services du module hôte MECH, ou encore pour renseigner ou mettre à jour des contraintes relatives au module hôte MECH. Un exemple d’application de service est une application permettant de commander un déplacement d’une machine-outil ou d’envoyer des messages comprenant des valeurs physiques mesurées depuis un terminal de communication vers un dispositif tiers. L’infrastructure VI fournit des ressources de calcul, de stockage et de réseau pour une ou plusieurs applications MEA. L'infrastructure VI comprend en outre un plan de commutation, dit couche de données, aussi dit plan de données DP (ou « Data Plane », en anglais), configuré pour exécuter les règles de transmission reçues par le module plateforme MEP. Le plan de données DP est généralement compris dans l’infrastructure VI du module hôte MECH et permet, notamment, d’acheminer des données entre les différents services, applications et services associés à l’architecture. Le module plateforme MEP que comprend le module MECH fournit en outre un ensemble de fonctionnalités pour exécuter des applications sur une entité hôte et pour permettre à ces applications d’utiliser les services associés. Ces fonctionnalités sont utilisées, par exemple, pour organiser le routage de données entre différentes applications, ou entre des services et/ou des réseaux interagissant avec une architecture MEC. Le niveau hôte HL comprend des entités externes au module hôte MECH, telles qu’un module gestionnaire de plateforme de périphérie à accès multiple de niveau hôte, dit module gestionnaire MEPM (ou « Mobile Edge Platform Manager », en anglais), ou encore un gestionnaire d’infrastructure de virtualisation, dit gestionnaire VIM (ou « Virtual Infrastructure Manager », en anglais). Le gestionnaire VIM interagit avec l’interface VI par un point de référence Mm7, ce qui fournit une interface permettant de gérer les ressources virtualisées du module hôte MECH et/ou pour gérer d’éventuelles instanciations. Il est également utilisé pour conserver des informations sur les ressources disponibles. Le module gestionnaire de plateforme MEPM reçoit les règles de transfert de trafic et gère notamment les cycles de vie d’applications de service telles qu’une application MEA, une application de périphérie mobile ou une fonction de gestion. Le module gestionnaire de plateforme MEPM peut être une fonction soit locale soit centralisée dans une architecture MEC. Le module gestionnaire de plateforme MEPM permet de fournir des informations détaillées sur un ou plusieurs modules hôtes MECH déployés en différentes localisations, par exemple pour permettre de renseigner par exemple les identifiants réseau des serveurs qui les abritent, par exemple une adresse IP, une adresse MAC ou encore une adresse DNS. Le module gestionnaire de plateforme MEPM est connecté au module plateforme MEP via le point de référence Mm5 qui lui permet de transmettre des instructions. Ces instructions peuvent être transmises du module plateforme MEP à l’interface VI via le point de référence Mp2. Le point de référence Mp2 fournit une interface reliant la plateforme MEP au plan de données DP pour lui permettre de communiquer et transmettre des données. Les points de référence Mp1 et Mp2 permettent d’échanger et de gérer des flux de données entre différentes entités du module hôte MECH, par exemple des signaux passant par le plan de données DP. Le module plateforme MEP prend aussi en charge la configuration d’un éventuel serveur local, par exemple un serveur DNS, qui peut être utilisé pour diriger le trafic utilisateur vers des applications de périphérie souhaitées. Le module hôte MECH du domaine MEC1, et, en particulier, le module plateforme MEP du module hôte MECH, sont configurés pour échanger des données avec un autre domaine MEC2 (ici non représenté), qui comprend des éléments fonctionnels identiques à ceux du domaine MEC1. En particulier, une interface peut être réalisée entre les domaines MEC1 et MEC2 au moyen d’un point de référence Mp3, qui peut être configuré pour connecter le module hôte MECH du domaine MEC1 à un module hôte que comprend un autre domaine MEC2, ici non représenté. En particulier, cette connexion peut être établie entre le module plateforme MEP du module hôte MECH du domaine MEC1 et un module plateforme du module hôte que comprend cet autre domaine MEC2. Le point de référence Mp3 permet d’échanger et de gérer des flux de données entre plusieurs entités, et en particulier, entre plusieurs réseaux MEC. Le module plateforme MEP est de préférence une plateforme locale, c’est-à-dire une plateforme intégrée dans la topologie du réseau MEC1. La couche supérieure du domaine MEC1, qui correspond au niveau système SL, comprend un système de support d’opérations, dit système OSS (ou « Operations Support System », en anglais), un proxy LCM (ou « Life Cycle Manager », en anglais) et un orchestrateur multi-accès, dit orchestrateur MEO (ou « Mobile Edge Orchestrator », en anglais), qui est configuré pour exécuter des applications de périphérie mobile. De manière générale, le système OSS comprend un système OSS, un système BSS (ou « Business Support System », en anglais) et/ou un système OSS/BSS. L’orchestrateur MEO est agencé pour communiquer avec des applications installées sur un équipement utilisateur, dites applications UEA (ou « User Equipment Applications », en anglais), ou avec un portail CFS (ou « Customer-Facing Service », en anglais) qui sert de point d’entrée pour une application tiers par rapport au domaine MEC1, c’est-à-dire une application ne faisant pas partie de la ou des applications MEA. Dans les présentes, une application UEA est une application web, c’est-à-dire une application manipulable directement en ligne grâce à un navigateur web. Une application UEA permet de déplacer des applications entre des réseaux externes. En particulier, une application UEA peut être une application de périphérie qui est instanciée dans un élément du niveau hôte HL en réponse à une demande d'un équipement. Dans les présentes, le proxy LCM est un proxy de gestion du cycle de vie des applications utilisateur, et permet en outre aux applications de requérir l’intégration, l’instanciation, la résiliation d’applications utilisateur ou encore la relocalisation d’applications utilisateur à l’intérieur et à l’extérieur du réseau de périphérie mobile. Une exécution d’une application de périphérie (mobile) peut être initiée par un équipement tiers par l’intermédiaire d’un point de référence situé entre une application UEA et le proxy LCM dans le niveau système SL. L’exécution d’une telle application peut aussi être initiée par l’intermédiaire d’un autre point de référence situé entre le portail CFS et le système OSS. Selon différents exemples, les différents éléments du niveau SL permettent de mettre en œuvre une ou plusieurs instanciations d’applications spécifiques dans le module hôte MECH, et en particulier, des instanciations effectuées sur demande d’une ou de plusieurs applications UEA d’un équipement utilisateur. L’orchestrateur MEO est configuré pour avoir connaissance de la topologie de l’architecture MEC, de tous les modules hôte déployés dans l’architecture, ainsi que des services et des ressources disponibles dans chaque module hôte. Le système OSS est quant à lui relié au niveau hôte HL via un point de référence Mm2 le connectant au module gestionnaire MEPM et conçu pour déclencher l'instanciation et la fermeture d’applications de périphérie mobile du module hôte, par exemple. Le point de référence Mm2 peut aussi être utilisé pour la gestion des pannes, de la configuration et des performances du module plateforme MEP. Il est maintenant fait référence à la figure 2, qui représente une vue schématique d’un réseau et de connexions entre deux domaines dans ce réseau. Le réseau représenté comprend deux domaines MEC1 et MEC2 qui sont chacun reliés ou connectés à un espace industriel de données IDS1. En outre les domaines MEC1 et MEC2 disposent d’interfaces inter-domaines. Dans les présentes, on considère que le domaine MEC2, dit deuxième réseau MEC2, est identique structurellement au premier réseau MEC1 et comprend donc des éléments fonctionnels identiques. En l’occurrence, le deuxième réseau MEC2 comprend, au niveau hôte HL, un module gestionnaire de plateforme MECM2, un gestionnaire d’infrastructure de virtualisation VIM2, un module hôte MECH2, le module hôte MECH2 comprenant un module plateforme MEP2, une ou plusieurs applications MEA2. Le deuxième réseau MEC2 comprend en outre, au niveau système SL, et notamment, un orchestrateur MEO2 et un système OSS2, qui peut aussi être noté BSS2 ou OSS2/BSS2. Le premier réseau MEC1 comprend un premier module de services MECS1, et le deuxième domaine MEC2 comprend un deuxième module de services MECS2. Le module gestionnaire de plateforme MECM1, dit premier module gestionnaire de plateforme, du premier réseau est connecté à (ou utilise) le module de services MECS1. Le module gestionnaire de plateforme MECM2, dit deuxième module gestionnaire de plateforme, du deuxième réseau est connecté à (ou utilise) le module de services MECS2. Un espace industriel de données IDS1 est connecté aux domaines MEC1 et MEC2 et à leurs modules de services respectifs. L’espace industriel de données IDS1 est par exemple opéré par un tiers distinct des opérateurs du premier réseau MEC1 et/ou du deuxième réseau MEC2. L’espace industriel de données IDS1 est par exemple un fournisseur d’applications de services et/ou une entité propriétaire de logiciels permettant de commander des systèmes cyber-physiques. Par ailleurs, le premier réseau MEC1 comprend un site d’exploitation OT1 (OT désignant le terme technologie d'exploitation, ou « Operational Technology » en anglais), par exemple une première ligne de production, ce site d’exploitation OT1 pouvant être connecté à un réseau industriel IT1 (IT désignant le terme technologie d'information, ou « Information Technology » en anglais), le réseau industriel IT1 pouvant comprendre un réseau en nuage, un réseau filaire, etc. De manière similaire, le deuxième domaine MEC2 comprend un site d’exploitation OT2, par exemple une deuxième ligne de production qui est parallèle à OT1 mais qui n’est pas reliée à celle-ci. Cette deuxième ligne de production d’OT2 peut être connectée à un autre réseau industriel IT2. IT1 et IT2 sont ici par exemple deux réseaux industriels indépendants et/ou gérés par des opérateurs différents. Dans l’exemple représenté ici, l’interface inter-domaines entre les domaines MEC1 et MEC2 est mise en œuvre de préférence entre les modules gestionnaires MECM1 et MECM2. En variante, ou de manière complémentaire, cette interface inter-domaines est mise en œuvre entre les domaines de production OT1 et OT2. Dans les présentes, le site d’exploitation OT1 et le module gestionnaire MECM1 sont par exemple connectés au plan de données DP du domaine MEC1. Le plan de données DP est connecté au premier réseau IT1, qui est par exemple un réseau en nuage d’une usine. Un schéma de connexion similaire peut s’appliquer au site d’exploitation OT2. Dans l’exemple représenté ici, on souhaite autoriser le deuxième réseau MEC2 à pouvoir utiliser un système cyber-physique R2_1 dont le premier réseau MEC1 est initialement seul utilisateur ou seul autorisé à utiliser. En particulier, l’espace industriel de données IDS1, aussi appelé client IDS1, souhaite mettre en œuvre une location d’un système cyber-physique R2_2 qui est opéré par le domaine MEC2 et connecté à (ou utilisé par) le module de services MECS2. En général, les systèmes cyber-physiques R2_1 et R2_2 sont de même type ou issus d’un même constructeur, et sont configurés de sorte qu’un même espace industriel de données IDS1 (ou un système cyber-physique associé à celui-ci) puisse être utilisé pour commander ces système cyber-physiques, en vue d’effectuer une tâche. On prend ici le cas où, pour effectuer des tâches au moyen du système cyber-physique R2_1, une application de service APP1 doit être utilisée, cette application de service étant par exemple l’une des applications de périphérie MEA1. Pour être utilisée par l’un des domaines, cette application APP1 doit être téléchargée par le domaine MEC2 depuis le domaine MEC1. Initialement, l’application de service APP1 est installée dans le module de service MECS1. Dans l’exemple ici présenté, l’application APP1 est alors localisée, téléchargée, configurée puis utilisée par le réseau MEC2 depuis le réseau MEC1. Selon différentes variantes possibles, cette localisation, ce téléchargement, cette configuration et/ou cette utilisation peut se faire sur la base d’instructions fournies par le premier réseau MEC1, par le client IDS1, ou de préférence par le deuxième réseau MEC2. De préférence, le client IDS1 est le propriétaire initial de l’application APP1, et éventuellement le seul à disposer de droits d’accès à ladite application. Pour échanger des informations et mettre en œuvre les objets des présentes, les domaines MEC1 et MEC2 disposent d’interfaces inter-domaines. Il est maintenant fait référence à la figure 3, qui représente une vue schématique de connexions entre deux entités, et plus précisément entre deux réseaux MEC1 et MEC2, cette vue étant plus détaillée que celle de la figure précédente. Comme illustré, le premier réseau MEC1 comprend un système OSS1 connecté à un module mandataire PROXY1, un orchestrateur MEO1 et un module gestionnaire MECM1 qui sont connectés l’un à l’autre, le gestionnaire MECM1 étant connecté au site d’exploitation OT1 de MEC1 par l’intermédiaire de la plateforme MEP1 que comprend OT1. De manière similaire, le deuxième réseau MEC2 comprend un système OSS2 connecté à un module mandataire PROXY2, un orchestrateur MEO2 et un module gestionnaire MECM2 qui sont connectés l’un à l’autre, le module gestionnaire MECM2 étant connecté au site d’exploitation OT2 de MEC2 par l’intermédiaire de la plateforme MEP2 que comprend OT2. L’espace industriel de données IDS1 est ici connecté aux domaines MEC1 et MEC2 par l’intermédiaire des modules mandataires PROXY1 et PROXY2, ces modules mandataires étant reliés au système OSS/BSS du domaine respectif, c’est-à-dire au système OSS1 pour le premier réseau MEC1 et au système OSS2 pour le deuxième réseau MEC2. Dans l’exemple présenté ici, les réseaux MEC1 et MEC2 sont connectés entre eux au moyen d’une interface inter-domaines. Selon différentes variantes pouvant être combinées entre elles, au moins une interface inter-domaines est mise en œuvre entre les réseaux MEC1 et MEC2 au moyen d’un ou de plusieurs points de référence intermédiaires, et permettant un échange de données et d’applications. Dans une première variante, une interface inter-domaines est définie par un point de référence intermédiaire MpID reliant les modules gestionnaires MECM1 et MECM2 des réseaux MEC1 et MEC2. Ce point de référence intermédiaire MpID, situé de préférence dans les niveaux hôte HL des architectures correspondant à chacun des réseaux, permet une communication directe. Dans une deuxième variante, une interface inter-domaines est définie par le point de référence Mp3 intermédiaire qui relie le module plateforme MEP1 du réseau MEC1 au module plateforme MEP2 du réseau MEC2. Dans une troisième variante, l’interface inter-domaines comprend les points de référence MpID et Mp3 des deux variantes précédemment décrites. De manière générale, une interface directe ou indirecte peut être mise en œuvre entre plus de deux réseaux MEC, au moyen de points de référence semblables à ceux précédemment décrits. Outre le module plateforme MEP1, le site d’exploitation OT1 comprend en outre deux lignes de production parallèles CA11 et CA12, chacune de ces lignes de production permettant le contrôle d’un système cyber-physique de même type, d’une part le système cyber-physique R2_11 contrôlé par la ligne de production CA11 et d’autre part le système cyber-physique R2_12 contrôlé par la ligne de production CA12. Le site d’exploitation OT2 comprend une seule ligne de production CA21 permettant le contrôle d’un autre système cyber-physique R2_2, de même type que les systèmes cyber-physiques R2_11 et R2_12. Cette configuration se généralise à d’autres variantes de lignes de production se répartissant dans les sites OT1 et OT2, par exemple deux lignes de production dans OT1 et deux lignes de production dans OT2, etc. Les sites d’exploitation OT1 et OT2 sont connectés aux réseaux industriels IT1 et IT2, respectivement. Dans l’exemple ici présenté, chacune des lignes de production CA11, CA12 et CA21 comprend un contrôleur C, aussi appelé contrôleur-maître, et une pluralité de capteurs A, aussi appelés capteurs-actuateurs. Au moins l’un de la pluralité de capteurs A est connecté au système cyber-physique R2_11 et au système cyber-physique R2_12. Une commande d’une action de l’un des systèmes cyber-physiques correspondant à une ligne de production donnée se fait typiquement au moyen d’une interface C2D (ou « Controller to Device », en anglais) associée, et configurée pour interfacer le contrôleur C avec les capteurs A de ladite ligne de production. Des systèmes cyber-physiques R2_11, R2_12 et R2_2 de même type, l’un pouvant être commandé au moyen du deuxième réseau MEC2 et au moins un autre pouvant être commandé au moyen du premier réseau MEC1, nécessitent l’emploi d’un logiciel ou d’une application de service par un donneur d’ordre différent. Toutefois, l’un de ces deux donneurs d’ordre peut ne pas être autorisé à télécharger ou utiliser cette application de service tandis que l’autre de ces donneurs d’ordre y est autorisé. En particulier, le deuxième réseau MEC2 ne pourra pas exécuter de tâches au moyen du système cyber-physique R2_2 si cette exécution nécessite une installation et une autorisation d’utilisation de l’application de service APP1 dans MEC2. Par exemple, le site industriel OT2 de MEC2 ne dispose pas nécessairement de l’application de service APP1 qui est présente dans MEC1. Dans l’exemple représenté ici, une délégation est mise en œuvre depuis le client IDS1, en utilisant les modules mandataires PROXY1 et PROXY2. Par exemple, sur la base d’une requête initiale provenant du réseau MEC2, le client IDS1 indique au domaine MEC2, par l’intermédiaire du module mandataire PROXY2 puis par le système OSS2, qu’une délégation de l’application de service APP1 est nécessaire. Pour effectuer une tâche par le système cyber-physique R2_2, le réseau MEC2 est informé que cette application de service est nécessaire et/ou à localiser, et que les moyens nécessaires au téléchargement de ladite application de service se situent dans le réseau MEC1. Dans le cas présent, initialement, l’application APP1, qui correspond à au moins l’une des applications de périphérie MEA1 précédemment décrites, est accessible par le module plateforme MEP1. Dans d’autres exemples, la délégation est mise en œuvre depuis IDS1 mais en utilisant les systèmes OSS1 et OSS2, les orchestrateurs MEO1 et MEO2, des modules de services MECS1 et MECS2 (ici non représentés) et/ou les modules gestionnaires MECM1 et MECM2. Pour ce faire, un opérateur disposant de ressources propres au réseau MEC2 peut exécuter une tâche pour le compte du client IDS1. Ceci est mis en œuvre au moyen de l’exécution d’une application du client IDS1, par exemple MEA1 (ou APP1), qui s’exécute en utilisant des ressources de l’architecture MEC correspondante, et en l’occurrence, le système cyber-physique R2_2 du réseau MEC2. Ensuite, par le biais d’un échange de données entre les modules plateforme MEP2 et MEP1, une délégation est mise en œuvre de manière ad hoc pour que l’application de service soit téléchargée depuis le réseau MEC1 vers le réseau MEC2, ici pour permettre une commande de tâches par le système cyber-physique R2_2 du réseau MEC2 pour le compte d’un opérateur externe. Par exemple, cet échange de données est mis en œuvre au moyen du point de référence Mp3 entre les réseaux MEC1 et MEC2. De manière générale, les applications qui sont exécutées et les tâches qui sont effectuées pour le client IDS1 nécessitent l’usage d’une sécurisation. Selon différentes variantes, cette sécurisation est par exemple mise en œuvre au moyen d’une solution de chiffrement, pour sécuriser l’échange et le stockage des données, qui sont par exemple des clés privées. Ces données et/ou ces clés privées sont par exemple transmises par IDS1 vers le réseau MEC2. En outre, et comme décrit ci-après, le réseau MEC2 requiert une application de service, un logiciel ou encore un certificat au réseau MEC1. Il est maintenant fait référence à la figure 4, qui représente sous forme d’organigramme des étapes S1, S2, S3 et S4 d’un procédé de délégation d’une application de service d’un premier réseau MEC1 à un deuxième réseau MEC2 connectés l’un à l’autre. Une étape S1 concerne la localisation de l’application de service APP1, ou d’une moins d’une copie de celle-ci, au sein de toute entité à laquelle peut se connecter le deuxième réseau MEC2. Par exemple, cette localisation est mise en œuvre au moins par l’échange de messages requête-réponse de localisation échangée entre le deuxième réseau MEC2 et une entité externe, en particulier avec le client IDS1 auquel se connecte MEC2, et qui dispose des droits d’accès à ladite application de service. En particulier, le client IDS1 peut indiquer au deuxième réseau MEC2 une application de service compatible pour exécuter une commande avec le système cyber-physique R2_2, ou encore un identifiant réseau dans lequel une telle application peut se localiser, par exemple un nom de domaine pleinement qualifié, dit identifiant FQDN ("Fully Qualified Domain Name", en anglais). Sur réception d’une requête de localisation, le client IDS1 peut ainsi renseigner au deuxième réseau une position ou un identifiant d’une application de service APP1, par exemple en renseignant, via le renvoi d’une réponse correspondante d’IDS1 à MEC2, son identifiant réseau dans le premier réseau MEC1 qui possède APP1. Une étape S2, qui suit l’étape S1, concerne la fourniture de l’application de service APP1 au deuxième réseau MEC2. Cette fourniture peut comprendre par exemple une copie de l’application APP1 ou d’une partie de ladite application APP1 présente dans le premier réseau MEC1 vers le deuxième réseau MEC2. En variante ou en complément, cette fourniture peut comprendre un téléchargement ou une installation de certaines parties de l’application APP1 depuis le client IDS1 vers le deuxième réseau MEC2. La copie, le téléchargement ou l’installation des dites parties de l’application APP1 peut en outre être conditionnée à une autorisation du client IDS1 et/ou du premier réseau MEC1. Par exemple, cette fourniture comprend un échange de messages requête-réponse de fourniture de l’application de service APP1 entre le deuxième réseau MEC2 demandant celle-ci et le premier réseau MEC1 dans lequel ladite application de service a été localisée au cours de l’étape S1. Selon une variante possible, ladite paire requête-réponse de fourniture est échangée entre le deuxième réseau MEC2 et le premier réseau MEC1, par exemple entre leurs modules gestionnaires MECM1 et MECM2 ou entre leurs modules plateforme MEP1 et MEP2. Une étape S3, qui suit l’étape S2, concerne la configuration d’une délégation de l’application de service APP1 du premier réseau MEC1 vers le deuxième réseau MEC2. En particulier, l’étape S3 comprend une configuration d’une politique de délégation de l’application de service APP1 en fonction d’au moins une contrainte d’interaction avec le premier réseau MEC1. Selon une variante, la politique de délégation de l’application de service APP1 est configurée en fonction d’au moins une contrainte d’interaction avec le deuxième réseau MEC2. Selon une autre variante, la politique de délégation de l’application de service APP1 est configurée en fonction d’au moins une contrainte d’interaction avec le premier réseau MEC1 et le deuxième réseau MEC2, ladite contrainte pouvant dépendre de l’interaction entre MEC1 et MEC2. Par exemple, cette configuration comprend un échange de messages requête-réponse de configuration entre le deuxième réseau MEC2 et le premier réseau MEC1, et en particulier, entre le module plateforme MEP2 du deuxième réseau MEC2 et le module plateforme MEP1 du premier réseau MEC1. Une étape S4, qui suit l’étape S4, concerne l’exécution d’une commande d’un système cyber-physique R2 au moyen de l’application de service APP1 qui a été fournie au deuxième réseau MEC2 au cours de l’étape S2, et dont une politique de délégation a été configurée au cours de l’étape S3. Le système cyber-physique R2 correspond ici au système cyber-physique R2_2 des figures précédentes. Par exemple, cette exécution de commande comprend un échange d’une paire requête-réponse de commande entre le deuxième réseau MEC2 et le système cyber-physique industriel R2. Il est maintenant fait référence à la figure 5, qui représente sous forme de diagramme de flux un exemple de sous-étapes d’un procédé de délégation entre deux réseaux informatiques de périphérie à accès multiple. En particulier, le diagramme de flux représenté à la figure 5 illustre un exemple de procédé de délégation comprenant des étapes S21 à S45, au cours desquelles des flux sont échangés entre les entités d’un premier domaine MEC1 et les entités d’un deuxième domaine MEC2. Les flux échangés peuvent être des flux de données, des flux d’applications et/ou des flux de commande. En lien avec les étapes décrites précédemment, l’étape S2 de fourniture comprend les sous-étapes S21 à S25, l’étape S3 de configuration comprend les sous-étapes S31 à S35, et l’étape S4 d’exécution d’une commande de système cyber-physique comprend les sous-étapes S41 à S45. Le domaine MEC2 comprend au moins une application de périphérie MEA2, une plateforme MEP2, un gestionnaire MEPM2, un orchestrateur MEO2 et un système OSS2. Le domaine MEC1 comprend au moins une application MEA1, une plateforme MEP1 et un gestionnaire MEPM1. L’application MEA2 peut ici désigner, de manière plus générale, un module de service MECS2 du domaine MEC2. L’application de service APP1 nécessaire pour exécuter une commande de R2 est, initialement, présente dans le premier réseau MEC1, par exemple au sein de MEA1. Lors des sous-étapes S21 et S22, une requête de fourniture RQ_PROV de l’application de service APP1 est reçue par le module plateforme MEP2 du deuxième réseau MEC2. De préférence, la requête RQ_PROV est émise par le système OSS2 au module gestionnaire MECM2 au cours de la sous-étape S21, le module gestionnaire MECM2 transférant ensuite cette requête au module plateforme MEP2 du deuxième réseau MEC2 au cours de la sous-étape S22. Le transfert de la requête de fourniture RQ_PROV par le module gestionnaire MECM2 au cours des sous-étapes S21 et S22 permet de préciser la destination de la requête, éventuellement en fonction de la politique de délégation souhaitée, car l’infrastructure d’un domaine tel que MEC2 comprend généralement une pluralité d’applications MEA2 qui se répartissent globalement dans l’architecture, alors que le module plateforme MEP2 est localisé dans l’architecture. Lors de la sous-étape S23, le module plateforme MEP2 initie une demande de délégation d’une application de service associée au système cyber-physique R2 afin d’en requérir une fourniture, une configuration et une utilisation. Cette demande de délégation revient au module plateforme MEP2 si une délégation de l’application de service APP1 n’est pas déjà mise en œuvre pour le deuxième réseau MEC2. Optionnellement, cette demande de délégation peut dépendre d’une politique de délégation déjà configurée ou mise en œuvre au niveau local. Lors de la sous-étape S24, et si l’application de service pour laquelle la demande de délégation est mise en œuvre n’est pas déjà fournie au deuxième réseau MEC2, le module plateforme MEP2 initie une délégation de domaine pour autoriser une mise en œuvre d’une politique de délégation d’une application de service n’appartenant pas au deuxième réseau MEC2. En particulier, et la sous-étape S24 suivant la localisation de l’application de service APP1 au cours de l’étape S1 dans le premier réseau MEC1, cette mise en œuvre de la politique de délégation comprend l’envoi d’une requête correspondante depuis le module plateforme MEP2 vers le module gestionnaire MECM2. Optionnellement, lors de la sous-étape S25, un message d’acquittement correspondant à la requête de la sous-étape S24 est transmis du module gestionnaire MECM2 vers le module plateforme MEP2 pour confirmer que la délégation peut bien être mise en œuvre, et en particulier, qu’un réseau sélectionnable pour fournir et/ou configurer l’application de service APP1 est le premier réseau MEC1. Lors de la sous-étape S31, une requête de configuration RQ_CFG, aussi dite requête de délégation, est émise par le module plateforme MEP2 à destination du module plateforme MEP1 du premier réseau MEC1. Cette requête comprend au moins un paramètre utile à la mise en œuvre de la délégation, ce paramètre permettant de renseigner des capacités de délégation du deuxième réseau MEC2 au premier réseau MEC1. En particulier, un tel paramètre défini une contrainte d’interaction de l’application de service avec le premier réseau MEC1 et/ou le deuxième réseau MEC2. Par exemple, l’au moins un paramètre est une contrainte du domaine MEC1, par exemple une contrainte de ressource physique ou virtuelle, qui intervient lorsqu’un contrôle ou une manipulation du système cyber-physique R2 est requise. L’au moins une contrainte d’interaction dont peut dépendre un choix ou une configuration d’une méthode de délégation est par exemple une durée, un droit d’accès, une consommation maximale de ressource(s) ou encore une contrainte physique liée à l’architecture MEC formant le premier réseau MEC1 ou le deuxième réseau MEC2. Par exemple, lorsqu’une méthode de délégation de type LURK est utilisée comme décrit ci-après, il est nécessaire de prendre en compte les éventuelles contraintes liées au fait que les infrastructures intervenant dans le contrôle du système cyber-physique R2 n’ont pas nécessairement un serveur de clés à disposition. L’au moins une contrainte d’interaction peut être sélectionnée parmi les méthodes de délégation supportées, par exemple une méthode de renouvellement automatique à court terme de certificats, dite méthode ACME/STAR (ou « Automated Certificate Management Environment / Short-Term Automatically Renewed », en anglais), une méthode PKCS #11 (ou « Public Key Cryptography Standards #11 », en anglais), une méthode SubCerts (ou « Subordinate CERT teams », en anglais) ou une méthode LURK (ou « Limited Use of Remote Keys », en anglais). L’au moins une contrainte d’interaction peut aussi être sélectionné parmi les contraintes de terminaux, de capteurs ou d’actuateurs du domaine de production dans lequel se situe le système cyber-physique R2. L’au moins une contrainte d’interaction peut aussi être sélectionnée parmi des politiques et/ou des contraintes associées au deuxième réseau MEC2, par exemple la durée de la délégation, le type d’application de service, le type de système cyber-physique, etc. Lors de la sous-étape S32, le module plateforme MEP1 du premier réseau ou domaine MEC1 sélectionne une méthode de délégation à mettre en œuvre en fonction de la ou des contrainte(s) d’interaction. Cette sélection peut se faire par exemple en fonction de paramètres de délégation, ces paramètres définissant par exemple le client comme étant le réseau industriel IDS1, l’application de service comme étant une application permettant d’exécuter une commande du système cyber-physique R2, le bénéficiaire de la délégation comme étant le deuxième réseau MEC2, etc. Un exemple de méthode de délégation supportée comprend une méthode LURK. Une méthode LURK comprend l’instanciation d’un serveur virtuel, dit serveur LURK, permettant au module hôte MECH d’une architecture MEC, et plus généralement au domaine MEC lui-même, de disposer de clés nécessaires à l’accès d’un contenu sur un serveur, par exemple des clés cryptées permettant le téléchargement ou l’utilisation de l’application MEA1. Un serveur LURK est un exemple de serveur « dissimulé » dans une architecture existante, c’est-à-dire un serveur agencé pour être ignoré par les processus habituels prenant place dans cette architecture. Une méthode de délégation de type LURK permet à un tiers de ne pas devoir enregistrer ses propres clés sur un ou des serveurs qu’il opère. Par exemple, l’émission d’un identifiant d’un serveur sur lequel ces clés sont enregistrées peut être mise en œuvre. En particulier, si un terminal effectue une demande d’un contenu spécifique sur un serveur, une connexion « https » est établie de sorte à permettre de localiser les clés nécessaires sur le serveur même. Ceci permet de déporter des clés, par exemple des clés privées, sur un autre serveur, cet autre serveur étant éloigné du serveur utilisé pour livrer le contenu. Il n’est ainsi pas nécessaire de mettre en œuvre une gestion, éventuellement complexe, de ces clés, et donc de mieux résister à des attaques pirates, par exemple sous forme d’attaques d’imitation (ou « spoofing », en anglais). Un autre exemple de méthode de délégation supportée comprend une méthode STAR/ACME. Une méthode STAR/ACME comprend l’émission d’une requête de signature de certificat, ou CSR (pour « Certificate Signing Request », en anglais), vers une autorité de certification afin de générer un certificat ayant une durée limitée. Ainsi, l’emploi de la méthode STAR/ACME pour mettre en œuvre la délégation méthode STAR/ACME permet de requérir l’accord d’un fournisseur de contenus, en particulier un fournisseur d’applications de services, pour lui demander des certificats correspondants, et par la suite, de requérir un renouvellement de son accord pour l’obtention de certificats ultérieurs. Ceci permet donc d’améliorer la sécurisation de la délégation tout en réduisant la complexité de cette sécurisation. Un autre exemple de méthode de délégation supportée comprend une méthode PKCS#11. Dans les présentes, la méthode PKCS#11 est définie comme une norme de cryptographie à clé publique permettant de créer et de manipuler des jetons cryptographiques. Il est ainsi possible de mettre en œuvre une délégation utilisant la méthode PKCS#11 pour permettre un accès à une clé de signature fournie par une autorité de certification ou pour inscrire des certificats utilisateur. Lors de la sous-étape S33, le module plateforme MEP1 émet la méthode de délégation sélectionnée à destination de la plateforme MEP2, par exemple sous la forme d’un message. Cette émission comprend notamment la politique de délégation qui a été configurée au cours de la sous-étape S32 et/ou différents paramètres associés, parmi lesquels, par exemple, les paramètres d’une requête CSR, les paramètres d’un certificat correspondant, les paramètres d’une autorité de certification, des paramètres de points de terminaison d’un certificat de type STAR/ACME ou d’un serveur LURK, etc. Lors de la sous-étape S34, et si l’émission de la politique de délégation qui configurée est bien reçue, la plateforme MEP2 renvoie une confirmation de réception à destination de la plateforme MEP1, par exemple sous la forme d’un message d’acquittement. Ce message d’acquittement permet éventuellement de renseigner ou de mettre à jour la localisation du module plateforme MEP2 au premier réseau MEC1. Lors de la sous étape S35, la méthode de délégation précédemment émise, la configuration et/ou les différents paramètres associés reviennent au module plateforme MEP2, qui transfère ces informations à la ou aux application(s) MEA2 pour mettre en œuvre la délégation. Ceci permet alors au deuxième réseau MEC2 de procéder à une configuration de l’application de service APP1 qui lui a été fournie. Cette configuration, au moyen notamment de l’au moins une contrainte d’interaction avec le premier et/ou le deuxième réseau, permet alors d’exécuter une commande du système cyber-physique R2 avec l’application de service APP1, dont une utilisation est ainsi déléguée au deuxième réseau MEC2. Une fois l’étape S3 et/ou les sous-étapes S31 à S35 mises en œuvre, lors de la sous-étape S41, le système cyber-physique R2 peut émettre une requête de RQ_R2 vers l’architecture MEC la plus proche, et dans le cas présent, le deuxième réseau MEC2. Comme illustré, cette requête est émise par le système cyber-physique R2 vers le module gestionnaire MECM2. Dans les présentes, le système cyber-physique R2 connaît a priori l’application qu’il nécessite pour effectuer une tâche. Un système cyber-physique peut aussi avoir connaissance du module plateforme de l’architecture MEC à laquelle il est connecté. Lors de la sous-étape S42, et sur réception de la requête RQ_R2, le module plateforme MEP2 émet une confirmation de réception à destination du système cyber-physique R2, ici par exemple sous la forme d’un message d’acquittement. Lors de la sous-étape S43, sur réception de la requête et/ou suite à l’émission de la confirmation de réception correspondante, une requête de commande de R2 est émise depuis l’application MEA2 du deuxième réseau MEC2 vers l’application MEA1 du premier réseau MEC1. En variante, la requête de commande peut aussi être émise par MEA2 vers le client IDS1 et/ou un module mandataire que comprend le premier réseau MEC1. Par exemple, en guise de requête, on peut préciser l’utilisation d’une application spécifique à R2, avec pour objectif de lui transmettre des commandes à exécuter. L’application APP1 peut dans ce cas être téléchargée, de sorte que le deuxième réseau MEC2 dispose de cette application, éventuellement durant une certaine durée. Par exemple, on peut plutôt permettre au deuxième réseau MEC2 une utilisation à distance de l’application APP1, par exemple depuis le premier réseau MEC1. Une autorisation d’utilisation de l’application APP1 peut dans ce cas être fournie de MEC1 au deuxième réseau MEC2, de sorte que le deuxième réseau MEC2 soit autorisé à utiliser cette application. Lors de la sous-étape S44, un message d’acquittement confirmant la réception et/ou la prise en compte de la requête de commande e confirmation de réception sous la forme d’un message d’acquittement est émise depuis MEA1 vers MEA2. Suite à la sous-étape S44, une sous-étape S45 peut être mise en œuvre de manière optionnelle. La sous-étape S45 comprend une émission d’un message d’acquittement par le gestionnaire MECM2 vers le système cyber-physique R2 pour lui indiquer la bonne mise en œuvre des sous-étapes S43 et/ou S44. La figure 6 représente un bloc-diagramme schématique d'un circuit de traitement informatique selon un exemple de mise en œuvre des réalisations décrites. Selon un exemple, ledit circuit de traitement informatique est un processeur. De préférence, un tel circuit de traitement informatique est un système sur puce 1000 agencé pour mettre en œuvre un procédé de commande d’un réseau informatique de périphérie. En particulier, ce circuit de traitement informatique peut correspondre à un élément matériel définissant ou compris dans l’un des modules plateforme MEP1 et MEP2, ou encore dans l’un des modules gestionnaires MECM1 et MECM2. De manière non limitative, le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU. Le système sur puce 1000 comporte en outre une mémoire à accès aléatoire 1020, notée RAM, apte à mémoriser le code exécutable du procédé de commande ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation, la capacité de mémoire de celui-ci peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple. En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des réalisations décrites précédemment, ainsi qu’une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues. L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010. Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, un support de stockage optionnel 1060 noté HD, et un module d’entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres. Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté. L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple. Dans l’exemple présenté ici, le système sur puce 1000 est un appareil programmable qui utilise un logiciel. Toutefois, à titre subsidiaire, la présente description peut être mise en œuvre dans n’importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC). Procédé de délégation d’une application de service (APP1) entre une pluralité de réseaux informatiques de périphérie à accès multiple (MEC1, MEC2) connectés entre eux, ladite application de service étant configurée pour commander un système cyber-physique (R2), le procédé comprenant: - fournir (S2) l’application de service d’un premier réseau (MEC1) à un deuxième réseau (MEC2) de la pluralité ; et - configurer (S3), par le premier réseau, une politique de délégation de l’application de service en fonction d’au moins une contrainte d’interaction avec le premier et/ou le deuxième réseau. Procédé selon la revendication 1, dans lequel la politique de délégation configurée est transmise d’un premier module plateforme à un deuxième module plateforme, le premier module plateforme et le deuxième module plateforme se situant respectivement dans le premier réseau et dans le deuxième réseau. Procédé selon la revendication 2, dans lequel la configuration de la politique de délégation comprend : - émettre (S31), par le deuxième module plateforme à destination du premier module plateforme, une requête de configuration (RQ_CFG) comprenant ladite au moins une contrainte d’interaction ; et - sélectionner (S32), par le premier module plateforme, une méthode de délégation à mettre en œuvre en fonction de l’au moins une contrainte d’interaction. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre localiser (S1) le premier réseau parmi ladite pluralité, ledit premier réseau comprenant l’application de service. Procédé selon la revendication 4, dans lequel la localisation du premier réseau comprend recevoir, par le deuxième module plateforme, une requête de fourniture (RQ_PROV) émise par un système de support d’opérations (OSS2) du deuxième réseau. Procédé selon la revendication 4 ou 5, dans lequel la localisation du premier réseau comprend autoriser, par un module gestionnaire de plateforme (MECM2) du deuxième réseau, un accès du deuxième réseau à l’application de service que comprend le premier réseau. Procédé selon l’une quelconque des revendications 4 à 6, dans lequel la localisation du premier réseau est mise en œuvre sur réception, par un dispositif propriétaire (IDS1) connecté à la pluralité de réseaux, d’une requête d’accès (RQ_ACC) à l’application de service que comprend le premier réseau, ladite requête d’accès étant émise par le deuxième réseau. Procédé selon la revendication 7, dans lequel la fourniture de l’application de service est mise en œuvre sur émission d’une requête de fourniture, par un système de support d’opérations (OSS2) du deuxième réseau audit dispositif propriétaire. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend en outre, sur réception, par le deuxième réseau, de la politique de délégation configurée, exécuter (S4), une commande du système cyber-physique au moyen de l’application de service fournie au deuxième réseau. Procédé selon l’une quelconque des revendications précédentes, dans lequel la fourniture de l’application de service comprend au moins l’un parmi un téléchargement de l’application de service, un clonage de l’application de service et/ou un partage à distance d’une utilisation de l’application de service. Procédé selon l’une quelconque des revendications précédentes, dans lequel la configuration de la politique de délégation comprend au moins un protocole de délégation choisi parmi un protocole ACME/STAR, un protocole PKCS #11, un protocole SubCerts et un protocole LURK. Procédé selon l’une quelconque des revendications précédentes, dans lequel la configuration de la politique de délégation comprend l’intégration d’au moins un paramètre de délégation, d’un cryptage et/ou d’un certificat de sécurité dans ladite politique de délégation. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’au moins une contrainte d’interaction est choisie parmi une priorité d’utilisation de protocole de délégation, une contrainte de configuration, une durée de délégation, une contrainte de terminal, une contrainte de connectivité réseau, un type d’application, une politique d’un opérateur et une contrainte de sécurité. Procédé selon l’une quelconque des revendications précédentes, dans lequel la fourniture de l’application de service du premier réseau localisé au deuxième réseau et/ou la configuration de la politique de délégation de l’application de service par le premier réseau est mise en œuvre sur réception, par le deuxième réseau, d’une requête correspondante émise par le système cyber-physique. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 14, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement informatique.