Internet pollue. La plupart des sites web aussi.
Le numérique représente entre 3 et 4 % des émissions mondiales de gaz à effet de serre, un chiffre en progression constante. Une page web moyenne pèse aujourd'hui plus de 2 Mo. Chaque octet chargé consomme de l'énergie : sur le serveur qui envoie, sur le réseau qui transmet, sur l'appareil qui reçoit.
La majorité des clients avec qui je travaille ne le savent pas. Ils savent qu'une voiture pollue, qu'un vol pollue, qu'une usine pollue. Ils n'ont pas conscience qu'un site web qui charge 80 requêtes HTTP sur chaque page, avec des scripts publicitaires, des polices Google, des animations JavaScript non sollicitées, a une empreinte réelle et mesurable. Quand on leur explique, la réaction est presque toujours la même : l'enthousiasme. Personne ne veut d'un site inutilement lourd si on lui montre que la légèreté est possible sans compromis sur le résultat.
Ce que « sobre » veut dire dans les faits
Le Référentiel Général d'Écoconception de Services Numériques (RGESN) liste les critères d'un service numérique sobre. Parmi eux : limiter le nombre de requêtes HTTP, ne charger que les ressources nécessaires à la page affichée, éviter les dépendances tierces superflues, privilégier les formats légers, ne pas charger de scripts dont la page n'a pas besoin.
Un thème FSE natif respecte ces critères par construction. WordPress
core charge ce dont la page a besoin. Le thème bloc n'ajoute pas de
couche JavaScript propriétaire. Les blocs natifs Gutenberg génèrent
du HTML sémantique sans markup superflu. Les styles globaux définis
dans theme.json s'appliquent via une feuille CSS unique,
sans duplication entre composants.
Un site builder charge ses scripts et ses styles sur chaque page, qu'ils soient utilisés ou non. Ce n'est pas une question de bonne volonté des équipes qui développent ces outils : c'est une contrainte structurelle. Un outil généraliste qui doit couvrir tous les cas d'usage possibles ne peut pas être aussi sobre qu'un outil natif qui ne charge que ce que le site utilise réellement. Elementor et Divi progressent sur ce terrain, c'est réel. Mais la complexité d'une couche tierce reste une dette écoconception que le natif n'a pas.
La sobriété comme point de départ, pas comme contrainte
L'argument écoconception change la conversation avec un client. Au lieu de parler de performances techniques, de millisecondes, de Core Web Vitals, on parle d'un choix cohérent avec des valeurs qu'il a déjà. Un artisan qui travaille le bois local, une association qui milite pour la transition écologique, une commune qui a signé une charte environnementale : leur site web peut être cohérent avec ce positionnement, ou le contredire sans qu'ils le sachent.
Partir sur FSE, c'est partir sobre par défaut. Pas sobre après optimisation, pas sobre avec des plugins de cache et de compression ajoutés après coup : sobre par construction, parce que l'outil natif ne charge pas ce dont il n'a pas besoin.
Gutenberg comme infrastructure, pas comme fonctionnalité
Gutenberg n'est pas une option qu'on active dans WordPress. Depuis la version 5.9, il est l'infrastructure sur laquelle WordPress construit l'ensemble de l'expérience d'édition. Les templates de pages, les parties de templates comme le header et le footer, les patterns réutilisables, les styles globaux : tout passe par l'éditeur de blocs.
Ce positionnement change la nature du choix. Choisir Elementor ou
Divi, c'est choisir de poser une couche supplémentaire au-dessus de
cette infrastructure. Choisir FSE, c'est travailler avec
l'infrastructure elle-même. Un thème bloc repose sur trois
éléments : theme.json pour l'ensemble du système
de design (couleurs, typographie, espacements, mise en page), des
fichiers HTML dans templates/ pour la structure des
pages, des fichiers PHP dans patterns/ pour les
compositions réutilisables. Aucune dépendance externe, aucun plugin
intermédiaire, aucune couche propriétaire entre le code et le rendu.
Le HTML sémantique natif : ce que ça change pour l'accessibilité et le SEO
Un bloc Gutenberg natif génère du HTML sémantique. Un titre est un
h1, h2 ou h3. Une liste est
un ul ou ol. La navigation principale est
une nav. Le contenu principal est un main.
Ce marquage est produit par WordPress core, pas par une bibliothèque
tierce.
Un site builder génère le même contenu visuel avec un markup
différent. Les div s'empilent là où des balises
sémantiques suffiraient. Les niveaux de titres sont parfois inversés
parce que l'apparence visuelle a guidé le choix plutôt que la
hiérarchie documentaire.
Cette différence a deux conséquences directes. Pour
l'accessibilité : un lecteur d'écran navigue dans la structure
sémantique du document. Un h2 annonce une section. Un
nav signale une zone de navigation. Sans ces balises,
l'utilisateur d'un lecteur d'écran reçoit une suite de
div sans repères. Pour le SEO : Google utilise la
même structure pour comprendre la hiérarchie du contenu. Un
h1 identifie le sujet principal de la page. Une balise
article délimite le contenu éditorial. Accessibilité et
SEO partagent la même exigence de base : un contenu structuré,
lisible sans dépendance au visuel ou au JavaScript.
La pérennité comme critère écoconception
Un site qu'on refait tous les trois ans parce que le plugin de page builder a changé d'interface, parce que la licence n'a pas été renouvelée, parce qu'une mise à jour a cassé la mise en page : ce site a une empreinte écoconception bien plus lourde qu'un site stable.
La hiérarchie de styles FSE est documentée et prévisible : core
defaults, puis theme.json, puis le thème enfant si
présent, puis les personnalisations utilisateur. Cette cascade est
stable entre les versions de WordPress. Tous les sites FSE livrés
depuis les premières versions stables ont traversé les mises à jour
sans régression. Pas de breaking changes entre versions mineures,
pas de comportement inattendu après une mise à jour core. La
maintenance est fluide parce que l'outil est natif : WordPress
ne casse pas ce qu'il a lui-même introduit.
Un site qui dure, c'est un site qu'on ne recrée pas. C'est l'argument écoconception le plus simple et le plus difficile à contredire.
Ce que Gutenberg demande vraiment
FSE a une courbe d'apprentissage réelle, et l'honnêteté impose de
le dire. Comprendre la structure d'un thème bloc demande de
distinguer ce qui relève de theme.json, des templates,
des template parts et des patterns. Comprendre pourquoi un style ne
s'applique pas demande de savoir lire la hiérarchie : est-ce
que c'est theme.json qui définit cette valeur, ou une
personnalisation utilisateur stockée en base qui l'écrase ?
Mais cet apprentissage est linéaire et documenté. Ce qu'on apprend
sur theme.json aujourd'hui est valable dans trois ans.
Ce qu'on apprend sur les templates HTML de WordPress core ne
deviendra pas obsolète parce qu'un éditeur tiers a changé son
modèle commercial. Quelqu'un qui apprend FSE apprend WordPress.
Quelqu'un qui apprend Elementor apprend Elementor.
Ce qu'on retient
Gutenberg n'est pas le choix écoconception parce qu'il est parfait. C'est le choix écoconception parce qu'il est natif, sobre par construction, sémantique par défaut, stable dans le temps, et cohérent avec les critères du RGESN sans configuration supplémentaire. Là où un site builder ajoute une couche de complexité que l'écoconception demande ensuite de compenser, FSE part du bon endroit.
Pour un client qui découvre que son site web a une empreinte environnementale réelle, c'est un argument qui parle avant même d'ouvrir WordPress.