GitOps et infrastructure immuable : comment ArgoCD et Flux rendent les déploiements

Du CI/CD push-based au GitOps pull-based

Le déploiement continu traditionnel suit un modèle push : un pipeline CI construit l’application, exécute les tests, puis pousse l’artefact vers l’environnement de production. Jenkins, GitHub Actions, GitLab CI — ces outils exécutent des scripts de déploiement qui se connectent en SSH aux serveurs, lancent des commandes kubectl apply ou appellent les API des fournisseurs cloud pour mettre à jour les services en cours d’exécution. Le système CI est l’acteur ; l’environnement de production est le destinataire passif. Ce modèle fonctionne, mais il présente une faiblesse fondamentale : le système CI doit disposer des identifiants pour modifier la production, l’état déployé peut diverger de ce qui est défini dans le code (dérive de configuration), et il n’existe aucun mécanisme continu pour détecter ou corriger cette divergence.

GitOps inverse ce modèle. Inventé par Alexis Richardson, CEO et fondateur de Weaveworks, dans un article de blog de mars 2017 intitulé « Operations by Pull Request », GitOps propose que l’état souhaité de l’infrastructure et des applications soit déclaré dans un dépôt Git, et qu’un agent tournant à l’intérieur du cluster réconcilie en continu l’état réel avec l’état déclaré. Si quelqu’un modifie manuellement un déploiement Kubernetes (source courante de dérive), l’agent GitOps détecte l’écart et le rétablit pour correspondre à l’état défini dans Git. Git devient la source unique de vérité — chaque changement est versionné, auditable et réversible par les opérations Git standard.

Les deux outils GitOps dominants — ArgoCD et Flux — ont tous deux obtenu le statut CNCF (Cloud Native Computing Foundation) Graduated, le plus haut niveau de maturité de l’écosystème CNCF. ArgoCD, initialement open-sourcé par Intuit en janvier 2018, a dépassé 20 000 étoiles GitHub et est utilisé en production par des entreprises dont Red Hat, Tesla, IBM, Adobe et Capital One. Une enquête CNCF de juillet 2025 a trouvé ArgoCD opérationnel dans près de 60 % des clusters Kubernetes pour la livraison d’applications, avec 97 % des répondants l’utilisant en production. Flux, créé à l’origine par Weaveworks et désormais maintenu par la communauté CNCF après la fermeture de Weaveworks en février 2024, fournit un toolkit GitOps plus léger et composable. Ensemble, ils ont fait de GitOps le pattern de déploiement dominant pour les environnements basés sur Kubernetes.

Comment fonctionnent ArgoCD et Flux

ArgoCD opère comme un contrôleur Kubernetes qui surveille les dépôts Git contenant les définitions d’applications (manifestes Kubernetes, charts Helm ou overlays Kustomize). Quand un développeur merge une modification dans le dépôt Git — mise à jour d’un tag d’image conteneur, modification des limites de ressources, ajout d’une variable d’environnement — ArgoCD détecte le changement et synchronise le cluster Kubernetes pour correspondre. L’interface web ArgoCD fournit une visualisation en temps réel de l’état de l’application. Les rollbacks sont aussi simples qu’un revert Git.

ArgoCD supporte plusieurs stratégies de synchronisation. L' »auto-sync » applique les changements immédiatement quand Git est mis à jour — adapté aux environnements de développement et de staging. Le « manual sync » nécessite l’approbation d’un opérateur — approprié pour les environnements de production. ArgoCD excelle dans les patterns app-of-apps et ApplicationSet pour gérer des centaines d’applications de manière déclarative, ce qui explique que les ingénieurs de plateforme représentent désormais 37 % des utilisateurs d’ArgoCD selon l’enquête CNCF 2025.

Flux adopte une approche plus modulaire. Plutôt qu’une application monolithique, Flux est composé de contrôleurs spécialisés : Source Controller (surveille les dépôts Git, les dépôts Helm et les registres OCI), Kustomize Controller (applique les overlays Kustomize au cluster), Helm Controller (gère les releases de charts Helm), Notification Controller (envoie des alertes vers Slack, Teams ou des endpoints webhook) et Image Automation Controllers (met automatiquement à jour les tags d’images conteneur dans Git quand de nouvelles images sont poussées dans un registre). La capacité d’automatisation d’images de Flux est particulièrement puissante : quand un pipeline CI pousse une nouvelle image conteneur, Flux la détecte, met à jour le tag dans le dépôt Git, puis réconcilie le cluster — automatisant totalement le pipeline de déploiement sans qu’aucun système CI n’ait besoin d’identifiants cluster.

Après la fermeture de Weaveworks en février 2024, des questions se sont posées sur l’avenir de Flux. Le projet s’est stabilisé sous la gouvernance CNCF. ArgoCD a nettement pris les devants en adoption — le rapport annuel CNCF 2023 comptait 927 auteurs de code pour le projet Argo contre 188 pour Flux — mais Flux reste le choix préféré pour les équipes qui valorisent son architecture modulaire et composable.

Infrastructure immuable : ne jamais modifier, toujours remplacer

GitOps est profondément lié au principe d’infrastructure immuable — l’idée que les serveurs et conteneurs en cours d’exécution ne devraient jamais être modifiés sur place. Au lieu de se connecter en SSH à un serveur pour installer un correctif de sécurité ou mettre à jour un fichier de configuration (infrastructure mutable), on construit une nouvelle image serveur avec le correctif appliqué et on remplace entièrement l’ancien serveur (infrastructure immuable). Ce concept a été nommé par Chad Fowler dans un article de 2013, tandis que le site de Martin Fowler chez Thoughtworks documentait le pattern étroitement lié de « serveur immuable ». Mis en oeuvre à travers la conteneurisation, l’infrastructure immuable élimine la dérive de configuration.

Dans un contexte Kubernetes, l’infrastructure immuable signifie que les conteneurs sont traités comme des unités jetables. On ne fait jamais d’exec dans un conteneur en cours d’exécution pour modifier un fichier. On ne fait jamais de kubectl edit in-place. Au lieu de cela, on met à jour l’image conteneur, on pousse la nouvelle version dans un registre, on met à jour le tag dans le dépôt Git, et on laisse ArgoCD ou Flux déployer de nouveaux pods avec l’image mise à jour tout en terminant les anciens.

Les bénéfices se composent à l’échelle. Quand chaque environnement (développement, staging, production) est défini dans Git, promouvoir un changement du staging à la production est un merge Git. Quand la conformité exige une piste d’audit de chaque changement en production, Git la fournit automatiquement. Quand un déploiement casse la production, le rollback est un revert Git.

Le virage organisationnel : GitOps est un changement de culture

Adopter GitOps ne se résume pas à installer ArgoCD. Cela nécessite un changement fondamental dans la façon dont les équipes d’opérations travaillent. Premier changement culturel : les opérateurs doivent cesser de faire des modifications ad-hoc en production. Plus de commandes kubectl « correctif rapide » jamais documentées. Chaque changement doit passer par Git — une pull request, une revue de code, un merge.

Le deuxième virage organisationnel est la convergence des workflows développeur et opérateur. Dans un modèle GitOps, développeurs et opérateurs utilisent les mêmes outils (Git), les mêmes processus (pull requests, revue de code) et le même artefact (le dépôt Git).

Le troisième virage concerne la gestion des secrets, qui reste le défi pratique le plus épineux de l’adoption GitOps. Les solutions incluent Sealed Secrets, External Secrets Operator (récupérant les secrets depuis des coffres externes comme HashiCorp Vault, AWS Secrets Manager ou Google Secret Manager au moment du déploiement) et SOPS (l’outil Secret Operations de Mozilla).

Au-delà de Kubernetes : GitOps pour tout

Le modèle GitOps est né dans l’écosystème Kubernetes, mais ses principes — état déclaratif, configuration versionnée, réconciliation continue — s’appliquent largement. Terraform suit déjà un pattern adjacent à GitOps. OpenTofu, le fork open source de Terraform créé en réponse au changement de licence BSL de HashiCorp en août 2023, suit le même modèle et a gagné une traction significative — en 2025, la moitié des déploiements de Spacelift tournent sur OpenTofu.

Crossplane, qui a obtenu le statut CNCF Graduated en octobre 2025, étend la gestion déclarative de style Kubernetes à toute ressource cloud. Avec plus de 3 000 contributeurs de plus de 450 organisations et des utilisateurs incluant Nike, NASA Science Cloud et SAP, Crossplane a validé la vision « GitOps pour tout ».

La trajectoire est claire : les opérations d’infrastructure manuelles deviennent aussi anachroniques que le déploiement manuel par FTP. Les organisations qui adoptent GitOps rapportent des améliorations mesurables : l’équipe d’infrastructure Creative Cloud d’Adobe a réduit les temps de rollback de 45 minutes à 3 minutes avec ArgoCD, et l’enquête CNCF 2025 a trouvé que 93 % des organisations prévoient de continuer ou d’augmenter leur adoption GitOps.

Questions Fréquemment Posées

Sources et lectures complémentaires

• CNCF End User Survey Finds Argo CD as Majority Adopted GitOps Solution — CNCF
• ArgoCD Documentation — Argo Project / CNCF
• Flux Documentation — FluxCD / CNCF
• Cloud Native Container Management Platform Weaveworks Shuts Its Doors — TechCrunch
• Why Flux Isn’t Dying After Weaveworks — The New Stack
• Cloud Native Computing Foundation Announces Graduation of Crossplane — CNCF
• GitOps Goes Mainstream: ArgoCD Surpasses 20,000 GitHub Stars — DevOps Tales
• Sealed Secrets — Bitnami Labs
• External Secrets Operator — External Secrets Project
• Immutable Server — Martin Fowler