# Présentation de la recherche La recherche Sovrium **n'est pas un domaine de fonctionnalité autonome**. Elle étend les schémas que vous utilisez déjà : les tables déclarent _ce qui_ est cherchable (pondérations de champs, indexation), et les composants de page déclarent _comment_ la recherche se comporte (moteur, anti-rebond, surlignage, affichage des résultats). Il n'y a pas de configuration `app.search` de premier niveau — la configuration vit là où elle est utilisée. Le backend est entièrement bâti sur PostgreSQL : la recherche plein texte (`tsvector`/`tsquery`) plus l'extension `pg_trgm` pour une correspondance floue, tolérante aux fautes de frappe. Pas d'Elasticsearch, pas d'Algolia, pas de service externe — la recherche reste à l'intérieur de votre propre base de données, conformément au principe de souveraineté numérique de Sovrium. :::callout Deux couches de recherche distinctes existent. La **recherche d'enregistrements** (cette page) interroge les données de table via le mode de source de données `search` et les quatre moteurs ci-dessous. La **recherche de pages publiques** indexe le _contenu_ des pages statiques via le composant `pageSearch` — voir [search-components](/fr/docs/search-components#pagesearch). Ce sont des fonctionnalités différentes à des couches différentes. ::: ## Moteurs de recherche Une source de données en `mode: 'search'` sélectionne son backend avec `searchEngine`. La même table peut utiliser des moteurs différents sur des pages différentes. | Moteur | Où il s'exécute | Idéal pour | | --------- | ------------------------ | ------------------------------------------------------------------------------------------------- | | `client` | JavaScript du navigateur | Petits jeux de données déjà chargés dans la page ; instantané, sans aller-retour. **Par défaut.** | | `fts` | FTS PostgreSQL | Pertinence classée côté serveur sur du texte indexé ; grands jeux de données. | | `trigram` | `pg_trgm` PostgreSQL | Correspondance floue et tolérance aux fautes de frappe ; requêtes partielles/mal orthographiées. | | `hybrid` | FTS PostgreSQL + trigram | FTS pour la pertinence avec un repli flou trigram ; le meilleur des deux. | ### `client` — filtrage dans le navigateur Filtrage JavaScript dans le navigateur. Les enregistrements sont déjà récupérés, et la requête les restreint en mémoire. Aucun aller-retour serveur, mais l'ensemble du jeu de résultats doit tenir dans la page. À utiliser pour les petites listes de référence et les sélecteurs. ```yaml - type: data-table dataSource: table: products mode: search searchFields: [name, description] searchEngine: client debounceMs: 300 ``` ### `fts` — recherche plein texte PostgreSQL Recherche classée côté serveur utilisant `tsvector`/`tsquery`. Les résultats reviennent triés par pertinence, pondérés par le [`searchWeight`](/fr/docs/full-text-search#field-relevance-weights) de chaque champ. Requiert que les champs cherchés soient `indexed: true`. À utiliser pour les grands jeux de données riches en texte où le classement importe. ```yaml - type: data-table dataSource: table: articles mode: search searchFields: [title, body] searchEngine: fts debounceMs: 300 limit: 20 ``` ### `trigram` — correspondance floue Utilise l'extension `pg_trgm` pour faire correspondre les trigrammes de caractères, tolérant les fautes de frappe et les mots partiels. Idéal quand les utilisateurs font des fautes ou tapent des fragments (par ex. `prodct` correspond toujours à `product`). Voir [full-text-search](/fr/docs/full-text-search#trigram-fuzzy-matching) pour les détails d'indexation. ```yaml - type: data-table dataSource: table: products mode: search searchFields: [name] searchEngine: trigram ``` ### `hybrid` — pertinence plus tolérance Combine le FTS pour le classement par pertinence avec le trigram comme repli flou, de sorte que les correspondances exactes et classées remontent en premier tandis que les requêtes mal orthographiées renvoient quand même des résultats. Le moteur le plus indulgent pour la recherche destinée à l'utilisateur final. ```yaml - type: data-table dataSource: table: products mode: search searchFields: [name, description] searchEngine: hybrid debounceMs: 300 limit: 50 ``` :::callout `searchEngine` vaut `client` par défaut. Les moteurs `fts`, `trigram` et `hybrid` ne s'exécutent que dans PostgreSQL — ils requièrent un corpus indexé. Sur SQLite, le classement côté serveur se rabat sur une correspondance plus simple ; concevez la recherche adossée à un index contre Postgres. Voir [full-text-search](/fr/docs/full-text-search#postgresql-vs-sqlite). ::: ## Le mode de source de données `search` La recherche est l'un des trois modes de source de données (`list`, `single`, `search`). Définir `mode: 'search'` transforme un composant lié à des données en une expérience de recherche interactive et anti-rebondie. | Propriété | Description | | -------------- | ---------------------------------------------------------------------------------------------------------- | | `table` | Table à interroger (validée par rapport à `app.tables`). | | `searchFields` | Tableau (≥ 1) de noms de champs sur lesquels chercher. Requis pour le mode recherche. | | `searchEngine` | Backend : `client` (par défaut), `fts`, `trigram` ou `hybrid`. | | `debounceMs` | Délai d'anti-rebond pour la saisie de recherche en millisecondes (entier ≥ 0), par ex. `300`, `500`. | | `limit` | Nombre maximal de résultats à renvoyer (entier ≥ 1), par ex. `10`, `20`, `50`. | | `bindTo` | ID d'un composant `searchInput` dont la requête pilote cette source de données (liaison inter-composants). | | `filter` | Conditions de filtre (logique ET) appliquées aux côtés de la requête de recherche. | | `sort` | Règles de tri appliquées aux résultats. | | `refreshMode` | Comment les résultats se rafraîchissent après le chargement : `none` (par défaut), `poll` ou `realtime`. | ```yaml # Interactive search with debounce and a result limit - type: data-table dataSource: table: products mode: search searchFields: [name, description] searchEngine: hybrid debounceMs: 300 limit: 20 ``` Pour le filtrage et le tri statiques de résultats hors recherche, utilisez le mode `list` avec `filter`/`sort` à la place — voir [records-filtering-sorting](/fr/docs/records-filtering-sorting). ## Choisir une approche | Besoin | Utiliser | | ------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | Restreindre une petite liste déjà sur la page | `searchEngine: client` | | Classer de grands jeux de données textuelles par pertinence | `searchEngine: fts` + `indexed: true` + `searchWeight` | | Tolérer les fautes de frappe et les mots partiels | `searchEngine: trigram` | | À la fois classement par pertinence et tolérance aux fautes | `searchEngine: hybrid` | | Chercher le contenu de pages statiques à l'échelle du site | `pageSearch` component — voir [search-components](/fr/docs/search-components) | | Définir quels champs sont cherchables et comment ils sont pondérés | Config au niveau du champ — voir [full-text-search](/fr/docs/full-text-search) | ## Associé - [Recherche plein texte](/fr/docs/full-text-search) — `fullTextSearch`, `indexed` et `searchWeight` au niveau du champ. - [Composants de recherche](/fr/docs/search-components) — `searchInput`, `pageSearch`, `list`, `command` et la recherche de barre d'outils. - [Champs texte](/fr/docs/text-fields) — l'indicateur `fullTextSearch` du champ `rich-text`. - [Présentation des tables](/fr/docs/tables-overview) — les propriétés de base des champs incluant `indexed` et `searchWeight`.