Écoconception web : les choix concrets pour un site plus sobre et durable

Une vidéo se lance avant que le visiteur ait lu le titre. Une photographie destinée à une petite carte est téléchargée dans sa résolution d’origine. Un module de prise de rendez-vous charge ses scripts sur toutes les pages, alors qu’il n’apparaît que dans la rubrique contact. Ces décisions paraissent modestes. Additionnées, elles imposent des transferts et des traitements dont l’utilisateur n’a pas toujours besoin.

L’écoconception web consiste à examiner ces choix dès le cadrage, puis pendant la conception, le développement et la maintenance du service. Elle cherche à réduire ses impacts environnementaux sur l’ensemble de son cycle de vie, en tenant compte des équipements, des réseaux et des centres de données. Elle commence par une question simple : quel service devons-nous réellement rendre, et avec quelles ressources ?

Pour une PME, l’enjeu est de disposer d’un site utile, accessible et maintenable, capable de fonctionner dans les conditions réelles de ses visiteurs. Ce guide explique les arbitrages techniques à mener, les mesures à demander à son prestataire et la manière dont nous abordons ce travail chez Logiks. Les bonnes pratiques proposées ne valent ni certification environnementale ni promesse de réduction carbone.

1. Cadrer l’utilité et le périmètre avant d’optimiser

1.1. Trois repères à interpréter correctement

Le premier chiffre porte sur une année de référence, pas sur une mesure de 2026. Le deuxième décrit un référentiel de conception. Le troisième définit des seuils de qualité d’usage. Les additionner dans un prétendu « score vert » n’aurait aucun sens.

1.2. Partir d’une tâche que le visiteur doit accomplir

Prenons le site d’un cabinet de conseil. Un prospect doit comprendre l’offre, vérifier quelques références et demander un rendez-vous. Pour préparer le chantier, nous recommandons de décrire ces tâches avant de choisir un carrousel, une animation ou un agent conversationnel.

Pour chaque fonctionnalité, posez trois questions : quel besoin sert-elle ? Quelle solution plus simple répondrait au même besoin ? Que perdrait l’utilisateur si nous la retirions ? Un annuaire de quelques dizaines de références peut parfois fonctionner avec des filtres simples ; il n’a pas nécessairement besoin d’un moteur de recherche conversationnel. À l’inverse, retirer une recherche utile dans un catalogue volumineux peut allonger les parcours et déplacer la charge sur les utilisateurs.

Cet examen relève du responsable du service, avec les équipes métier, design et développement. Le responsable numérique ou RSE aide à intégrer les impacts environnementaux. Les organismes de standardisation fournissent des références ; ils ne prennent pas les décisions opérationnelles de votre projet.

1.3. Préserver ce qui fonctionne déjà

Une refonte complète n’est pas notre point de départ automatique. Sur un site existant, commencez par inventorier les gabarits, composants, médias, scripts et dépendances. Vérifiez si une intervention ciblée peut corriger le problème : réduire les ressources d’un modèle de page, supprimer un widget redondant ou améliorer la mise en cache.

La bonne décision dépend également de la sécurité et de la maintenabilité. Conserver un composant obsolète sans correctif pour éviter une migration peut créer un risque disproportionné. Inversement, remplacer un système fonctionnel par un nouvel empilement technique mobilise un travail et des ressources qu’il faut justifier. L’arbitrage doit expliciter ce que l’on garde, ce que l’on retire et ce que l’on reconstruit.

2. Alléger ce que le navigateur télécharge et exécute

2.1. Images : adapter le fichier à son usage réel

Le travail commence par le contenu : une image apporte-t-elle une information, une démonstration ou une fonction visuelle utile ? Ensuite viennent le cadrage, les dimensions, le format et la compression. Une image destinée à une vignette ne nécessite généralement pas le même fichier que son affichage plein écran.

On prépare plusieurs dimensions et on renseigne correctement srcset et sizes pour aider le navigateur à choisir une ressource adaptée. Les formats WebP ou AVIF peuvent être comparés aux formats existants à qualité visuelle acceptable, sans annoncer un taux universel de compression. Le résultat dépend notamment de l’image et de son encodage. web.dev : images adaptatives.

Le contrôle se fait dans l’onglet Réseau du navigateur : quel fichier a réellement été demandé sur mobile, et combien d’octets ont été transférés ? Vérifiez aussi la lisibilité des détails, la transparence et l’absence de recadrage gênant. Un export léger mais inutilisable ne remplit pas le besoin.

2.2. Chargement différé : choisir ce qui peut attendre

Les images situées plus bas dans la page peuvent être chargées à l’approche de l’écran. Ce chargement différé, ou lazy loading, évite certains téléchargements si le visiteur ne descend jamais jusque-là. Il ne supprime pas le coût des images effectivement consultées.

L’image principale visible dès l’arrivée mérite un traitement différent. Si elle constitue le plus grand élément affiché, retarder son chargement peut dégrader le LCP. Google recommande de rendre cette ressource découvrable tôt et de ne pas la charger paresseusement. Une priorité élevée peut être pertinente pour cette image ; la donner à toutes les images annulerait l’intérêt de la hiérarchisation. web.dev : optimiser le LCP.

2.3. Vidéos : laisser le visiteur décider

Pour une démonstration produit, une image d’aperçu et un bouton de lecture peuvent remplacer un lecteur chargé immédiatement. Pour une vidéo native qui ne démarre pas automatiquement, preload="none" indique au navigateur de ne pas précharger le média ; son comportement doit néanmoins être vérifié sur les navigateurs ciblés.

Un lecteur tiers peut, lui aussi, être initialisé après une action du visiteur. Il faut alors conserver une commande accessible au clavier, prévoir les sous-titres nécessaires et tester le consentement lorsque des traceurs sont concernés. Le gain porte sur les chargements évités avant lecture, pas sur une vidéo devenue sans impact. web.dev : chargement des vidéos.

2.4. JavaScript et services tiers : charger au bon endroit

Dressez la liste des outils ajoutés au site : statistiques, publicité, chat, cartes, avis, réservation, tests marketing. Pour chacun, nommez un responsable et les pages où sa présence est nécessaire. Un formulaire de contact n’a pas forcément besoin de charger le même ensemble de scripts que l’espace client.

Le JavaScript ne se contente pas d’être téléchargé : il doit être analysé et exécuté. Différer un script améliore parfois le moment où il intervient, mais ne supprime pas son travail. Pour réduire la charge, examinez d’abord les outils inutilisés, les doublons et les fonctionnalités que le navigateur fournit déjà. Les dépendances conservées peuvent être chargées à la demande ou seulement sur les pages concernées. web.dev : maîtriser le JavaScript tiers.

Après suppression ou report d’un outil, testez ce qu’il servait à faire. Une page plus légère qui ne permet plus d’envoyer le formulaire ou de finaliser une commande est une régression.

2.5. Polices : conserver l’identité sans multiplier les variantes

Une identité graphique peut nécessiter plusieurs caractères, mais chaque famille, graisse ou jeu de glyphes doit avoir un usage. Commencez par supprimer les variantes jamais affichées. Comparez ensuite les fichiers réellement utilisés, y compris lorsque vous envisagez une police variable : un seul fichier n’est pas automatiquement plus léger que toutes les variantes nécessaires.

Le sous-ensemble de caractères doit couvrir les langues du site. Le mode d’affichage de la police et la police de remplacement doivent être testés pour préserver la lecture et éviter les déplacements de mise en page. Précharger toutes les polices peut concurrencer des ressources plus importantes. web.dev : bonnes pratiques pour les polices.

3. Réduire les traitements, les données et les ressources serveur

3.1. Mettre en cache ce qui peut être réutilisé

La mise en cache permet de réutiliser une réponse au lieu de la retransférer ou de la recalculer systématiquement. Distinguez le cache du navigateur, un cache partagé comme un CDN et les caches applicatifs : ils n’agissent pas au même endroit.

Des ressources statiques versionnées se prêtent à une conservation longue. Une information métier évolutive demande une stratégie de fraîcheur et d’invalidation. Les pages authentifiées ou personnalisées exigent une attention particulière : une réponse destinée à un client ne doit pas être diffusée par erreur à d’autres utilisateurs. MDN : fonctionnement et contrôle du cache HTTP.

Le test comporte donc deux questions : la deuxième visite réutilise-t-elle bien les ressources prévues ? Une modification de contenu, de droits ou de données apparaît-elle au moment attendu ?

3.2. Éviter les appels et les calculs sans utilité

Pour le backend, notre recommandation est de partir des traces de la tâche réelle. Une page appelle-t-elle plusieurs fois la même donnée ? Télécharge-t-elle un catalogue complet pour afficher une sélection ? Relance-t-elle un calcul identique à chaque rafraîchissement ?

Les réponses possibles sont différentes : pagination, limitation des champs retournés, cache applicatif, regroupement de requêtes ou calcul à une fréquence adaptée au besoin. Un tableau mis à jour chaque seconde n’est pertinent que si une décision exige cette fraîcheur. Pour une application existante, une modification doit être validée avec l’équipe métier : optimiser une requête en retirant une information utile ne constitue pas un progrès.

La même logique vaut pour l’IA. Réservez une génération ou une analyse à ce qu’elle apporte réellement. Une FAQ stable peut parfois répondre sans inférence à chaque consultation. Le choix dépend du besoin et doit être testé ; il ne permet pas d’annoncer une économie énergétique chiffrée sans mesure.

3.3. Organiser la conservation plutôt qu’accumuler par défaut

Les journaux, exports, médias anciens et environnements temporaires ont besoin d’un cycle de vie. Identifiez leur utilité, leur propriétaire et leur durée de conservation. Distinguez ce qui reste actif, ce qui doit être archivé et ce qui peut être supprimé.

Pour les données personnelles, la durée est déterminée selon la finalité et les obligations applicables. Elle ne se réduit pas à une règle générale du type « tout supprimer après un an ». Les sauvegardes et les exigences de sécurité doivent également être prises en compte. CNIL : durées de conservation.

Le nettoyage proposé dans un chantier d’écoconception doit donc être validé avec les responsables des données. Une réduction de stockage qui détruit une preuve nécessaire, une archive obligatoire ou la capacité de restauration serait une mauvaise décision.

3.4. Choisir l’hébergement sur des éléments vérifiables

La localisation, la transparence du fournisseur, les équipements mobilisés et le dimensionnement du service méritent d’être examinés ensemble. Une offre hébergée en France peut répondre à un objectif de souveraineté ; cette localisation ne suffit pas à démontrer sa supériorité environnementale.

Demandez ce qui est mesuré, sur quel périmètre et selon quelle méthode. Vérifiez également la capacité choisie : un environnement surdimensionné ou un serveur de test laissé actif sans usage restent des pistes d’examen. La spécification SCI rappelle que le calcul énergétique doit considérer les ressources réservées ou provisionnées, pas seulement le travail utile observé. Green Software Foundation : spécification SCI.

4. Faire durer le service sur des équipements modestes

Un service qui devient inutilisable sur des équipements encore fonctionnels contribue à leur obsolescence d’usage. Le RGESN intègre précisément la compatibilité avec des terminaux anciens et l’allongement de la durée de vie des équipements parmi ses objectifs. Il ne s’agit pas de demander aux visiteurs de conserver un appareil dont la sécurité n’est plus assurée.

Définissez une matrice de tests adaptée au public : téléphones de gamme modeste, tailles d’écran, navigateurs pris en charge et connexions contraintes. Une simulation de processeur lent dans un navigateur de développement aide à repérer des problèmes ; elle ne reproduit pas parfaitement un appareil réel.

L’accessibilité complète cet examen. Une interface légère peut rester inutilisable au clavier, avec un lecteur d’écran ou lorsque le texte est agrandi. À l’inverse, retirer les alternatives textuelles, les sous-titres ou les informations nécessaires au nom de la sobriété exclurait des utilisateurs. Le W3C recommande de combiner outils et évaluation humaine : aucun outil seul ne peut déterminer toute l’accessibilité d’un service. W3C WAI : évaluer l’accessibilité.

Dans la recette, suivez une tâche entière : trouver un service, lire une référence, remplir le formulaire et comprendre la confirmation. Notez les blocages, les délais perceptibles et les contenus qui obligent à revenir en arrière. Cette observation révèle parfois une optimisation plus utile qu’une suppression marginale d’octets.

5. Mesurer les progrès sans inventer un bilan carbone

5.1. Comparer le même parcours dans les mêmes conditions

Avant modification, choisissez un petit ensemble représentatif : accueil, page service, article, formulaire, recherche ou espace client selon le projet. Définissez aussi la séquence d’actions et le point où la mesure s’arrête. Sinon, deux tests peuvent simplement avoir téléchargé des contenus différents.

Dans Chrome DevTools, l’onglet Réseau permet notamment d’observer les requêtes et les volumes transférés. Le cache peut être désactivé pour étudier une première visite. Faites aussi un passage avec cache, et notez les conditions de connexion, l’appareil, la version testée et l’état du consentement. Chrome DevTools : référence du panneau Réseau.

Répétez les passages et conservez leur dispersion. Pour analyser un script qui bloque une interaction, examinez sa trace d’exécution ; pour une consommation serveur, utilisez les mesures d’infrastructure disponibles. Un poids de page, un temps CPU, une facture cloud et un score Lighthouse répondent à des questions différentes.

5.2. Exemple pédagogique : alléger une page de prise de contact

Les données suivantes sont fictives. Elles illustrent un calcul de transferts, pas un résultat client Logiks. On suppose le même contenu utile, une première visite sans cache et une mesure arrêtée au même point. Les volumes sont exprimés en mégaoctets décimaux transférés.

Pour 20 000 chargements identiques sans cache, ces hypothèses donnent 64 Go avant et 19 Go après, soit 45 Go de transferts évités. Le calcul utilise 1 Go = 1 000 Mo. En production, le cache, les interactions, les appareils et le trafic réel modifieraient ce résultat.

On ne peut pas conclure « 70,3 % de CO₂ en moins ». Les équipements, le réseau, l’infrastructure et leurs consommations ne varient pas nécessairement dans la même proportion. Une évaluation carbone suppose de définir le périmètre, l’énergie, les facteurs d’émission et, selon la méthode, une part des émissions de fabrication. La SCI rapporte ainsi les émissions à une unité fonctionnelle ; elle ne couvre pas à elle seule tous les impacts environnementaux.

La variante doit enfin réussir les mêmes tâches : formulaire envoyé, informations compréhensibles, affichage correct et accessibilité préservée. Ce sont les conditions de son adoption, pas des détails reportés à plus tard.

5.3. Publier une affirmation proportionnée à la mesure

Une formulation utile serait : « Sur les parcours testés, le volume transféré lors d’une première visite diminue de X %, dans les conditions décrites. » Le X est remplacé uniquement après une mesure réelle, accompagnée de sa date et de son périmètre.

Le score d’avancement du RGESN mesure la mise en œuvre de critères applicables ; ce n’est pas un calcul d’impact. L’Arcep précise que sa publication doit être accompagnée d’une déclaration d’écoconception. Un score de performance ou l’achat d’un hébergement ne suffisent donc pas à qualifier un service de « neutre » ou de « zéro impact ».

6. Comment Logiks conduit ce travail en développement web

Notre présentation du cabinet décrit une approche fondée sur le code optimisé, les ressources compressées, le chargement de l’essentiel et des choix d’infrastructure attentifs à la souveraineté. Notre offre de développement web comprend l’architecture, l’optimisation technique, l’accessibilité, l’hébergement et la maintenance.

Pour un chantier d’écoconception, nous recommandons de traduire cette approche dans un périmètre convenu avec le client. Les contrôles ci-dessous constituent une proposition de travail à adapter ; ils ne signifient pas qu’un audit complet RGESN ou une analyse de cycle de vie serait inclus dans toute prestation.

6.1. Du diagnostic à une liste de décisions

On commence par les parcours utiles et les dépendances qui les servent. Le livrable attendu est un état initial lisible : ressources transférées, traitements identifiés, contraintes de maintenance, difficultés d’usage et limites des mesures. Chaque recommandation doit indiquer le composant concerné, le bénéfice recherché, l’effort estimé et le test de non-régression.

Pour prioriser, nous regarderions d’abord les ressources manifestement inutiles et les défauts répétés sur de nombreuses pages. Ensuite viennent les optimisations demandant un arbitrage métier : vidéo, recherche, outil tiers, fraîcheur des données ou reconstruction d’un composant. La direction tranche l’utilité ; l’équipe technique propose et vérifie la solution.

6.2. Une recette qui survit à la livraison

La maintenance compte autant que le premier nettoyage. Si les contributeurs peuvent remettre une vidéo automatique ou une image originale volumineuse sans contrôle, le bénéfice disparaît. Le brief de livraison doit préciser les formats autorisés, les dimensions attendues, les dépendances approuvées et les personnes habilitées à modifier ces choix.

Pour préparer un échange avec votre prestataire, demandez un audit technique web portant sur des parcours nommés. Complétez-le, selon le besoin, par l’examen de l’accessibilité du service et de la gouvernance des données.

7. Les questions à trancher avant de lancer le chantier

7.1. Faut-il changer de CMS pour écoconcevoir un site ?

Pas systématiquement. Commencez par les contenus, les médias, les scripts, le thème ou les composants et l’hébergement. Un changement de CMS se justifie si les limites de l’existant empêchent durablement les objectifs de sécurité, d’usage ou de maintenance. Comparez les possibilités sur une page représentative avant d’engager une migration.

7.2. Un site rapide est-il forcément écoconçu ?

Non. Il peut charger rapidement beaucoup de données sur un appareil puissant, multiplier des traitements serveur ou solliciter des services inutiles. La performance reste un contrôle utile. L’écoconception examine aussi l’utilité, le cycle de vie, les ressources mobilisées et les effets du service.

7.3. Peut-on promettre un pourcentage de réduction avant l’audit ?

On peut proposer un objectif de travail, pas présenter un résultat comme acquis. Le gain dépend du point de départ et des contraintes. Définissez les indicateurs mesurés, puis distinguez les résultats techniques obtenus des estimations environnementales éventuelles.

7.4. Doit-on supprimer les vidéos, animations et fonctionnalités IA ?

Aucune de ces catégories ne doit être jugée par son seul nom. Évaluez son utilité, sa fréquence d’usage, son coût technique et les alternatives. Une démonstration vidéo demandée par le visiteur peut être justifiée ; une vidéo décorative préchargée sur toutes les pages appelle un autre arbitrage.

7.5. Par quoi commencer cette semaine ?

Choisissez un parcours important. Observez ses ressources et ses traitements, puis identifiez un élément dont l’utilité ne peut pas être expliquée. Testez sa suppression ou son chargement à la demande, comparez les mesures et faites accomplir la même tâche à un utilisateur. Vous disposerez d’une première décision concrète et documentée pour organiser la suite.

8. Sources et références

Sources primaires et documentation consultées le 16 septembre 2026. Les chiffres nationaux conservent leur année de référence ; les tableaux de scénario sont explicitement fictifs.

• ADEME, impact environnemental du numérique en France en 2022, publication janvier 2025 : chiffres et périmètre, p. 3 (PDF).
• Arcep / Arcom, RGESN, édition du 17 mai 2024 : 78 critères et déclaration d’écoconception.
• Google web.dev, Core Web Vitals et seuils d’expérience.
• Google web.dev, images adaptatives : srcset, sizes et picture.
• Google web.dev, optimisation du Largest Contentful Paint.
• Google web.dev, chargement des vidéos, mise à jour du 2 juillet 2026.
• Google web.dev, chargement du JavaScript tiers.
• Google web.dev, bonnes pratiques de chargement des polices.
• MDN, cache HTTP et directives de contrôle.
• CNIL, durées de conservation des données personnelles.
• W3C WAI, évaluation de l’accessibilité web.
• Chrome for Developers, panneau Réseau de DevTools.
• Green Software Foundation, Software Carbon Intensity Specification.