Brevet FR3124873A1 — publié le 20230106

Il est proposé un procédé de contrôle de traitement de programmes mis en œuvre dans un système comprenant des dispositifs informatiques connectés par un réseau, représentés par un graphe comprenant des nœuds, chacun ayant plusieurs ressources matérielles. Les nœuds sont logiquement indexés dans une structure multidimensionnelle selon les ressources d’un espace muldimensionnel. En réponse à une demande de traitement de microservices d’un programme, le procédé comprend un calcul (507), pour chaque microservice, d’un indicateur de qualité de service élémentaire associé au microservice, à partir de différences relatives à chaque paramètre de qualité de service parmi un ensemble de paramètres de qualité de services représentant des paramètres de capacité de ressources matérielles du dispositif source, et une opération (511) relative au traitement d’une partie des microservices du programme dans un dispositif du réseau en fonction des indicateurs de qualité de service. Le procédé permet d’optimiser la consommation énergétique des dispositifs. (Figure 5) Système et procédé de planification de traitement de programme L’invention concerne de manière générale le traitement de programmes informatique et en particulier un système et un procédé de planification dynamique de programme dans un réseau comprenant un ensemble de dispositifs informatiques. La gestion du traitement des programmes et des données dans les réseaux informatiques est un enjeu majeur. Un programme informatique peut être constitué d’un ensemble de microservices à exécuter en utilisant les ressources des dispositifs informatiques du réseau. En particulier, dans un environnement de réseau décentralisé, l'équilibrage de charge, la découverte des microservices et l'économie d'énergie sont difficiles à analyser en l'absence d'entité centrale contenant toutes les informations nécessaires pour appliquer l'heuristique de planification de traitement des programmes. Il existe des structures capables de modéliser les ensembles de données dans les réseaux informatiques sous la forme d’espaces avec autant de dimensions que les ensembles de données ont des caractéristiques. De tels espaces permettent d'insérer, d'analyser et de récupérer des données à des coûts d'exploitation efficaces. Des exemples unidimensionnels de structures existantes de modélisation de données sont les arbres basés sur des binaires, effectuant des opérations de gestion de données en O(Log (N)). Cependant, ces opérations se compliquent avec l'incrémentation des dimensions de la recherche dans les arbres. Pour surmonter un tel problème, des solutions reposant sur des métriques définies par des fonctions de distance et/ou sur des espaces à plusieurs dimensions ont été proposées. Ces solutions sont capables de gérer des ensembles de données multidimensionnelles du point de vue : - des distances entre ses éléments (par exemple BKT, BT ou LAESA), comme décrit dans Edgar Chávez, Gonzalo Navarro, Ricardo Baeza-Yates, and José Luis Marroquín. 2001. Searching in Metric Spaces. ACM Comput. Surv. 33, 3 (Sept. 2001), 273–321. https://doi.org/10.1145/502807.502808; ou - de l'abstraction de l'univers dans lequel ils existent (par exemple KD-tree, R* tree ou Z-ordering), comme décrit dans Volker Gaede and Oliver Günther. 1998. Multidimensional Access Methods. ACM Comput. Surv. 30, 2 (June 1998), 170–231. De telles approches de gestion de données permettent non seulement de traiter des requêtes de traitement de programmes basées sur une seule caractéristique/dimension pour obtenir un seul élément, mais aussi de récupérer toutes les données qui répondent à différents critères dans une certaine région, soit du point de vue d'un autre élément, soit du point de vue du point de vue de l'univers entier. Cependant les solutions existantes ne permettent pas un placement dynamique du traitement des microservices dans les dispositifs d’un environnement distribué, tenant compte de la consommation énergétique du système. Il existe ainsi un besoin pour un système et un procédé de planification de traitement de programme optimisé dans un réseau informatique constitué d’un ensemble de dispositifs informatiques. Pour améliorer la situation, Il est proposé un procédé de contrôle de traitement de programmes mis en œuvre dans un système informatique comprenant une pluralité de dispositifs informatiques connectés au moyen d’au moins un réseau informatique. Chaque dispositif a une pluralité de ressources matérielles, chaque programme étant configuré sous la forme d’un ensemble de microservices, chaque dispositif étant apte à traiter au moins un programme. La pluralité de dispositifs informatiques est représentée sous la forme d’un graphe comprenant des nœuds, deux nœuds étant reliés par un lien, un nœud représentant un dispositif informatique, un lien reliant de nœuds représentant la connexion entre les deux dispositifs informatiques représentés par les nœuds. Les nœuds sont logiquement indexés dans une structure multidimensionnelle selon les ressources d’un espace muldimensionnel. Le procédé comprend les étapes consistant à : - Recevoir une demande de traitement d’au moins une partie des microservices d’un programme d’un dispositif source de l’ensemble de dispositifs, émise dans l'espace multidimensionnel; - Pour chaque paramètre de qualité de service parmi un ensemble de paramètres de qualité de service représentant des paramètres de capacité de ressources matérielles du dispositif source, déterminer la différence entre la valeur cible et la valeur obtenue du paramètre de qualité de service pour le traitement du microservice par le dispositif requérant, ce qui fournit une différence relative au paramètre de qualité de service ;les paramètres de qualité de service comprennent au moins la fréquence du processeur central du dispositif source, la capacité de la mémoire RAM du dispositif source, le taux de transfert de l’interface réseau du dispositif source, et le taux de transfert du disque dur du dispositif; - Calculer pour chaque microservice, un indicateur de qualité de service élémentaire associé au microservice, à partir des différences relatives à chaque paramètre de qualité de service ; et - Calculer un indicateur de qualité de service de programme à partir des indicateurs de qualités de services élémentaires déterminées pour chaque microservice du programme; - Effectuer une opération de traitement relative au traitement d’au moins une partie des microservices du programme dans un dispositif du réseau en fonction des indicateurs de qualité de service. Dans un mode de réalisation, l’opération de traitement est un arrêt de la partie des microservices du programme dans le dispositif source. Dans un mode de réalisation, le procédé comprend en outre une étape de sélection d’au moins un dispositif candidat cible parmi la pluralité de dispositifs en fonction de l’indicateur de qualité de service de programme et d’une information de consommation d’énergie déterminée pour chaque dispositif à l’instant T, en utilisant le graphe. L’opération de traitement consiste alors à déplacer ou dupliquer la partie des microservices dans le au moins un dispositif candidat sélectionné pour une exécution du programme par le au moins un dispositif sélectionné. Dans des modes de réalisation, dans l’étape de sélection, le dispositif source est apte à rechercher un nœud voisin logiquement proche du nœud représentant le dispositif source dans le graphe et pour mettre en œuvre des échanges de négociations avec le nœud voisin. Le procédé peut comprendre une étape consistant à gérer les dispositifs du réseau en utilisant le graphe dans laquelle un nœud du graphe est apte à être ajouté ou supprimé dynamiquement de l'espace multidimensionnel. Un indicateur de qualité de service élémentaire associé à un microservice peut être calculé en effectuant la somme pondérée des différences relatives à chaque paramètre de qualité de service en utilisant des poids élémentaires associés à chaque paramètre de qualité de service. La somme des poids élémentaires peut être égale à 1. Dans un mode de réalisation, un indicateur de qualité de service de programme peut être calculé en effectuant la somme pondérée des qualités de services élémentaires déterminées pour les microservices du programme en utilisant des poids globaux associés à chaque microservice. La somme des poids globaux peut être égale à 1. Dans un mode de réalisation, l’indicateur de qualité de service élémentaire calculé pour un microservice peut être la valeur minimale entre les différences relatives à chaque paramètre de qualité de service, chacune pondérée par un indicateur d’impact. Dans un mode de réalisation, l’indicateur de qualité de service de programme peut être la plus petite valeur parmi les indicateurs de qualité de service élémentaires calculés pour les microservices du programme. Le procédé peut comprendre une étape de détermination de l’information de consommation d’énergie de chaque dispositif de l’ensemble de dispositifs, l’étape de détermination comprenant : - déterminer la consommation d’énergie du processeur central CPU du dispositif ; - déterminer la consommation d’énergie de la RAM du dispositif ; - déterminer la consommation d’énergie des carte d’interface réseau du dispositif et du disque dur du dispositif ; L’information de consommation d’énergie du dispositif peut être calculée à partir de la consommation d’énergie du processeur central CPU du dispositif, de la consommation d’énergie de la RAM, de la consommation d’énergie des cartes d’interface réseau et de la consommation du disque dur du dispositif. Dans un mode de réalisation, la consommation d’énergie E du processeur central CPU du dispositif peut être déterminée selon l’équation : désigne la capacitance du processeur central, désigne la tension du processeur central, désigne la fréquence du processeur central et la quantité d’énergie consommée à un instant donné par le (CPU) du dispositif. La consommation d’énergie E générée par un microservice donné sur la carte d’interface réseau ou le disque dur du dispositif peut être déterminée, selon l’équation : Wu désigne la consommation en Watts du dispositif lorsque la carte d’interface réseau du dispositif ou le disque dur du dispositif est dans un état actif. Wi désigne lorsque la carte d’interface réseau du dispositif ou le disque dur du dispositif est dans un état inactif. Li désigne le taux de transfert d’un microservice. L MAX désigne le taux de transfert maximal du microservice et L désigne la charge courante du dispositif à l’instant T. Dans un mode de réalisation, le procédé est lui-même exécuté sous la forme d’un microservice. Il est en outre proposé un système de contrôle de traitement de programmes, mis en œuvre dans un système informatique, comprenant une pluralité de dispositifs informatiques connectés au moyen d’au moins un réseau informatique, chaque dispositif ayant une pluralité de ressources matérielles, chaque programme étant configuré sous la forme d’un ensemble de microservices, chaque dispositif étant apte à traiter au moins un programme, la pluralité de dispositifs informatiques étant représentée sous la forme d’un graphe comprenant des nœuds, deux nœuds étant reliés par un lien, un nœud représentant un dispositif informatique, un lien reliant de nœuds représentant la connexion entre les deux dispositifs informatiques représentés par les nœuds. Les nœuds sont logiquement indexés dans une structure multidimensionnelle selon les ressources d’un espace muldimensionnel. Le système est configuré pour : - Recevoir une demande de traitement d’au moins une partie des microservices d’un programme d’un dispositif source (D) de l’ensemble de dispositifs, émise dans l'espace multidimensionnel; - Pour chaque paramètre de qualité de service parmi un ensemble de paramètres de qualité de service représentant des paramètres de capacité de ressources matérielles du dispositif source, déterminer la différence entre la valeur cible et la valeur obtenue du paramètre de qualité de service pour le traitement du microservice par le dispositif requérant, ce qui fournit une différence relative au paramètre de qualité de service, les paramètres de qualité de service comprenant au moins la fréquence du processeur central du dispositif source, la capacité de la mémoire RAM du dispositif source, le taux de transfert de l’interface réseau du dispositif source, et le taux de transfert du disque dur du dispositif; - Calculer pour chaque microservice, un indicateur de qualité de service élémentaire associé au microservice, à partir des différences relatives à chaque paramètre de qualité de service ; et - Calculer un indicateur de qualité de service de programme à partir des indicateurs de qualités de services élémentaires déterminées pour chaque microservice du programme ; - Effectuer une opération de traitement relative au traitement d’au moins une partie des microservices du programme dans un dispositif du réseau en fonction des indicateurs de qualité de service. Les modes de réalisation de l’invention permettent un placement du traitement des microservices sur les dispositifs informatiques du réseau de manière optimisée en fonction de la consommation d’énergie du système. Ils permettent notamment une reconfiguration dynamique par redéploiement des microservices et de modifier dynamiquement les reconfigurations des applications sur les divers dispositifs matériels du réseau. Avantageusement, ils permettent de déterminer les déploiements de microservices qui permettent la meilleure exploitation matérielle et la plus faible consommation électrique des composants matériels des dispositifs informatiques matériels du réseau. Brève Description des Figures D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement : La représente un exemple de système informatique dans lequel peut être mis en œuvre le système et le procédé de planification de traitement selon les modes de réalisation de l’invention; La représente schématiquement les composants matériels (ou ressources matérielles) d’un dispositif informatique, selon certains modes de réalisation de l’invention ; La est un exemple d’architecture de superposition de réseau pouvant être utilisée par le réseau informatique ; La est un organigramme représentant le procédé de supervision de microservice, selon certains modes de réalisation de l’invention ; et La est un organigramme représentant le procédé de planification de traitement, selon certains modes de réalisation de l’invention ; Description détaillée de la demande La représente un exemple de système informatique 100 dans lequel peuvent être mis en œuvre le système et le procédé de traitement de programme selon certains modes de réalisation. Le système informatique comprend au moins un réseau de communication 2, qui peut être centralisé ou non centralisé, et un ensemble de dispositifs informatiques 10 connectés entre eux via le réseau 2. Un réseau de communication peut être par exemple un réseau de type WIFI ou satellite (par exemple, Ethernet, sans fil, 4G, Bluetooth, etc.). Les dispositifs 10 (encore appelé « appareil » ou « machine ») peuvent comprendre tout type de dispositif informatique, notamment des dispositifs mobiles, comme des ordinateurs personnels, des téléphones mobiles intelligents (appelé « Smartphone » en langue anglo-saxonne), des tablettes informatiques, etc. Les dispositifs informatiques 10 peuvent supporter différents types de réseaux de communication. Les dispositifs informatiques 10 peuvent comprendre des dispositifs hétérogènes, c’est à dire de différents types. Un dispositif informatique 10 est apte à exécuter un programme (encore appelé ‘application’). Chaque programme étant configuré sous la forme d’un ensemble de composants logiciels de programme encore appelés ci-après « microservices ». Chaque dispositif informatique 10 est apte à traiter (c’est-à-dire exécuter) un programme et les microservices compris dans un programme. Les dispositifs informatiques 10 du réseau 2 sont représentés sous la forme d’un graphe comprenant des nœuds, deux nœuds étant reliés par une connexion, un nœud représentant un dispositif informatique, un lien reliant deux nœuds représentant la connexion entre les deux dispositifs informatiques représentés par les nœuds. Chaque programme est ainsi déployé sur un graphe de dispositifs connectés, dont les nœuds peuvent être: - des dispositifs individuels ayant des caractéristiques hétérogènes (par exemple des dispositifs dépendant de batteries, des dispositifs mobiles, et des dispositifs ayant des interfaces réseau différentes) ou - des entités abstraites telles que des clusters ou des cloudlets. Une entité abstraite désigne un fournisseur de ressources tel qu’un cluster ou un cloudlet. Une entité abstraite peut être déployée et connectée de la même manière que des dispositifs individuels, en établissant la quantité de ressources à fournir et gérer. Les dispositifs informatiques 10 peuvent ou non appartenir à une même hiérarchie, c’est-à-dire appartenir ou non à un seul niveau d'abstraction. Dans un mode de réalisation où les nœuds appartiennent à une même hiérarchie, le procédé de planification de traitement de programme peut être distribué, c’est-à-dire qu’il n'est pas exécuté par une unique entité centrale qui décide de la manière dont la charge doit être équilibrée mais est distribué parmi les nœuds correspondant aux différents dispositifs informatiques 10. Les nœuds représentant les dispositifs informatiques 10 peuvent alors mettre en œuvre un procédé de négociation en échangeant des messages pour gérer la planification du traitement. Le procédé de planification peut être utilisé dans différents types de système, tels que par exemple: - Dans des systèmes de clusters gérés par différents types de technologies. Dans une telle application, le procédé de planification de traitement peut remplacer un procédé de déploiement et d'équilibrage de charge classique de manière à avoir des nœuds “masters” qui ne soient que des gestionnaires de découverte et d'application de restrictions (nombre de copies, vitesse de réponse requise, etc.). - Dans des systèmes de dispositifs informatiques connectés par au moins un réseau 2 (par exemple ordinateurs portables, tablettes, téléviseurs intelligents) dans lesquels des applications peuvent être exécutées sur différents dispositifs du système, comme par exemple des systèmes de type Internet des Objets (IoT)). Les connexions entre les dispositifs informatiques 10 (représentées par des liens entre deux nœuds) permettent de déterminer le taux de transfert auquel les microservices peuvent envoyer ou recevoir des données entre eux. Un dispositif informatique 10 désigne une entité de traitement identifiable par un unique identifiant de dispositif ID. La est un schéma représentant un dispositif informatique 10, selon des modes de réalisation de l’invention. Un dispositif informatique 10 comprend un processeur 22, encore appelé Unité Centrale de Traitement ou CPU (acronyme pour l’expression anglaise correspondante « Central Processing Unit »), un dispositif de mémoire de masse 26, une interface entrée/sortie (E/S ou I/O en anglais) 28, et une interface homme-machine (HMI) 30. Le dispositif informatique 10 peut aussi être couplé à une ou plusieurs ressources externes 32 par l'intermédiaire d’un réseau 35 (qui peut être le même que le réseau 2 ou un autre réseau), ou d'un dispositif d’interface réseau 31. L’interface réseau 31 peut être connectée à un support de communication 33, qui peut être lui-même en communication avec d’autres dispositifs informatiques. Le dispositif d’interface réseau comprend une carte d’interface réseau NIC 310 (acronyme pour l’expression anglaise correspondante « Network Interface Card »). La carte réseau(NIC) permet les communications filaires et sans fil entre le dispositif 10 et d’autres dispositif informatiques 10 connectés via le réseau 2 ainsi que les communications via le réseau 35, par exemple au moyen du protocole Internet (IP). Les ressources externes 32 peuvent inclure, sans limitation, des serveurs, des bases de données, des dispositifs de mémoire de masse, des dispositifs périphériques, des services de réseau cloud, ou tout autre ressource informatique appropriée pouvant être utilisée avec le dispositif 10. Le processeur CPU 22 est configuré pour exécuter sur des instructions de programme enregistrées dans la mémoire 34. La mémoire 26 comprend une mémoire à accès aléatoire RAM 260 (Random Access Memory). La mémoire 26 peut en outre inclure un ou plusieurs dispositifs de mémoire comme par exemple et sans limitation une mémoire à lecture seule (ROM acronyme pour Read-Only Memory), une mémoire volatile, une mémoire non volatile, une mémoire vive statique (SRAM acronyme pour Static Random Access Memory), une mémoire dynamique à accès aléatoire (DRAM acronyme pour Dynamic Random Access Memory), une mémoire flash, une mémoire cache ou tout autre dispositif capable de stocker des informations. La mémoire de masse 24 comprend au moins un disque dur HDD 240 (Hard Disk Drive). Elle peut en outre comprendre des dispositifs de stockage de données tels qu’un disque optique, ou tout autre dispositif capable de stocker des informations. Le processeur CPU 22 peut fonctionner sous le contrôle d'un système d'exploitation 261 qui réside dans la mémoire 26. Le système d'exploitation 261 peut gérer les ressources du dispositif informatique 10 de sorte que le code des programmes du dispositif informatique 10, intégré sous forme d'un ou plusieurs logiciels d'application, telle que les applications 262 qui résident dans la mémoire 26, puisse disposer d'instructions exécutées par le processeur 22. En variante, le processeur 22 peut exécuter directement les applications 262 sans système d'exploitation 261. Une ou plusieurs structures de données 264 peuvent également résider dans la mémoire 26, et peuvent être utilisées par le processeur 22, le système d'exploitation 261, et/ou les applications 262 pour stocker ou manipuler des données. L'interface E/S 28 fournit une interface machine qui couple le processeur 22 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 35 ou les ressource externes 32. Le système informatique 100 peut comprendre des applications localisées extérieurement aux dispositifs informatiques 10 et pouvant être distribuées aux dispositifs informatiques 10 fournies par un système Cloud (nuage) sur le réseau 35. L’interface Homme Machine IHM 30 peut être couplée avec le processeur 22 pour permettre à un utilisateur d'interagir directement avec le dispositif informatique 10. L’interface IHM 30 peut inclure un affichage vidéo ou alphanumérique, un écran tactile, un haut-parleur et tout autre élément visuel et/ou audio capable de communiquer des données à l'utilisateur. L’interface IHM 30 peut aussi inclure des dispositifs de contrôle de saisie tels qu'un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur et de les transmettre au processeur 22. Le dispositif 10 peut comprendre une ou plusieurs bases de données 25 pour collecter et organiser les données utilisées par les différents composants du système. La base de données 25 peut inclure des données et/ou des structures de données stockant les données. Les bases de données 25 peuvent résider dans la mémoire de masse 24. Chaque dispositif informatique 10 a des capacités de composants spécifiques en termes de fréquence de processeur central CPU (22), de taille de RAM (260), de vitesse de disque dur (240), de taux de transfert du réseau 2 (vitesse à laquelle les données sont envoyées ou reçues par le réseau 2), et de batterie (29), en fonction du type de dispositif et de sa configuration. Chaque dispositif 10 est capable d’exécuter des microservices, en leur fournissant une quantité de ressources qui peut dépendre de leurs besoins et/ou de besoins de microservices compétiteurs (par exemple en cas de planification partagée proportionnelle). Un dispositif 10 comprend un programme de supervision qui s’exécute sur le dispositif pour : - suivre le statut de chacun de ses composants en terme de charge, de capacité et de consommation d’énergie; et - pour exécuter un procédé de planification de traitement distribué selon les modes de réalisation de l’invention. Le procédé de planification de traitement distribué permet de déterminer une opération de microservices parmi: - un déplacement de microservice(s) vers un autre dispositif pair 10; - un démarrage d’exécution de microservice(s) ; - un arrêt d’exécution de microservice(s) ; - un duplication d’un microservice vers un autre dispositif pair 10. De telles opérations peuvent dépendre de conditions de consommation énergétique de critères de négociation, d’équilibre de charge, de nombre de sauts, etc. Un programme (ou application) est également représenté par graphe orienté comprenant un ensemble de nœuds élémentaires, chaque nœud élémentaire représentant un microservice, les nœuds élémentaires étant reliés par des connexions entre les microservices. Tel qu’utilisé ici, un microservice désigne une entité fonctionnelle (composant logiciel du programme) identifiable avec un unique identifiant de microservice ID, qui a une fonction associée. Un microservice est un code qui représente cette fonction associée et qui peut être dupliqué par un système de traitement de programme. Lorsqu’un microservice est déployé sur un dispositif 10, le microservice requiert une quantité de ressources en termes de processeur central CPU (22), de capacité réseau (31), de RAM (260) et de disque dur (240) de la part du dispositif 10 qui l’exécute. Les microservices peuvent être de différents types tels que par exemple des microservices d’interface utilisateur graphique, des microservices de calcul et des microservices de gestion de données. Ces types de microservices peuvent différer entre eux sur le plan de : - leur consommation de ressources par défaut, - la quantité de données qu’ils envoient ou reçoivent, et - l’indicateur de restriction associé qui indique si le microservice peut être ou non déplacé et/ou dupliqué d’un dispositif 10 à un autre. Par exemple un microservice d’interface graphique IU peut être associé à un indicateur de restriction indiquant qu’il ne peut pas être déplacé dans la mesure où l’expérience utilisateur peut être affectée par un tel déplacement. Un microservice de calcul peut être associé à un indicateur de restriction indiquant qu’il peut être dupliqué ou déplacé vers un autre dispositif voisin. Un microservice de gestion de données peut être associé à un indicateur de restriction indiquant qu’il peut être déplacé mais un tel déplacement peut avoir un impact fort sur la consommation de bande passante. Un utilisateur d’un dispositif 10 peut créer son propre type de microservice. Les connexions entre deux dispositifs peuvent être directes (sans composants intermédiaires autres qu’un routeur) ou indirectes. Les connexions entre des microservices peuvent être logiques/fonctionnelles. Une connexion physique supporte plusieurs connexions de microservice et permet de suivre le taux de transfert possible maximum et courant entre deux dispositifs 10 (capacité de transmission maximale du dispositif avec l’interface réseau). Les connexions entre des microservices stockent logiquement un ensemble de connexions physiques qu’ils utilisent pour communiquer. Ainsi, il est possible de déterminer au moyen d’un superviseur du microservice le trajet des dispositifs 10 qu’une connexion de microservice utilise pour opérer, de même que les taux de transfert courant et attendu. Le système informatique 100 peut comprendre un centre d’opération 12 correspondant à une entité centralisée qui stocke toutes les références à des connexions dans le réseau 2 et à des dispositifs 10 déployés. Le système informatique 100 met en œuvre un procédé de planification pour déployer et planifier les microservices sur les dispositifs 10 du réseau, en fonction de la consommation d’énergie des dispositifs 10, et de la Qualité de Service des programmes. Lors du déploiement de dispositifs 10 dans le réseau 2, les paramètres de capacité du nouveau dispositif 10 peuvent être spécifiés. Par exemple, les paramètres de capacité peuvent comprendre : - la fréquence du CPU 22 du dispositif 10 en Ghz, - la capacité RAM 260 du dispositif 10 en MB, - la capacité réseau 31 en Mb/s du dispositif 10, - la capacité du disque dur 240 du dispositif en MB/s, - la capacité de la batterie 29 du dispositif. Dans un mode de réalisation, le système informatique 100 peut comprendre un gestionnaire de dispositifs 120, par exemple mis en œuvre dans le centre d’opération 12, configuré pour ajouter un dispositif 10 dans le réseau ou supprimer un dispositif 10 du réseau 2. La suppression peut être effectuée statiquement en réponse à une commande d’un utilisateur ou dynamiquement, selon un scénario de déploiement. Un opérateur du système peut activer une commande de suppression pour chaque dispositif 10 provoquant la suppression d’un dispositif 10, lorsque la commande de suppression est activée. Le procédé de planification de traitement de programme permet de planifier le traitement (l’exécution) des microservices sur un ou plusieurs dispositifs 10 du réseau. Ainsi, une fois déployé, un microservice utilise une quantité de ressources pour un temps déterminé ou indéfini. La taille d’un microservice en termes de sérialisation (quantité de données à envoyer sur le réseau si le microservice est déplacé ou dupliqué) peut être prédéfinie. Un tel attribut de taille peut être utilisé pour analyser le coût des opérations relatives à l’exécution de la planification du traitement en termes d’efficacité et d’énergie. Le système informatique 100 peut comprendre un gestionnaire de microservices 122 configuré pour exécuter une opération de microservice pouvant être un arrêt, un démarrage, une migration ou une duplication d’un microservice. Les microservices peuvent être déplacés (migrés) d’un dispositif D du réseau à un autre dispositif du réseau D’ en réponse à l’exécution du procédé de planification du traitement du microservice. Le gestionnaire de microservices 122 peut être implémenté dans le centre d’opération (comme dans l’exemple de la ) ou depuis un dispositif spécifique qui connaît ses pairs connectés et est capable d’exécuter des algorithmes décentralisés. En réponse à une demande de déplacement d’un microservice d’un dispositif D à un autre dispositif D’ : - le microservice libère d’abord les ressources de son dispositif courant D ; - le système de planification de traitement de programme exécute le processus de déplacement du microservice de D vers D’ en utilisant la connexion de réseau impliquée pendant une période de temps basée sur la taille du microservice ; - le microservice commence à se mettre en compétition pour les ressources du nouveau dispositif D’. Si un microservice est déplacé, le microservice peut devenir inatteignable pour une de ses dépendances. Des mécanismes de recherche peuvent alors être mis en œuvre pour une instance dupliquée ou pour établir une recherche spéciale et des mécanismes d’optimisation de trajet pour résoudre un tel problème d’accès au microservice. Le gestionnaire de microservices 122 peut dupliquer un microservice requis en réponse à l’exécution du procédé de planification du traitement du microservice, par exemple si le procédé de planification détermine qu’un tel microservice est très demandé et produit une consommation d’énergie excessive ou une faible QoS (Qualité De Service). Le procédé de planification détermine alors le dispositif cible D’ sur lequel dupliqué le microservice qui peut être : - le même dispositif que le microservice d’origine, ou - un autre dispositif connecté ou atteignable par le dispositif D. Le gestionnaire de microservices 122 peut arrêter ou démarrer un microservice en réponse à l’exécution du procédé de planification du traitement du microservice. Les dispositifs et/ou les microservices arrêtés peuvent être mis en état de veille ou supprimés de manière permanente. Le procédé de planification permet d’optimiser la charge des dispositifs informatique 10 du système 100 en fonction de la consommation d'énergie des composants matériels des dispositifs informatiques 10. Le procédé de planification des ressources permet de déterminer dynamiquement les dispositifs informatiques 10 sur lesquels le traitement d’un ou plusieurs programmes (ou applications) constitué de microservices doit s’exécuter de manière à optimiser la consommation d’énergie dans le réseau 2. Dans un mode de réalisation de l’invention où le procédé de planification est décentralisé, chaque dispositif informatique 10 peut exécuter des étapes du procédé de planification et négocier avec les autres dispositifs informatiques du réseau 2 en échangeant des messages pour la sélection du ou des dispositifs informatiques cibles sur lesquels la ou les programmes requis doivent être exécutés. Dans des modes de réalisation, des paramètres de configuration du procédé de planification peuvent être modifiés pour réduire la consommation énergétique d'une ou plusieurs ressources spécifiées (comme le CPU 22, la RAM 260, la batterie 29, etc.). Les dispositifs informatiques 10 sont agencés de sorte que chaque dispositif informatique 10 puisse rechercher un autre dispositif informatique dans le réseau 2, en fonction de la charge d’au moins une ressource parmi un ensemble de ressources des dispositifs informatiques 10. Le gestionnaire de dispositifs 3 est notamment apte à ajouter ou supprimer dynamiquement de nouveaux dispositifs. Ainsi un dispositif peut être isolé à un moment donné et reconnecter dynamiquement à un autre instant. Dans un mode de réalisation, l’ensemble de ressources informatiques comprend une ou plusieurs ressources parmi le CPU 22, la RAM 260, la carte d’interface réseau NIC 310, le disque dure 20, la batterie 29 d’un dispositif informatique 10. Le système et le procédé de planification de traitement de programme selon les modes de réalisation de l’invention exploitent des requêtes d'un espace multidimensionnel de ressources matérielles (encore appelées ‘composants matériels’ ci-après) pour optimiser la consommation de l'énergie dans un environnement de microservices. La consommation d'énergie des composants matériels des dispositifs informatiques 10 est étroitement liée à la manière dont sont utilisés ces composants matériels. Par exemple pour un composant de type processeur, la consommation d’énergie peut dépendre de l'intensité, ou de l’utilisation de fonctionnalités spéciales du processeur comme un « turbo boost », etc. Ainsi, à un instant donné, pour un microservice M exécuté dans un dispositif informatique D source (10) générant une charge L et une consommation d'énergie E, le procédé de planification de traitement de programme détermine un dispositif destinataire D' dans le réseau 2 tel que: - D’ dispose au moins de ressources matérielles C de telle sorte que C>=L et - la consommation d'énergie E' générée par le microservice M dans D' soit inférieure à la consommation énergétique E (par exemple, en raison de la charge de courant ou des caractéristiques particulières des composants matériels concernés). Le dispositif D’ est alors candidat pour exécuter le microservice M en déplaçant M de D vers D’. Le procédé de planification de traitement de programme selon les modes de réalisation de l’invention permet une organisation intelligente des dispositifs informatiques 10 du réseau 2 (par exemple réseau P2P). Ainsi, si un dispositif informatique D a des problèmes de surcharge ou d'énergie (par exemple, situation de batterie faible, dépenses énergétiques des ventilateurs, etc.), le système et le procédé de planification de traitement selon les modes de réalisation de l’invention permettent au dispositif informatique D de déplacer un ou plusieurs microservices M vers un autre dispositif informatique D’ pour diminuer la charge de D et/ou économiser l'énergie de D. En outre, le système et le procédé de planification de traitement selon les modes de réalisation de l’invention peuvent permettre à un dispositif informatique D’ sous-chargé de proposer de l'aide à un ou plusieurs autres dispositifs informatiques D pour traiter les microservices de ces dispositifs D d'une manière plus économe en énergie. Les ressources matérielles des dispositifs 10 dans le réseau 2 sont organisées sous la forme d'un espace multidimensionnel à N dimensions (par exemple un espace à 4 dimensions). Les dimensions correspondent à des paramètres de capacités représentant des paramètres de capacité de composants des dispositifs informatiques 10. Chaque nœud (10) du réseau 2 peut faire des requêtes dans l'espace multidimensionnel selon la ou les ressources à optimiser, chaque nœud pouvant trouver un voisin logiquement proche au sens des paramètres à optimiser sur ces ressources (énergie par exemple) pour engager des négociations et effectuer des opérations sur les microservices (telles qu’une opération d’arrêt, de déplacement, ou de duplication) pour optimiser les paramètre choisis, chaque nœud pouvant entrer ou sortir dynamiquement de l'espace sans altérer la stabilité du système. Dans un mode de réalisation, l’espace multidimensionnel est un espace à au moins 4 dimensions (N au moins égal à 4), les quatre dimensions correspondant 4 paramètres de capacité comprenant un paramètre de capacité du processeur central 22, à un paramètre de capacité de la RAM 260, à un paramètre de capacité de l’interface réseau 31, et à un paramètre de capacité du disque dur 240. Dans un mode de réalisation, les quatre paramètres de capacité comprennent : C1. la fréquence du processeur 22 exprimée en GHz, C2. la capacité de la RAM 260 exprimée en Mo, C3. le taux de transfert réseau associé à l’interface réseau 31, et C4. la vitesse du disque dur 240. Pour faciliter la suite de la description, il sera considéré que l’espace multidimensionnel U est défini, dans un ensemble de dispositifs 10 connectés à un réseau commun 2, et comprend les 4 dimensions C1 à C4. Des requêtes peuvent être échangées dans l’espace U pour permettre à un dispositif 10 de déterminer le ou les dispositifs 10 du réseau qui ont des ressources suffisantes ou des caractéristiques optimales pour un traitement de microservices, comme par exemple, un microservice à faible besoin de processeur et un dispositif 10 dont le processeur est capable de désactiver certains cœurs pour exécuter un microservice donné. Pour déterminer si un microservice est un candidat pour un déplacement ou une duplication dans un processus de négociation ultérieur avec un autre dispositif 10 (mis en œuvre au moyen d’échange de messages entre les dispositifs 10), chaque dispositif 10 peut analyser les exigences, le type et les restrictions de traitement d’un microservice. Les microservices peuvent comprendre : - des microservices qui restent en cours d'exécution jusqu'à ce qu'un objectif soit atteint, tandis que d'autres continuent d'exécuter en permanence des demandes en attente. - des microservices qui peuvent être déplacés ou non en fonction de leurs objectifs. Par exemple, alors qu'un microservice qui effectue des opérations CPU à coût élevé peut être déplacé ou dupliqué pour équilibrer la charge, un microservice qui représente un élément d'une interface graphique ne doit pas toujours être déplacé car il fonctionne généralement avec un seul écran. Le système et le procédé de planification selon les modes de réalisation de l’invention permettent de déterminer sur quel dispositif cible 10 du réseau exécuter un microservice, en mettant en œuvre un processus de négociation préalable d'une opération de microservices entre les dispositifs informatiques 10 à l’issu duquel il peut être décidé de démarrer, migrer, arrêter, ou dupliquer les microservices sur un dispositif informatiques sélectionné. Dans un mode de réalisation décentralisé, le système et le procédé de planification de traitement selon les modes de réalisation de l’invention permettent à chaque dispositif 10 d'analyser sa propre charge et/ou sa propre consommation énergétique afin d'effectuer des opérations liées au traitement des microservices (opérations de négociation, d’équilibrage de charge, d’interrogation, etc.) au moyen d’échanges directs avec d'autres dispositifs 10 du réseau. Le réseau 2 peut reposer sur différentes architectures de superposition de réseau pour permettre aux dispositifs informatiques 10 de rechercher des informations ou des dispositifs informatiques pairs dans un nombre logarithmique de sauts (“hops”) en faisant abstraction du réseau 2 en tant que déploiement de structure de données, tels que: - une liste circulaire ordonnée itérée avec des techniques de hachage, dont les nœuds et les informations sont indexées dans le même univers d'identifiants un exemple de liste circulaire ordonnée repose par exemple sur la technique “Chord” (comme décrit par exemple dans Ion Stoica, Robert Morris, David Karger, M. Kaashoek, and Hari Balakrishnan.2001. Chord: A scalable peer-to-peer lookup service for internet applications, Vol. 149-160. 149–160. https://doi.org/10.1145/383059.383071); - un arbre binaire qui peut être exploré à travers un espace binaire et des opérations logiques comme XOR (comme décrit par exemple dans Petar Maymounkov and David Eres. 2002. Kademlia: A Peer-to-peer Information System Based on the XOR Metric. Kademlia: A Peer-to-peer Information System Based on the XOR Metric 2429. https://doi.org/10.1007/3-540-45748-8_5 Microsoft. 2018. Creating composite UI based on microservices); ou - une liste chaînée de nœuds qui peuvent rechercher des éléments en effectuant des sauts intelligents dans la structure (comme décrit par exemple dans S. Mandal, S. Chakraborty, and S. Karmakar. 2012. Deterministic 1–2 skip list in distributed system. In 2012 2nd IEEE International Conference on Parallel, Distributed and Grid Computing. 296–301). Cependant, l’invention n’est pas limitée à de telles architectures de superpositions de réseau et peut reposer sur d’autres types d’architectures de superposition de réseau qui permettent le déploiement et les requêtes dans des espaces multidimensionnels sur les réseaux P2P. Dans un exemple de mode de réalisation, l’espace U peut par exemple reposer sur l’architecture de superposition MAAN (Multi-Attribute Addressable Network) qui dépend de la technique Chord, comme décrit par exemple dans M. Cai, M. Frank, J. Chen, and P. Szekely. 2003. MAAN: a multi-attribute addressable network for grid information services. In Proceedings. First Latin American Web Congress. Chord est un réseau de recouvrement de type table de hachage distribuée pour les réseaux pair à pair (P2P). Chord déploie une liste circulaire ordonnée de dispositifs 10 dans laquelle les dispositifs sont organisés dans le sens des aiguilles d'une montre en fonction de leur identifiant ID. Dans Chord, chaque dispositif ainsi que les éléments à rechercher (c'est-à-dire les données, les processus, etc.) sont identifiés avec le même univers d’identifiants IDs. La table de hachage distribuée stocke des paires de clé/valeur en assignant des clés aux différents dispositifs informatiques 10 qui correspondent à des nœuds. Un nœud stocke les valeurs de toutes les clés dont il est responsable. Chord définit la manière selon laquelle des clés sont assignées à des nœuds et comment un nœud peut découvrir la valeur pour une clé donnée en localisant le nœud responsable de la clé. Les nœuds et les clés sont assignés un identifiant à m bits en utilisant une fonction de hachage (par exemple selon l’algorithme SHA-1). Selon le protocole Chord, les nœuds et les clés sont agencés dans un cercle d’identifiants qui a au plus 2 m nœuds allant de 0 à 2 m -1, m étant le nombre de bits dans la clé de hachage. Certains des nœuds correspondent à des dispositifs informatiques ou à des clés tandis que d’autres sont vides. Un nœud a un successeur et un prédécesseur. Le successeur d’un nœud est le nœud suivant dans le cercle selon une direction horaire. Les nœuds correspondant à des clés peuvent également avoir des successeurs. Le successeur d’un nœud correspondant à une clé k est le premier nœud dont l’identifiant est égal à k ou qui suit k dans le cercle (appelé successeur (k)). Chaque clé est stockée dans un nœud successeur de sorte qu’une recherche de clé k revient à rechercher successeur (k). Le protocole Chord permet de demander une clé à un client (nœud généralement) pour trouver successeur (k). Chord implémente une méthode de recherche rapide selon laquelle chaque dispositif informatique 10 (représenté par un nœud chord) maintient une table d’adresses (appelée ‘finger table’ en langue anglo-saxonne) contenant jusqu’à m entrées, m étant le nombre de bits dans la clé de hachage. La table d’adresse contient autant d'éléments que la longueur de la chaîne de bits qui représente l'ID le plus élevé de tous les éléments. La i-ème entrée d’un nœud n contient successeur ((n+2 i-1 ) mod m). La première entrée de la table du nœud est le successeur immédiat du nœud. Lorsqu’un nœud recherche une clé k, il passe la requête au successeur ou prédécesseur le plus proche de k selon la table ‘finger’ La illustre un exemple d’architecture de superposition de type chord à plusieurs nœuds (N1, N8, etc.) agencés selon un cercle, comme décrit dans Ion Stoica, Robert Morris, David Karger, M. Kaashoek, and Hari Balakrishnan. 2001. Chord: A scalable peer-to-peer lookup service for internet applications, Vol. 149-160. 149–160. https://doi.org/10.1145/383059.383071. La montre la table d’adresses (‘finger table’) du nœud N6. La montre les entrées de la table d’adresse au nœud N6 et une requête « Lookup(29) » pour rechercher la clé 29 en commençant au niveau du nœud N6 en utilisant l’algorithme de recherche Chord. Dans l’exemple de la , le système prend en charge jusqu'à 127 (1111111 dans le système binaire) dispositifs 10. Par conséquent, la table d’adresses peut contenir jusqu'à 7 éléments. Chaque index i de la table d’adresse est défini par l'identifiant ID de chaque nœud ajouté à 2 i étant compris entre 0 et la longueur de la chaîne de bits qui représente l'ID le plus élevé de tous les éléments. Dans l’approche Chord existante, chaque fois qu’un élément E est recherché à travers un nœud N, N recherche l’index du successeur de E dans sa table d’adresse (finger table), c’est-à-dire l’index le plus élevé possible qui ne dépasse pas l’identifiant de E. Par exemple, si dans la topologie de la , l'élément 24 est recherché par le nœud N6, il sera déterminé que l'élément 24 doit être dans le nœud N23, puisqu'il s'agit de l'élément stocké entre l'index 22 (N6 + 16), c'est-à-dire le plus haut identifiant possible, qui ne dépasse pas 24 (sinon, N6 + 32 = 38). Ainsi, la structure de données utilisée pour rechercher des éléments est une table de hachage cohérente. D'autre part, les nœuds peuvent rejoindre et quitter à tout moment le réseau 2 de manière dynamique. Une opération d’insertion ou de sortie de nœud du réseau 2 peut être mise en œuvre pour atteindre ce dynamisme. Un nouveau nœud nN et d'autres nœuds du réseau doivent effectuer plusieurs opérations pour que nN rejoigne le réseau Chord. Le nœud entrant nN se voit d’abord attribuer un ID unique en utilisant une fonction SHA-1 pour transformer son adresse IP. Ensuite, un mécanisme externe garantit une connexion entre nN et un nœud préexistant du réseau Chord qui est trouvé en exécutant une requête à l'intérieur du réseau pour trouver un nœud représentatif d'un successeur immédiat de nN: nN1. L’information de nN1, constituée d'une référence de nœud prédécesseur de cercle immédiat et d'une table d’adresses (“finger table”), est ensuite utilisée par nN pour affecter sa propre référence de prédécesseur de cercle à celle de nN1 et remplir sa propre “finger table” en copiant celle de nN1. Enfin, la référence prédécesseur de nN1 est remise à nN à cet instant. Une fois que nN a été initialisé, une mise à jour est émise en se déplaçant dans le sens antihoraire le long du cercle pour mettre à jour les tables d’adresses (‘finger tables’) des nœuds précédents, en reconnaissant l'existence de nN et en préservant la cohérence des tables d’adresses. Cette mise à jour est effectuée en attribuant l'ID de nN aux références de tables d’adresses (“finger tables”) appropriées à l'intérieur de la table d’adresses du nœud prédécesseur P si les deux conditions suivantes sont remplies : - P précède nN d’au moins 2 i -1 où i est compris entre 1 et m, avec m désignant la longueur des tables d’adresse, et - La dernière entrée du nœud P succède à nN. Cette opération de mise à jour est maintenue jusqu'à ce qu'un nœud précédent P, dont la i-ème entrée précède nN, soit atteint. Enfin, la responsabilité des clés correspondantes est déléguée du nœud nN1 à nN. Une opération de sortie d’un nœud affecte les membres du réseau lorsque l'opération de sortie est exécutée. Plus précisément, un nœud sortant LN informe tout d’abord son nœud prédécesseur pLN que le nœud successeur immédiat de LN dans le cercle, LN1, est désormais son successeur immédiat dans le cercle. Ensuite, la référence de prédécesseur de cercle de LN1 est définie sur pLN. Une opération de mise à jour similaire à celle décrite pour l'opération d’insertion est effectuée avec l'ID du successeur de LN. Le but de cette opération de mise à jour est de maintenir à jour les tables d’adresses (“finger tables”) situées dans la contre-horloge le long du cercle. Enfin, la responsabilité des clés de LN est déléguée à LN1. L’architecture MAAN existante généralise l'approche Chord pour prendre en charge les requêtes à n dimensions ainsi que les requêtes par intervalle. MAAN utilise une première fonction de hachage (SHA-1 par exemple) afin d'attribuer un identifiant de bits de longueur m pour chaque nœud et une deuxième fonction de hachage préservant la localité (une fonction configurée pour fournir en sortie des valeurs consécutives à partir d'entrées associées) qui, à la différence de l'approche Chord de base, est utilisé pour attribuer à chaque attribut un identifiant dans l'espace de m-bits en fonction de sa valeur (même espace partagé par les identifiants de nœud de m-bits). L’utilisation de tels identifiants permet d’éviter que la première fonction de hachage (SHA-1) ne détruise la localité des clés dans la mesure où MAAN cherche à leur associer des valeurs d'attributs numériques au lieu des noms d'objets. Ainsi, cela permet l'exécution de deux approches de résolution de requêtes multi-attributs différentes qui ne sont pas possibles dans le système de Chord, ces deux approches comprenant: - Une approche itérative, qui consiste en une recherche de ressources issue d'un nœud N et composée d'un nombre M de sous-requêtes suivantes en fonction du nombre n de dimensions d'attribut disponibles. L’approche itérative fournit une série de listes de candidats qui sont ensuite intersectées dans le nœud d'origine N dans le but de trouver le candidat le plus apte ; - Une résolution de requête dominée par un attribut unique visant à trouver des candidats appropriés en effectuant une recherche répondant aux besoins d'un seul attribut dominant, retournant un ensemble candidat X. Des sous-requêtes pour d'autres attributs sont ensuite appliquées sur X pour obtenir un ensemble unique des candidats dont les membres répondent aux besoins d'autres ressources. Enfin, le nœud d'origine N procède à la sélection du candidat le plus apte par corrélation. En variante, les sous-requêtes peuvent être appliquées localement dans les nœuds membres de X. Les ressources de périphériques (CPU 22, RAM 260, HDD 240, Interface Réseau 31 et/ou batterie 29) existent à l'intérieur de l'espace U en fonction de la disponibilité de leurs capacités de traitement. Le procédé de planification de traitement selon les modes de réalisation permet de trouver et d’indexer efficacement les ressources qui permettent d’effectuer des opérations de migration et de duplication des microservices afin de réaliser des économies d'énergie. L'espace U étant multidimensionnel (au moins 4 dimensions de ressources), une indexation multidimensionnelle des ressources est prise en charge. L'espace U comprenant au moins les 4 dimensions liées aux ressources matérielles (1) fréquence du processeur en GHz, (2) capacité de la RAM en MB, (3) taux de transfert réseau en Mbps, et (4) vitesse du disque dur en Mbps, l’architecture de superposition, par exemple MAAN, peut être utilisée pour indexer chaque valeur de disponibilité de ressource de périphérique sur l'axe U correspondant. Lorsqu'un appareil a l'intention de rejoindre le réseau MAAN, au moins 4 nœuds logiques différents sont créés dans les 4 dimensions de l’espace (un nœud pour chaque dimension), conformément à l'axe de l'espace U. Ces 4 nœuds logiques suivent des opérations similaires à celles décrites pour des opérations d'insertion de nœuds de Chord. Une formule de préservation de localité qui, pour toute dimension, transforme une valeur numérique représentant la disponibilité d'une ressource en un identifiant correspondant cohérent avec l'espace d'identifiant disponible est en outre utilisée. La formule 1 indique une limite supérieure pour les valeurs d'entrée numériques et un nombre maximal de nœuds pris en charge : (1) Dans la formule (1), V désigne une valeur d’entrée, N désigne la quantité maximale des nœuds et SL désigne la valeur maximale qu’un nœud peut avoir concernant une ressource (disponibilité d’un composant matériel). La formule (1) est utilisée pour transformer la disponibilité d'une ressource en un nombre entier ID. Ainsi, la valeur d’entrée numérique V est multipliée par le nombre maximal de nœuds pris en charge (à tout moment) N et le produit obtenu VxN est divisé par la valeur limite de ressource maximale SL de tous les dispositifs, où les valeurs SL et N sont relatives à chaque contrainte de dimension. Une limite inférieure existe en tant que valeur constante de 0 pour toutes les dimensions en considérant que la position 0 est associée à 0 disponibilité des ressources, tandis que SL n’est pertinent que pour le contexte de chaque dimension (différence d’unités et de magnitudes) et N est une valeur constante. La formule (1) permet de conserver un univers unique d’ID entiers numériques pouvant être attribués aux nœuds quelle que soit la dimension. Ainsi, selon les modes de réalisation de l’invention, les tables d’adresses (“finger tables”) contiennent des enregistrements dans des paires d'identificateurs d'espace de m-bit et de références de nœuds. De tels éléments permettent d’exécuter des requêtes à n-dimensions en appliquant une approche itérative comme celle utilisée dans la proposition originale de MAAN. Il est à noter que les nœuds ayant une valeur de disponibilité déjà existante pour n'importe quel attribut peuvent rejoindre le réseau, ce qui entraîne une attribution d'identifiant identique à celle d'un nœud préexistant dans le réseau. Pour éviter une collision provoquant le placement de tout nœud entrant entre un nœud de cercle successeur et (s’il existe) un nœud identique à lui-même, ci-après appelé « nœud jumeau » (“twin node” en langue anglo-saxonne), un procédé peut être mis en œuvre pour gérer les nœuds impliqués dans ce phénomène de collision, selon des modes de réalisation de l’invention. Lorsqu'un “nœud jumeau” TN tente de rejoindre le réseau et trouve un nœud prédécesseur rN (nœud racine qui a attribué le même identifiant que TN) le long du cercle, TN entre dans une liste de “nœuds jumeaux” de rN dans laquelle chaque nœud a une référence à son jumeau dans la position précédente et suivante dans la liste. Dans la suite de la description, il est supposé que l’approche itérative de la technique MAAN est utilisée, à titre d’exemple non limitatif, en considérant toute liste de candidats. Un verrou candidat peut être utilisé pour éviter les collisions de sélection de ressources. Des collisions de sélection de ressources se produisent lorsque le même nœud est sélectionné comme candidat le plus apte par plusieurs exécutions de requêtes différentes et que des opérations simultanées de migration/duplication de microservices se produisent vers ce nœud, provoquant la saturation et augmentation de la consommation énergétique du nouveau candidat en raison des microservices nouvellement reçus en concurrence. Le verrou-candidat est appliqué sur chaque membre , ce qui signifie que les appareils peuvent être candidats à une seule requête à la fois. L'opération de sortie d’un nœud est similaire à celle de la technique Chord, en traitant les “twin node” comme une fonctionnalité supplémentaire. Pour toute liste de « twin nodes » à l'intérieur de tout nœud racine parent préexistant rN, si rN quitte le réseau, le premier “twin node” TN de la liste de twins à l'intérieur de rN est affecté comme nouveau rN en copiant les éléments de rN, tels que la référence du prédécesseur et sa table d’adresse (“finger table”). Dans le cas où un “twin node” à l'intérieur de la liste de jumeaux de rN part, il est supprimé de la liste “twins” de rN et les références de son prédécesseur et successeur de la liste sont réinitialisées. Des trames de données (« dataframes ») peuvent être implémentées pour obtenir la valeur du changement de disponibilité des ressources dans chaque dispositif, ce qui permet de contrôler la fréquence à laquelle les nœuds sont réindexés dynamiquement dans l’architecture de superposition (par exemple MAAN). Les trames de données (“dataframes”) désignent une collection limitée de valeurs de mesure de la disponibilité des ressources liées à une seule ressource. Le processus de réindexation d'un seul nœud peut ainsi être effectué via un service de supervision qui fait partir le nœud puis le rejoindre à nouveau s'il y a un changement substantiel de son identifiant. Le système 100 peut mettre en œuvre un procédé de calcul pour déterminer si un nœud doit être ré-indexé ou non comprenant les étapes consistant à: - trouver la valeur moyenne dans la trame de données (dataframe) pour obtenir un identifiant qui lui est associé, et - si l'identifiant est différent de celui actuellement indexé, effectuer une opération de ré-indexation sur ce nœud. Pour réduire la consommation d’énergie dans le réseau 2 de dispositifs 10, les caractéristiques des composants matériels des dispositifs et la manière dont ils sont utilisés par les processus en cours d’exécution sont pris en compte. L'exécution de microservices dans les dispositifs du réseau prend en compte leur charge en termes de fréquence CPU (22), de RAM (260), de taux de transfert réseau (310) et de vitesse de disque dur (240) et/ou batterie (29). L’optimisation de la consommation du réseau prend en compte, pour chaque composant CPU (22), de RAM (260), de taux de transfert réseau (310) et de vitesse de disque dur (240) et/ou batterie (29): - la quantité d'énergie consommée par rapport à sa charge, - la quantité d'énergie consommée par un microservice en cours d'exécution, et - la quantité d'énergie consommée par un microservice s'il était migré ou dupliqué sur un autre dispositif. En réponse à une insertion d’un dispositif informatique 10 dans le réseau 2 (le réseau 2 ayant par exemple une configuration MAAN contenant l’espace U déployé), un procédé de supervision de microservices peut être mis en œuvre pour superviser ses microservices et ses ressources matérielles par exemple par le gestionnaire de microservice 122 ou de manière décentralisée par le dispositif 10. La décrit le procédé de supervision mis en œuvre par un dispositif 10 pour son insertion dans le réseau 2, selon des modes de réalisation de l’invention (approche décentralisée de la supervision). À l’étape 400, à chaque instant écoulé la charge supportée par chacun des composants matériels du dispositif 10 est estimée. À l’étape 402, l’ensemble de microservices que le dispositif exécute sont gérés en utilisant un procédé de supervision mis en œuvre par chaque dispositif. L’étape 402 de gestion de microservices permet de vérifier que chaque composant matériel du dispositif n’est pas en surcharge. S’il est vérifié qu’un composant du dispositif est en surcharge, une opération de microservice parmi un démarrage, un arrêt, une migration ou une duplication de microservice peut être mise en œuvre. À l’étape 402, le dispositif 10 utilise son procédé de supervision pour analyser son état de charge par composant (ressource matérielle) et son état de consommation énergétique par composant. À l’étape 404, des informations relatives au dispositif et/ou aux microservices sont déterminées, comprenant : - des informations de performances relatives au dispositif 10 telles que la charge des composants matériels du dispositif, ou les capacités des composants matériels du dispositif; - des informations relatives aux microservices que le dispositif exécute, comme les exigences de traitement, le temps d'exécution et la charge générée par l’exécution des microservices dans chacun des composants matériels. De telles informations peuvent être collectées pendant l’étape 402 de gestion de supervision. À l’étape 406, le procédé de supervision peut mettre en œuvre une analyse des trames de données (“dataframes”) de chaque ressource matérielle (notamment le CPU 22, la RAM 260, le HDD 240, l’interface réseau 31, et optionnellement la batterie 29) du dispositif 10 pour maintenir des informations de consommation mises à jour. Une telle supervision est mise en œuvre de sorte que les dispositifs 10 du réseau 2 puissent atteindre un état d'énergie de charge efficace au moyen du procédé de planification de traitement de programme selon les modes de réalisation de l’invention et d’échanges de messages dans le cadre d’un processus de négociation collaborative entre les dispositifs 10. Les informations collectées pendant le procédé de supervision permettent de déterminer les états de charge et de consommation par ressource matérielle du dispositif 10. Le traitement de planification de traitement permet à un dispositif initial de rechercher un autre dispositif candidat 10 dans le réseau 2 et négocier avec ce dispositif candidat pour déplacer ou dupliquer au moins une partie des microservices du programme en fonction de l’état de charge et de consommation du dispositif source déterminé à partir des informations collectées par le procédé de supervision. Le procédé de planification permet notamment: - à un dispositif source D (10) de rechercher un autre dispositif candidat D’ pour traiter un microservice répondant aux exigences de traitement associés au microservice avec une consommation d'énergie inférieure ; ou - à un dispositif source D qui présente des conditions de surcharge dans ses ressources matérielles (CPU 22 et/ou composants NIC 310 et HDD 240 par exemple) de mettre en œuvre une action d’économie d’énergie, pour éviter l’utilisation de mécanismes de dissipation de chaleur (comme un ventilateur) qui entraîne une consommation d'énergie plus élevée ; ou - de migrer des microservices d’un dispositif source D à un dispositif destinataire D’ pour arrêter le dispositif D, et ainsi économiser de l'énergie ; - à un dispositif source D de migrer des microservices à consommation élevée/faible vers un ou plusieurs dispositif destinataires. L’exécution du procédé de planification peut avoir pour résultat des actions relatives aux microservices ou au dispositif source D (opération de microservice tel qu’un déplacement ou une migration ou une action d’économie d’énergie dans le dispositif source D) qui dépendent de la situation énergétique du dispositif source selon qu’il est déterminé, en réponse à l’exécution du procédé de planification de traitement, que: i. le dispositif source D est saturé : dans ce cas, des opérations de migration sont effectuées en réponse à l’exécution du procédé de planification de traitement. ii. le dispositif source D n'est pas saturé mais il est détecté que la consommation d'énergie peut être atténuée/réduite : dans ce cas, des opérations de migration de microservices peuvent être effectuées pour réduire la charge matérielle. Dans le cas ii. où le dispositif source D est déterminé comme non saturé, les actions mises en œuvre pour diminuer la consommation peuvent comprendre une réduction de la charge d'un appareil à un taux donné (par exemple 80% ou moins), ce qui atténue la consommation d'énergie supplémentaire (par exemple, la diminution de consommation induite par une réduction de vitesse du ventilateur) Une ressource matérielle (22, 240, 260, 31, 310, 29) est considérée saturée (sur la base d'observations comportementales précédentes de l'algorithme) lorsque l'une des ressources matérielles est chargée au-delà d’un seuil de charge, qui peut être fixé à 85%. De plus, une consommation électrique supplémentaire fixée à un taux donné, par exemple de 20%, peut être appliquée à un dispositif saturé pour mettre en évidence la saturation. Si une condition de saturation de dispositif est détecté, le procédé de planification peut sélectionner un ou plusieurs microservices du programme, par exemple le ou les microservices les plus lourds du programme (en terme de charge), et exécuter une recherche de dispositifs candidats D’ répondant aux exigences de charge pour héberger et traiter les microservices sélectionnés. S'il n'y a pas de dispositifs candidats disponibles, une nouvelle recherche de dispositif peut être mise en œuvre itérativement en utilisant les exigences d’autres microservices du programme jusqu’à ce qu’un ou des dispositifs candidats soit trouvés. Les microservices sélectionnés peuvent être alors migrés vers les dispositifs candidats sélectionnés. Dans des modes de réalisation de l’invention, le procédé de planification de traitement de programme exploite notamment la qualité de service QoS des microservices. Le procédé de planification de traitement peut calculer la valeur de la qualité de service QoS des microservices proportionnellement aux ressources matérielles (hardware) requises ou obtenues. Le QoS d’un programme est déterminé proportionnellement au QoS de chaque microservice qui le compose. Ainsi pour un microservice M exécuté dans un dispositif D, une Qualité de Service optimale (QoS=100%) est définie en spécifiant: - les ressources dont le microservice M a besoin pour s’exécuter en termes de fréquence de CPU 22 en GHz, la consommation de RAM 260 in MB, le taux de transfert réseau 310 en MB/s et le taux de transfert de disque dur 240 en MB/s, et - une valeur d’impact dont chacun des paramètres de qualité a besoin. La valeur d’impact peut être comprise entre 0 et 1 et la somme de toutes les valeurs d’impact peut être égale à 1. Il existe des différences entre les ressources M nécessaires à l’exécution d’un microservice et les ressources obtenues du dispositif D. Chaque différence entre les ressources demandées par M et les ressources obtenues de D, pour chaque paramètre de qualité de service, peuvent être exprimées en pourcentage (entre 0 et 100). Les paramètres de qualité de service correspondent aux paramètres de capacité de l’univers U. La suite de la description sera faite en référence à un espace U comprenant 4 dimensions pour faciliter la compréhension de l’invention, correspondant aux quatre paramètres de capacités : paramètre de fréquence CPU 22, paramètre de RAM 260, paramètre de taux de transfert de réseau 310, et paramètre de taux de transfert de disque dur 240. Ces quatre paramètres de capacité seront désignés Cependant l’homme du métier comprendra aisément que d’autres paramètres de capacité relatives à des composants matériels du dispositif 10 peuvent être ajoutés, comme un paramètre de capacité de batterie, pour un espace U avec plus de 4 dimensions. Les différences entre les ressources demandées et celle obtenue pour chaque paramètres de qualité de service peuvent comprendre au moins : - La différence D C pour le paramètre de fréquence CPU 22, - La différence D R pour le paramètre de RAM 260, - La différence D N pour le paramètre de taux de transfert de réseau 310, et - La différence D H pour le paramètre de taux de transfert de disque dur 240. Dans la première approche dite « indépendante », une QoS d’un microservice QoS M est définie par la somme pondérée des différences relatives aux différents paramètres de qualité de service, le poids I i associé à chaque paramètre de qualité de service étant une valeur inférieure à 1, la somme des poids étant égale à 1 selon l’équation 11: La QoS d’un programme (application) QoS prog est définie par la QoS déterminée pour chacun des N microservices QoS i qui compose le programme, sur la base de la valeur d’impact que l’utilisateur définit : Dans la deuxième approche dite “dépendante”, la qualité de service d’un microservice M est limitée par la ressource qui a obtenu le moins de quantité de ressources par rapport aux autres, en prenant en compte le paramètre d’impact I C , I N , I R et I H spécifié par l’utilisateur pour chaque paramètre de qualité de service. La QoS d’un microservice QoS M est alors définie par: La QoS d’un programme PROG composé d’un ensemble de microservices Mi, l’ensemble de microservices étant noté M = [M0...Mn], est limitée par le microservice ayant la plus petite valeur de QoS, soit : (5) Le procédé de planification peut évaluer le QoS des applications et microservices à un taux spécifique prédéfini. La consommation de puissance d’un dispositif est basée sur le niveau d’utilisation de chaque composant du dispositif. La consommation de puissance d’un dispositif est définie par une fonction qui relie la consommation de puissance exprimée en Watts à la fréquence CPU 22 utilisée, au taux de transfert courant du disque dur 240 et au taux de transfert 310 courant du réseau (la consommation de RAM 260 est indépendante de sa charge). Les modèles suivants peuvent par exemple et sans limitation être utilisés pour mesurer l’énergie des dispositifs et des microservices: Afin de trouver la quantité d’énergie consommée à un temps par le CPU 22 d’un dispositif D, en fonction de sa charge, l’équation (6) suivante peut être utilisée : (6) La formule (6) fournit la consommation d’énergie en Joules (watts*secondes) du processeur de D D à partir de sa capacitance commutée par le cycle d’horloge (C D ), de sa tension (V D ), de la fréquence de processeur F D (cycles par seconde) et du facteur T D , en secondes. . L’énergie consommée par un microservice M, en termes de CPU de D peut être déterminée en interprétant l’équation (5) proportionnellement à la charge que M génère dans ce composant CPU de D. Ainsi, à partir de la “capacitance” C D de ce processeur, la tension V D , du facteur T D et de la fréquence totale F D à un instant donné, si le microservice M le charge à X%, l'énergie consommée pour le processus M sera calculée dans la même proportion que la charge mentionnée selon l’équation (7): (7) Pour déterminer l'énergie consommée par M sur le processeur d'un périphérique externe (pour savoir combien d'énergie le microservice va consommer avant de le migrer), l'équation (7) peut être utilisé pour déduire le nombre d'instructions de programme de M en tenant compte du nombre d'instructions par unité de temps que le processeur peut exécuter. Ainsi, si le processeur de D est capable d'exécuter les instructions du programme à dans le temps T1 et si M consomme % de la capacité de ce composant au temps T1, alors M exécute également les instructions du programme de manière proportionnelle : (8) En considérant un autre dispositif D2, il est possible de déduire le pourcentage de sa charge CPU si M était exécuté dans ce dispositif, en fonction du nombre d’instructions dans le temps T1 que D2 peut exécuter : (9) L’énergie que le processeur de D2 consommerait pour traiter M peut être calculée selon l’équation (6), en tenant compte des proportions précitées: (10) L’équation (10) permet d’obtenir à partir de D, une estimation de l’énergie que le CPU de D2 consommerait s’il exécutait M. Ainsi, dans un processus de négociation, cette consommation peut être utilisée avant une opération de migration ou de duplication. Comme la charge de la RAM entraîne généralement des augmentations relativement faibles de la consommation globale d'énergie, dans un mode de réalisation, la consommation de RAM est estimée de manière à éviter les situations de surcharge qui peuvent avoir un impact sur les performances du programme et une augmentation de la charge/consommation du disque. Dans un mode de réalisation, la consommation d'énergie de la RAM 260 d’un dispositif 10 peut être estimée comme une valeur de puissance constante multipliée par le temps d’analyse T en secondes (watt *s) selon l’équation (11): (11) En variante, des modèles mathématiques basés sur la quantité d'opérations de lecture et d'écriture que la RAM effectue dans un temps donné peuvent être utilisés. La consommation d'énergie de la RAM peut par exemple être estimée à partir du nombre d'accès et d'opérations que la RAM effectue dans le contexte de l'exécution d'un programme. Pour modéliser la consommation d’énergie des interfaces réseau 31 d’un dispositif et des unités de disque dur 240, leur hétérogénéité est prise en compte. Dans le cas des interfaces réseau 31, différents types de connexions (par exemple Ethernet, WIFI, 2G, 3G, 4G, 5G, etc.) peuvent être pris en compte. Pour chaque type de connexion, il existe une relation entre la consommation d'énergie et la vitesse de transmission à laquelle la connexion fonctionne. Similairement, la consommation d'énergie produite par le disque dur 240 est liée à son taux de transfert. La consommation d’une carte réseau 310 et/ou d’un disque dur 240, lorsqu'ils sont dans leur état actif (lecture / écriture) et leur état inactif peut être prédéterminée. Pour chacun des deux composants carte réseau NIC 310 et disque dur HDD 240 d’un dispositif, la consommation électrique du composant à un instant T peut être liée au taux de transfert du composant. Le taux de transfert d’une carte réseau 310 ou d’un disque dur 240 est la moyenne des états d'émission/réception et de l’état inactif (idle) du composant considéré (310 ou 240) à l’instant T. Pour un dispositif D donné, la consommation électrique en watts lorsque le composant NIC 310 (respectivement HDD 240) est dans un état actif est notée W u et lorsque son composant NIC 310 (respectivement HDD 240) est dans un état inactif est notée W i . La carte réseau NIC 310 ou le disque dur HDD 240 d’un dispositif (D) seront communément désignés par la notation « ND » ci-après, ND désignant ainsi soit la carte réseau NIC 310 soit le disque dur HDD 240. Pour un taux de transfert courant L, W u est multiplié par L par rapport à sa capacité de transfert maximale L MAX . Ce résultat est ensuite ajouté à la consommation correspondant à l’état inactif. Pour cela, Wi est multiplié par le complément de charge de ND par rapport à L MAX , c’est à dire L MAX -L. Pour obtenir la consommation d’énergie en Joules (watts*s), T est pris en compte (T en secondes). Ainsi, la consommation d'énergie de la carte réseau NIC 310 ou de disque dur HDD 240 est donnée par l’équation (12), avec ND désignant la carte réseau NIC 310 ou le disque dur HDD 240 : (12) Afin de modéliser la consommation d’énergie d’un microservice M en fonction de sa charge générée dans la carte réseau NIC 310 ou le disque dur HDD 240 d’un dispositif (D) (tous deux désignés communément par la notation « ND »)), l’équation (12) peut être utilisée en ne tenant compte que de la charge générée par M, soit L M , et en considérant l’état de repos que M génère proportionnellement de la même manière que L M pour la charge actuelle L du ND, ce qui donne l’équation (13) suivante: (13) Pour modéliser la consommation d’énergie qu'un microservice M produirait en fonction de sa charge générée dans un autre dispositif, l’équation (13) s’écrit, en considérant le composant ND de D1, sa capacité de transfert maximale et sa charge actuelle : (14) Le procédé de planification de traitement de programme permet de mesurer la consommation d’énergie dans une plage de temps. Cette analyse peut être effectuée pour chaque dispositif ou pour chaque scénario entier (tous les dispositifs). En réponse à l’exécution du procédé de planification, des métriques relatives aux performances du procédé de planification peuvent être estimées telles que: (1)le Temps d’exécution, (2) le Nombre d’opérations effectuées, (3) les données transmises par les mouvements/les duplications sur le dispositif ou dans le réseau, (4) l’énergie utilisée pour des mouvements/duplications sur des dispositifs ou sur le réseau, et (5) la charge par dispositif et la charge globale des dispositifs. Un affichage de telles métriques peut être en outre généré sur une interface graphique destinée à un opérateur du système 100. La illustre le procédé de planification de traitement de programme selon certains modes de réalisation À l’étape 500, une demande de traitement d’au moins un programme à un instant donné T de la part d’un dispositif requérant (D) de l’ensemble de dispositifs 10 du réseau 2. Le programme comprend un ensemble de microservices associés. Pour chaque microservice associé au programme (bloc 502), des valeurs cibles pour un ensemble de paramètres de qualité de service définis pour le microservice et les valeurs obtenues pour l’ensemble de paramètres de qualité de service par le dispositif requérant (D) sont extraites à l’étape 504. Pour chaque paramètre de qualité de service (bloc 505), la différence entre la valeur cible et la valeur obtenue du paramètre de qualité de service pour le traitement du microservice par le dispositif requérant D est déterminée, à l’étape 506, ce qui fournit une différence relative au paramètre de qualité de service. À l’étape 507, pour chaque microservice, un indicateur de qualité de service élémentaire associé au microservice (encore appelé indicateur de qualité de service de microservice) est calculé à partir des différences relatives à chaque paramètre de qualité de service. À l’étape 508, l'indicateur de qualité de service globale (encore appelé indicateur de qualité de service de programme est calculé à partir des indicateurs de qualités de services élémentaires déterminées pour chaque microservice du programme. À l’étape 510, au moins un dispositif cible D’ parmi ladite pluralité de dispositifs est sélectionné, en mettant en œuvre une recherche, dans le réseau, en fonction de l’indicateur de qualité de service de programme et d’une information de consommation d’énergie déterminée pour chaque dispositif à l’instant T. À l’étape 511, une opération de microservices (opération relative au traitement d’une partie des microservices du programme) est exécutée pour un ou plusieurs microservices sélectionnés du programme PROG dans un dispositif du réseau en fonction de l’indicateur de qualité de service de programme calculé. Par exemple, l’opération de microservices peut être un arrêt de programme. Dans un tel mode de réalisation, l’arrêt du programme peut être mis en œuvre directement après l’étape 508 et dans ce cas l’étape 510 n’est pas effectuée. En variante, l’opération de microservices peut être un déplacement ou une duplication des microservices du programme PROG sur le dispositif D’ sélectionné à l’étape 510 pour une exécution du programme par le dispositif D’. Le procédé de traitement de programme, selon les modes de réalisation de l’invention, permet ainsi d’exécuter un programme sur un ou plusieurs dispositifs 10. Par exemple, si un des dispositifs 10 consomme beaucoup d'énergie, un microservice du dispositif 10 peut être déplacé vers un autre dispositif, si les coûts de puissance de traitement sont meilleurs. Dans un autre exemple, si un microservice consomme beaucoup parce que de nombreux autres microservices en consomment les données, le dispositif 10 peut également chercher à dupliquer le microservice. Dans un autre exemple d’application de l’invention, si un microservice a une restriction de non-mouvement de sorte que le microservice ne peut pas être déplacé, le microservice peut être dupliqué sur un autre dispositif D’ (cas d’un microservice GUI par exemple). Avantageusement, le procédé de planification de traitement de programme peut être lui-même implémenté sous la forme d’un microservice. L’homme du métier comprendra que le systèmes ou des sous-système selon les modes de réalisation de l’invention peuvent être mis en œuvre de diverses manières par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d’instructions de programme d’ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de programme d’ordinateur peuvent également être stockées dans un support lisible par ordinateur. Par ailleurs, l'invention n'est pas limitée aux modes de réalisation décrits ci-avant à titre d’exemple non limitatif. Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. En particulier, l’homme du métier comprendra que l’invention n’est pas limitée aux exemples d’architectures de superposition (Chord, Maan) cités à titre d’illustration.   1. Procédé de contrôle de traitement de programmes mis en œuvre dans un système informatique comprenant une pluralité de dispositifs informatiques connectés au moyen d’au moins un réseau informatique (2), chaque dispositif ayant une pluralité de ressources matérielles, chaque programme étant configuré sous la forme d’un ensemble de microservices, chaque dispositif étant apte à traiter au moins un programme, ladite pluralité de dispositifs informatiques étant représentée sous la forme d’un graphe comprenant des nœuds, deux nœuds étant reliés par un lien, un nœud représentant un dispositif informatique, un lien reliant de nœuds représentant la connexion entre les deux dispositifs informatiques représentés par les nœuds, caractérisé en ce que les nœuds sont logiquement indexés dans une structure multidimensionnelle selon les ressources d’un espace muldimensionnel, caractérisé en que procédé comprenant les étapes consistant à : - Recevoir (500) une demande de traitement d’au moins une partie des microservices d’un programme d’un dispositif source (D) dudit ensemble de dispositifs, émise dans l'espace multidimensionnel; Pour chaque paramètre de qualité de service parmi un ensemble de paramètres de qualité de service représentant des paramètres de capacité de ressources matérielles du dispositif source, déterminer la différence entre la valeur cible et la valeur obtenue du paramètre de qualité de service pour le traitement du microservice par le dispositif requérant, ce qui fournit une différence relative au paramètre de qualité de service (506), les paramètres de qualité de service comprenant au moins la fréquence du processeur central (22) du dispositif source, la capacité de la mémoire RAM (260) du dispositif source, le taux de transfert de l’interface réseau (31) du dispositif source, et le taux de transfert du disque dur (240) du dispositif; Calculer (507) pour chaque microservice, un indicateur de qualité de service élémentaire associé au microservice, à partir des différences relatives à chaque paramètre de qualité de service ; et Calculer un indicateur de qualité de service de programme à partir des indicateurs de qualités de services élémentaires déterminées pour chaque microservice du programme; Effectuer (511) une opération de traitement relative au traitement d’au moins une partie des microservices du programme dans un dispositif du réseau en fonction des indicateurs de qualités de service calculés. 2. Procédé selon la revendication 1, caractérisé en ce que ladite opération de traitement est un arrêt de ladite au moins une partie des microservices du programme dans le dispositif source. 3. Procédé selon la revendication 1, caractérisé en ce qu’il comprend en outre l’étape suivante : - Sélectionner au moins un dispositif candidat cible parmi ladite pluralité de dispositifs en fonction de l’indicateur de qualité de service de programme et d’une information de consommation d’énergie déterminée pour chaque dispositif à l’instant T, en utilisant ledit graphe, et en ce que ladite opération de traitement consiste à déplacer ou dupliquer ladite au moins une partie des microservices dans ledit au moins un dispositif candidat sélectionné pour une exécution du programme par ledit au moins un dispositif sélectionné. 4. Procédé selon la revendication 3, caractérisé en ce que dans l’étape de sélection, le dispositif source est apte à rechercher un nœud voisin logiquement proche du nœud représentant ledit dispositif source dans ledit graphe et pour mettre en œuvre des échanges de négociations avec ledit nœud voisin. 5. Procédé selon l’une des revendications 1 à 4, caractérisé en ce qu’il comprend une étape consistant à gérer les dispositifs du réseau en utilisant ledit graphe dans laquelle un nœud du graphe est apte à être ajouté ou supprimé dynamiquement de l'espace multidimensionnel. 6. Procédé selon l’une des revendications précédentes, caractérisé en ce qu’un indicateur de qualité de service élémentaire associé à un microservice est calculé en effectuant la somme pondérée des différences relatives à chaque paramètre de qualité de service en utilisant des poids élémentaires associés à chaque paramètre de qualité de service. 7. Procédé selon la revendication 6, caractérisé en ce que la somme des poids élémentaires est égale à 1. 8. Procédé selon l’une des revendications, caractérisé en ce qu’un indicateur de qualité de service de programme est calculé en effectuant la somme pondérée des qualités de services élémentaires déterminées pour les microservices du programme en utilisant des poids globaux associés à chaque microservice. 9. Procédé selon la revendication 8, caractérisé en ce que la somme des poids globaux est égale à 1. 10. Procédé selon l’une des revendications 1 à 5, caractérisé en ce que l’indicateur de qualité de service élémentaire calculé pour un microservice est la valeur minimale entre les différences relatives à chaque paramètre de qualité de service, chacune pondérée par un indicateur d’impact. 11. Procédé selon la revendication 10, caractérisé en ce que l’indicateur de qualité de service de programme est la plus petite valeur parmi les indicateurs de qualité de service élémentaires calculées pour les microservices du programme. 12. Procédé selon l’une des revendications précédentes, caractérisé en ce qu’il comprend en outre une étape de détermination de l’information de consommation d’énergie de chaque dispositif de l’ensemble de dispositifs, ladite étape de détermination comprenant : - déterminer la consommation d’énergie du processeur central CPU (22) du dispositif ; - déterminer la consommation d’énergie de la RAM (260) du dispositif ; - déterminer la consommation d’énergie des carte d’interface réseau (310) du dispositif et du disque dur (240) du dispositif ; l’information de consommation d’énergie du dispositif étant calculée à partir de la consommation d’énergie du processeur central CPU (22) du dispositif, de la consommation d’énergie de la RAM (260), de la consommation d’énergie des cartes d’interface réseau (310) et de la consommation du disque dur (240) du dispositif. 13. Procédé selon la revendication 12, caractérisé en ce que la consommation d’énergie E du processeur central CPU (22) du dispositif pendant un temps est déterminée selon l’équation : Avec désignant la capacitance du processeur central, désignant la tension du processeur central, désignant la fréquence du processeur central. 14. Procédé selon l’une des revendications 12 et 13, caractérisé en ce que la consommation d’énergie E générée par un microservice donné sur la carte d’interface réseau (310) ou le disque dur (240) du dispositif est déterminée, selon l’équation : , avec Wu désignant la consommation en Watts du dispositif lorsque la carte d’interface réseau du dispositif ou le disque dur (240) du dispositif est dans un état actif, Wi désignant lorsque la carte d’interface réseau du dispositif ou le disque dur (240) du dispositif est dans un état inactif, Li désignant le taux de transfert d’un microservice, L MAX désignant le taux de transfert maximal du microservice et L désignant la charge courante du dispositif à l’instant T. 15. Procédé selon l’une des revendications précédentes, caractérisé en ce que le procédé est lui-même exécuté sous la forme d’un microservice. 16. Système de contrôle de traitement de programmes mis en œuvre dans un système informatique comprenant une pluralité de dispositifs informatiques connectés au moyen d’au moins un réseau informatique (2), chaque dispositif ayant une pluralité de ressources matérielles, chaque programme étant configuré sous la forme d’un ensemble de microservices, chaque dispositif étant apte à traiter au moins un programme, ladite pluralité de dispositifs informatiques étant représentée sous la forme d’un graphe comprenant des nœuds, deux nœuds étant reliés par un lien, un nœud représentant un dispositif informatique, un lien reliant de nœuds représentant la connexion entre les deux dispositifs informatiques représentés par les nœuds, caractérisé en ce que les nœuds sont logiquement indexés dans une structure multidimensionnelle selon les ressources d’un espace muldimensionnel, caractérisé en que le système est configuré pour : - Recevoir une demande de traitement d’au moins une partie des microservices d’un programme d’un dispositif source (D) dudit ensemble de dispositifs, émise dans l'espace multidimensionnel; Pour chaque paramètre de qualité de service parmi un ensemble de paramètres de qualité de service représentant des paramètres de capacité de ressources matérielles du dispositif source, déterminer la différence entre la valeur cible et la valeur obtenue du paramètre de qualité de service pour le traitement du microservice par le dispositif requérant, ce qui fournit une différence relative au paramètre de qualité de service, les paramètres de qualité de service comprenant au moins la fréquence du processeur central (22) du dispositif source, la capacité de la mémoire RAM (260) du dispositif source, le taux de transfert de l’interface réseau (31) du dispositif source, et le taux de transfert du disque dur (240) du dispositif; Calculer pour chaque microservice, un indicateur de qualité de service élémentaire associé au microservice, à partir des différences relatives à chaque paramètre de qualité de service ; et Calculer un indicateur de qualité de service de programme à partir des indicateurs de qualités de services élémentaires déterminées pour chaque microservice du programme ; Effectuer une opération de traitement relative au traitement d’au moins une partie des microservices du programme dans un dispositif du réseau.