Une personne saisit le nom d’un service, clique sur « Rechercher » et se retrouve devant un écran vide. En théorie, la recherche est terminée. En pratique, le dialogue avec le site s’est interrompu au moment précis où cette personne a exprimé son intérêt le plus clairement. Nous proposons de concevoir ce moment non comme une erreur de l’utilisateur, mais comme un scénario à part entière : que comprendra la personne et que pourra-t-elle faire ensuite ?
Définissez d’abord où le site effectue réellement la recherche
Un champ accompagné d’une loupe promet souvent plus qu’il ne permet. S’il ne parcourt que les titres des articles, et non les services, les documents et le texte intégral des pages, cela doit être indiqué clairement à côté du champ. « Rechercher dans le journal » est plus précis qu’un simple « Rechercher » lorsque les autres contenus ne font pas partie du périmètre. Pour un petit site, des archives d’articles bien organisées sont parfois plus utiles qu’un formulaire complexe qui masque ses limites.
Avant le développement, rassemblez quelques requêtes courantes : un titre exact, un sujet général, une autre orthographe et un mot absent du site. Déterminez quels contenus doivent apparaître dans chaque cas. Il s’agit d’un accord éditorial, pas d’une promesse selon laquelle l’algorithme devinera toutes les intentions.
Conservez la requête et distinguez les différents états
Après la recherche, le texte devrait rester dans le champ. La personne peut ainsi modifier un seul mot au lieu de tout saisir à nouveau. Une requête vide, un chargement en cours, une absence de correspondances et une erreur technique nécessitent des messages différents. « Aucun résultat » ne doit pas masquer un serveur indisponible : dans cette situation, nous ne savons pas encore si des résultats existent.
Pour une recherche avec des filtres, affichez les restrictions actives. L’absence de contenus dans la catégorie sélectionnée ne signifie pas qu’il n’y en a aucun sur l’ensemble du site. Proposez une action distincte « Réinitialiser les filtres » qui n’efface pas le texte saisi. La personne comprend ainsi exactement ce qui changera après le clic.
Proposez quelques pistes honnêtes plutôt qu’un mur de conseils
Un état vide concis peut contenir la requête elle-même, une explication du périmètre de recherche et deux étapes possibles : reformuler la requête ou ouvrir une rubrique thématique. Inutile d’afficher immédiatement des dizaines de cartes choisies au hasard. Si vous proposez des sujets proches, présentez-les comme des recommandations et non comme des correspondances exactes.
Prenons un exemple hypothétique pour un studio : le mot « relancement » ne donne aucun résultat, mais des rubriques sur la maintenance et la mise à jour d’un site sont disponibles. Vous pouvez les proposer comme un autre chemin, sans remplacer la réponse ni présenter comme trouvé un contenu qui ne correspond pas à la requête. Les intitulés des liens doivent expliquer le contenu de leur destination, comme nous le décrivons dans notre article sur les liens explicites.
Un champ de saisie n’est pas un moteur de recherche prêt à l’emploi
MDN décrit input type="search" comme un champ destiné à la saisie d’une requête de recherche. Le type de champ ne crée pas à lui seul un index et ne détermine pas comment associer les mots aux contenus. Cette logique doit être mise en œuvre séparément. Le champ a également besoin d’un intitulé clair : un exemple affiché à l’intérieur du champ vide ne devrait pas être la seule explication de sa fonction.
Si les résultats sont actualisés sans rechargement de la page, un court message indiquant leur nombre ou leur absence doit être accessible aux technologies d’assistance, sans déplacement forcé du focus. C’est précisément ce type de message que le W3C aborde dans son explication du critère de succès 4.1.3. Cela ne signifie pas que toute la liste des résultats doit être annoncée comme un seul message.
Vérifiez le parcours, pas seulement la présence d’une loupe
Testez le scénario sur un écran étroit et au clavier : saisissez une requête, lancez la recherche, corrigez-la, réinitialisez un filtre, ouvrez un résultat et revenez en arrière. Assurez-vous que les boutons ne disparaissent pas derrière le clavier à l’écran, que les titres longs ne recouvrent pas les éléments voisins et que les messages ne se déplacent pas sous les yeux à chaque caractère saisi.
Testez séparément les requêtes dans les différentes langues du site et ne masquez pas les limites entre les sections linguistiques. Une bonne recherche n’a pas à tout deviner. Son intérêt concret est de permettre à la personne de voir les limites de la réponse, de ne pas perdre ce qu’elle a déjà fait et de disposer d’une prochaine étape claire, même sans aucun résultat.