Démarche environnementale

Build local du site internet

Le site est généré via des runners GitLab auto-hébergés directement sur une Freebox. En exploitant cet équipement déjà actif 24h/24, je valorise des cycles de calcul existants sans engendrer de consommation électrique supplémentaire dédiée.

Cette approche locale limite les transferts de données vers des infrastructures distantes (Cloud) tout en conservant une redondance via les runners partagés de GitLab pour garantir la résilience des déploiements. C’est une application concrète de la sobriété numérique : faire mieux avec le matériel déjà en place.

Alpine comme distribution GNU/Linux de base

La chaîne de construction logicielle (CI/CD) s’appuie sur Alpine Linux. Cette distribution est privilégiée pour son empreinte minimale.

L’usage d’images légères réduit la bande passante, le stockage et le temps processeur. Cette efficience est renforcée par une personnalisation stricte via Dockerfile : chaque image est construite sur mesure pour ne contenir que le strict nécessaire.

Pour garantir la stabilité et la sobriété, aucune image ne se base sur le tag :latest. Les versions sont explicitement figées (“version pinning”), évitant les téléchargements redondants et imprévus. Cette maîtrise totale du cycle de vie des conteneurs assure une reproductibilité parfaite tout en minimisant l’empreinte énergétique des mises à jour.

Politique de récupération d’images (Pull Policy) en circuit court

Grâce au paramètre pull_policy = “if-not-present”` dans le config.toml de mes runners, j’élimine les requêtes inutiles vers le Docker Hub. L’image n’est téléchargée qu’une seule fois : si elle est présente localement, elle est réutilisée instantanément. Économie de bande passante et builds ultra-rapides garantis.

Migration vers un moteur haute performance

Hugo surpasse Jekyll grâce à sa vitesse d’exécution phénoménale : là où l’interpréteur Ruby (Jekyll) requiert plusieurs secondes par build, le binaire compilé en Go (Hugo) traite des milliers de pages par seconde. Ce gain d’efficience réduit drastiquement le temps d’occupation processeur lors des cycles de CI/CD.

Techniquement, Hugo est un binaire statique “tout-en-un”, ce qui simplifie radicalement la maintenance. Contrairement à Jekyll qui impose la gestion complexe d’un environnement de gemmes interdépendantes, Hugo ne possède aucune dépendance externe, garantissant une surface d’attaque réduite et une stabilité logicielle pérenne.

Fin des calculs redondants avec l’immuabilité logicielle

Bien que le site n’affiche aucun contenu distant, sa construction nécessite quelques bibliothèques externes. Le fichier composer.lock garantit l’intégrité du projet en fixant le hash exact de chaque paquet. En utilisant exclusivement la commande install, je court-circuite la phase de résolution de dépendances. Cette pratique supprime les calculs CPU intensifs liés à l’analyse des versions, assure un miroir strict entre le développement et la production, et accélère significativement le temps de déploiement.

Fin des transferts inutiles avec le cache binaire

Plutôt que de sauvegarder le dossier vendor, j’ai fait le choix de cibler le dossier .composer_cache. Cette approche optimise les entrées/sorties (I/O) : seules les archives compressées sont conservées, réduisant le volume de stockage du cache et accélérant la phase d’installation sans solliciter le réseau inutilement. Le runner compresse alors quelques fichiers volumineux au lieu de 23 000 micro-fichiers. Le gain est massif : le cycle de compression/décompression s’effondre de plusieurs minutes à quelques secondes seulement.

Architecture virtuelle : abstraction via Hugo Mounts

L’usage des module.mounts implémente une couche d’abstraction virtuelle (VFS), fusionnant logiquement les sources sans duplication physique. Cette architecture préserve l’intégrité des liens relatifs pour les actifs statiques (Webfonts) tout en exposant sélectivement les dépendances aux Hugo Pipes. Ce traitement à la volée évite la redondance sur le disque, optimise les entrées/sorties et garantit une compilation haute performance en mémoire vive.

Structure Classique (Duplication) Structure avec Mounts (Virtuelle)
Action : Copie physique des fichiers de vendor vers static. Action : Montage logique (Mapping) des dossiers.
Impact : Redondance des données, consommation disque inutile. Impact : Source unique, accès direct par Hugo Pipes.
Maintenance : Risque de désynchronisation des sources. Maintenance : Configuration centralisée et transparente.