Aller au contenu principal
Version: v2 beta

Allocation et partage des impacts

Un équipement, une infrastructure ou un service supporte souvent plusieurs usages, utilisateurs ou services en même temps. L'allocation sert à définir quelle part d'impact peut être attribuée à l'objet évalué. C'est un choix méthodologique structurant : il influe directement sur le résultat et doit donc être explicite, justifié et stable au sein d'une même famille d'évaluations.

Conventions D4B et règles RCP​

Les conventions décrites ici restent celles des calculs D4B. Le RCP parent privilégie les relations physiques, puis le temps et les autres critères lorsque nécessaire ; les RCP enfants précisent ces choix selon le service.1

Pour le réseau, notre exemple par volume diffère de la séparation fixe/variable décrite dans Réseau. Pour le cloud, une allocation par ressources réservées ne suffit pas à reproduire toutes les allocations d’un facteur RCP. Le dénominateur d’un facteur terminal détermine aussi son usage : temps calendaire, temps d’utilisation et facteur déjà alloué par seconde ne sont pas interchangeables. La convention retenue reste explicite ; deux allocations du même poste ne se cumulent pas.

Pourquoi l'allocation est structurante​

L'allocation n'est pas un paramètre secondaire. Un même serveur physique partagé entre trois services peut voir son impact attribué à parts égales, au prorata du temps d'usage ou au prorata des ressources réservées -- et le résultat par service dépend de la règle choisie. Ce choix doit donc être :

  • explicite : la règle d'allocation est documentée dans chaque évaluation.
  • justifié : le critère retenu est relié à la fonction rendue ou à la ressource sollicitée.
  • stable : au sein d'une même campagne d'évaluation, la même règle est appliquée à des objets comparables.
  • calculable : les données nécessaires sont disponibles ou estimables de manière traçable.
Posture méthodologique

La méthodologie privilégie des allocations simples et traçables plutôt qu'une pseudo-précision non reproductible. Lorsqu'un choix est arbitraire, il vaut mieux le documenter que le masquer dans un calcul complexe.

Principales familles d'allocation​

Le tableau ci-dessous résume les familles d'allocation mobilisées dans la méthode, le contexte où elles s'appliquent et leur base physique23 :

FamilleBase d'allocationContexte d'usage principalVariable clé
TemporelleDurée d'usageTerminaux, serveurs dédiésDusageD_{usage}
VolumétriqueVolume de données transféréesRéseau (WAN, LAN, CDN)VV (en octets)
Par capacité réservéeRessources provisionnées (vCPU, RAM, stockage)Centres de données, Cloud, VMNvcpuN_{vcpu}, NramN_{ram}, VstorageV_{storage}
Par nombre d'utilisateursUtilisateurs actifs ou déclarésServices partagés, SaaSNusersN_{users}
Forfaitaire documentéePart fixe conventionnelleCas où aucune donnée d'usage n'est disponiblePart documentée

Mécanismes d'allocation​

Allocation temporelle​

L'allocation temporelle est la règle par défaut pour les équipements dont l'usage est caractérisé par une durée. Elle s'applique notamment aux terminaux et aux serveurs dédiés.

Impact intrinsèque -- la part d'impact de fabrication allouée à un usage est proportionnelle à la durée d'usage rapportée à la durée de vie totale de l'équipement :

Iembi=Dusage×IFembiavecIembi=Impact intrinseˋque alloueˊ pour l’indicateur i[Ui]Dusage=Dureˊe d’usage deˊdieˊe au service eˊvalueˊ[s]IFembi=Facteur d’impact intrinseˋque pour l’indicateur i[Ui/s]\begin{aligned} &I_{emb_{i}} = D_{usage} \times IF_{emb_{i}} \\ \text{avec} \\ &I_{emb_{i}} = \text{Impact intrinsèque alloué pour l'indicateur } i \htmlClass{unit}{[U_i]} \\ &D_{usage} = \text{Durée d'usage dédiée au service évalué} \htmlClass{unit}{[s]} \\ &IF_{emb_{i}} = \text{Facteur d'impact intrinsèque pour l'indicateur } i \htmlClass{unit}{[U_i/s]} \end{aligned}

Lorsque le facteur d'impact est fourni pour une durée de vie théorique TLTL qui diffère de la durée de vie réelle RLRL de l'équipement, une correction proportionnelle est appliquée au facteur déjà normalisé par unité de temps, et non à un inventaire de fabrication total :

IFembi=TIFembi×TLRLavecTIFembi=Facteur d’impact theˊorique[Ui/s]TL=Dureˊe de vie theˊorique du reˊfeˊrentiel[s]RL=Dureˊe de vie reˊelle observeˊe[s]\begin{aligned} &IF_{emb_{i}} = TIF_{emb_{i}} \times \frac{TL}{RL} \\ \text{avec} \\ &TIF_{emb_{i}} = \text{Facteur d'impact théorique} \htmlClass{unit}{[U_i/s]} \\ &TL = \text{Durée de vie théorique du référentiel} \htmlClass{unit}{[s]} \\ &RL = \text{Durée de vie réelle observée} \htmlClass{unit}{[s]} \end{aligned}
Unités de temps

Les formules sont données en secondes par convention. En pratique, on travaille souvent en heures ou en années selon le contexte. Voir Temporalité, vieillissement et versionnement pour le détail du calcul des durées de vie réelles.

Impact opérationnel -- l'énergie consommée est directement proportionnelle à la durée d'usage :

Eelec=Dusage×PelecavecEelec=Consommation eˊlectrique[kWh]Dusage=Dureˊe d’usage[h]Pelec=Puissance moyenne de l’eˊquipement[kW]\begin{aligned} &E_{elec} = D_{usage} \times P_{elec} \\ \text{avec} \\ &E_{elec} = \text{Consommation électrique} \htmlClass{unit}{[kWh]} \\ &D_{usage} = \text{Durée d'usage} \htmlClass{unit}{[h]} \\ &P_{elec} = \text{Puissance moyenne de l'équipement} \htmlClass{unit}{[kW]} \end{aligned}

Pour une fabrication totale connue, l’allocation annuelle correspond à cette fabrication divisée par la durée de vie retenue. L’exemple suivant illustre cette relation, hors impacts d’usage.

40 kg CO₂e/an de fabrication allouée
Exemple : un équipement fabriqué pour 200 kg CO₂e, répartis sur sa durée de vie. Usage exclu ; ce calcul ne mesure pas des émissions évitées.

Allocation volumétrique​

L'allocation volumétrique est la règle de référence pour les réseaux, en tant que convention d'attribution moyenne au trafic.

L'impact d'un segment réseau est calculé par :

SIembi=V×L×CFembiavecV=Volume de donneˊes transfeˊreˊes[o]L=Longueur du segment reˊseau[km]CFembi=Facteur de conversion pour l’indicateur i[Ui/o/km]\begin{aligned} &SI_{emb_{i}} = V \times L \times CF_{emb_{i}} \\ \text{avec} \\ &V = \text{Volume de données transférées} \htmlClass{unit}{[o]} \\ &L = \text{Longueur du segment réseau} \htmlClass{unit}{[km]} \\ &CF_{emb_{i}} = \text{Facteur de conversion pour l'indicateur } i \htmlClass{unit}{[U_i/o/km]} \end{aligned}

Cette approche attribue une part moyenne d'une infrastructure partagée au trafic. Elle ne démontre pas que l'énergie marginale varie linéairement avec les octets ou la distance : les équipements ont une consommation fixe et des capacités par paliers. N'introduire LL que si le facteur est effectivement exprimé par octet et par kilomètre ; un facteur par Go ne doit pas être multiplié à nouveau par une distance.

Allocation par capacité réservée​

Lorsque l'inventaire physique d'un centre de données n'est pas accessible mais que les ressources provisionnées sont connues (vCPU, RAM, stockage), l'allocation repose sur les composants :

Ecomponents=Dusage×(Pcpu+Pgpu+Pram+Pstorage)avecPcpu=Nvcpu×(Pcpumin+12(Pcpumax−Pcpumin))Pram=Nram×0,000392[kW]Pstorage={1,2×10−3×Vstoragesi SSD0,65×10−3×Vstoragesi HDD\begin{aligned} &E_{components} = D_{usage} \times (P_{cpu} + P_{gpu} + P_{ram} + P_{storage}) \\ \text{avec} \\ &P_{cpu} = N_{vcpu} \times \left(P_{cpu_{min}} + \tfrac{1}{2}(P_{cpu_{max}} - P_{cpu_{min}})\right) \\ &P_{ram} = N_{ram} \times 0{,}000392 \htmlClass{unit}{[kW]} \\ &P_{storage} = \begin{cases} 1{,}2 \times 10^{-3} \times V_{storage} & \text{si SSD} \\ 0{,}65 \times 10^{-3} \times V_{storage} & \text{si HDD} \end{cases} \end{aligned}
vCPU et hyperthreading

Un vCPU peut représenter un thread matériel, mais la correspondance dépend de l'offre et de l'architecture. Huit vCPU ne correspondent à quatre cœurs que si le fournisseur documente deux threads par cœur. Les puissances CPU doivent être exprimées par vCPU pour cette formule ; NramN_{ram} est en Go et VstorageV_{storage} en To décimaux. Les coefficients sont des modèles historiques de Cloud Carbon Footprint, à remplacer par des mesures compatibles quand elles existent. Le point médian CPU suppose une charge de 50 %, pas une charge observée.4

Pour l'impact intrinsèque, les ressources provisionnées sont rapprochées de configurations de référence (machines virtuelles petite, moyenne, grande de la Base Empreinte ou base Cloud Carbon Footprint).

Arbre de décision​

Le choix de la règle d'allocation dépend de la couche évaluée et des données disponibles :

Application concrète​

Cas : un service web hébergé sur un serveur partagé

Un serveur physique est partagé entre deux services A et B. On connaît les éléments suivants :

ParamètreValeur
Impact intrinsèque total du serveur (GWP)1 200 kg CO₂ eq. sur 5 ans
Durée d'utilisation du serveur5 ans
Service A : durée d'usage annuelle4 380 h/an (50 % du temps)
Service B : durée d'usage annuelle2 190 h/an (25 % du temps)
Serveur inactif2 190 h/an (25 % du temps)

Avec une allocation temporelle au prorata du temps actif :

Service AService B
Part du temps actif50 / 75 = 66,7 %25 / 75 = 33,3 %
Impact intrinsèque annuel (GWP)240 × 0,667 = 160 kg CO₂ eq.240 × 0,333 = 80 kg CO₂ eq.
Temps inactif

La normalisation sur le temps actif répartit ici la totalité des 240 kg annuels, y compris la part d'inactivité, entre A et B. Une allocation sur le temps calendaire donnerait au contraire 120 kg à A, 60 kg à B et 60 kg à une catégorie « capacité non allouée ». Les deux conventions répondent à des questions différentes ; ne pas présenter la première comme excluant l'inactivité. L'exemple suppose des créneaux exclusifs ; des services simultanés nécessitent également une part de ressources.

Principes de choix​

Une bonne règle d'allocation doit :

  1. être reliée à la fonction rendue par l'équipement ou le service.
  2. rester compréhensible pour un relecteur non spécialiste.
  3. être calculable avec les données effectivement disponibles.
  4. limiter les effets arbitraires -- une allocation simple est souvent préférable à une pseudo-précision non traçable.
  5. être cohérente avec les allocations utilisées dans les autres couches de la même évaluation.

Effet du dénominateur sur l’allocation​

Pour un équipement fictif de 1 000 kg CO₂e sur cinq ans, un service de 100 heures reçoit :

Convention du scénarioCalculFabrication allouée
Temps calendaire1 000 × 100 / (5 × 8 760)2,28 kg CO₂e
Temps utile de 2 000 h/an1 000 × 100 / (5 × 2 000)10 kg CO₂e
Capacité réservée à 10 % pendant un an1 000 × 1/5 × 10 %20 kg CO₂e

Ces valeurs répondent à des questions différentes. La première ne réattribue pas les périodes inactives au service ; la deuxième répartit toute la fabrication entre les heures utiles ; la troisième inclut la part réservée, même inutilisée. Elles ne s’additionnent pas. La convention et le traitement des capacités restantes accompagnent le résultat.

Hypothèses et limites​

  • Les allocations mixtes sont parfois nécessaires, notamment pour les services qui combinent temps d'usage, stockage et flux réseau. Dans ce cas, chaque couche peut avoir sa propre règle d'allocation, à condition que l'ensemble reste documenté.
  • L'allocation par capacité réservée attribue la capacité rendue indisponible aux autres usages, même lorsqu'elle est peu utilisée. Elle n'est pas une mesure de consommation réelle. Une allocation à la consommation répond à une autre question et doit répartir explicitement le socle à vide et les ressources de support.
  • Les anciens forfaits VM sont obsolètes pour la méthode cible. Une configuration intermédiaire est calculée par composants, puis allouée ; elle n’est pas obtenue par interpolation de ces forfaits.
  • L'allocation forfaitaire ne doit être utilisée qu'en dernier recours, lorsque aucune donnée d'usage n'est disponible.

Les durées de vie reposent sur les inventaires historisés et les hypothèses du registre ; aucun catalogue public data/hardware n’est présent dans l’instantané vérifié.

Notes de bas de page​

  1. ADEME, RCP services numériques, version 2, juin 2026, p. 16–19. ↩

  2. Facteurs d'impact intrinsèques : digital4better/data → data/equipment/*, data/factor/*. Facteurs réseau : Base Empreinte ADEME (services numériques, lignes réseau fixe et mobile). Coefficients de puissance composants : Cloud Jewels, Cloud Carbon Footprint. Durées de vie : inventaires historisés et hypothèses du registre. Données d'usage mesurées quand elles existent ; à défaut, hypothèses documentées dans le Registre des hypothèses et valeurs par défaut. Digital4Better, catalogue de données, instantané 77cae4a. Références et portée : Sources et corpus. ↩

  3. Digital4Better, digital4better/data Catalogue évolutif ; utiliser un commit pour figer les facteurs. ↩

  4. Cloud Carbon Footprint -- Methodology Documentation en ligne, version non figée. ↩