La recherche globale Ctrl+K interroge toutes les rubriques métier en même temps (clients, tickets, projets, contrats, etc.). Pour que l'expérience reste perçue comme instantanée, l'équipe a optimisé la chaîne de recherche afin de descendre en dessous du seuil psychologique des 50 ms.
Cette doc décrit le comportement et les gains de performance du moteur de recherche transverse (Meilisearch). Elle ne concerne pas la recherche avancée, qui repose sur des requêtes SQL paginées avec un objectif de performance différent.
| Indicateur | Cible | État |
|---|---|---|
| Latence moyenne d'une recherche globale | < 50 ms | Atteint (~30 ms) |
| Latence avant optimisations | ~ 60 ms | — |
| Recherches simultanées (rubriques interrogées) | 20 | — |
À 30 ms par requête, la recherche est imperceptiblement plus rapide que le délai naturel entre deux frappes au clavier : l'utilisateur voit ses résultats apparaître au même rythme qu'il tape.
Quatre leviers d'optimisation ont été activés sur le moteur de recherche. Ils sont transparents pour l'utilisateur — il n'y a rien à activer ni à configurer côté usage.
Plutôt que d'ouvrir une nouvelle connexion réseau à chaque frappe, l'application maintient la connexion ouverte avec le moteur de recherche. Gain : 8 à 12 ms par recherche après la première frappe.
Le moteur retourne désormais les résultats correspondant au plus grand nombre de mots possible plutôt que d'exiger que tous les mots soient présents. Concrètement : taper "client paris dupond" peut renvoyer un résultat même si seuls "client" et "dupond" matchent. Gain : 2 à 4 ms + meilleure tolérance pour les recherches imprécises.
Pour chaque résultat, seuls les champs réellement affichés (nom, identifiant, vignette) sont remontés. Les champs non utilisés à l'écran ne traversent plus le réseau. Gain : 3 à 5 ms sur les rubriques riches.
Les droits d'accès de l'utilisateur (qui détermine ce qu'il a le droit de voir) sont calculés une fois par session puis mémorisés. Plus besoin de les recalculer à chaque frappe. Gain : 1 à 2 ms par frappe.
| Optimisation | Gain estimé |
|---|---|
| Connexions réutilisées | 8-12 ms |
| Stratégie de correspondance | 2-4 ms |
| Données limitées | 3-5 ms |
| Cache des permissions | 1-2 ms |
| Total | ~14 à 23 ms gagnés |
Un script de benchmark interne permet à l'équipe technique de mesurer la latence réelle dans des conditions proches de la production (5 termes × 10 itérations × 20 index, statistiques moyenne / médiane / P95 / P99). Il est utilisé après chaque évolution de la recherche pour s'assurer qu'aucune régression de performance n'est introduite.
Doc technique : .claude/technical-docs/search/meilisearch-optimizations.md