Workflow GitOps et comparaison des outils

Le cours précédent posait les principes du GitOps. Maintenant on passe à la pratique : comment fonctionne le workflow de bout en bout, comment choisir entre ArgoCD et FluxCD, et quels patterns adopter (ou éviter) en entreprise.

Le workflow GitOps de bout en bout

Le flux GitOps se décompose en deux phases distinctes avec deux repos séparés :

Phase CI (app repo) : le développeur push du code → le pipeline CI teste, build l’image Docker, la scanne, et la push dans un registry. Ensuite, le CI met à jour le tag d’image dans le gitops repo.

Phase CD (gitops repo) : l’opérateur GitOps (ArgoCD, FluxCD) surveille le gitops repo. Quand il détecte un changement, il synchronise l’état du cluster Kubernetes avec l’état déclaré dans Git.

# Étape CI : mise à jour automatique du gitops repo
# (GitHub Actions, GitLab CI, ou tout autre CI)
- name: Update GitOps repo
  run: |
    cd gitops-repo/environments/production
    kustomize edit set image ghcr.io/org/myapp:${{ github.sha }}
    git commit -am "chore: update myapp to ${{ github.sha }}"
    git push

💡 La séparation des repos est fondamentale : l’app repo contient le code source (cycle de vie rapide, beaucoup de commits), le gitops repo contient la configuration de déploiement (cycle de vie lent, chaque commit déclenche un déploiement). Permissions différentes, responsabilités différentes.

Le pull model vs push model

Le CI/CD traditionnel (push model) : le pipeline a des credentials pour accéder au cluster et pousse les changements. Si le CI est compromis, l’attaquant a accès au cluster.

Le GitOps (pull model) : l’opérateur tourne dans le cluster et tire les changements depuis Git. Le CI n’a jamais de credentials cluster — il ne fait que pousser dans un repo Git. Surface d’attaque réduite.

ArgoCD vs FluxCD : le choix de 2026

Les deux outils sont des projets CNCF matures. Le choix dépend de ton contexte.

ArgoCD est le leader du marché (CNCF Graduated). Ses forces : une UI web riche pour visualiser l’état des applications, les diffs, les logs. Un système de multi-tenancy avec AppProjects et RBAC granulaire. Les sync waves pour orchestrer l’ordre de déploiement. Et ApplicationSet pour gérer des centaines d’applications avec un seul template.

FluxCD est l’alternative légère et composable. Pas d’UI intégrée (tu utilises Weave GitOps ou Grafana), mais une architecture en toolkit de controllers indépendants. Sa killer feature : l’image automation native qui détecte les nouveaux tags dans un registry et met à jour automatiquement le gitops repo. 100% Kubernetes-native, tout se fait via des CRDs.

Jenkins X est en déclin — basé sur Tekton, complexe à opérer, communauté réduite. À éviter pour les nouveaux projets.

🔥 En résumé : ArgoCD si tu veux une UI, du multi-cluster, et du multi-tenancy. FluxCD si tu veux du léger, du composable, et de l’image automation native. Dans le doute, ArgoCD — c’est ce que la majorité des équipes adoptent.

Patterns de déploiement GitOps

Environment promotion

La promotion entre environnements se fait via la structure du gitops repo. La méthode recommandée utilise des répertoires :

gitops-repo/
├── environments/
│   ├── dev/
│   │   └── kustomization.yaml
│   ├── staging/
│   │   └── kustomization.yaml
│   └── production/
│       └── kustomization.yaml
└── base/
    ├── deployment.yaml
    ├── service.yaml
    └── kustomization.yaml

La promotion se fait par PR : le CI met à jour le tag dans environments/dev/, puis une PR (automatique ou manuelle) propage le changement vers staging/, puis une PR avec approbation vers production/. Chaque environnement a son propre état, visible dans l’historique Git.

Rollback et progressive delivery

C’est la beauté du GitOps : le rollback est un simple git revert sur le commit problématique. Pas besoin de retrouver l’ancien pipeline, pas besoin que le CI fonctionne. L’opérateur détecte le changement dans Git et resynchronise le cluster.

# Identifier le commit problématique
git log --oneline
# abc1234 chore: update myapp to sha456  ← problème

# Revert → restaure automatiquement l'ancien tag
git revert abc1234
git push

# ArgoCD/FluxCD détecte → sync → ancienne version redéployée

🎯 L’historique montre clairement le revert, c’est reproductible et auditable. Ça fonctionne même si le CI est down.

Pour les déploiements progressifs, combine GitOps avec Argo Rollouts (compagnon d’ArgoCD) ou Flagger (compagnon de FluxCD). Le principe : au lieu d’un Deployment Kubernetes standard, tu utilises un CRD Rollout qui gère le canary automatiquement.

Le flux : 5% du trafic vers la nouvelle version → analyse des métriques (error rate, latence via Prometheus) → si OK, 10% → 25% → 50% → 100%. Si KO à n’importe quelle étape, auto-rollback. Tout piloté par Git.

Anti-patterns à éviter

🎯 Secrets en clair dans Git : c’est le piège n°1. Utilise SOPS (chiffrement avec clé KMS), Sealed Secrets (chiffrement côté cluster), ou External Secrets Operator (sync depuis Vault, AWS Secrets Manager, etc.).

🎯 kubectl apply/edit manuellement : le moment où quelqu’un fait un kubectl edit en production, l’état du cluster diverge de Git. Le drift sera détecté et corrigé par l’opérateur — mais le changement manuel sera perdu. Tout passe par Git, pas d’exception.

🎯 Un seul repo pour tout : mélanger le code applicatif et la configuration de déploiement crée du bruit. Chaque commit de code déclenche un “changement” dans le gitops repo même si rien ne change côté déploiement. Sépare les repos.

🎯 Tag :latest : un tag mutable rend impossible de savoir quelle version tourne. Utilise toujours des tags immutables — le SHA du commit ou un tag semver.

🎯 Désactiver le self-heal : la réconciliation continue est la killer feature du GitOps. La désactiver, c’est revenir au push model avec plus de complexité. Le drift non corrigé est un risque de sécurité.

🎯 Pas de review sur le gitops repo : les changements d’infrastructure méritent une review comme le code applicatif. Active la protection de branche et exige des approbations sur les changements production.

Ce qu’il faut retenir

Le workflow GitOps sépare CI (build/test/scan dans l’app repo) et CD (déploiement piloté par le gitops repo). Le pull model est plus sécurisé car le CI n’a jamais de credentials cluster.

ArgoCD domine le marché avec son UI, son multi-tenancy et sa communauté. FluxCD est l’alternative légère pour les puristes Kubernetes. Jenkins X est à éviter.

Les patterns essentiels : séparation des repos, promotion par PR entre environnements, rollback par git revert, progressive delivery avec Argo Rollouts ou Flagger.

Les anti-patterns : secrets en clair, kubectl manuel, tag :latest, self-heal désactivé, pas de review sur le gitops repo.

La réconciliation continue détecte et corrige automatiquement le drift entre Git et le cluster. C’est ce qui fait la différence entre “on utilise Git” et “on fait du GitOps”.

Adopte ces principes progressivement : commence par séparer tes repos et automatiser la mise à jour des tags, puis installe un opérateur GitOps. Le prochain cours passe à la pratique : installation d’ArgoCD, Application CRD, sync policies et premier déploiement. 🚀