Quelles technologies sont les plus adaptées à l'écoconception ?

Il n'y a pas de technologie écologique en soi : le poids et la complexité de ce qu'on construit comptent davantage que le langage. Pour un site vitrine dont l'équipe publie souvent, un WordPress avec un thème sur mesure ou un thème bloc ; pour un site dont les contenus bougent peu, un générateur de site statique comme Astro, qui n'envoie pas de JavaScript par défaut ; pour un e-commerce, WooCommerce avec des développements sur mesure pour les règles métier ; pour une application métier, Symfony avec API Platform et une interface React, ou Next.js de bout en bout, selon les compétences de l'équipe et l'existant.

Quel est le critère le plus important pour choisir une technologie web ?

L'équipe qui fera vivre le service : qui modifie les contenus, à quelle fréquence, avec quel niveau technique, et qui assure les mises à jour. Une technologie bien choisie mais impossible à maintenir pour l'équipe en place vieillit mal et finit en refonte.

Certains langages de programmation consomment-ils moins d'énergie que d'autres ?

Une étude de 2017, mise à jour en 2021, classait les langages par efficacité énergétique et plaçait C et Rust en tête. Une étude de 2024 conteste ce classement : une fois contrôlés l'implémentation, le nombre de cœurs utilisés et l'activité mémoire, le langage n'a pas d'effet significatif sur la consommation au-delà du temps d'exécution. Pour un site web, l'usage qu'on fait du langage compte bien plus que le langage lui-même.

Comment choisir la meilleure technologie pour éco-concevoir un service web ?

Article publié en août 2024 et mis à jour en octobre 2026 : la grille de choix reflète désormais les technologies que nous utilisons en production, et elle part de l’équipe qui fera vivre le service.

En bref : il n’existe pas de technologie écologique en soi. Ce qui pèse, c’est ce qu’on construit avec : le poids des pages, la quantité de JavaScript, le nombre de services tiers. Le bon choix part du projet et de l’équipe qui le fera vivre. Pour un site vitrine, WordPress quand l’équipe publie souvent, un site statique comme Astro quand les contenus bougent peu ; WooCommerce pour un e-commerce aux règles métier spécifiques ; Symfony, API Platform et React, ou Next.js de bout en bout, pour une application métier, selon l’équipe qui la fera vivre.

« Et vous faites ça avec quelle techno ? » La question arrive tôt dans chaque projet, et elle déclenche des débats sans fin entre développeurs. Nous avons d’abord défini un éco-budget pour nos pages. Reste à choisir avec quoi les construire.

Le langage compte moins que l’usage qu’on en fait

Une étude de 2017 (nouvelle fenêtre), reprise en 2021 dans Science of Computer Programming (nouvelle fenêtre), a classé les langages de programmation par efficacité énergétique, avec C et Rust en tête. Elle est citée dans de nombreux articles sur l’écoconception.

Son classement a depuis été contesté. Une étude publiée en 2024 (nouvelle fenêtre) montre qu’une fois contrôlés l’implémentation du langage, le nombre de cœurs actifs et l’activité mémoire, le choix du langage n’a pas d’effet significatif sur la consommation d’énergie au-delà du temps d’exécution.

Pour un site web, la conclusion est de toute façon la même : c’est l’usage du langage qui compte. L’augmentation continue du poids des pages, mesurée par HTTP Archive (nouvelle fenêtre), en est l’illustration. On construit des pages plus complexes, plus lourdes, plus chargées en scripts, quel que soit le langage. Et le choix de la technologie dépend aussi de son écosystème, des compétences disponibles et de la facilité à trouver quelqu’un pour reprendre le projet.

On débranche le JavaScript

La première question : qui va faire vivre le service ?

Dans la première version de cet article, nous choisissions selon deux critères : le type de projet et le budget. Avec le recul, il en manquait un, plus décisif que les deux autres : l’équipe qui fera vivre le service après la livraison.

Qui modifie les contenus, et à quelle fréquence ? Une équipe qui publie chaque semaine a besoin d’une administration simple. Des pages qui changent deux fois par an peuvent vivre dans des fichiers modifiés par un développeur.
Avec quel niveau technique ? Sans développeur dans l’équipe, tout doit pouvoir se faire depuis l’administration, sans risque de casser la charte.
Qui fera les mises à jour, et avec quel budget ? Un CMS demande une maintenance régulière. Un site statique en demande beaucoup moins.
Que se passe-t-il si le service tombe ? Une boutique en ligne ne supporte pas la même indisponibilité qu’un site vitrine.

Une technologie bien choisie sur le papier, mais que personne dans l’équipe ne sait faire vivre, vieillit mal et finit en refonte. Nous développons ce point dans notre article sur la refonte de site web.

Choisir selon le projet et l’équipe

Voici la grille que nous appliquons aujourd’hui. Elle ne liste que des technologies que nous utilisons en production, sur des projets que nous maintenons.

Projet	Notre choix par défaut	Quand choisir autre chose	Exemple
Site vitrine ou de contenu, équipe qui publie souvent	WordPress avec un thème sur mesure ou un thème bloc	Les contenus bougent peu et un développeur peut les modifier : site statique	Ilex Environnement, thème bloc bilingue
Site vitrine aux contenus stables	Astro, site statique	L’équipe veut tout modifier seule et souvent : WordPress	ouzom.fr, le site que vous lisez
E-commerce	WooCommerce, avec des développements sur mesure pour les règles métier	Gros catalogue et équipe technique dédiée : solution e-commerce découplée	Perlette, retrait en boutique daté et précommandes
Application métier	Pas de choix par défaut : Symfony avec API Platform et une interface React, ou Next.js de bout en bout	Selon l’équipe et l’existant ; une application existante garde son framework	Orysk, en Angular depuis 2022 ; notre outil d’audit RGESN, en Next.js

Quelques précisions sur ces choix.

WordPress, avec un thème sur mesure plutôt qu’un thème du commerce. Un thème vendu clé en main embarque des fonctions dont le site n’a pas besoin, et chacune pèse sur chaque page. Un thème sur mesure ne contient que ce qui sert. Depuis WordPress 5.9 (nouvelle fenêtre), les thèmes bloc permettent en plus à l’équipe de modifier ses pages avec les blocs natifs de WordPress, sans constructeur de pages et sans pouvoir casser la charte.

Astro quand les contenus bougent peu. Un site statique est construit une fois, puis servi tel quel : pas de base de données, presque rien à mettre à jour côté serveur. Astro n’envoie pas de JavaScript au navigateur par défaut (nouvelle fenêtre) : on l’ajoute composant par composant, quand il sert. La contrepartie, c’est que modifier un contenu passe par un développeur, ou par un CMS découplé à brancher en plus.

WooCommerce pour l’e-commerce aux règles spécifiques. Retrait en boutique à une date et une heure, précommandes, bons cadeaux : ces règles ne rentrent pas dans une extension standard, mais WooCommerce permet de les développer sans quitter un écosystème que beaucoup de prestataires savent reprendre.

Pour les applications métier, deux voies, sans hiérarchie. Avec Symfony et API Platform, l’API et l’interface React sont séparées : chaque partie évolue à son rythme, et l’API peut servir plus tard une application mobile ou un outil tiers. C’est un bon choix quand les règles métier sont lourdes ou quand l’équipe et l’hébergement sont déjà en PHP. Next.js couvre l’interface et le serveur dans un seul langage, TypeScript : une seule chaîne d’outils, et une équipe qui passe de l’un à l’autre sans changer de langage. C’est souvent le plus simple quand l’équipe, la nôtre ou celle du client, travaille déjà en JavaScript. Notre outil d’audit RGESN est construit ainsi. Dans les deux cas, ce sont les compétences de ceux qui maintiendront l’application qui tranchent.

Ce que nous ne recommandons plus

La version de 2024 de ce tableau citait Gatsby, Firebase, Appwrite ou Medusa. Ce sont des outils sérieux, mais nous ne les utilisons pas en production. Nous préférons recommander ce que nous savons maintenir dans la durée.

Le choix ne s’arrête pas à la livraison

Une technologie légère ne garantit pas un site léger : il faut aussi un budget, et une mesure dans la durée. Sur ouzom.fr, un serveur Lighthouse CI mesure nos pages à chaque déploiement et nous alerte quand l’une d’elles dépasse son budget, et le poids affiché en bas de chaque page est mesuré par le navigateur du visiteur.

Le bon outil est donc celui qui correspond au besoin, à l’équipe et au budget de maintenance, et qu’on surveille ensuite. Il n’est pas forcément pertinent de tuer un moustique avec un tractopelle : on dimensionne la solution au besoin, puis on vérifie qu’elle reste dimensionnée.

Ces choix sont les nôtres et restent discutables selon chaque projet. Si vous voulez les confronter aux vôtres, écrivez-nous.

Transparence : comment cet article a été mis à jour

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cette mise à jour, elle a servi à relire la version de 2024 et à identifier des sources plus récentes. La grille de choix reflète les projets que nous menons. Les études citées et les documentations de WordPress et d’Astro ont été consultées directement : les liens de l’article et de la section Sources permettent de refaire ce chemin de vérification.

Sources

← Tous les articles