Exemple illustratif : une panne coupe l’import des commandes alors que les stocks continuent de bouger et que le repricer publie encore. En dix minutes, trois équipes lancent des vérifications différentes, deux personnes relancent le même lot et le support ne sait pas quoi promettre. Le problème technique initial et cette friction organisationnelle créent une désynchronisation de décisions, plus difficile à réparer que le composant tombé.
Le vrai enjeu d’un runbook vendeur marketplace est de rendre l’action reproductible sous pression. Il doit dire qui décide, quelles preuves prendre, quoi geler et comment revenir. Contre-intuitivement, sa valeur ne vient pas de sa longueur : une page testée avec les bons liens protège mieux qu’un manuel exhaustif introuvable lorsque la panne majeure commence.
Une agence marketplace spécialisée dans le run vendeur construit ce dispositif autour de décisions exécutables. Le premier signal faible apparaît lorsque les gestes d’urgence vivent dans la mémoire d’une seule personne. Le second se voit quand un document décrit la correction technique mais oublie commandes, support, finance et critères de sortie.
Faire du runbook un outil exécutable
Écrire pour une personne qui découvre la crise
Le runbook relie signal, décision, action, preuve et résultat. Chaque étape commence par une condition observable et se termine par un état vérifiable. Les verbes vagues — surveiller, vérifier, prévenir — sont remplacés par source, requête, destinataire, seuil et délai. Une personne de permanence doit pouvoir l’utiliser sans explication orale.
Le document ne remplace ni diagnostic ni jugement. Il sécurise les premières décisions répétables, préserve les données et indique quand escalader. Les variantes rares restent dans des annexes ou des fiches liées. Le chemin principal doit rester visible sur écran réduit et accessible si l’outil de documentation habituel tombe.
La réussite se mesure au temps gagné avant contention et à la qualité de reprise, pas au nombre de pages. Un runbook qui n’a jamais été exécuté demeure une hypothèse opérationnelle.
Borner les scénarios couverts
Regrouper par conséquence plutôt que par composant
Les scénarios couvrent commandes absentes, stock non fiable, prix dangereux, diffusion interrompue, statuts divergents, paiements incertains et dépendance marketplace. Un même composant peut produire plusieurs conséquences ; plusieurs composants peuvent produire la même. Le runbook se déclenche depuis ce que le run observe, avant que la cause soit connue.
Chaque scénario précise inclusions et exclusions. Une erreur sur cinq offres ne mobilise pas la procédure majeure ; un taux de rejet croissant sur un canal stratégique peut la déclencher. Les incidents de sécurité ou de données personnelles basculent vers leurs procédures spécialisées tout en conservant la coordination marketplace nécessaire.
Préparer les prérequis hors crise
Contacts, astreintes, droits, tableaux, sources, contrats et chemins de support sont vérifiés régulièrement. Les commandes de diagnostic sont en lecture seule par défaut. Les comptes d’urgence portent un propriétaire et une procédure d’ouverture. Les exports essentiels restent disponibles hors du composant surveillé.
Le document donne URLs exactes, rôle attendu et solution de repli. Une dépendance critique sans contact ou un tableau inaccessible depuis l’astreinte crée un risque avant toute panne. Les prérequis ont une date de dernier test ; une simple date de dernière modification du texte ne prouve pas leur fonctionnement.
Déclencher sans débat inutile
Un déclencheur associe population, vitesse, impact ou indisponibilité à un niveau de réponse. À titre d’exemples internes à calibrer : commandes sans accusé depuis quinze minutes, stock plus vieux que le seuil, prix sous plancher ou lot rejeté au-delà d’un ratio. La source de mesure et la fenêtre de confirmation sont explicites.
Si le seuil est franchi avec une propagation active, alors le coordinateur ouvre le runbook avant la cause. Il peut le refermer après qualification si le périmètre reste borné. Cette asymétrie coûte moins cher que vingt minutes de débat pendant lesquelles de nouvelles commandes ou valeurs fausses continuent d’entrer.
Structurer les quinze premières minutes
Observer, contenir, décider et annoncer
Les cinq premières minutes confirment signal, heure, population et source. Les cinq suivantes choisissent contention et responsables. Les cinq dernières publient un premier point avec impact, action, décision attendue et prochaine mise à jour. Ce rythme donne une structure, sans promettre que chaque cause sera trouvée en quinze minutes.
L’équipe capture les données volatiles avant toute relance, sauf si une action immédiate protège un risque irréversible. Elle n’exécute pas deux corrections concurrentes. Le coordinateur indique ce qui est gelé, qui diagnostique et quand les hypothèses seront réévaluées. Cette clarté réduit les messages sans bloquer l’initiative.
Distribuer les rôles
Le coordinateur tient rythme et décisions ; le responsable technique mène diagnostic ; le métier choisit la promesse ; le scribe conserve chronologie ; la communication informe les audiences. Support, finance et logistique rejoignent selon la population. Un rôle possède un suppléant pour chaque plage de permanence.
La même personne peut cumuler deux fonctions dans une petite équipe, mais la responsabilité reste nommée. Le diagnostic ne doit pas être interrompu par toutes les questions de statut. La méthode pour escalader un incident sans perdre des heures précise mandat, paquet et échéance.
Tenir une chronologie unique
La chronologie enregistre horodatage, fait, source, décision, action, responsable et échéance. Elle ne copie pas chaque conversation. Une estimation est identifiée comme telle, puis remplacée explicitement lorsqu’une preuve arrive. Les décisions orales sont écrites immédiatement avec leur périmètre.
Cette mémoire facilite relève, communication et retour d’expérience. Elle évite aussi de répéter une expérience ou de relancer un flux déjà traité. Une horloge commune est utilisée entre outils ; sinon le décalage est documenté. Les données sensibles restent dans leurs systèmes, reliées par identifiants adaptés.
Constituer le paquet de faits
Rendre l’état compréhensible en deux minutes
Le paquet contient symptôme, première occurrence, dernière réussite, canaux, populations confirmée et possible, tendance, impact, actions menées, hypothèses, inconnues et prochaine décision. Les liens vers journaux ou exports complètent la synthèse sans la rendre illisible.
Chaque version porte une heure. Une personne qui rejoint la crise comprend ce qui change depuis le point précédent. Le paquet distingue exposition et dommage, puis indique la donnée susceptible de modifier l’action. Il devient la base commune des escalades internes et externes.
Geler ce qui aggrave l’écart
Le gel peut arrêter un traitement par lot, désactiver un repricer, bloquer un webhook, masquer une population ou réduire une cadence. Il vise le mécanisme de propagation avec le plus petit périmètre défendable. L’action porte heure, exécuteur, objets, conséquence, durée et condition de levée.
Un gel sans visibilité crée une seconde panne. La supervision vérifie qu’il est effectif et que les files ne saturent pas ailleurs. Le cadre de quarantaine d’un flux vendeur aide à séparer objets douteux et population saine.
Classer les objets critiques
Les commandes payées, prix sous marge, stocks à survente, remboursements sensibles et statuts avant l’heure limite précèdent généralement l’enrichissement ou les mises à jour non urgentes. La priorité dépend toutefois de la prochaine perte évitable, de la propagation et de la réversibilité.
Le cadre pour prioriser les incidents qui mangent la marge évite que la file la plus bruyante monopolise les équipes. Le runbook conserve une règle simple par scénario et renvoie au tableau de tri pour l’ordre détaillé.
Protéger les commandes
Maintenir identité, état et capacité de reprise
Le runbook capture commandes reçues, accusées, réservées, payées, préparées et expédiées. Il sépare absentes, doublons, statuts en retard et commandes sans stock. Les heures limites déterminent celles qui peuvent encore être sauvées. Aucune relance globale ne précède cette segmentation.
Le contrat de secours décrit entrée, sortie, idempotence, responsable, seuil de file et délai. La journalisation conserve chaque verdict ; la supervision alerte sur l’âge ; une nouvelle tentative borne ses répétitions. Un retour arrière ou une file manuelle prend les cas ambigus. Ce bloc rend la reprise techniquement et opérationnellement contrôlable.
Protéger prix et stock
Un prix dynamique peut être gelé sur la dernière valeur approuvée ou borné par un plancher. Un stock incertain peut recevoir tampon, réserve ou retrait. Les règles dépendent de rotation, marge, âge de la source et délai de propagation. Une valeur unique pour tout l’assortiment serait dangereuse.
Le mode dégradé sur prix, stock et commandes fournit la matrice détaillée. Le runbook indique seulement quel scénario activer, qui l’autorise et où vérifier sa population. Cela garde le chemin de crise court.
Sécuriser finance et paiements
Capture, remboursement, annulation et reversement portent des effets différents. Le runbook interdit tout rejeu dont la preuve ou l’idempotence n’est pas garantie. Les transactions inconnues sont isolées avec identifiants PSP, commande, montant et état comptable avant correction.
Finance décide des doubles validations, seuils et délais de clôture. Les gestes commerciaux restent séparés des remboursements. Une seconde mise en œuvre décrit responsabilités, dépendances, mode de repli, journalisation et sortie. Cette précision évite qu’une urgence client crée un double mouvement financier.
Capturer les preuves utiles
Préserver les données volatiles sans retarder la protection
Les preuves incluent exemples, volumes, horodatages, version, corps de requête, réponse, corrélation et état métier. Une capture avant relance conserve la population. Les journaux bruts sont archivés avec leur période, mais la synthèse indique les lignes réellement utiles au diagnostic et à la décision.
Une capture parfaite ne justifie pas une survente supplémentaire. Le runbook fixe le minimum automatique et la preuve complémentaire après contention. Les accès restent en lecture seule lorsque possible. Les données personnelles sont minimisées ou masquées avant partage à un tiers.
Ordonner le diagnostic
Les hypothèses sont classées par capacité à expliquer la population et par coût de test. Chaque expérience a une question, une entrée, une sortie attendue et un seuil d’arrêt. Les résultats négatifs restent dans la chronologie afin qu’une relève ne recommence pas le même chemin.
Le diagnostic part des frontières : source, transformation, transport, accusé et effet final. Il compare dernier succès, premier échec et changements récents. Une correction n’est pas déployée seulement parce qu’elle semble plausible ; elle passe par un échantillon, une observation et un retour arrière adaptés à son risque.
Escalader vers les tiers
Marketplace, PSP, transporteur ou éditeur reçoivent identifiants contractuels, exemples reproductibles, horodatages, fréquence, impact et résultat attendu. Le chemin de sévérité et les contacts sont testés avant crise. Plusieurs tickets concurrents pour le même incident ralentissent la coordination.
La demande précise diagnostic, restauration ou délai. Chaque réponse est rapprochée des observations internes. Le tiers ne remplace pas la décision locale de geler ou communiquer. Un numéro unique et la prochaine relance figurent dans la chronologie avec un responsable.
Communiquer par audience
Donner un état stable sans promettre l’inconnu
Support, commerce, logistique, finance, direction et clients reçoivent impact, mesure, consigne et prochaine mise à jour adaptés à leur rôle. Les faits sont séparés des hypothèses. Une heure de résolution n’est pas annoncée tant que la cause et la trajectoire restent incertaines.
Le responsable de communication collecte les questions sans élargir la cellule. Les messages sont numérotés. Le support obtient populations et promesses autorisées, pas seulement « incident en cours ». Une information erronée est corrigée explicitement au point suivant.
Préparer les relèves
Une crise longue exige des plages, des suppléants et une passation. Le paquet de relève reprend population, décisions temporaires, hypothèses écartées, actions en cours, tiers, risques et prochaines échéances. Le nouveau titulaire reformule l’état avant de prendre le rôle.
Les experts sortants ne restent pas tous en veille permanente. Leur fatigue augmente le risque de correction. Une question bornée peut les rappeler, mais la responsabilité passe réellement. Les horaires de repas, de nuit et du lendemain sont préparés dès que la durée probable dépasse la première équipe.
Choisir la stratégie de reprise
Revenir par population, cadence et preuve
La reprise peut repartir du courant, rejouer les événements en attente, recalculer un état ou combiner ces options. Le choix dépend de la source de vérité et des effets déjà produits. Il est écrit avant l’exécution avec ordre, lots, contrôle, cadence, seuil de recul et responsable.
Le redémarrage après un incident majeur de diffusion détaille les paliers. Un job vert ne suffit pas : l’équipe vérifie l’état canal, les commandes et les systèmes aval avant d’augmenter le volume.
Rejouer sans doubles effets
Les événements en attente sont dédupliqués et comparés à l’état actuel. Un événement ancien peut être devenu faux après une correction manuelle ou une nouvelle commande. Les clés d’idempotence et états finaux empêchent facture, email, réservation ou remboursement de se reproduire.
Un échantillon couvre cas nominal, doublon, absence, délai et erreur aval. Les lots portent identifiants, début, fin, succès et exceptions. Si la divergence dépasse le seuil, alors le retour arrière ou le gel intervient immédiatement plutôt qu’une correction en direct au milieu du lot.
Définir les portes de sortie
Distinguer restauration, stabilisation et retour au nominal
La restauration remet une fonction ; la stabilisation confirme l’absence de nouvelle dérive ; le nominal retire les mesures temporaires et réconcilie les conséquences. Les portes couvrent files, prix, stock, commandes, paiements, droits, communication et capacité. Une personne autorisée signe chaque passage.
Les incidents résiduels peuvent quitter la cellule avec un responsable et un délai. Les alertes reviennent à leurs seuils ordinaires. Les canaux d’urgence et accès temporaires sont fermés. La conclusion de crise indique ce qui reste volontairement dégradé au lieu de déclarer un retour total trompeur.
Transformer l’incident en prévention
Le retour d’expérience reconstruit conditions, décisions et conséquences sans chercher un coupable. Il distingue cause de déclenchement, facteurs d’amplification et lacunes de récupération. Les temps jusqu’à détection, contention, décision, restauration et nominal révèlent où le dispositif a réellement perdu des heures.
Chaque action porte preuve attendue, responsable et échéance. Les corrections du runbook, alertes, tests, contrats et dettes techniques n’ont pas toutes la même priorité. La documentation des incidents orientée prévention aide à relier apprentissage et décision financée.
Maintenir le runbook vivant
Un exercice trimestriel teste scénario, droits, contacts, tableaux, contention et reprise. Il injecte une donnée manquante ou un tiers muet pour observer les décisions réelles. Les temps et erreurs mettent à jour le document. Une lecture collective sans exécution ne valide pas la chaîne.
Chaque changement majeur de canal, OMS, ERP, PSP ou astreinte déclenche une revue ciblée. Le document affiche propriétaire, version et dernière exécution. Les liens morts et personnes parties sont traités comme des anomalies opérationnelles avant la prochaine crise.
Cas concret illustratif : jouer une panne majeure
Contenir les commandes absentes puis réconcilier
Dans ce scénario chiffré fictif, à 14 h 05, aucun accusé OMS n’arrive depuis douze minutes alors que quarante-sept commandes apparaissent côté canal. Le runbook s’ouvre à 14 h 08. Les promotions sont suspendues, le stock tampon augmente et le support reçoit une consigne. La capture conserve les identifiants avant toute relance.
À 14 h 18, le diagnostic montre une authentification expirée. Les commandes sont présentes dans une file, non traitées. Le secret est renouvelé sur un environnement pilote ; cinq commandes passent sans doublon. La marge encore récupérable est estimée à 6 400 euros avant l’heure limite de 16 heures.
Deux lots de vingt puis le solde sont rejoués. Une commande déjà corrigée manuellement est écartée par sa clé. À 15 h 02, les accusés sont cohérents ; à 15 h 25, stock et préparation sont réconciliés. La cellule ferme, tandis qu’une rotation automatique du secret devient action prioritaire.
Gouverner le dispositif
Opérations possède le runbook ; les métiers valident promesses et priorités ; technique vérifie actions et reprise ; sécurité contrôle accès ; finance encadre mouvements sensibles. Une revue semestrielle examine couverture, exercices et changements. Les responsables de permanence participent à sa validation.
Ciama pour le pilotage marketplace peut centraliser signaux, chronologie et populations. Le service de run et supervision vendeur aide à concevoir les scénarios, jouer les exercices et mesurer la progression de la continuité.
Pour qui ce runbook convient-il ?
Le dispositif concerne responsables marketplace, opérations, intégration, support, logistique, finance, commerce et sécurité qui partagent la réponse à une panne majeure. Il devient indispensable lorsque plusieurs canaux ou systèmes peuvent diverger et que la personne experte n’est pas toujours présente.
Une petite équipe peut préparer trois scénarios et cumuler des rôles. Une organisation mature différencie domaines, astreintes et tiers. Dans les deux cas, le document reste court au premier niveau, accessible hors panne et testé avec les personnes qui l’exécuteront réellement.
Éviter les erreurs fréquentes
La première erreur écrit le runbook après l’incident sans le tester. La deuxième organise par application plutôt que par conséquence. La troisième oublie les métiers. La quatrième relance avant snapshot. La cinquième ne borne pas le gel, tandis que la sixième confond restauration et nominal.
Une autre dérive colle des journaux sans synthèse. Les contacts périmés, droits absents et procédures trop longues apparaissent seulement pendant la crise. Enfin, un retour d’expérience sans action prouvable ne réduit pas la récidive. Déclencheurs, chemins courts, exercices et portes de sortie corrigent ces défauts.
Plan d’action en dix jours
Cadrer les scénarios et les moyens
Jour 1 — choisir trois scénarios. Couvrez commandes, prix ou stock avec conséquences, populations, vitesses et seuils qui dépassent clairement la correction locale habituelle de premier niveau.
Jour 2 — nommer les rôles. Désignez coordinateur, diagnostic, métier, scribe, communication et suppléants sur les plages réellement couvertes par les équipes de permanence opérationnelle.
Jour 3 — vérifier les prérequis. Testez contacts, droits, tableaux, exports, contrats et canaux alternatifs depuis le contexte réel d’une permanence hors horaires ouvrés et sans aide.
Écrire le chemin exécutable
Jour 4 — fixer les déclencheurs. Reliez signal, fenêtre, seuil, niveau, contention et autorité pour éviter le débat au premier écart visible sur le canal.
Jour 5 — préparer les preuves. Automatisez les captures minimales et indiquez identifiants, versions, horodatages, durées de conservation et données à ne jamais partager aux tiers.
Jour 6 — écrire les actions. Pour chaque étape, précisez condition, commande ou geste, responsable, résultat attendu, délai, preuve et mode de repli suffisamment sûr.
Jour 7 — définir la reprise. Documentez source de vérité, déduplication, échantillon, lots, supervision, retour arrière et portes de sortie jusqu’aux systèmes aval réellement concernés par le rejeu.
Exécuter avant la vraie panne
Jour 8 — jouer le scénario. Injectez une propagation active, une information absente et un contact tiers indisponible sans guider les participants pendant leurs décisions.
Jour 9 — corriger les lacunes. Mesurez contention, décisions, accès, communication, relève et réconciliation, puis simplifiez les étapes hésitantes observées pendant l’exercice complet de panne.
Jour 10 — publier et maintenir. Fixez propriétaire, version, accès hors panne, prochaine exécution et revue après chaque changement critique de système, de canal ou d’organisation interne.
- Déclencher depuis une conséquence observable et une vitesse, sans attendre de connaître la cause technique complète de la panne.
- Distribuer coordination, diagnostic, décision, chronologie et communication afin de protéger l’exécution comme la qualité des arbitrages.
- Capturer les preuves volatiles, contenir le mécanisme de propagation et reprendre par populations dédupliquées avec seuils de recul.
- Maintenir contacts, droits et portes de sortie grâce à des exercices réguliers qui testent le dispositif depuis le contexte réel de permanence.
Guides complémentaires de continuité
Relier alertes, mode réduit et reprise
Les alertes marketplace sur prix, stock, commandes, litiges et cash alimentent les déclencheurs avec des populations. Elles doivent rester capables de fonctionner lorsque la chaîne principale est dégradée.
Le mode dégradé sur prix, stock et commandes décrit la promesse minimale, tandis que le redémarrage par paliers encadre le retour du volume. Le runbook relie ces deux états à une chronologie, des responsables et des preuves, sans dupliquer leurs instructions détaillées.
Conclusion : préparer la décision avant la panne
Un runbook vendeur marketplace transforme une panne majeure en séquence gouvernable : déclencher, distribuer les rôles, capturer, contenir, décider, reprendre et réconcilier. Sa force vient de conditions et résultats observables, pas d’un inventaire théorique de toutes les causes.
Les exercices révèlent les liens morts, droits absents et mandats flous avant l’incident réel. Les portes de sortie empêchent un retour prématuré, tandis que le retour d’expérience finance les améliorations capables de réduire la prochaine crise.
Pour construire vos scénarios, tester les permanences et rendre la reprise fiable jusque dans les systèmes aval, Dawap peut vous accompagner avec son expertise d’agence marketplace. La cible est une décision préparée, une propagation bornée et un retour au nominal prouvé.
