L’éco-conception
chez MobileThinking

Front ou Back ?

29.07.2025

Deuxième équipe, nouveau défi : mieux répartir les efforts

Dans l'épisode précédent, on s’attaquait aux images, vidéos et polices superflues pour rendre nos pages plus sobres.

Mais derrière chaque clic, chaque affichage, il y a aussi… des calculs.
Et ces calculs, ils se font quelque part.

📍 Parfois sur votre appareil (le front, côté navigateur)
🖥️ Parfois sur nos serveurs (le back, côté infrastructure)

Mais alors, où placer intelligemment les traitements pour réduire leur impact ?

Répondre à cette question ? C’est une mission taillée sur mesure pour Fabien et Jody, qui ont retroussé leurs manches pour mettre la lumière sur ces mécaniques invisibles. 

Constat initial 🔎

Chaque service numérique repose sur une série d’opérations : 
  • Rechercher une info
  • Trier des résultats
  • Transformer des données
  • Paginer une liste… 
Des actions quotidiennes dans nos projets, mais rarement questionnées sous l’angle de la sobriété numérique.

Et pourtant, selon où elles sont exécutées, la consommation énergétique peut varier du simple au double.

Les problématiques identifiées 🤔

Une des règles majeures de l’éco-conception : éviter les transferts inutiles.

Partant de ce postulat là, voici les principales questions étudiées par notre duo de choc :
  • À quel moment faut-il déléguer un traitement au serveur ?
  • Faut-il envoyer toutes les données d’un coup ou faire plusieurs requêtes ciblées ?
  • Quand la transformation est complexe, vaut-il mieux la gérer côté back ?
  • Comment peut-on mesurer l’impact réel de ces choix techniques ?

Ce qu’on a testé 🧪

L’équipe s’est appuyée sur un cas réel : la page “Projets” de notre site web.
  • Tests comparés d’envoi complet vs chargement progressif
  • Mesures du poids des réponses API
  • Tentatives d’analyse avec Lighthouse, WebPageTest et Scaphandre (encore peu concluantes à ce stade)
  • Revue des bonnes pratiques et retours d’expérience issus de projets similaires 

Nos pistes d’amélioration

🌿 Voici quelques premiers enseignements tirés de leurs tests :
  • Si le volume est faible et stable → traitement côté front
  • Si le volume est important, changeant ou difficilement contrôlable → traitement côté back
  • Mieux vaut plusieurs petites requêtes bien ciblées qu’une grosse réponse inutile
  • Les transformations complexes → back
  • Les ajustements simples → front
  • Et dès que possible : on met en cache !
💡 Cas concret : Grâce à l’ajout d’une ressource adaptée et au cache, la réponse API est passée de 85 kB à 38 kB → 55% plus légère, tout en chargeant plus de contenu.

Ce qu’on retient

Bien répartir les traitements entre le front et le back, ce n’est pas juste une question d’optimisation technique. C’est une démarche de sobriété, de responsabilité… et de lucidité sur ce qu’on fait circuler et calculer.

C’est se demander : “Est-ce que ce traitement est utile ici, ou est-ce que je le fais par habitude ?” Et si je peux en faire moins, tout en gardant la même qualité d’expérience… alors pourquoi s’en priver ?

À suivre… ✨

On sait maintenant comment optimiser les images, on sait mieux répartir les traitements entre le front et le back… mais le serveur ronronne encore trop fort.

C’est sûrement parce que tout ce qui se passe derrière le site, ça compte aussi !

Dans le prochain épisode, on explore l’envers du décor : 
  • Où sont stockées les données ?
  • Que se passe-t-il quand vous cliquez ?
  • Et comment rendre tout ça plus rapide et plus écologique ?
Spoiler : ce n’est pas réservé aux ingénieurs réseau 🐝