Flux CD vs Argo : choisir son GitOps

À la fin de cette page, vous saurez positionner Flux CD et Argo CD, lire un tableau comparatif, appliquer une grille de décision DevOps, bootstrapper Flux sur un cluster lab (contexte cloud ca-central-1), et enchaîner vers le parcours GitOps / Platform — sans podium absolu.

Niveau : Intermédiaire · Temps estimé : 55–70 min · Versions cibles : Flux v2 (GitOps Toolkit) · Argo CD stable · Kubernetes 1.29+ · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug proposé : wow-flux-cd-gitops · Série : WOW Platform / DevOps · Mot-clé SEO : flux cd vs argo · Pages sœurs : wow-argo-cd-gitops, argocd-gitops-kubernetes, wow-platform-engineering-2026, wow-backstage-idp

Statut : READY — draft livré (auto-push WP autorisé Maître)

Prérequis

• [ ] Cluster Kubernetes lab (kind, k3d, minikube ou EKS jetable en ca-central-1) avec kubectl admin
• [ ] Git + dépôt de manifests (public ou privé) ; bases Git
• [ ] Notions K8s : Deployments, Helm, kubeadm
• [ ] Lecture utile : Argo CD GitOps · sœur WOW Argo CD GitOps
• [ ] Coût lab : quasi nul en local ; sur EKS, budget d’alerte + suppression en fin de session

Objectif : clarifier deux familles GitOps, installer Flux, synchroniser un path Git, comparer avec le modèle Application Argo, décider selon équipe / UI / multi-cluster.

Ce que nous allons construire

Lab Flux CD vs Argo (WOW) — ca-central-1
  ├── Clarifier GitOps pull (desired state dans Git)
  ├── Panorama Flux v2 (controllers) vs Argo CD (Application + UI)
  ├── Tableau comparatif multi-critères
  ├── Grille de décision DevOps / Platform
  ├── Lab Flux : CLI + bootstrap + GitRepository + Kustomization
  ├── Miroir conceptuel Application Argo
  ├── Day-2 : drift, secrets, multi-tenancy, notifications
  ├── Erreurs fréquentes + FAQ (5) + quiz
  └── Suite → Argo WOW / Platform / Backstage / e-books

(Schéma — alt : « Flux GitOps Toolkit et Argo CD synchronisent le même dépôt Git vers Kubernetes ».)

Étape 1 — GitOps : même promesse, deux outils

GitOps : l’état désiré vit dans Git ; un agent compare le cluster et le dépôt, puis applique (ou signale) le drift. Avantages : audit PR, rollback = revert, moins de kubectl apply manuels en prod.

En 2026, deux stacks dominent sur Kubernetes :

1. Argo CD — contrôleur + UI/CLI riches ; modèle Application (et ApplicationSet) ; très répandu en plateforme avec portail ops.
2. Flux CD (v2) — GitOps Toolkit : controllers Kubernetes (source, kustomize, helm, notification, image-automation…) ; philosophie API-native, CLI flux, peu d’UI « tout-en-un ».

Les deux sont pull-based, CNCF, compatibles Helm/Kustomize. Le choix est surtout UX, modèle opérationnel et culture d’équipe, pas « lequel est GitOps ».

Étape 2 — Panorama Flux v2 vs Argo CD

Famille	Briques centrales	Posture
Flux	GitRepository / OCIRepository, Kustomization, HelmRelease, Alert/Provider, image reflectors/automation	Controllers découplés ; tout est CR Kubernetes
Argo CD	Application, AppProject, ApplicationSet, repo-server, UI	App-centric ; sync/health/self-heal visibles dans l’UI

Flux brille quand vous voulez composer le CD comme des APIs cluster, automatiser les images, et rester proche de kubectl/GitOps Toolkit. Argo brille quand les ops veulent une console, des ApplicationSets multi-env, et un onboarding visuel.

Les deux cohabitent parfois (Flux pour system/addons, Argo pour apps métier) — à documenter pour éviter le double sync sur les mêmes objets.

Étape 3 — Tableau comparatif (2026)

Critère	Flux CD v2	Argo CD
Modèle	Controllers CRD (toolkit)	Application (+ ApplicationSet)
UI	Limitée / écosystème	Forte (web + CLI)
Helm / Kustomize	HelmRelease / Kustomization	Sources Helm/Kustomize/plain
Multi-cluster / multi-tenant	Via clusters + RBAC K8s / Flux	AppProjects + ApplicationSet
Drift / self-heal	Reconciliation continue	Sync + optional self-heal
Image updates	Image automation native	Policies / outils autour
Courbe UI ops	Plus « YAML/API »	Plus « portail »
Footprint	Controllers ciblés	Stack argocd (+ UI)

Lecture : pas de gagnant universel. UI/portail → Argo. API controllers + image automation → Flux. Platform Engineering : souvent Argo côté apps + catalogue (Backstage).

Étape 4 — Grille de décision DevOps

Scénario	Préférer	Pourquoi
Équipe ops veut dashboard sync/health	Argo CD	UI + Application model
Platform « tout est CR » / GitOps Toolkit	Flux	Controllers composables
Multi-env (dev/stage/prod) par générateur	Argo ApplicationSet ou Flux + structure Git	Les deux marchent ; Argo plus guidé UI
Update auto tags d’images	Flux image automation	Pattern mature
Onboarding juniors via écran	Argo	Moins de YAML brut au départ
Addons cluster (ingress, cert-manager)	Souvent Flux	System GitOps découplé des apps
Déjà lab Argo sur le site	Continuer Argo + lire cette page	Lab Argo
IDP / catalogue services	Argo + Backstage	Portail + GitOps apps

Région cloud de référence pour les labs DEH : ca-central-1 (EKS ou buckets/OIDC associés). Le bootstrap Flux ci-dessous marche aussi en local.

Étape 5 — Lab Flux : bootstrap + sync (15–25 min)

Préflight :

export AWS_DEFAULT_REGION=ca-central-1   # si EKS / AWS CLI
kubectl cluster-info
kubectl get nodes

Installer la CLI Flux (pinnez une version stable ; revalidez sur fluxcd.io) :

curl -s https://fluxcd.io/install.sh | sudo bash
flux --version
flux check --pre

Bootstrap (dépôt Git que vous contrôlez — fork ou repo lab). Remplacez l’owner/repo ; SSH ou HTTPS selon votre auth :

export GITHUB_TOKEN=***   # PAT repo scope — jamais committer le token
flux bootstrap github 
  --owner=<vous> 
  --repository=fleet-lab 
  --branch=main 
  --path=clusters/lab 
  --personal

Attendu : namespace flux-system, controllers Ready, commits Flux dans clusters/lab.

Ajoutez une app (exemple path apps/demo) avec un Deployment minimal dans Git, puis :

# clusters/lab/demo-source.yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: demo-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/<vous>/fleet-lab
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: demo-app
  namespace: flux-system
spec:
  interval: 1m
  path: ./apps/demo
  prune: true
  sourceRef:
    kind: GitRepository
    name: demo-app

kubectl apply -f clusters/lab/demo-source.yaml
flux get sources git
flux get kustomizations
kubectl get pods -A | head

Succès lab : Kustomization Ready, objets du path présents, un commit de test (changement replicas) se réconcilie sans kubectl apply manuel.

Prod : pin de versions controllers, RBAC least-privilege, repos privés, secrets hors Git clair (SOPS / ESO), notifications, pas de token dans l’historique.

Étape 6 — Miroir Argo (sans réinstaller si déjà fait)

Côté Argo, le même path Git devient une Application (voir Argo CD et WOW Argo) : source.repoURL + path + destination.namespace, sync/health dans l’UI.

Exercice mental : mappez GitRepository+Kustomization → une Application ; HelmRelease → Application Helm ; AppProject ≈ frontières multi-tenant. Ne synchronisez pas les deux outils sur les mêmes ressources.

Étape 7 — Day-2 : drift, secrets, multi-cluster

• Drift : Flux reconcilie selon interval + prune ; Argo via refresh/sync/self-heal. Interdisez les hotfixes kubectl non suivis d’un commit.
• Secrets : External Secrets / SOPS / sealed-secrets — jamais de plain secret dans Git.
• Multi-cluster : un bootstrap Flux par cluster ou ApplicationSets Argo vers plusieurs destinations ; nommez clairement clusters/lab vs clusters/prod-ca-central-1.
• Notifications : Flux Provider/Alert (Slack, etc.) ; Argo notifications controller — alertez sync failed / health degraded.
• Progressive delivery : Argo Rollouts ou Flagger (souvent avec Flux) pour canary/blue-green — hors scope lab, à prévoir en day-2 prod.
• Observabilité : métriques controllers + alertes sync ; reliez Prometheus/Grafana déjà vus dans le parcours K8s.
• Platform : catalogue dans Backstage, CD dans Flux ou Argo, pas l’inverse.

Erreurs fréquentes

Symptôme	Cause probable	Correctif
flux check KO	Droits cluster / version CLI	Admin RBAC ; aligner CLI et controllers
Bootstrap refuse Git	Token/SSH scope	PAT repo ; deploy key ; droits contents
Kustomization not Ready	Path Git faux / build error	flux logs ; vérifier path et kustomization.yaml
Double drift avec Argo	Deux outils sur les mêmes objets	Un owner GitOps par namespace/app
Secrets en clair	Commit accidentel	Rotate ; SOPS/ESO ; history purge si besoin
EKS ca-central-1 timeouts	SG / endpoint privé	Lire events ; VPN/bastion ; endpoint access

FAQ

Flux remplace-t-il Argo ?
Non. Ce sont deux implémentations GitOps. Choisissez selon UI, modèle CR et compétences.

Peut-on utiliser Flux et Argo ensemble ?
Oui, avec frontières claires (ex. Flux = addons cluster, Argo = apps). Évitez le double reconcile.

Faut-il une UI pour être « GitOps mature » ?
Non. Git + reconcile + revue PR suffisent. L’UI Argo accélère l’ops humaine.

Helm : Flux ou Argo ?
Les deux. Flux via HelmRelease ; Argo via source Helm. Standardisez le chart museum / OCI interne.

Par où commencer sur DEH ?
Lab Argo déjà documenté, puis ce comparatif + bootstrap Flux ; ensuite Platform / Backstage. Gardez un seul outil par namespace tant que l’équipe n’a pas de runbook clair.

OCI vs Git pour les manifests ?
Flux gère aussi OCIRepository : utile pour artifacts signés / registries. Git reste le défaut pédagogique et audit PR-friendly.

Quiz (5)

1. GitOps pull signifie surtout : a) CI push kubectl b) agent reconcile depuis Git c) FTP manifests
2. Controller Flux pour charts Helm : a) source-controller seul b) helm-controller / HelmRelease c) Ingress
3. Point fort typique d’Argo CD : a) UI Application b) seul outil CNCF c) remplace etcd
4. Image automation native : plutôt a) Flux b) kube-proxy c) CoreDNS
5. Deux outils sync le même Deployment : a) HA idéale b) risque de fight/drift c) obligatoire en prod

Réponses : 1-b · 2-b · 3-a · 4-a · 5-b

Suite du parcours

1. Argo CD sur Kubernetes (lab)
2. WOW — Argo CD GitOps
3. Platform Engineering 2026
4. Backstage IDP
5. Helm · kubeadm
6. Hub Kubernetes · DevOps · E-books

---

Sources (2026-09-11) : documentation Flux (fluxcd.io), GitOps Toolkit Controllers ; Argo CD (argo-cd.readthedocs.io / argoproj) ; pratiques CNCF GitOps. Versions et flags CLI évoluent : revalidez avant prod. Region lab DEH : ca-central-1.