La dérive est l'ennemi que GitOps est venu nommer
Publié 6 août 2026 · 4 min de lecture
Les environnements divergent de leur état déclaré un hotfix à la fois. Le vrai travail d'Argo CD est de rendre cette divergence visible avant qu'elle ne devienne une panne.
Comment les environnements pourrissent
Personne ne décide de rendre la production unique. Cela arrive une urgence à la fois : un hotfix appliqué à la main à 2h du matin, un réglage pendant un incident, une limite de ressources relevée pour faire taire une alerte. Chaque changement est raisonnable ; leur accumulation est un environnement que personne ne peut reconstruire.
Le coût refait surface plus tard, toujours au pire moment — un exercice de reprise après sinistre qui échoue, un environnement de staging qui cesse de prédire la production, une mise à niveau qui se comporte autrement sur le seul cluster qui compte.
Réconciliation, pas déploiement
Argo CD est souvent présenté comme un outil de déploiement, mais sa valeur durable est la discipline qu'OpenGitOps énonce en principes : état désiré exprimé déclarativement, versionné et immuable, tiré automatiquement, réconcilié en continu. Dans le vocabulaire d'Argo CD lui-même, le target state vit dans Git, le contrôleur le compare en continu au live state, et une application dont l'état vivant dévie est marquée OutOfSync — la dérive devient une condition visible et alertable au lieu d'une surprise latente. Avec l'automated sync policy, le self-heal et le pruning activés, le contrôleur ne se contente pas de signaler la divergence : il l'inverse.
Cela recadre le hotfix de 2h du matin. Le correctif arrive quand même — mais il atterrit en commit, ou il apparaît en dérive le lendemain matin avec un nom attaché. Dans les deux cas, l'histoire de l'environnement reste vraie.
La politique appartient à la même boucle
L'état désiré déclaré, la politique en code contrôle ce qui peut être déclaré : des admission controllers — OPA Gatekeeper ou Kyverno — imposent référentiels de sécurité et standards de ressources à la porte du cluster, tandis que les contrôles de SBOM et de provenance dans l'esprit de sigstore et SLSA tournent à la fusion, où les changements sont bon marché à corriger, pas à la mise en production, où ils sont chers à discuter. Rapide parce que sûr, pas malgré cela.