Rollback et reprise après incident avec ArgoCD

Un déploiement casse la production, et vous devez revenir à la version d'avant, vite. ArgoCD garde l'historique de chaque synchronisation et sait rejouer une version antérieure. Ce guide montre comment lire cet historique, faire un rollback en urgence, et surtout quelle est la vraie méthode GitOps pour revenir en arrière proprement. Toutes les sorties viennent d'un cluster k3d réel (ArgoCD v3.4.5). Public : personnes qui exploitent ArgoCD et doivent gérer un incident. Prérequis : une première application synchronisée.

Ce que vous allez apprendre

Lire l'historique de déploiement d'une Application
Comprendre pourquoi le rollback exige de désactiver l'auto-sync
Revenir à une version précédente en urgence (CLI et interface)
Choisir entre rollback ArgoCD et git revert (la vraie méthode GitOps)
Connaître les limites du rollback (données, hooks, migrations)
Sauvegarder et restaurer ArgoCD avec argocd admin export

L'historique de déploiement

À chaque synchronisation vers une nouvelle révision Git, ArgoCD enregistre une entrée d'historique. C'est ce journal qui rend le rollback possible. On le consulte avec la CLI :

argocd app history guestbook

SOURCE  https://github.com/argoproj/argocd-example-apps.git
ID      DATE                            REVISION
0       2026-07-16 08:50:06 +0200 CEST  HEAD (8088f4c)

Chaque ligne associe un ID d'historique à une révision Git (le commit réellement déployé) et à sa date. C'est cet ID que le rollback prend en argument, pas le SHA du commit. Par défaut, ArgoCD conserve les 10 dernières entrées (réglable via spec.revisionHistoryLimit).

Pourquoi il faut d'abord désactiver l'auto-sync

C'est le piège numéro un. Si l'Application a l'auto-sync activé, ArgoCD refuse le rollback. Voici le comportement réel sur le cluster :

argocd app rollback guestbook 0

FATA[0000] rpc error: code = FailedPrecondition
desc = rollback cannot be initiated when auto-sync is enabled

La raison est logique : un rollback fait diverger le cluster de Git (vous déployez une version qui n'est plus celle de la branche suivie). Avec l'auto-sync, ArgoCD re-synchroniserait aussitôt vers HEAD et annulerait votre rollback dans la seconde. Il faut donc d'abord couper l'auto-sync.

Faire un rollback en urgence

La procédure complète, du gel de l'auto-sync à la vérification :

Identifier la version cible dans l'historique :
Fenêtre de terminal
```
argocd app history guestbook
```
Repérez l'ID de la dernière version saine.
Désactiver l'auto-sync (sinon le rollback est refusé) :
Fenêtre de terminal
```
argocd app set guestbook --sync-policy none
```
Lancer le rollback vers l'ID choisi :
Fenêtre de terminal
```
argocd app rollback guestbook <ID>
```
ArgoCD réapplique les manifestes de cette révision et attend que l'Application redevienne Healthy.

Vérifier que le service est rétabli :

argocd app get guestbook
kubectl -n guestbook get pods

Le service est de nouveau sur la version stable. L'incident est contenu, mais pas clos : il reste à réparer Git.

Rollback depuis l'interface

L'interface expose la même fonction sans ligne de commande. Sur la vue détail d'une Application, le bouton HISTORY AND ROLLBACK (visible en haut de l'arbre de ressources) ouvre la liste des déploiements passés ; un clic sur Rollback en face d'une entrée rejoue cette version. L'interface demande aussi de couper l'auto-sync au préalable, avec le même message.

La vraie méthode GitOps : git revert

Le rollback ArgoCD est un outil d'urgence, pas la façon normale de revenir en arrière. En GitOps, Git est la source de vérité : si le cluster doit repasser à l'état d'avant, c'est Git qui doit exprimer cet état.

La bonne séquence après un incident :

Contenir l'incident avec le rollback ArgoCD (ci-dessus), pour rétablir le service tout de suite.
Réparer dans Git : annuler le commit fautif.
Fenêtre de terminal
```
git revert <sha-du-commit-fautif>
git push
```
Réactiver l'auto-sync :
Fenêtre de terminal
```
argocd app set guestbook --sync-policy automated
```
ArgoCD synchronise le cluster sur le nouveau HEAD (qui contient le revert). L'Application repasse Synced + Healthy, et le cluster est de nouveau aligné avec Git.

Sauvegarder et restaurer ArgoCD

Le rollback annule un déploiement applicatif ; il ne protège pas ArgoCD lui-même. Si vous perdez le cluster de gestion, vous perdez vos Applications, AppProjects, dépôts et réglages. La CLI fournit une sauvegarde complète de l'état ArgoCD :

# Exporter tout l'état ArgoCD dans un fichier YAML
argocd admin export -n argocd > argocd-backup.yaml

kind: ConfigMap    name: argocd-cm
kind: ConfigMap    name: argocd-rbac-cm
kind: Secret       name: argocd-secret
kind: AppProject   name: default
kind: Application   name: guestbook
kind: Application   name: helm-guestbook
...

L'export contient les ConfigMaps de configuration, les Secrets (dépôts, clés), les AppProjects et toutes les Applications. La restauration se fait avec la commande inverse :

# Réimporter l'état sur une instance neuve
argocd admin import -n argocd - < argocd-backup.yaml

Conservez cet export dans un stockage sûr et chiffré (il contient des secrets), et rejouez-le lors d'une reconstruction ou avant une montée de version risquée.

Les limites du rollback

Un rollback rejoue des manifestes, il ne remonte pas le temps sur tout le reste. À garder en tête :

Les données ne reviennent pas. Si la version fautive a migré un schéma de base ou supprimé des lignes, le rollback des manifestes ne restaure pas la donnée. Prévoyez un plan de reprise des données à part.
Les migrations irréversibles posées par un hook PreSync ne se défont pas seules. Concevez les migrations pour être compatibles avec l'ancienne version le temps d'un rollback.
Les ressources supprimées avec prune sont recréées au rollback, mais leur contenu dynamique (un PersistentVolumeClaim par exemple) peut ne pas suivre.

Dépannage

Symptôme	Cause probable	Solution
`rollback cannot be initiated when auto-sync is enabled`	Auto-sync actif	`argocd app set <app> --sync-policy none` avant le rollback
Le rollback est aussitôt annulé	Auto-sync réactivé trop tôt	Réparer Git (revert) avant de réactiver l'auto-sync
ID d'historique introuvable	Au-delà de `revisionHistoryLimit`	Augmenter la limite, ou repartir d'un commit Git précis
Application saine mais données incohérentes	Le rollback ne restaure pas les données	Restaurer la base depuis une sauvegarde

À retenir

ArgoCD garde un historique de chaque synchro (argocd app history) ; le rollback prend l'ID d'historique, pas le SHA.
Le rollback est refusé si l'auto-sync est actif : rollback cannot be initiated when auto-sync is enabled. Couper l'auto-sync d'abord.
Un rollback rend l'Application OutOfSync par construction : c'est un état d'urgence, pas durable.
La vraie méthode GitOps est git revert + push : Git reste la source de vérité. Le rollback contient l'incident, le revert le referme.
Le rollback ne restaure pas les données ni les migrations irréversibles : prévoyez un plan de reprise dédié.

Pour aller plus loin

Sécuriser ArgoCD : RBAC, SSO et durcissement pour une installation prête pour la production.
Admission Controllers : Bloquer les déploiements fautifs à l'admission avec Kyverno et policy-as-code, pour réduire le besoin de rollback.