Concevoir une recherche interne qui aide vraiment à trouver

Vérifier que la recherche répond à un vrai besoin

Sur un petit site, une navigation claire et quelques filtres peuvent suffire. La recherche devient pertinente lorsque le volume, la variété ou les termes employés par le public rendent le repérage difficile. Recueillez des exemples de questions réelles avant de choisir un outil.

Décidez ce qui sera recherché : produits, articles, ressources, pages services ou documents. Distinguez les contenus publics des éléments privés. Un moteur qui interroge tout sans préciser son périmètre renvoie souvent des résultats inutiles et peut exposer des titres qui ne devraient pas apparaître.

• Dix requêtes issues d’usages réels.
• Types de contenus inclus et exclus.
• Chemin de navigation conservé sans recherche.

Préparer les données et le vocabulaire

Chaque résultat a besoin d’un titre distinct, d’un résumé fidèle, d’une URL stable et, si utile, d’une catégorie. Corrigez les pages sans titre parlant avant de régler le classement. Notez les synonymes que les visiteurs utilisent réellement, y compris les termes courants différents du vocabulaire interne.

Définissez le traitement des fautes, accents, pluriels et variantes avec des exemples vérifiables. Une équivalence trop large peut masquer le bon résultat. Testez les termes ambigus dans plusieurs familles de contenus au lieu de promettre qu’un moteur « comprend » toute intention.

• Titres et extraits distinctifs.
• Liste courte de synonymes validés.
• Cas d’ambiguïté à tester.

Rendre le formulaire et les résultats compréhensibles

Le champ doit avoir un libellé accessible, une action d’envoi claire et fonctionner au clavier. Affichez la requête exécutée et le nombre de résultats sans laisser croire qu’un tri approximatif est une réponse exacte. Une carte doit expliquer pourquoi elle correspond : titre, type, court extrait et date si la fraîcheur compte.

Si des filtres sont utiles, indiquez les critères actifs et permettez de les retirer facilement. Testez la pagination, l’historique du navigateur et l’affichage sur téléphone. Les recommandations du W3C sur les formulaires accessibles s’appliquent aussi à la zone de saisie d’une recherche.

Testez la valeur reçue, pas seulement l’aspect de la barre d’adresse. Dans cet exercice, URLSearchParams décode q=C%2B%2B en C++, mais q=C++ en la lettre C suivie de deux espaces U+0020. Le signe plus brut représente un espace dans ce format de paramètres ; %2B représente le caractère plus. Construisez les couples nom et valeur avec l’API plutôt qu’en concaténant la saisie. Vérifiez ensuite le résultat reçu par le serveur, dont le parseur peut suivre un autre contrat.

Conservez les distinctions qui changent la tâche. Avec tag=seo&tag=design, getAll lit deux valeurs dans leur ordre ; get ne renvoie que la première. Un paramètre q= est présent et vide, tandis qu’un paramètre absent donne null avec get. Décidez explicitement si ces états ont le même effet dans votre moteur. L’API ne définit ni les synonymes, ni la logique des filtres, ni la pertinence des résultats. Rechargez le lien et utilisez le retour arrière pour contrôler la restitution des critères.

• Libellé de recherche explicite.
• Résultats compréhensibles sans image.
• Filtres et retour arrière vérifiés.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

Prévoir zéro résultat et les erreurs

Une page vide ne doit pas être la fin du parcours. Répétez la requête, proposez de vérifier l’orthographe, d’enlever un filtre ou de parcourir des catégories pertinentes. Ne fabriquez pas de résultats hors sujet pour éviter d’afficher zéro. Si le moteur échoue, dites qu’il est momentanément indisponible et gardez une autre voie de navigation.

Testez aussi une requête vide, très longue, avec ponctuation et avec caractères propres aux langues publiées. Dans une version multilingue, confirmez la langue effectivement interrogée et évitez de mélanger des résultats non traduits sans l’indiquer.

• État vide avec pistes concrètes.
• Erreur technique distincte de zéro résultat.
• Tests dans chaque langue servie.

Observer les requêtes pour améliorer le site

Regardez les recherches fréquentes, celles sans résultat et celles qui mènent à une sortie immédiate. Elles peuvent révéler un contenu absent, un titre incompréhensible ou une navigation insuffisante. Conservez seulement les données nécessaires selon la politique de mesure applicable à votre site.

Évaluez les corrections par tâche : la personne trouve-t-elle la bonne page et peut-elle agir ensuite ? Corrigez d’abord les données et la présentation avant d’ajouter des réglages complexes. Le guide de mesure aide à relier ces observations à une décision.

• Requêtes sans résultat revues.
• Pages manquantes ou mal nommées identifiées.
• Test de tâche après correction.

Vérifier les suggestions et les réponses en retard

Si la recherche propose des suggestions, contrôlez le passage entre texte libre et valeur choisie. Lancez deux saisies rapprochées avec des réponses retardées : les résultats de la première ne doivent pas remplacer ceux de la seconde. Le bilan annoncé doit correspondre à la dernière requête appliquée.

Une recherche vide, une recherche sans correspondance et une panne ne demandent pas le même message. Pour chaque état, préparez une suite utile : préciser un terme, retirer un filtre ou reprendre le chargement. Une annonce de résultat ne doit pas déplacer automatiquement la personne loin de la commande qu’elle ajuste.

Concevoir une autocomplétion pour choisir une valeur · Rédiger et annoncer les messages d’état d’une interface · Choisir les liens, boutons et actions d’une interface

Tester une recherche sans jargon

Cas proposé : un visiteur cherche « changer d’adresse », tandis que la page porte un terme administratif. Une correspondance technique parfaite peut laisser la tâche introuvable.

Préparez des requêtes formulées par le public et examinez résultats, titres et absence de réponse. Documentez synonymes et destination utile ; ajouter des mots ne dispense pas d’observer le classement.

• Relever les mots du public
• Vérifier la destination proposée
• Tester une requête sans résultat

• Conserver le sens des filtres

  Concevoir des filtres utiles pour un catalogue ou un annuaire

Établir un petit jeu de résultats attendus pour la recherche

Catalogue fictif : A = guide « Sécurité d’un site web », B = service « Création de site web », C = guide « Préparer une page contact ». Règles choisies pour cet exercice : ignorer casse et accents, chercher tous les mots dans le titre et appliquer les filtres en plus du texte. Ces règles ne décrivent pas tous les moteurs.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• W3C WAI · ARIA22

  Après chaque changement appliqué, le bilan doit décrire la liste courante. La technique ARIA22 du W3C illustre une annonce de statut sans déplacement du focus ; elle ne définit pas l’algorithme de recherche.