Guides pratiques approfondis

Tester la pertinence d’une recherche interne

Construire des requêtes représentatives, vérifier les résultats par langue et améliorer les parcours sans confondre présence d’un moteur et réussite de la recherche.

Mise à jour :

L’utilisateur peut-il trouver le contenu qui répond à son besoin ?

Une recherche interne sert des intentions différentes : retrouver une fiche connue, explorer un sujet ou comprendre quel outil utiliser. Un résultat techniquement renvoyé ne prouve pas que le contenu utile est visible. L’évaluation doit relier la requête à une tâche et vérifier le titre, l’extrait, la destination et la langue. Un petit ensemble de questions bien documentées vaut mieux qu’un score calculé sur des requêtes sans objectif.

  1. Établir un jeu de tâches

    Choisir des contenus importants dans chaque grande famille : guide, fiche, catégorie, outil et dossier. Pour chaque tâche, écrire ce que la personne cherche et les pages qui répondent réellement à ce besoin. Inclure un besoin sans réponse connue pour tester l’absence de résultat.

  2. Varier les formulations pertinentes

    Tester le titre exact, une expression usuelle, un terme métier et une formulation plus courte. Ajouter accents, apostrophes, caractères non latins et abréviations effectivement employées. Les variantes doivent représenter des usages plausibles, pas seulement reproduire les mots choisis par l’équipe éditoriale.

  3. Contrôler chaque langue séparément

    Effectuer les recherches depuis les six interfaces. Vérifier les intitulés de filtres, les extraits, les messages et la langue du lien final. Lorsque le corpus est localisé, un résultat ne doit pas renvoyer sans explication vers une autre version linguistique.

  4. Évaluer le résultat et la destination

    Relever où apparaît la page attendue et si son titre permet de la reconnaître. Ouvrir le résultat puis confirmer que le passage utile existe encore. Un extrait ancien, une fiche supprimée ou une catégorie trop large peuvent tromper même lorsque le classement paraît bon.

  5. Vérifier les états du parcours

    Tester requête vide, aucune réponse, filtre actif, plusieurs pages de résultats et retour arrière. Vérifier la conservation de la requête et de la langue. Parcourir le formulaire au clavier et confirmer que son libellé décrit l’action et que les messages restent compréhensibles.

  6. Corriger la cause puis rejouer

    Distinguer contenu absent, index périmé, terminologie différente, lien incorrect et classement inadéquat. Choisir la correction correspondant au constat. Rejouer le jeu de tâches après reconstruction de l’index pour vérifier le gain et détecter une régression dans une autre famille.

Situations et arbitrages

Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.

La page existe mais n’apparaît pas

Chercher son titre et vérifier si elle figure dans l’index localisé. Si elle manque, corriger l’inclusion ou l’extraction. Si elle est présente, examiner les termes indexés avant d’ajouter une page qui ferait doublon.

Un filtre produit une impasse

Vérifier si le filtre restreint réellement le type demandé et s’il demeure identifiable dans l’état sans résultat. Proposer sa suppression ou une reformulation utile ; ne pas inventer une liste de résultats pour remplir l’écran.

Un résultat change de langue à l’ouverture

Comparer l’URL du résultat avec celle du contenu équivalent. Corriger le paramètre ou le routage, puis tester pagination et retour. Un titre traduit ne suffit pas si la destination réinitialise la langue.

Preuve à conserver

  • Tâche, requête exacte, langue, filtres et pages attendues avec justification.
  • Position observée, extrait, URL ouverte et présence du contenu utile.
  • État sans résultat, parcours clavier et comportement de pagination.
  • Version de l’index, cause identifiée, correction et résultat du nouveau contrôle.

Références officielles

Protocoles connexes

Questions fréquentes

Combien de requêtes faut-il tester ?

Couvrir les principales familles et intentions, puis les cas qui posent réellement problème. Ajouter des requêtes lorsqu’elles révèlent une lacune distincte. Le nombre seul ne prouve pas que le jeu représente les usages.

Faut-il des résultats pour toute requête ?

Non. Une absence honnête avec filtres visibles et pistes pertinentes est préférable à un résultat sans rapport. Examiner ensuite si le besoin justifie un nouveau contenu utile.

Comment mesurer une amélioration ?

Rejouer les mêmes tâches et comparer la réussite, la position de la page utile et les étapes nécessaires. Conserver l’environnement et la version du corpus ; une hausse du nombre de résultats peut masquer une baisse de pertinence.

L’index doit-il tout conserver ?

Indexer les contenus qui servent la recherche et garder les paramètres nécessaires à leur identité. Exclure les erreurs, contenus périmés et états techniques sans valeur documentaire. Vérifier que les mises à jour du corpus déclenchent la reconstruction prévue.