Le cahier des charges décrit onboarding, catalogue, paiement et back-office, mais personne ne sait qui validera une offre, débloquera un reversement ou répondra le samedi. Le prestataire livre les écrans demandés. À l’ouverture, les décisions arrivent dans une boîte partagée et chaque équipe invente son propre processus.
Le symptôme apparaît bien avant la panne : statuts sans owner, opérations manuelles non chiffrées, partenaires non engagés, files sans SLA et données dont aucune équipe ne garantit la qualité. Le projet paraît fonctionnel en recette alors que le modèle d’exploitation reste absent.
Le vrai enjeu d’une marketplace opérateur consiste à concevoir l’organisation qui tiendra la promesse au quotidien. Contre-intuitivement, préciser le run avant l’outil ne bride pas le produit : cela révèle les automatisations utiles et les décisions qui doivent rester humaines.
Vous allez comprendre comment traduire la promesse en processus, rôles, capacités, données, partenaires et indicateurs. Cet operating model devient une entrée du cahier des charges. Chaque fonctionnalité possède un owner métier, un responsable d’exécution et un chemin d’exception avant le développement.
Partir de la promesse opérateur
Décrire le service réellement vendu
La plateforme promet-elle une mise en relation, une transaction sécurisée, un assortiment qualifié, une livraison ou une prestation terminée ? Chaque promesse entraîne des contrôles et responsabilités différents. L’équipe écrit ce que l’acheteur et le vendeur peuvent attendre, ainsi que les limites visibles.
Le modèle distingue plateforme, vendeur et partenaire. Une phrase marketing comme « livraison garantie » devient source de délai, suivi, recours et compensation. Si l’opérateur ne maîtrise pas ces éléments, la promesse est réduite ou le contrat avec le partenaire renforcé.
Borner catégories, zones et horaires
Le service dépend du périmètre : une catégorie réglementée, un produit fragile ou une mission urgente exige des compétences spécifiques. Le lancement précise volumes, pays, plages de support et modes de livraison. L’operating model ne suppose pas que chaque extension utilisera la même capacité.
Les limites deviennent des règles produit et non des consignes orales. Un service indisponible hors horaires ne s’affiche pas comme immédiat. Une zone non couverte reste fermée. Cette cohérence protège support et conversion en évitant une promesse que le run ne peut pas tenir.
Cartographier les processus de bout en bout
Suivre les objets et leurs états
Vendeur, offre, commande, paiement, livraison, mission, litige et versement sont cartographiés depuis leur création jusqu’à leur fermeture. Chaque transition nomme déclencheur, décision, preuve et effet. Le processus inclut les étapes réalisées hors de la plateforme.
La cartographie évite les boîtes « traitement manuel ». Elle décrit file, rôle, outil, délai et résultat. Les entrées inconnues, les délais dépassés et les corrections sont visibles. Le produit peut alors décider quelles étapes automatiser et lesquelles nécessitent une expertise.
Ajouter les exceptions avant le nominal
Pour chaque parcours, l’équipe provoque donnée manquante, refus, timeout, annulation, retour, contestation et partenaire indisponible. Ces cas révèlent les véritables besoins de back-office et de journalisation. Un diagramme heureux seul sous-estime le travail opérationnel.
Par exemple, un paiement inconnu ne devient ni réussi ni échoué. Il rejoint une file de rapprochement, conserve l’identifiant PSP et bloque les effets irréversibles. Le cahier des charges doit prévoir cet état, son owner et son SLA.
Attribuer décisions et exécution
Pour qui définir le RACI
Produit possède la promesse et le workflow, opérations l’exécution courante, finance le rapprochement, conformité le cadre validé et SI la disponibilité technique. Les partenaires portent les résultats contractualisés. Chaque décision critique reçoit un Accountable unique et un suppléant.
Le RACI s’écrit sur des verbes : activer un vendeur, accepter une pièce, rembourser, geler un versement ou fermer un litige. Une colonne « gérer » ne suffit pas. Les consultations et droits de veto sont bornés par domaine et délai.
Traduire les rôles en droits
Les rôles deviennent permissions, files, validations et notifications dans le back-office. Une décision financière sensible peut demander double contrôle. Une délégation temporaire possède une date de fin. Les équipes ne partagent pas un compte générique pour aller plus vite.
Le système enregistre auteur, rôle, règle, motif et résultat. L’audit vérifie que la personne avait l’autorité au moment du geste. Le cahier des charges inclut ces exigences, pas seulement les écrans de consultation.
Organiser les opérations vendeurs
Couvrir recrutement, activation et autonomie
L’operating model précise qui cible les vendeurs, négocie, vérifie, forme et autorise la première offre. Les documents et données ont une source. Les tâches sont mesurées par temps et taux de reprise, afin de dimensionner l’équipe avant la campagne de recrutement.
Le vendeur accède à un parcours self-service pour les étapes répétables et à un interlocuteur pour les exceptions. L’autonomie se mesure jusqu’à la commande, la facture et le litige, pas à la seule création du compte.
Prévoir surveillance et offboarding
Qualité, stock, réponse, livraison, réclamations et conformité alimentent des contrôles adaptés au risque. Chaque alerte indique owner et action. Une baisse n’entraîne pas automatiquement une sanction globale si la cause appartient au client ou à la plateforme.
La sortie ferme offres, accès, commandes, litiges, factures et soldes selon une séquence. Les données et preuves suivent leur durée. Un vendeur désactivé reste accessible au support pour les dossiers ouverts sans pouvoir créer de nouveaux effets.
Organiser catalogue et offre
Nommer les sources de donnée
Produit canonique, offre vendeur, prix, stock, médias et attributs possèdent chacun une source et un owner. L’import ne transforme pas le fournisseur du fichier en propriétaire de la définition. Les règles de qualité et de fraîcheur sont contractualisées.
Les corrections passent par la source puis se propagent. Une modification directe de l’index peut servir une mesure d’urgence, avec expiration et reprise, mais ne devient pas le processus quotidien. Le back-office affiche source, état et prochaine synchronisation.
Dimensionner modération et enrichissement
Les catégories déterminent attributs obligatoires, contrôles et expertise. Le volume d’offres multiplié par taux de rejet et temps de revue donne une première charge. Les règles automatiques réduisent les cas clairs ; la revue humaine traite l’ambiguïté et les recours.
L’équipe mesure faux positifs, reformulations et offres sans trafic. L’enrichissement répond à une décision de recherche, conformité ou conversion. Il ne consiste pas à compléter tous les champs parce que le PIM les propose.
Orchestrer commandes et paiements
Attribuer chaque état de commande
Acceptation, préparation, expédition, livraison, annulation et retour ont une source et un délai. Le vendeur, le transporteur ou l’opérateur peut produire l’événement selon le modèle. Le système normalise sans écraser l’origine.
Les dossiers en retard rejoignent une file avant la rupture de promesse. Le support voit la prochaine action et la partie responsable. Une correction produit un événement, pas un changement silencieux de statut.
Relier paiement, ledger et finance
Autorisation, capture, remboursement, frais, réserve et versement suivent des commandes idempotentes. Le ledger porte les droits financiers ; le PSP porte les opérations externes et la banque le règlement. Finance rapproche ces sources selon une cadence.
Un résultat inconnu déclenche retry, webhook ou investigation sans double effet. Le runbook précise qui peut reprendre et quel seuil gèle les versements. L’outil doit rendre l’écart visible avant la clôture, pas seulement exporter un fichier après incident.
Structurer support et litiges
Organiser les niveaux de prise en charge
Le premier niveau qualifie identité, objet, motif et urgence avec des actions sûres. Le niveau métier décide selon la politique. Les experts finance, conformité ou SI reçoivent un dossier compact. L’escalade ne recommence pas la collecte à chaque niveau.
Le routage tient compte de langue, catégorie, valeur et risque. Les SLA distinguent accusé, décision et résolution. Une réponse rapide sans owner de résolution ne satisfait pas la promesse de support.
Fermer recours et compensation
Le litige rassemble commande, preuves, échanges, règle et effets financiers. Chaque décision possède un motif compréhensible et un recours. L’opérateur ne demande pas aux parties de renvoyer des pièces déjà disponibles dans le dossier.
Remboursement, avoir, geste commercial et correction vendeur restent distincts. Leur exécution est rapprochée du verdict. Le support ferme lorsque toutes les suites sont terminées, pas après l’envoi d’une réponse au client.
Définir données, outils et intégrations
Choisir le système de travail
Chaque équipe sait où lire, décider et exécuter. Le back-office agrège les faits utiles sans prétendre remplacer ERP, PSP, PIM ou CRM comme sources. Les liens et identifiants de corrélation évitent les recherches par date approximative.
Les tableurs temporaires ont owner, finalité et date de retrait. Une dépendance durable devient une intégration ou une procédure contrôlée. Le cahier des charges chiffre migration et exploitation de ces outils, pas seulement la construction du nouveau front.
Contractualiser les flux
Chaque API, fichier ou webhook décrit schéma, source, fréquence, volumétrie, idempotence, retry, sécurité et monitoring. Les erreurs rejoignent une file avec action. La plateforme ne considère pas une réponse technique comme preuve d’un résultat métier.
Les propriétaires de part et d’autre sont nommés. Un changement de schéma suit préavis et tests. Le mode dégradé protège les commandes ouvertes et limite les nouvelles entrées selon le risque.
Décider ce qui reste internalisé
Arbitrer par différenciation et contrôle
Une capacité stratégique, riche en règles propres ou critique pour la promesse mérite un contrôle fort. Une commodité spécialisée peut être confiée à un partenaire. Le choix compare vitesse, compétence, coût complet, données, dépendance et réversibilité.
Externaliser l’exécution ne transfère pas l’accountability de l’opérateur. Un owner interne suit service, incidents et sortie. Le produit prévoit l’expérience lorsque le partenaire échoue ou demande une action manuelle.
Écrire le contrat de run
Le contrat décrit résultat, horaires, SLA, volumes, preuves, sécurité, sous-traitants, notification et support. Les pénalités seules ne restaurent pas une commande. Les procédures et contacts sont testés sur un incident simulé.
La réversibilité couvre export, mapping, durée d’accès et opérations ouvertes. Un changement de prestataire ne doit pas perdre litiges ou remboursements. Le cahier des charges réserve les adaptateurs et identifiants nécessaires à cette sortie.
Dimensionner capacité et niveaux de service
Transformer volumes en charge
Le modèle relie vendeurs, offres, commandes et taux d’exception aux minutes de traitement. Il ajoute pics, langues, congés, formation et contrôle qualité. La capacité n’est pas calculée depuis le seul volume moyen mensuel.
Les tâches rares mais longues sont visibles. Un nouveau pays peut doubler la charge conformité sans doubler les commandes. Les hypothèses portent une source et sont recalibrées pendant le pilote.
Fixer seuils et modes dégradés
Chaque file possède cible, alerte et plafond. Si le backlog de modération dépasse deux jours ou si les dossiers financiers non rapprochés franchissent un montant convenu, alors l’ouverture se réduit. Le seuil déclenche une décision connue.
Le mode dégradé peut limiter nouvelles offres, masquer une promesse ou suspendre un moyen de paiement. Il conserve les obligations sur les dossiers ouverts. L’équipe l’exécute en recette avant le lancement.
Installer rituels et indicateurs
Séparer run, produit et risque
Le point quotidien traite files et incidents ; la revue hebdomadaire analyse qualité et capacité ; le comité produit arbitre les changements ; les experts revoient les risques selon leur cadence. Un même meeting ne mélange pas statuts et décisions structurantes.
Chaque rituel possède entrées, décisions, participants et sorties. Les actions sont reliées à un owner et une échéance. Une alerte qui ne change aucune décision est supprimée ou reformulée.
Piloter la chaîne complète
Le tableau suit activation, offres achetables, commandes, promesse, paiements, litiges, reversements et charge. Les métriques se ventilent par catégorie et vendeur. Une moyenne stable ne masque pas une file vieillissante.
Le coût de service rejoint marge et valeur. Les corrections manuelles sont comptées. Le comité peut décider automatiser, former, réduire le périmètre ou modifier la promesse selon la cause dominante.
Éviter les erreurs fréquentes
Dessiner seulement l’organisation cible
Un organigramme ne décrit ni décision ni flux. L’operating model doit partir des dossiers et états. Les rôles deviennent utiles lorsqu’ils possèdent entrées, action, preuve et SLA dans un outil réel.
Autre erreur : supposer que l’automatisation supprimera les exceptions. Les cas inconnus restent. Leur file, leur owner et leur seuil doivent exister avant que l’algorithme traite le nominal.
Repousser le run après le build
Cette séquence produit des écrans impossibles à exploiter et des coûts non budgétés. Les opérateurs participent au cadrage, exécutent les prototypes et valident les traces. Le cahier des charges reflète leurs décisions, pas une vision théorique.
Enfin, confier tous les problèmes au support masque les owners. Le support qualifie et communique ; produit, finance, conformité ou SI décident selon leur domaine. Les escalades et permissions empêchent la boîte partagée de devenir l’organisation.
Plan d’action avant le cahier des charges
Cartographier promesse, processus et responsabilités
L’équipe choisit une catégorie pilote et vingt dossiers représentatifs. Elle écrit promesse, limites et cycle complet du vendeur au reversement. Chaque transition décrit entrées, sorties, responsabilités, système, délai et preuve. Le RACI nomme owner et suppléant. Les tâches manuelles sont chronométrées et les dépendances partenaires identifiées. Dix scénarios couvrent refus, timeout, annulation, litige, correction de donnée et clôture financière.
La mise en œuvre traduit cette carte en exigences : états, permissions, files, idempotence, journalisation, monitoring et rollback. Les équipes exécutent un prototype de back-office. Finance rapproche un dossier, support ferme un litige et opérations reprend une offre. Les écarts deviennent critères d’acceptation. Le budget inclut licences, partenaires, capacité, formation et mode dégradé, avec des seuils avant chaque extension.
Tester le run pendant le pilote
Le canary limite vendeurs, catalogue et volume pendant un cycle complet. Le tableau suit charge, SLA, exceptions, corrections directes et coût. Si plus de 5 % des dossiers n’ont pas d’owner ou si une file critique dépasse deux fois son plafond, alors les nouvelles entrées sont réduites. Les commandes ouvertes restent servies selon leur contrat.
À la revue, l’équipe ajuste processus, outils ou promesse avant d’élargir. Une étape répétable devient candidate à l’automatisation ; une décision rare reste humaine et outillée. Le cahier des charges final s’appuie sur les faits du pilote. L’operating model rejoint ensuite onboarding, contrats partenaires et rituels, afin de rester vivant après la livraison.
- À faire d’abord : écrire promesse, limites et cycle complet.
- À tester ensuite : exceptions, permissions, charge et mode dégradé.
- À différer : l’automatisation avant un processus stable.
- À refuser : toute fonctionnalité sans owner, preuve et coût de run.
Guides complémentaires pour l’opérateur
Borner le premier périmètre
Le MVP marketplace à livrer avant l’ouverture aide à limiter les flux tout en couvrant le cycle réel.
La méthode pour ouvrir une première catégorie fournit un canary où mesurer charge, qualité et autonomie.
Le périmètre retenu doit néanmoins traverser une commande jusqu’à sa clôture financière, y compris une modification, une annulation et une demande support. Une catégorie trop simple peut valider l’interface sans éprouver les responsabilités. L’équipe choisit donc quelques dossiers représentatifs, attribue chaque étape et mesure le temps réellement consommé. Si une exception n’a ni owner ni condition de sortie, elle reste hors du go, même lorsque le parcours nominal fonctionne.
Outiller les équipes
Les écrans du back-office opérateur donnent les files, preuves et actions nécessaires au run.
Le cadre de refonte et migration marketplace complète la reprise des outils et processus existants.
Avant la décision, le responsable d’exploitation relie chaque écran à une action permise, une preuve attendue et un délai. Il vérifie aussi les dépendances avec CRM, PIM, OMS, PSP et support. Cette matrice empêche de financer un bouton qui déplace seulement le travail vers une feuille. Elle sert ensuite de base à la recette, au dimensionnement et au runbook du mode dégradé.
Conclusion : concevoir le run avant l’outil
L’operating model marketplace transforme la promesse en processus, décisions, rôles, outils et niveaux de service. Il révèle ce que la plateforme doit automatiser et ce que les équipes doivent opérer.
Vendeurs, catalogue, commandes, finance et support sont suivis jusqu’à leur état final. Les exceptions et partenaires disposent d’un contrat avant le lancement.
Capacité, coût et modes dégradés rejoignent le cahier des charges. Le pilote vérifie le modèle sur des dossiers réels et corrige la promesse ou l’organisation avant l’extension.
Pour cartographier le run, cadrer les outils et sécuriser la première catégorie, Dawap peut vous accompagner dans votre projet de marketplace opérateur, de l’operating model à l’exploitation quotidienne.
