Optimisation des Workflows CI/CD avec GitHub Actions
Introduction
Après avoir migré plus d'une dizaine de projets vers GitHub Actions ces dernières années, je peux affirmer que cet outil a profondément changé ma façon d'aborder le CI/CD. Chez Epiconcept, où j'ai travaillé 4 ans sur des projets pour l'INSERM et les Armées, le passage de Jenkins à GitHub Actions a divisé par trois le temps de maintenance des pipelines. Voici les stratégies d'optimisation que j'applique systématiquement en mission.
Les runners self-hosted : un levier de performance sous-estimé
Sur le projet WizOps.fr lui-même, j'utilise des runners self-hosted pour les builds Docker multi-plateforme. Le gain est double : les temps de build passent de 12 minutes à 4 minutes grâce au cache local, et on évite les limites de minutes gratuites. Chez Epiconcept, nous avions déployé des runners sur des machines dédiées pour les tests d'intégration qui nécessitaient l'accès à des bases MariaDB volumineuses. L'astuce consiste à tagger les runners par capacité (gpu, high-memory, standard) et à router les jobs en conséquence. Un runner avec un SSD NVMe et 32 Go de RAM change radicalement la donne sur les builds Docker avec des layers lourdes. J'ai également mis en place un système de nettoyage automatique du cache Docker sur ces runners, sans quoi le disque sature en quelques semaines.
La stratégie de cache multi-niveaux
Le cache est le nerf de la guerre en CI/CD. Sur mes projets, j'utilise systématiquement trois niveaux de cache : le cache GitHub Actions natif pour les dépendances (node_modules, .venv), le cache Docker layer avec docker/build-push-action et le mode cache-to: type=gha, et enfin le cache applicatif (compilations intermédiaires, artefacts de test). Chez TEKYN, un projet e-commerce avec un monorepo conséquent, cette stratégie a réduit les temps de pipeline de 18 à 6 minutes. Le piège classique est d'oublier la clé de hashage : j'utilise toujours le hash du lockfile (pnpm-lock.yaml, poetry.lock) combiné au hash du Dockerfile pour invalider le cache au bon moment, ni trop tôt ni trop tard.
Matrices et parallélisation intelligente
Les matrices GitHub Actions permettent de paralléliser les tests sur plusieurs versions, OS ou configurations. Mais attention à ne pas tomber dans le piège de la matrice exhaustive qui explose le temps total. Sur un projet Django chez Bloomflow, j'ai mis en place une matrice conditionnelle : les tests unitaires tournent sur une seule version Python en mode rapide sur chaque push, tandis que la matrice complète (Python 3.10/3.11/3.12, PostgreSQL 14/15/16) ne s'exécute que sur les pull requests vers main. Résultat : un feedback en 2 minutes pour le développeur, et une validation exhaustive avant le merge. La commande fail-fast: false est aussi essentielle pour ne pas perdre les résultats des autres combinaisons quand une seule échoue.
La gestion des secrets et environnements
GitHub Actions gère les secrets de manière sécurisée, mais en production je recommande toujours d'aller plus loin. Sur mes déploiements Kubernetes, les secrets de pipeline (tokens Helm, credentials de registry) sont stockés dans GitHub Secrets, tandis que les secrets applicatifs vivent dans HashiCorp Vault avec des External Secrets. Chez Bloomflow, où nous étions en environnement ISO 27001, chaque environnement GitHub (staging, production) avait ses propres secrets avec des reviewers obligatoires pour la production. Cette séparation stricte a satisfait les auditeurs et empêché toute fuite accidentelle de credentials de production dans un workflow de développement.
Workflows réutilisables et composite actions
Au bout de quelques projets, on se retrouve à copier-coller les mêmes workflows. La solution : les reusable workflows et les composite actions. J'ai créé un repository d'actions partagées qui contient mes patterns récurrents : build Docker multi-arch avec push vers GHCR, déploiement Helm sur Kubernetes, notifications Discord en cas d'échec. Sur le CI/CD de WizOps.fr, le workflow complet (lint, test, build frontend, build backend, push images) tient en 50 lignes grâce à ces briques réutilisables. Chez Epiconcept, cette approche a permis à une équipe de 8 développeurs de maintenir 15 repositories avec des pipelines cohérents sans effort de synchronisation.
Conclusion
L'optimisation des workflows GitHub Actions repose sur des principes simples : cacher agressivement, paralléliser intelligemment, réutiliser systématiquement et sécuriser rigoureusement. Ces stratégies, éprouvées sur plus de 100 projets en mission, transforment le CI/CD d'un goulot d'étranglement en un accélérateur de livraison. Le temps investi dans l'optimisation des pipelines se rembourse en quelques semaines par la réduction du temps d'attente des développeurs.