Argo CD 3.6 bascule l’observabilité des déploiements GitOps dans le noyau du projet
Sortie le 3 novembre 2026, Argo CD 3.6 apporte des métriques de synchronisation progressive aux ApplicationSets, durcit le TLS de Dex et remplace des scripts Lua maison par des health checks natifs. Pour un opérateur, c’est moins de code de colle à maintenir et une signature SLSA de niveau 3 sur chaque artefact.
3 novembre 2026. Le projet Argo CD publie la version 3.6.0 de son orchestrateur de déploiement continu GitOps, suivie dès le 4 novembre d’un correctif 3.6.1. 3 novembre 2026. La nouveauté de fond tient en trois mots : observabilité, durcissement et health checks natifs. 3 novembre 2026. Les images et binaires sont signés cosign avec une provenance SLSA de niveau 3. Pourquoi c’est important : cette version ne vend pas une fonctionnalité spectaculaire — elle réduit la surface de colle artisanale qu’un opérateur doit entretenir autour de son GitOps.
Les ApplicationSets gagnent des métriques de synchronisation progressive
Le point le plus visible concerne les ApplicationSets, le mécanisme qui déploie un même ensemble d’applications sur de nombreux clusters. La synchronisation progressive (progressive sync) — qui déroule les vagues de déploiement étape par étape plutôt que tout d’un bloc — recevait jusqu’ici peu de signaux observables : difficile de savoir, en cours de vague, combien d’applications avaient déjà basculé.
3.6.0 comble ce trou avec des métriques de synchronisation progressive exposées par l’ApplicationSet controller, un compteur d’actualisations déclenché pendant la progression, et la remontée du scénario de progression dans les conditions de la ressource. S’y ajoute une annotation de réconciliation forcée qui permet de reprendre la main avant de passer à la vague suivante — uniquement sur les applications pilotées par un ApplicationSet en mode progressif, pas sur les applications autonomes. Des flags de rate limiter sur le contrôleur complètent le tableau.
Pour un SRE, c’est la différence entre déployer à l’aveugle et déployer sous contrôle : on mesure désormais la progression d’un roll-out multi-clusters avec les mêmes réflexes que la télémétrie d’une application.
Dex : le durcissement TLS devient configurable
Dex, le pont SSO d’Argo CD vers les fournisseurs d’identité, est un maillon sensible : c’est lui qui tient la porte d’entrée authentifiée du plan de contrôle. 3.6.0 rend sa configuration TLS pilotable depuis argocd-cm : suites de chiffrement et préférences de courbes explicites, version TLS minimale configurable, et même le type de stockage de Dex.
L’enjeu n’est pas cosmétique. Une suite de chiffrement trop permissive ou une TLS 1.0 encore autorisée sont exactement le genre de faiblesse que les audits de conformité relèvent, et qu’un RSSI demande de fermer. Pouvoir les figer dans la config déclarative — donc versionnées dans Git — plutôt que dans un fichier d’un conteneur, c’est rendre le durcissement auditable et reproductible. La contrepartie opérationnelle : ces changements ne prennent effet qu’après un redémarrage du pod dex-server.
Des health checks natifs à la place des scripts Lua maison
Le changement le plus structurant pour un opérateur de longue date est l’arrivée d’une vague de health checks natifs pour des ressources CustomResourceDefinition jusqu’ici couvertes par des scripts Lua dans resource.customizations. Argo CD sait désormais évaluer nativement l’état de santé de CloudNativePG (bases et sauvegardes), cert-manager (demandes de certificat, ordres ACME), Velero (sauvegardes, restaurations, planifications), Tekton (PipelineRun, TaskRun), l’opérateur Prometheus (Alertmanager, ThanosRuler), Kyverno, les ressources AWS ACK, Kro, Flink et Medusa, ainsi que Gateway API (TLSRoute, ListenerSet).
Pourquoi ça compte : ces scripts Lua maison constituent de la dette opérationnelle. Ils cassent aux mises à jour de CRD, ils divergent d’un cluster à l’autre, et personne ne les documente. Les remplacer par des health checks maintenus par le projet — synchronisés sur les versions des opérateurs — c’est supprimer du code de colle et aligner le verdict de santé sur la communauté plutôt que sur un script local. Les opérateurs concernés doivent retirer leurs anciennes surcharges Lua pour ne pas masquer les nouveaux contrôles natifs.
Signature, provenance et petits gains d’exploitation
Le reste de la version consolide la chaîne d’approvisionnement et l’observabilité. Les spans OpenTelemetry du projet deviennent échantillonnables par configuration. L’hydrator — le composant qui réécrit les manifests avant commit — gagne des métriques et un support alpha de la signature des commits hydratés. La CLI argocd admin export apprend un flag --exclude-status qui produit des exports plus légers et plus faciles à diffuser.
Côté sécurité, deux points méritent attention. Les artefacts sont signés cosign avec une provenance SLSA niveau 3 — un prérequis de plus en plus fréquent dans les politiques de supply chain. Et une option permet de désactiver l’application stricte de l’impersonation multi-tenant : pratique pour certaines migrations, mais à évaluer soigneusement avant de l’activer, car elle assouplit un contrôle de sécurité.
Le signal derrière les health checks : le GitOps sort de l’enfance
La vague de health checks natifs n’est pas qu’une commodité : c’est un signal de maturité pour l’écosystème entier. Quand Argo CD intègre nativement l’état de santé de CloudNativePG, de cert-manager ou de Velero, cela veut dire que ces opérateurs sont devenus assez répandus pour mériter un support de premier ordre dans l’outil de référence du GitOps. Le projet absorbe ce que les équipes faisaient à la main, et c’est le bon mouvement : la customisation est un coût, la normalisation est un produit.
Le contraste avec l’autre grand moteur, Flux, est instructif. Là où Flux mise sur une composition de contrôleurs légers et une surface minimale, Argo CD concentre davantage de logique dans un plan de contrôle riche, et assume d’en faire le catalogue des bonnes pratiques d’exploitation. Les deux approches restent valables, mais la direction de 3.6.0 est claire : Argo CD veut être l’endroit où l’observabilité du déploiement vit en standard, pas en plugin.
Il faut aussi lire 3.6.0 à la lumière du correctif 3.6.1, publié le lendemain. Un plan de contrôle GitOps est une pièce critique de la chaîne de livraison : la prudence commande d’attendre la première correctif avant un déploiement large, et de vérifier la signature cosign de l’image qu’on déploie. Sur ce point, Argo CD a fait sa part, c’est à l’opérateur de faire la sienne.
Pour un SRE qui pilote des dizaines de clusters, cette version trace une ligne directrice simple : tout ce qui touche au déploiement doit être mesurable, signé et réversible. Les métriques de synchronisation progressive, les spans OpenTelemetry échantillonnables et les health checks natifs convergent vers ce but : rendre le roll-out aussi instrumenté qu’une application en production. C’est exactement la discipline qui manquait aux débuts du GitOps, où l’on traitait le déploiement comme un simple git push.
Verdict
Si vous exploitez Argo CD en production, la mise à niveau vers 3.6.1 est un chantier à faible risque et à fort rendement : pas de rupture signalée, mais un ensemble de gains qui réduisent votre code de colle. Déployez avec un kubectl apply --server-side --force-conflicts sur les manifests v3.6.1 — les CRD d’Argo CD sont volumineuses et échouent sans --force-conflicts — puis retirez vos surcharges Lua devenues redondantes pour profiter des health checks natifs. Si vous déployez multi-clusters avec des ApplicationSets progressifs, activez dès maintenant les nouvelles métriques : c’est le seul moyen de piloter une vague autrement qu’à l’aveugle. Et si vous êtes audité sur le SSO, figez les suites de chiffrement et la version TLS minimale de Dex dans argocd-cm — un redémarrage du pod, et le durcissement est dans Git, pas dans un conteneur.