Quand un flux API critique tombe, l’entreprise ne manque pas seulement de technique. Elle manque souvent d’un ordre de décision partagé.
Le runbook évite d’improviser au mauvais moment. Il dit qui qualifie, qui décide, quoi couper, quoi rejouer, quoi annoncer et quelles preuves conserver.
Une intégration API fiable doit prévoir son incident avant de le subir.
La qualité d’un runbook se mesure pendant la pression : il doit réduire le nombre de décisions floues, protéger les flux money et empêcher les reprises massives qui créent des doublons.
Le bon runbook
Un runbook utile ne raconte pas toute l’architecture. Il donne une séquence de décisions courtes, vérifiables et réutilisables sous pression.
Décider avant la panique
La panique crée des resync massifs, des corrections invisibles et des messages contradictoires. Le runbook pose un cadre avant l’urgence.
Il doit être connu des équipes métier et technique.
Qualifier l’incident
Le premier réflexe consiste à qualifier le périmètre : flux touché, période, objets, volume, criticité, système source et système cible.
Sans périmètre, chaque action élargit le risque.
La qualification doit séparer panne totale, dérive partielle, retard, rejet métier et incohérence de données. Le bon remède dépend de cette lecture.
Prioriser les flux money
Commandes, paiements, stocks, factures et leads chauds ne doivent pas être traités comme un export secondaire.
Le runbook doit classer ce qui protège le cash et la promesse client.
Rassembler les preuves
Logs, payloads, statuts, identifiants externes, erreurs, horodatages et décisions doivent être conservés. La preuve évite de corriger à l’aveugle.
Elle prépare aussi le post-mortem.
Les preuves doivent être compréhensibles par le métier. Un identifiant commande, un timestamp, une cause et une action possible valent mieux qu’une trace technique inexploitable.
Contenir sans aggraver
Contenir peut vouloir dire stopper une file, réduire la cadence, isoler un endpoint ou bloquer une famille d’objets.
Le premier réflexe consiste à arrêter la création de nouveaux écarts.
Reprendre proprement
La reprise doit être bornée par période, identifiant, statut ou lot. Elle doit être idempotente pour éviter les doublons.
Une reprise trop large cache parfois l’écart sans le corriger.
Le runbook doit préciser le seuil de validation avant relance : échantillon, contrôle métier, comparaison source-cible et feu vert explicite.
Informer les bonnes équipes
Support, finance, commerce et logistique n’ont pas besoin du même niveau de détail. Ils ont besoin de savoir quoi dire et quoi ne pas promettre.
Le message doit rester stable.
Le runbook doit prévoir des messages par audience : client final, équipe support, direction, finance ou partenaire externe. Chacun doit recevoir une vérité cohérente, mais limitée à ce qui permet d’agir sans propager l’incertitude.
Rollback ou correction ciblée
Le rollback est utile quand une version crée l’incident. La correction ciblée est préférable quand l’écart concerne des objets précis.
Le runbook doit éviter le réflexe “on relance tout”.
Le critère doit être explicite : si la version produit encore des écarts, rollback; si la version est saine mais certains objets sont faux, correction ciblée. Cette séparation évite de mélanger incident logiciel et reprise métier.
Post-mortem actionnable
Le post-mortem doit produire des actions : alerte, test, seuil, runbook, responsabilité ou dette à traiter.
- Qualifier le flux touché.
- Stopper la dérive.
- Conserver les preuves.
- Rejouer par périmètre.
- Fermer par action corrective.
Le post-mortem ne doit pas chercher un coupable. Il doit rendre l’incident moins probable, moins long ou moins coûteux la prochaine fois.
Conclusion : répéter sans improviser
Un runbook incident API transforme une crise en séquence maîtrisée. Il protège le run, les équipes et la confiance client.
Il donne surtout une mémoire à l’organisation : les mêmes erreurs ne doivent pas être redécouvertes à chaque panne de flux.
Sur commandes, paiements, stocks ou factures, la priorité est de contenir vite, reprendre proprement et prouver ce qui a été corrigé.
Pour rendre la reprise sûre, relisez l’idempotence API, puis cadrez les flux critiques avec l’intégration API Dawap.
