GitOps

GitOps est un mode d’exploitation dans lequel l’état voulu du système — manifests Kubernetes, configuration, versions déployées — est décrit dans un dépôt Git, et où un agent compare en continu cet état déclaré à l’état réel du cluster pour les réconcilier. Déployer ne consiste plus à exécuter des commandes sur la production, mais à merger un commit.

Ce que ça change concrètement

Le dépôt Git devient la source de vérité unique. Toute modification passe par une pull request : elle est relue, tracée, datée, attribuée. Le rollback est un git revert. L’audit (« qui a changé quoi, quand, pourquoi ») est fourni par l’historique Git au lieu d’être reconstitué après coup. Et parce que l’agent tire (pull) la configuration depuis le dépôt au lieu que le pipeline pousse (push) vers le cluster, la CI n’a plus besoin de credentials de production — une surface d’attaque en moins.

Réconciliation continue, pas déploiement ponctuel

La différence avec un simple « pipeline qui fait kubectl apply » est la boucle de réconciliation : l’opérateur (Argo CD et Flux sont les deux implémentations de référence) détecte aussi la dérive dans l’autre sens. Une modification manuelle faite directement sur le cluster est repérée, signalée, et selon la politique choisie, écrasée. C’est ce qui élimine la configuration fantôme — ces changements appliqués à la main en urgence dont plus personne ne se souvient six mois plus tard.

Les limites à connaître

GitOps décrit bien un état cible, mal un processus : les migrations de schéma de base de données, les tâches ordonnées, tout ce qui a un « avant/après » demande un outillage complémentaire. La gestion des secrets doit être résolue séparément — on ne commite pas un mot de passe dans Git, chiffré ou pas c’est un débat, et des outils comme Sealed Secrets ou External Secrets existent pour ça. Enfin, l’erreur classique consiste à adopter l’outil sans la discipline : si l’équipe garde l’habitude de modifier le cluster à la main « juste pour cette fois », l’opérateur GitOps passe son temps à écraser des correctifs légitimes et la confiance dans le système s’effondre.

Sur un périmètre stable, le résultat net est une production dont l’état est lisible dans un dépôt, reproductible sur un autre cluster, et modifiable par le même processus de revue que le code applicatif.