Un transporteur ne répond plus pendant quarante minutes pendant une pointe de trafic. La marketplace continue d’afficher « livraison demain », confirme 126 commandes pour 18 400 euros et empile les demandes dans une file. Quand le service revient, la moitié des adresses sont hors zone, les créneaux ont disparu et le support doit rappeler chaque acheteur. Le problème produit réclamations, remboursements, perte de confiance et heures de réconciliation : la plateforme était disponible, mais sa promesse ne l’était plus.
Le réflexe inverse consiste à fermer tout le site dès qu’une dépendance ralentit. Des parcours encore sûrs deviennent indisponibles et le support perd ses outils au moment critique. Sans niveaux de dégradation, l’incident oppose une expérience mensongère à une coupure disproportionnée.
Le vrai enjeu du mode dégradé d’une marketplace opérateur est de réduire la promesse jusqu’à ce qu’elle reste prouvable. Contre-intuitivement, retirer une option ou demander une confirmation ultérieure protège mieux la conversion durable qu’un checkout apparemment fluide fondé sur des données incertaines.
Vous allez comprendre comment inventorier les dépendances, fixer fraîcheur, niveaux, replis et kill switches. Catalogue, commande et paiement reçoivent des stratégies propres ; la reprise inclut rattrapage, réconciliation et communication avant le retour complet au nominal.
Définir la promesse minimale
Partir des décisions utilisateur
Consulter, comparer, réserver, payer et suivre ne demandent pas la même certitude. Chaque parcours nomme les informations indispensables et celles qui peuvent attendre. Une page produit peut rester lisible sans recommandation, tandis qu’une commande exige prix, disponibilité et verdict de paiement cohérents.
Le contrat minimal précise sortie, délai, données et responsabilité. Si une condition manque, le parcours réduit son engagement ou s’arrête. Une réponse technique réussie ne suffit pas lorsque le contenu ne permet plus une décision honnête.
Classer réversibilité et exposition
Une suggestion imparfaite est réversible ; une double capture ou une réservation impossible ne l’est pas. L’équipe classe chaque effet selon argent, stock, droit et communication. Les replis privilégient les actions corrigibles.
Le seuil dépend aussi du volume. Une approximation acceptable sur dix demandes devient dangereuse sur dix mille. Le monitoring combine taux, nombre absolu et valeur exposée avant de choisir le niveau.
La matrice de décision croise réversibilité, valeur et délai de détection. Une lecture peut accepter une donnée vieille de dix minutes ; une écriture financière exige un verdict unique. Produit signe ces compromis avec finance et opérations, puis la plateforme les transforme en policies testables plutôt qu’en consignes orales.
Cartographier les dépendances
Relier service et promesse
Stock, paiement, transport, identité, taxes, recherche et messagerie alimentent des sorties précises. La carte indique appel synchrone, événement, cache, owner, timeout et source de vérité. Un composant partagé ne reste pas une boîte anonyme.
Les parcours traversent cette carte avec un identifiant de corrélation. L’équipe sait quelles commandes ou pages utilisent une dépendance. L’incident peut cibler un marché ou un moyen de paiement au lieu de couper globalement.
Recenser les dépendances cachées
DNS, certificats, secrets, horloge, feature flags et back-office peuvent devenir aussi critiques qu’une API métier. Les jobs nocturnes et imports vendeurs créent des retards différés. La cartographie inclut ces chemins.
Un exercice retire chaque dépendance majeure et observe la sortie réelle. Les écarts entre diagramme et comportement deviennent des actions. Une documentation non éprouvée n’est pas un mode dégradé.
La carte doit aussi suivre les sorties asynchrones : webhooks, emails, factures et exports peuvent sembler secondaires pendant la panne puis produire des effets plusieurs heures après. Chaque flux déclare checkpoint, rétention, idempotence et procédure de replay. L’owner sait ainsi si une reprise peut rattraper ou si un dossier doit être revu manuellement.
Définir les niveaux de dégradation
Nommer des états opérationnels
Nominal, prudent, limité et arrêté donnent un langage commun. Chaque niveau associe fonctionnalités, messages, métriques et autorité de bascule. Les équipes ne débattent pas pendant l’incident de ce que « partiellement disponible » signifie.
Les états sont définis par domaine. Paiement peut être arrêté pendant que catalogue reste prudent. Le statut global expose une synthèse, mais le run conserve les décisions locales.
Utiliser des critères mesurables
Latence, erreurs, fraîcheur, backlog et exposition déclenchent une recommandation de niveau. Un owner confirme lorsque le risque métier l’exige. Les seuils sont versionnés et associés au budget d’erreur.
Par exemple, si le stock n’est plus rafraîchi depuis quinze minutes sur une catégorie tendue, alors la confirmation passe en mode limité. Deux fenêtres saines et un backlog résorbé sont nécessaires pour revenir au nominal.
Gouverner fraîcheur et incertitude
Transporter l’âge de la donnée
Prix, stock, délai et droit portent source, version et horodatage. Les consommateurs n’interprètent pas un cache comme une vérité éternelle. Le service retourne valeur, fraîcheur et niveau de confiance.
Les TTL suivent le risque et la fréquence de changement. Une donnée contractuelle varie moins qu’un stock. Le cache indique sa dernière invalidation et la raison de son repli.
Définir une valeur de repli
Dernière valeur connue, intervalle, absence ou confirmation différée sont des replis possibles. Le choix est documenté par champ. Un timeout ne devient jamais automatiquement « disponible » ou « gratuit ».
Si la valeur dépasse son âge maximal, alors l’interface retire l’engagement associé. Le journal conserve la décision. Le retour de la source invalide les caches touchés avant de rouvrir.
Le contrat de fraîcheur est exposé dans les traces et dans le dossier support. Pour une valeur servie, l’équipe retrouve la source, l’horodatage, le repli choisi et la policy active. Cette traçabilité permet de rechercher toutes les commandes ayant vu une donnée dépassée au lieu d’attendre les réclamations.
Dégrader catalogue et recherche
Conserver la découverte sûre
Une panne de recommandation peut revenir aux catégories ou aux meilleures ventes. Une recherche ralentie utilise un index sain antérieur si son âge reste compatible. Les pages n’inventent pas de stock ou de prix pour remplir les emplacements.
Les candidats dont les droits ou la disponibilité ne sont plus vérifiables perdent leur promesse précise. Ils peuvent rester consultables avec un message ou sortir du ranking selon la catégorie. Le fallback garde sa version.
Borner publications et imports
Si la validation catalogue tombe, les nouveaux contenus attendent en file plutôt que d’être publiés sans contrôle. Les mises à jour critiques peuvent suivre une voie vérifiée séparée. Le vendeur voit l’état réel.
Le consumer reprend depuis un checkpoint et revalide les versions. Une file croissante déclenche une réduction du débit. La reprise ne publie pas une offre devenue obsolète pendant l’attente.
Le contrôle de publication compare la version de l’index avec celle du catalogue. Une offre retirée depuis plus de cinq minutes ou une promotion expirée déclenche une purge ciblée et une alerte. La voie prioritaire réserve sa capacité aux retraits de sécurité et aux corrections de prix, tandis que les enrichissements éditoriaux attendent la résorption du backlog.
Protéger la commande
Distinguer panier et confirmation
Le panier peut conserver une intention avec des données datées ; la confirmation exige les préconditions actuelles. Prix, stock, droits, livraison et taxes sont revalidés. Le client voit les changements avant de payer.
Une dépendance incertaine peut produire un devis temporaire ou une demande à confirmer, mais pas un succès définitif. La machine d’états distingue attente, confirmée et refusée.
Préserver idempotence et réservations
Chaque tentative possède une clé et une version de panier. Les écritures de commande et d’outbox sont atomiques. Un retry retrouve le verdict, même si la dépendance revient entre les appels.
Les holds expirent selon une règle et libèrent le stock. Une confirmation tardive ne ressuscite pas une réservation. Les cas ambigus rejoignent une file avec owner et délai.
Par exemple, si le stock central devient inconnu mais que le vendeur maintient un quota local vérifié, alors seules les offres couvertes par ce quota restent confirmables. Les autres paniers deviennent des demandes. Ce compromis conserve du chiffre sans transformer une indisponibilité partielle en survente généralisée.
Éviter les paiements ambigus
Privilégier un verdict unique
Un prestataire en timeout peut avoir encaissé. La plateforme ne relance pas la capture avant réconciliation. Elle conserve intention, clé idempotente, commande et dernier état connu.
L’acheteur voit « vérification en cours » plutôt qu’un échec trompeur. Une file relit le fournisseur et produit capturé, refusé ou à investiguer. La commande suit ce verdict.
Basculer sans double effet
Un second moyen de paiement n’est proposé que si le premier est définitivement refusé ou annulé. Le routage multi-prestataire connaît les capacités, devises et risques. La bascule possède version et kill switch.
Si cinq paiements restent inconnus ou si la valeur dépasse le seuil, alors les nouvelles captures s’arrêtent. Finance et support reçoivent la liste exposée. Le retour exige rapprochement à zéro.
La réconciliation financière compare intention interne, verdict prestataire et mouvement bancaire. Chaque écart reçoit un état, une ancienneté et un owner ; aucun script ne transforme automatiquement un statut inconnu en échec. Si le webhook revient après remboursement ou bascule, alors une compensation contrôlée est créée sans modifier l’histoire de la commande.
Encadrer les fournisseurs externes
Mesurer ce que la marketplace observe
Le SLA contractuel ne remplace pas la latence et le taux d’erreur vus depuis les parcours. Les métriques portent région, opération et version. Une panne partielle peut toucher un seul mode.
Le vendor manager rapproche incidents, impact et communication. Les problèmes récurrents alimentent architecture, capacité ou renégociation. Le repli est testé avant renouvellement.
Limiter retries et tempêtes
Timeouts, backoff, jitter, circuit breaker et quotas empêchent une dépendance lente d’épuiser la plateforme. Chaque appel porte budget de temps. Les retries restent idempotents.
Le circuit s’ouvre sur des signaux mesurés et sonde la reprise avec une petite cohorte. Il ne renvoie pas tout le trafic au premier succès. Les files protègent les parcours prioritaires.
Le contrat fournisseur précise aussi les preuves de reprise : deux sondes saines ne suffisent pas si le backlog continue de croître. Le dashboard rapproche latence, erreurs, messages en attente et dossiers sans verdict. L’opérateur garde le circuit ouvert tant que la capacité observée ne peut pas absorber le trafic et le rattrapage.
Communiquer sans tromper
Adapter le message à la décision
Le message explique ce qui reste possible, la limite et la prochaine étape. « Service indisponible » est trop vague si la consultation fonctionne encore. « Délai à confirmer avant paiement » aide réellement.
Les écrans, emails et support utilisent le même statut de domaine. Une bannière globale ne masque pas les différences. Les textes sont préparés et localisés avant incident.
Conserver la continuité du dossier
L’utilisateur retrouve panier, demande et pièces après la reprise. Un identifiant lui permet de suivre une vérification. L’équipe ne lui demande pas de recommencer une opération déjà enregistrée.
Support voit la dépendance touchée, l’âge des données et les actions autorisées. Le mode lecture reste disponible lorsque possible. Les gestes manuels sont audités et réconciliés.
Piloter par kill switches
Construire des commandes ciblées
Les switches portent domaine, marché, fournisseur, catégorie ou action. Ils disposent d’un owner, d’une valeur sûre et d’un audit. Une commande globale existe pour l’urgence, mais n’est pas le seul outil.
La configuration est validée avant propagation. Les instances confirment la version active. Une bascule partielle ne laisse pas des comportements contradictoires sans alerte.
Sécuriser activation et retour
Un switch sensible exige prévisualisation d’impact et parfois double approbation. Son expiration empêche un mode dégradé oublié. Le dashboard montre qui l’a activé et pourquoi.
Le rollback fonctionnel ne supprime pas les événements créés. La reprise traite backlog et états avant désactivation. Un canary vérifie le nominal sur une cohorte.
Chaque commande sensible est signée par une policy de contrôle : prévisualisation du nombre d’offres ou commandes touchées, double validation au-delà d’un seuil financier, propagation confirmée et expiration automatique. L’instrumentation alerte si deux nœuds exécutent des versions différentes ou si le rollback ne restaure pas la cohorte attendue.
Tester et exploiter la reprise
Exercer les scénarios réels
Les tests coupent stock, paiement, transport, identité et feature flags. Ils mesurent détection, bascule, message, continuité et exposition. Les dépendances lentes sont aussi injectées.
Le scénario utilise des commandes synthétiques traçables. Les entrées et sorties restent disponibles pour le débrief. Chaque écart reçoit owner et échéance.
Réconcilier avant de clôturer
Files, caches, commandes et paiements doivent converger. Le runbook indique ordre de reprise, checkpoints et seuils. Un service vert ne signifie pas que les clients sont réparés.
Scénario : le transporteur revient mais mille devis attendent. Si leur promesse a expiré, alors ils sont recalculés et soumis au client ; ils ne deviennent pas des commandes silencieuses. L’incident reste ouvert jusqu’au verdict de chaque dossier.
Le débrief mesure temps de détection, temps de bascule, commandes exposées, interventions manuelles et délai de convergence. Une réussite technique avec cinquante dossiers ambigus reste un échec métier. Les résultats alimentent seuils, capacités et contrats fournisseurs, puis un second exercice vérifie la correction avant clôture de l’action.
Adapter la méthode et éviter les erreurs
Pour qui le mode dégradé est nécessaire
Il est nécessaire dès qu’une marketplace dépend de fournisseurs ou de flux asynchrones pour tenir sa promesse. Une petite plateforme peut commencer par paiement, stock et transport avec quelques niveaux clairs.
Produit définit la promesse ; domaine les états ; plateforme les replis ; run les seuils ; support les messages ; finance la réconciliation. Chaque owner valide une sortie.
Erreurs fréquentes en mode dégradé
Servir une donnée périmée sans signal, relancer un paiement ambigu, fermer tout le site, multiplier les retries et rouvrir avant rattrapage sont les erreurs majeures. Elles aggravent l’incident.
Une autre erreur consiste à concevoir le repli pendant la panne. Les contrats, messages, switches et exercices doivent exister avant que la dépendance ne tombe.
Plan d’action pour construire le mode dégradé
Semaines 1 à 4 : promesses et replis
La première semaine choisit paiement, stock et transport, puis cartographie leurs sorties et effets. La deuxième définit fraîcheur, niveaux, messages et valeurs de repli. Chaque action irréversible possède une condition d’arrêt.
Les semaines trois et quatre implémentent statut de domaine, timeouts, circuits et kill switches. L’instrumentation suit dépendance, âge, backlog et exposition. Les tests couvrent timeout, réponse fausse et événement perdu.
Semaines 5 à 8 : exercices et reprise
La cinquième semaine exécute un scénario par domaine. La sixième confie la bascule au run avec les messages support. Les files, caches et écritures possèdent checkpoints et procédures de réconciliation.
Les semaines sept et huit ouvrent une cohorte et testent un incident combiné. Le go exige promesse réduite mais vraie, aucune double écriture et retour nominal prouvé. Les actions manuelles sont rejouées dans le système.
Le comité conserve seuils, durées, décisions et dettes. Toute nouvelle dépendance doit déclarer repli, fraîcheur et owner avant son branchement au parcours public.
Le dossier de go rassemble la carte des dépendances, les policies versionnées, les captures des messages, les résultats des tests de charge et la preuve de réconciliation. Opérations peut activer chaque switch depuis le runbook sans accès développeur exceptionnel. Finance vérifie les paiements inconnus ; support rejoue trois dossiers réels ; produit confirme que chaque promesse réduite reste compréhensible. Si un de ces contrôles échoue, alors la cohorte demeure limitée et la dette reçoit un owner daté.
- À faire d’abord : choisir trois dépendances qui portent un engagement.
- À tester ensuite : timeout, donnée périmée, backlog et reprise partielle.
- À différer : les replis sans sortie utilisateur claire.
- À refuser : tout succès affiché lorsque le verdict reste inconnu.
Guides complémentaires pour l’opérateur
Structurer états et commandes
Les écrans du back-office opérateur aident à piloter statuts, files et switches.
Le catalogue PIM marketplace précise fraîcheur et publication.
Borner la première cohorte
Le MVP marketplace avant ouverture aide à limiter les dépendances critiques.
La méthode pour ouvrir une première catégorie permet d’éprouver les replis sur un volume réel.
Conclusion : réduire avant de mentir
Un mode dégradé fiable réduit la promesse selon la dépendance et le risque, sans confondre disponibilité technique et décision sûre.
Fraîcheur, niveaux, files et switches rendent le repli explicite. Catalogue, commande et paiement gardent leurs propres règles.
La reprise inclut backlog et réconciliation avant le nominal. Les exercices transforment une intention en capacité opérationnelle. Chaque retour reste conditionné par une preuve métier, un owner et un seuil vérifié.
Pour concevoir ces replis et leur run, Dawap peut vous accompagner dans votre marketplace opérateur.
