Gérer une panne d’intégration avec des états fidèles

Pendant une panne d’intégration, rendez visible ce que le logiciel sait réellement. Un portail peut amortir une interruption, mais il ne doit pas présenter un traitement ERP encore ouvert comme une commande terminée. Des états traçables et une reprise contrôlée sont déterminants.

Déterminer le dernier état établi de manière fiable

Dans un portail fictif, un client envoie une requête de création de commande. L’ERP est temporairement inaccessible. Le portail doit pouvoir déduire de son propre état de traitement enregistré de manière fiable si la requête a été acceptée. Un affichage seul ne conserve pas une requête.

Ces états sont notre modèle d’exemple. Les libellés doivent correspondre aux preuves réelles de l’application. Une réception HTTP rapide et réussie ne prouve pas, à elle seule, que la commande a été créée.

Rattacher les répétitions à la même opération

Si un client renvoie sa requête parce que l’affichage reste indéterminé, l’application doit pouvoir reconnaître si la même commande est visée. Définissez l’identifiant utilisé, son périmètre et le traitement des requêtes déjà exécutées. Stripe décrit les livraisons multiples d’événements comme un cas précis de webhook ; cela ne définit pas une règle universelle de répétition pour votre ERP.

Vérifiez notamment le cas où la commande ERP a été créée mais où sa réponse a été perdue. Une nouvelle tentative ne doit pas déclencher une deuxième création sans vérification.

Définir les responsabilités et la communication

Déterminez qui évalue la panne, qui autorise la reprise du traitement et qui actualise l’état visible. Le Google SRE Workbook distingue la résolution d’un incident de sa coordination et de la communication. Une petite équipe peut réunir les rôles, mais elle a toujours besoin de responsabilités claires.

Reprendre de manière contrôlée après le rétablissement

L’accessibilité de l’ERP est le point de départ de la vérification. Clarifiez les requêtes ouvertes et celles déjà traitées avant d’exécuter à nouveau le travail en attente. N’affichez l’état confirmé que lorsque la preuve correspondante existe.

Testez une panne avant l’enregistrement, une panne après l’enregistrement et une réponse ERP perdue. Vérifiez l’état visible dans le portail et le nombre réel de commandes créées. Vous saurez ainsi si le retour reste fidèle lorsque le client subit directement la panne.

Sources

• Google SRE Workbook: Incident Response

• Stripe: Webhooks