Recherche documentaire sur un corpus : parcours de conception du pipeline d'indexation, des permissions et de la réindexation

Objectif

Effectuer une recherche sur un corpus qui vit dans un système de référence, avec des résultats qui respectent les permissions et un index dont le retard sur la source ne dépasse jamais une borne fixée.

Prérequis

Une définition du document (id, titre, corps, métadonnées, propriétaire, visibilité, updated_at), les langues concernées, et une borne de fraîcheur acceptée par le produit.

Étapes

1. Contraintes : la source reste faisant autorité et l'index est dérivé et reconstructible ; un utilisateur ne doit jamais voir un extrait d'un document qu'il ne peut pas ouvrir ; l'interrogation à chaque frappe est une décision produit, pas un défaut.
2. Composants : un indexeur alimenté par des événements de changement (un outbox) ou par un sondage (polling) sur updated_at ; un magasin d'index, en commençant par l'index plein texte propre à la base de données puis en migrant vers un moteur dédié lorsque les fonctionnalités de classement ou l'échelle l'exigent ; un service de requête qui analyse la saisie, applique les filtres de permission, classe et met en évidence ; un réconciliateur qui compare la source et l'index.
3. Modèle de données : search_doc(doc_id, version, text fields, acl_keys[], updated_at, indexed_at) ; les clés d'ACL (identifiant du propriétaire, identifiants de groupe, public) sont des champs indexés pour que le filtrage ait lieu à l'intérieur du moteur plutôt qu'après le classement. Dans PostgreSQL, la documentation indique que les index GIN sont le type d'index de recherche plein texte à privilégier, conservant une entrée par lexème avec une liste compressée de positions.
4. Gestion de l'index : versionner l'index (docs_v3) et basculer un alias après une reconstruction complète ; garder l'indexeur idempotent (upsert par doc_id, ignorer les versions plus anciennes que celle déjà indexée) ; traiter les suppressions comme des événements explicites, jamais par absence.
5. Classement : partir de la pertinence par défaut du moteur, plus une pondération du titre et un terme de récence ; journaliser la requête, les identifiants de résultat et la position du clic, afin qu'un futur changement de classement puisse être jugé au regard de ce journal.
6. Modes de défaillance : événements de changement manqués (le réconciliateur compare les décomptes et le updated_at maximum par plage, puis réindexe la différence) ; changements de permission non propagés (traiter les modifications d'ACL comme des mises à jour de document) ; requêtes très longues ou truffées de jokers (plafonner la longueur, interdire les jokers en tête) ; réindexation sous charge (limiter le débit, lire depuis une réplique) ; extraits exposant des champs que le document visible masque (n'indexer que ce qui peut être affiché).
7. Mesurer : le retard de l'index (updated_at de la source moins indexed_at), la latence des requêtes, le taux de résultats vides, la part des requêtes avec un clic parmi les meilleurs résultats, la dérive détectée par le réconciliateur, la durée d'une réindexation complète.
8. Pas en premier : recherche sémantique ou vectorielle, synonymes et correction orthographique, classement personnalisé, autocomplétion, recherche multilingue.

Résultat attendu

Un document modifié dans la source apparaît dans la limite de la borne de fraîcheur, disparaît lorsqu'il est supprimé ou masqué, et une reconstruction complète est une opération de routine plutôt qu'un incident.

Limites et base de vérification

Conception proposée, aucune mesure. La qualité de la pertinence n'est pas traitée, au-delà de la journalisation suffisante pour l'évaluer plus tard ; la borne de fraîcheur est une donnée d'entrée produit, pas une propriété de la conception.