L'Intégration Continue avec GitHub Actions : Un Guide Approfondi

Introduction

GitHub Actions est devenu mon outil CI de référence. Je l'utilise sur tous mes projets personnels (WizOps.fr, WizStatus, WizArmor, MongoAdmin.dev) et chez la majorité de mes clients depuis 2020. Après des centaines de workflows écrits et optimisés, voici un guide approfondi fondé sur l'expérience terrain.

Comprendre GitHub Actions en profondeur

GitHub Actions va au-dela d'un simple CI : c'est une plateforme d'automatisation complète intégrée a GitHub. Les workflows YAML vivent dans le repo, versionnés comme le code. C'est un avantage décisif par rapport a Jenkins (configuration externe, Groovy) ou CircleCI (configuration séparée). Chez Epiconcept, la migration de Jenkins vers GitHub Actions a éliminé un serveur Jenkins a maintenir et des heures de debug Groovy. Sur WizOps.fr, le fichier .github/workflows/docker-image.yml est reviewé en PR comme n'importe quel code. L'intégration native avec GitHub (PR status checks, branch protection, environments) rend le pipeline invisible — il fait partie du flux naturel de développement.

Configuration des workflows avancés

Les workflows avancés utilisent des déclencheurs conditionnels, des matrices de tests et des étapes réutilisables. Sur WizOps.fr, les tests se déclenchent sur push et PR, le build Docker uniquement sur main. Chez Bloomflow, des workflow_dispatch permettaient de déclencher des déploiements manuels vers des environnements spécifiques. La stratégie matrix permet de tester sur plusieurs versions de Node.js ou plusieurs OS en parallèle. Les composite actions (actions réutilisables) évitent la duplication entre workflows. Chez Epiconcept, on avait extrait les étapes communes (setup Node, install deps, cache pnpm) dans une composite action partagée entre les repos.

Tests automatisés : de la théorie a la pratique

Sur WizOps.fr, le workflow exécute dans l'ordre : ESLint (conventions de code), TypeScript typecheck (typage), 51 tests Vitest (comportement). Si une étape échoue, les suivantes ne s'exécutent pas — inutile de tester du code qui ne compile pas. Chez KNDS, le pipeline ajoutait des scans de sécurité (Trivy pour les images Docker, secret scanning pour les fuites de credentials). Chez Bloomflow, les tests d'intégration avec docker-compose lancaient PostgreSQL, Redis et Vault éphémères dans le pipeline. Le cache actions/cache économise 45 secondes par run sur WizOps.fr en persistant le store pnpm.

Du CI au CD avec GitHub Actions

GitHub Actions gère aussi le déploiement. Sur WizOps.fr : après les tests, Docker Buildx construit les images multi-plateforme (amd64/arm64), les pousse vers GHCR avec le tag du commit SHA, et le déploiement sur Scaleway Kubernetes suit. Chez TEKYN, le déploiement AWS ECS Fargate était déclenché par un workflow qui mettait a jour la task definition. Chez Earny SA, deux workflows parallèles (un pour GCP, un pour AWS) ont permis la migration sans downtime. Les environments GitHub avec required reviewers ajoutent une validation humaine quand nécessaire — utile pour la production en contexte réglementaire.

Bonnes pratiques du quotidien

Premièrement, pinnez les actions tierces a un SHA spécifique, pas a un tag — chez KNDS c'était une exigence sécurité. Deuxièmement, utilisez les permissions minimales pour le GITHUB_TOKEN. Troisièmement, séparez les workflows par responsabilité : un pour les tests, un pour le build, un pour le déploiement. Quatrièmement, surveillez le temps de vos pipelines — au-dela de 10 minutes, les développeurs décrochent. Cinquièmement, utilisez Renovate pour maintenir les actions et les dépendances a jour automatiquement (c'est ce que je fais sur WizOps.fr). Et surtout : rendez les checks obligatoires dans les branch protection rules.

Conclusion

GitHub Actions est l'outil CI/CD le plus productif que j'ai utilisé. Son intégration native avec GitHub, sa flexibilité YAML, son écosystème marketplace et ses fonctionnalités avancées (matrices, environments, composite actions) en font le choix par défaut pour tout projet hébergé sur GitHub. Les bonnes pratiques décrites ici sont le fruit de 5 ans d'utilisation intensive sur des dizaines de projets. Adoptez-les et votre pipeline deviendra un atout, pas un fardeau.