Un kubectl apply lancé depuis un poste de développeur retient rarement qui l’a exécuté, sur quelle version, à quel moment. GitOps remplace cette question par une réponse structurelle : la seule façon légitime de changer l’état du cluster est de merger un commit, et un agent qui tourne dans le cluster se charge de faire correspondre le réel à ce que Git décrit. ArgoCD est l’implémentation la plus répandue de ce principe pour Kubernetes.

Pull plutôt que push : qui déclenche le changement

Un pipeline CI/CD classique pousse activement les changements vers le cluster : le job de déploiement détient des identifiants avec des droits d’écriture sur l’infrastructure de production, et c’est lui qui décide quand appliquer quoi. ArgoCD inverse ce flux : un agent tourne à l’intérieur du cluster, surveille un ou plusieurs dépôts Git, et tire (pull) les changements lui-même dès qu’il détecte un écart. Aucun système externe n’a jamais besoin d’un accès en écriture direct au cluster : le pipeline CI n’a plus qu’à pousser vers Git, jamais vers Kubernetes.

# Application ArgoCD — décrit CE QUI doit être synchronisé, pas COMMENT
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-api
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/acme/k8s-manifests.git
    targetRevision: main
    path: apps/payment-api
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # supprime ce qui n'est plus dans Git
      selfHeal: true    # corrige tout changement fait hors Git

La boucle de réconciliation : le mécanisme, pas une métaphore

ArgoCD compare en continu deux états : l’état désiré (le contenu du dépôt Git, résolu via Kustomize, Helm, ou du YAML brut) et l’état réel (ce qui tourne effectivement dans le cluster, lu via l’API Kubernetes). Cette comparaison tourne en boucle, typiquement toutes les trois minutes par défaut, indépendamment de tout événement de déploiement.

Trois états résultent de cette comparaison. Synced : le réel correspond exactement à Git, rien à faire. OutOfSync : un écart existe, ArgoCD propose un diff avant d’appliquer quoi que ce soit (sauf en mode automated, où la correction est immédiate). Unknown : ArgoCD ne parvient pas à déterminer l’état, souvent parce qu’une ressource personnalisée n’a pas de logique de comparaison définie.

Ce que révèle un OutOfSync inattendu

Un kubectl edit ou un kubectl scale exécuté directement sur le cluster, en dehors de tout commit, produit un OutOfSync détecté à la prochaine réconciliation. Avec selfHeal: true, ArgoCD annule silencieusement ce changement manuel à la réconciliation suivante, ce qui surprend régulièrement une équipe qui découvre que Kubernetes lui-même semble « annuler » son intervention d’urgence. C’est le comportement voulu, pas un bug : si un changement manuel était légitime, il doit être commité dans Git, sinon il n’a jamais existé du point de vue du système.

Cette même détection de dérive sert de garde-fou de sécurité : un changement fait directement sur le cluster (par un accès compromis, ou une modification malveillante) apparaît comme OutOfSync et peut être automatiquement corrigé avant qu’un humain n’ait même besoin de le remarquer.

Les limites réelles du modèle

GitOps déclaratif fonctionne bien pour ce qui se décrit entièrement en état final : manifests Kubernetes, configuration, versions d’images. Il gère mal ce qui est intrinsèquement séquentiel ou avec état : une migration de base de données ne se « réconcilie » pas, elle s’exécute une fois, dans un ordre précis, avec des conséquences si elle est relancée par erreur. Les secrets posent un problème similaire : les stocker en clair dans Git contredit le principe même de GitOps, d’où le recours à Sealed Secrets ou Vault pour garder le dépôt Git comme source de vérité sans y exposer de valeurs sensibles.

Où ça se range

ArgoCD est le mécanisme qui rend concret ce que l’étape « Fiabiliser les déploiements » d’une migration Kubernetes vise réellement : un rollback qui redevient un simple revert Git plutôt qu’une opération de sauvetage sous pression, et une industrialisation CI/CD où le pipeline pousse vers Git, jamais directement vers la production.

À retenir

GitOps avec ArgoCD remplace l’exécution manuelle de commandes par une réconciliation continue entre Git et le cluster, en mode pull plutôt que push. Un OutOfSync n’est pas une erreur mais un signal : soit un changement légitime qui doit être commité, soit une dérive à corriger. Le modèle excelle sur l’état déclaratif et gère mal ce qui est séquentiel (migrations) ou sensible (secrets), qui restent des outils complémentaires plutôt que remplacés.