Dans mon premier article sur la performance, l’accessibilité et l’écoconception, nous avions conclu que concilier ces trois piliers n’est pas toujours possible à 100 %, mais des arbitrages éclairés permettent de tendre vers un web plus responsable.
Encore faut-il savoir où agir.
Et c’est précisément ce que révèle l’examen de la dette technique web : un angle mort écologique, souvent invisible dans les décisions projet.
Comprendre les liens entre dette technique et impact carbone
La dette technique ne se limite plus au delivery
Traditionnellement, la dette technique est envisagée comme une accumulation de raccourcis ou de choix techniques discutables faits au cours d’un projet pour gagner du temps à court terme mais qui engendrent une charge de maintenance, de correction ou de refonte à long terme.
Elle peut se manifester sous différentes formes :
- Code dupliqué, non documenté ou peu lisible,
- Choix de frameworks ou bibliothèques surdimensionnés par rapport aux besoins,
- Fonctionnalités mal implémentées ou non testées,
- Dépendances obsolètes, scripts inutiles, architecture rigide.
Aujourd’hui, il faut aussi lui reconnaître un coût énergétique. En effet, celle-ci peut correspond à l’accumulation de complexité logicielle inutile (code mort, scripts non optimisés, surarchitecture), qui alourdit les pages, ralentit l’usage, mobilise plus de ressources et augmente donc l’empreinte carbone du projet numérique.
Le poids caché des infrastructures numériques
Plus un site est complexe sans justification fonctionnelle claire, plus il sollicite intensément l’ensemble de la chaîne numérique. Chaque surcouche technique inutile, qu’il s’agisse de scripts lourds, de composants non utilisés ou d’architectures redondantes, se répercute à plusieurs niveaux :
- Côté utilisateur, le terminal doit mobiliser davantage de ressources matérielles (CPU, RAM, GPU) pour interpréter, afficher et maintenir en mémoire un contenu devenu inutilement complexe ;
- Côté réseau, le poids des pages, le nombre de requêtes et la multiplication des ressources embarquées augmentent significativement la bande passante consommée à chaque chargement ;
- Côté serveurs et infrastructures, les traitements côté backend, la gestion des fichiers, la réplication via les CDN et le stockage à long terme génèrent une activité constante qui sollicite matériel, refroidissement et énergie.
Autrement dit, la dette technique ne reste pas confinée au code : elle se diffuse dans toute la chaîne d’exécution. Et avec elle, une part évitable de l’empreinte carbone numérique du projet que l’on ne peut plus se permettre d’ignorer dans une démarche d’écoconception cohérente.
Quand la complexité devient un facteur d’émissions
Des outils puissants… souvent disproportionnés
Les frameworks JavaScript comme React, Vue ou Angular sont devenus des standards du développement web moderne. Ils permettent de construire des interfaces riches, interactives, capables de se mettre à jour en temps réel sans recharger la page. Ils sont très utiles pour des applications complexes : services en ligne, plateformes collaboratives, tableaux de bord, etc.
Mais dans de nombreux projets notamment des sites vitrines, des pages éditoriales ou des interfaces sans interactions avancées, leur utilisation n’est pas justifiée. Ces frameworks chargent automatiquement des centaines de kilo-octets de code, même si le site n’en a pas besoin. Le navigateur de l’utilisateur doit tout télécharger, analyser et exécuter, ce qui ralentit l’affichage, mobilise de l’énergie, et alourdit l’empreinte carbone du site, sans valeur ajoutée réelle.
Des CMS alourdis par une accumulation de plugins
Les CMS comme WordPress sont conçus pour être flexibles. Grâce aux plugins, on peut ajouter facilement des fonctionnalités : formulaire, slider, SEO, analytics, etc. Mais cette souplesse devient vite un piège. Au fil du temps, les plugins s’accumulent, parfois en doublon, souvent mal configurés, sans réelle stratégie d’optimisation.
Résultat : chaque page du site charge des scripts inutiles, multiplie les requêtes, et intègre des éléments techniques souvent peu visibles côté utilisateur, mais très coûteux côté performance et environnement. Ces couches superflues rendent aussi le site plus fragile, plus difficile à maintenir, et donc plus susceptible de produire une dette technique qui s’amplifie avec le temps.
Des architectures complexes pour des besoins simples
Dans une logique d’industrialisation du développement, beaucoup de projets adoptent des architectures dites “découplées” ou “headless”, où le système de gestion de contenu est séparé du site lui-même. Les deux communiquent via des API, sortes de ponts techniques qui transmettent les données en temps réel.
Ce modèle est pertinent pour les sites multisupports, les applications évolutives ou les plateformes fortement personnalisées. Mais il est souvent mis en œuvre même quand les besoins ne le justifient pas.
Conséquence : chaque page affichée entraîne plusieurs appels réseau, des traitements répartis sur plusieurs services, et une logique de fonctionnement bien plus lourde que nécessaire. Ce surplus de complexité technique génère des lenteurs, des bugs, des surcoûts d’infrastructure et une pollution numérique évitable.
Le code mort : une pollution silencieuse mais persistante
Dernier facteur d’impact souvent négligé : le code mort. Il s’agit de portions de code qui ne sont plus utilisées, mais qui sont toujours présentes dans le projet. Par exemple, des feuilles de style associées à d’anciens composants, des fonctions JavaScript inutilisées, ou des scripts tiers laissés en place « au cas où ».
Ce code n’apporte rien à l’expérience utilisateur, mais il est tout de même chargé, interprété, stocké, mis en cache à chaque visite (consiste à mémoriser temporairement les données pour éviter de les recharger à chaque fois), sur chaque page. Il alourdit le site de façon invisible, dégrade les performances, et participe à la dette technique cumulative.
"La dette technique ne reste pas confinée au code : elle se diffuse dans toute la chaîne d’exécution."
Mesurer pour mieux agir
Voir au-delà de la performance perçue
Optimiser un site web en faveur de l’écoconception nécessite plus qu’un bon score Lighthouse. Si les outils de performance traditionnels (comme Lighthouse, ou WebPageTest) évaluent la vitesse, le poids et la fluidité, ils restent centrés sur l’expérience utilisateur. Ils ne mesurent ni la consommation énergétique réelle, ni l’impact environnemental global du parcours numérique.
Pour cela, il est essentiel de s’appuyer sur des outils spécifiquement conçus pour évaluer l’empreinte carbone du web.
- EcoIndex: un indicateur rapide basé sur le poids des ressources, le nombre de requêtes et la complexité DOM. Il fournit un score global (A à G) et une estimation des émissions de CO₂ par page ;
- GreenIT Analysis : une solution d’analyse plus détaillée, qui estime l’impact d’un site web sur l’ensemble du cycle de vie numérique, en tenant compte du réseau, du terminal et de l’infrastructure ;
- GreenFram.io : cet outil simule desparcours utilisateurs réels pour calculer les émissions générées à chaque interaction. Il permet d’identifier les points de friction ou d’optimisation en situation d’usage ;
- Fruggr: une plateforme SaaS complète, intégrée dans une logique RSE/IT responsable. Elle analyse l’impact carbone mais aussi l’accessibilité, la diversité des usages, la conformité, avec des KPI actionnables pour les équipes produit, design et tech.
Croiser les audits pour piloter intelligemment
Ces outils ne remplacent pas les audits techniques, SEO ou UX classiques. Mais ils en élargissent le périmètre, en intégrant des critères environnementaux objectifs, aujourd’hui absents de la majorité des livrables digitaux.
En croisant les données de performance (LCP, TTI, TBT) avec celles d’impact (gCO₂, consommation électrique, nombre de requêtes inutiles), on peut prioriser les optimisations selon leur bénéfice réel pour l’utilisateur, mais aussi pour la planète.
Comprendre les indicateurs LCP, TTI et TBT
Pour évaluer la performance réelle d’un site, certains indicateurs techniques sont devenus des références. Ils sont au cœur des outils comme Lighthouse, PageSpeed Insights ou WebPageTest. Voici les trois principaux à connaître, et ce qu’ils disent de l’expérience utilisateur… mais aussi de l’efficacité énergétique du site.
- LCP – Largest Contentful Paint : Mesure le temps nécessaire pour afficher l’élément principal visible à l’écran (ex. : image de héros, titre, vidéo). Un bon LCP garantit une sensation de rapidité. Objectif : < 2,5 secondes
- TTI – Time to Interactive. Mesure le moment où la page devient pleinement interactive (clics, scrolls, formulaires). Une page qui s’affiche vite mais reste inutilisable est perçue comme lente. Objectif : < 5 secondes
- TBT – Total Blocking Time. Additionne les périodes pendant lesquelles le navigateur est bloqué par des scripts lourds ou longs à exécuter. Un TBT élevé = une page saccadée ou figée. Objectif : < 200 ms
Ces indicateurs ne mesurent pas directement l’impact carbone… mais ils sont souvent liés : plus un site est rapide et fluide, moins il sollicite les ressources matérielles et réseau. À condition bien sûr que cette performance ne soit pas obtenue au prix d’un excès technologique
Concevoir un socle plus sobre dès l’architecture
L’écoconception d’un site web ne se joue pas uniquement dans l’optimisation des images ou la réduction du poids des pages. Elle commence bien plus tôt, au moment de choisir le socle technique. Car c’est dans l’architecture elle-même que se construisent, ou se préservent, les marges de sobriété.
Choisir des technologies plus légères
Les générateurs de sites statiques (comme Astro, Eleventy ou Hugo) permettent de construire des sites web dont le contenu est précompilé en pages HTML avant même d’être mis en ligne. Cela signifie que lorsque l’utilisateur consulte le site, il reçoit directement une page prête à l’emploi, sans qu’aucun traitement ne soit nécessaire côté serveur.
Cette approche présente plusieurs avantages :
- Un temps de chargement très court, car aucun calcul n’est effectué à la volée.
- Un code final plus léger, sans scripts superflus.
- Une architecture plus simple, plus facile à sécuriser et à héberger.
Le poids caché des CMS dynamiques
À l’inverse, des CMS classiques comme WordPress, Drupal ou Joomla génèrent le contenu des pages à la demande. À chaque visite, le serveur interroge une base de données, assemble le contenu, puis le renvoie à l’utilisateur. Ce fonctionnement est plus flexible, surtout pour des sites complexes ou fréquemment mis à jour, mais il est aussi plus lourd en termes de traitement, de ressources et de maintenance.
Utiliser un CMS dynamique pour un petit site vitrine qui évolue peu, peut fonctionner mais le coût en infrastructure et en impact carbone est rarement justifié.
Adopter une philosophie de lean code
La sobriété ne dépend pas uniquement des outils utilisés, mais aussi de la manière de les exploiter. C’est tout l’enjeu de la démarche dite de lean code.
Par analogie avec le lean management en industrie, le lean code vise à :
- éliminer les éléments techniques superflus,
- optimiser chaque composant pour qu’il soit utilisé à bon escient,
- réduire les dépendances externes au strict nécessaire,
- documenter les choix techniques pour éviter les couches opaques ou redondantes.
Un code « lean », c’est un code plus clair, plus lisible, plus facilement maintenable. C’est aussi un code qui mobilise moins de ressources au chargement, au calcul, et à la maintenance et qui réduit mécaniquement l’empreinte écologique du projet.
Penser à long terme : lisibilité, évolutivité, durabilité
Un socle technique sobre n’est pas seulement plus performant aujourd’hui : il est plus facile à maintenir, à faire évoluer et à transmettre demain.
Moins de complexité signifie moins de bugs, moins de dépendances à surveiller, moins de ressources consommées. À l’échelle d’un cycle de vie complet, c’est aussi une réduction concrète de l’impact environnemental car un site que l’on peut faire durer est un site que l’on n’a pas besoin de refaire.
Intégrer la sobriété dans la gestion de projet
L’écoconception n’est pas qu’une affaire de code ou d’outillage technique. Elle s’inscrit dans la façon dont le projet est pensé, piloté et transmis. Intégrer une logique de sobriété numérique dès la gestion de projet permet d’aligner les décisions stratégiques, techniques et éditoriales tout au long du cycle de vie du site.
Dès le cadrage, poser les bons objectifs
- Combien de pages sont vraiment nécessaires ?
- Peut-on mutualiser les types de contenus ?
- Quels contenus seront pérennes ?
Ces réflexions de cadrage permettent de limiter les excès structurels, de réduire la dette éditoriale future, et d’optimiser les parcours sans surdimensionner le périmètre du projet.
Automatiser l’optimisation pendant la production
Une fois le projet lancé, les outils de production doivent eux aussi intégrer une logique d’écoconception. Cela passe notamment par :
- des scripts de nettoyage automatisé pour les ressources obsolètes, comme les CSS ou JS non utilisés ;
- des outils de minification pour réduire le poids des fichiers livrés ;
- la systématisation de tests de performance (LCP, TBT, EcoIndex…) en phase d’intégration continue et de déploiement ;
- la mise en place d’un monitoring post-livraison, pour suivre les dérives et corriger les excès en continu.
Ce sont autant de précautions techniques qui permettent de maintenir un niveau de sobriété constant, même sur des projets qui évoluent.
Diffuser une culture de la sobriété numérique
Enfin, la sobriété ne se décrète pas : elle se construit collectivement, dans les choix comme dans les usages. Cela implique de :
- former les équipes projet (design, développement, contenu) aux enjeux environnementaux du web ;
- sensibiliser les clients et les commanditaires pour qu’ils comprennent les arbitrages proposés ;
- poser un cadre clair pour les décisions techniques (avec des critères d’impact, pas seulement de coût ou de rapidité).
Cette culture partagée est essentielle pour inscrire l’écoconception dans la durée et pour éviter qu’elle ne reste un geste isolé dans un projet unique.
Une expertise proposée chez Adbeona
Un site à la fois performant, accessible et sobre ne repose pas sur une solution miracle. C’est le fruit d’un équilibre réfléchi, fondé sur des arbitrages structurants, posés dès le départ. (cf. cet article)
Mon rôle chez Adbeona, c’est justement de vous aider à faire ces choix en toute conscience. Je vous accompagne dès la phase de cadrage pour construire un socle clair, durable et utile, sans superflu.
Ma démarche combine :
- un cadrage stratégique rigoureux : objectifs réels, hiérarchie des contenus, structure fonctionnelle ;
- un design épuré mais exigeant, pensé pour servir l’usage avant tout ;
- le choix de technologies sobres, adaptées à vos besoins (et non l’inverse),
- une gestion de projet centrée sur l’impact : performance réelle, accessibilité native, contenu durable ;
- et une écoconception concrète et documentée, intégrée à chaque étape du projet.
Je conçois des sites plus intelligents, plus lisibles, plus responsables qui tiennent dans la durée, et qui servent vos objectifs sans surproduire.
