Une marketplace peut accepter le paiement sans créer la commande vendeur, confirmer une expédition qui n’est jamais partie, appliquer deux fois un remboursement ou perdre un événement de stock. Chaque équipe voit alors une partie différente : le PSP montre une transaction, l’OMS un état intermédiaire, le vendeur une commande absente et le support une plainte. La pression pousse à corriger vite, parfois dans plusieurs outils à la fois.
Le symptôme le plus dangereux est l’absence de vérité partagée. La finance rembourse pendant que la logistique relance l’expédition ; un vendeur recrée une commande déjà existante ; le service client annonce un délai que les opérations ne peuvent pas tenir. L’incident technique devient une incohérence commerciale, puis un litige dont la chronologie reste impossible à défendre.
Le vrai enjeu d’une marketplace opérateur n’est pas seulement de rétablir un service. Il faut décider quelle promesse protéger, borner les nouvelles entrées, conserver les preuves et rendre chaque reprise idempotente. Contre-intuitivement, suspendre une partie du parcours peut accélérer le retour à la normale en empêchant la file ambiguë de continuer à grandir.
Ce protocole permet de décider quoi faire depuis l’alerte jusqu’à la réconciliation. Il distingue commandement, diagnostic et exécution ; il relie commandes, paiements, vendeurs et messages clients ; il exige enfin un bilan des dossiers ouverts avant de déclarer l’incident fermé.
Qualifier gravité et promesse touchée
Partir de l’effet client ou vendeur
La gravité ne dépend pas uniquement du nombre d’erreurs HTTP. Une seule commande à montant élevé, un lot de produits réglementés ou plusieurs prélèvements peuvent justifier une réponse immédiate. L’équipe nomme la promesse atteinte : paiement accepté, commande transmise, stock réservé, expédition confirmée ou remboursement exécuté.
Le premier dossier sert de cas témoin. Il rassemble identifiants de panier, commande, transaction, vendeur et expédition. L’équipe vérifie ce qui est certain, probable et inconnu. Cette séparation empêche un statut rassurant dans un système de devenir le verdict de toute la chaîne.
Évaluer expansion et réversibilité
La qualification observe si de nouvelles commandes entrent encore dans le défaut, si les effets peuvent être annulés et si la population est identifiable. Une erreur stable sur un canal borné n’a pas le même risque qu’une dérive qui touche progressivement tous les vendeurs.
Le niveau de gravité déclenche une cadence, des rôles et une autorité de décision. Il peut évoluer lorsque le diagnostic progresse. Le journal conserve chaque changement et son motif ; la rétrogradation n’efface pas la période où l’incertitude était plus forte.
Décider si la cellule de crise doit ouvrir
Fixer des critères d’ouverture
La cellule est utile quand plusieurs équipes doivent arbitrer la même promesse, quand une action peut aggraver l’impact ou quand la communication externe doit rester cohérente. Un incident purement local, compris et réversible peut suivre le runbook ordinaire. Une commande ambiguë entre paiement, OMS et vendeur exige déjà une coordination transverse.
Les critères combinent impact, vitesse d’expansion, irréversibilité et incertitude. Ils sont testés avant la crise. L’objectif n’est pas de transformer chaque alerte en réunion, mais d’éviter qu’un problème commercial soit traité comme cinq tickets indépendants.
Désigner un commandement sans attendre tous les experts
Le responsable d’incident tient l’objectif, la chronologie, les décisions et la cadence. Il n’est pas nécessairement la personne qui connaît le mieux le code. Il protège les spécialistes des sollicitations dispersées et demande une formulation exploitable : fait, hypothèse, test, résultat et prochaine action.
Un suppléant est nommé si l’incident dure. La passation reprend état du service, population, actions en cours et décisions à prendre. Elle ne consiste pas à partager un fil de discussion de plusieurs centaines de messages. Le dossier central reste la référence.
Attribuer commandement et responsabilités
Séparer décision, investigation et action
Le commandement choisit priorité et périmètre. Les équipes techniques recherchent la cause et proposent des options. Les opérations exécutent les gestes sur commandes ou vendeurs selon une liste approuvée. La communication transforme les faits validés en messages adaptés. Cette séparation évite qu’une hypothèse technique devienne une promesse client.
Chaque action sensible possède un owner unique : geler les entrées, rembourser, réexpédier, suspendre une offre ou publier un message. Plusieurs contributeurs peuvent préparer, mais une personne confirme la décision et son résultat. La responsabilité reste visible dans la chronologie.
Réserver un canal pour les décisions
Les discussions peuvent vivre dans plusieurs outils, mais les décisions rejoignent un registre commun avec heure, auteur, contexte et condition de révision. Un message oral ou une réaction emoji ne suffit pas pour déclencher une compensation financière.
Le support reçoit une vue opérationnelle : ce qui est touché, ce qui ne l’est pas, ce qu’il peut promettre et quand attendre la prochaine mise à jour. Il n’a pas besoin d’accéder aux logs techniques pour répondre correctement. Toute modification de la consigne est datée.
Construire une chronologie commune
Ancrer les événements dans des identifiants
La chronologie relie panier, commande, paiement, vendeur, stock, expédition et messages. Les horloges peuvent différer ; l’ordre métier s’appuie aussi sur versions et identifiants d’événement. Un timestamp seul ne prouve pas qu’une transition a précédé une autre.
Les sources restent nommées. « Commande créée » peut signifier objet enregistré, paiement confirmé ou notification vendeur livrée. Le dossier indique le système et le niveau de preuve. Cette précision réduit les débats de vocabulaire pendant la reprise.
Séparer faits et hypothèses
Un fait possède une source consultable. Une hypothèse explique plusieurs faits et annonce le test qui peut la contredire. Une action ne doit pas être présentée comme preuve de la cause : redémarrer un worker peut vider une file sans démontrer pourquoi elle s’est bloquée.
La chronologie conserve également les corrections manuelles. Sans elles, le post-mortem interprète un état réparé comme un fonctionnement nominal. L’avant, l’après, le motif et l’auteur permettent de distinguer l’impact original de la réponse apportée.
Protéger les états de commande
Choisir une autorité par transition
Le paiement, la préparation et l’expédition peuvent vivre dans des systèmes différents. Le protocole précise qui fait foi pour chaque événement et comment les autres le vérifient. Une interface ne doit pas passer une commande à « expédiée » simplement pour aligner un écran sur une notification douteuse.
Les transitions irréversibles reçoivent une attention propre. Capturer, rembourser, annuler ou déclarer livré exige une précondition et un résultat terminal. Si le verdict manque, le dossier reste ambigu avec un owner ; il ne choisit pas l’état le plus favorable.
Empêcher le double effet pendant la reprise
Chaque geste porte une clé d’idempotence liée à la commande et à l’intention. Après un timeout, l’opérateur consulte le résultat avant de relancer. Une même demande avec un contenu différent est refusée. Cette règle protège remboursements, créations de commande et expéditions.
Les scripts de correction suivent le même contrat que le back-office. Ils enregistrent population, version attendue, résultat par ligne et erreur. Une requête SQL exécutée sans dossier peut résoudre l’écran tout en laissant événements et systèmes aval incohérents.
Identifier la population réellement affectée
Définir une requête reproductible
La population s’appuie sur période, canal, vendeur, version, type de paiement et symptôme observé. La requête est versionnée et peut être rejouée. Le nombre annoncé garde son heure de calcul, car de nouvelles commandes peuvent entrer tant que le défaut n’est pas contenu.
Un échantillon contrôle vrais positifs et faux négatifs. L’équipe recherche aussi des commandes apparemment normales qui partagent le même chemin technique. La population utile n’est pas seulement celle qui a déjà produit un ticket support.
Segmenter par décision de reprise
Deux commandes touchées peuvent nécessiter des gestes différents : paiement autorisé non capturé, capture sans commande, commande sans vendeur ou expédition sans mise à jour. Chaque segment possède un verdict, une action et un contrôle final.
Exemple concret : si plus de 2 % des commandes d’un canal restent sans accusé vendeur pendant 15 minutes, alors les nouvelles entrées de ce canal sont suspendues. Ce seuil local protège la file ; il est révisé selon volume, délai nominal et capacité de reprise.
Choisir gel, dégradation ou correction
Réduire d’abord les nouvelles ambiguïtés
Le confinement peut désactiver un moyen de paiement, un vendeur, une promotion ou une zone logistique. Il peut aussi passer le parcours en information différée. La décision compare coût de suspension et coût d’une file qui continue à grossir.
Le kill switch est testé et ciblé. Couper tout le site pour un défaut d’un seul canal crée un impact supplémentaire ; laisser toutes les commandes ouvertes pour préserver la conversion reporte le coût sur la finance et le support. Le périmètre suit la preuve disponible.
Préférer une correction observable
Le correctif d’urgence commence sur une cohorte réduite, avec métriques et rollback. Il ne mélange pas migration, optimisation et changement métier. Le responsable d’incident valide le signal attendu avant d’élargir.
Un redéploiement réussi n’autorise pas automatiquement la reprise. L’équipe vérifie nouvelles commandes, taille de file, états terminaux et absence de double effet. Si un indicateur se dégrade, le système revient au palier précédent et la population reste bornée.
Coordonner vendeurs et opérations
Donner une consigne actionnable
Le vendeur doit savoir quelles commandes traiter, attendre ou ignorer. Le message inclut identifiants, période, promesse et prochaine mise à jour. Il interdit les recréations manuelles tant que l’opérateur ne sait pas dédupliquer.
Les retours vendeurs enrichissent la population sans devenir la seule source. Un marchand peut observer une absence alors qu’un événement est en retard. L’équipe rapproche portail, API et accusés avant de demander une nouvelle action.
Préserver les preuves logistiques
Les étiquettes, scans, numéros de suivi et confirmations restent attachés au dossier. Annuler une commande dans l’OMS ne supprime pas une expédition déjà partie. La reprise choisit alors retour, interception ou traitement commercial adapté.
Le seller manager collecte les exceptions qui sortent de la procédure. Il ne promet pas un geste unique pour tous. Une commande préparée, une commande expédiée et une commande jamais reçue par le vendeur appartiennent à des segments différents.
Communiquer une promesse client vérifiable
Dire ce qui est connu et ce qui ne l’est pas
Le message client confirme l’effet visible, la mesure de protection et la prochaine échéance. Il ne publie pas une cause non établie. « Votre paiement est autorisé, la commande reste en vérification » est plus utile qu’une promesse générale de résolution immédiate.
Les équipes alignent email, centre d’aide, scripts support et interface. Un bandeau global n’est utilisé que si la population ne peut pas être ciblée. Les clients non touchés ne doivent pas recevoir une consigne qui crée de nouvelles demandes.
Mettre à jour selon une cadence annoncée
La cadence dépend de la gravité. Une mise à jour peut dire qu’aucun fait nouveau n’est confirmé, tout en rappelant la protection en place. Le silence après une première alerte pousse clients et vendeurs à multiplier les contacts.
La fin d’incident distingue service rétabli et dossier client résolu. Certaines commandes exigent encore remboursement, réexpédition ou preuve. Le message individuel ferme seulement lorsque l’action correspondante est confirmée.
Arbitrer paiement et compensation
Distinguer autorisation, capture et remboursement
Le statut « payé » masque parfois plusieurs étapes. La finance lit l’identifiant PSP, le montant, la devise et le verdict de chaque opération. Une autorisation peut expirer, une capture peut réussir sans réponse et un remboursement peut rester en attente.
Les gestes financiers sont idempotents et rapprochés du relevé PSP. Le support ne relance pas sur la seule base d’un écran interne. Une commande annulée ne prouve pas que l’argent est revenu ; la preuve terminale vient du système de paiement et du rapprochement.
Encadrer les compensations commerciales
La compensation dépend du dommage, de la promesse et de la politique. Elle ne remplace pas le remboursement dû. Le barème et l’autorité d’approbation sont disponibles avant l’incident afin que deux clients comparables ne reçoivent pas des réponses opposées.
Le dossier sépare remboursement, avoir, remise et geste vendeur. Cette distinction protège comptabilité et analyse de coût. Les décisions exceptionnelles sont tracées, puis réexaminées au post-mortem si le volume dépasse la capacité prévue.
Reprendre puis réconcilier les commandes
Réouvrir par paliers
La reprise commence sur un canal ou un vendeur témoin. Elle vérifie acceptation, paiement, notification, stock et état terminal. Le palier suivant s’ouvre seulement si la cohorte précédente reste explicable après le délai nécessaire.
Les anciennes commandes ne se mélangent pas aux nouvelles. Une file de remédiation traite les dossiers historiques avec leurs versions et décisions. Le flux nominal n’est pas ralenti par des retries illimités sur des cas déjà ambigus.
Fermer les écarts avant le bilan
La réconciliation compare commandes attendues, paiements, notifications vendeurs, expéditions et remboursements. Elle produit des balances par segment : terminées, annulées, compensées, encore ouvertes et sans owner. Zéro erreur applicative ne signifie pas zéro dossier.
Le responsable d’incident peut fermer la phase critique lorsque le service est stable et chaque résidu possède une équipe et une échéance. Le post-mortem commence avec cette liste. Il ne transforme pas les exceptions restantes en dette anonyme.
Éviter les erreurs fréquentes
Lancer plusieurs corrections concurrentes
Quand finance, support et technique modifient le même dossier, la chronologie devient illisible. Toute correction passe par un owner, une population et un résultat attendu. Une seconde action attend le verdict de la première ou reçoit une justification explicite.
Autre erreur : attendre la cause racine avant de contenir. L’équipe peut geler une entrée sur la base d’un risque prouvé sans savoir encore quel composant a failli. Confinement et diagnostic progressent en parallèle avec des responsabilités distinctes.
Communiquer une date inventée
Une échéance rassurante mais non soutenue détruit la confiance et surcharge le support. Le message annonce la prochaine mise à jour, pas une résolution certaine. La cellule révise la promesse lorsqu’un fait nouveau change le chemin.
Enfin, fermer dès le retour des métriques nominales masque les commandes historiques. La réconciliation et les owners des résidus font partie du critère de sortie. Le post-mortem ne remplace pas les compensations encore dues.
Plan d’action pour les premières heures
Contenir et établir la vérité commune
L’équipe qualifie la promesse touchée, ouvre le commandement et choisit un cas témoin. Elle inventorie entrées, sorties, systèmes et dépendances. Le contrat attribue responsabilités, owner de chaque action, seuils de gel et autorité sur paiement, commande, vendeur, expédition et communication. Il précise aussi la cadence de décision, le suppléant et la preuve requise avant toute action irréversible, documentée dans le registre partagé.
La cellule borne les nouvelles entrées, versionne la requête de population et segmente les dossiers par verdict. Le support reçoit une consigne datée. Les corrections manuelles conservent avant, après, motif et identifiant de corrélation. Aucun script n’est exécuté sans résultat par commande.
Reprendre, réconcilier et transmettre
Le correctif passe par un pilote avec instrumentation, monitoring, traçabilité, queue de remédiation et rollback. La reprise vérifie état terminal et absence de double effet avant chaque extension. Le runbook couvre réponse perdue, paiement ambigu et commande déjà expédiée.
La réconciliation attribue les résidus et valide les messages de clôture. Le post-mortem distingue cause technique, facteurs organisationnels et coût client. Chaque action corrective possède une preuve attendue et une date. La cellule ferme seulement lorsque la passation est acceptée.
- À faire d’abord : nommer commandement, promesse touchée, cas témoin et mesure de confinement.
- À tester ensuite : timeout après paiement, notification vendeur perdue et reprise idempotente.
- À différer : les optimisations sans effet direct sur la population ou la stabilité.
- À refuser : toute correction sans owner, population, preuve et rollback.
Guides complémentaires pour le run
Donner une vue exploitable au back-office
Les écrans indispensables du back-office opérateur aident à réunir commande, vendeur, paiement et actions. Ils offrent au support le contexte nécessaire sans exposer les outils techniques.
Le catalogue PIM d’une marketplace précise les identités produit et offre. Cette base facilite la segmentation quand l’incident touche un vendeur, une variante ou une catégorie.
Éprouver la reprise sur un périmètre borné
Le MVP marketplace fournit une méthode de pilote et de rollback. Les scénarios d’incident doivent exister avant l’ouverture large, pas après la première crise.
L’ouverture d’une première catégorie donne des commandes et vendeurs réels pour tester chronologie, communication et réconciliation sans exposer tout le catalogue.
Conclusion : fermer avec des preuves
Un incident commande marketplace exige une vérité commune avant une multiplication des gestes. La gravité part de la promesse touchée, la cellule attribue commandement et actions, puis la chronologie sépare faits, hypothèses et corrections manuelles.
Le confinement borne les nouvelles ambiguïtés. Les états de commande et de paiement gardent leurs autorités ; chaque reprise est idempotente. Vendeurs, support et clients reçoivent une consigne cohérente, datée et limitée à ce qui est établi.
Le retour des métriques nominales ouvre la réconciliation, il ne ferme pas l’incident. Commandes, paiements, expéditions, remboursements et compensations doivent rejoindre un verdict ou un owner. Le bilan commence avec ces preuves.
Pour concevoir la cellule, instrumenter la chronologie et exercer la reprise, notre équipe peut vous accompagner dans votre création de marketplace opérateur, du premier scénario de panne jusqu’au post-mortem.
