L’agrégateur ne répond plus, mais les marketplaces continuent de recevoir des commandes, les équipes commerciales modifient des prix et l’entrepôt expédie. Le problème n’est donc pas seulement une API indisponible : chaque système avance avec une version différente de la réalité. Le risque de survente, de prix obsolète ou de double expédition apparaît avant même que la panne soit qualifiée.
Le vrai sujet consiste à décider ce qui peut continuer sans l’intermédiaire, ce qui doit être gelé et quelle preuve permettra ensuite de reprendre. Un mode dégradé qui autorise tout n’est pas un plan de continuité. C’est une dette de rapprochement reportée sur des opérateurs déjà mobilisés par l’incident.
La méthode couvre toute la chaîne : dépendances, détection métier, files d’attente, checkpoint, règles manuelles, seuils d’arrêt, idempotence et ordre de resynchronisation. Elle permet de décider avant la panne, puis de corriger sans confondre vitesse de retour et intégrité des commandes.
L’agence marketplace Dawap aide à inscrire cette continuité dans l’architecture vendeur. Selon le périmètre, la connexion des canaux marketplace structure les contrats techniques, tandis que Ciama peut centraliser certaines opérations vendeur sans remplacer le système de référence.
Cartographier ce que l’agrégateur porte vraiment
Distinguer transport, règles et mémoire métier
Un agrégateur peut transporter des flux, convertir des formats, appliquer des règles de prix, conserver une table de correspondance SKU, dédupliquer des événements ou devenir l’unique écran du support. Ces responsabilités n’ont pas le même impact lors d’une indisponibilité. Perdre un transport pendant dix minutes est récupérable si les événements restent durables ; perdre la table de correspondance rend le rejeu dangereux même après retour du service.
La cartographie doit donc relier chaque entrée à sa sortie, son système de référence, son propriétaire et son mode de repli. Pour une commande, elle précise qui crée l’identifiant interne, où demeure l’état marketplace et quelle application sait encore reconnaître un doublon. Pour un stock, elle indique si l’agrégateur calcule le disponible ou s’il ne fait que transmettre une quantité déjà arbitrée par l’ERP ou le WMS.
Repérer les dépendances cachées dans l’exploitation
Les dépendances les plus coûteuses ne figurent pas toujours dans le diagramme. Une équipe peut recevoir les alertes uniquement dans l’interface de l’agrégateur, télécharger les étiquettes transport depuis ce même écran ou utiliser son export pour rapprocher les paiements. Lorsque ces usages disparaissent, le SI paraît techniquement disponible alors que les opérations sont bloquées.
Un inventaire exploitable nomme aussi les secrets d’accès, quotas, webhooks, tâches planifiées, files, caches et journaux nécessaires au diagnostic. Il différencie une donnée reconstruisible d’une donnée irremplaçable. Cette distinction décide d’abord des sauvegardes et des checkpoints, puis du budget consacré à une voie directe de secours.
Pour qui le plan de continuité devient nécessaire
Qualifier l’exposition plutôt que la taille du vendeur
Le dispositif devient nécessaire dès qu’une indisponibilité peut faire manquer une obligation client ou créer un état irréconciliable. Un vendeur réalisant peu de commandes, mais commercialisant des pièces rares à stock partagé, peut être plus exposé qu’un catalogue volumineux disposant de stock dédié. Le nombre de canaux ne suffit pas : il faut examiner la criticité des promesses portées par l’intermédiaire.
La direction e-commerce, les opérations, la finance, le support, l’IT et la logistique ont chacun une partie de la réponse. Le responsable métier arbitre ce qui reste vendable ; l’équipe technique maîtrise les dépendances et le rollback ; le support connaît les engagements visibles par l’acheteur. Sans cette pluralité, le plan protège une API mais oublie la commande réelle.
Reconnaître les cas où un repli léger suffit
Une voie directe complète n’est pas toujours justifiée. Si le flux est différable, si la marketplace garde durablement les événements et si aucun geste manuel ne modifie les mêmes objets pendant la panne, une file locale, un gel explicite et une procédure de reprise testée peuvent suffire. En revanche, un canal à expédition le jour même ou un stock très contraint impose davantage de contrôles.
Le bon arbitrage compare le coût complet du repli au coût d’une rupture : commandes annulées, pénalités, charge support, rapprochements financiers et risque de suspension. Cette comparaison se fait par famille de flux. Elle peut conduire à protéger fortement les commandes, à dégrader les mises à jour catalogue et à suspendre temporairement les promotions.
Détecter une panne métier, pas seulement un timeout
Croiser disponibilité technique et fraîcheur des objets
Une réponse HTTP correcte ne prouve pas que le service utile fonctionne. L’agrégateur peut accepter un fichier sans le distribuer, répondre depuis un cache ancien ou traiter les commandes avec plusieurs heures de retard. Le signal faible apparaît quand l’âge du dernier objet traité augmente alors que les appels restent verts.
L’instrumentation suit donc au minimum le dernier accusé métier, l’âge du plus ancien événement en attente, le débit entrant et sortant, le nombre de rejets, la profondeur de file et l’écart entre les comptes attendus. Une alerte relie ces mesures à une action connue. Sans runbook ni responsable, un tableau rouge ne réduit pas le délai de décision.
Éviter les faux retours à la normale
Le service peut recommencer à répondre avant d’avoir résorbé son retard. Si le flux temps réel est rouvert trop tôt, les nouveaux objets se mélangent au backlog et compliquent l’ordre causal. Une sonde de disponibilité doit donc être complétée par un contrôle de rattrapage : ancienneté maximale, taux de traitement et absence d’erreur durable sur un échantillon métier.
En pratique, la fin d’incident n’est pas l’heure du premier appel réussi. C’est le moment où le système retrouve une fraîcheur compatible avec la promesse vendeur et où les contrôles de rapprochement passent. Cette règle empêche la communication prématurée et maintient la surveillance renforcée pendant la reprise.
Décider quels flux geler ou maintenir
Classer les flux par réversibilité
Les lectures et écritures n’appellent pas la même décision. Consulter un catalogue en cache peut rester acceptable avec un horodatage visible ; modifier un prix promotionnel sans certitude de diffusion crée une promesse commerciale ambiguë. De même, télécharger une commande déjà connue est moins risqué que confirmer son expédition sans savoir si l’état sera transmis.
La matrice de décision classe chaque opération en maintien, file d’attente, traitement manuel contrôlé ou blocage. Elle associe une durée maximale et une condition de sortie. Si la donnée perd sa valeur avec le temps, comme une quantité disponible, alors le repli doit expirer plutôt que rejouer aveuglément une information obsolète.
Préserver la promesse client avant le débit
Paradoxalement, ralentir volontairement certaines ventes peut limiter davantage la perte qu’une continuité apparente. Une quantité de sécurité, la désactivation d’offres sensibles ou l’allongement d’un délai d’expédition protège la promesse tant que le stock n’est plus synchronisé. Ces règles doivent être autorisées à l’avance, pas improvisées par le support.
Si une action manuelle est maintenue, alors son périmètre, son auteur et son motif sont journalisés. Aucun collaborateur ne modifie simultanément l’objet dans trois outils. Le responsable choisit une seule voie d’écriture et les autres interfaces deviennent temporairement consultatives.
Créer un checkpoint avant toute opération manuelle
Figer une photographie réconciliable
Le checkpoint conserve l’heure, la dernière séquence traitée, les curseurs de pagination, les identifiants d’événement, les états de commande et les versions des mappings. Il ne s’agit pas d’un export décoratif : chaque champ doit servir à retrouver la frontière entre ce qui est acquis, ce qui est en vol et ce qui reste à rejouer.
La sauvegarde est chiffrée, horodatée et accessible aux responsables de reprise. Son intégrité est vérifiée avant de basculer en manuel. Si le service disparaît totalement, ce point permet de reconstruire la chronologie sans demander aux équipes de se souvenir de l’ordre des gestes.
Journaliser les dérogations pendant l’incident
Chaque correction manuelle reçoit un identifiant stable, une cible, une valeur avant, une valeur après et une justification. Le journal précise aussi si l’action doit être propagée après reprise ou si elle remplace définitivement l’événement en attente. Ce contrat évite qu’un opérateur applique deux fois une remise ou réexpédie une commande déjà traitée.
La traçabilité reste séparée des conversations de crise. Un message instantané explique une décision, mais il ne constitue pas une entrée rejouable. L’outil de suivi doit produire une sortie structurée que le script de rapprochement ou l’équipe de contrôle pourra consommer.
Organiser catalogue, prix et stock en mode dégradé
Traiter la fraîcheur selon la nature de la donnée
Une description produit ancienne de quelques heures n’a pas le même impact qu’un stock ancien. Le catalogue éditorial peut souvent attendre ; le prix doit respecter les engagements commerciaux ; le stock demande une marge de sécurité et une durée de validité courte. Le mode dégradé définit ces tolérances par famille, canal et type d’offre.
Par exemple, un vendeur peut autoriser localement un décalage de six heures sur un enrichissement non contractuel, mais geler une offre lorsque la quantité disponible n’a pas été confirmée depuis quinze minutes. Ces valeurs illustrent une politique à calibrer sur la vitesse de vente, le stock mutualisé et le délai d’annulation : elles ne constituent pas des normes universelles.
Éviter la mise à jour concurrente
Le principal danger vient d’une voie directe de secours qui écrit pendant que l’agrégateur continue à mettre en file les mêmes mutations. Chaque ressource doit porter une version, un horodatage métier ou une clé de commande permettant d’arbitrer. Un simple « dernier arrivé gagne » est fragile si les horloges diffèrent ou si le réseau réordonne les messages.
La règle de conflit est explicite : source prioritaire, conditions de refus, journalisation et traitement humain des cas ambigus. En revanche, automatiser la fusion de deux prix sans connaître leur intention commerciale augmente le risque. L’exception rejoint une file dédiée avec les preuves nécessaires à la décision.
Protéger les commandes sans inventer leur état
Conserver l’identifiant marketplace de bout en bout
Une commande est rapprochée avec son identifiant canal, son identifiant interne et les identifiants de lignes. La documentation officielle de l’Orders API d’Amazon Selling Partner API décrit les opérations d’accès aux commandes ; elle ne garantit pas qu’un vendeur suspendu ou qu’un intermédiaire indisponible conservera les mêmes possibilités. Le plan doit donc vérifier les capacités réelles de chaque canal et de chaque compte.
Si la création interne réussit mais que l’accusé se perd, le retry recherche d’abord l’identifiant externe avant de recréer. L’entrée, la sortie, le statut et la clé d’idempotence sont journalisés. Une commande inconnue n’est jamais déclarée annulée ou expédiée par déduction.
Séparer prise en charge et changement d’état
Le WMS peut préparer un colis tandis que la confirmation d’expédition attend dans une file. Cette séparation doit rester visible : « préparée en interne » n’équivaut pas à « expédition confirmée au canal ». Le support ne promet pas un état qu’il ne peut pas prouver.
Lorsque le délai contractuel approche, le responsable métier décide en priorité : poursuivre avec une preuve de transport, suspendre la préparation ou contacter l’acheteur selon les outils autorisés. Les contraintes et règles de chaque marketplace doivent être vérifiées dans leur documentation et leur console, car elles évoluent indépendamment de l’architecture interne.
Borner les retries et empêcher les doubles effets
Associer backoff, limite et budget d’erreur
Un retry immédiat et illimité peut prolonger la panne en saturant le service qui tente de revenir. Les recommandations AWS sur la limitation des nouvelles tentatives invitent à borner les retries et à utiliser un backoff. Le délai, le jitter, le nombre maximal et la file d’échec sont donc définis par dépendance.
Le retry ne doit pas dépasser la durée utile de l’action. Rejouer demain une quantité prévue pour aujourd’hui est techniquement réussi mais commercialement faux. Chaque message porte une date d’expiration ; passé ce seuil local, il rejoint une revue ou est remplacé par un recalcul depuis la source.
Rendre les effets idempotents
L’idempotence recommandée par AWS consiste à faire en sorte que plusieurs requêtes identiques produisent le même effet qu’une seule. Pour une création, la clé réunit l’objet métier et l’intention ; pour une transition, le contrat refuse une version déjà dépassée.
La déduplication a une durée de conservation cohérente avec le rejeu maximal. Elle ne repose pas seulement sur un cache volatil. Si un message échoue après l’effet externe mais avant l’enregistrement local, alors la reprise interroge d’abord l’état distant ou rapproche la preuve avant de relancer.
Attribuer décisions, communication et preuves
Nommer un commandement métier et technique
Le responsable d’incident coordonne la chronologie, mais chaque domaine conserve son décideur. Le métier autorise le gel commercial ; la logistique décide des préparations ; l’IT choisit le repli technique ; le support adapte le message client. Une matrice RACI trop large ralentit l’arbitrage : le runbook désigne une personne de garde et un suppléant par décision critique.
Les responsabilités couvrent aussi la sortie. Une personne valide le checkpoint, une autre signe le rapprochement et le responsable produit décide de rouvrir progressivement. La communication mentionne faits, impacts, mesures de protection et prochaine échéance ; elle sépare clairement ce qui est confirmé de ce qui reste une hypothèse.
Donner au support un état exploitable
Le support n’a pas besoin de lire les logs techniques. Il lui faut une vue par commande : dernier état prouvé, action en cours, message autorisé et date de prochaine vérification. Cette sortie limite les réponses contradictoires et la charge support quand plusieurs canaux sont touchés.
Une alerte interne précise également ce qu’il ne faut pas faire. Par exemple, ne pas recréer une commande, ne pas modifier un stock depuis l’interface de secours ou ne pas confirmer une expédition avant rapprochement. Ces interdits temporaires réduisent les effets irréversibles.
Fixer des seuils locaux qui déclenchent une action
Relier chaque mesure à un choix
Un seuil utile ne prétend pas définir la disponibilité idéale. Il déclenche une action locale : alerter, ralentir, basculer, geler ou reprendre. Un vendeur peut décider qu’une absence d’accusé pendant cinq minutes ouvre l’incident, que quinze minutes gèlent les promotions et que trente minutes activent le traitement manuel des commandes urgentes. Ces durées doivent être testées contre son volume, ses engagements et la capacité de ses équipes.
La profondeur de file seule est trompeuse : cent messages catalogue peuvent peser moins qu’une seule commande proche de son échéance. Le tableau combine âge, criticité et taux de traitement. Si le plus ancien objet critique dépasse son délai métier, alors le niveau d’incident augmente même si le service répond encore.
Définir des conditions de retour plus strictes
Le seuil de sortie exige une stabilité observée sur une fenêtre locale, un backlog en baisse et un rapprochement sans écart bloquant. Une reprise progressive peut commencer avec un canal ou une famille de produits, puis élargir après validation. Si le taux d’erreur remonte, le rollback revient au palier précédent sans réinventer la procédure.
Ces seuils sont révisés après chaque exercice et incident. Une valeur trop sensible provoque des bascules inutiles ; une valeur trop tolérante masque les pertes. La mesure utile est celle qui permet de décider assez tôt pour protéger la promesse, pas celle qui embellit un SLO.
Resynchroniser dans un ordre métier explicite
Rouvrir les dépendances avant les flux de volume
La reprise commence par figer les opérations manuelles, sauvegarder leur journal et comparer les curseurs. Elle restaure ensuite les référentiels indispensables — mappings, identifiants, configurations — avant les transactions. Les commandes précèdent généralement les mises à jour éditoriales, mais l’ordre exact dépend de la promesse vendeur.
Chaque lot possède une entrée, une sortie, un responsable, un seuil d’arrêt et une procédure de rollback. Le premier lot est petit et observable. Si deux contrôles métier divergent, alors la file s’arrête et l’écart est isolé plutôt que compensé par une modification globale.
Rapprocher avant d’effacer les preuves
Le contrôle compare les objets attendus, reçus, appliqués et rejetés. Pour les commandes, il rapproche montants, lignes, quantités, statuts et expéditions ; pour le stock, il recalcule depuis la source plutôt que de rejouer toutes les valeurs historiques. Les messages obsolètes sont conservés avec un motif de non-application.
La file d’incertitude ne disparaît pas dans un compteur global. Chaque cas possède un responsable et une échéance. Le retour à la normale est prononcé lorsque les obligations critiques sont réconciliées, la surveillance renforcée active et les actions manuelles clôturées ou planifiées.
Erreurs fréquentes d’un dispositif trop théorique
Confondre haute disponibilité et continuité métier
Dupliquer une instance ne protège ni d’une mauvaise règle de mapping ni d’une indisponibilité du fournisseur. De même, un cache peut maintenir un écran tout en servant une promesse obsolète. La dégradation progressive décrite par AWS vise à conserver les fonctions essentielles ; leur définition reste une décision métier locale.
Une autre erreur consiste à construire une voie de secours jamais exercée. Les secrets expirent, les permissions changent et les personnes quittent l’équipe. Le test doit provoquer la dépendance indisponible et mesurer la capacité réelle à détecter, décider, opérer puis reprendre.
Tout rejouer dès le premier signal vert
Le redémarrage massif cumule backlog et trafic courant. Il peut créer un second incident, masquer les doublons et dépasser les quotas. Le rattrapage doit être régulé, priorisé et interrompable. Le coût caché d’une reprise trop rapide se retrouve dans les annulations, les rapprochements manuels et les dossiers support.
Il faut aussi éviter de supprimer les messages rejetés après correction. Sans trace, impossible de prouver pourquoi un objet n’a pas été appliqué. La bonne sortie conserve l’identifiant, la cause, la décision et l’état final, avec une durée de rétention adaptée aux obligations de l’entreprise.
Plan d’action pour tester la continuité
Préparer le premier exercice
D’abord, choisir un parcours critique et limiter le périmètre : par exemple la réception d’une commande jusqu’à son accusé interne. Nommer les responsables métier et technique, puis l’observateur chargé de la chronologie. Documenter les entrées, sorties, dépendances, seuils, files et conditions de rollback.
Ensuite, capturer un checkpoint, provoquer l’indisponibilité en environnement maîtrisé et jouer le runbook sans aide de ses auteurs. Contrôler la détection, le gel, la communication et la traçabilité. Le but n’est pas de démontrer que tout fonctionne, mais d’identifier les décisions qui manquent avant un incident réel.
- Cartographier les objets, systèmes de référence, mappings et voies d’écriture.
- Décider en priorité les opérations à maintenir, différer, bloquer ou traiter manuellement.
- Créer le checkpoint et valider que sa restauration produit une preuve exploitable.
- Tester les retries, l’idempotence, l’expiration et la file d’incertitude.
- Rejouer un petit lot, rapprocher les effets et tester le rollback.
- Corriger le runbook, attribuer les actions et planifier le prochain exercice.
Mesurer la capacité de reprise
Le compte rendu mesure le temps de détection, le temps de décision, le nombre d’actions non documentées, les écarts de rapprochement et l’ancienneté du dernier objet critique. Il indique les hypothèses non vérifiées. Une durée totale flatteuse ne compense pas une commande dupliquée ou un stock devenu inexplicable.
La feuille de route corrige d’abord les défauts irréversibles, ensuite les tâches manuelles fréquentes, puis le confort d’exploitation. Chaque action possède un responsable, une échéance et une preuve de fermeture. L’exercice suivant vérifie les corrections au lieu de recommencer un scénario sans mémoire.
Ressources pour fiabiliser le run vendeur
Relier l’incident au mode dégradé
Le runbook vendeur marketplace en cas de panne majeure complète la répartition des décisions et des preuves. Le mode dégradé sur les prix, stocks et commandes approfondit les règles spécifiques par flux.
Ces ressources doivent être adaptées aux capacités réellement testées. Une opération décrite par une documentation fournisseur ne prouve ni que le compte y a accès pendant un incident, ni qu’elle respecte les règles internes de validation.
Conserver une architecture vendeur lisible
Le plan de continuité s’intègre à la supervision des connecteurs, au stockage durable des événements et à la gouvernance des référentiels. Il ne devient pas un second SI clandestin. Les responsabilités et les contrats restent visibles pour l’équipe qui assurera le prochain tour de garde.
Une revue semestrielle peut suffire pour un flux stable ; un canal très changeant exige une cadence plus rapprochée. La fréquence est locale et dépend des releases, incidents, changements de permissions et évolutions de promesse commerciale.
- Conserver avec le runbook les dépendances, responsables, seuils de bascule et preuves de reprise.
Conclusion : reprendre sans transformer l’incident en dette
La continuité d’un agrégateur ne consiste pas à faire passer tous les flux coûte que coûte. Elle consiste à préserver les obligations essentielles, à rendre les dérogations traçables et à garder un chemin de reprise. La vraie question reste celle de l’état que l’entreprise saura encore prouver après plusieurs heures d’indisponibilité.
Un checkpoint exploitable, des écritures uniques, des retries bornés et un ordre de resynchronisation réduisent le risque de doublon. Les seuils restent attachés au contexte : volume, vitesse de vente, engagements d’expédition et capacité d’intervention.
Le meilleur test met volontairement l’intermédiaire hors circuit, mesure les décisions réelles et révèle les dépendances humaines. Les corrections portent d’abord sur les effets irréversibles, puis sur la charge manuelle et enfin sur le confort du run.
Pour cadrer cette reprise de bout en bout, Dawap peut auditer les flux, tester les scénarios et accompagner l’exploitation avec son expertise d’agence marketplace.
