L’éco-conception
chez MobileThinking

Langages et Frameworks

12.08.2025

Quatrième défi : réduire l’impact en posant le meilleur cadre technique

Et si choisir un autre langage ou framework pouvait faire toute la différence ?

C’est ce qu’ont voulu vérifier Jules et Jérôme, en décidant de regarder ce qu’il se passe sous le capot, là où les choix techniques influencent (vraiment) la consommation.

Leur objectif : comparer les langages et frameworks les plus utilisés chez nous (et dans le monde) pour identifier ceux qui consomment le moins… et repenser nos choix techniques à en fonction de leur impact environnemental.

Un peu comme quand on choisit un frigo ou une machine à laver : à usage égal, certains consomment bien plus que d’autres. Alors pourquoi ne pas appliquer le même raisonnement à notre code ?

Constat initial 🔎

En tant que boîte spécialisée dans le développement web, on utilise plusieurs langages et frameworks selon les projets.

On les choisit souvent pour des raisons de performance, de productivité ou de préférence.

Mais on ne s’était jamais vraiment demandé lequel consommait le moins d’énergie. Et pourtant, il y a de grandes chances que certains soient bien plus gourmands que d’autres.

Alors la question s’est posée : et si on intégrait ce critère-là dans nos choix techniques ? Est-ce qu’on devrait, à l’avenir, privilégier un framework plutôt qu’un autre si son impact environnemental est significativement plus faible ?

Pour y voir plus clair, notre duo de choc a décidé de tester et comparer la consommation réelle de quelques-uns des frameworks les plus populaires.

Les problématiques identifiées 🤔

Au fil de la matinée, plusieurs questions concrètes sont apparues :
  • Est-ce que les frameworks les plus populaires sont aussi les plus sobres ?
  • Peut-on vraiment mesurer l’impact énergétique d’un appel API complexe, avec base de données, logique métier, sérialisation ?
  • Et côté frontend : dans quelle mesure les résultats sont biaisés par l’ordinateur, le système d’exploitation, ou même le navigateur utilisé ? 
Autrement dit, mesurer c’est bien… mais comparer à armes égales, c’est un vrai défi.

Ce qu’on a testé 🧪

Pour objectiver les écarts de consommation, Jules et Jérôme ont mis en place un protocole de test simple mais représentatif d’un usage réel.

👉 Côté backend, ils ont simulé une requête GET classique dans nos API :
  • Passage dans un middleware d’authentification
  • Requête vers la base de données
  • Sérialisation des données (profil utilisateur + liste de livres associés) 
Le tout mesuré avec Scaphandre, un outil open-source permettant d’estimer la consommation énergétique en microjoules (µJ). → Chaque framework a été testé sur 200 requêtes, dans les mêmes conditions.

👉 Côté frontend, ils ont comparé les frameworks les plus utilisés (Vue.js 3, React, Angular) à partir d’estimations de consommation annuelle, tout en tenant compte des limites liées au matériel (OS, navigateur, machine, etc.).

Résultats 📊

Backend

➡️ Résultat flagrant : un même traitement peut consommer 28 fois plus d’énergie selon le framework utilisé.

Frontend

➡️ Là aussi, les écarts sont significatifs : Vue.js est le plus sobre des trois, Angular le plus énergivore.

Nos pistes d’amélioration

Ce défi a permis d’identifier plusieurs leviers pour la suite :
  • Réduire l’impact de la sérialisation JSON, souvent sous-estimée mais énergivore.
  • Documenter les résultats et construire une base de comparaison interne.
  • Intégrer la notion de consommation énergétique dans nos critères de choix technique, au même titre que la maintenabilité ou la rapidité de dev.
  • Créer un protocole de test standardisé pour pouvoir benchmarker facilement à chaque nouveau projet.

Ce qu’on retient

  • Tous les frameworks ne se valent pas : certains consomment bien plus que d’autres pour un résultat identique.
  • Ces écarts ont un impact concret, projet après projet, requête après requête.
  • Le frontend reste difficile à comparer objectivement, mais des tendances nettes émergent (Vue.js plus sobre que React ou Angular).
  • Avec des outils comme Scaphandre, il est possible de mesurer, comparer, et décider en conscience.

À suivre… ✨

Les défis se sont enchaînés : alléger les images, mieux répartir les traitements, revoir notre architecture, et enfin… choisir les technos les plus sobres.

Chaque équipe a mis sa pierre à l’édifice, tout le monde a pu tester, bidouiller et s’étonner. Et ce qu’on pensait être de simples ajustements techniques… se sont transformés en prise de conscience collective.

Maintenant qu’on a les cartes en main, il reste une question : qu’est-ce qu’on en fait ?

👉 Réponse dans le prochain et dernier épisode : de la réflexion collective… à une nouvelle façon de concevoir