Je suis Adrien CHAUMARAT, développeur Symfony depuis 2014, basé dans les Ardennes. Sur la majorité de mes projets de SaaS sur mesure ou de logiciel métier sur mesure, la question écologique arrive en milieu de cadrage, presque toujours formulée comme : « Est-ce qu'on peut viser un produit sobre, sans dégrader l'expérience utilisateur ? » La réponse est oui, à condition d'en faire un critère structurant dès la conception et pas un vernis posé après coup. Cet article décrit la méthodologie ARDNTECH pour concevoir un SaaS bas carbone : mesure EcoIndex avant et après, optimisations techniques concrètes, choix d'hébergeur, écoconception fonctionnelle. C'est un guide opérationnel destiné aux éditeurs SaaS et aux PME qui veulent intégrer la sobriété numérique sans bullshit.
Qu'est-ce qu'un SaaS bas carbone en 2026
Un SaaS bas carbone est un service en ligne dont l'empreinte environnementale est mesurée, optimisée et documentée à toutes les étapes du cycle de vie : conception, développement, hébergement, usage, maintenance. La définition n'est pas normative au sens d'un référentiel ISO, mais elle s'appuie sur trois axes concrets : la sobriété fonctionnelle (ne développer que ce qui est utile), la performance technique (consommer le moins de ressources possible par fonctionnalité), et l'hébergement vert (faire tourner l'infrastructure sur de l'énergie bas carbone).
La documentation de l'Arcep sur l'empreinte environnementale du numérique rappelle que le secteur représente environ 2,5 % de l'empreinte carbone française, en augmentation continue. Pour un éditeur SaaS, agir sur cette empreinte n'est plus un sujet militant, c'est un sujet produit et commercial. Les directions achats des grands comptes commencent à intégrer des critères RSE dans leurs appels d'offres, et la pression réglementaire (CSRD à partir de 2026 pour les ETI) renforce cette tendance.
La distinction conception vs hébergement
On confond souvent SaaS bas carbone avec « SaaS hébergé chez un acteur vert ». L'hébergement vert est nécessaire mais largement insuffisant. La majorité de l'empreinte d'un SaaS vient en réalité de trois sources : le code exécuté côté serveur (CPU, mémoire, requêtes BDD), le poids des données transférées au navigateur de l'utilisateur (assets, HTML, JSON), et la consommation côté terminal (CPU navigateur, rendu graphique). Optimiser uniquement l'hébergement, c'est traiter 20 à 30 % du problème en laissant 70 % de côté.
Mesurer avant d'optimiser : EcoIndex et autres outils
La règle de base de toute démarche d'optimisation : mesurer avant, mesurer après, comparer. Sans mesure objective, vous risquez de gaspiller des jours de développement sur des optimisations marginales en ignorant les gros gisements. Pour un SaaS, deux outils suffisent à démarrer.
Le premier outil est EcoIndex, développé par le collectif GreenIT.fr. Il évalue une page web sur trois axes : complexité du DOM, nombre de requêtes HTTP, poids total transféré. Le score va de A (excellent) à G (très polluant) avec une estimation associée d'empreinte par visite (équivalent CO2, équivalent eau). L'outil est gratuit, en ligne, et reproductible : indispensable pour bâtir un référentiel.
Le second outil est Lighthouse de Google, intégré au navigateur Chrome. Il évalue les performances brutes (Core Web Vitals), l'accessibilité, le SEO et les bonnes pratiques. Si les performances brutes sont mauvaises, l'empreinte carbone l'est presque toujours aussi : un site lent consomme plus de CPU côté terminal, charge plus de ressources, et fait travailler plus longtemps les serveurs. Mon article Core Web Vitals SaaS Symfony détaille les seuils à atteindre.
Le protocole de mesure que j'applique
Sur chaque projet de refonte ou de nouveau SaaS, je mesure trois pages représentatives (page de connexion, écran principal après login, page de configuration la plus dense). Je relève l'EcoIndex et le score Lighthouse Performance avant les optimisations, puis je remesure après chaque jalon de refactoring. Cette discipline permet d'objectiver les gains et d'éviter les fausses optimisations qui dégradent un axe sans gain net sur l'autre.
Optimisations côté code serveur
Le code côté serveur consomme du CPU, de la mémoire et des entrées-sorties à chaque requête HTTP. La règle générale : plus une requête est rapide, moins elle consomme. L'optimisation serveur d'un SaaS bas carbone passe par cinq leviers principaux, classés par effort de mise en œuvre.
- Cache HTTP et HTTP/2 : un asset servi en cache local ou via un proxy ne consomme aucune ressource serveur. Implémenter correctement les en-têtes
Cache-Control,ETagetLast-Modifiedsur les assets statiques divise la charge serveur par deux ou trois sur un SaaS lambda. - Optimisation des requêtes BDD : la majorité des requêtes lentes d'un SaaS sont des requêtes Doctrine sous-optimales. Index manquants, jointures inutiles, N+1 queries non détectées, hydratation complète d'entités quand un DTO suffirait. Un profilage avec Blackfire ou Symfony Profiler en pré-production identifie les requêtes coûteuses.
- Cache applicatif Redis ou APCu : les calculs lourds (agrégations, statistiques, droits d'accès) gagnent à être mis en cache. Cinq lignes d'annotation Symfony peuvent diviser par dix les requêtes BDD sur un dashboard très consulté.
- Compression Gzip ou Brotli : activée par défaut sur Nginx et Apache modernes, à vérifier. Réduit le poids transféré de 60 à 80 % sur les contenus textuels (HTML, CSS, JS, JSON).
- Tâches asynchrones : tout traitement non bloquant (envoi d'emails, génération de rapports, calculs lourds) doit basculer en file d'attente Symfony Messenger plutôt que de bloquer une requête HTTP. Bénéfice : moins de connexions PHP-FPM simultanées, donc moins de RAM consommée.
Sur un projet d'éditeur SaaS de gestion documentaire pour cabinets de conseil pharma que j'accompagne, l'audit initial montrait des temps de réponse moyens autour de 1,2 seconde sur les pages de listing. Après six semaines de refactoring sur les axes ci-dessus, le temps moyen est passé à 280 millisecondes. La consommation CPU du serveur a chuté de 65 % sur le même volume de trafic, ce qui a permis de réduire la taille du VPS de moitié et donc l'empreinte carbone proportionnellement.
Optimisations côté client : ce que le navigateur télécharge
Le second levier majeur d'un SaaS bas carbone, c'est ce qui transite vers le navigateur de l'utilisateur. Chaque kilo-octet supplémentaire représente du transfert réseau (les data centers, les antennes 4G, les box opérateur consomment de l'électricité), du stockage local, du parsing CPU côté terminal. Sur un SaaS B2B utilisé plusieurs heures par jour par des centaines d'utilisateurs, ces kilos-octets se cumulent vite.
| Levier client | Gain potentiel | Effort |
|---|---|---|
| Compression et lazy loading images | 30 à 70 % du poids initial | Faible |
| Conversion en WebP ou AVIF | 20 à 40 % par image | Faible |
| SVG inline pour les icônes | Suppression de plusieurs requêtes HTTP | Faible |
| Subset des fonts (sous-ensemble Latin) | 30 à 60 % du poids des fonts | Moyen |
| Minification CSS et JS | 15 à 30 % du poids brut | Faible avec Webpack ou AssetMapper |
| Tree-shaking JS et bundling sélectif | 40 à 70 % du JS livré | Moyen à élevé |
| Suppression dépendances inutiles | Très variable, parfois énorme | Moyen |
Préchargement intelligent (preload, prefetch) | Gain UX sans gain net empreinte | Moyen |
Mon parti-pris sur les projets ARDNTECH : pas de framework JS lourd côté front quand un Twig server-side suffit. Symfony en version LTS avec AssetMapper et un Stimulus minimal couvre 80 % des besoins de SaaS B2B sans embarquer 300 kilo-octets de React ou Vue. Quand un framework JS est nécessaire (interfaces très interactives type éditeur graphique), je le scope au strict minimum et je passe par du code-splitting agressif.
Le choix de l'hébergeur et son mix énergétique
L'hébergement vert ne suffit pas à faire un SaaS bas carbone, mais il en est une composante non négligeable. Deux critères structurants : le mix énergétique du data center (carbone-intensité de l'électricité consommée) et l'efficacité énergétique de l'infrastructure (PUE, mutualisation, refroidissement).
Côté mix énergétique, la France bénéficie d'une électricité particulièrement décarbonée grâce au mix nucléaire et hydraulique. La plateforme RTE éco2mix publie en temps réel l'intensité carbone de l'électricité française, qui oscille entre 30 et 100 grammes de CO2 par kilowattheure selon les saisons. À titre de comparaison, l'Allemagne tourne autour de 400 grammes, les États-Unis autour de 350 grammes. Héberger en France divise mécaniquement l'empreinte carbone d'exploitation d'un facteur 4 à 5 par rapport à un hébergement allemand ou américain.
Mon parti-pris sur les projets ARDNTECH
Sur les projets que je conçois, j'utilise par défaut Scaleway ou OVH, deux acteurs français qui communiquent sur leurs engagements environnementaux et publient des indicateurs détaillés. Pour les éditeurs SaaS très soucieux de leur empreinte, l'auto-hébergement Proxmox sur un VPS dédié en France peut être plus efficace en mutualisant plusieurs services sur une même machine. Mon article comparatif des hébergeurs souverains détaille les arbitrages.
La sobriété fonctionnelle : la moitié du job
La sobriété fonctionnelle est l'optimisation la plus rentable et la plus négligée. Concrètement, ça veut dire : ne pas développer ce qui ne sert à rien. Un SaaS chargé de fonctionnalités gadget, de dashboards rarement consultés, de notifications push superflues, de tableaux de bord auto-rafraîchissants toutes les 30 secondes, consomme des ressources serveurs, des transferts réseau, du CPU terminal, sans valeur métier proportionnée.
Le bon réflexe dès la conception : pour chaque fonctionnalité envisagée, se demander combien de fois par mois elle est réellement utilisée, et par combien d'utilisateurs. Les fonctionnalités utilisées moins de 5 % du temps par moins de 20 % des utilisateurs sont des candidates à la simplification, voire à la suppression. Sur le projet d'éditeur SaaS télécom que j'accompagne, un dashboard temps réel auto-rafraîchi a été remplacé par une mise à jour à la demande sur un bouton : 80 % du trafic AJAX en moins, et aucune dégradation d'usage constatée par les utilisateurs.
Le dark mode : utile ou greenwashing
Le dark mode est souvent présenté comme une optimisation énergétique. La réalité est plus nuancée. Sur un écran OLED ou AMOLED, il réduit effectivement la consommation de 10 à 40 % selon la luminosité ambiante. Sur un écran LCD (la majorité des moniteurs bureautiques), le gain est marginal voire nul. Le proposer comme option utilisateur est légitime pour l'accessibilité et le confort, mais le présenter comme une mesure d'écoconception sur un SaaS B2B utilisé en bureau est un argument fragile. Mieux vaut concentrer l'effort sur la sobriété fonctionnelle et le code.
Cas concret : EcoIndex avant et après sur un projet ARDNTECH
Pour illustrer la méthodologie, voici un retour d'expérience anonymisé sur la refonte du tableau de bord d'un éditeur SaaS B2B de signature électronique que j'accompagne. La page principale, consultée plusieurs fois par jour par chaque utilisateur, présentait des indicateurs lourds : graphiques temps réel, listes paginées, exports possibles, notifications.
| Indicateur | Avant refactoring | Après refactoring |
|---|---|---|
| Score EcoIndex | D | A |
| Poids total page | 2,1 Mo | 340 ko |
| Nombre de requêtes HTTP | 78 | 22 |
| Score Lighthouse Performance | 54 | 96 |
| Time to Interactive | 4,2 s | 0,9 s |
| CPU serveur par requête | 180 ms | 45 ms |
Les gains viennent de trois actions principales : conversion des images PNG décoratives en SVG inline, remplacement d'une bibliothèque graphique JavaScript de 380 kilo-octets par du SVG généré côté serveur, et refonte des requêtes Doctrine sur le tableau de bord (4 N+1 queries supprimées, 2 index ajoutés). L'effort total a représenté 12 jours-homme, sur un budget global de refonte qui prévoyait initialement 8 jours. Le surcoût a été absorbé par l'éditeur qui en a fait un argument commercial.
La leçon : un SaaS bas carbone ne se fait pas en un jour, mais les gains atteignables avec 10 à 20 jours-homme de travail ciblé sont spectaculaires. Et ces gains se cumulent avec les gains SEO (Core Web Vitals améliorés), les gains UX (interface plus rapide donc plus utilisable) et les gains d'infrastructure (moins de ressources serveur). C'est un triple bénéfice qui justifie largement l'investissement initial.
Pérenniser la démarche : rituels d'écoconception
Concevoir un SaaS bas carbone n'est pas un sprint, c'est une discipline continue. Sans rituels intégrés dans le cycle produit, les optimisations gagnées en sprint 1 dérivent en sprint 12 quand l'équipe oublie pourquoi ces choix avaient été faits. Voici les quatre rituels que j'intègre systématiquement dans mes contrats de TMA.
- Mesure trimestrielle EcoIndex + Lighthouse sur trois pages représentatives. Comparaison avec le trimestre précédent, identification des dérives. Action correctrice si le score baisse d'un cran.
- Budget de performance par feature : chaque nouvelle fonctionnalité s'inscrit dans une enveloppe maximale (par exemple : +50 ko de JS, +20 requêtes HTTP, +100 ms de temps de chargement). Si la feature dépasse, refactoring ou simplification.
- Revue annuelle des dépendances : audit Composer et npm, suppression des packages non utilisés, mise à jour vers les versions allégées, remplacement des bibliothèques lourdes par des alternatives plus légères. Cette revue s'inscrit dans la maintenance long terme du SaaS.
- Audit fonctionnel biennal : sur la base des données d'usage, identifier les fonctionnalités utilisées par moins de 5 % des utilisateurs et statuer (conserver, simplifier, supprimer). Souvent, cette revue dégage 20 à 40 % de surface fonctionnelle à alléger.
Ces rituels représentent quelques jours-homme par an. Le retour sur investissement est immédiat : performance maintenue, empreinte stable ou en baisse, dette technique contenue. À mon sens, ces rituels devraient être inclus dans tout contrat de maintenance sérieux pour un SaaS qui se revendique éco-responsable.
Concevons votre SaaS bas carbone dès le départ
Si vous préparez un projet de SaaS sur mesure ou de logiciel métier sur mesure avec une exigence écologique structurante, je propose un échange initial gratuit de 30 minutes pour cadrer les axes prioritaires d'éco-conception. Comme tous mes accompagnements, le périmètre est défini sur devis personnalisé. Mon guide du développement de logiciel métier sur mesure détaille la méthodologie projet, la page sur mes engagements écoresponsables complète le volet infrastructure, et le formulaire de contact permet de réserver un créneau.
