GitOps : principes, ArgoCD vs Flux et mise en œuvre

GitOps transforme Git en source de vérité déclarative pour l'état souhaité de vos systèmes. Concrètement : au lieu de vous connecter à un serveur pour modifier une configuration ou lancer un déploiement manuellement, vous modifiez un fichier dans un dépôt Git. Un outil appelé opérateur (ou contrôleur) surveille ce dépôt en permanence et applique automatiquement les changements sur vos environnements.

Chaque modification passe par une pull request, ce qui permet une revue avant application. L'historique Git conserve la trace de qui a changé quoi, quand et pourquoi. En cas de problème, revenir en arrière consiste simplement à faire un git revert.

Cette page couvre les fondamentaux : principes, stratégies de déploiement, mise en œuvre pas à pas, critères de réussite et pièges à éviter. Les guides pratiques sur les outils (ArgoCD, Flux) sont liés en bas de page.

Ce que vous allez apprendre

Les quatre principes GitOps et pourquoi chacun compte
La différence entre stratégie pull (recommandée) et stratégie push
Comment structurer vos dépôts : app-repo vs config-repo
Comment choisir entre ArgoCD et Flux selon votre contexte
Les critères pour valider que votre implémentation est solide
Les pièges courants et comment les éviter

Prérequis

Qu'est-ce que le DevOps ? Comprendre la culture avant l'outillage.

Infrastructure as Code Décrire l'infra en code versionné.

Le problème terrain

Avant d'adopter GitOps, la plupart des équipes déploient leurs applications de manière impérative : quelqu'un se connecte au cluster, exécute kubectl apply, et espère que tout fonctionne. Cette approche pose des problèmes fondamentaux de traçabilité et de sécurité que vous reconnaîtrez peut-être si vous gérez déjà des environnements Kubernetes.

Les équipes sans GitOps rencontrent souvent ces symptômes :

Déploiements manuels : kubectl apply en direct, sans traçabilité
Drift non détecté : l'état réel diverge de l'état déclaré sans que personne ne le sache
Pas de rollback simple : revenir en arrière nécessite de retrouver la bonne configuration
Accès trop larges : les développeurs ont des droits admin sur le cluster pour déployer
Audit impossible : personne ne sait qui a changé quoi, quand
Environnements incohérents : dev, staging et prod dérivent les uns des autres

Les quatre principes GitOps

GitOps repose sur quatre principes définis par le groupe de travail OpenGitOps du CNCF (Cloud Native Computing Foundation), formalisés dans la spécification v1.0.0. Ensemble, ils garantissent un déploiement fiable, traçable et reproductible, indépendamment de l'outil utilisé pour les appliquer.

1. Déclaratif

L'état souhaité est décrit dans des fichiers déclaratifs (YAML, HCL pour HashiCorp Configuration Language, JSON…) : le fichier dit ce qui doit exister, pas la suite de commandes pour y arriver. C'est l'opposé d'un script impératif, qui décrit une séquence d'actions.

Pourquoi : un fichier déclaratif peut être versionné, comparé, audité. Un script impératif dépend de l'état initial du système au moment de son exécution, ce qui rend le résultat imprévisible si ce point de départ diffère.

2. Versionné et immuable

Tout changement passe par Git : commit, pull request, review, merge. Chaque état appliqué correspond à un commit précis et immuable : impossible de le modifier après coup sans en laisser la trace.

Pourquoi : historique complet, rollback par git revert, audit natif, collaboration via PR.

3. Récupéré automatiquement (pulled)

Un agent logiciel surveille le dépôt et récupère les changements sans intervention humaine, plutôt que de recevoir un ordre de déploiement d'un système externe.

Pourquoi : pas d'oubli, pas d'erreur de manipulation, déploiement reproductible à chaque merge. Aucun credential cluster n'a besoin de sortir du périmètre de l'agent.

4. Réconcilié en continu

L'agent compare en permanence l'état réel à l'état déclaré et corrige les dérives automatiquement, sans attendre qu'un humain s'en aperçoive.

Pourquoi : si quelqu'un modifie le cluster manuellement, l'agent remet l'état conforme au bout de quelques secondes ou minutes selon sa fréquence de synchronisation. Ce self-healing automatique constitue le principal bénéfice opérationnel de GitOps.

Stratégies de déploiement : pull vs push

Il existe deux grandes approches pour appliquer les changements Git sur vos environnements. La différence réside dans qui initie le déploiement, et ce choix conditionne directement votre surface d'attaque et vos accès à sécuriser.

Stratégie Pull (recommandée)

Un agent dans le cluster surveille Git et applique les changements.

Git repo ──▶ Agent GitOps (dans le cluster) ──▶ Ressources Kubernetes

Avantages :

Le pipeline CI n'a pas besoin d'accès au cluster
Réconciliation continue automatique, le drift est corrigé sans intervention
Sécurité renforcée : aucun credential cluster n'est exposé dans la CI

Outils : ArgoCD, Flux, Fleet

Stratégie Push

Le pipeline CI pousse les changements vers le cluster.

Git repo ──▶ Pipeline CI ──▶ kubectl apply ──▶ Ressources

Avantages :

Plus simple à mettre en place initialement
Fonctionne hors Kubernetes (VM, ressources cloud)

Inconvénients :

Le CI a besoin d'accès privilégié au cluster
Pas de réconciliation continue : le drift n'est pas détecté ni corrigé

Choisir son opérateur

Pour Kubernetes, les deux outils GitOps leaders sont ArgoCD et Flux. Les deux projets sont passés Graduated au CNCF fin 2022 (Flux le 30 novembre, ArgoCD le 6 décembre), le plus haut niveau de maturité de la fondation : gouvernance ouverte, sécurité auditée, adoption large en production. Ils implémentent tous les deux les quatre principes GitOps et assurent une réconciliation continue solide.

Critère	ArgoCD	Flux
Interface utilisateur	UI web intégrée	CLI + API (pas d'UI officielle)
Architecture	Contrôleur centralisé	Ensemble de contrôleurs modulaires
Multi-cluster	Géré nativement dans l'UI	Support via Flux multi-tenancy
Approche	Opinionné sur le workflow GitOps	Plus proche des APIs Kubernetes natives
Notifications	Intégrées	Via contrôleurs additionnels
Prise en main	Accessible avec l'UI	Courbe plus technique

Comment choisir :

Vous débutez avec GitOps et voulez une visibilité immédiate → ArgoCD
Vous préférez une approche 100% déclarative et orientée contrôleurs → Flux
Vous gérez de nombreuses équipes avec des périmètres distincts → les deux conviennent, ArgoCD a un système RBAC + AppProject plus intégré ; c'est aussi le terrain naturel du platform engineering, qui construit des plateformes internes en libre-service au-dessus de ces briques

Les deux projets continuent d'évoluer vite sur le volet sécurité de la chaîne d'approvisionnement : les versions récentes d'ArgoCD ajoutent par exemple le mTLS (chiffrement mutuel) entre composants internes et la vérification de signature des commits Git avant synchronisation, deux protections utiles contre l'injection de manifestes non autorisés. Vérifiez la version installée et son changelog avant un déploiement en production, ces fonctionnalités de sécurité évoluent d'une version majeure à l'autre.

Pour du GitOps hors Kubernetes (Terraform, Ansible) : Atlantis, Pulumi Operator, Spacelift.

Mise en œuvre pas à pas

Étape 1 : Structurer les dépôts

Séparez le code applicatif et les manifestes de déploiement en deux dépôts distincts :

app-repo/           # Code source + CI
  src/
  Dockerfile
  .github/workflows/build.yml

config-repo/        # Manifestes GitOps
  base/
    deployment.yaml
    service.yaml
  overlays/
    dev/
    staging/
    prod/

Pourquoi deux dépôts : le code applicatif change fréquemment (commits de feature) alors que les configs de déploiement ont un cycle de vie différent (promotions, releases). Mélanger les deux crée du bruit dans l'historique et complique l'audit.

Étape 2 : Installer l'opérateur

L'opérateur GitOps (ArgoCD ou Flux) s'installe dans le cluster qu'il doit surveiller : c'est lui qui portera ensuite les accès au dépôt Git et à l'API Kubernetes locale, jamais la CI. L'installation crée un jeu de contrôleurs qui tournent en continu et qu'il faut inclure dans votre supervision au même titre que vos autres charges critiques.

Avec ArgoCD (méthode Helm, le gestionnaire de paquets Kubernetes) :

helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd -n argocd --create-namespace

Vérifiez que les pods démarrent correctement avec kubectl get pods -n argocd : tous doivent passer à l'état Running avant de configurer une première application.

Avec Flux (méthode CLI) :

flux bootstrap github \
  --owner=mon-org \
  --repository=config-repo \
  --branch=main \
  --path=clusters/mon-cluster

Cette commande crée elle-même le dépôt de configuration s'il n'existe pas, y commite les manifestes des contrôleurs Flux, puis les déploie. flux check confirme ensuite que chaque contrôleur est opérationnel.

Étape 3 : Définir le workflow de contribution

Une fois l'opérateur en place, le workflow de contribution décrit le chemin que suit chaque changement, de la modification d'un manifeste jusqu'à son application sur le cluster. Formaliser ces étapes évite les déploiements informels qui contournent la revue :

Le développeur modifie un manifeste dans une branche
Pull request avec review (+ validation automatique par kubeconform)
Merge dans main
L'opérateur détecte le changement et réconcilie le cluster
Notification de succès ou d'échec

Étape 4 : Gérer les secrets

Les secrets ne doivent jamais être en clair dans Git. C'est le point le plus sensible d'une implémentation GitOps, car un dépôt Git a vocation à être cloné, forké, parcouru par plusieurs contributeurs : un secret en clair y survit dans l'historique même après suppression du fichier.

Outil	Principe
Sealed Secrets	Chiffrement asymétrique, le secret chiffré est stocké dans Git, déchiffré dans le cluster par un contrôleur
SOPS	Chiffrement des fichiers YAML avec des clés KMS (AWS KMS, GCP KMS, Age…)
External Secrets	Synchronisation depuis un coffre-fort externe (Vault, AWS Secrets Manager…), Git ne contient que la référence, pas la valeur

Étape 5 : Configurer les environnements

Utilisez Kustomize (un outil natif Kubernetes qui applique des correctifs, appelés patches, sur des manifestes de base sans les dupliquer) ou Helm pour gérer les variations entre environnements :

spec:
  replicas: 1

# overlays/prod/patch-replicas.yaml
spec:
  replicas: 3

L'opérateur pointe vers l'overlay correspondant à chaque environnement. Cette approche évite de maintenir des copies quasi identiques des manifestes pour dev, staging et prod : seule la différence est versionnée, ce qui rend chaque écart explicite et revuable en pull request.

Critères de réussite

Votre implémentation GitOps est solide quand vous pouvez cocher chacun des points suivants sans exception permanente. Utilisez cette liste comme grille d'audit avant de considérer une migration terminée.

Aucun déploiement ne se fait par kubectl apply manuel en dehors des incidents
Chaque changement en production a une PR associée et mergée
Le rollback se fait par git revert, pas par manipulation directe du cluster
Les dérives (drift) sont détectées et corrigées automatiquement
Les secrets ne sont jamais en clair dans le dépôt Git
Les développeurs n'ont pas d'accès admin au cluster de production
L'historique Git permet de répondre à "qui a changé quoi, quand"
Les environnements (dev, staging, prod) sont gérés depuis le même dépôt config

Scénarios concrets

Scénario 1 : Migration progressive vers GitOps

Contexte : équipe développant une dizaine de microservices sur Kubernetes. Les déploiements se font via kubectl apply depuis les postes de travail. Des incidents surviennent à cause de configurations incohérentes entre staging et production.

Démarche possible :

Installation d'ArgoCD sur le cluster
Migration sur deux services pilotes pour valider le workflow
Création du config-repo avec structure base/overlays
Formation de l'équipe au workflow PR + sync ArgoCD
Retrait progressif des accès kubectl directs sur les clusters de production

Ce que ça change : chaque déploiement est tracé dans Git, les environnements restent synchronisés, le rollback se fait sans connaître la commande exacte appliquée lors de l'incident.

Scénario 2 : Gestion multi-environnements

Contexte : trois environnements (dev, staging, prod) dont les configurations dérivent. La production contient des paramètres "temporaires" jamais documentés.

Démarche possible :

Audit des configs réelles vs déclarées sur chaque environnement
Création d'un config-repo unique avec overlays Kustomize par environnement
Promotion explicite (PR dev → staging → prod)
Alertes ArgoCD configurées pour tout drift détecté

Ce que ça change : les différences entre environnements sont explicites, versionnées dans Git, et toute deviation est visible et corrigée automatiquement.

Pièges courants

Certains pièges reviennent systématiquement lors d'une première adoption GitOps, souvent parce qu'ils ne se manifestent qu'une fois le système en production. Les connaître à l'avance évite de les découvrir lors d'un incident.

Piège	Impact	Correctif
Secrets en clair dans Git	Fuite de credentials, non-conformité	Utiliser Sealed Secrets, SOPS ou External Secrets
Un seul dépôt app + config	Cycles de vie mélangés, bruit dans l'historique	Séparer en deux dépôts
Ignorer le drift	L'état réel diverge sans alerte	Configurer les alertes de l'opérateur
Trop de customisation par env	Maintenance complexe, merges difficiles	Garder les overlays minimaux, patcher seulement ce qui diffère
Pas de validation pre-merge	Manifestes invalides mergés et appliqués	Ajouter `kubeconform` dans la CI (le projet `kubeval` est archivé et non maintenu)
Accès kubectl conservés en prod	Contournement silencieux du workflow GitOps	Supprimer les accès après migration
Pas de stratégie de rollback testée	Panique en cas d'incident	Documenter et tester le `git revert` avant d'en avoir besoin
Oublier les CRDs	L'opérateur échoue sur des ressources inconnues	Versionner les CRDs dans le config-repo avec les autres manifestes

À retenir

Git est la source de vérité déclarative pour le périmètre géré par l'opérateur, pas pour tout le système au sens absolu
Quatre principes OpenGitOps : déclaratif, versionné et immuable, récupéré automatiquement, réconcilié en continu
Stratégie pull : l'opérateur tire les changements depuis Git, la CI ne touche pas le cluster
ArgoCD et Flux sont tous deux Graduated au CNCF depuis fin 2022, un signal de maturité pour un choix en production
Deux dépôts : app-repo (code) et config-repo (manifestes) ont des cycles de vie différents
Réconciliation continue : le drift est détecté et corrigé automatiquement, le self-healing est le principal bénéfice opérationnel
Secrets séparés : jamais en clair dans Git, toujours chiffrés ou externalisés
Rollback = git revert : pas de manipulation manuelle, un commit suffit

FAQ : questions fréquentes

GitOps, c'est quoi exactement ?

GitOps est une méthode de déploiement où Git sert de source de vérité déclarative : un agent logiciel surveille le dépôt et applique automatiquement les changements sur le cluster, sans intervention manuelle ni accès direct au système par la CI.

Quelle est la différence entre GitOps et CI/CD classique ?

Le CI/CD classique pousse les changements vers le cluster via le pipeline (stratégie push). GitOps inverse le flux : un agent dans le cluster tire les changements depuis Git (stratégie pull), ce qui évite d'exposer des accès privilégiés à la CI et corrige le drift automatiquement.

Quelle différence entre ArgoCD et Flux ?

ArgoCD propose une interface web intégrée et un contrôleur centralisé, pratique pour débuter. Flux fonctionne en CLI et API avec des contrôleurs modulaires plus proches des APIs Kubernetes natives. Les deux sont Graduated au CNCF depuis fin 2022.

Comment gérer les secrets dans un workflow GitOps ?

Les secrets ne doivent jamais être en clair dans Git. Trois approches courantes : Sealed Secrets (chiffrement asymétrique), SOPS (chiffrement via clés KMS) ou External Secrets (synchronisation depuis un coffre-fort externe comme Vault).

Pourquoi adopter GitOps pour déployer sur Kubernetes ?

GitOps apporte une traçabilité complète des changements, un rollback simplifié par git revert, une détection automatique du drift entre état réel et état déclaré, et réduit les accès admin nécessaires sur le cluster de production.

Faut-il deux dépôts Git distincts pour GitOps ?

Oui, il est recommandé de séparer le code applicatif (app-repo) et les manifestes de déploiement (config-repo) car leurs cycles de vie diffèrent : le code change à chaque feature, la configuration suit des promotions entre environnements.

Prochaines étapes

Formation ArgoCD Implémenter GitOps sur Kubernetes avec ArgoCD : de l'installation à la production multi-cluster.

CI/CD : automatiser le chemin du code à la production GitOps prend le relais du pipeline CI/CD au moment du déploiement.

Kubernetes L'orchestrateur cible principal des workflows GitOps.

Gestion des secrets Ne jamais stocker de credentials en clair dans Git.

Infrastructure as Code Décrire l'infrastructure en code versionné, le prérequis de GitOps.