GitOps

Mise à jour : 14/12/2025

GitOps transforme Git en source de vérité unique 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.

Cette approche apporte des bénéfices majeurs : chaque modification passe par une pull request, ce qui permet une revue par vos pairs 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. Plus besoin de se souvenir de la commande exacte ou de la configuration précédente : tout est versionné.

Cette page vous guide pas à pas pour implémenter GitOps, des principes fondamentaux jusqu’à la mise en production, en passant par les pièges à é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 et configurations de manière impérative : quelqu’un se connecte au serveur ou au cluster, exécute des commandes (kubectl apply, ansible-playbook, SSH…) et espère que tout fonctionne. Cette approche pose plusieurs problèmes fondamentaux que vous reconnaîtrez peut-être.

Les équipes qui n’ont pas adopté GitOps rencontrent 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 config
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 principes GitOps

GitOps repose sur quatre principes fondamentaux qui, ensemble, garantissent un déploiement fiable, traçable et reproductible. Comprendre ces principes vous aidera à distinguer une vraie implémentation GitOps d’un simple “déploiement depuis Git”.

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.

2. Versionné dans Git

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

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

3. Automatiquement appliqué

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

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

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.

Stratégies de déploiement

Il existe deux grandes approches pour appliquer les changements Git sur vos environnements : Pull et Push. La différence réside dans qui initie le déploiement : est-ce un agent dans l’environnement cible qui “tire” les changements, ou est-ce le pipeline CI qui “pousse” vers la cible ?

Cette distinction peut sembler technique, mais elle a des implications importantes en termes de sécurité et de fiabilité.

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
Sécurité renforcée (pas de credentials CI vers le cluster)

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
Fonctionne hors Kubernetes (VM, cloud resources)

Inconvénients :

Le CI a besoin d’accès privilégié au cluster
Pas de réconciliation continue (drift possible)

Approche recommandée

Maintenant que vous comprenez les principes, voyons comment implémenter GitOps concrètement. Cette section vous guide étape par étape, de la structure des dépôts jusqu’à la gestion des environnements multiples.

Étape 1 : Structurer les dépôts

Séparez le code applicatif et les manifestes de déploiement :

app-repo/           # Code source
  src/
  Dockerfile

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

Pourquoi : le cycle de vie du code (commits fréquents) diffère de celui des configs (plus stable).

Étape 2 : Choisir un opérateur

Pour Kubernetes, les deux leaders sont :

Critère	ArgoCD	Flux
Interface	UI web complète	CLI + API
Multi-cluster	Natif	Via Flux multi-tenancy
Courbe d’apprentissage	Plus accessible	Plus technique
Notifications	Intégrées	Via controllers additionnels

Pour du non-Kubernetes : Atlantis (Terraform), Pulumi Operator.

Étape 3 : Définir le workflow

Développeur modifie un manifeste dans une branche
Pull request avec review (+ validation automatique)
Merge dans main
L’opérateur détecte le changement et applique
Notification de succès/échec

Étape 4 : Gérer les secrets

Les secrets ne doivent jamais être en clair dans Git.

Options :

Sealed Secrets : chiffrement asymétrique, déchiffré dans le cluster
SOPS : chiffrement des fichiers YAML avec clés KMS
External Secrets : synchronisation depuis un vault externe

Étape 5 : Configurer les environnements

Utilisez Kustomize ou Helm pour gérer les variations :

replicas: 1

# overlays/prod/patch.yaml
replicas: 3

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

Critères de réussite

Comment savoir si votre implémentation GitOps est réussie ? Ces critères vous permettent d’évaluer objectivement votre progression. Ne vous inquiétez pas si vous ne cochez pas toutes les cases immédiatement : GitOps est un parcours, pas une destination. L’important est de progresser vers ces objectifs.

Votre implémentation GitOps fonctionne si :

Aucun déploiement ne se fait par kubectl apply manuel
Chaque changement en production a une PR associée et mergée
Le rollback se fait par git revert, pas par manipulation directe
Les dérives (drift) sont détectées et corrigées automatiquement
Les secrets ne sont jamais en clair dans le dépôt
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

Scénarios concrets

Scénario 1 : Migration vers GitOps

Contexte : équipe de 10 personnes, 15 microservices sur Kubernetes. Déploiements via kubectl depuis les laptops. Plusieurs incidents dus à des configs incohérentes entre environnements.

Approche :

Installation d’ArgoCD sur le cluster
Migration progressive : 2 services pilotes d’abord
Création du dépôt deploy avec structure base/overlays
Formation de l’équipe au workflow PR
Retrait progressif des accès kubectl directs

Résultat à 3 mois : 100% des services migrés, zéro déploiement manuel, rollback en 2 minutes (vs 30 min avant).

Scénario 2 : Gestion multi-environnements

Contexte : 3 environnements (dev, staging, prod), configurations qui dérivent. La prod a des settings “temporaires” jamais documentés.

Approche :

Audit des configs réelles vs déclarées sur chaque env
Création d’un dépôt unique avec overlays par environnement
Promotion explicite : merge dev → staging → prod
Alertes sur drift configurées dans ArgoCD

Résultat : les 3 environnements sont synchronisés, les différences sont explicites et versionnées.

Pièges courants

L’adoption de GitOps s’accompagne de pièges classiques que nous voyons régulièrement sur le terrain. Les connaître à l’avance vous évitera des erreurs coûteuses et des frustrations inutiles. Voici les plus fréquents et comment les éviter.

Piège	Pourquoi c’est un problème	Correctif
Secrets en clair dans Git	Fuite de credentials, non-conformité	Utiliser Sealed Secrets, SOPS ou External Secrets
Un seul dépôt pour code et deploy	Cycles de vie différents, 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 customization par env	Maintenance complexe, erreurs de merge	Garder les overlays minimaux
Pas de validation pre-merge	Manifestes invalides mergés	Ajouter kubeval/kubeconform dans la CI
Accès kubectl conservés	Contournement du workflow GitOps	Retirer les accès après migration
Pas de stratégie de rollback	Panique en cas de problème	Documenter et tester le git revert
Oublier les CRDs	L’opérateur échoue sur des ressources inconnues	Versionner les CRDs avec les manifestes

À retenir

Git est la source de vérité : ce qui n’est pas dans Git n’existe pas officiellement
Pull > Push : la stratégie pull (opérateur dans le cluster) est plus sécurisée
Secrets à part : jamais en clair, toujours chiffrés ou externalisés
Réconciliation continue : le drift est détecté et corrigé automatiquement
Rollback = git revert : pas de manipulation manuelle, juste un commit

Liens utiles

Kubernetes L'orchestrateur cible principal de GitOps.

Terraform IaC pour les ressources hors Kubernetes.

Gestion des secrets Ne jamais stocker de credentials en clair.