La plateforme affiche 99,98 % de disponibilité. Pourtant, des offres validées restent invisibles, certains acheteurs ne reçoivent aucune proposition, des commandes payées attendent une confirmation et des vendeurs contestent des versements impossibles à expliquer. Le chiffre technique est exact ; il mesure seulement une autre promesse.
Le problème apparaît quand le métier tente de fabriquer un KPI depuis des statuts conçus pour l’interface ou depuis des logs incomplets. Les exclusions changent après chaque incident, les dossiers absents disparaissent du dénominateur et un succès tardif finit par être compté comme une réussite normale.
La vraie question précède l’objectif : quels événements avaient réellement droit au service, quelle sortie prouve la réussite, dans quel délai et avec quelle politique pour les données tardives ? Contre-intuitivement, un SLI plus bas mais reproductible protège mieux la marketplace qu’un taux excellent dont personne ne peut reconstruire les occasions manquées.
Vous allez comprendre comment construire ces contrats sans déplacer les échecs hors du calcul, puis comment les tester sur des cas connus. Le résultat attendu n’est pas un dashboard supplémentaire : c’est une mesure que produit, opérations, finance et ingénierie peuvent recalculer, contester et utiliser pour décider où investir.
Notre accompagnement en scalabilité marketplace opérateur relie ces contrats aux files, dépendances et capacités. La page création de marketplace reste le socle lorsque modèle, parcours et gouvernance doivent évoluer ensemble.
Pour qui un SLI métier devient-il nécessaire ?
Le besoin devient prioritaire dès que plusieurs services contribuent au même résultat, que les équipes discutent du taux plutôt que de l’incident ou que finance et opérations recomposent leurs propres chiffres.
Repérer la métrique qui rassure sans décider
Un taux global stable tandis que les tickets augmentent constitue un signal faible. Un second apparaît lorsque deux dashboards donnent des succès différents pour la même période.
La divergence révèle souvent un événement éligible absent, une fin mal définie ou une fenêtre qui ne traite pas les retards de la même façon.
Adapter la précision à la maturité
Un pilote peut commencer par quatre événements et une extraction quotidienne. Une plateforme multi-pays exige versions, cohortes, correction tardive et preuve de recalcul.
La sophistication vient après la stabilité sémantique. Un calcul simple et relisible vaut mieux qu’un score composite impossible à contester.
Écrire le contrat de mesure avant la requête
Chaque SLI possède promesse, unité, population, numérateur, dénominateur, délai, exclusions, sources, fraîcheur et owner. La formule est versionnée avec sa date d’effet.
Nommer une occasion et une sortie
L’occasion correspond au moment où le service doit agir : offre soumise complète, demande de mise en relation recevable, commande validée ou versement arrivé à échéance.
La sortie décrit un effet observable, jamais une intention : offre consultable, proposition transmise, commande confirmée ou montant rapproché et disponible.
Attribuer les décisions de définition
Produit possède la promesse, opérations les états terminaux, finance le versement et l’ingénierie la collecte. La data garantit jointures et recalculs sans décider seule des exclusions.
Un changement de contrat passe par revue, simulation sur l’historique et publication de la rupture de série.
Définir les événements éligibles sans arranger le dénominateur
L’éligibilité se décide avec les informations connues au début. Retirer après coup les cas difficiles transforme le SLI en taux de réussite des seuls dossiers réussissables.
Distinguer invalide, refusé et échoué
Une soumission incomplète peut être inéligible si la règle est explicite avant l’envoi. Une offre valide refusée pour une panne de contrôle appartient au dénominateur et échoue.
Un refus métier conforme peut être une sortie réussie si le service promis consiste à rendre une décision, pas nécessairement à publier.
Geler la population de chaque fenêtre
Le registre conserve les identifiants éligibles et la version de règle. Une correction de données ne fait pas disparaître silencieusement une occasion passée.
Les exclusions portent motif, source et owner. Leur volume est publié à côté du SLI afin qu’une amélioration par rétrécissement reste visible.
Prouver une réussite métier plutôt que lire un statut
Un statut peut être anticipé, corrigé ou désynchronisé. La preuve associe événement terminal, effets attendus et absence de contradiction connue.
Choisir un événement terminal durable
La publication réussit lorsque l’offre est disponible sur la surface prévue avec vendeur, prix et droits corrects. Une écriture en base ou un job terminé ne suffit pas.
Le versement réussit lorsque montant, bénéficiaire, commission et échéance sont rapprochés, pas au moment où le batch démarre.
Gérer annulation et compensation
Une commande confirmée puis annulée par rupture révèle une réussite technique suivie d’un échec de promesse. Les deux événements restent consultables.
Le SLI choisi peut compter la confirmation sous délai et un indicateur de durabilité à 24 heures. Fusionner les deux masquerait le mécanisme.
Mesurer succès et délai dans le même contrat
Une opération peut aboutir trop tard. Le numérateur compte donc les réussites avant échéance, tandis que la distribution conserve le temps de tous les cas terminés.
Fixer l’horloge métier
Le début vient de l’événement éligible, la fin de la preuve. Les pauses légitimes, comme une pièce attendue du vendeur, suivent une règle explicite et restent mesurées séparément.
Temps système et temps calendrier sont conservés. Le premier éclaire la performance interne ; le second représente l’expérience réelle.
Publier taux et distribution
Le pourcentage sous seuil montre la promesse tenue. P50, P95 et longue traîne expliquent la forme du service et les cohortes qui décrochent.
Une amélioration de moyenne ne compense pas des dossiers bloqués. Le plus ancien objet et le nombre hors fenêtre accompagnent toujours le taux.
Construire le SLI de publication d’offre
L’occasion commence lorsqu’une offre complète entre dans le workflow de décision. La réussite exige une décision explicable puis, si elle est acceptée, une visibilité effective sur les surfaces promises.
Compter la décision et la propagation
Deux mesures restent liées : délai de décision et délai de publication après acceptation. Elles séparent modération, indexation, cache et exposition front.
Un rejet conforme dans le délai réussit la décision mais n’entre pas dans le dénominateur de propagation.
Vérifier la surface réellement promise
Un canari recherche l’offre par URL, catégorie et recherche lorsque ces canaux font partie du contrat. Le résultat respecte droits, pays et stock.
Cas concret : sur 1 000 offres éligibles, 970 décidées sous quatre heures et 940 visibles sous trente minutes produisent deux SLI, jamais un 94 % ambigu.
Par exemple, si le seuil de décision est de quatre heures et que 25 dossiers restent sans preuve à la fermeture de la fenêtre, ils demeurent dans le dénominateur comme résultats inconnus ou échoués selon le contrat. Les retirer parce que le workflow n’a pas produit de statut embellirait précisément la panne que le SLI doit révéler.
Construire le SLI de mise en relation
Une demande éligible exprime besoin, zone, disponibilité et critères obligatoires. La réussite n’est pas le lancement d’un algorithme mais une proposition conforme transmise aux parties.
Définir une proposition utile
Le candidat respecte contraintes bloquantes et possède la capacité annoncée. Un vendeur indisponible ou hors zone ne compte pas comme réponse.
La qualité commerciale ultérieure reste séparée : réponse, devis, conversion et satisfaction complètent le SLI sans modifier sa définition.
Traiter absence de candidat et refus
Si aucun vendeur ne satisfait les critères, une réponse explicite peut réussir le service de décision tout en révélant un déficit de liquidité.
La plateforme publie donc taux de décision sous délai et taux de demandes recevant au moins une proposition. Les confondre masquerait le manque d’offre.
Construire le SLI de commande aboutie
L’occasion naît après validation des données nécessaires et tentative de paiement conforme au parcours. La réussite exige identifiant durable, paiement cohérent et confirmation visible.
Séparer échec utilisateur et échec plateforme
Un moyen de paiement refusé par la banque suit une classe distincte. Un timeout, un double débit ou une commande orpheline constitue un échec de service.
La règle s’appuie sur codes PSP et réconciliation, non sur le seul écran présenté à l’acheteur.
Mesurer la durabilité de la confirmation
Un succès immédiat peut être annulé parce que le stock n’était pas réservable. Le SLI primaire mesure la commande ; un second suit stabilité après la fenêtre logistique.
Cette séparation localise paiement, orchestration et stock sans diluer leur impact dans une moyenne de conversion.
Construire le SLI de versement vendeur explicable
L’occasion correspond à un montant arrivé à échéance selon contrat, réserve et litiges connus. La réussite exige ordre accepté, rapprochement et détail accessible au vendeur.
Figer l’échéance et le montant attendu
Le snapshot conserve commandes, commissions, remboursements, réserves et ajustements qui composent le versement. Une correction ultérieure crée une nouvelle version.
Un paiement parti à temps avec un montant inexpliqué ne satisfait pas entièrement la promesse de service.
Distinguer fournisseur et responsabilité opérateur
Le PSP peut retarder l’exécution après acceptation. Le SLI opérateur mesure préparation et transmission ; un SLI bout en bout suit disponibilité effective.
Les deux apparaissent ensemble afin de protéger le vendeur sans attribuer automatiquement la cause au mauvais acteur.
Traiter les données tardives, absentes et corrigées
Un SLI calculé avant réception de toutes les preuves peut évoluer. Le système publie fraîcheur, complétude et statut provisoire plutôt que de transformer l’absence en échec ou en réussite.
Utiliser watermark et période de correction
Chaque source annonce jusqu’où elle est supposée complète. La fenêtre reste provisoire jusqu’au watermark, puis accepte des corrections pendant une durée définie.
Le dashboard conserve valeur publiée et valeur corrigée. La différence mesure la qualité de collecte.
Réconcilier les dénominateurs
Les occasions sources sont comparées au registre analytique. Un écart ouvre une alerte de données avant toute interprétation de performance.
Une suppression RGPD peut anonymiser l’identité sans retirer l’événement agrégé nécessaire au dénominateur, selon la politique validée.
Segmenter sans perdre la vérité globale
Les cohortes révèlent vendeurs, pays, catégories, modes logistiques et versions qui décrochent. Elles n’autorisent pas à choisir après coup uniquement la vue favorable.
Borner les dimensions
Les axes correspondent à une différence de promesse ou d’action. Commande et offre restent recherchables par identifiant, jamais utilisées comme labels de séries.
La valeur inconnue est publiée. Son augmentation signale une régression d’instrumentation.
Présenter micro et macro moyennes
Le taux global pondéré montre l’expérience totale. La moyenne par cohorte empêche les petits marchés ou parcours de disparaître derrière le volume dominant.
Les volumes accompagnent chaque taux. Un 100 % calculé sur deux occasions ne devient pas une preuve de scalabilité.
Éviter les erreurs fréquentes de calcul SLI
Les principales erreurs améliorent artificiellement le chiffre : exclusion tardive, succès déduit d’un statut intermédiaire, doublons dans le numérateur ou fenêtre recalculée sans version.
Ne pas compter tentatives et objets ensemble
Trois retries pour une commande représentent une occasion, une réussite éventuelle et trois tentatives. Mélanger ces grains peut produire un taux supérieur à 100 %.
L’idempotency key et l’identité métier servent à dédupliquer avant agrégation, tout en conservant les tentatives pour le diagnostic.
Ne pas modifier la règle pendant l’incident
Une exclusion nouvelle peut être justifiée, mais elle s’applique à une version suivante et simule son impact historique. Le SLI courant reste lisible.
Corriger silencieusement le passé détruirait la preuve qui permet de décider du budget de fiabilité.
Implémenter le registre SLI et ses responsabilités
Le modèle relie définition, version, événement éligible, preuve, délai, exclusion, cohorte, fenêtre et valeur publiée. Chaque calcul pointe vers les données sources.
Contractualiser ingestion et calcul
En entrée arrivent événements versionnés et identités stables ; en sortie, la pipeline produit numérateur, dénominateur, distribution, exclusions et complétude.
Instrumentation, monitoring, journalisation et dépendances possèdent des owners. Le runbook prévoit retard source, rollback de formule et repli vers la dernière version fiable.
Garantir replay et idempotence
Une file d’ingestion rejouée ne duplique pas les occasions. Le calcul peut être reconstruit depuis un journal immuable et la version de contrat.
Si un mapping change, la migration produit une nouvelle série. Le monitoring compare avant-après et bloque une baisse inexpliquée du dénominateur.
Tester formules, replays et cas limites
Une fixture couvre réussite à temps, réussite tardive, refus conforme, échec, doublon, annulation, preuve absente et événement arrivé hors ordre.
Vérifier le calcul à la main
Dix occasions connues produisent un numérateur et un dénominateur attendus. Une personne non auteure reconstruit la valeur depuis le contrat et les événements.
Le seuil de sortie exige égalité exacte des comptes et explication de chaque exclusion, pas seulement un pourcentage proche.
Rejouer les données tardives
Le même lot arrive dans trois ordres et avec des doublons. La valeur finale reste identique, tandis que les versions provisoires gardent leur historique.
Une panne de source teste « inconnu », alerte de fraîcheur et reprise sans inventer de zéros.
Plan d’action : déployer quatre SLI en six semaines
Le pilote choisit une cohorte et les quatre promesses. Il vise des contrats reproductibles, pas des objectifs ambitieux décidés avant la qualité des données.
La sortie exige calcul manuel concordant, replay idempotent, fraîcheur visible et une décision de fiabilité fondée sur chaque SLI.
Commencer par les occasions
- À faire d’abord : promesse, éligibilité, preuve, délai, exclusions, grain, sources et owner.
- À différer : objectifs contractuels, score composite et extension à toutes les catégories.
- À refuser : statut intermédiaire comme succès, exclusion rétroactive et donnée absente transformée en zéro.
Produit, opérations, finance et ingénierie relisent vingt cas réels par promesse. Ils marquent les désaccords avant de choisir les tables ou l’outil de visualisation.
La baseline conserve valeur, volumes, complétude et dispersion. Elle ne sert pas encore de sanction ; elle révèle le service réellement rendu et la dette de mesure.
Une revue de décision confronte ensuite les quatre résultats. Si la publication reste sous 95 % alors que commande et versement tiennent leur cible, le premier investissement porte sur validation, indexation ou propagation catalogue. Si tous les SLI chutent dans la même fenêtre, l’équipe recherche plutôt une dépendance partagée ou une rupture de collecte avant d’ouvrir quatre chantiers.
Livrer par preuves successives
- Semaine 1 : écrire les quatre contrats et classer quatre-vingts cas historiques.
- Semaine 2 : instrumenter occasions, preuves, identités et horloges ; mesurer les trous.
- Semaine 3 : calculer taux, délais, exclusions et complétude sur une cohorte pilote.
- Semaine 4 : tester doublons, corrections tardives, données absentes et changement de version.
- Semaine 5 : publier micro et macro moyennes, exemples et registre de définitions.
- Semaine 6 : faire décider un investissement, exercer le recalcul et fixer la prochaine cohorte.
Le pilote réussit lorsqu’un tiers explique chaque valeur, retrouve les occasions manquantes et distingue une baisse du service d’une panne de collecte.
Avant extension, l’équipe rejoue également une semaine complète avec la version précédente du contrat. Elle documente les écarts de numérateur, de dénominateur et d’exclusions, puis refuse la promotion si plus de 1 % des occasions changent de classe sans raison métier explicite. Ce seuil protège la continuité de lecture autant que la formule elle-même.
Relier SLI, SLO et scalabilité sans cannibalisation
Cette méthode possède la construction de la mesure. Elle ne redéfinit ni les objectifs de fiabilité ni les budgets d’erreur déjà traités ailleurs.
Passer du SLI vérifié au SLO gouverné
Le cadre des SLO marketplace par domaine transforme ensuite les mesures en objectifs, budgets d’erreur, alertes et décisions d’investissement.
La frontière est claire : ici, qui entre au dénominateur et quelle preuve compte ; là-bas, quel niveau viser et que faire lorsque le budget se consume.
Relier la mesure aux seuils de scale
L’analyse de la scalabilité des jobs, caches, recherche et files marketplace localise les capacités qui limitent le service.
- Mesurer une promesse à partir de ses occasions réelles.
- Versionner preuve, délai, exclusion et correction tardive.
- Fixer l’objectif seulement après une baseline reproductible.
Conclusion : mesurer la marketplace sans arranger son histoire
Publication, mise en relation, commande et versement possèdent des occasions, des preuves et des temporalités différentes. Une disponibilité globale ne peut pas les représenter.
Le contrat SLI protège le dénominateur avant de discuter du taux. Les données tardives, exclusions et versions deviennent visibles plutôt que corrigées en silence.
Une mesure reproductible rend ensuite possibles SLO, budget d’erreur et capacity planning. Elle permet surtout de distinguer dégradation du service et défaut de collecte.
Pour industrialiser cette base, notre expertise en création et reprise de marketplace opérateur relie événements, files, calculs, dashboards et runbooks jusqu’à des décisions de fiabilité défendables.
