Stratégies de rollback pour les agents IA : comment rollback un release en sécurité

L’idée en 30 secondes

Les stratégies de rollback sont un mécanisme runtime de retour rapide du trafic vers une version stable quand un nouveau release dégrade les métriques.

Quand c’est nécessaire : quand un agent est livré via canary/rollout et qu’une régression en production doit être arrêtée sans long downtime.

Le problème

Sans rollback, l’équipe voit le problème mais ne peut pas en retirer vite l’impact. Pendant l’analyse, le trafic continue vers la version dégradée et l’incident grossit.

Scénario typique :

• error_rate ou latency_p95 augmente
• les utilisateurs tombent toujours sur la version problématique
• l’équipe fait des actions manuelles sous pression de temps

Analogie : c’est comme ne pas avoir de frein d’urgence. Quand le système est déjà en dérapage, une réaction lente coûte bien plus que le correctif lui-même.

Et chaque minute sans rollback ajoute des erreurs, des coûts et une perte de confiance.

La solution

La solution est de faire du rollback une couche policy séparée dans le runtime release flow. La policy vérifie les signaux de dégradation et décide : continuer le rollout ou renvoyer le trafic vers stable version.

Rollback policy layer renvoie une décision technique : allow ou stop avec raison :

• rollback_required
• sla_breach
• error_spike

En cas de stop, le système exécute un traffic switch contrôlé vers active stable version et enregistre l’événement dans l’audit log. C’est un contrôle d’urgence dédié, pas une improvisation manuelle pendant un incident.

Rollback ≠ kill switch

Ce sont des outils différents :

• Rollback renvoie à la version stable précédente.
• Kill switch arrête des actions ou du trafic sans changer de version.

L’un sans l’autre ne suffit pas :

• sans rollback, restaurer un fonctionnement normal après une régression de release est difficile
• sans kill switch, il est difficile de freiner vite les actions risquées jusqu’à la fin du rollback

Exemple :

• rollback : 2.4.0 -> 2.3.3 après error_spike
• kill switch : writes_disabled=true temporaire pendant le retour à stable version

Composants du contrôle rollback

Ces composants travaillent ensemble pendant chaque rollout.

Exemple d’alerte :

Slack: 🛑 Rollback triggered support-agent@2.4.0 -> 2.3.3, reason=error_spike, stage=canary.

À quoi ça ressemble dans l’architecture

Rollback policy layer se place entre release runtime et le trafic, et bloque un rollout dégradé avant son extension. Chaque décision (allow ou stop) est écrite dans l’audit log.

Chaque étape du rollout passe par ce flow avant l’augmentation de trafic : runtime ne scale pas candidate directement, il demande d’abord une décision à la policy layer.

Résumé du flow :

• Monitoring émet un signal de dégradation
• Policy vérifie error_rate, latency_p95, tool_failures, rollback_plan
• allow -> le rollout continue
• stop -> le trafic bascule vers active stable version
• les deux décisions sont écrites dans l’audit log

Exemple

Après le release support-agent@2.4.0, tool_failure_rate augmente en canary. Rollback policy renvoie stop (reason=rollback_required).

Résultat :

• le trafic revient à 2.3.3
• candidate est verrouillé pour toute extension supplémentaire
• l’équipe analyse la cause sans incident actif

Rollback réduit le dommage pendant l’incident, pas après son amplification.

En code, ça ressemble à ça

Le schéma simplifié ci-dessus montre le flow principal. Point critique : rollback doit être idempotent et rapide, pour qu’un signal répété ne casse pas le traffic switch.

Exemple de configuration rollback :

rollback:
  stable_version: support-agent@2.3.3
  candidate_version: support-agent@2.4.0
  triggers:
    error_rate_p95: 0.05
    latency_p95_ms: 1800
    tool_failure_rate: 0.03
  lock_candidate_after_rollback: true

release_cfg = load_release_config("support-agent")
signal = monitor.read(version_id=release_cfg.candidate_version)
decision = rollback_policy.check(signal, release_cfg)

if decision.outcome == "stop":
    switch_result = traffic.switch(
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

    if release_cfg.lock_candidate_after_rollback:
        rollout.lock(version_id=release_cfg.candidate_version)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
        switch_status=switch_result.status,
    )
    alerts.notify_if_needed(release_cfg.candidate_version, decision.reason)
    return stop(
        decision.reason,
        from_version=release_cfg.candidate_version,
        to_version=release_cfg.stable_version,
    )

allow_decision = Decision.allow(reason=None)  # standard allow outcome/reason model
audit.log(
    run_id,
    decision=allow_decision.outcome,
    reason=allow_decision.reason,
    version_id=release_cfg.candidate_version,
    stage="canary",
)
return continue_rollout()

À quoi ça ressemble pendant l’exécution

Scénario 1 : rollback_required en canary

1. La version candidate reçoit 5% de trafic.
2. Les métriques dépassent les seuils (error_rate et tool_failure_rate).
3. Policy renvoie stop (reason=rollback_required).
4. Le trafic revient vers stable version.
5. Candidate reste verrouillé jusqu’à l’analyse de l’incident.

Scénario 2 : false alarm, rollback non nécessaire

1. Monitoring signale un pic court, mais les seuils ne sont pas dépassés.
2. Policy renvoie allow.
3. Le rollout continue sur la stage actuelle.
4. L’événement est écrit dans l’audit log.
5. Le système reste stable sans rollback inutile.

Scénario 3 : signal répété après rollback

1. Après rollback, une autre alerte arrive avec le même signal.
2. La logique idempotente n’exécute pas un switch répété.
3. Policy renvoie un statut technique sans actions en double.
4. Les logs montrent que rollback a déjà été appliqué.
5. L’équipe travaille sur la root cause sans bruit additionnel.

Erreurs typiques

• rollback est seulement manuel, sans triggers policy
• aucune stable version n’est disponible pour retour rapide
• candidate n’est pas verrouillé après rollback
• rollback fait le switch, mais ne vérifie pas les métriques de recovery
• pas d’idempotency pour signaux rollback répétés
• l’audit log ne contient pas from/to version et reason

Résultat : rollback semble exister, mais pendant un incident il est lent et imprévisible.

Auto-vérification

Vérification rapide de la stratégie rollback avant lancement en production :

FAQ

Q : Quand déclencher rollback automatiquement, et quand manuellement ?
A : Pour des seuils SLO clairs, l’automatique est préférable. Pour les cas ambigus (par exemple opération business risquée), utiliser human approval au-dessus de la policy.

Q : Rollback et kill switch se doublonnent-ils ?
A : Non. Rollback restaure stable version, kill switch limite vite les actions. En production, ils doivent fonctionner ensemble.

Q : Que faire après rollback ?
A : Capturer un incident snapshot (version, reason, métriques), verrouiller candidate et relancer rollout seulement après correctif et vérification.

Q : Faut-il rollback s’il y a déjà un canary ?
A : Oui. Canary réduit seulement le blast radius, rollback est nécessaire pour revenir vite à un état stable.

Q : Quels champs logger obligatoirement ?
A : reason, from_version, to_version, stage, switch_status, timestamp, actor (si rollback manuel).

Où Rollback se place dans le système

Les stratégies rollback sont une des couches d’Agent Governance. Avec versioning, limites, budgets, approval et audit, elles forment un système de changements sûrs en production.

Pages liées

Suite du sujet :

• Vue d’ensemble Agent Governance — modèle global de contrôle des agents en production.
• Agent Versioning — comment contrôler les changements prompt/tools/policy avant rollback.
• Kill switch — comment limiter instantanément les actions pendant un incident.
• Rate limiting pour agents — comment contenir les pics pendant la dégradation.
• Audit logs pour agents — comment reconstruire la chaîne de décisions rollback.