Un client cherche un « raccord pour tuyau souple » et le catalogue emploie une autre terminologie. Une recherche sémantique peut rapprocher des formulations qui ne partagent pas les mêmes mots. Mais en B2B, une ressemblance de sens ne suffit pas : diamètre, matière, pression admissible ou compatibilité peuvent exclure un produit pourtant proche. Le projet doit combiner la compréhension de la demande avec des contraintes structurées. Une référence suggérée doit être pertinente pour l’usage, pas seulement pour la phrase saisie.
En bref : recherche par sens, recherche exacte et filtres métier doivent être évalués ensemble, avec des cas où un produit proche reste techniquement inadapté.
Séparer vocabulaire et caractéristiques obligatoires
Les clients utilisent des noms de métier, des abréviations et des descriptions d’usage. Le catalogue peut employer une terminologie fabricant. Le travail consiste d’abord à identifier ces écarts à partir de demandes réelles. Certains peuvent être traités par des synonymes maîtrisés ; d’autres demandent une recherche capable de rapprocher des formulations plus longues. L’IA n’est pas nécessairement la réponse à chaque différence de mot.
Les contraintes doivent rester explicites. Une dimension ou une compatibilité ne devrait pas disparaître parce qu’un résultat obtient un bon score sémantique. Les attributs structurés permettent de limiter les produits selon les exigences reconnues. Le prestataire doit expliquer comment les filtres sont appliqués et comment l’interface montre ceux qui ont été retenus.
Les références exactes demandent un parcours spécifique. Un acheteur qui saisit un code produit ne cherche pas forcément une alternative ressemblante. La recherche doit traiter les séparateurs, les variantes et les éventuelles références remplacées selon les règles du catalogue. Présenter automatiquement un produit voisin peut être trompeur si la différence n’est pas rendue visible.
Préparer des données qui décrivent réellement les produits
Une description promotionnelle ne contient pas toujours les caractéristiques nécessaires au choix. Les unités, les valeurs et les familles doivent être cohérentes. Deux produits indiquant une dimension sous des formats différents peuvent être difficiles à comparer. Le projet de recherche doit commencer par un examen du catalogue, plutôt que tenter de réparer toutes les incohérences au moment de la requête.
Les compatibilités doivent être documentées et maintenues. Une expression vague comme « convient aux équipements professionnels » ne suffit pas à identifier un usage autorisé. Le système peut aider à retrouver une information, mais ne doit pas inventer une relation entre des produits. Les correspondances connues doivent venir d’une source métier validée et être séparées des rapprochements linguistiques.
Les nouveautés et les produits retirés doivent suivre un circuit d’actualisation. Le responsable doit savoir quand une modification devient visible dans la recherche. Un catalogue correct dans l’outil de gestion peut rester périmé dans l’index si la synchronisation échoue. Les statuts de disponibilité et les informations commerciales doivent également être présentés avec leur portée réelle.
Construire un test avec les mauvaises réponses possibles
Le jeu de requêtes doit couvrir les recherches faciles et les ambiguïtés. Une demande sans dimension, un code proche et une description mélangeant deux familles révèlent des besoins différents. Les responsables produit doivent indiquer les résultats acceptables et ceux qui seraient trompeurs. Le test ne doit pas être limité aux exemples utilisés pour préparer la démonstration.
Les premiers résultats comptent, mais il faut aussi regarder les produits qui ont été écartés. Une solution peut sembler pertinente en proposant trois articles plausibles et manquer la référence attendue. Les mesures doivent être définies avec les utilisateurs du catalogue. Le nombre de résultats ne constitue pas, à lui seul, une indication de qualité.
L’absence de résultat peut être préférable à une suggestion incompatible. L’interface peut demander une précision ou transmettre la demande à un interlocuteur. Ce parcours doit être prévu pour les contraintes insuffisamment documentées. Le logiciel ne doit pas présenter une recommandation comme une validation technique lorsque les informations nécessaires ne sont pas disponibles.
Ces filtres reposent sur les informations préparées en amont. Notre dossier sur les caractéristiques produit à définir avant un PIM complète le projet de recherche par le travail de données dont ses résultats dépendent.
Préserver la compréhension du choix
Le résultat doit montrer les caractéristiques qui justifient sa présence : famille, dimensions ou référence associée selon le besoin. L’utilisateur doit pouvoir vérifier ce qu’il achète. Une réponse rédigée automatiquement peut compléter l’affichage, mais ne doit pas remplacer l’accès aux informations produit. Les termes employés doivent rester cohérents avec la documentation validée.
Le projet doit aussi examiner les droits d’accès aux catalogues et aux conditions commerciales. Un filtre de confort dans l’interface ne doit pas être supposé suffisant pour protéger une information réservée. La séparation des accès doit être mise en œuvre dans les mécanismes prévus par la solution, avec une vérification adaptée. Recherche pertinente et contrôle d’accès répondent à des problèmes distincts.
Le pilote doit enfin observer les demandes reformulées, les recherches sans résultat et les questions envoyées au support. Ces éléments montrent ce qui manque dans les données ou dans l’interface. La valeur de la recherche sémantique réside dans l’aide apportée au choix, avec des contraintes conservées et des incertitudes visibles, plutôt que dans une réponse séduisante à toutes les phrases.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
