Un vendeur appelle avec la référence de payout visible sur son relevé. Le support ne trouve rien, demande un numéro de commande, puis ouvre le dossier d’un homonyme depuis son email. Quinze minutes plus tard, l’agent découvre que le payout regroupe quarante-deux commandes et qu’il appartient à une autre entité du même groupe.
Le problème n’est pas un champ de recherche manquant. Les identifiants vivent dans paiement, catalogue, logistique, CRM et outils partenaires avec formats, durées et droits différents. Une mauvaise correspondance expose des données, déclenche une action sur le mauvais objet et transforme une demande simple en incident.
Le vrai enjeu de la recherche administrative dans une marketplace opérateur est de relier une référence fournie à l’objet canonique et à son contexte autorisé. Contre-intuitivement, une recherche « partout » peut réduire la pertinence et la sécurité si elle mélange homonymes, valeurs obsolètes et champs sensibles.
Vous allez comprendre comment inventorier les identifiants, construire mappings et index, interpréter les requêtes, filtrer par droits, présenter la fraîcheur et ouvrir un dossier actionnable. Entrées, sorties, owners, seuils, instrumentation, monitoring, dépendances, retry, file et rollback assurent une reprise fiable.
Définir la recherche opérateur
Partir des enquêtes réelles
Support cherche une commande, Finance un mouvement, Trust un compte et Logistique un colis. Chaque enquête commence avec une valeur disponible : référence PSP, téléphone, SKU seller, tracking ou ticket. L’inventaire vient des cas, pas des colonnes de base.
Le résultat attendu est aussi défini : identifier, confirmer, comprendre ou agir. Une recherche qui renvoie un objet sans le contexte nécessaire oblige l’agent à ouvrir cinq outils. Une recherche qui expose déjà toutes les actions augmente le risque.
Le corpus de départ associe pour chaque enquête la valeur reçue, le bon objet, le temps passé et les erreurs observées. Il inclut les échecs : référence tronquée dans un email, tracking réutilisé, ancienne commande migrée ou nom partagé. Ce jeu devient une fixture de pertinence et de sécurité. Les besoins rares mais sensibles, comme retrouver une dispute depuis un identifiant réseau, ne disparaissent pas derrière les volumes du support généraliste.
Fixer les limites
La recherche administrative n’est pas un outil d’exploration analytique ni un export massif. Elle répond à un dossier légitime, avec finalité et permissions. Les usages de reporting passent par des produits adaptés.
Les domaines gardent leurs sources d’autorité. L’index accélère la découverte, il ne devient pas la vérité métier. Toute action relit l’objet courant dans son service avant exécution.
Inventorier les identifiants
Classer internes et externes
Seller, buyer, offer, order, line, payment, payout, shipment, dispute et ticket possèdent des IDs canoniques. PSP, transporteur, ERP et vendeur ajoutent leurs références. Chaque type indique format, unicité, source et durée.
Une même chaîne peut exister dans deux namespaces. « 12345 » n’est pas interprété sans type ou contexte. Les préfixes visibles réduisent l’ambiguïté ; l’index conserve toujours type et tenant.
Le dictionnaire précise aussi qui génère la valeur et à quel moment. Un order_number lisible peut être unique par boutique seulement, tandis que order_id reste global ; un SKU vendeur peut être réaffecté après suppression, contrairement à offer_id. La recherche affiche le namespace dans le libellé et conserve la période de validité. Les agents apprennent ainsi à demander « référence de quelle source ? » plutôt qu’à supposer.
Encadrer les attributs personnels
Email, téléphone, nom et adresse aident à retrouver un compte, mais changent et ne sont pas des identifiants définitifs. Leur normalisation, historique, rétention et droit de recherche sont spécifiques.
Une valeur partagée peut renvoyer plusieurs personnes ou organisations. L’interface ne choisit pas automatiquement. Elle demande des critères supplémentaires et masque les résultats que l’agent ne peut pas consulter.
Construire les relations canoniques
Modéliser les liens métier
Une commande contient lignes, paiements et colis ; un payout regroupe mouvements de plusieurs commandes ; un litige peut viser une ligne. Le graphe décrit relation, direction, validité et source.
Les liens ne sont pas déduits uniquement par valeur identique. Un payment metadata erroné ne doit pas rattacher deux clients. Le domaine émet une relation ou un mapping validé avec version.
Le payout illustre une relation complexe : il agrège ledger entries, commandes, remboursements et frais, parfois sur plusieurs boutiques d’une même entité. La vue conserve le chemin payout vers mouvement puis vers order_line. Elle n’attache pas directement toutes les commandes au seller sans préciser la base. Un agent peut expliquer le total et isoler l’écriture contestée sans confondre une relation d’appartenance avec une cause financière.
Gérer fusion et historique
Un compte fusionné, une offre migrée ou un tracking réutilisé conserve ancien et nouvel identifiant avec fenêtre. La recherche retrouve l’historique sans présenter deux objets actifs identiques.
Une fusion produit merged_into et un événement. Un split indique les objets résultants. Le support voit la transformation et ne tente pas d’agir sur une identité retirée.
Alimenter un index fiable
Projeter des documents de recherche
Chaque domaine publie identifiant, aliases, relations, libellés autorisés, statut et updated_at. L’index stocke une projection minimale pour classer les résultats. Les détails restent chargés à l’ouverture.
Le schéma est versionné. Les champs sensibles sont séparés ou chiffrés selon l’usage. Un mapping dynamique ne doit pas indexer par accident une donnée personnelle ajoutée à un événement.
Garantir ingestion et reprise
Les entrées sont événements de domaine et snapshots ; les sorties documents indexés et checkpoints. Search Platform est owner. Idempotence, ordre, retry et dead-letter queue protègent la projection.
Un backfill lit une source bornée avec manifeste. Le monitoring compare événements attendus, indexés et erreurs. Le replay garde tenant et version pour ne pas créer des aliases croisés.
La cohérence utilise un outbox ou une source de changements plutôt qu’un double write fragile. Chaque projecteur garde dernier offset, version d’objet et checksum des champs recherchables. Une mise à jour plus ancienne ne remplace pas une projection récente. Si un schéma inconnu arrive, alors la partition concernée se met en sécurité, alerte l’owner et continue les types compatibles plutôt que de bloquer tout l’index.
Interpréter la requête
Normaliser selon le type
Un email est mis en forme, un téléphone suit le pays, un UUID reste exact et un tracking respecte son alphabet. La normalisation conserve la valeur saisie. Elle n’enlève pas des caractères arbitrairement à tous les identifiants.
La détection de type propose des candidats avec confiance. L’agent peut forcer « payout » ou « commande ». Une requête exacte passe avant une recherche floue.
Les préfixes et séparateurs servent de hints, mais ne deviennent pas une autorité. Une valeur ressemblant à un téléphone peut être un SKU ; l’interface montre les types candidats et la portée active. Les filtres seller, date ou montant sont appliqués après une première détection structurée. L’historique de recherche ne réinjecte jamais automatiquement une ancienne organisation lorsqu’un agent change de dossier.
Limiter le fuzzy matching
La tolérance aux fautes convient aux noms et libellés, pas aux montants ni IDs financiers. Elle est bornée par tenant, type et longueur. Un caractère différent dans un order_id peut désigner une autre commande.
Par exemple, une recherche exacte de « PAY-84K2 » renvoie un payout unique ; « PAy 84K2 » peut être normalisé. « PAY-84K3 » n’est jamais rapproché par distance si ce second identifiant existe.
Appliquer les permissions
Filtrer avant le résultat
Le moteur applique rôle, organisation, domaine, objet et finalité avant de renvoyer. Il ne montre pas un résultat interdit avec détails masqués, car son existence peut déjà être sensible.
Un agent support voit commandes de son périmètre ; Finance les mouvements nécessaires ; Trust des signaux protégés. Les règles de row et field level sont testées ensemble.
L’autorisation s’applique à la requête, au résultat, à l’ouverture et à chaque relation chargée. Un objet autorisé ne donne pas automatiquement accès à son buyer ou à ses signaux Trust. Les permissions sont évaluées depuis un contexte frais avec organization_id et purpose. Un changement de rôle invalide les sessions ou caches concernés ; un résultat déjà affiché ne reste pas exploitable après retrait du droit.
Auditer les recherches sensibles
La recherche par email, téléphone, adresse ou référence financière conserve acteur, motif, valeur hachée, filtres et résultats consultés. Les accès massifs ou répétés déclenchent une alerte.
Les champs révélés progressivement demandent parfois un dossier ou une justification. Les comptes d’urgence expirent. Le journal d’audit n’expose pas lui-même la valeur en clair à tous les administrateurs.
Présenter les résultats
Montrer type, provenance et fraîcheur
Chaque résultat affiche type, identifiant canonique, statut, tenant, source et updated_at. Les aliases ayant conduit au match sont signalés. L’agent distingue un objet actif d’une référence historique.
La fraîcheur est lisible : « indexé il y a 20 secondes » et « source consultée maintenant ». Une donnée dépassant son SLA reçoit un avertissement et une action de rafraîchissement contrôlée.
Désambiguïser sans deviner
Lorsque plusieurs résultats sont légitimes, l’écran demande un second critère : date, montant, organisation ou catégorie. Il affiche juste assez de contexte autorisé pour choisir. Le premier score n’est pas ouvert automatiquement.
Les résultats sont groupés par objet puis relation. Un payout peut apparaître au-dessus de ses commandes sans que celles-ci soient prises pour des matches directs. La navigation conserve la requête initiale.
Le classement explique pourquoi un élément apparaît : identifiant exact, alias historique, attribut normalisé ou libellé approchant. Il ne combine pas ces signaux dans un score opaque. Un match exact ancien peut précéder un nom actuel flou, mais son statut « fusionné » reste visible. Si deux résultats exacts existent dans des tenants autorisés, alors l’interface exige un choix et n’utilise ni récence ni montant pour deviner.
Ouvrir le bon contexte
Construire une vue dossier
L’ouverture charge la source d’autorité, les relations utiles, une timeline et les alertes. Le contexte dépend du type : paiement et ledger pour un payout, lignes et colis pour une commande.
Les onglets gardent identifiants visibles et liens copiables selon droits. Un agent ne mélange pas deux dossiers ouverts. L’entête colore l’environnement et l’organisation pour éviter une action au mauvais endroit.
Préserver la causalité
La timeline distingue occurrence et ingestion. Elle relie demande, décision et effet. Un webhook reçu tard ne se place pas artificiellement après l’action qu’il décrit.
Les notes restent attribuées et séparées des faits. Une capture illustre ; elle ne remplace pas le lien vers l’événement. Le support peut partager un dossier interne sans exporter toutes les données.
Le lien partagé transporte object_type et canonical_id, jamais la requête personnelle en clair. À l’ouverture, les droits sont recalculés et les sections non autorisées restent absentes. Une copie destinée à un ticket externe produit un résumé expurgé avec date, source et auteur. Elle ne colle pas le DOM de la page ni les attributs cachés, ce qui évite de transformer la collaboration en fuite latérale.
Sécuriser les actions
Relire avant mutation
Au clic, l’action recharge version, statut et droits depuis le domaine. Elle compare etag ou version à celle affichée. Si l’objet a changé, alors l’agent revoit le contexte.
La confirmation nomme objet, population, effet et rollback. Une action globale ne se cache pas derrière une ligne de résultat. Les opérations sensibles exigent motif et parfois double approbation.
Tracer intention et résultat
Chaque commande porte action_id, acteur, objet, inputs, motif et idempotency key. Son résultat et ses effets reviennent dans la timeline. Un timeout reste incertain jusqu’à réconciliation.
Le support ne répète pas une action parce que l’écran paraît figé. Le runbook consulte action_id, interroge le domaine puis rejoue seulement si l’absence d’effet est prouvée.
Une action de masse commence par une population figée et prévisualisée. Le système montre les objets exclus depuis la recherche, car une facette peut changer pendant la revue. Au-dessus du seuil approuvé, un second opérateur confirme le manifeste. Les sorties sont succès, refus et incertains ; un rollback applique des compensations par objet. Le moteur ne rejoue jamais aveuglément tout le lot après une coupure réseau.
Préparer les modes dégradés
Réagir à un index indisponible
Un fallback exact peut interroger quelques sources critiques par ID typé. Il ne lance pas une requête large sur toutes les bases. L’interface indique le mode dégradé et ses limites.
Les recherches personnelles ou floues peuvent être suspendues. Les actions restent disponibles depuis un lien direct vérifié si le domaine répond. La sécurité n’est pas abaissée pour compenser la panne.
Le mode exact de secours est borné par types, quotas et délai. Il journalise source interrogée et résultat, puis rapproche ces recherches avec le nouvel index après restauration. Si une source critique ne répond pas, l’interface affiche « résultat indéterminé », pas « aucun résultat ». L’agent ouvre une file d’attente avec la référence fournie et un SLA, ce qui évite de créer un objet de remplacement ou d’abandonner un dossier légitime.
Restaurer et réconcilier
Le plan restaure snapshot, checkpoint et événements suivants. Un canary compare index et sources. Le trafic revient progressivement avec monitoring de latence, erreurs et résultats vides.
Si plus de 0,2 % des objets échantillonnés sont absents ou si deux tenants se croisent, alors le rollback maintient l’ancien index. Les documents produits durant l’incident sont backfillés avant ouverture complète.
Mesurer qualité et abus
Suivre succès et temps utile
Le dashboard suit zero-result, multiple-result, reformulations, clic utile, temps jusqu’au dossier et temps jusqu’à résolution. Il segmente par type et rôle. Une latence faible ne compense pas de mauvais objets.
Les requêtes sans résultat sont échantillonnées après hachage et contrôle. Elles révèlent alias manquant, source en retard ou besoin non couvert. Chaque correction possède owner et mesure après livraison.
Le taux de succès est confronté à la résolution : ouvrir un résultat puis revenir immédiatement suggère une mauvaise pertinence. Un clic suivi d’une action refusée peut révéler un droit ou un contexte incomplet. Les sessions sont agrégées sans surveiller inutilement les agents. Une revue mensuelle rejoue cinquante fixtures et dix cas réels, puis vérifie que l’amélioration d’un type n’a pas dégradé un autre namespace.
Détecter exfiltration et dérive
Le monitoring signale volume inhabituel, séquences alphabétiques, recherches de dirigeants, accès hors horaire et export répété. Une détection ouvre une revue de sécurité sans exposer davantage de données.
La qualité technique rapproche lag, dead letters, documents orphelins, droits refusés et divergences. Une réconciliation quotidienne teste des fixtures par tenant. Les seuils possèdent alertes et runbooks.
Adapter la méthode et éviter les erreurs
Pour qui la recherche administrative convient
Elle devient nécessaire quand plusieurs domaines et partenaires identifient le même dossier différemment. Une petite marketplace commence avec recherche exacte sur commande, seller, paiement et colis, puis ajoute aliases observés.
Chaque domaine possède ses IDs et relations, Search Platform l’index, Sécurité les accès et Operations les parcours. L’owner du cas définit le contexte utile, pas la totalité des données disponibles.
Erreurs fréquentes de la recherche admin
Utiliser email comme clé, mélanger namespaces, indexer toutes les données, filtrer après résultat, activer le fuzzy sur des IDs et agir depuis une projection obsolète sont les erreurs majeures.
Une autre erreur consiste à mesurer uniquement la latence. Enfin, un champ universel sans vues dossier déplace simplement les onglets après la recherche. Le résultat doit mener à une enquête sûre.
Plan d’action pour construire la recherche administrative
Semaines 1 à 4 : cas et index
La première semaine analyse deux cents recherches et leurs valeurs initiales. La deuxième inventorie types, namespaces, droits et relations. La troisième définit documents et événements ; la quatrième indexe commande, seller, paiement et colis.
Les fixtures couvrent exact, alias, historique, homonyme, tenant, email partagé, mapping absent et objet supprimé. Chaque résultat attendu indique type, source, fraîcheur et droits.
Semaines 5 à 8 : dossiers et exploitation
La cinquième semaine construit les vues dossier ; la sixième sécurise actions et audit. L’instrumentation suit lag, résultats, clics, résolution, permissions et anomalies avec seuils, owners et runbooks.
Les semaines sept et huit testent panne index, backfill, tenant croisé et rollback. Le go exige zéro fuite, 99 % des fixtures retrouvées sous le SLO et reprise d’une action incertaine depuis action_id.
Le paquet de run conserve dictionnaire d’identifiants, schémas, mappings, policies, fixtures, accès et procédures de restauration. Une personne extérieure au projet doit partir d’une référence PSP, retrouver le bon dossier, justifier le match et reprendre une dead letter. La recette mesure le temps sans sacrifier la vérification d’identité.
La décision d’extension compare résultats exacts, ambiguïtés, recherches interdites, lag et temps de résolution par rôle. Si le support gagne du temps mais que Finance ouvre davantage de mauvais payouts, alors l’owner limite la nouvelle détection au périmètre validé. En revanche, un alias manquant sur un type critique bloque la suppression de l’ancien outil jusqu’à ce que backfill et fixtures prouvent la couverture.
- À faire d’abord : inventorier cas, types, namespaces, relations et permissions.
- À tester ensuite : alias, historique, homonyme, fraîcheur, action, panne et rollback.
- À différer : le fuzzy matching tant que la recherche exacte reste incomplète.
- À refuser : toute action sensible depuis un résultat non relu dans sa source.
Ressources complémentaires pour l’opérateur
Borner le premier index
Le MVP marketplace avant ouverture aide à choisir les objets recherchables indispensables.
La méthode pour ouvrir une première catégorie fournit des dossiers pilotes.
Stabiliser objets et écrans
Le catalogue PIM marketplace structure identifiants d’offres et variantes.
Les écrans du back-office opérateur cadrent navigation, droits et actions.
Conclusion : retrouver avant d’agir
Une recherche administrative fiable relie références internes, externes et historiques à des objets canoniques.
Namespaces, permissions, fraîcheur et contexte empêchent un résultat plausible de devenir une mauvaise action.
Audit, résilience et réconciliation maintiennent la recherche utile même lorsque les systèmes évoluent.
Dawap peut vous accompagner pour construire ce socle dans votre marketplace opérateur.
