La méthode

Le protocole de mesure

Grammage ouvre la page dans un vrai navigateur et la laisse vivre comme elle vivrait chez un visiteur, en suivant toujours le même protocole, qu'on appelle grammage-1. Tout ce qui suit est donc fixé d'avance, et c'est ce qui permet à quelqu'un d'autre de refaire la mesure dans les mêmes conditions et de retrouver les mêmes octets.

Les conditions

Le réseau n'est pas bridé, ce qui ne change pas les octets comptés mais peut changer ce qu'une page décide de charger selon la vitesse de sa connexion, et on y revient dans les limites. Quant au processeur du téléphone, il est ralenti quatre fois pour ressembler à un modèle de milieu de gamme.

Les cinq temps

Le défilement sert à déclencher tout ce qui ne se charge que quand on s'en approche, comme les images différées. Quand une page bloque le geste, ce que fait souvent un bandeau de consentement tant qu'on ne lui a pas répondu, Grammage la fait défiler par script, comme le fait EcoIndex, sans jamais répondre au bandeau, ni pour accepter ni pour refuser, et le rapport le dit. La page mesurée ressemble alors plutôt à celle d'un visiteur qui refuse les cookies. Quand le contenu défile dans un grand bloc de la page plutôt que dans la fenêtre, comme dans certaines applications, c'est ce bloc que Grammage fait défiler.

Le chargement initial et la page entière

Grammage garde deux vues de chaque passage. Le chargement initial regroupe ce qui est arrivé pendant le chargement et l'attente du calme, donc avant le défilement, et c'est lui que la note compare, parce que c'est ainsi que l'HTTP Archive mesure les pages dont viennent nos repères. La page entière ajoute le défilement et l'observation, et c'est elle que le carbone compte, puisque ce qu'un visiteur fait télécharger en descendant compte aussi pour l'énergie. Une image chargée seulement en bas de page ne pèse donc pas sur la note, comme elle ne pèse pas sur les repères, alors qu'elle pèse sur l'estimation de carbone.

Ce qui est relevé

Les pages d'un site et leurs gabarits

Grammage teste une page quand on lui en donne l'adresse, et la note qu'il rend ne vaut alors que pour elle. Pour un site entier, il lit le sitemap, ou suit les liens de la page quand il n'y en a pas, puis il garde trois pages par gabarit et cinquante en tout, et chacune est mesurée comme une page à part, avec sa propre note.

Le gabarit se lit d'abord dans l'adresse, donc /blog/un-article et /blog/un-autre partagent /blog/*. Quand un site range ses fiches à la racine, l'adresse ne dit plus rien, alors Grammage compare le squelette du HTML, les balises et les classes du contenu sans le texte, l'en-tête, le menu ni le pied de page. Une application dessinée dans le navigateur, dont le HTML est presque vide, n'est pas regroupée de cette façon, et sans sitemap le même regroupement se fait sur la page rendue pendant le parcours des liens.

Le poids de chaque page dans le site

Le résultat du site, sa note, son carbone moyen par page et son poids initial moyen, est la moyenne de ses pages mesurées, où chacune compte pour la part du site qu'elle représente. Une fiche produit mesurée parmi trois, sur un sitemap qui en compte deux mille, pèse ainsi pour environ 667 pages, et la page d'accueil pour une seule. Quand le site est découvert par ses liens plutôt que par un sitemap, on ne connaît pas la taille de chaque gabarit et chaque page compte à égalité. Comme Grammage ne connaît pas le trafic de chaque page, le carbone d'un site est une moyenne par page du site, jamais par page vue, et on ne dit rien de tout un site à partir de sa seule page d'accueil.

Les pages qu'on ne peut pas mesurer

Une page qui répond par un défi anti-robots, celui de Cloudflare ou de DataDome, ou par un refus d'Akamai, d'Imperva, de HUMAN ou de Kasada, est déclarée non mesurée plutôt que notée, puisque ce qu'on aurait pesé n'est pas la vraie page. Sur notre corpus, ces services ont refusé douze des trente boutiques en ligne et six des trente sites de presse. Un client dont le site est ainsi protégé ajoute à la liste blanche de son service l'agent qui contient Grammage/, car Grammage ne cherche jamais à se faire passer pour un visiteur humain.

Du poids au carbone

Mesurer directement l'énergie que consomme une page, chez chaque visiteur, sur chaque réseau et dans chaque centre de données, c'est impossible depuis l'extérieur. Grammage l'estime donc avec un modèle publié, Sustainable Web Design dans sa version 4, que le collectif du même nom maintient et que la bibliothèque CO2.js de la Green Web Foundation met en œuvre, dans sa version 0.19. Le modèle part des octets transférés, les traduit en énergie répartie entre les centres de données, le réseau et l'appareil du visiteur, fabrication du matériel comprise, puis traduit cette énergie en carbone avec l'intensité de l'électricité.

Les constantes du modèle

Un gigaoctet vaut ici un milliard d'octets. Le modèle répartit 1 581 TWh par an, dont 1 021 d'usage et 560 de fabrication, sur le trafic d'Internet, et il obtient 0,300 kWh par gigaoctet, soit 0,194 d'usage et 0,106 de fabrication.

La fabrication est comptée en térawattheures équivalents électricité, ce qui explique qu'on la multiplie ensuite par une intensité comme l'usage. Ces totaux viennent d'estimations qui s'écartent beaucoup d'une source à l'autre, et avec un autre dénominateur de trafic, les coefficients d'usage des centres de données et des réseaux seraient environ 20 % plus hauts, c'est pourquoi on garde le carbone pour une estimation et pas pour une mesure.

Les formules

Go           = octets / 10⁹
usage        U(s) = Go × ε_usage(s) × I(s)
fabrication  F(s) = Go × ε_fabrication(s) × 494
première vue = U(centre) × (1 − H) + F(centre) + U(réseau) + F(réseau) + U(appareil) + F(appareil)

s   le segment : centre de données, réseau ou appareil du visiteur
ε   l'énergie par gigaoctet du tableau, en kWh
I   l'intensité de l'électricité du segment, en g de CO₂ éq. par kWh (494 par défaut)
H   1 quand l'hébergeur est reconnu vert, 0 sinon

L'usage utilise l'intensité de l'électricité du segment, 494 g par kWh par défaut, la valeur mondiale du jeu Ember de 2022 que Sustainable Web Design recommande. La fabrication, elle, garde toujours 494, même quand on met une intensité locale, parce que presque tout le matériel numérique passe par une chaîne d'approvisionnement mondiale. Un hébergeur que la Green Web Foundation reconnaît comme vert retire seulement l'usage électrique du centre de données, jamais sa fabrication ni le reste de la chaîne, ce qui enlève 0,055 sur 0,300 au facteur mondial, soit 18,3 % du total.

Grammage compte une première visite, donc sans aucune réduction pour le cache, ce qui correspond aux valeurs par défaut de CO2.js pour la version 4. C'est ce chiffre, le plus prudent, que Grammage met en avant et que le badge affiche, parce qu'il ne dépend d'aucune hypothèse sur votre public et qu'il se compare aux statistiques du Web Almanac, qui utilisent le même calcul. Il compte la page entière, défilement compris, alors que la note, elle, ne regarde que le chargement initial.

Un calcul pas à pas

Prenons une page qui a transféré un mégaoctet, donc 0,001 Go, vers un hébergeur que la Green Web Foundation ne reconnaît pas comme vert, avec l'intensité mondiale de 494 g par kWh partout. Le centre de données consomme 0,001 × 0,055 kWh d'usage, soit 0,000055 kWh, que l'on multiplie par 494 pour trouver 0,0272 g, et l'on refait la même opération pour chaque segment et pour la fabrication.

L'usage et la fabrication additionnés donnent 0,1482 g, ce qui revient à 0,3 kWh par gigaoctet multipliés par 494 g par kWh, soit 148,2 g par gigaoctet. Une page de 2,4 Mo reçoit de la même façon 0,356 g.

L'estimation locale

À côté du chiffre principal, le rapport donne une estimation locale, qui reprend l'électricité du pays de votre public pour le réseau et l'appareil, la France par défaut, et celle du pays du serveur pour le centre de données quand on le connaît. Le pays du serveur se déduit de son adresse IP, et quand on ne le connaît pas, le centre de données garde les 494 g du monde. La fabrication reste toujours à 494, ce qui fait que, pour un public et un serveur en France, l'usage devient presque négligeable et le résultat ne dépend plus guère que de la fabrication. Cette estimation ne remplace jamais le chiffre principal, parce qu'elle dépend d'hypothèses qu'on choisit, mais elle donne un ordre de grandeur plus proche de la réalité d'un site français.

Ces intensités annuelles sont celles de 2025, embarquées dans CO2.js, et la France illustre bien leur fragilité puisqu'Electricity Maps donne 60, 91, 49, 33 puis 31 g par kWh de 2021 à 2025. Le rapport traduit enfin les grammes en équivalences tirées des facteurs publics de l'ADEME, en kilomètres de voiture ou en recherches web par exemple.

Situer les grammes

La page de vérification situe les grammes d'un site sur l'échelle de notation carbone de Sustainable Web Design, par vue. Les paliers sont inclusifs, une page de 0,079 g est encore un A.

Les catégories et leurs seuils

Une boutique en ligne n'a pas du tout les mêmes besoins qu'un site de présentation, donc Grammage ne compare jamais une page à tout le web mais seulement aux pages de sa catégorie. Il y en a six, et chacune a ses propres repères, tirés des données du Web Almanac, l'étude annuelle de l'HTTP Archive sur des millions de sites. Comme le Web Almanac range les sites par technologie plutôt que par genre, chaque catégorie reprend les technologies qui lui correspondent le mieux, et c'est sur elles que se calcule son repère.

Comment la catégorie est choisie

Celui qui mesure peut déclarer la catégorie, avec l'option --category de la ligne de commande ou le champ category de l'API, où elle vaut vitrine par défaut. Il peut aussi écrire auto, et Grammage déduit alors lui-même la catégorie de chaque page, plutôt que de laisser quelqu'un choisir la plus indulgente. Il lit pour ça ce que la page publie déjà pour les moteurs de recherche, ses types schema.org, en JSON-LD ou en microdonnées, son og:type et sa balise generator, ainsi que la plateforme qu'il a reconnue. Il cherche les indices dans l'ordre du tableau, et la première catégorie dont il en trouve un l'emporte.

Les catégories présentation et application ne se déduisent jamais, il faut les déclarer. Chaque page garde sa propre catégorie, donc sur un même site une fiche produit se compare aux fiches produit pendant que l'article du blog se compare aux articles, et le rapport indique par score.context.inferred quand la catégorie a été déduite.

D'où viennent les repères

Chaque catégorie a deux repères de poids, le « bon », qui est le 25e percentile, c'est-à-dire le poids sous lequel se trouve le quart des pages les plus légères, et la médiane. La médiane vient du Web Almanac 2024, chapitre Sustainability, qui donne le poids médian de chaque technologie, séparément sur téléphone et sur ordinateur. Grammage fait la moyenne de ces médianes pour les technologies de la catégorie, en pondérant chacune par son nombre de pages, ce qui donne par exemple 2 688 Ko pour la vitrine sur téléphone. Le 25e percentile se déduit ensuite de cette médiane, en la multipliant par le rapport que donne le Web Almanac 2025, chapitre Page Weight, entre le 25e percentile et la médiane des pages d'accueil de tout le web, soit 0,497 sur téléphone et 0,507 sur ordinateur. Le « bon » repère vaut donc à peu près la moitié de la médiane, avec 1 336 Ko pour la vitrine sur téléphone.

Les repères de requêtes viennent du Web Almanac 2025, chapitre Page Weight, et ceux du DOM du Web Almanac 2024, chapitre Markup. Les premiers dépendent du type de page, la page d'accueil quand l'adresse est la racine et une page intérieure sinon, les seconds seulement de l'appareil, et ni les uns ni les autres ne changent avec la catégorie.

Une même technologie peut nourrir deux catégories, WordPress, Drupal et Joomla pour la vitrine et l'éditorial, Gatsby pour la présentation et l'application, ce qui explique que la vitrine et l'éditorial aient des repères de poids presque identiques.

Une courbe réglée par deux repères

Pour le poids, les requêtes et le DOM, Grammage place la page sur une courbe log-normale, la même que Lighthouse, réglée par deux repères réels de la catégorie. Une page aussi légère que le quart des pages les plus légères, le 25e percentile, obtient 0,9, une page dans la moyenne, c'est-à-dire à la médiane, obtient 0,5, et la note glisse doucement entre les deux et au-delà, sans aucune marche d'escalier. Une page aussi loin au-dessus de la médiane que le repère bon l'est en dessous obtient 0,1, ce qui revient à peu près à deux fois la médiane, et une page presque vide approche 1 sans jamais le dépasser.

z    = ln(mesure / médiane) × 0,9062 / ln(médiane / bon)
note = erfc(z) / 2

bon       le repère « bon », le 25e percentile de la catégorie
médiane   le repère « médiane » de la catégorie
erfc      la fonction d'erreur complémentaire
0,9062    la valeur qui donne 0,9 à la page égale au repère « bon »

Des repères aux lettres

Les seuils des lettres sont les points où cette courbe croise des repères réels. Le A commence à 90, la note du « bon » repère, donc au niveau du quart des pages les plus légères. Le C commence à 50, la note de la médiane, et le E à 10, la note d'une page environ deux fois plus lourde que la médiane, puis en dessous de 10 la page reçoit un F. Entre ces trois repères, le B commence à 70 et le D à 30, qui découpent en deux l'écart de note entre deux repères voisins. Prenons le poids d'une page vitrine sur téléphone, dont la médiane est de 2 688 Ko et le « bon » repère de 1 336 Ko, et regardons à quel poids la courbe donne chaque seuil.

Ces poids se lisent sur la note du seul poids. La note de la page additionne ensuite ses cinq parts, donc elle atteint 90 seulement quand la page est au niveau du meilleur quart sur chaque critère, et c'est ce que veut dire un A. Les requêtes et le DOM suivent la même courbe avec leurs propres repères, ce qui leur donne d'autres seuils, par exemple 43 requêtes pour le A et 75 pour le C sur la page d'accueil d'un téléphone.

La note sur 100

Le score va de 0 à 100 et compare la page à celles de sa catégorie, que la section précédente explique. Il additionne cinq parts, avec les poids suivants.

Les cinq parts

Chaque part reçoit une note entre 0 et 1, que l'on multiplie par son poids, et la note de la page est la somme de ces points rapportée aux seuls poids comptés, puis arrondie à l'entier le plus proche, le demi allant à l'entier pair. Ces poids sont un choix de méthode, que nous publions. Le poids l'emporte parce que c'est la grandeur que multiplie le modèle de carbone, les requêtes et le DOM comptent chacun pour moitié moins, les bonnes pratiques attrapent ce que ni le poids ni le nombre ne voient, et l'hébergement pèse moins que ce que la page fait télécharger à des milliers de visiteurs. Le poids, les requêtes et le DOM sont ceux du chargement initial, avant le défilement.

Les bonnes pratiques et l'hébergement

La part des bonnes pratiques est la somme des poids des règles réussies, une règle à moitié tenue comptant pour la moitié, divisée par la somme des poids des règles qui concernent la page, et la liste complète est dans la section suivante. La part de l'hébergement vaut 1 quand la Green Web Foundation reconnaît l'hébergeur comme vert ou quand le serveur est dans un pays dont l'électricité émet moins de 100 g de CO₂ par kWh, 0 sinon. Quand l'hébergement ne peut pas être connu, derrière un CDN comme Cloudflare qui cache le vrai serveur, cette part sort du calcul, et la note se fait sur 90 points ramenés à 100, parce qu'on préfère ne rien dire plutôt que de punir une page pour une chose qu'on ne sait pas.

Un exemple chiffré

Le 29 septembre 2026, la page d'accueil de solyzon.com a été mesurée en profil téléphone, dans la catégorie vitrine. Les quatre parts comptées rapportent 28,2, 11,85, 0,75 et 24 points, soit 64,8 sur 90, et 64,8 multiplié par 100 et divisé par 90 donne 72, une note de 72 sur 100. Presque tout ce qui manque vient du DOM, avec deux fois plus d'éléments que la médiane.

Les lettres

Le rapport et le badge n'affichent que la note sur 100, parce qu'une lettre seule se lit comme un verdict officiel que Grammage n'a pas à rendre. La lettre sert à situer le score sur la page de vérification, à côté de l'échelle de Sustainable Web Design, et de seuil dans votre CI, par GRAMMAGE_FAIL_UNDER.

Les quinze règles

Les règles viennent des 115 bonnes pratiques d'écoconception web du collectif Green IT, qu'on repère par leur numéro RWEB, du référentiel général d'écoconception de services numériques de l'Arcep et de l'Arcom, le RGESN 2024, et des Web Sustainability Guidelines du W3C, les WSG, dans leur brouillon de décembre 2025. Chaque règle vaut 1, 2 ou 3 selon ce qu'elle pèse vraiment sur l'empreinte. Une règle réussie rapporte tout son poids, une règle à moitié tenue, ce qu'on appelle « à surveiller », la moitié, une règle ratée rien du tout, et une règle qui ne concerne pas la page, une règle sur les vidéos pour une page sans vidéo par exemple, sort du calcul.

Les images vectorielles, les SVG, sortent des règles de redimensionnement et de chargement à la demande, puisqu'un dessin vectoriel se dessine à n'importe quelle taille sans rien peser de plus, mais leurs octets restent comptés dans le poids de la page comme ceux de toute autre ressource. Pour les polices, font-families ne compte que celles qui sont téléchargées, les replis en local() n'y entrent pas. Les références RGESN renvoient à huit critères du référentiel, que le rapport reprend dans une aide à la déclaration d'écoconception.

Ce que rapporterait chaque correctif

Chaque bonne pratique non tenue arrive avec son correctif et avec le gain qu'on peut en attendre à chaque vue, pour que vous commenciez par ce qui pèse vraiment. Ce gain se calcule sur le poids réel des fichiers fautifs, relevé pendant la mesure, auquel on applique une part volontairement prudente, tirée des études publiées plutôt que du meilleur cas, puis il se traduit en carbone par le même modèle que le reste, avec le même hébergeur.

gain en octets    = somme, sur chaque fichier fautif, de octets transférés × part
gain en carbone   = Sustainable Web Design v4 appliqué aux octets gagnés

image trop grande part = 1 − (largeur utile / largeur réelle)²
                  largeur utile = min(largeur réelle, largeur affichée × densité de l'écran)

Pour les images trop grandes, on ne prend pas une part fixe mais la surface en trop, puisqu'une image deux fois trop large dans chaque sens porte quatre fois les pixels utiles, et on la calcule avec la largeur qu'elle a à l'écran, multipliée par la densité de l'écran simulé. Les autres bonnes pratiques, une description absente ou trop de domaines par exemple, n'ont pas de gain chiffrable en octets, et le rapport n'en invente pas. Le rapport rejoue aussi la note avec le correctif appliqué, sur le chargement initial, pour dire combien de points il rapporterait, et c'est ce qui permet de classer les conseils.

Ce qui valide la méthode

Une méthode publiée ne vaut que si ses chiffres se reproduisent et s'accordent avec ce que d'autres mesurent, donc nous avons vérifié trois choses, que la mesure se répète, que les repères tiennent face à des pages réelles, et que notre façon de mesurer retrouve celle des autres outils.

La mesure se reproduit

Le 29 septembre 2026, nous avons mesuré huit sites trois fois dans la nuit, en profil téléphone, sur un Apple M4 Pro avec Chromium 153 et Playwright 1.63, par trois versions successives du moteur qui partagent le même protocole. Chaque case donne les trois valeurs dans l'ordre.

Le poids, les requêtes et le DOM se reproduisent à 0,6 % près sur sept sites, le plus grand écart étant une requête de plus sur 167 pour zetelecom.fr. La seule exception est kmc-events.fr, dont la page change d'elle-même d'un chargement à l'autre. Le temps de calcul, lui, varie du simple au double et jusqu'à près de six fois pour kmc-events.fr, ce qui explique qu'il soit affiché mais pas noté. Une mesure faite depuis l'image Docker de la CI donne d'ailleurs les mêmes chiffres qu'une mesure faite sur un poste, 1 584 Ko, 66 requêtes et 1 215 éléments pour solyzon.com dans les deux cas, à un kilo-octet près.

Les repères face à des pages réelles

Dans la nuit du 29 au 30 septembre 2026, nous avons mesuré cent quatre-vingts pages d'accueil, trente par catégorie, surtout françaises et européennes, avec un seul passage par page, quatre pages à la fois et la catégorie de chaque liste déclarée. Le tableau compare le poids initial mesuré aux repères du Web Almanac.

La vitrine, l'éditorial et l'application tiennent leurs repères, avec une note médiane entre 51 et 52 alors que la page moyenne d'une catégorie reçoit 50. La présentation et la documentation mesurent environ 30 % de moins que le Web Almanac, mais notre corpus y est fait surtout de sites d'outils pour développeurs, sans doute plus sobres que la moyenne, donc cet écart dit plutôt quelque chose du corpus que des repères. L'e-commerce est la catégorie la moins sûre, parce que douze boutiques sur trente ont refusé le navigateur de mesure et que les dix-huit restantes sont surtout de grandes enseignes, ce qui ne permet pas de conclure. Un repère modifié change des notes déjà publiées, et cette confrontation n'en a modifié aucun.

Face aux autres outils

Le même jour, nous avons lu les derniers résultats publics d'EcoIndex et de Digital Beacon sur dix-sept pages, sans rien relancer chez eux. Quand ecoindex.fr a testé la page récemment, l'EcoIndex que Grammage calcule sur sa propre mesure tombe au point près sur le sien, et les écarts viennent des résultats anciens ou des pages dont le contenu bouge d'un jour à l'autre.

Digital Beacon passe par PageSpeed Insights, donc par Lighthouse, qui ne fait pas défiler la page, et il pèse à peu près pareil les pages qui ne chargent rien en défilant. Sur une page qui charge en défilant, il reste au chargement initial et s'écarte beaucoup de la page entière.

Les grammes de Digital Beacon sont en revanche deux à trois fois plus hauts que les nôtres pour le même poids, 0,164 g contre 0,07 g pour gohugo.io, parce qu'il applique encore l'ancien modèle Sustainable Web Design v3, qui comptait bien plus d'énergie par octet que la v4. Les trois outils classent les pages dans le même ordre, docs.python.org en tête, doctolib.fr et framasoft.org en queue, mais ils s'écartent sur la lettre, parce qu'ils ne posent pas la même question. EcoIndex juge la page entière dans l'absolu, sur des quantiles fixés depuis 2016, Digital Beacon juge les grammes sur l'échelle de Sustainable Web Design, et Grammage juge le chargement initial face aux pages de la même catégorie.

Les limites de la mesure

Ce n'est pas une mesure d'énergie. Le carbone est une estimation fondée sur un modèle, qui prend les octets pour indicateur de l'énergie sans mesurer le processeur ni la mémoire de l'appareil, et ses propres auteurs le jugent d'ailleurs peu adapté pour repérer ce qu'il faut optimiser dans une page. Deux pages de même poids reçoivent donc la même estimation, même si l'une fait beaucoup plus travailler le téléphone. Les auteurs ne publient pas non plus de marge d'erreur chiffrée, et leurs sources s'écartent beaucoup les unes des autres.

Le serveur reste en partie invisible. Grammage ne voit pas ce que fait le serveur pour fabriquer la page, et derrière un CDN, c'est-à-dire un réseau de serveurs relais, il ne sait même pas où se trouve le serveur d'origine, donc il le laisse inconnu plutôt que de deviner. Six des huit sites de notre campagne de septembre 2026 passaient par Cloudflare, pour lequel la Green Web Foundation répond à la place de l'hébergeur réel, alors que Website Carbon les compte comme verts, ce qui retire 18 % à son chiffre.

Le carbone de la page entière suppose qu'un visiteur défile jusqu'en bas , ce qui surestime sans doute les longues pages, comme celles des médias. Et la visite de retour, mesurée de 0 % à 10,3 % du premier chargement selon les sites, n'est pas déduite du chiffre principal.

Le temps de calcul n'est pas noté, parce qu'il varie encore du simple au double d'une mesure à l'autre. Le réseau n'est pas bridé pendant la mesure, ce qui ne change pas les octets comptés mais peut changer ce qu'une page décide de charger selon la vitesse de la connexion. Une page qui change d'elle-même, avec un contenu tiré au hasard ou des publicités, ne pèse pas la même chose à chaque visite, et la médiane de trois passages n'efface qu'une partie de cet écart.

Les repères viennent du Web Almanac, c'est-à-dire de sites réels, et pas d'un objectif. Une page qui tient la médiane de sa catégorie reçoit 50, sans que cela dise qu'elle soit sobre. Et une page protégée par un service anti-robots ne peut pas être mesurée du tout.

Les versions

Chaque rapport porte trois versions, celle de Grammage, celle du protocole de mesure et celle de la méthode de notation. Le protocole change seulement si ce qui est mesuré change, et la notation change quand les repères, les poids, les données de référence ou ce qui est comparé changent. Deux scores ne se comparent que s'ils partagent le même protocole et la même méthode, et un rapport ancien garde toujours la lettre et les repères de la méthode qu'il nomme, dans son champ score.method.

Les sources

Chaque chiffre de cette page vient de l'une de ces sources, d'une mesure que Grammage a faite lui-même ou d'un calcul qu'on peut refaire à partir d'elles. Le pays d'un serveur se déduit de son adresse IP par RIPEstat, et les données d'intensité sont celles qu'embarque CO2.js.

• Sustainable Web Design, modèle d'estimation des émissions
• Sustainable Web Design, échelle de notation carbone
• Union internationale des télécommunications, trafic Internet de 2022
• Malmodin, 2023, répartition entre usage et fabrication du matériel
• Green Web Foundation, CO2.js et la vérification des hébergeurs verts
• Electricity Maps, méthode des intensités électriques annuelles
• HTTP Archive, Web Almanac 2024, Sustainability
• HTTP Archive, Web Almanac 2024, Markup
• HTTP Archive, Web Almanac 2025, Page Weight
• Lighthouse, calcul des notes de performance
• EcoIndex, méthode publiée
• ADEME, Impact CO2, facteurs d'équivalence
• Green IT, 115 bonnes pratiques d'écoconception web
• Arcep et Arcom, RGESN 2024
• W3C, Web Sustainability Guidelines
• Union européenne, directive (UE) 2024/825