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.
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 :
| Famille | Base d'allocation | Contexte d'usage principal | Variable clé |
|---|---|---|---|
| Temporelle | Durée d'usage | Terminaux, serveurs dédiés | |
| Volumétrique | Volume de données transférées | Réseau (WAN, LAN, CDN) | (en octets) |
| Par capacité réservée | Ressources provisionnées (vCPU, RAM, stockage) | Centres de données, Cloud, VM | , , |
| Par nombre d'utilisateurs | Utilisateurs actifs ou déclarés | Services partagés, SaaS | |
| Forfaitaire documentée | Part fixe conventionnelle | Cas où aucune donnée d'usage n'est disponible | Part 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 :
Lorsque le facteur d'impact est fourni pour une durée de vie théorique qui diffère de la durée de vie réelle 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 :
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 :
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.
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 :
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 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 :
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 ; est en Go et 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ètre | Valeur |
|---|---|
| Impact intrinsèque total du serveur (GWP) | 1 200 kg CO₂ eq. sur 5 ans |
| Durée d'utilisation du serveur | 5 ans |
| Service A : durée d'usage annuelle | 4 380 h/an (50 % du temps) |
| Service B : durée d'usage annuelle | 2 190 h/an (25 % du temps) |
| Serveur inactif | 2 190 h/an (25 % du temps) |
Avec une allocation temporelle au prorata du temps actif :
| Service A | Service B | |
|---|---|---|
| Part du temps actif | 50 / 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. |
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 :
- être reliée à la fonction rendue par l'équipement ou le service.
- rester compréhensible pour un relecteur non spécialiste.
- être calculable avec les données effectivement disponibles.
- limiter les effets arbitraires -- une allocation simple est souvent préférable à une pseudo-précision non traçable.
- ê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énario | Calcul | Fabrication allouée |
|---|---|---|
| Temps calendaire | 1 000 × 100 / (5 × 8 760) | 2,28 kg CO₂e |
| Temps utile de 2 000 h/an | 1 000 × 100 / (5 × 2 000) | 10 kg CO₂e |
| Capacité réservée à 10 % pendant un an | 1 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é.