Le stock d’une offre affiche douze unités alors que l’ERP vendeur est vide depuis trois heures. Une commande passe, le vendeur l’annule et le support promet un remboursement. Dans un autre rayon, une fiche parfaitement fraîche ne contient pas la puissance nécessaire au choix. Ailleurs, prix catalogue et prix panier divergent après une promotion.
Ces situations portent toutes l’étiquette « mauvaise donnée », mais elles n’ont ni la même cause ni le même impact. Un taux de qualité global à 97 % peut paraître rassurant alors que les 3 % restants concentrent les produits les plus vendus. L’équipe corrige des lignes sans savoir quelle promesse protéger en premier.
Le vrai enjeu d’une marketplace opérateur consiste à transformer fraîcheur, complétude et cohérence en niveaux de service reliés à des décisions. Contre-intuitivement, viser 100 % partout peut dégrader le service : les contrôles retardent des données peu critiques tandis qu’une rupture à fort impact reste noyée dans la moyenne.
Vous allez comprendre comment définir des SLO par usage, construire leur budget d’erreur et organiser la reprise. Le dispositif nomme producteurs, consommateurs et owners, observe les événements de bout en bout et déclenche une action avant que l’acheteur ne découvre l’écart.
Relier la qualité à une promesse métier
Partir de la décision affectée
Une donnée n’est pas bonne dans l’absolu. Elle est assez fiable pour publier, comparer, commander, payer ou piloter. L’équipe décrit la décision, le champ utilisé, la tolérance et la conséquence d’un défaut. La disponibilité influence la commande ; une photo secondaire influence surtout la confiance ; un IBAN incohérent bloque le paiement.
Cette carte relie l’objet métier à un résultat observable : annulation, recherche sans réponse, litige, marge ou temps support. Les catégories critiques reçoivent un niveau plus exigeant. Le choix est assumé par le responsable marketplace et non délégué au seul outil de data quality.
Formuler un engagement mesurable
Un SLO associe population, dimension, seuil et fenêtre. « 99 % des offres actives du top 500 disposent d’un stock daté de moins de quinze minutes sur sept jours » peut être calculé et discuté. « Les données doivent être fiables » ne permet ni alerte ni arbitrage.
L’engagement précise exclusions et mode dégradé. Une offre sans remontée depuis trente minutes peut être masquée, proposée sur devis ou affichée avec délai confirmé. La conséquence est choisie avant l’incident afin que le support ne réinvente pas la règle à chaque vendeur.
Choisir données et consommateurs critiques
Inventorier les chaînes qui portent la promesse
Le registre suit produit, offre, vendeur, stock, prix, commande, paiement et livraison. Pour chaque objet, il nomme système source, transformations, destinations et équipes consommatrices. Une colonne « criticité » dépend de l’usage, du volume et de la réversibilité, pas de la préférence technique.
Le premier périmètre couvre une catégorie, quelques vendeurs et trois décisions majeures. Cette limite permet de vérifier les calculs et les alertes. Étendre immédiatement à tous les attributs crée des milliers de contrôles dont personne ne peut traiter les résultats.
Segmenter par impact plutôt que par table
Les mêmes champs peuvent exiger plusieurs SLO. Un stock vieux de deux heures reste acceptable pour du mobilier fabriqué sur commande, mais pas pour une pièce disponible en urgence. Les fenêtres suivent la promesse commerciale et le mode d’approvisionnement.
L’équipe construit des cohortes : top ventes, produits réglementés, longue traîne, vendeurs API et vendeurs fichier. Elle compare incident, revenu et effort de correction. Un SLO séparé empêche une cohorte stable de masquer une source défaillante ou inversement.
Définir un SLO de fraîcheur
Mesurer l’âge au point de consommation
La fraîcheur est le temps entre l’événement source et la donnée réellement utilisée. L’horodatage d’un fichier reçu ne prouve pas que le front l’a indexé. La mesure traverse extraction, transport, traitement, PIM, moteur de recherche et cache jusqu’à l’affichage ou au calcul.
Chaque événement conserve heure source, heure d’ingestion, heure de publication et identifiant de version. Les décalages d’horloge sont contrôlés. Le tableau montre percentiles plutôt qu’une simple moyenne : un P95 à vingt minutes révèle la file lente que cinq secondes de médiane cachent.
Adapter cadence et conséquence
Prix promotionnel, stock, délai et certification n’ont pas la même durée de vie. L’owner fixe un objectif selon vitesse de changement et coût d’une erreur. Un stock volatile peut viser cinq minutes ; une fiche technique stable, vingt-quatre heures après validation.
Par exemple, si le P95 du stock critique dépasse quinze minutes pendant deux fenêtres, alors l’acquisition payante est suspendue sur les offres concernées et la source passe en diagnostic. Une absence complète déclenche un mode plus protecteur qu’un simple retard connu.
Mesurer la complétude utile
Distinguer présence et capacité de décision
Compter les champs remplis récompense des valeurs inutiles. La complétude utile vérifie les attributs nécessaires à la recherche, à la compatibilité, à la commande et à la conformité. Une valeur « inconnu » ou une image factice est présente techniquement, mais ne permet aucune décision.
Le panier témoin contient des recherches et commandes représentatives. Pour chacune, l’équipe identifie les champs indispensables. Le score pèse ces attributs et contrôle format, unité et vocabulaire. La décoration éditoriale reste séparée du minimum de publication.
Suivre le défaut jusqu’à sa source
Chaque rejet cite règle, champ, valeur, vendeur et version. Le back-office propose l’action autorisée : corriger, demander, dépublier ou accepter une dérogation datée. La file est regroupée par cause afin qu’une erreur de mapping soit réparée une fois plutôt que fiche par fiche.
Si plus de 5 % des offres actives perdent un attribut critique après une mise à jour, alors la publication de la source est stoppée. Le rollback restaure la version précédente et conserve les nouvelles données en quarantaine. L’owner analyse le contrat avant de relancer.
Contrôler la cohérence entre systèmes
Écrire les invariants métier
La cohérence vérifie des relations : prix panier égal à la règle publiée, stock réservé inférieur au disponible, offre active rattachée à un vendeur autorisé, remboursement inférieur au montant encaissé. Ces invariants sont plus utiles que la recherche générique de valeurs atypiques.
Chaque invariant possède source de vérité et ordre de priorité. Si PIM et ERP divergent, l’équipe sait lequel commande la vente et lequel doit être corrigé. Une fusion automatique sans règle peut propager la valeur la plus récente alors qu’elle est précisément erronée.
Réconcilier sans écraser la preuve
La réconciliation compare identifiants, versions et montants à une cadence adaptée. Elle produit un écart attribué, pas une correction silencieuse. L’écriture initiale, l’écriture corrective, la cause et l’approbateur restent consultables pour les commandes et la finance.
Un scénario rejoue une promotion expirée dont le cache conserve le prix. Si le panier calcule un autre montant, alors la vente est bloquée ou le prix favorable est honoré selon la règle commerciale. Le monitoring vérifie ensuite que front, panier et ledger convergent.
Construire objectifs et budget d’erreur
Transformer la tolérance en capacité d’arbitrage
Un SLO à 99 % autorise 1 % de défaut sur la fenêtre définie. Ce budget d’erreur est réparti selon impact et durée. Dix minutes de retard sur un produit inactif ne valent pas dix minutes sur la référence qui concentre les commandes.
Le tableau affiche consommation du budget, tendance et causes. À 50 %, l’équipe analyse ; à 80 %, elle gèle les changements risqués ; à 100 %, elle applique le mode dégradé et priorise la fiabilité. Ces actions sont écrites avant la dérive.
Éviter l’objectif impossible ou décoratif
Un objectif trop bas normalise les annulations. Un objectif à 100 % peut empêcher toute évolution sans garantir l’absence d’incident. L’équipe utilise l’historique, le coût d’échec et la capacité de correction pour proposer un niveau, puis le teste sur une cohorte.
Le SLO est révisé lorsque la promesse ou la source change, jamais pour effacer une période mauvaise. L’ancienne version, ses résultats et la décision restent dans le registre. Le comité peut renforcer un seuil après stabilisation ou segmenter un usage plus critique.
Écrire des contrats de données
Nommer schéma, sémantique et responsabilité
Le contrat décrit identifiant, type, unité, valeurs permises, nullabilité, événement, cadence et owner. Il explique le sens métier : « stock disponible » inclut-il réservations, sécurité et boutiques ? Cette définition évite deux calculs corrects techniquement mais incompatibles.
Producteur et consommateur approuvent le contrat. Le producteur annonce un changement ; le consommateur précise sa tolérance et sa reprise. Une version majeure coexiste pendant une fenêtre définie. Le système rejette un message incompatible plutôt que d’inventer une conversion.
Sécuriser fichiers, API et événements
Un fichier possède nommage, manifeste, compteur, checksum et date source. Une API expose version et erreurs explicites. Les webhooks transportent identifiant d’événement, version et clé d’idempotence. Les retries ne créent ni doublon ni retour à un état plus ancien.
Les dépendances sont cartographiées avec timeout, file, rétention et procédure de replay. Si un message arrive hors ordre, alors la version empêche l’écrasement. Le runbook décrit réouverture, réconciliation et validation après reprise.
Instrumenter la chaîne de bout en bout
Corréler une donnée à son parcours
Un identifiant de corrélation relie source, ingestion, transformation, publication et usage. Les journaux contiennent version, règle appliquée, durée et résultat sans exposer de données sensibles. L’owner peut partir d’une commande annulée et retrouver l’état affiché au moment du choix.
La mesure est réalisée depuis le point de consommation. Un pipeline vert ne suffit pas si l’index ou le cache reste ancien. Des sondes synthétiques interrogent des références témoins et comparent leurs valeurs avec la source attendue.
Construire des alertes actionnables
L’alerte indique SLO, cohorte, écart, impact, début, owner et première action. Elle groupe les milliers d’offres touchées par une même cause. Un seuil de persistance filtre un retard transitoire, tandis qu’une absence totale déclenche immédiatement.
Le monitoring distingue symptôme et cause probable. Il propose tableau, file et runbook. Si personne n’accuse réception sous quinze minutes pour une cohorte critique, l’escalade change de niveau. La fermeture exige rétablissement et consommation du budget recalculée.
Traiter les incidents de qualité
Protéger l’acheteur avant de réparer
La première décision limite l’impact : masquer, figer, basculer sur devis, afficher un avertissement ou arrêter la commande. Le choix dépend du type de donnée et du risque. Continuer avec une valeur connue comme fausse pour préserver la conversion augmente litiges et coût support.
Le responsable incident confirme population, début et promesse touchée. Il attribue diagnostic et communication séparément. Le vendeur reçoit les références affectées et la conséquence. Le support dispose d’une réponse cohérente pour les commandes déjà passées.
Réparer, rejouer puis apprendre
La correction passe en quarantaine, puis rejoue une cohorte témoin. Les sorties sont comparées avant publication. Une reprise massive possède débit, monitoring et rollback. Le système conserve les événements manqués assez longtemps pour restaurer l’ordre.
La revue recherche cause de production, défaut de détection et temps de décision. Elle crée une action avec owner et échéance. Le SLO n’est pas abaissé pour fermer l’incident. Si le même défaut consomme deux budgets consécutifs, alors l’architecture ou le contrat devient prioritaire.
Rendre les vendeurs responsables sans les bloquer
Montrer la qualité au bon niveau
Le portail vendeur présente les règles critiques, le score par cohorte et les fiches à corriger. Il explique l’impact : offre masquée, achat sur devis ou baisse de couverture. Une liste brute de champs invalides ne permet pas de prioriser.
Le vendeur peut télécharger les erreurs, corriger en masse et vérifier avant republication. Pour une source API, il retrouve payload, version et motif sans données d’un autre partenaire. Les temps de correction alimentent l’accompagnement et le contrat de service.
Graduer contrôle et sanction
Une erreur isolée reçoit une demande. Une dérive répétée entraîne suspension de la cohorte ou changement de canal. Un risque réglementaire bloque immédiatement. Les seuils et recours figurent dans les règles vendeur ; le seller manager n’invente pas une sanction au téléphone.
Si un fournisseur respecte la fraîcheur mais échoue sur la complétude, son plan cible le mapping plutôt que toute l’intégration. Cette précision réduit le coût et évite de pénaliser les offres conformes. Une dérogation possède motif, périmètre et date de fin.
Installer une gouvernance de produit data
Distribuer les rôles de décision
Le métier possède la promesse et l’impact ; le data owner possède définition et source ; la plateforme possède transport et observation ; les opérations possèdent reprise ; le vendeur possède la donnée fournie. Un RACI par SLO empêche que chaque incident remonte à une équipe centrale.
Le comité mensuel examine budget d’erreur, incidents, exemptions et changements. Il arbitre selon revenu, risque et effort. Il ne relit pas toutes les anomalies. Les décisions modifiant une promesse ou une règle de publication sont signées par les owners concernés.
Piloter un portefeuille de SLO
Le registre limite le nombre d’objectifs actifs et archive ceux sans décision associée. Chaque SLO affiche coût de mesure, incidents évités et action déclenchée. Une métrique jamais consultée ni utilisée est supprimée ou transformée.
Les objectifs accompagnent les évolutions de catégorie, pays et canal. Avant une expansion, l’équipe confirme sources, volumes et tolérances. Le nouveau périmètre passe par canary ; son budget reste séparé jusqu’à stabilisation afin de ne pas masquer le service existant.
Adapter la méthode et éviter les erreurs
Pour qui les SLO de qualité sont utiles
Ils servent au responsable marketplace qui protège la promesse, au product manager catalogue, aux data engineers, aux opérations, au seller manager et au support. Ils deviennent indispensables lorsque plusieurs systèmes, vendeurs ou pays produisent des valeurs concurrentes.
Une petite cohorte manuelle peut commencer avec trois contrôles et un tableau simple. Le besoin d’outillage augmente avec fréquence, volume et irréversibilité. La discipline de définir source, seuil et conséquence reste la même, même sans plateforme data dédiée.
Erreurs fréquentes : mesurer sans protéger
Moyenner toutes les lignes, mesurer avant le cache, compter les champs présents et alerter sans owner produisent de beaux dashboards. Ils ne réduisent ni annulations ni temps support. Copier un seuil technique sans promesse métier crée aussi une priorité artificielle.
Chaque mesure doit répondre à trois questions : quelle décision, quel impact, quelle action ? Sans réponse, elle reste exploratoire. Les équipes commencent par quelques cohortes critiques et prouvent que l’alerte arrive avant l’incident visible.
Plan d’action SLO en huit semaines
Semaines 1 à 4 : choisir et mesurer
La première semaine sélectionne une promesse et vingt incidents récents. L’équipe relie chacun aux objets, systèmes et décisions. Elle choisit deux cohortes et trois dimensions. La deuxième écrit définitions, sources, fenêtres, seuils et modes dégradés. Chaque SLO reçoit owner, consommateur et hypothèse de valeur dans le registre.
Les semaines trois et quatre ajoutent horodatages, identifiants de corrélation et sondes au point de consommation. Le tableau calcule percentiles, complétude utile, invariants et budget d’erreur. Les équipes confrontent mesure automatique et dossiers réels. Elles corrigent les faux positifs avant toute alerte opérationnelle.
Semaines 5 à 8 : alerter, reprendre et décider
Une cohorte pilote reçoit alertes avec file, owner, délai et runbook. L’équipe provoque retard, champ critique absent, divergence de prix et événement dupliqué. Elle vérifie entrées, sorties, responsabilités, dépendances, instrumentation, retry, idempotence et rollback. Chaque scénario conserve preuve et temps de retour.
À la huitième semaine, le comité compare incidents évités, budgets consommés, charge et temps de correction. Le go étend uniquement les SLO qui déclenchent une action fiable. Les autres sont simplifiés ou arrêtés. Une nouvelle catégorie passe après la stabilisation de la cohorte, sans diluer les seuils existants.
- À faire d’abord : relier trois défauts critiques à une décision et un impact.
- À tester ensuite : provoquer retard, absence et incohérence sur une cohorte.
- À différer : les contrôles sans consommateur ni action définie.
- À refuser : un SLO global qui masque les offres et vendeurs à fort impact.
Guides complémentaires pour l’opérateur
Structurer le catalogue et ses contrôles
Le catalogue PIM marketplace relie taxonomie, attributs et modération aux décisions de publication.
Les écrans du back-office opérateur rendent files de qualité, propriétaires et preuves accessibles au run.
Borner le périmètre d’apprentissage
Le MVP marketplace à livrer avant l’ouverture aide à choisir les flux dont la donnée doit tenir dès le pilote.
La méthode pour ouvrir une première catégorie fournit une cohorte où vérifier fraîcheur, complétude et cohérence sans généraliser trop tôt.
Conclusion : piloter la donnée par ses effets
Fraîcheur, complétude et cohérence deviennent utiles lorsqu’elles protègent une décision acheteur, vendeur, finance ou opérationnelle.
Un SLO précise population, seuil, fenêtre et conséquence. Son budget d’erreur transforme une dérive en arbitrage plutôt qu’en tableau passif.
Contrats, instrumentation et runbooks relient le défaut à sa source puis sécurisent la reprise. Les vendeurs voient les corrections prioritaires et les règles de suspension.
Pour définir vos niveaux de service data et industrialiser leur pilotage, Dawap peut vous accompagner dans votre projet de marketplace opérateur.
