D’après le référentiel général d’écoconception des services numériques, la phase de fabrication d’un service — et non seulement son usage — pèse dans son empreinte environnementale globale. Pour une agence engagée dans une démarche de sobriété numérique, cette phase de fabrication inclut directement les pipelines de déploiement : chaque exécution d’intégration continue consomme du calcul, donc de l’électricité, sur des machines partagées quelque part.
Ce constat pousse à regarder d’un œil différent ce qu’on considérait jusqu’ici comme un détail technique invisible. Un pipeline WordPress typique lance des dizaines, parfois des centaines de builds par mois selon la fréquence des déploiements d’une agence gérant plusieurs projets. Réduire ce poids ne relève pas seulement du geste écologique : cela réduit aussi la facture des minutes de calcul facturées par les plateformes d’intégration continue.
Décomposer un build en étapes mesurables
Avant de chercher à réduire quoi que ce soit, il faut savoir ce qui consomme réellement du temps de calcul dans un pipeline. Un déploiement WordPress classique enchaîne généralement : installation des dépendances Composer, installation des dépendances npm, compilation des assets, exécution des tests, puis transfert vers le serveur cible. Chronométrer chaque étape séparément, sur plusieurs exécutions, fait apparaître des écarts qui passent inaperçus quand on ne regarde que la durée totale du pipeline.
Sur un projet suivi sur plusieurs semaines, l’installation des dépendances représentait à elle seule plus de la moitié du temps de build total, alors même que le contenu de composer.lock et de package-lock.json changeait rarement d’une exécution à l’autre.
Où se cachent les redondances de calcul
La première source de gaspillage identifiée n’est pas exotique : c’est l’absence de mise en cache des dépendances entre deux exécutions du pipeline. Sans cache, chaque build retélécharge et recompile l’intégralité des paquets, alors que la majorité d’entre eux n’a pas changé depuis le dernier commit.
- Recompilation systématique des assets même quand seul le contenu PHP a changé.
- Exécution de la suite de tests complète sur chaque commit, y compris ceux qui ne touchent qu’un fichier de documentation.
- Multiplication des jobs parallèles redondants pour tester des combinaisons de versions rarement utilisées en production.
- Absence de condition d’arrêt anticipé quand une étape précédente a déjà échoué.
Une méthode d’estimation simple
Sans outil de mesure carbone dédié, une approximation raisonnable consiste à multiplier la durée cumulée des builds par la puissance moyenne d’un cœur de calcul en intégration continue, puis à appliquer le facteur d’émission moyen du mix électrique de la région d’hébergement des runners. Cette estimation reste grossière, mais elle suffit à comparer un pipeline avant et après optimisation, ce qui est l’objectif ici : pas une mesure absolue certifiée, une tendance exploitable.
Réduire sans perdre en fiabilité
Les gains les plus importants viennent rarement de la suppression de tests, ce qui serait contre-productif, mais de la suppression du travail redondant :
- Mettre en cache les dépendances Composer et npm entre les exécutions, à condition d’invalider le cache correctement dès que les fichiers de verrouillage changent.
- Découper le pipeline pour ne relancer la compilation des assets que lorsque les fichiers sources concernés ont changé.
- Réduire le nombre de combinaisons de versions testées à celles réellement présentes en production.
- Faire échouer le pipeline dès la première étape en erreur, plutôt que de laisser tourner les étapes suivantes inutilement.
Le calcul le plus sobre reste celui qu’on ne relance pas inutilement.
Fonctionnement interne et limites de la démarche
Cette approche ne mesure que la fabrication du logiciel, pas son hébergement en production, qui reste un sujet à part entière avec ses propres leviers (mutualisation, mise en veille des environnements inactifs, choix du fournisseur). Elle ne remplace pas non plus un bilan carbone méthodologiquement complet : c’est un outil de pilotage interne, utile pour prioriser les optimisations techniques d’une agence, pas un document à présenter comme une certification environnementale.
Pour aller plus loin
Réduire l’empreinte d’un pipeline de déploiement WordPress commence par une chose simple : mesurer avant d’optimiser. Sur les projets suivis, la suppression des redondances de calcul a réduit le temps de build de 40 %, avec un effet direct sur la consommation électrique associée et, accessoirement, sur le temps d’attente des équipes avant chaque mise en production.
