ArgoCD et GitOps en 2026 : Deploiement Continu Kubernetes et Questions d'Entretien

ArgoCD s'est impose comme l'outil GitOps de reference pour le deploiement continu sur Kubernetes. La version 3.4, publiee en mai 2026, confirme cette position dominante alors que plus de 64 % des entreprises declarent desormais utiliser le GitOps comme mecanisme principal de livraison. Cet article explore les concepts fondamentaux d'ArgoCD, les patterns de configuration avances et les questions d'entretien les plus frequentes pour les postes DevOps et ingenierie de plateforme.

Comment ArgoCD implemente le modele GitOps

ArgoCD fonctionne sous la forme d'un ensemble de microservices deployes dans un cluster Kubernetes : un serveur API, un serveur de depots, un controleur d'applications et un cache Redis. Le controleur surveille les depots Git et compare l'etat desire (les manifestes dans Git) avec l'etat reel du cluster. Lorsqu'une difference apparait, ArgoCD alerte ou synchronise automatiquement selon la politique configuree.

Ce modele base sur le pull (tirage) offre un avantage securitaire majeur par rapport aux deploiements traditionnels de type push pilotes par le CI. Le cluster tire les modifications depuis Git plutot que d'exposer un point d'entree pour qu'un outil CI pousse vers le cluster. Les credentials du cluster ne quittent jamais le perimetre du cluster.

La premiere etape consiste a installer ArgoCD puis a definir une ressource Application :

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

Le bloc source pointe vers le depot Git contenant les manifestes Kubernetes. Le bloc destination specifie le cluster et le namespace cibles pour le deploiement. L'activation de automated.selfHeal: true garantit que toute modification manuelle effectuee via kubectl sera ecrasee par l'etat declare dans Git en quelques secondes.

Sync Waves et Hooks : orchestrer l'ordre de deploiement

Les deploiements en production ne se limitent rarement a un seul manifeste. Les migrations de base de donnees doivent s'executer avant le demarrage des pods applicatifs. Les ConfigMaps et Secrets doivent exister avant que les Deployments ne les referencent. ArgoCD resout cette problematique grace aux sync waves et aux resource hooks.

Les sync waves attribuent un ordre numerique aux ressources. Les numeros les plus bas sont deployes en premier, et ArgoCD attend que chaque vague devienne saine avant de passer a la suivante :

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Le hook PreSync execute le job de migration avant qu'ArgoCD n'applique les manifestes principaux de l'application. La politique de suppression HookSucceeded nettoie le Job apres une execution reussie. ArgoCD 3.3 a egalement introduit les hooks PreDelete, resolvant le probleme recurrent des ressources orphelines lors de la suppression d'applications.

Gestion multi-cluster avec les ApplicationSets

Gerer des dizaines de clusters depuis une seule instance ArgoCD necessite davantage que la duplication de manifestes Application. Les ApplicationSets generent des ressources Application de maniere dynamique a partir de templates et de generateurs :

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Le generateur clusters itere sur tous les clusters enregistres correspondant au label env: production et cree une Application par cluster. Les placeholders {{name}}, {{server}} et {{metadata.labels.region}} sont resolus a partir des donnees d'enregistrement du cluster. L'ajout d'un nouveau cluster de production a ArgoCD declenche automatiquement le deploiement de l'application sur ce cluster.

ArgoCD vs Flux : choisir le bon outil GitOps

La comparaison ArgoCD / Flux constitue l'un des sujets les plus recurrents en entretien DevOps. Les deux projets, tous deux diplomes CNCF Graduated, implementent le pattern GitOps, mais se distinguent par leur architecture et leurs compromis :

| Fonctionnalite | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Architecture | Serveur centralise avec interface web | Controleurs distribues par cluster | | Interface web | Dashboard integre et abouti | Pas d'interface native (options tierces) | | Support Helm | Rendu des templates cote serveur | Integration native du SDK Helm | | Multi-cluster | Hub-and-spoke depuis une instance unique | Installation independante par cluster | | RBAC | Au niveau applicatif avec SSO | RBAC natif Kubernetes uniquement | | Automatisation d'images | Composant Image Updater separe | Reflecteur/automatisation d'images integre | | Deploiement progressif | Integration Argo Rollouts | Integration Flagger | | Empreinte ressources | Elevee (serveur API, serveur repo, Redis) | Reduite (uniquement les controleurs necessaires) |

ArgoCD convient aux equipes qui privilegient la visibilite centralisee, un tableau de bord web et un RBAC granulaire au niveau applicatif. Flux s'adresse aux equipes operant en environnements edge ou a ressources limitees, ou a celles qui s'appuient fortement sur les fonctionnalites natives du cycle de vie Helm. Certaines organisations utilisent les deux : ArgoCD pour les deploiements applicatifs ou l'interface apporte une valeur ajoutee, et Flux pour les composants d'infrastructure ou le fonctionnement distribue et la fidelite Helm importent davantage.

Structure de depot pour un GitOps en production

Une erreur frequente lors de l'adoption du GitOps consiste a stocker les manifestes Kubernetes dans le meme depot que le code source de l'application. Separer le depot de configuration du depot applicatif permet un historique Git plus propre, des cycles de revue independants et des declencheurs CI plus simples :

# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

Le repertoire base contient les manifestes partages. Chaque overlay applique des patches specifiques a l'environnement via Kustomize. Le pipeline CI construit et pousse l'image conteneur, puis met a jour le tag d'image dans le depot de configuration. ArgoCD detecte le commit et synchronise la nouvelle version vers le cluster.

Nouveautes ArgoCD 3.4 a connaitre

ArgoCD 3.4, publie en mai 2026, cible les operations Day 2 avec des fonctionnalites qui apparaissent frequemment en entretien pour les postes DevOps seniors.

La pause de reconciliation de cluster permet aux operateurs de geler la synchronisation ArgoCD pendant un incident de production. Ce mecanisme empeche ArgoCD de reverter les correctifs d'urgence appliques directement sur le cluster pendant que l'equipe resout le probleme :

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

Les globs de valeurs Helm remplacent les listes verbeuses de valueFiles par des patterns, reduisant les conflits de merge dans les equipes qui maintiennent de nombreux fichiers de valeurs specifiques a l'environnement :

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

Questions d'entretien courantes sur ArgoCD

Ces questions apparaissent regulierement dans les entretiens DevOps et ingenierie de plateforme. Elles evaluent la comprehension des principes GitOps, pas uniquement la syntaxe ArgoCD. Pour une preparation plus large sur Kubernetes, le module Kubernetes avance couvre l'ordonnancement, les contextes de securite et les controleurs personnalises.

"Expliquez la difference entre la synchronisation automatique et manuelle dans ArgoCD."

La synchronisation automatique applique les modifications au cluster des qu'ArgoCD detecte une difference entre Git et l'etat reel. La synchronisation manuelle exige un declenchement explicite depuis l'interface, le CLI ou l'API. La synchronisation automatique avec selfHeal: true corrige en permanence la derive de configuration, ce qui constitue le standard pour les environnements de production ou la coherence de configuration est critique. La synchronisation manuelle convient aux environnements de staging ou les equipes souhaitent valider les changements avant de les appliquer.

"Que se passe-t-il lorsqu'ArgoCD detecte une derive entre Git et le cluster ?"

ArgoCD compare l'etat desire (les manifestes Git rendus via Helm, Kustomize ou YAML brut) avec l'etat reel du cluster. Si la synchronisation automatique est activee avec selfHeal, ArgoCD revert immediatement le cluster vers l'etat declare dans Git. Si selfHeal est desactive, ArgoCD marque l'application comme OutOfSync et attend une intervention manuelle. Le diff des ressources reste visible dans l'interface, indiquant precisement quels champs ont diverge.

"Comment gerer les migrations de base de donnees dans un workflow GitOps ?"

Les migrations de base de donnees s'executent sous forme de Jobs PreSync avec un numero de sync wave negatif. Le Job de migration s'execute avant qu'ArgoCD ne deploie la nouvelle version de l'application. En cas d'echec de la migration, la synchronisation est interrompue et la version precedente de l'application reste en cours d'execution. La politique de suppression HookSucceeded nettoie les Jobs de migration reussis. Pour les scenarios de rollback, les scripts de migration doivent etre concus comme des operations idempotentes.

"Comparez ArgoCD et Flux pour une infrastructure multi-cluster en production."

ArgoCD gere plusieurs clusters depuis un plan de controle unique, offrant une visibilite centralisee via son tableau de bord et un RBAC unifie sur l'ensemble des clusters. Flux fonctionne de maniere independante dans chaque cluster, reduisant le rayon d'impact puisqu'une defaillance du plan de controle n'affecte qu'un seul cluster. Au-dela de 100 clusters, le modele centralise d'ArgoCD necessite un cluster de gestion robuste, tandis que l'approche distribuee de Flux elimine ce point de defaillance unique. Le choix depend de la priorite de l'equipe : simplicite operationnelle (ArgoCD) ou isolation des defaillances (Flux). Le module securite des pipelines CI/CD couvre les questions connexes sur la securisation des pipelines de deploiement.

"Qu'est-ce qu'un ApplicationSet et dans quels cas l'utiliser ?"

Un ApplicationSet est un controleur qui genere des ressources Application ArgoCD a partir de templates. Il utilise des generateurs (cluster, repertoire Git, liste, matrice, merge) pour produire plusieurs Applications a partir d'une seule definition. Les cas d'usage typiques incluent le deploiement d'une meme application sur tous les clusters de production, la generation d'applications par tenant dans une plateforme SaaS multi-tenant, ou la creation d'Applications pour chaque repertoire d'un monorepo.

Conclusion

• ArgoCD 3.4 (mai 2026) introduit la pause de reconciliation et les globs de valeurs Helm, repondant aux besoins operationnels Day 2 des clusters Kubernetes en production
• Le modele GitOps base sur le pull elimine la necessite d'exposer les credentials du cluster aux outils CI, preservant les secrets a l'interieur du perimetre du cluster
• Les sync waves et les hooks resolvent l'ordonnancement des deploiements : migrations avant les pods applicatifs, ConfigMaps avant les Deployments, nettoyage apres suppression
• Les ApplicationSets automatisent le deploiement multi-cluster en generant des ressources Application a partir de labels de clusters, de repertoires Git ou de listes personnalisees
• La separation du depot de configuration et du depot applicatif garantit un historique Git plus propre, des cycles de revue independants et des declencheurs CI simplifies
• ArgoCD convient a la gestion multi-cluster centralisee grace a son dashboard et son RBAC ; Flux convient aux environnements distribues, a ressources limitees ou fortement dependants de Helm
• La preparation aux entretiens GitOps doit couvrir la detection de derive, les strategies de synchronisation, les modes de defaillance et des scenarios concrets de production plutot que des definitions memorisees