Filtres marketplace : le prix et le stock de la même offre

Un acheteur filtre une marketplace sur trois critères : moins de 100 euros, au moins une unité disponible et un délai annoncé de deux jours maximum. Une fiche apparaît à 80 euros. Pourtant, le vendeur à 80 euros n’a plus de stock ; celui qui peut expédier vend à 120 euros. Chaque information existe dans le catalogue, mais aucune offre ne réunit la promesse affichée.

La recherche doit couvrir une proposition vendeur complète avant de retenir le produit. Séparer correctement produit et offre dans le PIM ne suffit pas si l’index, le filtre ou le tri recombine ensuite leurs valeurs. Le risque se prolonge dans le prix du listing, le compteur de résultats et la sélection transmise au panier.

Avec Elasticsearch, un tableau d’objets ordinaires peut perdre l’association entre les champs de chaque objet lors de l’indexation. Nous partons de quatre produits et huit offres fictives pour rendre cette erreur visible, puis distinguons filtrage, offre gagnante et comptage. Un exercice SQLite exécutable vérifie le raisonnement relationnel ; il ne constitue pas un test d’Elasticsearch en fonctionnement.

Notre accompagnement en création de marketplace relie le modèle de données à la promesse acheteur. La conception du catalogue, du PIM et de la taxonomie marketplace doit préserver l’identité des offres jusqu’à leur présentation, avec des règles compréhensibles pour les équipes produit et les vendeurs.

Dans quel cas suspecter une combinaison d’offres impossible

Reconnaître une contradiction stable entre liste et fiche

Le défaut se rencontre lorsqu’un document de recherche représente un produit et contient plusieurs propositions commerciales. Un prix bas, une disponibilité et un délai peuvent chacun être vrais sans appartenir au même vendeur. Une fiche agrégée ne doit pas devenir une autorisation de composer une offre virtuelle à partir des meilleurs champs disponibles.

Le premier signal faible est un écart reproductible avec des données pourtant à jour : la réindexation ne corrige rien. Un second signal est un changement de vendeur après le clic, alors que l’acheteur a sélectionné une contrainte précise. Le support voit des « prix introuvables » et des retours immédiats vers la liste, sans nécessairement observer d’erreur serveur.

Séparer ce diagnostic des problèmes de fraîcheur

Un stock ancien peut produire une promesse fausse même si la corrélation est correcte. Ici, nous figeons toutes les données pour isoler une autre cause : le calcul sélectionne des caractéristiques incompatibles au même instant. Il faut d’abord reproduire cette contradiction sur une photographie connue avant d’accuser le délai des flux vendeurs.

La méthode concerne les opérateurs qui regroupent plusieurs offres sur une fiche commune. Une recherche déjà organisée par offre peut éviter ce croisement particulier, mais doit encore gérer regroupement produit, pagination et affichage. Le choix technique dépend de l’unité que l’utilisateur compare ; il ne découle pas automatiquement de la présence de plusieurs vendeurs.

Écrire le contrat commercial que les filtres doivent respecter

Qualifier montant, quantité et délai avant la requête

Notre scénario porte sur une unité, un prix en euros, une offre active et un délai indicatif déjà calculé pour le même contexte. La borne de prix est inclusive : 100 euros passent, 100,01 euros ne passent pas. Les montants sont stockés en centimes entiers. Aucune conversion de devise ni règle fiscale n’est exécutée dans la recette.

Dans une marketplace réelle, il faut préciser si le prix inclut taxes, livraison, quantité minimale et tarif de compte. De même, « deux jours » doit désigner une durée définie, pas mélanger préparation, transport et date de réception. Ces décisions appartiennent au contrat produit ; le moteur ne peut pas les déduire de noms de champs ambigus.

Conserver un identifiant d’offre utilisable après la recherche

Une proposition possède au minimum son identifiant, son produit, son vendeur et les conditions pertinentes. L’état de publication, la devise, le montant, la quantité vendable et le délai restent attachés à cette identité. Le résultat doit pouvoir expliquer quelle proposition a satisfait les contraintes, même si la carte affiche d’abord le nom du produit.

Les valeurs absentes ne deviennent pas implicitement favorables. Un délai inconnu ne signifie pas livraison immédiate ; un prix vide ne signifie pas gratuité. La recette exclut ces cas pour la sélection définie. Un autre parcours, comme une demande de devis, peut les traiter autrement, mais doit afficher cette différence au lieu de réutiliser le même badge.

Observer quatre produits dont seuls deux répondent au besoin

Construire des témoins que la recherche ne peut pas interpréter librement

Le produit P1 possède A à 80 euros, sans stock, et B à 120 euros avec cinq unités disponibles. Leurs délais sont respectivement un et deux jours. A échoue sur le stock ; B échoue sur le prix. P1 doit disparaître de cette sélection, même si sa fiche contient séparément un prix inférieur à 100 euros et une quantité positive.

P2 possède C à 95 euros, trois unités et deux jours, ainsi que D à 60 euros, quatre unités et cinq jours. Seule C répond au contrat. P3 possède deux offres admissibles : E à 90 euros, deux unités et un jour ; F à 99 euros, une unité et deux jours. P4 possède G à 70 euros mais suspendue, et H à 85 dollars, active. Aucun calcul de conversion n’autorise H dans une recherche en euros.

Fixer les résultats attendus avant de modifier le moteur

Le tri croissant doit présenter P3 à 90 euros, puis P2 à 95 euros. Trois offres satisfont les contraintes, mais elles correspondent à deux produits. Ces réponses sont établies depuis les huit propositions détaillées, indépendamment de l’implémentation que l’équipe souhaite faire accepter.

Par exemple, si P1 apparaît, alors le contrôleur a combiné au moins deux propositions ou ignoré une contrainte. Si P2 apparaît à 60 euros, alors la sélection produit peut être correcte tandis que le prix affiché ne l’est plus. Ces deux anomalies demandent des corrections différentes ; un simple nombre de résultats ne suffit pas à les distinguer.

Garder tous les critères dans la même offre Elasticsearch

Comprendre ce que le type object ne conserve pas

La documentation Elastic sur les tableaux de valeurs et d’objets explique qu’un tableau d’objets ordinaires est aplati lors de l’indexation. Des critères portant sur des champs différents peuvent alors correspondre à des objets différents. Le JSON d’origine peut paraître correctement structuré tout en conduisant à cette recherche indésirable.

Le type nested permet de préserver l’indépendance des objets à interroger. Le mapping d’offres doit être explicite avant leur chargement. Ce choix n’améliore pas à lui seul les données sources et ne dispense pas de décider quels champs appartiennent au produit, au vendeur ou à sa proposition commerciale.

Réunir la conjonction dans une seule portée nested

La requête nested sélectionne un document parent lorsqu’un objet imbriqué satisfait sa requête. Pour notre contrat, les cinq conditions doivent donc se trouver ensemble dans le même bloc. Deux blocs séparés, l’un pour le prix et l’autre pour le stock, pourraient être satisfaits par deux offres différentes.

{
  "query": {
    "nested": {
      "path": "offers",
      "query": {
        "bool": {
          "filter": [
            {"term": {"offers.active": true}},
            {"term": {"offers.currency": "EUR"}},
            {"range": {"offers.price_cents": {"lte": 10000}}},
            {"range": {"offers.quantity": {"gte": 1}}},
            {"range": {"offers.delay_days": {"lte": 2}}}
          ]
        }
      }
    }
  }
}

Ce fragment suppose un champ offers de type nested, des nombres correctement typés, un booléen et une devise de type keyword. Il illustre la portée commune des contraintes ; il n’est pas présenté comme une requête complète de production. Recherche textuelle, droits de visibilité, contexte acheteur et limites de réponse doivent être ajoutés selon le système réellement livré.

Afficher l’offre qui a réellement rendu le produit admissible

Retourner la preuve du résultat avec inner_hits

La sélection du parent ne dit pas automatiquement quelle offre doit alimenter la carte. Les inner hits permettent de récupérer les objets imbriqués qui ont correspondu. Leur taille et leur tri doivent être explicités : la documentation prévoit par défaut seulement trois correspondances, classées selon le score.

Pour afficher une seule offre gagnante, le contrat peut demander la moins chère parmi celles qui passent, puis départager les égalités avec un identifiant stable. L’identifiant de cette offre accompagne prix, devise et promesse. Relire ensuite le minimum global de toutes les offres du produit annulerait la correction réalisée dans la requête.

Rendre le choix visible sans enfermer l’acheteur

La carte P2 doit annoncer 95 euros pour la proposition C. La fiche peut montrer D à 60 euros en expliquant son délai de cinq jours, mais ne doit pas la présenter comme la continuité exacte du filtre « deux jours maximum ». L’acheteur reste libre de changer de contrainte ; ce changement devient une décision visible.

Le lien vers la fiche conserve le contexte utile et l’identité de l’offre sélectionnée. Si cette offre n’existe plus, l’interface l’indique et propose une alternative clairement décrite. Le badge « dès 60 euros » ne doit pas remplacer silencieusement le prix filtré de 95 euros dans un parcours qui promet toujours le délai court.

Trier sur le prix admissible et non sur le minimum du produit

Répéter le périmètre dans le calcul de tri

Elastic documente un tri dans les objets nested avec un chemin et un filtre propres. Ce filtre détermine quelles valeurs participent au tri ; il n’est pas actif par défaut. Le contrat de recherche doit donc aligner l’ensemble filtré et l’ensemble utilisé pour calculer le prix de classement.

Cas concret : trier P2 et P3 sur toutes leurs offres place P2 en tête grâce aux 60 euros de D. Pourtant, D ne respecte pas le délai demandé. Après restriction aux offres admissibles, P3 à 90 euros précède P2 à 95 euros. La différence n’est pas une préférence de merchandising : elle corrige la valeur sur laquelle repose le tri annoncé.

Départager les égalités sans changer la promesse

Si deux propositions d’un produit ont le même prix admissible, il faut une règle explicite pour choisir la carte : qualité de service documentée, délai, puis identifiant stable, par exemple. Notre exercice utilise seulement prix puis identifiant d’offre. Il ne prétend pas optimiser la marge ou l’équité d’exposition entre vendeurs.

Le ranking commercial intervient dans le cadre autorisé par le produit. Une commission plus élevée ne rend pas admissible une offre trop chère ou trop lente. L’équipe doit séparer la décision « ce produit répond » de la décision « cette proposition représente le produit », puis du classement entre produits. Ces trois sorties se testent séparément.

Compter les produits et les offres sans changer d’unité

Choisir ce que le nombre affiché promet

Les agrégations nested travaillent sur les documents imbriqués. Une sous-agrégation filtrée permet de restreindre les offres considérées. Reprendre toutes les offres des produits sélectionnés réintroduirait D dans certains calculs, même si C était la seule proposition qui justifiait la présence de P2.

Le retour au parent avec reverse_nested permet de remonter au niveau produit depuis une agrégation imbriquée. Dans notre exemple, les trois offres C, E et F donnent deux parents distincts. Le libellé doit donc annoncer « deux produits » ou « trois offres », selon l’objet réellement compté.

Définir le contexte propre à chaque facette

Une facette peut compter les résultats avec tous les filtres actifs ou montrer ce qui deviendrait disponible en modifiant son propre filtre. Ces deux comportements sont possibles, mais ils n’annoncent pas la même chose. Le responsable produit doit écrire le contexte attendu au lieu de comparer des nombres calculés sur des populations différentes.

Pour chaque valeur proposée, la recette précise les contraintes conservées, celles temporairement retirées et l’unité de comptage. Les paramètres de l’agrégation, la liste et la pagination sont ensuite rapprochés. Un compteur exact sur les offres reste faux pour l’interface s’il est présenté comme un nombre de produits distincts.

Exécuter les erreurs témoins avant de tester le moteur réel

Un banc relationnel pour réfuter quatre raisonnements incorrects

Le programme Python et SQLite des offres corrélées crée huit lignes fictives en mémoire. Il compare une sélection appliquée à chaque offre à des filtres indépendants par produit. Il confronte aussi prix global et prix admissible, nombre d’offres et nombre de produits, puis exclusion globale et conservation d’une offre valable.

python3 offres_correlees.py
42 contrôles réussis ; 24 permutations
4 témoins insuffisants détectés
Résultat : P3 / E / 90 EUR puis P2 / C / 95 EUR
Trois offres admissibles, deux produits affichés

Si P4 remonte dans la recherche en euros, alors la livraison reste bloquée, même si le prix affiché semble inférieur à 100 euros. G est suspendue et H porte une autre devise : aucune des deux ne satisfait le contrat. L’équipe doit corriger la portée commune des critères avant de retester le tri ; modifier seulement le libellé monétaire masquerait le défaut sans rendre la proposition admissible.

Le quatrième témoin retire un produit dès qu’une de ses offres ne passe pas. Il conserve P3 mais élimine P2 à cause de D, alors que C suffit à satisfaire le besoin. Paradoxalement, durcir globalement le filtre peut masquer une bonne proposition au lieu de corriger une mauvaise association. La règle attendue exige ici au moins une offre entièrement admissible.

Tester les limites et reconnaître ce qui reste à prouver

Les vingt-quatre ordres des quatre produits, avec leurs offres réordonnées, conservent les mêmes cartes. Les cas limites vérifient 100 euros, 100,01 euros, stock nul, délai trop long, suspension, devise différente et valeurs absentes. Un prix égal est départagé de manière stable. Après épuisement de C, la sélection courante ne conserve plus P2.

Ces observations prouvent la logique locale de la recette, pas l’exécution du fragment Elasticsearch. La réception réelle doit charger ce jeu dans un index de test avec le mapping, la version du moteur et les requêtes effectivement utilisées. Elle compare les identifiants retenus, les inner hits, les valeurs de tri et les agrégations aux résultats attendus, puis contrôle le rendu du frontend.

Erreurs fréquentes après une première correction du filtre

Corriger la requête tout en conservant une carte trompeuse

Le défaut peut survivre dans un composant qui calcule son propre minimum, un cache qui ignore les filtres ou un service qui remplace l’offre choisie par celle de la meilleure commission. Il faut suivre les champs rendus, pas seulement constater que la liste contient les bons identifiants produits. Une capture de la carte doit être reliée à sa réponse de recherche.

Un autre piège consiste à traiter « aucune offre interdite » comme l’équivalent de « une offre autorisée existe ». La documentation de la requête nested attire l’attention sur la portée des exclusions. Une interdiction au niveau produit peut être justifiée par une politique distincte, mais elle ne doit pas résulter accidentellement d’une traduction du filtre commercial.

Confondre cohérence de recherche et autorisation de commander

Un résultat correctement corrélé peut devenir périmé avant l’ajout au panier. Le moteur de recherche ne réserve pas le stock et ne garantit pas la validité future du tarif. La commande doit revérifier l’offre sélectionnée et les conditions applicables auprès des services responsables, avec une décision explicite si la proposition change.

La suspension d’un vendeur ou un changement de droits ne doit pas attendre uniquement une réindexation pour protéger une opération sensible. Le contrôle transactionnel reste indépendant. Ce dossier traite des offres publiques fictives ; il ne certifie pas l’isolation des tarifs privés ni les autorisations d’un catalogue B2B à partir d’un filtre de recherche.

Plan d’action : vérifier une promesse complète de la liste au panier

Figer un petit catalogue contradictoire avec ses réponses attendues

Commencez par une catégorie où plusieurs vendeurs proposent réellement les mêmes produits. Le responsable catalogue choisit les champs intrinsèques et commerciaux ; le responsable produit écrit ce que signifient les filtres. La QA construit les offres contradictoires avant de demander une correction technique. Le tableau attendu précise produits présents, proposition affichée, ordre et compteurs.

Les entrées comprennent une photographie du PIM, les offres et le contexte acheteur. Les sorties comprennent des identifiants admissibles, un prix représentatif et une explication de chaque exclusion. Le responsable recherche conserve la version du mapping, des requêtes et des règles. Le seuil d’acceptation du jeu témoin est exact : aucun faux produit et aucun prix emprunté à une offre exclue.

Relier calcul, réponse et écran dans la même réception

Vérifiez d’abord la sélection, puis le tri, puis les compteurs et enfin le rendu. Cette séquence permet d’attribuer chaque écart. L’intégration doit transmettre l’identité de l’offre retenue jusqu’à la fiche ; le frontend ne doit pas réinventer le gagnant. La QA inspecte aussi un retour arrière, un lien partagé et une réponse de recherche arrivant après une nouvelle sélection.

Le runbook prévoit une mise à jour de stock pendant le parcours et une offre suspendue entre deux lectures. Les dépendances comprennent index, cache, service d’offre et panier. La journalisation conserve contexte de filtre, identifiants et versions nécessaires au diagnostic. Le repli retire une promesse devenue invérifiable ou demande une nouvelle sélection ; il ne fabrique pas une disponibilité rassurante.

Mesurer le coût du modèle avant d’étendre la correction

Les objets nested ont un coût de stockage et de requête que la documentation Elastic invite à considérer. Mesurez le nombre d’offres par produit, la taille des réponses, les temps de tri et les agrégations sur la distribution réelle. Un petit jeu fonctionnel ne dimensionne pas une catégorie dominée par quelques produits portant des centaines de propositions.

Une autre architecture peut indexer les offres séparément, à condition de résoudre explicitement le regroupement et la pagination produit. Il faut comparer les deux options sur les mises à jour, la mémoire, la lisibilité et la maintenance du contrat. Le choix n’est pas une compétition de technologies : l’opérateur doit pouvoir prouver la promesse affichée à un coût acceptable.

• Ouvrir la catégorie pilote lorsque les témoins passent dans le moteur réel et que la carte reprend l’offre admissible.
• Différer l’extension tant que les coûts et la fraîcheur restent inconnus sur les catégories denses.
• Refuser une mise en ligne qui réintroduit un prix global après un filtrage correctement corrélé.

Relier ce contrôle à la gouvernance du catalogue

Définir les responsabilités avant de construire la projection

La méthode produit, offre et recherche : séparer les vérités traite les frontières de données et leurs cycles de vie. Elle aide à décider quels objets alimentent la projection. Le contrôle présenté ici intervient ensuite, quand plusieurs offres correctement identifiées doivent satisfaire une combinaison précise sans perdre leur association.

Le modèle d’index conserve cette distinction plutôt que de se substituer au catalogue. Les corrections de source, les versions d’offre et les suspensions doivent rester attribuables. Une adaptation locale dans le moteur peut masquer l’incident pendant quelques heures tout en laissant le prochain import reproduire les mêmes contradictions.

Donner aux facettes une promesse que l’on peut vérifier

Le cadrage des facettes marketplace couvre leur utilité, leurs compteurs et leurs URLs. Il complète la recette d’offres corrélées en distinguant navigation acheteur et choix d’indexation. Un filtre mathématiquement cohérent peut encore être incompris ou inutile pour la décision d’achat.

Le back-office doit rendre les contradictions consultables : produit, offres examinées, contraintes et proposition finalement retenue. Cette vue aide l’opérateur à répondre au vendeur sans attribuer au hasard un problème de recherche à la qualité de son catalogue. Elle donne aussi au support un dossier reproductible à transmettre à l’équipe technique.

Conclusion : chaque promesse doit appartenir à une offre réelle

Un prix intéressant, un stock positif et un délai court ne constituent pas une offre lorsqu’ils proviennent de propositions différentes. La corrélation doit survivre au filtre, au calcul du prix représentatif, au tri et à l’affichage. Corriger une seule de ces étapes laisse la contradiction circuler dans le parcours.

Les quatre produits fictifs donnent un résultat simple à vérifier : trois offres admissibles, deux produits, P3 à 90 euros puis P2 à 95 euros. Les témoins incorrects montrent pourquoi un nombre plausible ou une liste apparemment pertinente ne suffit pas. L’exercice local prépare une réception sur le moteur réel sans prétendre l’avoir remplacée.

La conception du catalogue et du PIM marketplace doit conserver les identités et les conditions commerciales nécessaires à cette preuve, puis organiser leur mise à jour jusqu’aux écrans utilisés par les acheteurs.

Dawap accompagne votre projet de marketplace opérateur pour relier modèle de données, recherche et parcours de commande. Nous cadrons les règles de sélection, construisons les cas contradictoires et préparons les contrôles qui permettent aux équipes de comprendre chaque proposition affichée.