Écoconception web et SEO : alléger sans perdre en visibilité

Un responsable SEO reçoit un audit d'écoconception sur son site et découvre une liste de recommandations : réduire le nombre d'images, simplifier les fonctionnalités, alléger les pages. Son premier réflexe est légitime et inquiet à la fois : est-ce compatible avec le référencement, ou est-ce en train de lui demander de démonter ce qui fait justement la force de ses pages ? La question se pose avec une acuité particulière en France, où la loi REEN et le RGESN ont fait de la sobriété numérique un sujet d'entreprise et non plus seulement une posture militante.

La réponse tient en une phrase, mais elle mérite d'être détaillée : la plupart des leviers d'écoconception web vont dans le même sens que le SEO technique, parce que les deux poursuivent en réalité le même objectif intermédiaire, un site plus léger et plus rapide. Une minorité de recommandations, en revanche, ciblent la quantité de contenu ou de médias plutôt que leur poids, et c'est précisément là que les deux disciplines peuvent entrer en conflit. Cet article sépare les deux catégories et donne une méthode pour trancher, page par page, sans sacrifier ni l'un ni l'autre objectif.

La loi REEN et le RGESN : ce qu'impose vraiment la sobriété numérique

La loi relative à la réduction de l'empreinte environnementale du numérique en France, votée en 2021, a posé un cadre légal à une pratique jusque-là informelle : concevoir un service numérique en cherchant à limiter son impact environnemental sur l'ensemble de son cycle de vie, depuis la fabrication des terminaux qui l'affichent jusqu'à l'énergie consommée par les serveurs qui l'hébergent. Le Référentiel Général d'Écoconception de Services Numériques, produit par la mission numérique écoresponsable associant l'Arcep, l'Ademe et la direction interministérielle du numérique, traduit ce cadre en critères opérationnels : des dizaines de points de contrôle qui couvrent la stratégie du service, ses spécifications fonctionnelles, l'expérience utilisateur, les contenus, le frontend et le backend, jusqu'à l'hébergement.

Ce référentiel vise d'abord les services numériques de l'État et des collectivités, dont beaucoup l'intègrent déjà dans leurs cahiers des charges. Le secteur privé n'y est pas encore soumis de la même façon, mais un nombre croissant d'agences, d'intégrateurs web et d'entreprises l'utilisent volontairement comme grille d'audit, en anticipation d'un périmètre appelé à s'élargir. C'est ce mouvement, plus que la seule obligation légale, qui fait atterrir le RGESN dans les recommandations d'agences qui n'ont pourtant aucune obligation réglementaire à ce jour.

Ce point mérite d'être clarifié parce qu'il change la façon d'aborder le sujet : il ne s'agit pas d'une case à cocher ponctuelle, mais d'un référentiel qui va continuer à peser sur les choix de conception des sites français, avec ou sans obligation légale directe.

Là où l'écoconception et le SEO technique tirent dans le même sens

La grande majorité des critères RGESN qui portent sur le frontend et le backend recoupent presque mot pour mot les recommandations de performance web que le SEO technique porte depuis des années, pour une raison simple : réduire le poids d'une page et le nombre de requêtes qu'elle déclenche accélère son chargement, et la vitesse de chargement conditionne les Core Web Vitals que Google utilise comme signal de classement, au premier rang desquels le LCP. Compresser une image, éliminer un script tiers inutile ou supprimer une chaîne de redirections sert donc simultanément l'objectif environnemental et l'objectif de classement, sans qu'il y ait le moindre arbitrage à faire.

Le second point de convergence touche au budget d'exploration. Un site qui multiplie les requêtes superflues, les scripts de tracking redondants ou les ressources jamais utilisées force Googlebot à consacrer une partie de son passage à explorer des éléments qui ne rapportent rien, au détriment des pages qui mériteraient d'être explorées plus souvent. Un site allégé n'explore pas plus vite parce que Google le récompense pour son écoconception, mais parce qu'il présente moins d'obstacles techniques à traverser : le résultat pratique se ressemble, mais le mécanisme est différent, et c'est cette nuance qui évite de croire à un signal de classement environnemental qui n'existe pas en tant que tel.

Concrètement, les leviers suivants servent les deux objectifs sans exception :

• Servir les images au format adapté (WebP ou AVIF) et à la résolution réellement affichée, plutôt qu'en taille native
• Minifier et regrouper les feuilles de style et les scripts pour réduire le nombre de requêtes
• Retirer les bibliothèques JavaScript chargées en entier pour une fonctionnalité mineure
• Limiter les scripts tiers de mesure et de publicité au strict nécessaire
• Éliminer les chaînes de redirections et les liens internes qui pointent vers une URL redirigée
• Mettre en cache les ressources statiques et s'appuyer sur un CDN pour réduire la distance parcourue par les données

Le vrai point de friction : réduire le poids n'est pas réduire le fond

Le RGESN comporte aussi des critères qui portent sur la quantité plutôt que sur le poids : limiter le nombre de fonctionnalités proposées, limiter la quantité de contenu affiché par défaut, limiter le nombre d'images par page. Pris au pied de la lettre, ces critères poussent à retirer des éléments plutôt qu'à les optimiser, et c'est exactement là que le SEO et l'écoconception cessent de pointer dans la même direction. Une page qui répond en profondeur à une intention de recherche le fait souvent grâce à sa richesse : des visuels qui illustrent un point que le texte seul n'explique pas bien, des exemples multiples, des fonctionnalités interactives qui répondent à un besoin réel de l'utilisateur. Retirer ces éléments pour cocher une case d'écoconception peut faire baisser le poids de la page tout en faisant baisser sa capacité à satisfaire la recherche qui l'amène.

Prenons un cas concret : un audit d'écoconception signale qu'une page produit ou qu'un guide comporte trop d'images et recommande d'en supprimer la moitié. La réaction la plus rapide, supprimer effectivement des visuels, réduit le poids de la page mais retire aussi ce qui pouvait la faire apparaître dans la recherche d'images, aider à la conversion ou clarifier un point technique que le texte seul rend confus. La question à se poser n'est pas combien d'images ai-je, mais si ces images sont lourdes parce qu'elles sont nombreuses, ou parce qu'elles sont mal servies. Dans l'immense majorité des cas observés, c'est la seconde raison qui domine, et la solution qui préserve les deux objectifs n'est pas de supprimer, mais de mieux compresser et de mieux dimensionner.

La même logique s'applique aux fonctionnalités interactives : un configurateur, un comparateur ou une carte intégrée pèsent en scripts, mais s'ils répondent à un besoin que documente le comportement des visiteurs, les retirer améliore un score d'écoconception isolé au prix d'une expérience et d'un temps passé sur la page qui comptent, eux, pour le référencement.

Compresser plutôt que supprimer : les leviers qui ne coûtent rien en visibilité

La bonne nouvelle est que l'essentiel du poids d'une page moderne se trouve dans un petit nombre d'éléments identifiables, et qu'agir sur ces éléments permet presque toujours d'atteindre les objectifs de sobriété sans toucher au fond éditorial. Les images et les polices de caractères représentent typiquement l'essentiel du poids transféré, suivies par les scripts tiers et les frameworks JavaScript surdimensionnés pour des pages qui pourraient rester en grande partie statiques. Corriger ces trois postes suffit, dans la plupart des cas, à obtenir la majeure partie du gain de poids visé par un audit RGESN.

Sur les images, le duo format nouvelle génération et attribut srcset permet de servir automatiquement la taille adaptée à l'écran du visiteur au lieu d'envoyer systématiquement le fichier le plus lourd. Le chargement différé, ou lazy loading, réduit le poids initial transféré en ne chargeant les images que lorsqu'elles approchent de la zone visible, mais avec une réserve technique importante : l'image qui sert de point de repère au LCP, généralement l'image principale visible sans défilement, ne doit jamais être différée, sous peine de dégrader à la fois le score de performance et, indirectement, le signal de classement lié à la vitesse.

Sur les polices, limiter le nombre de graisses chargées, sous-ensembler les caractères réellement utilisés et éviter de charger une bibliothèque d'icônes complète pour n'en afficher que trois réduisent le poids sans qu'aucun visiteur ne perçoive la différence. Sur les scripts, différer l'exécution de tout ce qui n'est pas nécessaire au premier rendu, et auditer régulièrement les scripts de mesure accumulés au fil des années, libèrent souvent plus de poids qu'une refonte complète des contenus.

• Convertir les images en WebP ou AVIF avec une compression adaptée au contexte d'affichage
• Utiliser srcset pour ne jamais envoyer une image plus grande que nécessaire
• Différer le chargement des images sous la ligne de flottaison, jamais celle qui constitue le LCP
• Sous-ensembler les polices web et limiter le nombre de graisses chargées
• Différer ou charger en asynchrone les scripts non indispensables au premier rendu
• Auditer les scripts tiers accumulés et retirer ceux dont personne ne consulte plus les données

Le texte et les données structurées ne pèsent presque rien : ne les sacrifiez pas

Un point passe souvent inaperçu dans les audits d'écoconception : le texte HTML, y compris les données structurées au format JSON-LD, représente une fraction minime du poids total d'une page, généralement de l'ordre de quelques kilo-octets, contre plusieurs centaines de kilo-octets, voire plusieurs méga-octets, pour les images, les scripts et les polices non optimisés. Raccourcir un contenu, retirer un bloc de FAQ ou supprimer un balisage schema pour répondre à une recommandation de sobriété déplace donc à peine l'aiguille du poids de la page, tout en retirant des éléments qui comptent lourdement pour le référencement, la FAQ pour répondre aux questions des internautes, le balisage pour la compréhension du contenu par les moteurs.

Le maillage interne suit la même logique. Un ensemble de liens internes pertinents ajoute quelques centaines d'octets à une page, un montant négligeable au regard du poids total, alors qu'il reste l'un des signaux les plus déterminants pour la découverte des pages par les robots d'exploration et pour la répartition de l'autorité thématique entre elles. Réduire volontairement le nombre de liens internes pour simplifier une page économise un poids marginal tout en abîmant la structure du site, ce qui va d'ailleurs à l'encontre des critères d'expérience utilisateur que le RGESN lui-même valorise.

Le principe général qui s'en dégage est cohérent avec l'esprit même de l'écoconception, bien appliqué : cibler les éléments réellement lourds, pas les éléments les moins coûteux à retirer parce qu'ils sont visibles dans un audit rapide.

Mesurer sans se fier à un chiffre unique

Un audit d'écoconception produit généralement trois types de mesures qu'il est tentant de confondre : le poids de la page en kilo-octets, un score de performance calculé par un outil comme Lighthouse, et une estimation de l'empreinte carbone par visite. Les deux premières mesures reposent sur des éléments directement observables et reproductibles. La troisième dépend d'hypothèses qui varient d'un outil à l'autre : le mix énergétique supposé du pays d'hébergement, le type d'appareil et de réseau utilisé par un visiteur type, l'efficacité énergétique présumée du centre de données. Deux calculateurs d'empreinte carbone appliqués à la même page peuvent produire des résultats différents, non parce que l'un se trompe, mais parce qu'ils ne posent pas les mêmes hypothèses de départ.

La conséquence pratique pour un professionnel du référencement est simple : traiter le chiffre d'empreinte carbone qu'un outil affiche comme une estimation directionnelle, utile pour suivre l'évolution du même site dans le temps, et non comme une donnée absolue à comparer d'un site à l'autre ou à citer comme une vérité mesurée. Reprendre un tel chiffre dans une communication externe en le présentant comme une donnée établie reviendrait à afficher une précision que l'outil lui-même ne revendique pas.

Le choix d'un hébergeur fonctionnant à l'énergie renouvelable ou affichant une bonne efficacité énergétique répond, lui, à un critère RGESN à part entière, et il est légitime de le rechercher pour cette raison. Mais il n'a aucun effet mécanique connu sur le classement : rien n'indique que Google dispose d'un signal fondé sur la source d'énergie d'un hébergeur, et présenter ce choix comme un levier SEO reviendrait à lui prêter un effet qu'il n'a pas. C'est une bonne pratique environnementale à défendre pour ce qu'elle est, sans avoir besoin de lui inventer un bénéfice de classement.

Une méthode d'arbitrage, page par page

Face à une recommandation d'écoconception donnée, la question qui tranche presque toujours entre compatible et risqué pour le référencement est celle-ci : cette recommandation cible-t-elle le poids d'un élément, ou sa présence même. Une recommandation qui cible le poids, compresser, reformater, mettre en cache, différer ce qui n'est pas critique, se traite pratiquement toujours sans risque pour le classement. Une recommandation qui cible la présence, supprimer des images, raccourcir un contenu, retirer une fonctionnalité, mérite un examen au cas par cas avant d'être appliquée.

Avant d'agir sur une page qui génère du trafic organique, il vaut la peine de vérifier ce que cette page rapporte réellement, en position, en trafic, en conversions, avant de retirer un élément au nom d'un objectif de poids. Un contenu ou un visuel qui ne joue aucun rôle mesurable peut être retiré sans regret ; un contenu qui contribue au classement de la page méritait d'être optimisé plutôt que supprimé, quitte à accepter que le gain de poids soit plus modeste que ce que suggérait l'audit initial.

• Commencer par identifier les éléments les plus lourds de la page avant toute décision, plutôt que de deviner
• Privilégier systématiquement la compression, le bon format et la mise en cache avant d'envisager une suppression
• Ne jamais retirer du texte, du balisage schema ou des liens internes au nom du poids, ils pèsent trop peu pour le justifier
• Vérifier la performance actuelle d'une page avant de supprimer un contenu ou un visuel qui y contribue
• Traiter toute estimation d'empreinte carbone comme une tendance à suivre, pas comme un chiffre à comparer entre sites
• Remesurer les Core Web Vitals après chaque changement, pas seulement le poids total de la page