Optimiser les Déploiements Kubernetes avec ArgoCD
Introduction
ArgoCD est l'outil qui a transformé ma manière de déployer sur Kubernetes. Depuis que je l'ai adopté chez Bloomflow il y a 4 ans, je l'ai déployé chez Padam Mobility, Earny SA, F2R2, KNDS, et sur l'infrastructure WizOps. Le GitOps avec ArgoCD, c'est la garantie que l'état du cluster correspond toujours a ce qui est dans Git. Voici comment en tirer le maximum.
GitOps : Git comme source de vérité
Le principe GitOps est simple : le repo Git contient l'état souhaité du cluster, et ArgoCD s'assure que le cluster correspond. Chez Bloomflow avec 50+ microservices, c'était indispensable — impossible de gérer autant de déploiements manuellement. Chaque modification passait par une PR : un développeur changeait l'image tag dans le values.yaml du Helm chart, l'équipe reviewait, et ArgoCD synchronisait automatiquement au merge. Chez Padam Mobility, les environnements de dev bout-en-bout se créaient automatiquement a chaque branche feature. Chez KNDS, le GitOps garantissait la traçabilité exigée par les audits de sécurité du secteur défense.
Surveillance et détection de drift
ArgoCD excelle dans la détection des dérives. Si quelqu'un modifie le cluster manuellement (un kubectl edit intempestif), ArgoCD le signale immédiatement dans son interface. Chez Bloomflow, on avait configuré ArgoCD pour auto-corriger les dérives — toute modification manuelle était annulée en quelques secondes. Chez Earny SA pendant la migration GCP vers AWS, l'interface ArgoCD montrait en temps réel l'état de synchronisation de chaque application sur les deux clusters. L'intégration avec Prometheus permet de créer des alertes Grafana quand une application est en état "OutOfSync" trop longtemps.
Sécurité et audit intégrés
Chez KNDS, chaque déploiement via ArgoCD était tracé : qui, quand, quoi. L'interface web montre l'historique complet des synchronisations et des rollbacks. Le RBAC d'ArgoCD permet de donner des permissions fines : l'équipe A peut déployer sur le namespace A mais pas sur le namespace B. Chez Bloomflow avec ISO 27001, cette traçabilité servait de preuve d'audit. Les projets ArgoCD permettent de restreindre quels repos Git et quels clusters chaque équipe peut cibler. Chez F2R2, les équipes n'avaient accès qu'a leurs propres applications, meme si ArgoCD gérait l'ensemble du cluster EKS.
Intégration avec le pipeline CI existant
ArgoCD s'intègre parfaitement avec GitHub Actions. Le pattern que j'utilise : GitHub Actions build l'image, la push vers GHCR/ECR, puis met a jour le tag dans le repo de manifestes (Helm values ou kustomize). ArgoCD détecte le changement et synchronise. Chez Earny SA, ce pattern a permis la migration de GCP vers AWS avec deux ArgoCD en parallèle. Chez F2R2, ArgoCD déployait les applications sur EKS Fargate après que GitHub Actions avait validé les tests et construit les images. L'avantage par rapport a un kubectl apply dans le workflow : ArgoCD gère les rollbacks, le monitoring et la réconciliation continue.
Scalabilité en production
ArgoCD est conçu pour l'échelle. Chez Bloomflow, une seule instance ArgoCD gérait plus de 50 applications sur plusieurs clusters. Chez F2R2, ArgoCD gérait les déploiements sur EKS avec Fargate — des centaines de pods sans node management. Les ApplicationSets permettent de générer dynamiquement des applications ArgoCD a partir de templates — utile quand vous avez N microservices avec le meme pattern de déploiement. Chez Padam Mobility, les ApplicationSets généraient automatiquement un environnement par branche Git, avec cleanup automatique a la suppression de la branche.
Conclusion
ArgoCD est devenu un standard dans ma pratique. Sa fiabilité, sa traçabilité et son intégration GitOps en font l'outil idéal pour déployer sur Kubernetes a toute échelle. De Bloomflow avec 50+ microservices a WizOps.fr avec 2 services, le pattern est le meme : Git est la source de vérité, ArgoCD s'occupe du reste. C'est la base de tout déploiement Kubernetes que je mets en place chez mes clients.