Une marketplace affiche une disponibilité globale de 99,95 %. Pourtant, les vendeurs attendent trois heures pour publier une offre, certains paiements restent « en cours » et le support ne voit pas les commandes touchées. La moyenne reste verte parce que les pages publiques répondent, même lorsque les opérations importantes sont bloquées.
Le problème vient d’un objectif technique unique appliqué à des domaines dont les utilisateurs, risques et temporalités diffèrent. Une recherche catalogue peut accepter un index vieux de quelques minutes ; une confirmation de paiement ne peut pas perdre son verdict. Mesurer les deux avec la seule disponibilité HTTP empêche de prioriser correctement.
Le vrai enjeu des SLO d’une marketplace opérateur est de borner la fiabilité de chaque promesse métier et de rendre son budget d’erreur décisionnel. Contre-intuitivement, un SLO moins élevé mais relié à une vraie sortie protège mieux les clients qu’un 99,99 % calculé sur une sonde décorative.
Vous allez comprendre comment définir domaines, SLI, fenêtres, budgets, alertes et dépendances. Catalogue, commande, paiement et support disposent d’objectifs distincts, puis les parcours transverses composent ces contrats sans masquer la cause ni la responsabilité pendant l’incident.
Relier fiabilité et parcours
Partir des sorties attendues
Publier une offre, trouver un produit, confirmer une commande, connaître un paiement et résoudre un incident sont des sorties métier. Chacune nomme utilisateur, début, fin et condition de succès. Une réponse 200 avec un état faux ne compte pas comme réussite.
L’équipe cartographie quelques parcours critiques et leurs pertes : abandon, annulation, double débit, retard vendeur ou ticket répété. Le SLO protège ces conséquences. Les endpoints et composants viennent ensuite comme moyens de mesure.
Classer criticité et tolérance
Un délai catalogue se rattrape parfois par une file ; un paiement ambigu demande une réconciliation immédiate. La criticité combine impact, réversibilité, exposition financière et nombre d’utilisateurs. Elle détermine objectif, fenêtre et réponse.
Les parcours internes comptent aussi lorsqu’ils conditionnent l’engagement public. Un back-office de support indisponible pendant un incident aggrave le dommage. Les équipes définissent le niveau de service attendu selon les heures et astreintes réellement assurées.
Séparer les domaines métier
Donner un owner à chaque promesse
Catalogue porte identité, publication et recherche ; commande porte panier, validation et cycle ; paiement porte intentions, captures et remboursements ; support porte visibilité et résolution. Chaque domaine possède owner produit et owner run.
Les frontières ne signifient pas isolement. Elles indiquent qui publie un état, qui le consomme et quelle dégradation est autorisée. Une matrice relie événements, API, files, dashboards et procédures de reprise.
Composer sans diluer
Le parcours d’achat dépend de catalogue, stock, commande et paiement. Son SLO transverse mesure le succès final, tandis que les SLO de domaine localisent la perte. Une moyenne des quatre serait trompeuse.
Un identifiant de corrélation traverse les appels et événements. L’observabilité restitue version, dépendance et verdict. Si le paiement réussit mais que la commande reste en attente, alors le parcours échoue et le domaine de réconciliation devient responsable.
La composition conserve la contribution de chaque domaine au budget de délai. Recherche peut consommer deux cents millisecondes, stock trois cents et commande le reste, mais une dépendance ne récupère pas automatiquement le temps économisé ailleurs. Les timeouts et fallbacks sont testés ensemble afin qu’une nouvelle intégration ne rende pas la promesse transverse mathématiquement impossible.
Construire des SLI utiles
Définir numérateur et dénominateur
Un SLI de succès compte événements éligibles et réussites selon une règle stable. Les exclusions sont nommées : trafic interne, requête invalide, annulation utilisateur ou maintenance annoncée. Elles ne changent pas pendant l’incident.
La source est proche de la sortie métier : événement confirmé, état réconcilié ou mesure synthétique. Les logs échantillonnés ne conviennent pas s’ils perdent précisément les erreurs. Data vérifie complétude et retard de chaque flux.
Combiner succès, délai et fraîcheur
Une opération peut réussir trop tard. Le SLI mesure alors réussite sous un seuil, distribution de latence ou fraîcheur d’état. Le percentile choisi correspond à une expérience, pas à une convention technique.
Les fenêtres glissantes révèlent la tendance ; les fenêtres calendaires soutiennent les engagements. Un dashboard montre objectif, consommation et données manquantes. Une absence de télémétrie ne devient jamais cent pour cent de réussite.
Le calcul est lui-même exploité comme un produit critique. Il publie heure du dernier événement, retard de traitement, taux d’événements rejetés et version de la requête. Une sonde compare chaque jour un échantillon brut au résultat agrégé ; tout écart au-delà du seuil suspend les décisions de budget jusqu’à correction.
Définir le SLO catalogue
Mesurer publication et propagation
Le SLI part d’une offre validée et s’arrête lorsqu’elle est consultable sur les surfaces prévues avec ses bons droits. Il mesure file, index, cache et cohérence. Une ligne écrite en base n’est pas encore une publication réussie.
La fenêtre dépend de la promesse vendeur : quelques minutes pour une mise à jour courante, davantage pour un import annoncé comme asynchrone. Les rejets métiers sortent du dénominateur technique mais restent suivis par leur propre indicateur de qualité.
Contrôler fraîcheur et exactitude
Prix, stock, statut et attributs critiques n’ont pas la même tolérance. Le système mesure âge de la dernière donnée et contradictions entre source, index et page. Un résultat disponible avec un mauvais prix n’est pas fiable.
Par exemple, si plus de 0,5 % des offres actives portent un stock vieux de plus de trente minutes, alors le boost de disponibilité est retiré et l’import concerné ralentit. Le retour exige rattrapage et cohérence sur une fenêtre complète.
Définir le SLO commande
Protéger confirmation et état
La commande réussit lorsqu’une intention valide reçoit un verdict unique, un identifiant et des lignes réservées. Timeout ambigu, double création et état impossible sont des échecs même si une réponse finit par arriver. L’idempotence fait partie du contrat.
Le SLI distingue panier, validation, confirmation et notifications. Une panne d’email n’annule pas la commande, mais elle dégrade une promesse de communication. Les métriques gardent chaque étape pour choisir le bon repli.
Mesurer progression après achat
Acceptation vendeur, préparation, expédition et livraison possèdent des délais métier. Le domaine surveille transitions en retard et événements manquants. Un statut « expédié » sans preuve transporteur peut être considéré incertain.
Les commandes bloquées dépassant leur SLO rejoignent une file avec montant, client, vendeur et dernier heartbeat. Le runbook prévoit retry, réconciliation, intervention et communication. La reprise ne fabrique pas un état pour fermer l’alerte.
La file sépare commande techniquement bloquée et dépendance métier attendue. Chaque item expose étape, horloge applicable, owner et prochaine action. Un worker idempotent relit l’outbox, compare les versions et produit un verdict ; les corrections manuelles passent par une commande auditée, jamais par une écriture directe sur le statut.
Définir le SLO paiement
Mesurer un verdict financier
Autorisation, capture, remboursement et payout ont chacun un état terminal attendu. Le SLI vérifie qu’une intention reçoit un verdict réconciliable sous le délai. Une redirection fournisseur réussie ne garantit pas que le ledger soit à jour.
Les refus légitimes ne sont pas des pannes, mais les erreurs techniques et états inconnus le sont. Les codes prestataires sont mappés et versionnés. Le monitoring distingue disponibilité, taux d’acceptation et risque.
Borner ambiguïté et rapprochement
Le cas critique est le paiement potentiellement effectué sans confirmation locale. Une file relit le prestataire avec une clé idempotente et rapproche intention, écriture et commande. Aucun retry de capture ne part avant ce contrôle.
Si plus de cinq paiements restent inconnus dix minutes ou si leur valeur dépasse le seuil financier, alors les nouvelles confirmations peuvent basculer vers un autre moyen ou s’arrêter. Finance et incident commander reçoivent la même liste d’exposition.
Définir le SLO support
Mesurer accès au contexte
Support doit retrouver commande, paiement, messages et événements avant de répondre. Le SLI mesure disponibilité et fraîcheur du dossier, pas seulement ouverture du logiciel. Une vue partielle pendant un incident peut produire une mauvaise action.
Les rôles et données sensibles restent contrôlés. Un mode dégradé en lecture permet d’informer sans modifier. Les accès d’urgence sont limités, horodatés et revus après usage.
Le dossier indique aussi la confiance de chaque donnée et son dernier rafraîchissement. Pendant une panne d’événements, support peut consulter la dernière version saine, mais l’interface signale son âge et interdit les actions irréversibles. La sonde vérifie régulièrement que commande, paiement et messages convergent vers la même chronologie.
Un exercice mesure le temps nécessaire pour retrouver les clients exposés depuis l’identifiant d’incident. Si la liste ne peut pas être produite sous le seuil, alors l’accès au contexte n’atteint pas son objectif, même lorsque l’écran principal reste disponible.
Distinguer réponse et résolution
Première réponse, prise en charge, résolution et réouverture mesurent des promesses différentes. Les objectifs varient par gravité et canal. Fermer automatiquement un ticket sans solution n’améliore pas le SLO.
Les dépendances métier sont visibles : remboursement en attente, vendeur absent ou bug produit. Le ticket conserve owner courant et prochaine échéance. Les réouvertures et transferts révèlent les résolutions fragiles.
Contractualiser les dépendances
Publier un contrat consommable
Chaque domaine annonce disponibilité, délai, quotas, erreurs, fraîcheur et comportement dégradé. Le consommateur sait quand retry, attendre, utiliser un cache ou refuser. Une dépendance interne n’est pas fiable par confiance implicite.
Le contrat contient owner, canal d’incident et historique des changements. Les tests de contrat vérifient schéma et codes. Les timeouts sont inférieurs au budget du parcours afin qu’un seul service ne consomme pas toute la promesse.
Prévoir fournisseurs externes
Paiement, transport, identité et messagerie ont leurs propres objectifs. La marketplace mesure ce qu’elle observe et définit un repli : multi-fournisseur, file, cache, information ou arrêt. Un SLA contractuel ne remplace pas la télémétrie réelle.
Les incidents externes sont corrélés aux parcours touchés. Le vendor manager reçoit volumes et impacts. Une dépendance récurrente peut imposer renégociation, nouvelle architecture ou promesse client différente.
Gouverner les budgets d’erreur
Transformer l’objectif en capacité de risque
Le budget représente les échecs tolérés sur une fenêtre. Il n’autorise pas à ignorer les clients ; il rend visible la marge avant rupture de promesse. Les volumes faibles utilisent aussi des événements absolus pour éviter des pourcentages trompeurs.
Chaque domaine suit budget restant, vitesse de consommation et causes. Les périodes commerciales importantes peuvent réduire le risque accepté. Une maintenance planifiée reste comptée ou exclue selon une règle fixée à l’avance.
Arbitrer livraison et stabilisation
Lorsque le budget brûle trop vite, les changements à risque ralentissent et les corrections prioritaires accélèrent. Le comité nomme les exceptions. Une feature urgente n’entre pas simplement parce que son équipe n’est pas owner du SLO.
Le retour au rythme normal exige budget stabilisé, cause traitée et preuve de reprise. Les investissements sont comparés à l’impact : tests, capacité, simplification ou repli. Le SLO ne devient pas une sanction abstraite.
La politique définit aussi les changements autorisés lorsque le budget est presque épuisé : correctifs, sécurité, réduction de charge et observabilité. Une revue courte examine risque, rollback et métrique attendue. Les exceptions expirent après le déploiement et leur impact est imputé au même budget, ce qui évite une série de décisions « urgentes » sans responsable.
Alerter sur la consommation
Utiliser plusieurs vitesses de burn
Une alerte rapide détecte une panne sévère ; une alerte lente révèle une dégradation chronique. Toutes deux portent fenêtre courte et longue pour limiter le bruit. Les seuils correspondent au budget et au temps d’action disponible.
Chaque page contient domaine, parcours, exposition, dépendance probable et lien runbook. Une alerte sans action n’éveille pas l’astreinte. Les dashboards exploratoires restent séparés des pages urgentes.
Tester la chaîne d’alerte
Des exercices injectent données manquantes, latence, taux d’échec et fausse récupération. Ils vérifient collecte, calcul, routage et acquittement. Une alerte silencieuse est un incident d’observabilité.
Les post-mortems suivent alertes trop tardives, inutiles ou absentes. Le tuning conserve l’historique. Supprimer une alerte bruyante sans corriger son SLI ou son owner ne résout rien.
Décider et reprendre en incident
Piloter par impact de domaine
L’incident commander voit parcours touchés, budget brûlé, volume, valeur et états inconnus. Les owners de domaine proposent repli et réconciliation. La priorité vient de l’impact utilisateur, pas du service qui génère le plus de logs.
Le kill switch peut geler publication, commande ou moyen de paiement séparément. Les preuves restent conservées. La communication précise ce qui fonctionne encore et évite de déclarer toute la marketplace indisponible.
Prouver le retour en service
La disparition de l’erreur ne suffit pas. Les files doivent rattraper, les états se réconcilier et les données retrouver leur fraîcheur. Le monitoring suit backlog et commandes exposées jusqu’à zéro ou transfert explicite.
Scénario : le paiement revient après vingt minutes mais trente commandes restent ambiguës. Si elles ne sont pas réconciliées, alors l’incident continue sur ce domaine malgré une disponibilité technique verte. La clôture exige verdict et communication pour chaque cas.
Adapter la méthode et éviter les erreurs
Pour qui des SLO par domaine conviennent
Ils conviennent aux marketplaces dont les parcours reposent sur plusieurs équipes et flux asynchrones. Une petite plateforme peut commencer avec quatre sorties critiques et quelques sondes, sans construire un catalogue de centaines d’objectifs.
Produit définit la promesse ; domaine les états ; plateforme l’instrumentation ; data le calcul ; run les alertes ; support l’impact. Chaque owner accepte le SLI et le repli avant publication.
Erreurs fréquentes dans les SLO marketplace
Mesurer seulement HTTP, moyenner les domaines, exclure les erreurs pendant incident, ignorer la donnée manquante et alerter sur chaque composant sont les erreurs majeures. Elles produisent des chiffres précis mais peu décisionnels.
Une autre erreur consiste à viser 100 % sans regarder le coût ni le repli. L’objectif utile protège une promesse explicite et attribue le risque ; il ne remplace pas la conception des états et de la reprise.
Plan d’action pour installer les SLO marketplace
Semaines 1 à 4 : sorties et mesures
La première semaine choisit publication d’offre, confirmation de commande, verdict paiement et résolution critique. Chaque équipe décrit succès, échec, délai et impact. La deuxième ferme domaines, owners, identifiants de corrélation et sources de vérité.
Les semaines trois et quatre instrumentent numérateurs, dénominateurs, fraîcheur et données manquantes. Data compare événements à un échantillon manuel. Les objectifs initiaux utilisent l’historique et la promesse réelle, puis documentent exclusions et repli.
Semaines 5 à 8 : budgets et incidents
La cinquième semaine construit budgets, burn rates et dashboards. La sixième route les alertes avec owner, runbook et kill switch de domaine. Les exercices testent file bloquée, paiement ambigu, index en retard et dossier support incomplet.
Les semaines sept et huit observent une fenêtre réelle et corrigent le bruit. Le go exige données fiables, alertes actionnables et reprise réconciliée. Une métrique sans owner ou un parcours sans stratégie de dégradation reste hors engagement public.
Le comité examine les exclusions, car elles deviennent facilement un moyen de préserver artificiellement l’objectif. Il conserve décisions, budgets consommés, incidents et date de révision. Une nouvelle promesse commerciale doit déclarer son SLO et sa dépendance avant lancement.
La recette finale fait intervenir l’astreinte qui exploitera réellement les alertes. Elle mesure détection, diagnostic, activation du repli, réconciliation et communication sur un chronomètre commun. Les écarts deviennent des actions attribuées avec échéance ; le passage en production attend que les chemins critiques puissent être exécutés sans connaissance détenue par une seule personne.
- À faire d’abord : choisir quatre sorties métier et leurs owners.
- À tester ensuite : retard catalogue, commande ambiguë, paiement inconnu et support aveugle.
- À différer : les SLI de composants sans impact parcours démontré.
- À refuser : toute donnée absente comptée comme une réussite.
Guides complémentaires pour l’opérateur
Structurer états et run
Les écrans du back-office opérateur aident à rendre files, impacts et reprises visibles.
Le catalogue PIM marketplace précise les états et fraîcheurs à surveiller.
Borner les premières promesses
Le MVP marketplace avant ouverture aide à choisir les parcours vraiment critiques.
La méthode pour ouvrir une première catégorie permet d’observer les SLO sur une cohorte réelle.
Conclusion : piloter la fiabilité utile
Des SLO marketplace utiles protègent des sorties métier et distinguent catalogue, commande, paiement et support sans perdre le parcours global.
SLI, fraîcheur, budgets et dépendances rendent les compromis visibles. Une alerte porte un impact et une action, pas seulement un composant.
La reprise inclut files, états et clients exposés jusqu’à réconciliation. La fiabilité devient une décision partagée entre produit et run.
Pour construire ces SLO et leur exploitation, Dawap peut vous accompagner dans votre marketplace opérateur.
