SaaS et décarbonation : comment un éditeur réduit vraiment son empreinte IT

Le fonctionnement d’un ERP monolithique 

Dans une architecture monolithique, le logiciel fonctionne comme un seul bloc. La moindre action d’un utilisateur oblige à charger et mobiliser de nombreuses parties du système, même pour une fonctionnalité isolée. C’est un peu comme allumer les lumières de tout un bâtiment alors que vous n’occupez qu’une seule pièce. Résultat : plus de mémoire mobilisée, plus de calcul, plus d’énergie consommée, et donc une infrastructure plus lourde et plus coûteuse. 

L’alternative modulaire 

Avec une architecture en microservices (vente, achats, finance, production, etc.), seul le service réellement sollicité est activé. Les autres restent au repos, et les tâches sont réparties de manière beaucoup plus intelligente. Pour reprendre l’image précédente : vous n’allumez que la pièce dans laquelle vous vous trouvez.

La charge liée aux utilisateurs 

Cette charge dite « interactive » correspond à l’usage quotidien : clics, ouvertures de fenêtres, impressions, saisies, validations. Elle varie selon les horaires de travail, ce qui permet d’ajuster la puissance disponible : forte en journée, réduite en dehors des heures de bureau, minimale la nuit. Par exemple, si aucun développeur ne se connecte la nuit, certains outils comme le moteur de recherche interne ou les outils d’administration n’ont pas besoin de tourner à plein régime. 

La charge liée aux machines 

D’autres tâches, comme les synchronisations, les mises à jour ou les échanges automatiques, s’exécutent en continu. Elles peuvent fonctionner 24 heures sur 24, à condition d’être isolées sur une infrastructure dédiée, sans venir alourdir celle réservée aux usages interactifs. 

Pour faire fonctionner des microservices associés à de l’autoscaling, la conteneurisation s’impose comme la solution la plus adaptée, avec des outils comme Docker. Un conteneur permet d’emballer un service de façon légère, afin qu’il démarre rapidement et s’arrête tout aussi vite. Il faut ensuite un outil pour orchestrer l’ensemble, à l’image de Kubernetes. Son rôle : 

• décider si un service doit tourner en un ou plusieurs exemplaires ; 

• démarrer et arrêter automatiquement les microservices ; 

• positionner chaque service à l’endroit le plus pertinent pour optimiser l’usage des serveurs ; 

• suivre l’usage de chaque microservice, dans le cadre d’une stratégie R&D actualisée incluant les correctifs de sécurité. 

Cette combinaison permet un ajustement fin de la consommation, et donc une réduction directe de l’empreinte énergétique. 

L’IA s’intègre progressivement dans les démarches d’optimisation des éditeurs SaaS. Elle permet notamment de mieux analyser la consommation des services, de repérer les schémas à l’origine d’instabilités, d’anticiper les moments propices pour désactiver certains services et de suggérer des pistes d’optimisation. Côté utilisateurs, l’IA transforme également la manière de consommer les logiciels SaaS. Mais attention : elle reste une grande consommatrice de ressources. Un usage excessif, ou des échanges trop longs avec les assistants, peut générer un surcoût énergétique important.