Une barre de recherche a l’air simple : quelques mots, un bouton et une liste de résultats. En entreprise, le moteur doit pourtant trouver le contrat signé plutôt que le brouillon, sans révéler le titre d’un dossier confidentiel. Ça demande une chaîne technique et beaucoup de décisions sur le contenu.

Le travail commence avant la requête. Un connecteur parcourt les sites, partages de fichiers et autres sources autorisées. Il lit les propriétés, extrait le texte des formats qu’il comprend, découpe les mots, normalise certaines variantes et construit un index inversé. Au lieu de rouvrir tous les documents à chaque recherche, cet index associe chaque terme aux documents où il apparaît.

Ce qui se passe quand on cherche

Pour la requête « contrat Contoso renouvellement », le moteur peut suivre cette séquence :

1. analyser les mots et retirer ceux qui apportent peu de sens;
2. repérer dans l’index les documents contenant les termes;
3. filtrer les résultats selon l’identité et les permissions;
4. calculer un score à partir du titre, du corps, de la fraîcheur et d’autres signaux;
5. générer un extrait et retourner la première page.

Le contrat peut tout de même rester quatrième. Un brouillon intitulé Contrat Contoso final contient les trois mots dans le titre; le PDF signé s’appelle scan0042.pdf et ne contient qu’une image. Sans reconnaissance optique de caractères, son texte n’est même pas dans l’index. Le moteur ne peut classer ce qu’il n’a pas lu.

J’ajouterais donc quelques métadonnées ciblées : client, type de document, état contractuel, date d’effet et propriétaire. Une règle de pertinence peut favoriser état = signé lorsqu’on cherche un contrat. Mais il faut éviter quinze champs obligatoires : pressé, le monde choisit la première valeur et l’index gagne une donnée fausse.

La sécurité fait partie du résultat

Le security trimming retire normalement ce que l’utilisateur ne peut pas lire. Il dépend toutefois d’une synchronisation correcte des groupes et des ACL. Si le crawler indexe avec un compte trop privilégié, puis que le filtre de requête est mal configuré, un titre ou un extrait sensible peut apparaître. J’essaierais la recherche avec des comptes de rôles différents, pas seulement avec celui de l’administrateur.

Il existe aussi une fenêtre de décalage. Un accès retiré à 9 h et un index mis à jour plus tard peuvent produire un comportement inattendu selon l’architecture. Les contenus très sensibles ne devraient pas reposer sur l’idée que « la recherche va sûrement les cacher ».

La fraîcheur a son coût. Un crawl complet de millions de fichiers charge les sources et prend du temps. Les crawls incrémentaux réduisent le travail, mais ils peuvent manquer un changement si la source signale mal les modifications. Je surveillerais le nombre de documents parcourus, les erreurs d’extraction, l’âge du dernier crawl réussi et les extensions de fichiers ignorées.

Enfin, les requêtes sont elles-mêmes une source d’amélioration. Beaucoup de recherches sans résultat indiquent un trou d’index ou un vocabulaire différent. Des reformulations immédiates montrent que les synonymes manquent. Un résultat souvent affiché mais jamais ouvert est probablement mal classé. Ces logs doivent être agrégés avec prudence, car les recherches des employés peuvent contenir des noms ou des sujets sensibles.

Avant de promettre une recherche « intelligente », je choisirais vingt tâches réelles, dont trouver le contrat valide, et je mesurerais le rang, la fraîcheur et les fuites de permissions. Une recherche utile n’est pas celle qui trouve beaucoup de fichiers; c’est celle qui permet d’agir sur le bon contenu avec le bon accès.