GitOps

GitOps avec ArgoCD : sync automatique dev/staging/prod

20.03.2026 8 min de lecture Nicolas Wibart

Le GitOps, c'est simple sur le papier : Git est la source de vérité, le cluster s'aligne. En pratique, dès qu'on parle de 3 environnements, la structure du repo devient le point critique.

Le principe en une image

Le flux GitOps : Git → ArgoCD → 3 namespaces, jamais de kubectl manuel

La structure de repo qui marche

Après avoir testé Helm seul, Kustomize seul, puis le combo, j'ai retenu la structure suivante. Elle évite la duplication tout en gardant chaque environnement complètement isolable.

infra-gitops/
├── apps/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       ├── dev/
│       │   ├── kustomization.yaml
│       │   └── patch-replicas.yaml
│       ├── staging/
│       │   ├── kustomization.yaml
│       │   └── patch-replicas.yaml
│       └── prod/
│           ├── kustomization.yaml
│           ├── patch-replicas.yaml
│           └── patch-resources.yaml
└── argocd-apps/
    ├── app-dev.yaml
    ├── app-staging.yaml
    └── app-prod.yaml

Règle d'or Ne jamais éditer une ressource directement dans base/ pour un seul environnement. Si tu en es là, c'est qu'il faut un overlay.

Une Application ArgoCD type

# argocd-apps/app-prod.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: fastapi-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/nicolaswibartDevOps/infra-gitops
    targetRevision: main
    path: apps/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Trois choses à noter ici : prune: true supprime automatiquement les ressources retirées du Git, selfHeal: true annule toute modification manuelle (oui, même la tienne à 23h), et CreateNamespace: true évite un kubectl create ns oublié.

Promotion entre environnements

Comment passer une nouvelle version de dev à prod ? Pas avec kubectl set image. Avec un commit Git.

Le CI build et push myapp:1.4.2 sur le registry
Un job met à jour apps/overlays/dev/kustomization.yaml → ArgoCD sync dev en ~1 min
Une PR manuelle met à jour staging, puis prod

Pourquoi pas tout en automatique ? Pour la prod, chaque changement passe par une PR avec review obligatoire. Le GitOps automatise le deploiement, pas la prise de decision.

Le piège du drift silencieux

Le premier mois, j'ai eu un cas étrange : une ConfigMap qui changeait toute seule. Cause : un opérateur tiers patchait la ressource. ArgoCD remontait OutOfSync en boucle, puis selfHeal annulait, puis l'opérateur re-patchait. Boucle infinie.

Solution : annoter la ressource pour qu'ArgoCD l'ignore partiellement.

metadata:
  annotations:
    argocd.argoproj.io/compare-options: IgnoreExtraneous
    argocd.argoproj.io/sync-options: Prune=false

Ce que GitOps a changé pour moi

Plus de "ça marche sur mon cluster" ; l'état désiré est versionné, point.
Audit gratuit ; chaque changement de prod = un commit avec auteur, date, raison.
Rollback en 30 secondes ; git revert, push, ArgoCD fait le reste.
Onboarding accéléré ; tu veux comprendre la prod ? Tu lis le repo, pas un cluster.

"Si ton processus de déploiement implique un humain qui se souvient d'une commande, tu n'as pas un processus, tu as un risque."

← Retour au journal $ echo "you build it, you run it"