DEV Community: Sébastien

I turned a 78-criterion green software standard into a 20-point scorecard

Sébastien — Wed, 30 Sep 2026 01:26:38 +0000

EOF
France's national green software standard has 78 criteria. It is good. It is free. It is written by the telecom regulator, the media regulator and the environment agency together (RGESN v2, 17 May 2024). Every criterion comes with an implementation sheet.

And in two years I have never once seen it decide anything.

Not because it is wrong. Because a checklist and a decision are different objects, and almost every sustainability framework I have read is the first one pretending to be the second.

A maturity score is not a comparison

The RGESN does have a score. Here is what the regulator says it is for:

"Afin de faciliter le suivi en continu des efforts entrepris, il est aussi possible de calculer un score d'avancement renseignant son niveau de maturité vis-à-vis du référentiel."

A progress score. Your maturity, against the standard, over time. That is a genuinely useful thing and it is not the thing anyone actually needs at the moment of choosing.

Because the moment that matters is this one: two suppliers, two proposals, one budget, and someone has to say this one, not that one, in writing, in a way that survives a challenge. At that moment a 78-item checklist gives you nothing. Both bidders will tick most of it. Both will tick the cheap ones. Neither will tick the one that would have mattered.

The missing layer is not more criteria. It is weights and the honest admission that weighting is where the actual opinion lives.

Weighting forces you to say what you believe

I write these scorecards for digital procurement, so I had to pick. Three things pushed the weights around.

1. The footprint is not where the dashboard is. The French environment agency and telecom regulator measured it together and put it plainly: "79 % de l'empreinte carbone du numérique provient de nos équipements" and of that equipment footprint, manufacturing accounts for "80 % !" (ADEME–Arcep study, March 2023). Devices, and mostly the making of them. Server hosting is the part everyone can buy their way out of, and the small part. So the heaviest line in my scorecard is not "green hosting". It is: does this service still work on an old device, and can you prove it.

2. Page weight is a proxy, not a truth. I wrote about this separately — a 45 KB page can still cost a phone and the short version is that per-byte carbon models systematically miss the cost of making the device do work. So bytes get points, but fewer than the thing bytes are standing in for.

3. A criterion nobody can verify is worth zero points. This is the rule that changed the document most. Every line has to name the artifact that proves it, a build output, a Lighthouse run, a test matrix, a commit. "Committed to eco-design principles" is not a criterion. It is a sentence.

The scorecard

Twenty points, four to six lines. Here is the shape I converged on for a public-facing digital service.

Line	Points	What it actually asks	How it is verified
Minimum device profile	6	The service is usable on a named low-end device from N years ago, on a throttled network	A test matrix naming device + browser versions, and a recorded run on the named device
Functional restraint	4	Features removed or not shipped, named, with the reasoning	A written trade-off log, per feature, with what was dropped
Page weight budget	3	A hard budget per critical journey, enforced, not aspirational	The budget file in the repo + a CI run that fails when it is exceeded
Trajectory	3	Measured today, measured again later, by the same method	Two dated measurements and the method, not one and a promise
Hosting and infrastructure	2	The part everyone starts with, weighted last	Provider, region, and the contract clause
Deletion and sobriety of data	2	Data that expires, logs that rotate, no infinite retention by default	The retention policy, in config, not in a PDF

Note what is not here. No certification points. No "has an environmental policy" points. No points for a carbon calculator screenshot. Every one of those is available to a supplier who changes nothing.

Note also the weighting choice that will annoy people: hosting is worth 2 out of 20. That is deliberate, and it is the direct consequence of where the footprint is. If a scorecard puts 8 points on green hosting, it is scoring the easy purchase, not the hard engineering.

Three rules that survived contact

Weights before criteria. If you cannot say which two criteria you would trade against each other, you do not have a scorecard, you have a wish list. Write the weights first and let them force the list down to six lines.
Name the artifact or drop the line. Every point has to be earnable by producing a file. If the only possible evidence is a claim, the line is greenwashing infrastructure.
Score the thing the buyer cannot buy. Anything a supplier can acquire in an afternoon (a certificate, a host, a badge) belongs at the bottom. The points belong on the work.

If you are the one answering

The same document read backwards is a spec. If a buyer scores you on a minimum device profile, then the useful engineering work is a test matrix and a throttled run, not a sustainability appendix. If they score trajectory, then one dated measurement now is worth more than any prose later. And if they score hosting at 2 points, the greenest region in the world will not save a 4 MB bundle.

Most of the sustainability work I see suppliers do is aimed at the lines that are cheap to claim, because those are the lines most scorecards weight highest. That is a scorecard problem before it is a supplier problem.

The tool, and its limits

I built a generator that produces this — the criterion, the execution condition, the 20-point scale and the documents to require from six questions: perennova-eco.github.io. It runs entirely in your browser, no account, nothing sent anywhere, free.

Two honest limits. It is written for French public procurement and the legal hook is Article 35 of the 2021 Climate and Resilience Act, whose implementing decree (décret n° 2022-767 of 2 May 2022) removes "la faculté de sélectionner les offres sur la base du critère unique du prix" and applies "au plus tard […] en août 2026" (DAJ, Ministry of the Economy) — and it outputs French. If you write tenders elsewhere, the part that transfers is the table above and the three rules, not the generated text.

If you have built one of these and weighted it differently, I would like to know which line you moved and why. The weights are the argument; everything else is bookkeeping.

(Previously: your servers are not the problem — devices are 65–92% of digital's footprint.)

A 45 KB page can still cost a phone: the blind spot in per-byte carbon models

Sébastien — Sat, 19 Sep 2026 08:49:16 +0000

Two independent models, built by people who never talked to each other, land on the same centre of gravity.

The Sustainable Web Design model (v3) splits the energy of a page view four ways: 15% datacentre, 14% transport network, 52% user device, 19% amortised hardware manufacturing, at 0.81 kWh per GB transferred. The French ADEME–Arcep study, working from national data rather than per-page arithmetic, puts end-user devices at 65–92% of digital's total footprint, with manufacturing, not electricity, as the dominant share.

Different methods, same answer: the thing you host is a rounding error next to the thing people hold.

That conclusion is now reasonably well known. What follows from it is not, and it is the reason I am writing this.

Both models scale with bytes. One of the four segments doesn't.

In a per-byte model, all four segments move together. Halve the payload, halve the datacentre share, the network share, the device-energy share, and the manufacturing share too, because it is expressed as a fixed proportion of transferred data.

That last step is the problem. Manufacturing impact is not a function of bytes. It is a function of replacement. A phone's embodied carbon is spent once, at the factory, and it is amortised over however many years that phone stays in service. What shortens that service life is not page weight. It is the accumulated experience of a device that feels broken.

So the model prices the single largest non-electrical chunk of the footprint as if it were proportional to the one variable that barely influences it.

Two pages, same weight, opposite consequences

Take a 45 KB page: HTML, CSS, no images, inline SVG for the charts. A carbon calculator gives it an A. Roughly 0.014 g CO₂e per visit, about 35× below the HTTP Archive median. Genuinely good work, and I am not being sarcastic, that page is better than almost everything shipped.

Now take another 45 KB page. Same payload to the byte. It runs a requestAnimationFrame loop for a decorative parallax. Its framework build target dropped Android WebView versions older than three years ago. It blocks the main thread for over a second on first interaction. It polls an endpoint every ten seconds and never reaches idle.

Same grade. Same gram count. One of those two pages participates in making a four-year-old phone feel like a broken phone, and the other does not, and the model cannot tell them apart, because nothing it measures changed.

There is a very clean illustration of this published on dev.to a few days ago. @giotramu measured a custom MultiSelect that mounted ~1,175 option components in one synchronous commit for about six visible rows: INP 1,256 ms, measured in DevTools at 4× CPU throttling. After hand-rolling a ~90-line virtual scroll hook, 13 mounted nodes and INP 96 ms. From a per-byte standpoint, that fix is invisible: the JS bundle barely moved, the transferred weight is the same, the carbon grade would not budge. From the standpoint of whether someone's phone still feels usable, it is one of the largest wins available in front-end work.

And @hanaharness measured third-party weight across 51 B2B SaaS homepages: median 6,072 KB, 34.6% of it someone else's code, and, the number I keep coming back to, 12 of those pages never reach an idle state at all. A page that never goes quiet keeps the CPU and the radio awake. That is battery cycles and thermal load, which is to say service life, which is to say manufacturing, which is to say 19% of the model that the model computes from bytes.

What I would measure instead, and I mean measure, not estimate

None of these is a carbon figure. Each one is a proxy for device service life, and each one is cheap enough to put in a definition of done.

1. The oldest device class you still support, written down and actually tested. Not "we support modern browsers". A named phone, a named OS version, a named year, in the ticket template. If nobody has written it down, the answer is decided accidentally by whatever your build tool defaults to, which is a sustainability decision made by a config file.

2. A main-thread budget at harsher throttling than the default.
Lighthouse's 4× CPU slowdown approximates a mid-tier phone, not an old one. Run your worst interaction at 6× or 10×, or better, on a real five-year-old handset from a drawer. The gap between 4× and the actual tail is exactly where the replacement decision gets made.

3. Time to idle after load. Does the page ever stop doing things? Set a threshold — no long tasks after N seconds, no network after settle, and treat a violation as a bug rather than as a characteristic.

4. Off-screen and background work. Animation frames while the tab is hidden, polling with no backoff, listeners that never detach. These cost nothing in bytes and run for as long as the page is open.

The honest limitation, stated plainly

I cannot convert any of the four into grams. There is no defensible coefficient that turns "we kept supporting one more device generation" into CO₂e, because the counterfactual, would that person have replaced the phone anyway, when, with what, is not observable from a web page.
So this is not a methodology, and anyone presenting it as one is selling something.

It is a narrower claim: the metric is missing, and its absence is systematic rather than accidental. Per-byte models are the only practical way to score a page today, and they structurally cannot see the largest lever, which means the industry optimises hard on 15% and guesses at 71%.

The question, and it's a real one

To @yel-martinez-green-tech, who implemented SWD v3 from scratch rather than calling someone's API, and to anyone else who has been inside these numbers: has anyone found a defensible way to represent a device-lifetime effect inside a per-byte model — or is the honest answer that it needs a second, separate metric that sits beside the gram count?

I have looked and I have not found one. I would rather be shown wrong than keep repeating that the gap exists.

A free tool, in case it helps. Since 21 August 2026, French public procurement law (article 35 of the Climate and Resilience Act) requires at least one environmental award criterion in every public contract — software and digital services included.

Writing the clause is one thing; knowing how to score it is another. I put a small generator online that does both for a digital tender: the drafted criterion, and the scoring scale that goes with it (weighting, scale, evidence to request from bidders).

Free, nothing to install, no account: https://perennova-eco.github.io/

Written and translated with AI assistance, declared with dev.to's AI-Assisted label. The measurements quoted are other people's published
work, credited above; the ADEME–Arcep and Sustainable Web Design figures
are public and linked in the sources of my previous article.

Your servers are not the problem: devices are 65–92% of digital's footprint

Sébastien — Thu, 17 Sep 2026 10:46:22 +0000

Most "green software" conversations I see start at the server. Pick a greener host, move to a cleaner region, trim your bundle, measure grams of CO₂ per page view. All of it is real work, and almost none of it is where the impact is.
The French environment agency (ADEME) and the telecoms regulator (Arcep) ran a joint study on the environmental footprint of digital technology in France. The headline number is uncomfortable if you're an engineer: user devices account for 65% to 92% of the total footprint, depending on which indicator you look at — and the bulk of that is manufacturing, not electricity.
Your servers are in the remainder.
What that actually implies
If devices dominate, and manufacturing dominates devices, then the single biggest environmental lever in a digital product is not efficiency. It's not pushing your users to replace their hardware.
A service that still runs acceptably on a six-year-old Android phone does more for its footprint than any hosting migration you will ever run. And that decision is almost never made by the infrastructure team. It's made in a refinement session, when someone says "we can drop support for that, nobody's on it anyway," and nobody asks how many people "nobody" is.
Here's the hierarchy I now use, most powerful first:

Rank	Lever	Who decides	Cost
1	Don't build the feature	Product	negative — you save
2	Don't exclude old devices	Product + Eng	low to medium
3	Cut media and data weight	Design + Eng	low
4	Simplify the flow (fewer screens, fewer requests)	Product + Design	low
5	Optimise architecture and hosting	Eng	medium to high
6	Offset	Nobody — this is not a lever	—

Rank 6 is not a joke. Offsetting doesn't reduce your service's footprint, it buys the reduction somewhere else. If it comes up as the answer in a steering committee, it's a reliable signal that ranks 1 to 5 were never worked.
And rank 1 is the whole thing in one line: the feature you don't ship is the only one whose impact is zero. No engineer can optimise a feature that shouldn't have existed.
Why the existing frameworks don't get used
France has a public, free, genuinely good reference framework for this: the RGESN (référentiel général de l'écoconception des services numériques), version 2, published 17 May 2024 by Arcep and Arcom together with ADEME. Seventy-eight criteria, each with a practice sheet, three priority levels. The W3C's Web Sustainability Guidelines cover similar ground for an English-speaking audience — that work now sits with the W3C Sustainable Web Interest Group, and the guidelines are developed in the open on GitHub.
Both are built for auditing. Neither is built for the thing that actually happens on a Tuesday afternoon, which is a product manager with fifteen minutes and a backlog, deciding whether a feature ships.
Seventy-eight criteria is not a decision tool. It's a conformance tool. Those are different objects, and conflating them is why most teams read the framework once and never open it again.
Eight questions instead of seventy-eight
So I compressed it into what a refinement session can absorb. Eight questions, roughly four minutes, asked before anything gets built. If the answer to the first one is weak, the other seven are moot.
What measured usage justifies this feature? Not expected usage — observed usage on something comparable. Failing that, what test will measure it before you generalise.
What are you removing in exchange? A team that has deleted nothing in six months isn't making trade-offs, it's accumulating.
Does this exclude any device currently in your user base? If yes: which one, how many users, and who owns that call by name.
How many network requests and kilobytes does this add to the main flow? An order of magnitude is enough. Having no answer at all is the real signal.
What new data does it collect, and how long is that data kept?
Does the degraded version stay usable without this feature? If not, you just created a hard dependency.
What triggers its removal? A usage threshold and a date. A feature with no kill criterion is permanent by default.
What's the likely rebound effect? A per-user gain multiplied by an increase in usage you caused can be a net loss.
Question 7 is the one that changes behaviour fastest, in my experience. Most backlogs have no deletion mechanism at all, so everything that ships stays forever, and the footprint only goes one way.
The traps, in order of how often I see them
Measuring what's easy instead of what matters. Hosting emissions are simple to obtain and small. Device impact is hard to obtain and is most of it. A sustainability page that talks only about hosting is a tell.
Confusing eco-design with offsetting. One reduces, the other purchases. Mixing them in the same communication invites a greenwashing critique that will be entirely fair.
Ignoring rebound. A lighter service that triggers three times the usage has increased its total footprint. Gains have to be reasoned in absolute terms, not per user.
Chasing the label before the practice. Publishing a sustainability declaration on top of an empty process is the most expensive reputational risk on this list.
If you want to run it
I built a free version of the eight questions as a single static page — no signup, no tracker, no network request after load, and it gives you a score out of 100 plus your two highest-priority levers: https://perennova-eco.github.io/en/
It's open and it costs nothing. The MIT-licensed source is on GitHub. There's no buy button on it: I do sell a longer kit built on the same method, but it exists in French only, and pointing English readers at a document they can't read would be a waste of their click.
Disclosure, since it matters here: I'm one person doing this in the open, and I use AI tooling to draft and translate. The numbers, the sources and the method are mine and are checkable — the ADEME-Arcep study and the RGESN are both public.
The question I'd actually like answered: for those of you who've tried to get this onto a roadmap — what got you a yes? In my experience the regulatory argument lands badly and the cost argument lands well, but I've only got my own sample. What worked in yours?

Free, nothing to install, no account: https://perennova-eco.github.io/