Brevet FR3160532A1 — publié le 20250926

L’invention concerne un procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique d’un système informatique (SI), ledit système informatique (SI) comprenant une unité d’exécution et au moins une charge logicielle apte à être exécutée à partir de ladite unité d’exécution, ledit procédé comprenant une étape de réception de données de fonctionnement (Data) du système informatique (SI), lesdites données de fonctionnement comprenant au moins un premier ensemble (M i ) de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle et une étape de calcul de la valeur de l’indicateur écologique à partir d’au moins un paramètre du premier ensemble (M i ) de paramètres. Figure pour l’abrégé : Fig.1 Procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique La présente invention se rapporte au domaine des systèmes informatiques et plus particulièrement à l’optimisation des consommations énergétiques et/ou des émissions carbones associées à ces systèmes. Art Antérieur Avec le développement du numérique, il existe aujourd’hui une pluralité de grands centres de traitement des données, également appelés « data center », répartis dans le monde. Ces centres de traitement utilisent des systèmes informatiques complexes comprenant des équipements qu’il faut sans cesse alimenter en électricité à la fois pour leur fonctionnement mais également pour leur refroidissement (climatisation) en vue de préserver l’intégrité des circuits électroniques utilisés. L’optimisation de la consommation énergétique de ces systèmes informatiques complexe est donc un enjeu crucial dans un objectif de réduction globale de l’empreinte carbone d’origine humaine. L’empreinte carbone est répartie habituellement en contribution opérationnelle et en contribution de construction (également appelée « embodied »). La contribution opérationnelle est la contribution directement induite par la consommation d’énergie électrique. Pour la calculer, il est également nécessaire de tenir compte du rendement énergétique de chaque « data center » et du facteur d’émission carbone du fournisseur d’énergie qui alimente chaque « data center », ce qui va permettre d’estimer les émissions carbones induites par la production de l’électricité. La contribution de construction consiste à évaluer la part du carbone émis lors de la construction et le recyclage d’un équipement au prorata de la part d’utilisation de cet équipement sur sa durée de vie opérationnelle. L’évaluation de la contribution opérationnelle d’un équipement peut se faire, aujourd’hui, au moyen de diverses méthodes d’estimation d’empreintes énergétiques et carbone basées sur des données de benchmarks de processeurs, telles que SPEC2008, disponibles à partir du lien https://www.spec.org/power_ssj2008/. Des estimateurs de calcul d’empreinte existent parmi lesquels on distingue : – des rapporteurs d’empreinte de fournisseurs de « cloud » tels que GCP®, Azure®, AWS®, OVH® ; – une application open-source disponible à l’adresse cloudCarbonFootprint.com, qui modélise le carbone et l’énergie consommée des instances de calcul des principaux fournisseurs de « cloud ». Cette modélisation est basée sur la méthodologie « Cloud Jewels » publiée par Etsy engineering ; – des modèles et APIs d’estimation basées sur les résultats des recherches du groupe de travail Boavizta (voir notamment le lien boavizta.org). Ce groupe de travail produit des ressources expertisées et actualisées sous licences libres. Ces estimateurs de l’état de l’art de focalisent à fournir une estimation de la consommation énergétique de serveurs physiques ou d’instances virtualisées. Leur évaluation est partielle car ne prenant pas en compte l’ensemble des composants matériels utilisés dans un « data center » ou les volumes de communications échangés. De plus, l’évaluation de la consommation est réalisée via des calculs a posteriori, par exemple en extrayant des charges et des durées d’usage depuis des factures. Enfin, l’évaluation de la consommation repose sur des méthodes de calcul non documentées qui rendent difficile une comparaison des résultats entre eux. Par ailleurs, il n’existe pas de technique portant sur une évaluation énergétique ou carbone dédiée à la partie logicielle. Ceci est très problématique car une infrastructure est créée et utilisée uniquement pour exécuter des logiciels. Ce sont donc les logiciels qui consomment l’énergie et génèrent du carbone au travers de l’infrastructure. Il existe donc un besoin de proposer une méthode permettant d’évaluer à la fois plus finement la consommation énergétique et carbone d’un système informatique, tout en intégrant la partie logicielle afin de pouvoir optimiser globalement les émissions carbones. Un objet de l’invention concerne un procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique d’un système informatique, ledit système informatique comprenant une unité d’exécution et au moins une charge logicielle apte à être exécutée à partir de ladite unité d’exécution. Le procédé comprend une étape de réception de données de fonctionnement du système informatique, lesdites données de fonctionnement comprenant au moins un premier ensemble de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle et une étape de calcul de la valeur de l’indicateur écologique à partir d’au moins un paramètre du premier ensemble de paramètres. L’invention permet de donner une estimation énergie/carbone pour une charge logicielle appartenant à un système d’informatique. Cette estimation est basée sur des métriques spécifiques à la charge logicielle, échantillonnées dynamiquement par l’infrastructure logicielle à des périodes variables. Dans une variante de réalisation, les données de fonctionnement du système informatique comprennent un deuxième ensemble de paramètres associés à un fonctionnement global de l’unité d’exécution et un troisième ensemble de paramètres associés au fonctionnement global du système informatique. Dans une variante de réalisation, l’indicateur écologique est choisi dans un ensemble d’indicateurs écologiques, ledit ensemble d’indicateurs écologiques comprenant au moins : une énergie consommée par la charge logicielle, une contribution opérationnelle de la charge logicielle, une contribution de construction de la charge logicielle. Dans une variante de réalisation, l’énergie consommée est fonction d’au moins un paramètre du premier ensemble de paramètres et d’au moins un paramètre du deuxième ensemble de paramètres. Dans une variante de réalisation, la contribution opérationnelle est fonction de l’énergie consommée et d’au moins un paramètre du troisième ensemble de paramètres. Dans une variante de réalisation, la contribution de construction est fonction d’au moins un paramètre du premier ensemble de paramètres et d’au moins un paramètre du deuxième ensemble de paramètres. Dans une variante de réalisation, l'énergie consommée est déterminée selon l’équation : , avec une puissance CPU, une puissance mémoire, une puissance de stockage ; une durée de référence, une énergie consommée par des accès entrée/sortie. Dans une variante de réalisation, la contribution opérationnelle est déterminée selon l’équation : avec un inverse du rendement énergétique du système informatique ; un facteur de conversion puissance vers CO2. Dans une variante de réalisation, la contribution de construction est déterminée selon l’équation : avec une quantité des émissions totales dues à la construction du système informatique, un temps d’allocation de ressource Hardware au ressource Software du système informatique, une durée de vie du système informatique ; une part de ressource Hardware allouée à la ressource Software. Dans une variante de réalisation, le sous-système informatique comprend N charges logicielles exécutées à partir de ladite unité d’exécution dans différentes plages temporelles, ledit procédé comprenant une étape de détermination d’une valeur résiduelle de l’indicateur écologique ladite valeur résiduelle étant représentative d’une non-utilisation de ladite unité d’exécution au cours du temps. Dans une variante de réalisation, la valeur de l’indicateur écologique déterminée pour la charge logicielle est affichée dans un graphique de visualisation globale du fonctionnement de l’ensemble des charges logicielles du système informatique. Un autre objet de l’invention concerne un dispositif de traitement de données pour la détermination d’une valeur d’un indicateur écologique d’un système informatique, ledit système informatique comprenant une unité d’exécution et au moins une charge logicielle exécutée à partir de ladite unité d’exécution, ledit dispositif de traitement comprenant : un module de réception de données de fonctionnement du système informatique, lesdites données de fonctionnement comprenant au moins un premier ensemble de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle et un module de calcul de la valeur de l’indicateur écologique à partir d’au moins un paramètre du premier ensemble de paramètres. Un autre objet de l’invention concerne un système informatique comprenant une unité d’exécution et au moins une charge logicielle exécutée à partir de ladite unité d’exécution, ledit système informatique étant apte à transmettre des données de fonctionnement dudit système informatique, lesdites données de fonctionnement comprenant au moins un premier ensemble de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle , au moins un paramètre du premier ensemble étant apte à être traité pour calculer une valeur d’un indicateur écologique. Dans un mode de réalisation particulier, la charge logicielle est adaptée pour s’exécuter au sein d’une autre charge logicielle. Un autre objet de l’invention concerne un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de traitement pour la détermination d’une valeur d’un indicateur écologique selon le procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique d’un système informatique, lorsque ledit programme est exécuté par un processeur. Un autre objet de l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution d’un procédé d’aide à la décision selon le procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique d’un système informatique, lorsque ledit programme est exécuté par un processeur. Description des figures D’autres caractéristiques et avantages de l’invention apparaîtront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés dans lesquels : La FIG. 1 illustre une infrastructure informatique comprenant un système informatique et un dispositif de traitement de données, selon un premier mode de réalisation de l’invention ; La FIG. 2 illustre un premier mode de réalisation du système informatique de la FIG. 1 ; La FIG. 3 illustre un second mode de réalisation du système informatique de la FIG. 1 ; La FIG. 4 illustre un troisième mode de réalisation du système informatique de la FIG. 1 ; La FIG. 5 illustre une infrastructure informatique comprenant un dispositif de traitement de données, selon un second mode de réalisation de l’invention ; La FIG. 6 illustre une infrastructure informatique comprenant un dispositif de traitement de données, selon un troisième mode de réalisation de l’invention ; La FIG. 7 illustre une visualisation globale des données issues du dispositif de traitement de données des figures 1 à 6, selon un premier mode de visualisation ; La FIG. 8 illustre une visualisation globale des données issues du dispositif de traitement de données des figures 1 à 6, selon un second mode de visualisation ; La FIG. 9 illustre une visualisation globale des données issues du dispositif de traitement de données des figures 1 à 6, selon un troisième mode de visualisation ; La FIG. 10 illustre un cycle d’optimisation de performance écologique pouvant être mise en œuvre par le dispositif de traitement de données des figures 1 à 6 ; La FIG. 11 illustre une méthode d’estimation d’impact via des simulations effectuées par le dispositif de traitement de données des figures 1 à 6 ; La FIG. 12 illustre un exemple de plan de réduction simulé selon la méthode de la FIG. 11 . Description de modes de réalisation La FIG. 1 illustre une infrastructure informatique INF selon un premier mode de réalisation de l’invention comprenant un système informatique SI et un dispositif de traitement de données T. Le système informatique SI est un système de « processing » qui permet à la fois de communiquer en entrée et en sortie vers l’extérieur et également de disposer de moyens de calcul et de capacité de stockage pour réaliser différents types de traitements logiciels. La définition d’un tel système informatique SI est donc relativement large et englobe tout système comportant un ensemble de serveurs ou d’unités de calcul qui exécute un logiciel. Cela peut être : – un système « on-premise », c’est-à-dire sur site, exécutant des applications ; – un IaaS (pour « Infrastructure as a Service »), dont l’objectif est de fournir des machines virtuelles ou instances s’exécutant au-dessus de serveurs (de type serveur « bare metal »), chacune de ces machines virtuelles étant une charge logicielle sur le système. Dans ce cas précis, il existe un besoin pour le fournisseur de Iaas de maîtriser sa consommation énergétique ou émissions carbones. – les utilisateurs du IaaS qui vont déployer également des charges logicielles à l’intérieur de chacune des machines virtuelles ; – les utilisateurs du IaaS qui exécutent des systèmes d’exécution de conteneurs (par exemple à l’aide du logiciel Kubernetes®). Dans ce cadre, les charges logicielles sont à la fois les conteneurs mais également les processus intégrés de gestion du logiciel Kubernetes® ; – un service managé au-dessus du serveur. Au-delà d’un système composé de serveurs, le système informatique SI englobe tout système qui exécute un logiciel, tel que : – un ensemble d’applications sur un parc informatique d’entreprise ; – des ordinateurs de bureau ou portables ; – une flotte de téléphones mobiles ; – un système embarqué comme machine2machine ; – des bornes de téléphone mobile. Comme il est illustré sur les figures 2 à 4, le système informatique SI comprend : – une unité d’exécution UE ; – au moins une charge logicielle. L’unité d’exécution UE est, par exemple, composé d’une pluralité de processeurs CPUs (pour « Central Processing Unit », en anglais). En variante, l’unité UE comprend un périphérique de calcul spécifique tel qu’un ensemble de GPUs (pour « Graphics Processing Unit ») pour le calcul flottant, nécessaire à l’intelligence artificielle. L’unité d’exécution UE peut également avoir des unités de calcul spécifiques soit par des cartes spécialisées ou des coprocesseurs internes disponibles. Complémentairement à ces moyens de calcul, des disques vont permettre de stocker des données de façon permanente. Une ou plusieurs mémoires et des périphériques d’entrée-sortie vont permettre de réaliser du stockage de données temporaire ou résilient. La charge logicielle est associée au fonctionnement d’un logiciel présent dans le système informatique SI. Cette notion englobe également une partie de code s’exécutant à l’intérieur d’une application ou d’un processus, pour lequel le développeur peut avoir des mesures de performances d’énergie ou d’émission carbone associé. Il peut y en avoir plusieurs niveaux d’imbrication des charges logicielles, comme il est illustré aux figures 2 à 4. La FIG. 2 représente un système informatique SI comportant N charges logicielles SW i à SW N . Ces charges logicielles s’exécutent directement sur l’unité d’exécution UE. Cette FIG. 2 illustre le cas de plusieurs applications sur un même système. Elle illustre également le cas d’un ensemble de machines virtuelles permettant de visualiser le « hardware » au niveau logiciel, par exemple dans une structure composée de serveurs « bare metal ». La FIG. 3 décrit un système informatique SI dans lequel plusieurs charges logicielles SSW i à SSW N s’exécutent au sein d’une charge logicielle amont SW i à SW N . Il peut s’agir ainsi d’un ensemble d’applications ou N processus différents s’exécutant au-dessus d’une machine virtuelle ou de N processus s’exécutant au sein d’une même application. La FIG. 4 décrit un système informatique SI dans lequel plusieurs charges logicielles SSSW i à SSSW N s’exécutent au sein d’une autre charge logicielle SSW i à SSW N qui s’exécute elle-même au sein d’une charge logicielle amont SW i à SW N s’exécutant au final sur l’unité d’exécution UE. Cela peut être le cas de N flows d’activité au sein de plusieurs applications dans une machine virtuelle. Pour l’ensemble des modes de réalisation des figures 2 à 4, le système informatique SI est adapté pour transmettre des données de fonctionnement Data du système informatique au dispositif de traitement de données T. Ces données de fonctionnement comprennent un premier ensemble M i de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle. Le premier ensemble M i englobe différents types de paramètres associés à la charge logicielle i tels que : – un temps d’utilisation CPU pour l’exécution de la charge logicielle, noté T ci ; – une charge CPU pour l’exécution de la charge logicielle, notée L ci ; – un temps d’utilisation GPU pour l’exécution de la charge logicielle, noté T gi ; – une charge GPU pour l’exécution de la charge logicielle, notée L gi ; – une quantité de stockage utilisée pour l’exécution de la charge logicielle, notée S i ; – une quantité de données échangées durant le temps d’utilisation T ci . Les données de fonctionnement du système informatique comprennent également un deuxième ensemble R de paramètres associés à un fonctionnement global de l’unité d’exécution. Le deuxième ensemble R englobe différents types de paramètres tels que : – un nombre de threads, noté Nthr. Par « thread », on entend un flot d’exécution logiciel pour lequel il est alloué du temps d’exécution sur le processeur. – une puissance minimale consommée par thread (0% de charge), notée Pmin ; – une puissance maximale consommée par thread (100% de charge), notée Pmax. Les valeurs de Pmin et Pmax proviennent en général de benchmarks et sont donnés pour une microarchitecture donnée. – une taille de Ram (pour « Random Access Memory » en anglais) de l’instance en Bytes, notée Qm ; – un facteur de réplication des données, noté Rs, dû à l’architecture du système de stockage (par exemple une architecture RAID pour « Redundant Array of Independent Disks ») et aux autres réplicas éventuels ; – un nombre d’unités GPU ; noté Ng ; – une part de la ressource HW (pour « Hardware » en anglais) allouée au SW (pour « Software » en anglais), notée Sa. Pour les instances virtuelles, ce paramètre correspond à un nombre de vCPUs divisé par le nombre de vCPUs total maximum allouables sur le serveur. Par « vCPU », on entend une quote part d’un CPU physique affectée à une machine virtuelle ; – une durée de vie de l’installation en année, notée L ; – un nombre de disques dur de stockage ; noté Nhdd ; – un nombre de « drives » de stockage à mémoire non-volatile, noté Nssd ; – un nombre de sockets CPU, noté Nsock. Par « socket », on entend un connecteur utilisé pour interfacer un processeur avec une carte mère ; – une taille de Ram installée en Go, notée Qram. Les données de fonctionnement Data comprennent également un troisième ensemble DC de paramètres associés au fonctionnement global du système informatique. Le troisième ensemble DC comprend différents types de paramètres tels que : – l’inverse d’un rendement énergétique du système informatique, noté Pue pour (« Power usage effectiveness » en anglais). Ce paramètre permet de prendre en compte l’énergie électrique totale effectivement dédiée à l’exécution de la charge logicielle, telle que l’énergie pour un refroidissement, des convertisseurs, etc. Un Pue supérieur à 1 est donné en général pour un « data center » ou comme moyenne globale d’un « provider ». – un facteur de conversion puissance (kWh) vers CO2 d’un réseau électrique régional noté Fc, éventuellement corrigé pour les datacenters équipés de générateurs autonomes (souvent publié en Tonnes de CO2 / kWh). Comme il est illustré à la FIG. 1 , le dispositif de traitement de données T est adapté pour recevoir les données de fonctionnement Data du système informatique. A partir de ces données, ce dispositif de traitement T met en œuvre un procédé de traitement de données. Ce procédé de traitement comprend une étape de réception des données Data et une étape de calcul d’une valeur d’un indicateur écologique à partir d’au moins un paramètre du premier ensemble M i de paramètres. Par indicateur écologique, on entend ici un indicateur qui tient compte d’une consommation énergétique et/ou des émissions carbones. L’indicateur écologique appartient à un ensemble d’indicateurs écologiques comprenant au moins une énergie consommée E i par une charge logicielle SW i , SSW i , SSSW i , une contribution opérationnelle Cop i de la charge logicielle SW i ; SSW i ; SSSW i , une contribution de construction Cc i de la charge logicielle SW i ; SSW i ; SSSW i . L’énergie consommée E i par la charge logicielle est calculée en Joules ou en ou Wh. Elle est déterminée selon l’équation : . Le paramètre est associé à l’unité d’exécution UE. Il correspond à une puissance consommée par des CPUs physiques ou virtuels proprement dits, estimé à partir de valeurs minimales et maximales benchmarkées, au prorata du nombre de CPUs et du % de charge. La puissance CPU, pour un ensemble de « threads » Nthr (ou de vCpus) chargés à un taux moyen Lc, est calculée de la manière suivante : Avec comme il a déjà été précisé, au moins en partie : : une puissance minimale consommée par « thread » (0% de charge) ; : une puissance maximale consommée par « thread » (100% de charge) ; : une charge moyenne pour les « threads » considérés ; : un nombre de « threads ». Le même principe s’applique aux GPUs éventuels. En effet, la puissance d’un GPU est calculée de manière similaire à celle d’un CPU, à l’exception du fait que l’on considère l’ensemble de la carte GPU. Cette puissance est calculée de la manière suivante : Avec comme il a déjà été précisé, au moins en partie : : une puissance minimale consommée par GPU (0% de charge) ; : une puissance maximale consommée par GPU (100% de charge) ; : une charge moyenne pour les GPUs considérés ; : un nombre de GPUs. Le paramètre est associé à une mémoire. Il correspond à une puissance consommée ou dissipée par une mémoire RAM, estimée par multiplication de la taille RAM par une puissance unitaire. Dans le mode de réalisation de l’invention, la puissance consommée par la RAM est calculée à partir d’un coefficient de dissipation moyen selon l’équation : Avec comme il a déjà été précisé, au moins en partie : : une taille de RAM de l’instance (en Bytes) ; : un Coefficient de puissance RAM (W/Bytes) La valeur de est déduite de données des principaux constructeurs de mémoires DDR4 et DDR5. Théoriquement, une partie de la RAM est déjà incluse dans les coefficients de puissance et du CPU, ceux-ci étant dérivés de benchmarks. La correction apportée sur la valeur de prend en compte la configuration RAM de l’instance et du serveur ainsi que la configuration RAM des machines évaluées pour l’architecture CPU considérée. Le paramètre est associé à une puissance de stockage. Il correspond à une puissance consommée par un disque dur, estimée par multiplication de la taille de stockage par une puissance unitaire et un éventuel facteur de réplication. Un tel facteur est donné par un fournisseur du service informatique et un service de stockage associé à une instance. La puissance de stockage est calculée à partir d’un coefficient de dissipation moyen selon l’équation : Avec comme il a déjà été précisé, au moins en partie : : une taille du disque de stockage (en Bytes) ; : un coefficient de dissipation (W/Byte), dépendant de la technologie (disque rotatif ou SSD (pour « Solid State Drive ») ; : un facteur de réplication des données, dû à l’architecture du système de stockage (par exemple RAID) et autres réplicas éventuels. Le paramètre correspond à une durée de référence sur laquelle l’estimation est projetée, en tenant compte de mesures avec la charge logicielle considérée. Le paramètre est associé au réseau. Il correspond à l’énergie consommée par des accès entrée/sortie, estimée par multiplication d’une quantité de données échangées (en entrée et en sortie) sur la durée par énergie unitaire. L’estimation de cette contribution est déterminée par l’utilisation d’un coefficient de dissipation moyen pour des transferts entre « data centers » par réseaux à fibres optiques, selon l’équation : Avec, comme il a déjà été précisé, au moins en partie : : une quantité totale de données échangées sur la durée ; : un coefficient de dissipation (J/Byte) La contribution opérationnelle Cop i de la charge logicielle ou carbone opérationnel s’exprime en g, Kg ou Tonne de CO2 équivalent. Elle est toujours calculée pour un service consommateur d’électricité dans une région donnée, depuis une énergie (en Wh ou Joules) par une formule de type : Comme il a déjà été indiqué, le paramètre est l’énergie consommée E i par la charge logicielle i. De la même manière, le paramètre est l’inverse du rendement énergétique du système informatique. Enfin, le paramètre est le facteur de conversion puissance vers CO2. La contribution de construction Cc i est déterminée selon l’équation : Le paramètre est un temps d’allocation de ressource « Hardware » à la ressource « Software » du système informatique. Le paramètre est une durée de vie du système informatique. Le paramètre est une part de ressource « Hardware » allouée à la ressource « Software ». Le paramètre est une quantité des émissions totales dues à la construction du système informatique. Elle est évaluée en tonnes de CO2. Dans le cas où ce paramètre n’est pas fourni par le fabricant, elle est estimée en fonction des composants majeurs du système informatique selon l’équation : Le paramètre correspond au carbone des composants périphériques (alimentation, châssis, câblage, carte mère, cartes réseau, etc.). Cette valeur est de l’ordre de 1 tonne. Comme il a déjà été indiqué, le paramètre correspond au nombre de sockets CPU. Le paramètre correspond au nombre de disques durs de stockage. Le paramètre correspond au nombre de « drives » de stockage à mémoire non-volatile. Le paramètre correspond au nombre d’unités GPU. Le paramètre correspond à la taille de RAM installée. Ainsi, l'indicateur écologique, énergie consommée E i , contribution opérationnelle Cop i , ou contribution de construction Cc i , détaillé dans les calculs précédents peut s’inscrire sous la forme de fonctions f, g, h : Ces fonctions sont dépendantes : – du premier ensemble M i de paramètres dépendant de la charge logicielle i. Comme il a déjà été indiqué, ce premier ensemble comprend le paramètre T ci temps d’utilisation CPU, le paramètre L ci charge CPU, le paramètre de la durée de référence, le paramètre du temps d’allocation de ressource HW au ressource SW, un paramètre de taille de disque de stockage, un paramètre de quantité totale de données échangées sur la durée de référence T u ; – du deuxième ensemble R de paramètres dépendant de la ressource de calcul. Comme il a déjà été indiqué, ce deuxième ensemble comprend le paramètre Pmin de puissance minimale consommées par un « thread », le paramètre Pmax de puissance maximale consommée par un « thread », le paramètre Nthr de nombre de « thread », le paramètre Qm de taille de RAM, le paramètre Rs de facteur de réplication, le paramètre Ng de nombre d’unités GPU, un paramètre de quantité de stockage allouée, le paramètre L de durée de vie, le paramètre du nombre de disques durs de stockage, le paramètre du nombre de « drives » de stockage à mémoire non-volatile, le paramètre du nombre de sockets CPU, le paramètre de taille de RAM installée ; – du troisième ensemble DC de paramètres dépendant du système informatique. Comme il a déjà été indiqué, ce troisième ensemble comprend le paramètre associé au rendement énergétique du système informatique, le paramètre du facteur de conversion puissance vers CO2. Selon les composants matériels du système de traitement, d’autres contributions énergétiques peuvent être ajoutées (co-processeurs spécifiques, unité de traitement spécifique). Dans les exemples tels que présentés ici, il est particulièrement décrit les composants matériels de base. Cependant, la technique d’estimation objet de l’invention permet également de prendre en compte des compteurs matériels de consommation d’énergie s’ils sont disponibles pour certains composants du système. L’invention permet également à l’utilisateur d’estimer une valeur résiduelle de l’indicateur écologique résultant d’une ressource allouée mais inutilisée. Cette estimation comprend : Dans une étape 1 : un processus d’estimation est exécuté N fois avec les métriques de charges et calcule , , ; Dans une étape 2 : un processus d’estimation est exécuté N fois avec les métriques de ressource et calcule , , ; Dans une étape 3 : des empreintes résiduelles sont déduites par les sommes et différences suivantes : Dans lequel les éléments , , sont déterminés à partir de métriques M a cumulées d’utilisation de ressource. Ces métriques sont, par exemple : T ca : un temps total d’utilisation CPU ou temps d’allocation de ressources ; L ca : une charge CPU moyenne durant T ca (%) ; T ga : un temps total d’utilisation GPU ou temps d’allocation du/des GPU(s) ; L ga : une charge GPU moyenne durant T ga (%) ; S a : une quantité de stockage allouée (B) ; Qn a : une quantité de données échangées durant T ci (B). La FIG. 5 illustre l’infrastructure informatique INF selon un second mode de réalisation de l’invention dans lequel le dispositif de traitement de données est scindé en un premier module REC et un deuxième module CAL. Le premier module REC est adapté pour recevoir les données de fonctionnement Data(M i, R, DC) du système informatique (SI) et à les stocker dans une base de données (non représentée). Le premier module REC est en outre adapté pour communiquer avec un module d’interface utilisateur UI et le deuxième module CAL. Sur requête d’un utilisateur via le module d’interface utilisateur UI, le premier module REC sélectionne et transfère au deuxième module CAL les données de fonctionnement pertinentes pour cette requête. Ces données de fonctionnement sont ensuite traitées par le deuxième module CAL et les résultats de ce traitement sont transmis au module d’interface utilisateur UI via le premier module REC. A la réception de ces résultats, le module d’interface utilisateur est adapté pour les afficher. En variante, le premier module REC appelle le deuxième module CAL à chaque réception de données de fonctionnement et stocke le résultat de ce traitement dans la base de données. Sur requête d’un utilisateur via le module d’interface utilisateur UI, le module REC envoie les données précédemment calculées. Par exemple, ces résultats peuvent être présentés sous forme de « heat map » comprenant une pluralité de carrés, comme il est illustré à la FIG. 7 . Chaque carré peut être ainsi une unité de traitement, une machine virtuelle, un GPU, un processus, un flot logiciel, un « thread ». Chaque carré possède également une couleur. Cette couleur indique une importance par rapport aux autres en fonction de la métrique choisie, comme l’énergie consommée, le carbone d’usage émis, le carbone de construction émis, …. Il est possible d’interagir avec chaque carré par l’intermédiaire d’une sélection, par exemple une sélection via une souris. A chaque sélection, l’utilisateur va avoir des informations sur la partie du système impliquée. Il devient ainsi plus aisé de visualiser le système complet sous différents critères pour identifier des optimisations prioritaires à réaliser sur des unités de traitement, des machines virtuelles, des conteneurs, etc… Une autre déclinaison de cette représentation est de pouvoir réaliser des visualisations temporelles des éléments. Par exemple, chaque ligne représente un serveur, et chaque colonne une heure donnée ou un jour donné. L’avantage est de pouvoir visualiser les variations temporelles des métriques, sur un nombre important d’éléments. Une autre façon de pouvoir analyser de façon interactive est d’utiliser un graphique de type « tree map » comme décrit au lien https://www.data-to-viz.com/graph/treemap.html. Un tel graphique est représenté à la FIG. 8 . De la même manière, il est possible d’utiliser un graphique de type « radial tree map » comme décrit au lien https://www.data-to-viz.com/graph/sunburst.html.représenté à la FIG. 9 . Ces graphiques ont la particularité de pouvoir présenter des hiérarchies depuis un élément racine jusqu’à des éléments enfants, par exemple depuis un serveur, toutes les machines virtuelles, puis tous les conteneurs, puis tous les traitements logiciels ou par exemple depuis une organisation, des projets, des environnements d’exécution, des machines virtuelles, des conteneurs. L’avantage de ces représentations est de pouvoir faire varier la taille de chaque élément ainsi que sa couleur pour permettre d’identifier rapidement par exemple des machines virtuelles qui émettent le plus de carbone. Le graphique de type « radial tree map » est plus adapté aux petites hiérarchies pour un projet ou un serveur particulier. Le graphique de type « tree map » est plus adapté pour des systèmes plus grands. L’intérêt de cette visualisation est de pouvoir montrer plusieurs éléments de la hiérarchie afin d’identifier plus rapidement les éléments à optimiser. Par exemple, un serveur et les machines virtuelles en même temps, tout en adaptant leur taille respective en fonction de la métrique à afficher. La FIG. 6 illustre une infrastructure informatique comprenant un dispositif de traitement de données T selon un troisième mode de réalisation. Dans ce mode de réalisation, un module d’estimation SIM est adapté pour interroger le dispositif de traitement T via une pluralité d’APIs API 1, …, API j, …, API m . Par API (pour « Application Programming Interface »), on entend une interface logicielle qui permet de connecter un logiciel ou un service à un autre logiciel ou service afin d’échanger des données et des fonctionnalités. Ces APIs délivrent les estimations énergétique et carbones à la fois pour la partie matérielle et pour chaque activité logicielle. Elles prennent en entrée la description du modèle du système de traitement ainsi que des métriques de fonctionnement permettant le calcul pour les éléments matériel et logiciel. Afin de simplifier la description du modèle, ces APIs permettent d’utiliser des modèles prédéfinis et qualifiés et permettant une utilisation plus simple du module d’estimation SIM par les utilisateurs. Par exemple, il est possible de mettre à disposition des modèles prédéfinis des instances de fournisseur d’un cloud comme AWS, GCP, Azure, Scaleway ou Outscale. Il est alors possible d’indiquer le nom du type d’instance basée sur une nomenclature du fournisseur et des informations comme une taille mémoire, une taille de disque, ou un nombre de CPU, GPU si le type d’instance ne le définit pas implicitement. Ces APIs permettent ainsi de réaliser des estimations en temps-réel, à postériori à partir de données de fonctionnement passées, ou en simulation à partir de nouvelles configurations/données. Dès lors que des empreintes d’énergie/carbone peuvent être dynamiquement estimées, des analyses de contributions et des projections peuvent être réalisées pour différentes infrastructures, machines de calcul ou localisations en vue d’optimiser ces empreintes pour tout ou partie du matériel ou des charges logicielles considérées. Les décisions menant à une action d’optimisation peuvent être prises : - après analyse humaine, éventuellement assistée par algorithme - automatiquement, par des algorithmes divers, dont l’intelligence artificielle. A titre d’exemples d’optimisation, il est possible de citer : - un groupe de processus logiciels qui sous-utilise une ressource de calcul peut être réallouée à une ressource de capacité inférieure mais moins gourmand en énergie et/ou moins coûteux ; - un groupe de processus logiciels auquel est alloué un serveur situé dans un centre de données utilisant une source électrique très carbonée peut être redéployé sur un serveur similaire dans un autre centre approvisionné par une énergie électrique moins carbonée ; - l’optimisation d’un processus logiciel ; - le déplacement de processus logiciel sur des nouvelles générations de matériel. La FIG. 10 décrit une méthode itérative permettant d’optimiser soit la performance écologique (la consommation énergétique ou les émissions carbones du système). La base de cette méthode réside dans la capacité à connaître l’état de la performance, de la consommation énergétique ou des émissions carbones à l’aide de métriques compréhensibles par un ingénieur, par exemple, la charge du système, les joules énergétiques générés, les grammes de co2eq émis pour l’utilisation et la construction. A l’aide de ces métriques, on peut alors identifier des optimisations à réaliser, puis, après réalisation, l’itération est renouvelée pour améliorer en continu et de façon itérative le critère désiré. Pour que l’ensemble des optimisations puissent être envisagées, il faut pouvoir disposer d’une évaluation complète et détaillée de l’ensemble du système. Ce qui est rendu possible grâce au procédé de traitement mis en œuvre par le dispositif de traitement T. Il est ainsi possible de pouvoir estimer la performance écologique par simulation, ce qui permet d’estimer les impacts d’une optimisation avant de la réaliser. En réalisant plusieurs simulations, il est possible de prendre la meilleure optimisation à réaliser en vue d’atteindre l’objectif fixé en un temps réduit. La FIG. 11 décrit la manière dont est possible d'estimer l'impact pour une meilleure prise de décision via les simulations. Pour chaque plan d'action il est ainsi possible de réaliser une simulation du système qui va délivrer une projection d'impact très précise à la seconde, heure, jour, mois, ou années sur l'ensemble des composants du système qu'il soit matériel ou logiciel tout en permettant de cumuler les différents impacts globalement pour un système donné. Ainsi grâce à ces différentes simulations, il est possible de réaliser un choix sur l'optimisation du système à réaliser en priorité pour atteindre les objectifs soit de réduction carbone ou de consommation énergétique. Grâce à ces capacités de simulation, des plans de réduction permettent aux utilisateurs de disposer d’un moyen d’analyse très performant et de pouvoir estimer l’impact, tout en restant dans le domaine du possible. Par exemple, le plan de réduction suppose le déplacement de certains serveurs dans une autre région, le remplacement par des serveurs plus petits grâce à l’optimisation des activités logicielles sur ces serveurs, le déplacement des activités logicielles de développement sur des serveurs mutualisés ayant une émission carbone minimale. Il est également possible de réaliser une assistance, voir une automatisation complète du cycle d’optimisation à l’aide d’algorithmes dédiés, par exemple à l’aide d’intelligence artificielle. Ces algorithmes vont permettre de proposer des options d’optimisation d’infrastructure en fonction du critère à atteindre tel que la performance, le coût, le gain énergie ou le gain carbone. La FIG. 12 décrit un exemple de plan de réduction réalisé par simulation. Il est ainsi possible de lire que pour 2000 serveur générant 1121 Tonnes d’émission carbone (co2-eq) sur un an, en incluant le carbone d’usage et de construction, le plan de réduction simulé permet d’indiquer une réduction à 966 Tonnes d’émissions carbones (co2-eq) sur l’année. Il présente en outre une réduction de 13,84% des émissions carbones si un tel plan est réalisé. Dans un système possédant un petit nombre de serveurs, les résultats des estimations ou simulations sont facilement visualisables. Dans un contexte d’un système de grandes tailles, les visualisations telles que proposées aux figures 7 à 9 sont particulièrement adaptées. Procédé de traitement de données pour la détermination d’une valeur d’un indicateur écologique (E i , Cop i , Cc i ) d’un système informatique (SI), ledit système informatique (SI) comprenant une unité d’exécution (UE) et au moins une charge logicielle (SW i ; SSW i ; SSSW i) apte à être exécutée à partir de ladite unité d’exécution (UE), ledit procédé comprenant : - une étape de réception de données de fonctionnement (Data) du système informatique (SI), lesdites données de fonctionnement comprenant au moins un premier ensemble (M i ) de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle (SW i ; SSW i ; SSSW i ) ; - une étape de calcul de la valeur de l’indicateur écologique (E i , Cop i , Cc i ) à partir d’au moins un paramètre du premier ensemble (M i ) de paramètres. Procédé de traitement de données selon la revendication 1, dans lequel les données de fonctionnement du système informatique comprennent un deuxième ensemble (R) de paramètres associés à un fonctionnement global de l’unité d’exécution et un troisième ensemble (DC) de paramètres associés au fonctionnement global du système informatique. Procédé de traitement de données selon l’une quelconque des revendications 1 ou 2, dans lequel l’indicateur écologique est choisi dans un ensemble d’indicateurs écologiques, ledit ensemble d’indicateurs écologiques comprenant au moins : une énergie consommée (E i ) par la charge logicielle (SW i ; SSW i ; SSSW i ), une contribution opérationnelle (Cop i ) de la charge logicielle (SW i ; SSW i ; SSSW i ), une contribution de construction (Cc i ) de la charge logicielle (SW i ; SSW i ; SSSW i ). 4. Procédé de traitement de données selon la revendication 3, dans lequel l’énergie consommée (E i ) est fonction d’au moins un paramètre du premier ensemble (M i ) de paramètres et d’au moins un paramètre du deuxième ensemble (R) de paramètres. Procédé de traitement de données selon l’une quelconque des revendications 3 ou 4, dans lequel la contribution opérationnelle (Cop i ) est fonction de l’énergie consommée (E i ) et d’au moins un paramètre du troisième ensemble (DC) de paramètres. 6. Procédé de traitement de données selon l’une quelconque des revendications 3 à 5, dans lequel la contribution de construction (Cc i ) est fonction d’au moins un paramètre du premier ensemble (M i ) de paramètres et d’au moins un paramètre du deuxième ensemble (R) de paramètres. , avec une puissance CPU, une puissance mémoire, une puissance de stockage ; une durée de référence, une énergie consommée par des accès entrée/sortie. avec un inverse du rendement énergétique du système informatique ; un facteur de conversion puissance vers CO2. avec une quantité des émissions totales dues à la construction du système informatique, un temps d’allocation de ressource Hardware au ressource Software du système informatique, une durée de vie du système informatique ; une part de ressource Hardware allouée à la ressource Software. 10. Procédé de traitement de données selon l’une quelconque des revendications 1 à 9, dans lequel le sous-système informatique comprend N charges logicielles exécutées à partir de ladite unité d’exécution (UE) dans différentes plages temporelles, ledit procédé comprenant une étape de détermination d’une valeur résiduelle de l’indicateur écologique ladite valeur résiduelle étant représentative d’une non-utilisation de ladite unité d’exécution (UE) au cours du temps. 11. Procédé de traitement de données selon l’une quelconque des revendications 1 à 10, dans lequel la valeur de l’indicateur écologique déterminée pour la charge logicielle (SW i ; SSW i ; SSSW i ) est affichée dans un graphique de visualisation globale du fonctionnement de l’ensemble des charges logicielles du système informatique. 12. Dispositif de traitement de données pour la détermination d’une valeur d’un indicateur écologique (E i , Cop i , Cc i ) d’un système informatique, ledit système informatique comprenant une unité d’exécution (UE) et au moins une charge logicielle (SW i ; SSW i ; SSSW i ) exécutée à partir de ladite unité d’exécution (UE), ledit dispositif de traitement (T) comprenant : - un module de réception (REC) de données de fonctionnement du système informatique, lesdites données de fonctionnement comprenant au moins un premier ensemble (M i ) de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle (SW i ; SSW i ; SSSW i ) ; - un module de calcul (CAL) de la valeur de l’indicateur écologique (E i , Cop i , Cc i ) à partir d’au moins un paramètre du premier ensemble (M i ) de paramètres. 13. Système informatique comprenant une unité d’exécution (CPU) et au moins une charge logicielle (SW i ; SSW i ; SSSW i ) exécutée à partir de ladite unité d’exécution (UE), ledit système informatique étant apte à transmettre des données de fonctionnement dudit système informatique, lesdites données de fonctionnement comprenant au moins un premier ensemble (M i ) de paramètres associés à un fonctionnement de l’unité d’exécution en lien avec l’exécution de la charge logicielle (SW i ; SSW i ; SSSW i ), au moins un paramètre du premier ensemble (M i ) étant apte à être traité pour calculer une valeur d’un indicateur écologique (E i , Cop i , Cc i ). 14. Système informatique selon la revendication 13, dans lequel la charge logicielle (SSW i ; SSSW i ) est adaptée pour s’exécuter au sein d’une autre charge logicielle (SW i ; SSW i ). Programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de traitement pour la détermination d’une valeur d’un indicateur écologique selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un processeur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution d’un procédé d’aide à la décision selon l’une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un processeur.