GitOps

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 que vous reconnaîtrez peut-être.

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 projet OpenGitOps. Ensemble, ils garantissent un déploiement fiable, traçable et reproductible.

1. Déclaratif

L’état souhaité est décrit dans des fichiers (YAML, HCL, JSON…), pas dans des scripts impératifs.

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.

2. Versionné dans Git

Tout changement passe par Git : commit, pull request, review, merge.

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

3. Automatiquement appliqué

Un opérateur surveille le dépôt et applique les changements sans intervention humaine.

Pourquoi : pas d’oubli, pas d’erreur de manipulation, déploiement reproductible à chaque merge.

4. Réconciliation continue

L’opérateur compare en permanence l’état réel à l’état déclaré et corrige les dérives.

Pourquoi : si quelqu’un modifie le cluster manuellement, l’opérateur remet l’état conforme. Le self-healing est automatique.

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.

Stratégie Pull (recommandée)

Un opérateur dans le cluster surveille Git et applique les changements.

Git repo ──▶ Opérateur (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. 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é

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

Avec ArgoCD (méthode Helm) :

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

Avec Flux (méthode CLI) :

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

Étape 3 : Définir le workflow de contribution

Le développeur modifie un manifeste dans une branche
Pull request avec review (+ validation automatique : kubeval, 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.

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 ou Helm pour gérer les variations entre environnements sans dupliquer les manifestes :

spec:
  replicas: 1

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

L’opérateur pointe vers l’overlay correspondant à chaque environnement.

Critères de réussite

Votre implémentation GitOps est solide quand :

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

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 `kubeval` ou `kubeconform` dans la CI
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
Stratégie pull : l’opérateur tire les changements depuis Git, la CI ne touche pas le cluster
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

Prochaines étapes

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

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.