L'automatisation des tests avec GitHub Actions et Docker
Introduction
Combiner GitHub Actions et Docker pour automatiser les tests, c'est le duo que j'utilise sur quasiment tous mes projets depuis 4 ans. Chez Epiconcept, quand on a migré les tests des projets INSERM de scripts manuels vers des containers Docker orchestrés par GitHub Actions, on est passé de "les tests passent sur ma machine" a "les tests passent partout, a chaque commit". Voici le retour d'expérience concret.
Pourquoi Docker Change la Donne pour les Tests
Le problème classique : les tests passent en local mais échouent en CI. Chez Coopengo, on avait des tests d'intégration qui dépendaient d'une version spécifique de PostgreSQL et de Redis. Trois développeurs, trois configurations différentes, des résultats incohérents. Docker résout ca radicalement en figeant l'environnement. Sur WizOps.fr, mon Dockerfile de test embarque exactement les memes dépendances que la production : Node.js 20, pnpm, et les bindings natifs nécessaires. Le build Docker Alpine a d'ailleurs nécessité l'ajout des bindings musl pour oxc-parser — un piège classique que j'ai résolu après investigation. Chez Bloomflow, on a standardisé tous les environnements de test en Docker, ce qui a éliminé 90% des "ca marche chez moi".
Configuration du Pipeline Tests + Docker
Le pattern que j'applique systématiquement : un docker-compose.test.yml qui monte les services nécessaires (base de données, cache, API mock), puis GitHub Actions lance les tests dans ce contexte. Chez Bloomflow, on avait un pipeline avec 4 services Docker (PostgreSQL, Redis, Vault, l'application) qui tournaient ensemble pour les tests d'intégration. Le temps d'exécution est passé de 12 minutes a 4 minutes grace au cache Docker layers de GitHub Actions. L'astuce : utiliser actions/cache pour persister le cache pnpm et les layers Docker entre les runs. Sur le pipeline WizOps.fr, le workflow docker-image.yml enchaine build multi-plateforme Buildx et push vers GHCR, le tout en moins de 5 minutes grace au cache.
Exécution et Suivi des Tests en CI
Sur GitHub Actions, chaque commit déclenche l'exécution des tests dans un container isolé. Chez Epiconcept, on avait configuré des notifications Discord pour chaque échec de test — le développeur concerné était immédiatement alerté avec le lien vers les logs détaillés. Les rapports de test intégrés a la pull request bloquent le merge si un test échoue. Sur WizOps.fr, j'ai 51 tests Vitest avec un objectif zéro warning : pas seulement zéro erreur, mais zéro warning. Ca parait strict, mais c'est cette rigueur qui garantit la stabilité. Chez KNDS dans le secteur défense, les tests de sécurité (scan des images Docker avec Trivy) étaient obligatoires avant tout déploiement.
Optimisation du Temps de Build et des Workflows
Le temps de build Docker est souvent le goulot d'étranglement. Chez TEKYN, les images Docker pour le e-commerce faisaient 2.3 Go avant optimisation. En passant a des builds multi-stage et Alpine, on a réduit a 180 Mo, divisant le temps de push par 10. Sur WizOps.fr, j'utilise Docker Buildx avec cache GitHub Actions, ce qui rend les rebuilds incrémentaux quasi instantanés. Autre optimisation cruciale : placer les COPY package.json et pnpm install avant le COPY . . pour maximiser le cache des layers de dépendances. Chez Bloomflow, la parallélisation des tests via la stratégie matrix de GitHub Actions a divisé le temps total par 3. Mon conseil : investissez du temps dans l'optimisation des images et du cache, c'est la ou se joue la différence entre un pipeline de 2 minutes et un pipeline de 20 minutes.
Conclusion
L'association GitHub Actions + Docker élimine le "ca marche sur ma machine" et garantit des tests reproductibles. Après l'avoir déployé sur plus de 15 projets dans des secteurs variés (défense, santé, e-commerce, fintech), le pattern est rodé : Docker pour l'isolation, GitHub Actions pour l'orchestration, le cache pour la performance. Investissez dans la rigueur des tests automatisés — c'est le meilleur investissement que vous ferez pour la qualité de vos livraisons.