GitOps avec ArgoCD : quand ça fonctionne (et quand ça échoue)

On me demande souvent si une équipe devrait adopter ArgoCD. Ma réponse est rarement un simple oui ou non. Elle est le plus souvent : "Montrez-moi la structure de vos dépôts et expliquez-moi comment vous gérez vos secrets." Après ça, la réponse est presque toujours évidente.

ArgoCD n'est pas un pilote automatique de déploiement que l'on branche sur une infrastructure Kubernetes existante. C'est un outil qui rend visibles et douloureux des choix que les organisations auraient dû trancher depuis longtemps. C'est l'une de ses plus grandes forces, et c'est précisément pourquoi beaucoup d'adoptions échouent.

Cet article énonce clairement ce qui fonctionne en pratique et ce qui ne fonctionne pas. Sans zones grises.

Ce que signifie vraiment GitOps

GitOps ne signifie pas "déploiement via commit Git". Cette simplification est le premier malentendu rencontré en projet, et le plus lourd de conséquences.

L'initiative OpenGitOps, qui s'appuie sur les travaux pionniers de Weaveworks, définit quatre principes fondamentaux : l'état du système est décrit de façon déclarative. Il est stocké de manière versionnée et immuable dans un système de gestion de versions. Les modifications sont appliquées automatiquement. Un agent logiciel assure en permanence la convergence entre l'état stocké et l'état réel.^[1]

Le quatrième principe est le plus important et le plus souvent négligé. GitOps est un modèle pull. ArgoCD interroge le dépôt et amène activement le cluster à l'état défini, de façon continue et auto-réparatrice. C'est fondamentalement différent d'un déploiement CI/CD basé sur le push, même si Git intervient dans les deux cas.

Jez Humble et David Farley ont posé les bases conceptuelles dans "Continuous Delivery" : des déploiements reproductibles et entièrement automatisés sont le prérequis de tout le reste.^[2] GitOps est la conséquence logique de cette idée pour l'exploitation Kubernetes. Qui comprend le principe utilise ArgoCD correctement. Qui ne connaît que l'outil accumule de la dette technique sous étiquette GitOps.

Quand ArgoCD fonctionne vraiment

ArgoCD est optimisé pour les charges de travail Kubernetes natives. Il donne des résultats fiables lorsque les conditions cadres sont réunies.

Plusieurs clusters, un dépôt Git central comme source de vérité. ArgoCD a été conçu précisément pour ce cas d'usage. La ressource ApplicationSet permet de déployer automatiquement une configuration unique sur des dizaines de clusters.^[4] Pour les équipes qui s'appuient sur des architectures multi-clusters dans le cadre d'un conseil Kubernetes entreprise, c'est un avantage opérationnel concret et mesurable par rapport aux approches basées sur des pipelines.

Séparation claire entre équipes plateforme et équipes applicatives. Quand une équipe plateforme maintient les composants d'infrastructure (contrôleur Ingress, cert-manager, stack de monitoring) dans un dépôt dédié, et que les équipes applicatives gèrent leurs charges de travail dans leurs propres dépôts, ArgoCD joue le rôle de couche d'application entre l'intention et l'état. Sam Newman décrit le déploiement indépendant comme le principe fondamental de l'approche microservices.^[3] GitOps rend cette indépendance opérationnelle, mais seulement si la structure des dépôts reflète la structure des équipes.

Exigences de conformité et d'audit. L'historique Git constitue un journal d'audit naturel et immuable. Chaque changement d'état est versionné, traçable et réversible. Pour les organisations des secteurs réglementés tels que les services financiers, les infrastructures critiques ou la santé, ce n'est pas un effet secondaire : c'est un argument central. Aucun autre modèle de déploiement ne fournit cette piste d'audit sans outils supplémentaires.

Déploiement en libre-service avec une surface d'attaque réduite. Quand les équipes de développement peuvent déployer via une pull request sans nécessiter d'accès direct au cluster, la surface d'attaque diminue considérablement. ArgoCD assure l'accès réel au cluster via un compte de service avec des permissions minimales. C'est le principe du moindre privilège appliqué en production, pas en théorie.

Quand ça échoue

La liste qui suit ne décrit pas des risques théoriques. Ce sont des patterns récurrents tirés de projets réels.

Pas d'approche déclarative au niveau applicatif. Quand les applications génèrent de l'état via des scripts de migration de base de données non documentés, des patches kubectl manuels ou une configuration gérée de façon impérative, ArgoCD ne peut pas représenter pleinement l'état réel du système via Git. Le statut de synchronisation devient alors un détecteur de mensonges : "Synced" signifie que les manifestes Kubernetes correspondent, pas que l'application fonctionne correctement. Les équipes qui ne connaissent pas cette distinction perdent confiance dans l'ensemble du processus.

Flou organisationnel sur les responsabilités. GitOps exige des réponses précises à deux questions : qui peut écrire dans quel dépôt ? Quel dépôt détermine le statut de déploiement d'un environnement ? Dans les organisations aux structures d'infrastructure héritées et aux multiples modes de déploiement selon les équipes, ArgoCD ne résout pas le problème organisationnel. Il le rend visible et douloureux. C'est une bonne chose, mais sans réorganisation des responsabilités, ArgoCD reste un outil de surveillance de symptômes coûteux.

La gestion des secrets traitée en réflexion après coup. ArgoCD synchronise tout ce qui se trouve dans Git. Les secrets n'ont pas leur place dans Git, même chiffrés, sauf si l'on dispose d'une stratégie explicite et concertée : Sealed Secrets, External Secrets Operator avec un secret store d'un fournisseur cloud, ou HashiCorp Vault. Les équipes qui reportent la gestion des secrets lors de l'adoption d'ArgoCD finissent avec un modèle hybride. Les manifestes transitent par ArgoCD, les secrets sont injectés via le pipeline CI ou manuellement via kubectl. Ce n'est pas du GitOps. C'est du GitOps pour tout sauf ce qui est le plus critique.

Mauvaise compréhension de la gestion du drift. ArgoCD détecte les écarts entre l'état dans Git et l'état dans le cluster. Quand les équipes font tourner ArgoCD en mode auto-sync avec self-heal sans comprendre ce que l'agent réinitialise lors d'un drift, des situations difficiles à déboguer apparaissent. Un opérateur Kubernetes modifie légitimement une ressource. ArgoCD écrase la modification. L'application casse. La solution n'est pas d'abandonner l'auto-sync. La solution est un modèle explicite précisant quelles ressources sont gérées par ArgoCD et lesquelles ne le sont pas, documenté, testable et concerté.

Monorepos sans stratégie. Un seul dépôt Git pour de nombreuses applications et plusieurs clusters est techniquement possible. Opérationnellement, c'est un cauchemar de maintenance. Chaque commit peut déclencher des synchronisations pour toutes les applications. Les revues de pull request deviennent ingérables. Les stratégies de branches explosent en complexité. La recommandation est claire : un dépôt par équipe ou par Bounded Context, agrégation via les ApplicationSets ArgoCD.^[4]

Recommandations claires pour démarrer

Pour les organisations qui adoptent ArgoCD dans le cadre d'un conseil Kubernetes entreprise, voici l'ordre à respecter.

Le dépôt plateforme d'abord, les applications métier ensuite. Le premier cas d'usage ArgoCD devrait être la stack de monitoring, le contrôleur Ingress et cert-manager, pas l'application métier. Cela laisse à l'équipe le temps de comprendre les concepts ArgoCD (pattern app-of-apps, health checks, sync waves et resource hooks) dans un environnement contrôlé, avant de mettre en jeu le déploiement de l'application génératrice de revenus.

Définir les politiques de synchronisation de façon explicite et consciente. L'auto-sync avec pruning et self-heal est puissant. Il est aussi dangereux pour les équipes qui n'ont pas encore joué des scénarios de drift. Recommandation pour le démarrage : synchronisation manuelle avec alertes en cas de drift. L'automatisation vient lorsque l'équipe comprend ce qu'elle automatise.

Finaliser la gestion des secrets avant l'adoption d'ArgoCD. External Secrets Operator avec HashiCorp Vault ou un secret store d'un fournisseur cloud est la solution recommandée en production. Sealed Secrets est acceptable pour les petites équipes sans infrastructure Vault. Aucune solution n'est pas une option.

La structure des dépôts suit la topologie des équipes, pas la technologie. Un dépôt pour "tous les charts Helm" est une vision technique. Un dépôt pour "l'équipe Paiements" est une vision organisationnelle. La seconde passe à l'échelle avec l'organisation ; la première devient un goulot d'étranglement.^[3]

Intégrer la validation des manifestes dans le processus de pull request. Kubeconform, Conftest avec des politiques OPA et la validation de templates Helm évitent qu'ArgoCD synchronise dans le cluster des manifestes valides mais mal configurés. ArgoCD n'est pas un linter. Il exécute ce que Git lui dit.

Conclusion

ArgoCD est une solution mature pour les équipes qui veulent gérer les déploiements Kubernetes de façon déclarative, avec une piste d'audit et un contrôle opérationnel. Ce n'est pas un outil que l'on ajoute à une infrastructure existante en espérant qu'il remettra de l'ordre. La décision d'adopter GitOps avec ArgoCD est une décision d'architecture avec des conséquences directes sur la topologie des équipes, la structure des dépôts, la gestion des secrets et les exigences de conformité.

Qui pose ces bases avant qu'ArgoCD n'exécute son premier sync construira une plateforme de déploiement stable qui réduit durablement la charge cognitive des équipes opérationnelles.^[2] Qui les ignore n'a fait que coller une URL Git sur des problèmes existants.

Sources

[1] OpenGitOps Working Group: GitOps Principles v1.0.0, Cloud Native Computing Foundation (CNCF), 2021. https://opengitops.dev

[2] Jez Humble, David Farley: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley Professional, 2010.

[3] Sam Newman: Building Microservices: Designing Fine-Grained Systems, 2e édition, O'Reilly Media, 2021.

[4] Argo CD Project: ApplicationSet Controller, Argo CD Documentation, 2024. https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/

[5] Alexis Richardson: GitOps: Operations by Pull Request, Weaveworks Blog, 2017. https://www.weave.works/blog/gitops-operations-by-pull-request