Aller au contenu
Retour au glossaire
Méthodologie DevOps

Qu'est-ce que GitOps ?

GitOps est une méthode opérationnelle où Git devient la source unique de vérité pour l'état souhaité d'une infrastructure. Un agent réconcilie en continu la production avec le contenu du dépôt.

À quoi sert GitOps

GitOps applique aux opérations les pratiques que les équipes de développement utilisent depuis quinze ans : versionnement, pull request, revue, traçabilité, rollback. L'idée fondatrice est qu'un dépôt Git ne décrit plus seulement le code applicatif, mais aussi l'état souhaité de l'infrastructure : manifests Kubernetes, charts Helm, fichiers Terraform, configuration de monitoring. Un agent automatisé (ArgoCD, Flux) lit ce dépôt en permanence et applique les changements au cluster pour faire converger la production vers le contenu du dépôt.

Concrètement, un opérateur ne fait plus kubectl apply à la main : il ouvre une pull request qui modifie un fichier YAML, la PR est revue et fusionnée, et l'agent GitOps détecte le changement en quelques secondes pour le propager sur l'environnement cible.

Pourquoi les équipes adoptent GitOps

Auditabilité totale. Chaque changement de production est un commit signé, avec auteur, date, contexte et revue. Pour les organisations soumises à nLPD, RGPD ou FINMA, c'est la voie la plus simple pour démontrer la traçabilité opérationnelle exigée par les auditeurs.

Rollback instantané. Un déploiement qui casse la production se rollback par un git revert. L'agent applique le retour à l'état précédent automatiquement, sans script ni intervention manuelle. Le temps moyen de récupération (MTTR) chute typiquement d'un facteur 3 à 5 selon nos observations terrain.

Cohérence entre environnements. Le même processus s'applique à dev, staging, production et disaster recovery. Les drifts manuels disparaissent puisque toute modification hors Git est détectée et automatiquement réconciliée.

Onboarding accéléré. Un nouvel ingénieur lit le dépôt et comprend l'état exact de l'infrastructure sans devoir interroger ses collègues. Le savoir tribal devient documenté par construction.

Les quatre principes GitOps (CNCF)

  1. Déclaratif : l'infrastructure est décrite en YAML/HCL, pas en scripts impératifs.
  2. Versionné et immuable : Git est l'unique source de vérité, jamais modifiée en place.
  3. Tiré automatiquement : un agent applique l'état souhaité, on ne pousse pas manuellement.
  4. Réconcilié en continu : tout drift par rapport à Git est corrigé sans intervention humaine.

En pratique

Sur les missions Hidora, nous déployons typiquement ArgoCD ou Flux sur le cluster cible, configurons un dépôt central par environnement (parfois un mono-repo avec dossiers par cluster), et migrons les déploiements existants en deux à quatre semaines selon la taille du périmètre. La courbe d'apprentissage côté équipe est de l'ordre de quinze jours pour maîtriser le workflow PR + revue + merge appliqué à l'infrastructure.

Quand GitOps ne suffit pas

Les opérations à fort caractère temporel ou stateful (migrations de base de données, scripts de seed, jobs ponctuels critiques) restent mieux gérées par des pipelines CI/CD classiques. GitOps brille pour l'état désiré stable ; il n'élimine pas les outils impératifs pour les bascules ponctuelles.

Services Hidora associés

  • Consulting : conception de l'architecture GitOps, choix entre ArgoCD et Flux, mise en place du workflow.
  • Managed Services : exploitation d'environnements GitOps existants avec monitoring 24/7.
  • Kubernetes et CI/CD : prérequis techniques d'une adoption GitOps réussie.