Quand une automatisation tombe en panne : préparer la reprise avant l’incident

L’incident commence parfois sans message d’erreur

Le traitement s’exécute, mais les données sont incomplètes ou une étape métier n’est plus réalisée. Une surveillance limitée à la disponibilité du serveur peut rester au vert. Il faut observer les résultats attendus : dossiers terminés, délais et écarts.

Définissez quelques signaux liés au service. L’approche SRE documentée par Google distingue indicateurs et objectifs de niveau de service ; l’intérêt pour une PME est de mesurer ce que l’utilisateur subit, pas de multiplier les métriques techniques sans action possible.

Savoir arrêter sans perdre le travail

Prévoyez un mécanisme qui suspend les nouvelles actions tout en conservant les demandes en attente. L’arrêt doit être accessible à une personne autorisée et documenté. Une coupure brutale peut laisser des opérations dans un état inconnu.

Séparez traitement commencé, effet externe confirmé et résultat enregistré. Cette distinction permet de décider s’il faut relancer, consulter un fournisseur ou effectuer une correction. Une action déjà envoyée ne doit pas être répétée simplement parce que sa confirmation interne manque.

Reprendre avec les mêmes protections

Les mécanismes d’idempotence et de suivi d’événements limitent les doubles effets lors des tentatives. Les documentations Stripe illustrent ces précautions pour les paiements, mais le principe concerne aussi la création de dossiers ou l’envoi de commandes.

La reprise manuelle doit utiliser les mêmes identifiants et règles. Un bouton administratif qui contourne les contrôles peut créer des doublons. Consignez l’intervention, son auteur et sa raison, sans copier de secrets dans les journaux.

Pour approfondir : Idempotent requests | Stripe API Reference

Scénario : une interruption entre paiement et livraison

Un paiement est confirmé chez le prestataire, mais le système interne s’arrête avant d’enregistrer la livraison. Relancer toute la chaîne pourrait tenter une nouvelle opération. Le support doit d’abord consulter les états et rapprocher les identifiants.

Dans cet exemple fictif, la procédure distingue vérification du paiement et exécution de la livraison manquante. Elle prévoit aussi l’information du client. Une restauration de base ne suffit pas : les effets externes survenus depuis la sauvegarde doivent être recensés et rapprochés.

Répartir les responsabilités pendant l’incident

Désignez qui coordonne, qui intervient et qui communique. Une petite équipe peut cumuler les rôles, mais doit éviter que plusieurs personnes modifient simultanément le même état sans se parler. Gardez une chronologie des observations et actions.

Préparez un message interne indiquant le périmètre affecté et les tâches à suspendre. Le client doit recevoir une information proportionnée et vérifiée. Ne promettez pas une heure de reprise que l’équipe ne peut pas justifier ; indiquez plutôt le prochain point d’information.

Apprendre sans transformer l’incident en recherche de faute

Après la reprise, examinez déclencheur, détection, durée et effets. Identifiez une correction qui réduit le risque ou accélère la reprise. Une réunion qui se termine seulement par « faire plus attention » ne change pas le système.

Nous recommandons un exercice périodique sur un environnement maîtrisé. Votre équipe saurait-elle arrêter et reprendre le flux si son développeur habituel était absent ? Si non, le plan doit être simplifié et testé. L’automatisation crée de la valeur lorsqu’elle reste exploitable pendant les situations imparfaites.