Comment ajouter une recherche à votre application : des filtres simples à la recherche plein texte

Pour ajouter une recherche à votre app, commencez par la solution la plus simple qui fonctionne : une zone de recherche qui appelle une route serveur, laquelle filtre les lignes de la base de données en comparant la requête à quelques colonnes, avec des filtres pour des éléments comme la catégorie ou le prix. Lorsque cela ne suffit plus — par exemple si vous avez besoin de classer les résultats par pertinence, de la racinisation des mots ou de nombreux enregistrements — passez à la recherche plein texte de votre base de données, et n'optez pour un moteur de recherche hébergé que si vous avez besoin d'une forte tolérance aux fautes de frappe ou de résultats instantanés sur de très grands volumes. Quelle que soit votre option, la recherche doit respecter les permissions : les utilisateurs ne doivent jamais trouver des enregistrements auxquels ils n'ont pas le droit d'accéder.

Ce que « recherche » signifie pour votre app

La recherche recouvre plusieurs choses différentes, et la plupart des apps en ont besoin de plus d'une :

Recherche par mots-clés : une zone de texte — « trouver les annonces qui mentionnent “jardin” ».
Filtres : des choix structurés — catégorie, ville, fourchette de prix, date, statut.
Tri : les plus récents, les moins chers, les plus pertinents.
Complétion automatique : des suggestions pendant la saisie.
Tolérance aux fautes de frappe : « restuarant » trouve quand même « restaurant ».

Pour un répertoire, un site d'offres d'emploi ou une boutique, les filtres comptent souvent plus que la zone de texte. Décidez de ce dont vous avez vraiment besoin avant de choisir un outil.

Vos options

Approche	Fonctionnement	Idéal pour	Limites
Filtrer dans le navigateur	Charger la liste, la filtrer en JavaScript	Petites listes publiques (quelques centaines d'éléments)	Envoie toutes les données à chaque visiteur; lent avec de grandes listes
Correspondance de motif dans la base de données	Requête serveur du type « le nom contient le texte », sans tenir compte de la casse	Petites et moyennes apps, outils d'administration	Aucun classement; peut être lent sur de grandes tables; pas de racinisation
Recherche plein texte dans la base de données	Postgres indexe les mots et classe les résultats	La plupart des apps riches en contenu	Faible face aux fautes de frappe, sauf si vous ajoutez une correspondance floue
Correspondance floue (trigrammes)	Postgres compare des séquences de caractères pour mesurer la similarité	Noms, champs courts, tolérance aux fautes de frappe	Nécessite une extension et un index; un réglage est nécessaire
Moteur de recherche hébergé	Un service distinct indexe vos données (Algolia, Meilisearch, Typesense, Elasticsearch et d'autres)	Grands catalogues, recherche instantanée, forte tolérance aux fautes	Un autre service à synchroniser, à payer et à sécuriser

Si vos données se trouvent déjà dans Postgres, sa recherche plein texte intégrée est un bon compromis. Elle découpe le texte en mots, les réduit à leur racine (de sorte que « courir » correspond à « cours »), ignore les mots courants et peut classer les résultats selon leur degré de correspondance. Avec le bon index, elle reste rapide sur de grandes tables.

Exemples de requêtes

Un départ simple :

Ajoute une zone de recherche et des filtres à la page des annonces. La recherche doit comparer la requête au titre et à la description, sans tenir compte de la casse. Filtres : catégorie (liste déroulante), ville (liste déroulante) et prix maximum. Fais la recherche sur le serveur avec une route d'API paginée, 20 résultats par page. Conserve la recherche et les filtres dans l'URL pour que les résultats puissent être partagés et que le bouton Retour fonctionne. Affiche un message clair lorsqu'aucun résultat ne correspond.

Passer à la recherche plein texte :

Remplace la recherche des annonces par la recherche plein texte de Postgres sur le titre (pondéré davantage) et la description. Ajoute le bon index, classe les résultats par pertinence, et conserve les filtres et la pagination existants. Ne modifie aucune donnée existante.

Ajouter la tolérance aux fautes de frappe pour les noms :

Ajoute une correspondance floue sur le nom de l'entreprise pour que de petites fautes de frappe trouvent quand même des résultats. Utilise la similarité par trigrammes si elle est disponible, avec un index, et reviens à la recherche actuelle si elle ne l'est pas.

Étape par étape

Listez ce que les gens recherchent. Quels champs (titre, description, étiquettes, nom)? Quels filtres? Parlez à quelques utilisateurs réels si vous le pouvez.
Commencez côté serveur. Ajoutez une route d'API qui reçoit la requête et les filtres, et renvoie une page de résultats. Ne chargez pas tout dans le navigateur.
Appliquez les permissions dans la requête. Si les utilisateurs ne voient que leurs propres enregistrements, ou seulement ceux qui sont publiés, cette condition doit faire partie de la même requête que la recherche.
Ajoutez la pagination dès le début — numéros de page ou « charger plus ».
Conservez l'état de la recherche dans l'URL (par exemple ?q=jardin&city=leeds). Les liens partageables, le bouton Retour qui fonctionne et les moteurs de recherche peuvent explorer les pages filtrées si vous le souhaitez.
Temporisez la recherche pendant la saisie. Attendez quelques centaines de millisecondes après la dernière frappe avant d'interroger, pour ne pas envoyer une requête à chaque touche.
Ajoutez des index une fois que vous savez sur quelles colonnes vous filtrez et recherchez.
Améliorez la recherche : plein texte, puis correspondance floue, puis moteur hébergé — seulement lorsque l'étape plus simple échoue auprès de vrais utilisateurs.
Testez avec des données réalistes : des centaines ou des milliers de lignes, caractères inhabituels, requêtes vides, requêtes très longues, d'autres langues si vous en prenez en charge.

Erreurs courantes

Charger toute la table dans le navigateur. Acceptable pour 50 éléments, pénible pour 50 000, et cela expose chaque enregistrement — y compris ceux que l'utilisateur ne devrait pas voir.
Une recherche qui ignore les permissions. La recherche est une fuite courante : un enregistrement privé ou un brouillon apparaît parce que la requête a oublié la condition « seulement les miens » ou « seulement les publiés ».
Construire du SQL à partir de données saisies brutes. Utilisez toujours des requêtes paramétrées. Un outil de création par IA le fait normalement, mais vérifiez si vous voyez des chaînes collées bout à bout.
Aucun état vide. Un « aucun résultat » accompagné d'une suggestion (effacer les filtres, vérifier l'orthographe) évite que les gens partent.
Aucun index. La recherche semble correcte avec des données de test et ralentit à mesure que les données réelles s'accumulent.
Passer directement à un service de recherche. Vous devez alors garder une seconde copie de vos données synchronisée, gérer les suppressions et sécuriser un autre ensemble de clés — souvent sans gain visible.
Oublier le mobile. Les filtres doivent tenir sur un téléphone; un tiroir de filtres ou un panneau repliable fonctionne généralement mieux qu'une barre latérale.

Liste de contrôle

Vous savez quels champs sont recherchés et quels filtres existent
La recherche s'exécute sur le serveur et renvoie des résultats paginés
La requête applique les mêmes permissions que le reste de l'app
Les données saisies par l'utilisateur sont transmises comme paramètres, jamais collées dans du SQL
L'état de la recherche se trouve dans l'URL
La saisie est temporisée
Les colonnes recherchées et filtrées sont indexées
Les états vides, sans résultat et d'erreur sont clairs
Testé avec des volumes de données réalistes et des saisies désordonnées

Ajouter une recherche avec Mythex

Dans une app créée avec Mythex, les données se trouvent en général dans la base de données Postgres du projet; vous pouvez donc commencer avec les requêtes ci-dessus : d'abord la correspondance de motifs, puis la recherche plein texte de Postgres lorsque vous avez besoin du classement. Si vous voulez un moteur de recherche hébergé, apportez votre propre compte et votre propre clé, stockez-la comme secret du projet, et demandez à l'agent d'indexer et d'interroger ce service depuis le serveur, comme décrit dans Intégrer n'importe quelle API.

La recherche est au cœur de nombreuses apps : consultez comment créer un site de répertoire, comment créer un site d'offres d'emploi et comment créer une place de marché pour voir comment elle s'intègre au reste du produit.

Questions

Quel est le moyen le plus facile d'ajouter une recherche à une app?

Si vos données sont dans une base de données, une route serveur qui filtre les lignes par une correspondance insensible à la casse sur quelques colonnes est le point de départ le plus simple. Pour une petite liste déjà chargée dans le navigateur, filtrer directement dans le navigateur est encore plus simple.

Ai-je besoin d'Algolia ou d'Elasticsearch pour la recherche?

En général, pas au début. La recherche plein texte de Postgres gère très bien la correspondance des mots, le classement et de milliers à des millions de lignes. Un moteur de recherche hébergé vaut la peine lorsque vous avez besoin d'une forte tolérance aux fautes de frappe, de résultats instantanés pendant la saisie sur de grands volumes de données, ou d'un réglage avancé de la pertinence.

Pourquoi ma recherche ne trouve-t-elle pas de résultats lorsqu'il y a une faute de frappe?

La correspondance de base et la recherche plein texte standard cherchent les mots tels qu'ils sont tapés (ou leurs racines), donc une faute de frappe échoue. Il faut une correspondance floue, comme la similarité par trigrammes dans Postgres, ou un moteur de recherche qui tolère les fautes de frappe.

La recherche doit-elle se faire dans le navigateur ou sur le serveur?

Sur le serveur, pour tout ce qui dépasse une petite liste publique. La recherche côté serveur passe à l'échelle, respecte les permissions et n'envoie pas l'ensemble de vos données à chaque visiteur.