Un vendeur demande le déblocage d’un reversement. Les opérations veulent préserver la relation, la finance refuse un solde non rapproché, le produit évoque une règle de plateforme et le SI attend une décision. Chacun participe ; personne ne sait qui peut autoriser l’exception ni qui devra expliquer ses conséquences.
Le symptôme se répète dans les catégories ouvertes sans capacité support, les remboursements corrigés à la main, les pièces vendeur acceptées par email et les changements de statut sans propriétaire. Les réunions grossissent tandis que les décisions ralentissent. Un tableau RACI existe parfois, mais il décrit des projets génériques plutôt que les gestes réels.
Le RACI d’une marketplace opérateur doit attribuer chaque décision critique à un responsable unique, des contributeurs identifiés et des destinataires d’information. Contre-intuitivement, inviter davantage de métiers ne réduit pas le risque : une consultation illimitée peut masquer l’absence d’autorité.
La démarche suivante part des objets et événements de la plateforme : offre, vendeur, commande, paiement, litige et règle. Elle distingue décision nominale, exception et incident, puis relie chaque rôle à un écran, une preuve et un délai. Le RACI devient un contrat d’exploitation testable, pas une présentation d’organisation.
Partir des décisions plutôt que des équipes
Inventorier les gestes qui changent un état
L’équipe recense les décisions qui modifient droits, argent, visibilité ou promesse : activer un vendeur, publier une offre, annuler une commande, rembourser, geler un versement, fermer un litige, changer un seuil et couper une intégration. Chaque ligne désigne objet, déclencheur, résultat et conséquence.
Les verbes vagues comme « gérer le catalogue » sont décomposés. Valider une catégorie, modérer un attribut et corriger une donnée ne portent ni le même risque ni le même owner. L’inventaire part des journaux, tickets et procédures réelles afin d’inclure les gestes que l’organigramme ne mentionne pas.
Séparer nominal, exception et urgence
Une décision automatique conforme à la politique suit un chemin nominal. Un cas hors politique exige une exception datée. Une menace immédiate peut autoriser une mesure conservatoire avant l’arbitrage. Ces trois modes reçoivent des rôles, preuves et délais différents au lieu d’utiliser une seule ligne RACI.
Par exemple, le gel temporaire d’un compte compromis peut appartenir à l’astreinte sécurité, tandis que sa fermeture définitive exige conformité et opérations. Le journal conserve l’auteur du geste conservatoire, sa durée maximale et le décideur attendu avant expiration.
Donner un sens strict aux rôles RACI
Nommer un seul responsable de résultat
Le rôle Accountable porte la décision finale et ses effets. Il doit avoir autorité, compétence et accès à la preuve. Deux responsables sur la même ligne recréent un comité informel ; aucun responsable transforme l’exception en attente. Le suppléant est nommé séparément avec ses conditions d’activation.
Responsible exécute la décision selon le workflow. Dans un petit périmètre, la même personne peut décider et exécuter ; dans un geste sensible, séparation des tâches et double validation s’imposent. Le modèle documente cette contrainte sans multiplier artificiellement les rôles.
Pour qui borner consultation et information
Consulted fournit une expertise nécessaire avant décision : finance sur l’impact comptable, conformité sur la règle applicable ou SI sur la faisabilité. La consultation possède une question et un délai. À l’échéance, la procédure indique si la décision attend, utilise un avis par défaut ou remonte d’un niveau.
Informed reçoit résultat, motif et prochaines actions sans disposer d’un veto implicite. Une notification ciblée remplace les copies générales. Le vendeur, le support ou la direction voit seulement l’information utile à son rôle, ce qui réduit le bruit et protège les éléments sensibles.
Attribuer les choix du produit
Posséder la promesse et les règles de parcours
Le produit porte la promesse utilisateur, le comportement nominal et la cohérence des parcours. Il décide comment une règle validée apparaît dans l’interface, quels états existent et quelle action reste possible. Il ne décide pas seul du fond juridique ou de la reconnaissance comptable.
Une modification de workflow décrit critères d’acceptation, populations affectées et métriques. Le product manager consulte opérations sur la capacité de traitement, SI sur les dépendances, finance ou conformité selon l’effet. La décision est versionnée avec une date de mise en vigueur.
Arbitrer valeur et dette de plateforme
Prioriser une fonctionnalité, réparer un parcours ou retirer une option relève d’un arbitrage produit fondé sur valeur, risque et coût d’exploitation. Le responsable ne transforme pas chaque incident en développement. Il vérifie si la cause appartient à la règle, aux données, à une dépendance ou à la formation.
Le backlog conserve la décision et la capacité allouée. Une exception répétée franchissant un plafond documenté devient un problème produit. À l’inverse, une demande locale rare peut rester dans une procédure bornée si son automatisation coûterait davantage que son traitement contrôlé.
Attribuer les décisions opérationnelles
Posséder l’exécution de la politique
Les opérations prennent les décisions prévues par la politique sur vendeurs, offres, commandes et litiges. Elles qualifient les faits, choisissent un motif autorisé et déclenchent l’action correspondante. Elles ne modifient pas silencieusement le seuil ou la règle pour fermer un dossier plus vite.
Le back-office présente l’état, les preuves, les actions disponibles et l’escalade. Une décision sensible exige une justification structurée. Le responsable opérationnel surveille charge, délai, réouvertures et décisions renversées pour détecter un contrat incompris ou une capacité insuffisante.
Assumer capacité et niveau de service
Avant l’ouverture d’une catégorie, opérations confirme volumes, horaires, compétences, langues et partenaires. Cette signature ne garantit pas l’absence d’incident ; elle atteste que les files, propriétaires et seuils de charge existent. Le sponsor ne peut pas imposer le volume sans accepter le risque documenté.
Lorsque le backlog dépasse le délai convenu, le responsable choisit parmi capacité temporaire, restriction du périmètre ou priorisation par impact. Le SI n’est pas responsable d’un retard de décision métier simplement parce que le dossier passe par un outil technique.
Protéger les décisions financières
Distinguer action commerciale et écriture
Un geste commercial, un remboursement PSP, un avoir, une compensation vendeur et une écriture ledger sont liés mais distincts. Le commerce ou les opérations peut proposer l’issue client ; finance valide son traitement, son plafond et son rapprochement. Le système exécute chaque effet avec un identifiant commun.
La décision indique montant, devise, bénéficiaire, motif et source budgétaire. Un dépassement suit une délégation explicite. Le rôle finance ne consiste pas à cliquer sur toutes les opérations nominales, mais à définir contrôles, limites et revue des exceptions.
Fermer les écarts avant de signer
Finance possède balance, rapprochement bancaire et règles de clôture. Les équipes paiement ou SI diagnostiquent les événements techniques ; elles ne déclarent pas un solde correct sans accord de la source financière. Chaque écart reçoit montant, ancienneté, hypothèse et prochaine action.
Un incident peut exiger le gel des reversements, décidé selon un seuil convenu entre finance, risque et opérations. La reprise attend une balance et un échantillon réconcilié. Le RACI précise qui autorise le redémarrage et qui informe les vendeurs affectés.
Associer conformité et sécurité
Faire valider le cadre, pas chaque clic
Conformité définit ou valide les obligations, critères de preuve, durées et recours avec les conseils adaptés. Les opérations appliquent ensuite la politique. Une escalade intervient lorsque le cas sort du cadre, lorsque la règle change ou lorsque plusieurs obligations se contredisent.
Cette répartition évite deux extrêmes : conformité absorbée par les cas courants, ou support qui interprète seul une règle sensible. La version applicable accompagne la décision. Les avis ponctuels importants rejoignent le registre au lieu de rester dans une conversation privée.
Coordonner incident et protection des données
Sécurité dirige la réponse technique à une compromission ; protection des données et juridique évaluent les obligations associées ; opérations contient les effets vendeurs et clients. Le responsable d’incident orchestre la chronologie sans s’approprier toutes les décisions métiers ou légales.
Les accès d’urgence sont limités, tracés et révoqués après usage. Le RACI inclut notification interne, conservation des preuves et validation du retour au nominal. Un exercice vérifie que chaque acteur dispose réellement de ses contacts, écrans et moyens d’action.
Borner les responsabilités du SI
Posséder disponibilité et intégrité technique
Le SI et les équipes d’ingénierie garantissent contrats d’interface, déploiements, sauvegardes, observabilité, reprise et sécurité technique selon les niveaux convenus. Ils qualifient panne, latence, donnée corrompue et résultat inconnu. Ils ne choisissent pas le remboursement ou l’exclusion vendeur à la place du métier.
Chaque service possède owner technique, SLO, dépendances et procédure. L’incident manager restaure la capacité ou un mode dégradé. Le propriétaire métier décide si ce mode permet de continuer à vendre, payer ou publier selon les risques.
Séparer donnée source et outil
Une équipe qui maintient le PIM n’est pas automatiquement propriétaire de la définition d’une catégorie. Le métier possède sens et qualité attendue ; le SI possède stockage, propagation et contrôles techniques. La même distinction s’applique au ledger, au CRM et aux règles de modération.
Les demandes de correction indiquent source, valeur attendue, décideur et impact. Le SI produit une migration ou un événement réversible ; il ne remplace pas une valeur en base sur la seule capture d’écran d’un ticket. La trace relie décision métier et exécution technique.
Arbitrer les décisions transverses
Nommer le décideur par type d’effet
Une décision traverse souvent plusieurs équipes. L’effet principal aide à nommer l’Accountable : promesse pour produit, exécution pour opérations, reconnaissance pour finance, obligation pour conformité, disponibilité pour SI. Les autres deviennent consultés sur leurs impacts, sans créer cinq co-décideurs.
Si deux effets sont indissociables, une règle d’arbitrage supérieure désigne le sponsor ou un comité limité. Le dossier présente options, recommandation, coûts, risques et réversibilité. Le comité tranche l’exception ; il ne remplace pas les propriétaires des décisions courantes.
Définir les droits de veto
Un veto existe seulement sur un domaine et un risque explicitement définis : conformité sur une interdiction validée, sécurité sur une exposition critique ou finance sur une balance non expliquée. Il exige un motif, une condition de levée et un délai de réexamen.
Le veto ne devient pas un « non » sans suite. Le propriétaire propose réduction de périmètre, contrôle compensatoire ou report. La décision finale conserve l’objection et la manière dont elle est traitée. Cette trace protège les métiers sans paralyser chaque évolution.
Traiter incident et exception
Prévoir l’escalade avant le premier cas
Chaque décision possède conditions de sortie du nominal : montant supérieur au plafond, preuve contradictoire, pays inconnu, règle absente ou risque immédiat. L’escalade transmet objet, faits, version, options et délai. Elle n’envoie pas seulement « urgent » à un groupe indifférencié.
Le destinataire accepte, refuse ou réoriente avec un motif. Si aucun propriétaire n’existe, la catégorie ne devrait pas être ouverte. Le taux de réorientation indique un RACI mal défini ou un formulaire incapable de qualifier la décision.
Gérer la mesure conservatoire
Une urgence autorise parfois gel, suspension ou limitation temporaire. La mesure possède un périmètre minimal, une expiration et une décision définitive attendue. Si le délai est dépassé, une alerte remonte au niveau supérieur plutôt que de laisser le provisoire devenir permanent.
Le retour au nominal exige les contrôles convenus. Par exemple, après une anomalie de reversement supérieure à 5 000 euros, la reprise peut demander balance nulle sur deux cycles et validation finance. Le seuil est adapté au modèle, documenté et revu ; il n’est pas inventé pendant l’incident.
Relier le RACI aux preuves
Inscrire les rôles dans les workflows
Le RACI devient permissions, files, validations et notifications. Le back-office sait qui peut décider, exécuter, consulter et être informé pour chaque état. Les délégations ont une date de fin. Une modification de rôle déclenche une revue des droits techniques associés.
Le workflow enregistre entrée, version de politique, décision, auteur, consultation, exécution et résultat. L’absence d’avis à l’échéance reste visible. La preuve ne se limite pas au nom d’un utilisateur ; elle démontre que la personne possédait le rôle au moment du geste.
Tenir un registre de décisions
Les arbitrages non récurrents rejoignent un registre avec contexte, options, décision, responsable, date d’effet, hypothèses et condition de révision. Les lignes RACI renvoient à ce registre lorsqu’une règle nouvelle est créée. Le prochain cas applique une politique plutôt que le souvenir d’une réunion.
Une décision expirée ouvre une revue. L’équipe mesure si hypothèses et impacts se sont confirmés. Les corrections ne réécrivent pas l’historique : elles ajoutent une nouvelle version. Cette chronologie explique pourquoi deux dossiers similaires ont reçu des traitements différents à des dates différentes.
Mesurer la qualité de décision
Suivre délais, renversements et files
Le tableau suit décisions par type, temps avant prise en charge, temps de consultation, escalades, réorientations, expirations et renversements. Il distingue attente de preuve, manque de capacité et absence d’autorité. La moyenne seule ne suffit pas ; les dossiers anciens révèlent les responsabilités orphelines.
Un seuil peut imposer une revue si plus de 10 % des décisions sont réorientées pendant deux semaines ou si trois mesures conservatoires expirent sans verdict. Ces valeurs sont calibrées sur le volume. Elles déclenchent une correction du contrat, pas une pression pour fermer artificiellement les tickets.
Réviser le RACI avec les changements
Nouvelle catégorie, pays, PSP, prestataire logistique ou réorganisation modifie les décisions possibles. La revue d’impact vérifie owners, suppléants, permissions et délais avant le go. Un départ de collaborateur ne doit pas laisser un rôle attaché à une identité personnelle.
Chaque trimestre, un échantillon suit de la demande au résultat. Les acteurs expliquent leur rôle sans lire la matrice. Les écarts entre document et pratique deviennent des actions : simplifier une ligne, corriger un droit, former une équipe ou retirer une décision devenue inutile.
Éviter les erreurs fréquentes
Faire un RACI d’organigramme
Une matrice « produit, ops, IT » face à « conception, run, reporting » paraît complète mais ne guide aucun dossier. Les lignes doivent être des décisions observables et les colonnes des rôles capables d’agir. L’objet et l’effet financier ou réglementaire restent visibles.
Autre erreur : mettre tout le monde en consultation. Le temps d’arbitrage augmente et le véritable veto devient implicite. Chaque C répond à une question précise. Les personnes seulement concernées par le résultat sont informées après décision.
Confondre décision et exécution technique
Le développeur qui peut modifier un statut n’est pas le responsable métier de ce statut. Une correction directe déplace le risque et détruit la preuve. L’owner décide selon la politique ; le SI exécute par un mécanisme idempotent et journalisé lorsque l’outil nominal ne suffit pas.
Enfin, un RACI sans suppléance échoue le week-end ou pendant un congé. Les rôles sensibles possèdent une délégation, un plafond et une durée. Les droits sont testés avant l’absence, puis retirés automatiquement au retour du titulaire.
Plan d’action pour construire le RACI
Cartographier les décisions et leurs effets
L’équipe choisit un parcours, par exemple activation vendeur jusqu’au premier reversement. Elle extrait trente dossiers, incidents et corrections manuelles, puis liste chaque décision qui change droit, argent, visibilité ou promesse. Pour chaque ligne, elle décrit entrées, sorties, responsabilités, autorité, exécution, consultations, destinataires, seuil, délai et preuve. Produit, opérations, finance, conformité et SI valident leurs frontières. Les cas sans Accountable, avec plusieurs Accountable ou sans suppléant bloquent la mise en service.
La mise en œuvre traduit la matrice en groupes, permissions, files, notifications et journalisation. Elle prépare dépendances, instrumentation, monitoring et rollback. Un jeu de tests couvre nominal, plafond dépassé, consultation en retard, veto, délégation et mesure conservatoire. Chaque acteur exécute depuis son écran réel. Une seconde personne doit reconstituer la décision avec les seules traces, sans demander qui « avait dit oui » pendant la réunion.
Piloter une cohorte puis généraliser
Le canary limite une catégorie et deux semaines représentatives. Le tableau suit temps de décision, réorientations, dossiers expirés, renversements et corrections techniques directes. Si plus de 10 % des cas changent de file ou si une mesure conservatoire expire sans owner, alors l’équipe réduit le périmètre et corrige la matrice. Les décisions déjà ouvertes gardent leur version et leur responsable jusqu’à clôture.
L’extension ajoute un parcours ou un pays à la fois. La revue vérifie que les owners disposent de capacité, que les délégations fonctionnent et que les droits correspondent au document. Les exceptions répétées deviennent politique ou sont refusées. Le RACI rejoint l’onboarding des rôles et la revue trimestrielle ; il ne reste pas un livrable de projet oublié après le lancement.
- À faire d’abord : inventorier les décisions qui changent droits, argent ou promesse.
- À tester ensuite : consultation tardive, veto, délégation et urgence.
- À différer : les décisions rares sans parcours ouvert.
- À refuser : toute ligne sans responsable unique, preuve et délai.
Guides complémentaires pour l’opérateur
Structurer le socle d’exploitation
Le dossier sur les écrans indispensables du back-office aide à matérialiser files, actions, preuves et escalades correspondant au RACI.
Le MVP marketplace à livrer avant l’ouverture permet de limiter les décisions initiales et de nommer leurs responsables avant la montée en charge.
Relier gouvernance et sécurité
Le socle sécurité, fraude et conformité marketplace précise les contrôles sensibles, les accès et les mesures conservatoires à répartir.
La méthode pour ouvrir une première catégorie fournit un périmètre concret où tester rôles, capacité et escalades.
Conclusion : rendre les rôles exécutables
Un RACI marketplace ne décrit pas seulement les équipes. Il attribue les décisions qui modifient droits, argent, visibilité et promesse, avec un responsable final unique.
Produit, opérations, finance, conformité et SI conservent leurs frontières. Les décisions transverses utilisent consultation et veto bornés plutôt qu’une responsabilité collective impraticable.
Permissions, workflows, preuves et délais rendent la matrice réelle. Les exceptions, délégations et mesures conservatoires sont testées avant l’urgence, puis suivies par des indicateurs de décision.
Pour cartographier les décisions, construire les workflows et sécuriser les responsabilités, Dawap peut vous accompagner dans votre projet de marketplace opérateur, du premier RACI au pilotage quotidien.
