Argo CD 3.6 rend le progressive sync observable et étoffe ses health checks
La version 3.6.0-rc1 d’Argo CD, publiée le 16 septembre 2026, ajoute des métriques et des conditions au progressive sync des ApplicationSets et enrichit la bibliothèque de health checks — CloudNativePG, cert-manager, Prometheus Operator, Kyverno. Les équipes qui déploient en vague sur plusieurs clusters devraient planifier la mise à niveau dès la sortie stable.
16 septembre 2026. Argo CD publie la v3.6.0-rc1, première ébauche de la prochaine version mineure de l’outil de GitOps de référence. Progressive sync : les ApplicationSets gagnent des métriques et des conditions dédiées. Health checks : la bibliothèque s’enrichit d’une douzaine de ressources, de CloudNativePG à cert-manager en passant par l’opérateur Prometheus. Pourquoi c’est important : les équipes qui déploient en vague sur plusieurs clusters cessent de piloter leurs déploiements à l’aveugle.
Le progressive sync passe de mécanique à observable
Le progressive sync est l’une des fonctions les plus stratégiques d’Argo CD : il permet de dérouler une mise à jour vague par vague sur un ensemble de clusters, en s’arrêtant dès qu’une étape échoue. C’est le mécanisme qui transforme une simple synchronisation Git en stratégie de déploiement digne d’un canary multi-environnements. Sa limite historique n’était pas fonctionnelle, mais observationnelle : il était difficile de savoir, au milieu d’une vague, combien d’applications avaient déjà été rafraîchies, pourquoi la progression marquait une pause, ou si un contrôleur était en train de s’essouffler.
La 3.6 s’attaque exactement à ce point aveugle. Les ApplicationSets exposent désormais des métriques de progressive sync, ainsi qu’un compteur des rafraîchissements d’applications déclenchés par l’ApplicationSet pendant la progression. Un contributeur ajoute des annotations sur les applications pour forcer une réconciliation avant de poursuivre la vague — le moyen de garantir qu’un état intermédiaire est bien pris en compte avant de passer à l’étape suivante. Enfin, les scénarios de progressive sync sont remontés dans les conditions des ressources sous forme de raisons et de messages lisibles, et le contrôleur d’ApplicationSet expose des flags de rate limiting sur sa file de travail.
Concrètement : une équipe qui déroule une mise à jour sur vingt clusters peut maintenant voir dans Prometheus et dans le statut des ressources où en est la vague, combien d’applications ont été synchronisées et pourquoi la progression s’est interrompue. Le progressive sync devient un objet que l’on supervise et que l’on déclenche avec la même rigueur qu’un déploiement applicatif classique.
Comment fonctionne le progressive sync
Pour mesurer l’écart, il faut rappeler la mécanique. Le progressive sync d’Argo CD repose sur une stratégie RollingSync déclarée au niveau de l’ApplicationSet : on découpe le parc en étapes (steps), chacune ciblant un sous-ensemble de clusters par des matchExpressions, et le contrôleur ne passe à l’étape suivante que lorsque la précédente est synchronisée et saine.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: fleet-rollout
spec:
strategy:
type: RollingSync
rollingSync:
steps:
- matchExpressions:
- key: env
operator: In
values: [dev]
- matchExpressions:
- key: env
operator: In
values: [staging]
generators:
- clusters: {}
template:
metadata:
name: "{{name}}-app"
spec:
project: default
source:
repoURL: https://github.com/example/fleet.git
targetRevision: main
destination:
server: "{{server}}"
namespace: defaultCe qui manquait à cette mécanique, c’était la visibilité. Dérouler une vague sur vingt clusters sans métriques, c’est piloter un déploiement au son — on sait que ça avance, pas où ça s’arrête. Les métriques de progressive sync ajoutées dans la 3.6 comblent précisément ce trou, et les annotations de réconciliation forcée répondent à un besoin plus fin : s’assurer qu’un état intermédiaire a bien été réconcilié avant d’autoriser la vague suivante. C’est la différence entre « déployer par étapes » et « déployer par étapes en sachant où l’on en est ».
Des health checks pour l’écosystème operator
L’autre moitié de la version est une extension nette de la bibliothèque de health checks — ces règles qui disent à Argo CD quand une ressource personnalisée est réellement « saine », au-delà du simple statut Synced. La 3.6 ajoute des contrôles pour :
- CloudNativePG : la base PostgreSQL opérée, ses backups et ses actions hibernate/rehydrate ;
- cert-manager : les CertificateRequest et les Bundle de trust-manager ;
- Prometheus Operator : les Alertmanager et ThanosRuler ;
- Kyverno, Kro, TLSRoute de la Gateway API, les ressources AWS ACK, FlinkSessionJob et les jobs Medusa.
La logique est limpide : les clusters modernes sont de plus en plus gouvernés par des opérateurs qui créent des CRD, et un outil de GitOps qui ne sait pas lire l’état réel de ces ressources les déclare « synchronisées » alors qu’elles sont en échec. Ajouter CloudNativePG ou cert-manager à la bibliothèque, c’est permettre à Argo CD de bloquer une vague quand le cluster de base de données ou l’émission de certificats n’est pas prêt, plutôt que de dérouler la suite sur une fondation bancale.
L’ajout des actions hibernate/rehydrate pour CloudNativePG illustre la profondeur atteinte : au-delà du simple état de santé, Argo CD comprend désormais le cycle de vie complet d’un cluster PostgreSQL opéré — le mettre en veille pour réduire les coûts, puis le réveiller avant une vague. C’est exactement le genre de capacité qui évite qu’une équipe déploie sur une base « synchronisée » mais en réalité endormie ou en restauration. La bibliothèque de health checks cesse d’être un simple confort pour devenir un garde-fou : elle transforme un statut Git — « la ressource est là » — en un état réel — « la ressource est prête ».
Cette frontière, ténue mais décisive, sépare une synchronisation d’une mise à disposition. Et parce que ces contrôles sont déclaratifs et versionnés comme le reste du manifeste, ils voyagent avec l’application d’un cluster à l’autre, sans configuration ad hoc ni script externe. Pour une équipe plateforme, c’est la garantie que la même rigueur s’applique au premier cluster comme au deux-centième — exactement le type de propriété qui fait la différence entre un outil que l’on utilise et un outil auquel on confie un parc entier.
Le corollaire est que ces contrôles ne coûtent rien à adopter : ils arrivent avec la mise à niveau, sans migration de données ni réécriture de manifests. C’est rare, pour un changement de cette portée, et c’est ce qui en fait une décision facile.
Une chaîne de déploiement un peu plus ferme
La sécurité du pipeline de livraison n’est pas en reste. Le projet active Zizmor dans sa CI pour faire respecter des configurations sûres sur ses propres workflows, et rend la version minimale de TLS du front Dex configurable, ainsi que le type de stockage de Dex via la ConfigMap argocd-cm. Côté distribution, les images et les binaires restent signés par cosign et accompagnés d’une provenance SLSA niveau 3.
Sur le plan opérationnel, la CLI apprend à exclure le champ status lors d’un argocd admin export, et le contrôleur accepte des flags de métriques et de conditions via argocd-cmd-params-cm. Ce sont des détails de confort, mais ils indiquent une direction : la 3.6 traite l’exploitation d’Argo CD comme un problème de premier ordre, pas comme un détail laissé aux intégrateurs.
Verdict
Argo CD 3.6 est une version de maturité : elle ne réinvente pas le produit, elle rend mesurables et pilotables des fonctions qui existaient déjà, et elle élargit la couverture des health checks à l’écosystème operator qui domine les clusters en 2026. Si vous déployez en progressive sync — ou si vous comptez le faire —, cette version est celle qui vous donne les métriques et les conditions nécessaires pour l’exploiter en production sans filet ; prévoyez de basculer dès la sortie stable. Si vous ne déployez pas encore en vague, l’argument décisif est ailleurs : la bibliothèque de health checks enrichie protège tout le monde, y compris les équipes qui synchronisent simplement, en empêchant Argo CD de déclarer sain un CloudNativePG ou un cert-manager qui ne l’est pas. Si vous hésitez encore entre Flux et Argo CD, ce n’est pas cette version qui tranchera — mais elle élargit l’écart sur un point précis : la profondeur de lecture de l’état réel de vos CRD.