Une panne majeure vendeur marketplace n'est pas seulement un incident technique. C'est un moment où les prix, les stocks, les commandes, les expéditions, le support et parfois la finance peuvent se désynchroniser en quelques heures.
Le runbook sert à éviter l'improvisation. Il indique qui décide, quoi couper, quoi surveiller, quoi reprendre et quoi expliquer aux équipes. Sans ce cadre, chaque personne tente de sauver son périmètre, et le canal devient plus difficile à remettre d'aplomb.
Dans une logique agence marketplace, le bon réflexe consiste à traiter la panne comme un sujet de run vendeur, pas comme une simple liste d'erreurs à vider.
Un runbook n'a pas besoin d'être long pour être utile. Il doit surtout être connu avant la crise, aligné avec la valeur business des flux et assez concret pour être suivi sous pression.
La règle à garder
En panne majeure, la première victoire n'est pas de tout réparer. C'est d'arrêter de créer de nouveaux écarts.
Déclencher le runbook au bon moment
Le runbook doit se déclencher quand un incident dépasse la correction locale : flux commandes bloqué, stock non fiable, prix massivement faux, statuts divergents, marketplace qui rejette des lots entiers ou support qui reçoit les mêmes alertes en boucle.
Le déclencheur doit être simple. Si l'équipe débat trop longtemps pour savoir si l'incident est majeur, elle perd déjà du temps. Mieux vaut ouvrir le runbook tôt, quitte à le refermer vite si le périmètre reste limité.
Geler ce qui aggrave l'écart
Une panne majeure appelle souvent un gel partiel : arrêter une synchronisation, suspendre une famille d'offres, bloquer une reprise automatique, ralentir un batch ou isoler une marketplace.
Le gel n'est pas un échec. C'est une protection. Il évite que les commandes, les stocks ou les prix faux continuent à se diffuser pendant que l'équipe cherche la cause.
La décision doit être réversible et documentée : quoi a été gelé, à quelle heure, par qui, avec quel critère de réouverture.
Classer les flux critiques
Tous les flux ne méritent pas la même urgence. Les commandes payées, les expéditions à date, les stocks à risque de survente, les prix qui détruisent la marge et les remboursements doivent passer avant les corrections de confort.
La page centralisation commandes marketplace devient clé quand il faut comprendre quelles commandes sont touchées et lesquelles peuvent attendre.
Le runbook doit séparer les impacts cash, promesse client, note vendeur, marge et charge support. Cette lecture évite de confondre incident bruyant et incident réellement coûteux.
Conserver les preuves utiles
Les preuves doivent être exploitables par le métier : identifiants commande, SKU, marketplace, statut source, statut cible, timestamp, action déclenchée, message d'erreur et décision prise.
Un export de logs illisible ne suffit pas. Il faut une trace qui permette de vérifier, rejouer, expliquer au support et préparer un post-mortem honnête.
Cette mémoire protège aussi contre les reprises trop larges. Quand on sait exactement ce qui a échoué, on évite de relancer tout le catalogue ou toutes les commandes.
Reprendre sans créer de doublons
La reprise doit être bornée : période, marketplace, statut, famille de produits, batch ou liste d'identifiants. Une reprise massive peut masquer la cause tout en créant des doublons.
Avant de rejouer, il faut vérifier l'idempotence, les statuts déjà appliqués et les effets secondaires possibles : facture, email client, stock réservé, remboursement ou étiquette transport.
La reprise doit commencer par un échantillon. Si l'échantillon réconcilie proprement les systèmes, le périmètre peut s'élargir. Sinon, il faut revenir au gel plutôt que forcer.
Communiquer sans brouiller les équipes
Le support, la logistique, la finance et la direction n'ont pas besoin du même message. Le runbook doit prévoir une communication courte par audience : ce qui est touché, ce qui est gelé, ce qui peut être promis, ce qui doit attendre.
Une communication instable augmente le coût de l'incident. Les équipes commencent à compenser localement, et ces compensations deviennent ensuite de nouveaux écarts.
Le reporting marketplace doit aider à suivre les volumes touchés et les priorités de sortie, pas seulement à afficher un tableau après coup.
Sortir de crise sans oublier le post-mortem
La sortie de crise ne se limite pas à voir moins d'erreurs. Il faut confirmer que les flux critiques sont revenus à un état cohérent : commandes traitées, stock fiable, prix vérifiés, support informé et écarts résiduels listés.
Le post-mortem doit produire des actions concrètes : alerte à créer, règle à clarifier, seuil de gel, test de non-régression, documentation ou automatisation. Sinon, l'incident reviendra sous une forme proche.
Conclusion : préparer avant la panne
Un runbook vendeur marketplace a de la valeur parce qu'il est prêt avant la panne. Il ne remplace pas l'expertise, mais il évite que l'expertise parte dans tous les sens au moment le plus coûteux.
Les vendeurs les plus solides ne sont pas ceux qui n'ont jamais d'incident. Ce sont ceux qui savent geler vite, prioriser juste, reprendre proprement et apprendre après coup.
Pour aller plus loin dans cette vague, lisez aussi comment prioriser les incidents qui mangent la marge et comment organiser un mode dégradé vendeur marketplace.
