Le produit annonce qu’une offre est « active », le support la voit « publiable » et le vendeur croit qu’elle est déjà visible. La finance clôt un litige parce que le remboursement est lancé, tandis que l’acheteur attend encore les fonds. Ces mots identiques cachent des états différents ; le problème finit en règle contradictoire, reprise manuelle et perte de confiance.
Le symptôme apparaît avant la panne : deux dashboards comptent un autre nombre de commandes, une équipe change le sens d’un statut pendant une réunion, ou une API expose « completed » sans que personne sache quel engagement est réellement terminé. Ajouter des colonnes ne résout pas cette ambiguïté.
Un dictionnaire opérateur utile ne collectionne pas des définitions littéraires. Il relie chaque terme à un objet, une portée, des transitions autorisées, une décision, une preuve et un owner. La méthode permet de comprendre quoi afficher, de décider ce que les flux acceptent et de corriger ce que le run doit reprendre.
Dawap construit ce langage avec les équipes qui conçoivent ou reprennent une marketplace opérateur. La page service porte la transformation globale ; la méthode ci-dessous sécurise la sémantique qui relie offre, commande, litige et paiement.
Repérer le coût des mots ambigus
Une ambiguïté devient coûteuse lorsqu’elle commande une action. « Commande validée » peut déclencher réservation, facture, notification ou versement selon l’équipe. Si ces actions ne partent pas du même fait, le support doit ensuite recoller la chronologie et la finance justifier des montants impossibles à reproduire.
Chercher les divergences de décision
L’équipe compare les endroits où un même terme apparaît : interface, API, événement, procédure, contrat vendeur et KPI. Une divergence de libellé reste bénigne ; une divergence de conséquence devient prioritaire. Le coût caché se mesure en dossiers rouvertes, compensations, délais et arbitrages refaits.
Contrairement à ce que l’on suppose, imposer un mot unique ne suffit pas. Deux services peuvent écrire « livré » tout en parlant l’un du colis et l’autre de la commande complète. Le dictionnaire fixe l’objet et la preuve avant de normaliser le libellé.
Savoir quand le dictionnaire devient nécessaire
Le besoin devient urgent dès que vendeurs, acheteurs, support, finance et produit interprètent les mêmes objets, ou lorsque plusieurs domaines émettent des événements sur une même transaction. Une petite plateforme mono-vendeur peut commencer léger ; une marketplace avec split de commande et paiement ne peut pas laisser le sens implicite.
Qualifier les équipes et décisions concernées
Le produit a besoin d’états affichables, la technique de contrats stables, les opérations de gestes autorisés et la finance de faits opposables. Le dictionnaire sert ces quatre usages sans leur donner quatre réalités. Chaque entrée indique les vues qui peuvent simplifier le terme sans modifier son sens.
Un signal faible est une phrase comme « chez nous, validé veut dire… ». Un second apparaît lorsque l’équipe ajoute un export pour corriger un KPI. Dès deux interprétations actives sur une décision critique, le terme entre dans le chantier.
Séparer objet, état, événement et décision
L’objet possède une identité durable : offre, commande, ligne, paiement ou litige. L’état résume sa situation actuelle. L’événement décrit un fait daté. La décision autorise une transition ou une action. Les quatre notions ne doivent jamais partager un champ générique « statut ».
Écrire une définition testable
« Commande acceptée » signifie par exemple que les contrôles de paiement et de capacité sont réussis, que les lignes ont un vendeur responsable et qu’une preuve horodatée existe. La phrase dit quand le terme devient vrai, pas seulement ce qu’il évoque.
Chaque entrée contient terme canonique, synonymes tolérés, termes interdits, objet, portée, préconditions, événement déclencheur, preuve, effets autorisés et exemples négatifs. Un lecteur doit pouvoir classer un cas sans demander l’intention de son auteur.
Définir précisément une offre
Le produit décrit ce qui peut être vendu ; l’offre relie ce produit à un vendeur, un prix, une disponibilité, une promesse et un canal. Une fiche complète n’est pas nécessairement une offre éligible, et une offre éligible n’est pas encore publiée.
Distinguer les portes d’exposition
Les états utiles peuvent être brouillon, instruite, éligible, publiable, publiée, suspendue et retirée. Chaque passage porte une preuve : conformité, prix, stock, acceptation du canal ou lecture front. « Active » disparaît s’il recouvre plusieurs de ces portes.
Une suspension conserve identité, historique et commandes antérieures. Un retrait empêche une nouvelle vente ; il n’efface pas la responsabilité du vendeur sur le passé. Cette nuance protège support, avis, retours et obligations contractuelles.
Définir la commande et ses engagements
Le panier porte une intention modifiable. La commande fige un engagement acheteur et une proposition de transaction. Les sous-commandes distribuent ensuite les obligations par vendeur. Confondre ces niveaux produit des annulations globales pour un défaut local.
Nommer la portée de chaque statut
« Expédiée » s’applique à un colis, une ligne vendeur, une sous-commande ou la totalité. Le terme canonique devient « sous-commande entièrement expédiée » lorsque toutes ses lignes possèdent une preuve transport. L’interface peut raccourcir, mais l’événement et le KPI gardent la portée.
L’acceptation, la préparation, l’expédition, la livraison, l’annulation et le retour restent des transitions différentes. Une compensation financière ne change pas automatiquement l’état logistique. Les règles disent explicitement quel événement peut entraîner quelle décision.
Définir litige, réclamation et incident
Une réclamation exprime une insatisfaction ; un litige ouvre une décision opposable entre parties ; un incident affecte le fonctionnement de la plateforme. Un retard peut créer les trois objets, mais chacun possède owner, délai et sortie distincts.
Éviter qu’une clôture administrative masque le dommage
Un litige est résolu lorsque la décision est prise, notifiée et exécutable. Il est exécuté lorsque remboursement, remplacement ou refus motivé possède une preuve. Il est clos lorsque le contrôle confirme cette exécution et que le délai de contestation applicable est connu.
Le support peut fermer une conversation sans clore le litige. La finance peut émettre un remboursement sans prouver sa réception. Le dictionnaire empêche ces raccourcis de déclencher un KPI de succès prématuré.
Définir paiement, capture et reversement
Autorisation, capture, encaissement, cantonnement, remboursement et reversement ne sont pas des synonymes. Chacun porte un mouvement, une partie, une devise, une date effective et un statut fournisseur. La commande ne doit pas déduire une réalité financière d’un simple booléen « paid ».
Relier l’argent au ledger plutôt qu’au libellé
Le ledger conserve les écritures et leurs compensations. Le dictionnaire précise quels événements créent une créance vendeur, une dette plateforme ou une restitution acheteur. Une annulation logistique peut déclencher un remboursement, mais ne remplace jamais l’écriture qui le prouve.
« Payé vendeur » exige l’ordre de reversement, son acceptation et la date de valeur selon le contrat. Si le PSP indique seulement « submitted », l’état reste en cours. Cette précision évite de promettre des fonds non encore disponibles.
Rendre les relations explicites
Les objets forment un graphe : une commande possède des sous-commandes, lignes, paiements, expéditions et dossiers ; un litige concerne une ou plusieurs lignes et produit éventuellement des écritures. Le dictionnaire nomme cardinalité et sens de chaque relation.
Refuser les rattachements implicites
Un dossier support ne devient pas un litige parce qu’il cite une commande. Il contient une référence qualifiée et une raison. Un paiement groupé peut couvrir plusieurs commandes ; l’allocation doit être calculée et prouvée plutôt que déduite de l’ordre d’arrivée.
Les identifiants externes restent associés à leur source. L’identifiant PSP, vendeur ou transporteur ne remplace pas l’identité interne. La recherche accepte plusieurs clés, mais retourne toujours l’objet canonique et la relation qui justifie le rapprochement.
Attacher une preuve à chaque terme
Une définition sans preuve reste une convention orale. L’entrée indique événement, champ, document ou contrôle qui rend l’état vrai. La preuve est reproductible par une personne extérieure au projet et reste consultable pendant la durée nécessaire au run.
Distinguer preuve, indice et projection
Un numéro de suivi est un indice d’expédition ; le scan transport constitue une preuve plus forte. Un calcul de reversement est une projection ; l’écriture PSP prouve l’exécution. La vue opérateur peut montrer les deux à condition d’indiquer leur nature.
Pour chaque terme critique, l’équipe prépare au moins un cas positif, un cas négatif et une frontière. Si deux lecteurs classent différemment plus de 5 % des vingt dossiers tests, la définition est reprise avant automatisation.
Attribuer owner et droit de modification
Chaque domaine possède ses objets et accepte ou refuse les évolutions sémantiques. Catalogue gouverne l’offre, order management la commande, opérations le litige et finance les mouvements. Un comité arbitre seulement les frontières entre domaines.
Séparer proposition, validation et déploiement
Tout collaborateur peut signaler une ambiguïté. L’owner propose la définition, les consommateurs évaluent l’impact et l’autorité métier valide. La technique déploie ensuite schémas, migrations et compatibilité. Aucun changement de code ne modifie seul le sens métier.
Un veto cite une obligation, un invariant ou un cas réel. Une préférence de vocabulaire ne bloque pas une version. Le registre conserve décideur, date, alternatives refusées et condition de réexamen.
Versionner sans casser le passé
Modifier une définition ne réécrit pas les événements historiques. Une version possède date d’effet, objets concernés et règle de traduction. Les dashboards indiquent s’ils relisent le passé avec la convention d’époque ou une vue analytique harmonisée.
Préserver une fenêtre de compatibilité
Un producteur émet l’ancienne et la nouvelle forme pendant une fenêtre bornée, ou un adaptateur traduit sans perdre l’original. Les consommateurs déclarent leur version comprise. La bascule ne ferme qu’après preuve qu’aucun flux actif n’interprète encore l’ancien sens.
Une correction urgente peut être ajoutée comme règle plus spécifique, mais elle porte une échéance. Sans revue, les exceptions deviennent le vocabulaire réel tandis que le dictionnaire officiel cesse d’expliquer la plateforme.
Brancher le dictionnaire aux produits et flux
Le dictionnaire alimente noms de champs, documentation API, événements, labels d’interface, runbooks, tests et KPI. Il ne reste pas dans un document séparé. Une entrée référence les artefacts qui l’implémentent et les contrôles qui détectent leur divergence.
Automatiser la conformité sans figer le métier
Les schémas vérifient valeurs autorisées, les tests contrôlent transitions et les dashboards signalent états impossibles. L’owner garde pourtant le droit de faire évoluer le sens par une décision versionnée. Le code exécute le contrat ; il ne devient pas sa seule documentation.
L’entrée d’une transition contient objet, version et preuve ; sa sortie porte état, événement et traçabilité. L’owner vérifie ces responsabilités dans le runbook, puis fixe le seuil au-delà duquel le flux passe en repli. Si une dépendance ne sait pas conserver l’original, alors l’intégration reste hors extension.
- D’abord : corriger les termes qui commandent argent, promesse ou droit d’action.
- Ensuite : aligner événements, API, interfaces et mesures sur la version validée.
- À différer : les synonymes éditoriaux sans conséquence opérationnelle.
- À refuser : un nouveau statut sans transition, preuve ni owner.
Un contrôle de build peut empêcher la réintroduction d’une valeur interdite dans un schéma. Une revue mensuelle vérifie plutôt les interprétations humaines : procédures parallèles, exports, gestes support et commentaires qui signalent une définition insuffisante.
Rejouer un cas opérateur complet
Cas concret : une commande contient deux vendeurs. Le premier expédie, le second annule après capture. L’acheteur ouvre une réclamation, le support crée un litige sur une ligne et la finance rembourse uniquement la part annulée.
Faire parler chaque domaine sans fusionner les objets
La commande globale reste partiellement exécutée ; une sous-commande devient expédiée et l’autre annulée. Le litige est décidé en faveur de l’acheteur, puis exécuté après preuve de remboursement. Le paiement initial reste capturé et reçoit une écriture compensatoire partielle.
Par exemple, le support peut afficher « remboursement envoyé » dès l’acceptation PSP, mais le KPI financier attend l’écriture rapprochée. Les deux vues dérivent du même fait avec une précision adaptée. Aucun service ne modifie le statut global pour rendre son écran plus simple.
Le test réussit si une personne retrouve, depuis le ticket, chaque objet, événement, décision et preuve en moins de cinq minutes. Sinon, le dictionnaire ou les relations restent insuffisants pour le run.
Contrôler les ambiguïtés résiduelles
L’équipe suit termes contestés, états corrigés manuellement, événements sans définition, écarts entre dashboards et temps de qualification support. Elle sépare une mauvaise application d’une définition réellement ambiguë.
Utiliser les désaccords comme signal faible
Lorsque deux équipes rouvrent le même arbitrage, le problème n’est pas forcément la formation. Si la preuve ou la portée manque, la définition doit changer. Si le contrat est clair mais non appliqué, l’artefact ou le contrôle devient prioritaire.
Le seuil de 95 % d’accord sur les cas tests autorise le pilote ; les 5 % restants sont documentés. Zéro ambiguïté absolue est irréaliste, mais aucune exception portant argent, droit vendeur ou promesse acheteur ne reste implicite.
Plan d’action en trente jours
Les entrées sont glossaires existants, schémas, écrans, procédures, contrats, incidents et questions support. Les sorties sont un dictionnaire versionné, une carte des objets, des cas tests, des owners, une matrice d’impact et un backlog d’alignement.
Passer des mots aux décisions exécutables
- Jours 1 à 5 : extraire cinquante termes et relever leurs définitions concurrentes.
- Jours 6 à 10 : séparer objets, états, événements, décisions et preuves.
- Jours 11 à 15 : arbitrer offre, commande, litige et paiement avec leurs owners.
- Jours 16 à 20 : rejouer vingt dossiers, mesurer l’accord et corriger les frontières.
- Jours 21 à 25 : aligner une API, un écran, un runbook et un dashboard pilotes.
- Jours 26 à 30 : publier la version, geler les termes interdits et décider l’extension.
La première semaine priorise les mots qui déclenchent paiement, visibilité, annulation ou suspension. Les synonymes sans effet sont conservés comme alias. Chaque définition reçoit un cas contraire afin d’éviter une phrase assez large pour tout accepter.
Durant le pilote, produit et support classent séparément les mêmes vingt dossiers. Un désaccord ouvre une correction du terme ou de l’interface ; il n’est pas résolu par une explication orale. Finance vérifie ensuite que les états retenus rejoignent les écritures.
La publication contient version, date d’effet, changements, impacts et responsables de migration. Les consommateurs accusent lecture. Une équipe qui ne peut pas migrer obtient une compatibilité bornée, jamais une dérogation permanente cachée.
Le verdict final exige au moins 95 % d’accord, zéro état critique sans preuve et zéro terme interdit dans les artefacts pilotes. L’extension se fait domaine par domaine. Si ces portes échouent, l’équipe corrige le langage avant d’automatiser davantage.
Éviter les erreurs fréquentes de gouvernance
Copier les noms de base de données confond implémentation et métier. Définir par synonyme déplace l’ambiguïté. Réunir vingt validateurs dilue l’owner. Réécrire le passé détruit l’explication des transactions.
Garder le dictionnaire assez précis pour décider
Ajouter tous les mots crée un catalogue inutilisable. Oublier les cas négatifs rend chaque définition permissive. Publier sans migration fabrique deux langues. Mesurer le nombre d’entrées récompense le volume au lieu de l’accord.
Le risque inverse est une précision juridique partout. Le niveau de détail dépend de la conséquence. Un libellé de filtre tolère un alias ; une transition qui libère un reversement exige objet, seuil, preuve et responsabilité sans équivoque.
En revanche, une ambiguïté qui ne commande aucune action peut attendre. Elle est consignée puis traitée après les transitions critiques, plutôt que d’allonger le chantier initial et de retarder la mise sous contrôle de l’argent ou de la promesse acheteur.
- Conserver : les termes compris et appliqués de façon reproductible.
- Réécrire : ceux qui déclenchent des décisions différentes selon l’équipe.
- Retirer : les états sans preuve, transition ou usage métier réel.
Relier événements, dossiers et finance
La taxonomie d’événements marketplace organise les faits observables. Le dictionnaire décide d’abord le sens des objets et transitions que ces événements transportent.
Compléter les méthodes sans reprendre leur intention
Le case management opérateur réunit les objets dans un dossier exploitable. Le ledger marketplace en double écriture prouve les mouvements financiers.
Le langage commun se situe en amont : il permet aux événements, dossiers et écritures de se référer aux mêmes décisions sans fusionner leurs responsabilités. Cette frontière protège l’intention de chaque ressource et renforce la landing de création marketplace.
Quand les équipes doivent conserver ces définitions, décisions et preuves dans le run, Ciama Marketplace peut soutenir leur suivi. Le produit n’invente pas le langage : il rend sa version et ses écarts visibles aux owners.
Conclusion : un langage qui décide
Une marketplace ne devient pas cohérente parce que toutes ses équipes emploient les mêmes mots. Elle le devient lorsque ces mots désignent les mêmes objets, preuves et droits d’action.
Offre, commande, litige et paiement forment le noyau du dictionnaire. Portée, événement, transition, owner et version les rendent opposables aux interfaces, aux flux et au run.
Ce langage réduit les débats rejoués, les clôtures prématurées et les KPI incompatibles. Il donne aussi une base stable aux automatisations, sans figer les évolutions du métier.
Dawap vous accompagne pour construire ce socle dans votre projet de création ou reprise de marketplace opérateur, puis le traduire en produits, contrats de données et procédures réellement exécutables.
