Un client cherche une vanne compatible avec un fluide corrosif. Le menu lui propose « Produits », « Solutions » et « Industries ». La recherche retourne deux cents références contenant le mot vanne, tandis que les facettes mélangent diamètre nominal, diamètre extérieur et unités. Il appelle le support ; celui-ci trouve le produit depuis un ancien code que le site ne connaît pas.
Le problème n’est pas un champ de recherche trop petit. Le site possède plusieurs modèles mentaux sans relation explicite : l’organisation classe par gamme, l’ingénieur par contrainte, l’acheteur par référence et le marketing par marché. Ajouter un moteur plus puissant à des identités et attributs ambigus augmente parfois le nombre de réponses sans rapprocher l’utilisateur de sa décision.
Le vrai enjeu est de transformer une intention en chemin explicable. L’architecture d’information nomme les objets et leurs relations. La navigation offre des parcours prévisibles. Le search interprète une requête, retrouve des candidats et explique les filtres. Les signaux d’usage corrigent vocabulaire et données, pas seulement un score opaque.
Dans une démarche de développement web sur mesure, recherche et navigation forment une capacité produit avec sources, contrats, accessibilité et run. Vous allez voir comment décider ce qui relève de la taxonomie, de l’index, de l’interface ou de la qualité des données avant de changer d’outil.
Partir des intentions et des échecs réels
Rejouer des tâches, pas des pages
Collectez requêtes, tickets, appels et parcours. Classez les intentions : retrouver une référence, explorer une famille, comparer, résoudre un problème, racheter, vérifier une compatibilité ou accéder à un document. La même chaîne peut porter plusieurs intentions ; « filtre » peut désigner un produit, une fonction ou une pièce de maintenance.
Pour chaque échec, notez résultat affiché, données disponibles, reformulations, filtre appliqué et issue. Un zéro résultat peut venir d’un synonyme absent, d’une référence mal normalisée, d’un droit ou d’une offre réellement indisponible. Une sortie rapide peut être un succès si l’utilisateur a trouvé le numéro de téléphone attendu.
Les signaux faibles apparaissent quand les commerciaux conservent des liens favoris, quand le support demande une capture ou quand les utilisateurs copient des codes depuis un PDF. Ces contournements révèlent des identités ou chemins manquants avant que le taux de conversion ne se dégrade visiblement.
Construire une architecture d’information orientée objets
Séparer hiérarchie, relation et point d’entrée
Produit, offre, application, industrie, problème, document et service sont des objets distincts. Une hiérarchie aide à parcourir ; elle ne doit pas porter toutes les relations. Un produit peut appartenir à une gamme, résoudre plusieurs usages et posséder des accessoires. Le modèle conserve ces liens sans dupliquer la fiche dans chaque branche.
Les libellés destinés aux utilisateurs peuvent différer des noms internes. Chaque concept possède un identifiant, des termes préférés, synonymes, langue et période. Les changements de vocabulaire ne cassent pas les URL historiques ni les analytics. Une redirection ou un alias accompagne la fusion.
Le plan de site principal reste peu profond et stable. Les pages d’atterrissage répondent à une intention cohérente, pas à toute combinaison de facettes. La profondeur n’est pas une règle universelle en nombre de clics ; elle se mesure par prévisibilité et réussite des tâches sur la population réelle.
Stabiliser identités, unités et vocabulaire de recherche
Conserver les codes dans des espaces nommés
Une référence ERP, un code fournisseur, un ancien SKU et une désignation client ne sont pas interchangeables. L’index les stocke avec provenance et période. La normalisation gère séparateurs, casse et espaces sans fusionner deux codes légitimes. Une correspondance ambiguë retourne plusieurs résultats qualifiés.
Les attributs portent type et unité. Un diamètre de 25 mm ne devient pas la chaîne « 25 ». Les intervalles et valeurs inconnues restent explicites. Les facettes ne comparent que des valeurs compatibles. Une conversion affichée conserve la valeur source afin que le support explique l’écart.
Les synonymes sont possédés par domaine et langue. Ils ne servent pas à cacher une taxonomie défaillante. Un terme peut élargir la recherche, mais un antonyme ou un composant incompatible ne doit pas entrer par proximité lexicale. Les règles sont testées sur requêtes positives et contre-exemples.
Concevoir des chemins complémentaires et persistants
Donner un repère avant d’ajouter un menu
La navigation globale expose les espaces stables. La navigation locale situe dans une famille. Le fil d’Ariane explique un chemin, sans prétendre représenter toutes les relations. Les liens contextuels relient accessoires, alternatives, documents et usages. Chaque mécanisme a une fonction ; les empiler sans hiérarchie visuelle augmente le bruit.
L’URL conserve l’état partageable : requête, filtres déterminants, tri et page. Retour arrière et ouverture dans un nouvel onglet doivent retrouver le contexte. Les paramètres ont une canonical et une politique d’indexation décidées. Un filtre client ou un droit sensible ne se place pas dans une URL publique.
Sur mobile, la navigation ne cache pas les catégories derrière plusieurs gestes sans retour clair. Le focus suit l’ouverture et la fermeture. Les zones tactiles, libellés et états sont testés au clavier et avec lecteurs d’écran. Une méga-navigation n’est utile que si ses groupes restent compréhensibles.
Fermer le contrat du moteur de recherche
Distinguer rappel, précision et règle commerciale
Le moteur reçoit requête, locale, contexte autorisé et filtres. Il retourne résultats, score explicable au diagnostic, facettes, corrections et version d’index. Le classement combine correspondance textuelle, champs, popularité qualifiée et disponibilité. Une campagne commerciale reste une règle séparée et visible.
La tolérance aux fautes aide sur les mots, mais elle peut être dangereuse sur les références. Les codes exacts bénéficient d’un chemin dédié. Les requêtes courtes ou ambiguës proposent catégories et suggestions plutôt qu’un classement arbitraire. Les termes sensibles conservent des règles explicites.
Contre-intuitivement, augmenter le rappel peut dégrader le produit. Retourner cinq cents références proches donne l’illusion de couverture tout en transférant le travail à l’utilisateur. Le moteur doit assumer « aucun produit compatible » et proposer une action, plutôt que masquer l’incertitude par la quantité.
Rendre facettes, filtres et URL cohérents
Afficher uniquement des choix qui ont un sens
Une facette correspond à un attribut compris et utile dans la famille. Les valeurs sont regroupées avec unités et ordre métier. Le nombre associé reflète le contexte courant. Une facette indisponible peut disparaître ou rester désactivée avec explication ; elle ne propose pas un chemin systématiquement vide.
Les dépendances entre facettes sont explicites. Choisir un type de raccord peut limiter matières et diamètres. Le backend calcule le domaine valide ; le frontend ne recrée pas les compatibilités. Une sélection devenue impossible après un autre filtre est retirée avec annonce et possibilité d’annuler.
Les URL de facettes sont normalisées afin que l’ordre des paramètres ne crée pas des milliers de variantes. La page conserve un titre et un contenu adaptés seulement pour les combinaisons réellement éditorialisées. Le reste sert l’utilisateur sans multiplier des pages d’indexation faibles.
Traiter zéro résultat, contenu absent et données faibles
Transformer l’échec en information
Le zéro résultat affiche la requête comprise, les filtres actifs et des actions : retirer un filtre, corriger une référence, parcourir une catégorie ou contacter un expert. Il ne remplace pas la requête silencieusement. Le journal distingue zéro véritable, défaut d’index et droit insuffisant.
Les contenus sans attribut requis entrent dans un rapport de qualité. Le moteur n’invente pas une valeur. Une fiche peut rester accessible par référence tout en étant exclue d’une facette impossible. La correction revient au PIM ou au propriétaire, avec identifiant et motif.
Une recherche sans résultat récurrente peut révéler une demande non couverte ou un vocabulaire absent. Produit et contenu la qualifient. La correction peut être un synonyme, une page conseil, une nouvelle offre ou une décision de ne pas servir ce besoin. Le moteur ne décide pas seul.
Cas concret : catalogue industriel multi-références
Construire le modèle cible
Cas concret. Un fabricant publie trente mille produits, cent vingt mille documents et des références historiques issues de trois ERP. Les clients cherchent par code, application et contrainte. L’ancien moteur indexe les PDF comme les fiches et mélange unités, ce qui place souvent une notice avant le produit.
La cible crée des objets produit, offre, document et application. Elle normalise les références sans les fusionner, type les unités et ajoute des relations de remplacement. Une recherche exacte de code privilégie l’objet correspondant. Une requête descriptive combine champs, synonymes possédés et facettes valides.
Fixer les critères du pilote
Par exemple, si le pilote couvre cinq familles, deux cents requêtes et vingt clients, alors le seuil d’ouverture reste local : aucune référence exacte derrière une correspondance floue, aucune facette mélangeant deux unités et aucun document d’un autre compte. Une requête ambiguë doit proposer une clarification plutôt qu’une certitude.
Le go est suspendu si plus d’un résultat critique ne peut être expliqué, si le support corrige l’index directement ou si le retour arrière perd les filtres. Ces critères commandent une action sur donnée, modèle ou interface ; ils ne promettent pas un taux universel de zéro résultat.
Sur ce lot hypothétique, si trois requêtes exactes échouent après une reconstruction, alors la famille reste fermée et les mappings sont comparés avant tout réglage de pertinence. Si dix zéros récurrents correspondent à une offre absente, le produit décide d’abord s’il faut la créer ou expliquer son absence ; le moteur ne reçoit pas un synonyme artificiel.
Implémenter index, API et composants accessibles
Fermer pipeline et contrats
Le pipeline reçoit objets versionnés depuis leurs autorités, valide identités et unités, puis produit un document d’index. Les entrées, sorties, responsabilités et dépendances sont contractualisées. Un événement transporte identifiant et version ; retry et file de rejet préservent l’idempotence. La reconstruction complète reste testée.
L’API reçoit requête, filtres, contexte et pagination ; elle retourne résultats, facettes, suggestions, version et corrélation. La journalisation minimise les données personnelles. Le monitoring suit âge d’index, rejets, latence, zéros anormaux et codes inconnus. Le rollback revient à une version d’index sans réécrire les sources.
Construire l’interface comme un état partageable
Le formulaire de recherche utilise des contrôles natifs lorsque possible. Les suggestions suivent un patron clavier testé ; les pratiques WAI-ARIA pour les combobox décrivent rôles et interactions, sans dispenser des tests avec les technologies d’assistance réelles.
Le rendu serveur fournit le premier résultat et une URL stable ; le client enrichit les facettes. Les chargements annoncent l’état sans déplacer le focus arbitrairement. Une réponse ancienne ne remplace pas une requête récente : identifiant ou annulation protège l’ordre.
Mesurer la réussite des tâches et la qualité du système
Relier requête, action et résultat
Les indicateurs incluent réussite de tâche, reformulation, filtres retirés, zéro résultat qualifié, clic utile, abandon et contact support. Un clic n’est pas toujours un succès ; l’utilisateur peut revenir immédiatement. La mesure suit des cohortes et intentions, pas seulement un taux global.
La qualité technique couvre fraîcheur, latence, erreurs, couverture des attributs et stabilité des URL. La qualité métier examine références exactes, produits critiques et compatibilités. Les jeux de requêtes dorés proviennent de cas réels et sont révisés lorsque l’offre change.
Les données de recherche peuvent contenir des informations sensibles. La collecte est minimisée, les accès bornés et la rétention décidée. Une requête authentifiée ne doit pas devenir un exemple partagé sans contrôle. Le dashboard privilégie agrégats et cas anonymisés.
Pour qui cette méthode search et navigation est utile
Associer produit, contenu, data et support
Elle concerne catalogues volumineux, bases documentaires, marketplaces, portails et sites multi-audiences. Produit, SEO, contenu, data, experts métier, support et frontend participent. L’équipe moteur ne peut pas résoudre seule une unité ou une compatibilité sans propriétaire.
Un site de quelques pages peut rester sur une navigation éditoriale simple. Un moteur devient pertinent quand plusieurs chemins, volumes ou vocabulaires coexistent. La sophistication suit la diversité des intentions, pas uniquement le nombre de documents.
Une recherche externe peut compléter l’accès public, mais elle ne remplace pas une recherche interne pour les données privées, filtres métier ou actions. La frontière dépend de la promesse et de la maîtrise des données.
Éviter les erreurs fréquentes
Changer de moteur avant de corriger les objets
Un nouvel algorithme ne type pas les unités et ne crée pas les relations. Stabilisez identités, attributs et ownership ; comparez ensuite les moteurs sur un jeu réel.
Utiliser les synonymes comme rattrapage universel
Les rapprochements finissent par produire du bruit. Possédez chaque règle, ajoutez un contre-exemple et retirez les synonymes qui détériorent une intention voisine.
Mesurer uniquement le clic
Un résultat trompeur reçoit aussi un clic. Reliez navigation, retour, action et support. Mesurez une tâche comprise, pas une interaction isolée.
Créer une URL pour chaque combinaison
Les facettes explosent les variantes et diluent le contenu. Normalisez les paramètres, choisissez les pages utiles et gardez les autres combinaisons fonctionnelles sans les traiter comme landings.
Arbitrage : navigation, moteur ou parcours guidé
Bloc de décision. Utilisez la navigation pour explorer des espaces stables. Utilisez le search pour une intention formulable et un corpus indexable. Ajoutez un parcours guidé lorsque l’utilisateur connaît son problème mais pas les attributs. Combinez-les avec des identités communes plutôt que trois taxonomies.
Priorisez référence exacte, droits, unités et zéro résultat avant le ranking sophistiqué. Différez une facette sans données fiables. Refusez un boost commercial qui masque son motif. Conservez un contact expert pour les compatibilités non déterministes.
- Nommer les intentions et objets.
- Tester les requêtes exactes et ambiguës.
- Conserver l’état partageable dans l’URL.
- Décider l’extension depuis la réussite des tâches.
Plan d’action sur dix semaines
Semaines 1 à 3 : observer et modéliser
Prélevez deux cents requêtes, trente tickets et vingt parcours. Classez intentions, objets, termes et issues. Cartographiez codes, unités, taxonomies et propriétaires. Mesurez zéros, reformulations et corrections. Définissez les seuils locaux et les produits critiques avant de toucher au ranking.
Construisez un jeu d’acceptation avec au moins une requête exacte, une requête métier, une faute, une ambiguïté et un zéro légitime par famille. Le seuil de publication est décidé avec le métier : si un produit critique sort des cinq premières réponses du pilote, alors bloquez l’index et faites qualifier la cause entre donnée, mapping, analyse linguistique ou règle commerciale.
Semaines 4 à 7 : construire une tranche
Stabilisez cinq familles, leurs identités et facettes. Créez le pipeline versionné, l’API et l’interface partageable. Exécutez le nouvel index en observation. Comparez les requêtes dorées à l’existant et faites qualifier les différences par l’expert métier.
Provoquez événement hors ordre, attribut absent, unité incohérente, code exact, requête ambiguë, index ancien et réponse tardive. Testez clavier, lecteur d’écran, retour arrière et mobile. Le support explique chaque résultat critique depuis la corrélation.
Semaines 8 à 10 : ouvrir et gouverner
Ouvrez cinq familles et vingt clients. Surveillez tâches, zéros, filtres, erreurs et charge support. Jouez rollback d’index et reconstruction. Étendez lorsque la période couvre les requêtes représentatives et que les propriétaires corrigent les rejets sans accès direct.
La revue ferme d’abord références exactes, droits et unités ; ensuite les zéros fréquents ; puis la pertinence longue traîne. Chaque synonyme, boost et facette reçoit owner, preuve et date de révision avant la prochaine tranche.
Enfin, comparez les vingt recherches les plus coûteuses pour le support avant et après ouverture. Une baisse de clics ne suffit pas : chaque dossier doit montrer une tâche terminée, un abandon compris ou une transmission mieux qualifiée. Si deux corrections manuelles restent nécessaires pour la même requête, alors retirez le réglage et revenez au dernier index prouvé.
- Partir des tâches et contournements.
- Fermer objets, vocabulaire et unités.
- Comparer en observation sur des requêtes dorées.
- Ouvrir par famille avec rollback et gouvernance.
Approfondir rendu, contenu et composants
Le guide des stratégies de rendu aide à servir le premier résultat et les facettes. Le guide des composants front précise les contrats des filtres et suggestions.
Le guide marketing, contenu et logique métier complète la gouvernance des pages d’atterrissage. Ces lectures doivent partir du corpus et des requêtes réels.
- Relier chaque résultat à un objet et une version d’index.
- Tester référence exacte, zéro résultat et filtre invalide.
- Reconstruire l’index avant d’élargir une taxonomie.
Conclusion : rendre chaque chemin explicable
Une bonne recherche ne commence pas par un algorithme. Elle commence par des objets identifiables, des attributs typés et des intentions comprises. La navigation structure l’exploration ; le moteur interprète une requête ; les facettes réduisent un domaine valide.
Le zéro résultat, la requête ambiguë et l’index ancien font partie du produit. Les traiter honnêtement évite de noyer l’utilisateur sous des réponses proches. Les mesures relient les signaux à une tâche et à une correction possédée.
Le test final est simple : le client et le support comprennent pourquoi ce résultat apparaît, pourquoi un filtre est disponible et quelle action reste possible. Si l’explication dépend d’un score opaque et d’un PDF parallèle, l’architecture d’information reste incomplète.
Dawap peut vous accompagner pour structurer cette capacité dans une démarche de développement web sur mesure : audit des requêtes, taxonomie, modèle d’index, API, composants accessibles, mesure de pertinence, migration et préparation du run.
