Flux et Argo CD sont les deux principaux contrôleurs GitOps pour Kubernetes. Tous deux sont des projets CNCF graduated, tous deux sont prêts pour la production, et tous deux mettent en œuvre les mêmes quatre principes GitOps : déclaratif, versionné, tiré automatiquement et réconcilié en continu. La différence tient à la conception, et le choix dépend davantage de votre équipe que des fonctionnalités. Ce guide les compare pour que vous puissiez choisir, ou décider d’utiliser les deux.

Deux philosophies de conception

Argo CD est centré sur l’application et se présente comme un système intégré : un serveur d’API, un repo server qui génère les manifestes, un contrôleur d’applications et une interface web. Vous définissez une Application qui relie un chemin Git à un cluster et un namespace, et Argo CD fait le reste.

Flux est une boîte à outils de petits contrôleurs à usage unique (source, kustomize, helm, notification et, en option, automatisation d’images) qui communiquent via des ressources personnalisées. Les sources et les déploiements sont des objets distincts, si bien qu’un même GitRepository peut alimenter plusieurs Kustomizations. Il n’y a pas d’interface intégrée, et la CLI et kubectl sont les principaux moyens d’interaction.

Une règle empirique utile : Argo CD convient aux équipes qui veulent voir et cliquer, Flux convient aux équipes qui veulent composer et scripter.

Côte à côte

Domaine	Argo CD	Flux
Architecture	Composants intégrés	Contrôleurs indépendants et composables
Interface web	Intégrée, avec arbre de ressources en direct et rollback en un clic	Aucune intégrée ; CLI, Grafana ou tableaux de bord communautaires
Installation	kubectl apply d’un seul manifeste	flux bootstrap, qui committe aussi les manifestes de Flux dans Git
Auto-gestion	Peut se gérer lui-même, configuré par vos soins	Le bootstrap se gère lui-même depuis Git par défaut
Contrôle de la synchro	Synchro manuelle par défaut ; l’automatisation (auto-sync, prune, self-heal) est optionnelle	Automatique par défaut ; contrôle de la production via Git, les tags ou suspend
Multi-cluster	De premier plan : une instance enregistre et gère de nombreux clusters	Une installation Flux par cluster par défaut ; clusters distants possibles via kubeconfig
Helm	Génère les charts sous forme de templates et applique les manifestes	helm-controller exécute le vrai cycle de vie Helm, avec tests et rollback automatique
Artefacts OCI	Pris en charge comme sources	Sources de premier plan pour les manifestes et les charts Helm
Mises à jour d’images	Projet complémentaire distinct	Contrôleurs optionnels intégrés qui committent les tags dans Git
Secrets	Plugins ou opérateurs externes (Vault, External Secrets, SOPS via des plugins)	Déchiffrement SOPS intégré à kustomize-controller, plus d’autres approches
Multi-tenance	Projets et politiques RBAC dans Argo CD	Namespaces et impersonation de service account, appliqués par le RBAC Kubernetes
SSO	Intégré (OIDC, SAML via Dex ou en direct)	Inutile ; l’accès relève du RBAC Kubernetes
Notifications	Moteur de notifications avec templates	notification-controller avec Alerts, Providers et Receivers

Quand Argo CD convient

• Les développeurs veulent voir l’état de synchronisation, le graphe de ressources et les logs sans kubectl.
• Une instance centrale doit gérer de nombreux clusters, avec une prise en main rapide pour les nouveaux utilisateurs.
• Vous vous appuyez beaucoup sur le SSO et un portail en libre-service pour les équipes produit.
• Votre équipe préfère une étape de synchronisation manuelle explicite pour certains environnements.

Quand Flux convient

• Vous voulez des mises à jour d’images automatisées committées dans Git.
• Les secrets doivent vivre chiffrés dans Git avec un minimum d’outillage supplémentaire.
• Vous utilisez beaucoup Helm et voulez une vraie gestion du cycle de vie des releases, y compris le rollback automatique.
• Vous construisez une plateforme interne et préférez des contrôleurs composables et le RBAC natif de Kubernetes pour les tenants.
• Vous voulez que chaque cluster soit autonome, avec des identifiants qui ne le quittent jamais.

Passage à l’échelle

Les deux passent à l’échelle de grands parcs. Argo CD propose le sharding du contrôleur d’applications et le clustering Redis pour de très grandes instances uniques. Les contrôleurs de Flux passent à l’échelle indépendamment et chaque cluster exécute les siens, ce qui évite un goulot d’étranglement central. Les chiffres publiés varient selon la charge de travail, faites donc vos propres benchmarks plutôt que de vous fier à un chiffre accrocheur.

Vous pouvez utiliser les deux

Ils ne sont pas ennemis. Un partage courant : Argo CD pour la livraison des applications, où les développeurs profitent de l’interface, et Flux pour les add-ons du cluster, l’infrastructure et les secrets. Ne laissez simplement jamais les deux gérer les mêmes ressources, sinon ils se les disputeront.

Choisir

1. Les développeurs ont-ils besoin d’une interface dès le premier jour ? Commencez par Argo CD.
2. Avez-vous besoin d’automatisation d’images, de déchiffrement de secrets intégré ou d’une stricte autonomie par cluster ? Commencez par Flux.
3. Toujours indécis ? Essayez chacun sur un cluster kind jetable le temps d’un après-midi, avec les guides de première application de cette bibliothèque.

Migrer de l’un à l’autre est possible parce que les deux lisent du YAML brut, du Helm et du Kustomize depuis Git, mais planifiez-le délibérément : c’est plus que renommer des fichiers. Pour les détails de référence, consultez la documentation de Flux et la documentation d’Argo CD.