Déploiement continu avec GitHub Actions et Kubernetes
Introduction
Le couple GitHub Actions + Kubernetes, c'est le pipeline que j'utilise quotidiennement sur WizOps.fr et que j'ai déployé chez une dizaine de clients. C'est aussi le pattern le plus demandé en mission freelance. Voici comment le mettre en place concrètement, avec les pièges a éviter.
GitHub Actions : la CI qui vit dans le code
GitHub Actions n'est pas juste "un CI de plus". Son avantage décisif, c'est qu'il vit dans le repo. Le workflow YAML est versionné, reviewé en PR, et évolue avec le code. Sur WizOps.fr, le fichier .github/workflows/docker-image.yml décrit tout le pipeline : lint, typecheck, tests, build Docker multi-plateforme avec Buildx, push vers GHCR. Chez Epiconcept, la migration de Jenkins vers GitHub Actions a simplifié la maintenance : plus de serveur Jenkins a gérer, plus de plugins a mettre a jour, plus de Groovy obscur. Les runners self-hosted que j'utilise pour WizOps.fr offrent des performances supérieures aux runners GitHub standard pour les builds Docker lourds.
Kubernetes : l'orchestrateur qui tient ses promesses
Kubernetes gère le déploiement, le scaling et la résilience. Ce n'est plus a prouver. Ce qui change, c'est la manière de l'utiliser. Chez KNDS sur OVH Cloud, les déploiements rolling update garantissaient zéro downtime pour les applications du secteur défense. Chez Okeiro sur GKE Autopilot, Google gère les nodes — on se concentre uniquement sur les workloads. Chez F2R2 sur EKS Fargate, meme philosophie serverless. Le choix dépend du contexte : managed (EKS, GKE) pour la simplicité, self-managed (OVH, Scaleway) pour le controle et les couts.
L'intégration concrète : du commit a la production
Voici le flux que j'implémente systématiquement. Le développeur push sur une branche, GitHub Actions lance les tests. Si OK, merge sur main. GitHub Actions build l'image Docker, la tague avec le SHA du commit, la push vers GHCR. Ensuite, soit ArgoCD détecte le changement et synchronise (pattern GitOps chez Bloomflow, Padam Mobility, Earny SA), soit le workflow met a jour le tag dans le Helm chart et déclenche le déploiement (pattern plus simple, utilisé sur WizOps.fr). Temps total du commit a la production : 6 a 10 minutes selon la taille de l'image.
Retour d'expérience : les gains concrets
Chez Bloomflow, le passage a ce pattern a réduit le temps de déploiement de 45 minutes (script manuel + SSH) a 6 minutes (automatique). Chez TEKYN, les déploiements e-commerce se faisaient plusieurs fois par jour au lieu d'une release hebdomadaire — les bugs étaient corrigés en heures au lieu de jours. Chez Earny SA, la migration de GCP vers AWS a utilisé ce meme pipeline en parallèle pendant la transition : deux workflows, deux clusters, un switch DNS progressif, zéro downtime. Le gain principal n'est pas juste la vitesse, c'est la confiance : quand le pipeline est fiable, l'équipe n'a plus peur de déployer.
Conseils d'implémentation tirés du terrain
Premièrement, ne mettez jamais de credentials dans le workflow — utilisez les GitHub Secrets et, coté Kubernetes, External Secrets avec Vault. Deuxièmement, tagez vos images avec le SHA du commit, pas avec "latest" — ca permet le rollback immédiat. Troisièmement, testez avant de déployer, pas l'inverse. Quatrièmement, surveillez après le déploiement : intégrez des health checks Kubernetes (readinessProbe, livenessProbe) et des alertes Prometheus/Grafana. Chez Metronome, chaque déploiement envoyait une notification Discord avec le SHA, l'auteur et un lien vers le dashboard Grafana.
Conclusion
GitHub Actions + Kubernetes est devenu le standard de facto pour le déploiement continu. En ajoutant ArgoCD pour le GitOps et une stack d'observabilité pour le monitoring, vous obtenez un pipeline complet, fiable et auditable. C'est exactement ce que je mets en place chez chaque client WizOps, et c'est ce qui tourne en production sur wizops.fr aujourd'hui.