Recherche intranet : comment aider les collaborateurs à trouver l’information dans Open Intranet

Une collaboratrice recherche « droits à congés ». La page utile s’intitule « Politique de congés annuels », mais elle n’apparaît jamais. Après deux tentatives, elle envoie un e-mail aux RH.

C’est un échec de la recherche intranet, mais cela ne signifie pas forcément que le moteur de recherche doit être remplacé. La cause peut être un vocabulaire manquant, une lacune d’indexation, un filtre trop restrictif ou un résultat difficile à reconnaître.

Lorsque vous construisez un nouvel intranet, concevez la recherche autour des tâches des collaborateurs plutôt que de la traiter comme une fonctionnalité du jour de lancement. Open Intranet fournit un point de départ que vous pouvez configurer et étendre. L’objectif pratique est d’aider les collaborateurs à atteindre plus vite la bonne information, tout en gardant confidentielles les informations à accès restreint.

Dans cet article :

• Pourquoi la recherche intranet par défaut déçoit-elle ?
• Que doit contenir votre index de recherche ?
• Quelles métadonnées rendent l’information plus facile à trouver ?
• Comment synonymes, boosting et filtres doivent-ils fonctionner ensemble ?
• Comment l’interface de recherche peut-elle aider les collaborateurs à choisir le bon résultat ?
• Comment étendre Open Intranet avec d’autres moteurs de recherche ?
• Comment la recherche vectorielle aide-t-elle les collaborateurs à chercher par intention ?
• Comment mesurer le succès de la recherche et continuer à l’améliorer ?

Pourquoi la recherche intranet par défaut déçoit-elle ?

La recherche travaille avec le contenu, les champs, les règles d’accès et les instructions de classement qu’elle reçoit. Elle ne peut pas anticiper la terminologie de chaque organisation ni décider, parmi plusieurs politiques contradictoires, à laquelle les collaborateurs doivent se fier.

Pour la requête « droits à congés », plusieurs choses peuvent mal se passer :

• Contenu manquant : la consigne pertinente n’existe pas.
• Décalage de vocabulaire : les collaborateurs et les rédacteurs utilisent des termes différents.
• Classement faible : la politique apparaît sous des annonces moins utiles.
• Doublons obsolètes : plusieurs versions concurrencent la politique en vigueur.
• Restrictions de permissions : la collaboratrice n’a pas accès à la page attendue.
• Résultats confus : la politique apparaît, mais son titre ou sa description ne l’identifie pas clairement.

Ces problèmes appellent des réponses différentes. Changer de backend ne créera pas une politique manquante et ne résoudra pas des versions contradictoires.

L’implémentation de la recherche d’Open Intranet sépare le contenu indexé du moteur qui le parcourt. Elle utilise Drupal Search API, initialement avec un backend base de données, et des index distincts pour le contenu et les profils utilisateurs. Les collaborateurs accèdent à la page de recherche principale à l’adresse /search.

Cette séparation aide à enquêter sur un résultat manquant. Essayez d’abord d’ouvrir la page attendue avec un compte collaborateur ordinaire. Si la page est accessible directement mais absente de la recherche, vérifiez si elle a été indexée et quels champs la requête interroge. Si la collaboratrice ne peut pas l’ouvrir, vérifiez plutôt le statut de publication et l’accès. Un contenu correctement restreint doit rester absent de ses résultats.

Conservez une petite collection de requêtes auxquelles revenir à chaque modification :

Requête du collaborateur	Ressource attendue	Ce qu’il faut vérifier
Droits à congés	Politique de congés annuels applicable	La politique en vigueur est facile à reconnaître
Formulaire de notes de frais	Page actuelle de soumission des notes de frais	Un formulaire retiré n’entre pas en concurrence
Contact RH	Profil collaborateur pertinent	La personne apparaît dans l’expérience de recherche prévue
Nom d’un projet confidentiel	Aucun résultat confidentiel pour un collaborateur non autorisé	Aucun titre, extrait ou suggestion ne le révèle

Utilisez les mêmes rôles de collaborateurs à chaque fois. Il est ainsi plus facile de voir si une modification a aidé, plutôt que de juger la recherche sur une seule requête réussie effectuée en tant qu’administrateur.

Que doit contenir votre index de recherche ?

Un index est la représentation interrogeable de votre contenu. Une page peut exister dans l’intranet sans que toutes ses informations utiles soient disponibles pour la recherche. C’est pourquoi la couverture mérite d’être vérifiée avant d’ajuster le classement.

Dans Open Intranet, les administrateurs peuvent inspecter les index à l’adresse /admin/config/search/search-api. Comparez les champs inclus et les éléments en attente avec les sources que les collaborateurs s’attendent à trouver : politiques, guides, personnes, fiches de documents et dépôts connectés.

La configuration de Search API dans Drupal réunit la source, les champs indexés et les processeurs qui préparent l’information pour la recherche. Par exemple, vous pouvez inclure le titre et le corps d’une politique pour la correspondance textuelle, et son site géographique comme filtre. Si un champ requis est absent de l’index, reformuler la requête ne rendra pas ce champ interrogeable.

Les documents méritent un examen distinct. Trouver un document par son titre ne prouve pas que la recherche peut lire le texte de sa pièce jointe. Un lien vers un fichier hébergé à distance n’intègre pas non plus automatiquement son contenu dans l’index. La recherche en texte intégral dans les pièces jointes peut nécessiter un composant d’extraction, et les PDF numérisés peuvent exiger une reconnaissance optique de caractères (OCR). Considérez cela comme une configuration supplémentaire là où elle est nécessaire.

Essayez de publier une nouvelle page, de mettre à jour une politique existante et de retirer une ressource ancienne. Vérifiez quand ces changements atteignent les résultats. Cela permet de distinguer un délai d’indexation d’un problème lié au contenu lui-même.

Garder les permissions attachées à l’expérience de recherche

La recherche documentée d’Open Intranet applique un filtrage d’accès à ses résultats. Dans Drupal Search API, les processeurs d’accès au contenu aident à transporter l’information d’accès dans la recherche. Lorsque vous ajoutez une autre source, un backend ou une restriction personnalisée, vérifiez que ses règles d’accès sont représentées tout au long du parcours de recherche, plutôt que de supposer que le nouveau composant les gère automatiquement.

Un collaborateur sans permission ne doit pas découvrir un document confidentiel par son titre, son extrait, une valeur de filtre ou une suggestion d’autocomplétion. Refuser l’accès seulement après le clic arrive trop tard si le résultat a déjà révélé une information sensible.

Utilisez des comptes aux permissions différentes pour vérifier à la fois les résultats visibles et les réponses mises en cache. Répétez ces vérifications après chaque modification des règles d’accès, pas seulement lors de la première configuration de la recherche.

Quelles métadonnées rendent l’information plus facile à trouver ?

Les collaborateurs ne devraient pas avoir à ouvrir plusieurs fichiers pour découvrir quelle politique s’applique à eux. Des titres clairs et quelques champs utiles permettent aux résultats d’expliquer cette différence avant même que quelqu’un ne clique.

Comparez HR_Final_v7.pdf avec une page intitulée « Politique de congés annuels pour les collaborateurs aux États-Unis », rattachée au thème des congés et marquée comme en vigueur. La seconde donne à la fois au collaborateur et à la configuration de recherche des informations plus utiles.

Comme Open Intranet est construit sur Drupal, vous pouvez travailler avec les champs des types de contenu concernés plutôt que d’essayer de faire tenir chaque distinction dans un nom de fichier. Passez en revue ce qui existe déjà, puis n’ajoutez que ce qui aide une tâche réelle :

• Titre : des mots que les collaborateurs reconnaissent.
• Type de contenu : politique, guide, formulaire, actualité ou une autre distinction utile.
• Thème : une catégorie cohérente comme les congés ou les notes de frais.
• Public ou site : lorsque l’applicabilité diffère.
• Responsable : la personne ou l’équipe qui entretient l’information.
• Statut : en vigueur ou remplacée.

L’étape suivante consiste à décider comment la recherche utilise ces champs. Dans un index Drupal Search API, les champs texte peuvent contribuer à la correspondance, tandis que des champs structurés correctement configurés peuvent servir au filtrage ou au tri. Ajouter un champ de site à une politique ne crée pas, à lui seul, un filtre par site sur la page de recherche : le champ doit aussi être indexé et relié à l’interface des résultats.

Après avoir modifié la configuration de l’index, reconstruisez les données concernées lorsque c’est nécessaire. Sinon, les enregistrements plus anciens risquent de ne pas encore contenir les valeurs qu’attend votre nouveau filtre.

Tous les champs n’ont pas vocation à devenir des filtres. Le responsable peut soutenir la maintenance éditoriale sans aider les collaborateurs à affiner leurs résultats. Gardez des choix gérables pour les rédacteurs, expliquez comment les utiliser et comblez les lacunes dans les pages existantes comme dans les nouvelles.

Un test utile consiste à montrer à un collaborateur deux politiques propres à un site dans les résultats. Peut-il identifier la bonne sans ouvrir les deux ? Sinon, améliorez le titre, les valeurs de champs ou l’affichage avant d’ajouter d’autres catégories.

Comment synonymes, boosting et filtres doivent-ils fonctionner ensemble ?

Ces leviers répondent à des problèmes différents. Les synonymes relient des expressions, le boosting modifie l’importance relative des correspondances, et les filtres permettent aux collaborateurs d’affiner délibérément les résultats.

Commencez par les mots que les gens utilisent réellement. « RTT », « congés payés » et « congés annuels » peuvent être liés, mais leur sens peut varier selon les sites. Convenez des termes équivalents avant de configurer une règle qui les traite comme identiques.

Pour Open Intranet, regardez d’abord les champs déjà indexés et si le contenu utilise un langage reconnaissable. Évaluez ensuite les options de pondération prises en charge par le backend Search API choisi. Donner plus d’importance à un titre descriptif qu’à un texte de corps incident peut aider une politique à remonter au-dessus d’une annonce qui ne fait que la mentionner.

Un traitement linguistique plus avancé relève en partie du moteur de recherche. Par exemple, une implémentation basée sur Solr peut utiliser sa configuration d’analyse linguistique pour gérer les synonymes. C’est différent de la modification de la politique elle-même, et cela ne doit pas être décrit comme un écran de synonymes universel d’Open Intranet. Les leviers disponibles dépendent du backend et du connecteur que vous déployez.

Les filtres utilisent la structure que vous avez établie dans les métadonnées. Open Intranet fournit déjà un filtre par type. Un filtre par site ou par thème peut être ajouté en indexant le champ approprié et en le configurant dans la vue de recherche ; une interface à facettes peut aussi nécessiter des modules supplémentaires et des réglages de backend.

Évitez de donner un avantage automatique à chaque page plus récente. Une politique en vigueur publiée il y a plusieurs années peut toujours être la bonne réponse, devant l’actualité de la semaine dernière.

Modifiez une règle à la fois et revenez à vos requêtes d’exemple. Incluez des formulations qui ne devraient pas correspondre et essayez des combinaisons de filtres. Si une politique disparaît lorsqu’un site est sélectionné, le problème vient peut-être d’un champ vide plutôt que du moteur de recherche.

Comment l’interface de recherche peut-elle aider les collaborateurs à choisir le bon résultat ?

Un résultat pertinent échoue quand même si le collaborateur ne le reconnaît pas. Pour la consultation d’une politique, un affichage utile pourrait ressembler à ceci :

Politique de congés annuels pour les collaborateurs aux États-Unis
Éligibilité, droits annuels et règles de report des congés non pris sur l’année suivante.
Politique · États-Unis · En vigueur

Il s’agit d’une présentation suggérée, pas d’une capture d’écran par défaut du produit. Elle donne au collaborateur une réponse rapide à trois questions : qu’est-ce que c’est, cela s’applique-t-il à moi et est-ce à jour ?

La page de recherche d’Open Intranet est construite avec Drupal Views. Views réunit la requête, les filtres, le tri et la présentation des résultats. Un site builder peut examiner la vue de recherche pour ajuster les informations affichées et la façon dont les collaborateurs affinent la liste. Lorsque les résultats utilisent du contenu rendu plutôt que des champs individuels, la configuration d’affichage ou le template concerné demande aussi de l’attention.

Better Exposed Filters est utilisé pour la présentation des filtres dans la configuration documentée. Cela donne à l’équipe une voie de configuration pour modifier l’apparence des choix de filtres disponibles, plutôt que de commencer par écrire une nouvelle interface.

Gardez une présentation ciblée. Montrez l’applicabilité là où elle aide, utilisez des descriptions parlantes et rendez les personnes, les pages et les documents faciles à distinguer. Laissez les filtres actifs visibles et proposez un moyen clair de les réinitialiser. Quand rien ne correspond, expliquez comment retirer un filtre ou essayer un autre terme au lieu de laisser une page vide.

Les suggestions orthographiques et l’autocomplétion peuvent être des ajouts utiles, mais elles nécessitent leur propre implémentation et leurs propres contrôles d’accès. Une suggestion tirée d’un document restreint peut exposer une information avant même que le collaborateur ne lance une recherche.

Testez le parcours complet sur un téléphone, au clavier et avec les technologies d’assistance pertinentes. Les personnes doivent comprendre ce qui a changé après l’application d’un filtre et comment revenir à un ensemble de résultats plus large.

Comment étendre Open Intranet avec d’autres moteurs de recherche ?

Open Intranet n’est pas limité à son moteur de recherche initial. Sa base Drupal et son intégration de Search API offrent des voies vers d’autres services sans faire du remplacement de tout l’intranet la réponse par défaut.

Considérez Search API comme la couche d’intégration. Elle définit l’information indexée et fournit à Drupal un moyen d’interroger un backend pris en charge. Le backend exécute la recherche, avec des capacités qui varient selon le moteur et le connecteur.

Option de recherche	Où elle s’inscrit	Ce qu’il faut prendre en compte
Search API avec backend base de données	Le point de départ documenté d’Open Intranet	Couverture, champs, pertinence et performance face aux vraies tâches des collaborateurs
Apache Solr via Search API Solr	Une extension pour des besoins comme une analyse linguistique plus riche et des contrôles de pertinence	Un service de recherche configuré, des modules compatibles et une exploitation continue
Elasticsearch via un connecteur Search API compatible	Une autre voie d’intégration, y compris pour les équipes qui exploitent déjà Elasticsearch	Versions de Drupal et d’Elasticsearch prises en charge et fonctionnalités du connecteur
Recherche sémantique vectorielle	Correspondance par le sens là où les différences de formulation restent un obstacle	Embeddings, conception de la récupération, choix du fournisseur et application des permissions

Search API Solr fournit la connexion Drupal à Solr. Pour Elasticsearch, évaluez les prérequis du connecteur pour votre déploiement. Ce sont des voies d’extension, pas des interrupteurs interchangeables au support fonctionnel identique.

Dans une implémentation Drupal, changer de backend signifie configurer le service de recherche choisi, connecter les index concernés et les alimenter. L’équipe passe ensuite en revue les requêtes, filtres et rendus de résultats affectés. Conserver la page de recherche destinée aux collaborateurs ne dispense pas de tester ce qui se passe désormais derrière.

Faites ce travail d’abord en staging. Comparez la configuration actuelle et la configuration proposée avec les mêmes contenus, requêtes et comptes collaborateurs. Examinez l’utilité des résultats, le temps de réponse, les délais de mise à jour et le comportement en matière d’accès. Intégrez l’hébergement, la supervision, les mises à jour et la reprise dans la décision, pas seulement l’installation initiale.

Un autre moteur est utile lorsqu’il répond à un besoin démontré. Il ne peut pas, à lui seul, résoudre des politiques contradictoires ni rendre compréhensible un document mal nommé.

Comment la recherche vectorielle aide-t-elle les collaborateurs à chercher par intention ?

Un collaborateur qui demande « Puis-je reporter mes congés non pris sur l’année prochaine ? » a peut-être besoin d’une section intitulée « Report des congés annuels ». La recherche sémantique peut aider à relier ces expressions même lorsque la formulation diffère.

Elle utilise des embeddings, des représentations numériques du texte qui permettent à un système de comparer des significations. Une base de données vectorielle stocke ces représentations et récupère celles qui sont similaires. Elle n’est pas elle-même un modèle qui rédige des réponses.

Cela donne à Open Intranet une autre façon de faire évoluer sa recherche grâce à l’écosystème d’extensions de Drupal. Drupal AI Search est un module à évaluer pour connecter la récupération vectorielle à Search API. Le module choisi, le fournisseur d’embeddings et le service vectoriel doivent être vérifiés en matière de compatibilité et d’aptitude à la production avant le déploiement.

Le processus de base consiste à préparer un texte approuvé, à créer ses embeddings, à les stocker avec des références vers la source et à récupérer le matériel pertinent lorsqu’un collaborateur pose une question. Pour les documents longs, l’implémentation peut rechercher des passages plus courts afin de trouver la section utile plutôt que de traiter tout le manuel comme un seul élément.

La recherche sémantique doit compléter la précision, pas la supprimer. Les noms, identifiants et références exactes à des politiques bénéficient toujours d’une correspondance littérale. Une approche hybride combine la récupération par mots-clés et la récupération sémantique pour prendre en charge les deux types de requêtes.

Commencez par une collection limitée et comparez-la à votre recherche par mots-clés optimisée. Incluez des questions paraphrasées, des formulations ambiguës et des références exactes. Observez si les collaborateurs atteignent la bonne source, combien de temps cela prend et ce que le service coûte à exploiter.

Trouver une source et générer une réponse sont deux étapes différentes

La récupération sémantique peut renvoyer des liens pertinents sans rédiger de réponse. Si vous ajoutez des réponses générées, le modèle qui rédige la réponse a besoin de son propre ensemble de contrôles : des liens vers les sources applicables, une réponse claire quand les preuves manquent et une protection contre les instructions trompeuses intégrées au matériel récupéré.

Seules les informations que le collaborateur demandeur est autorisé à utiliser doivent entrer dans le contexte de génération de la réponse. Vérifier a posteriori les liens sources visibles ne suffit pas ; les informations restreintes ne doivent tout simplement pas fuiter dans le résumé.

Gardez l’information d’accès rattachée aux passages indexés et vérifiez la gestion des permissions dans le parcours de récupération. Examinez les caches, les modifications de documents et ce qui se passe lorsqu’un collaborateur perd un accès. Les mécanismes d’accès du module soutiennent ce travail, mais ils ne dispensent pas de valider votre configuration particulière.

Ce sont des extensions à évaluer pour le site déployé, pas des hypothèses sur ce que chaque installation d’Open Intranet inclut déjà. De même, un assistant IA éditorial et une recherche sémantique destinée aux collaborateurs sont des capacités distinctes.

Comment mesurer le succès de la recherche et continuer à l’améliorer ?

Le succès de la recherche signifie accomplir une tâche, pas seulement renvoyer des résultats. Commencez par des mesures qui vous aident à comprendre l’expérience du collaborateur :

Mesure	Ce qu’elle vous aide à comprendre
Accomplissement de la tâche	Si les collaborateurs ont atteint la bonne ressource ou la bonne réponse
Temps jusqu’à la bonne ressource	Combien de temps prend une consultation définie
Position du résultat attendu	Si la ressource prévue apparaît en bonne place
Taux de résultats nuls	À quelle fréquence les requêtes ne renvoient rien, compte tenu des filtres et du contexte du compte
Reformulation des requêtes	Si les collaborateurs changent plusieurs fois de formulation avant de trouver quelque chose

Établissez une base de référence avant de modifier la configuration. Observez les tâches réelles avant de choisir des objectifs, plutôt que d’emprunter un benchmark qui ne correspond peut-être pas à votre organisation.

Pour un site Open Intranet, la vue de recherche est un point de départ utile pour discuter de la mesure avec le responsable de l’analytique. Passez en revue les événements de requête, de filtre, de clic sur un résultat et de résultat vide déjà capturés, et le suivi supplémentaire nécessaire. La configuration de Search API et le reporting analytique servent des objectifs différents ; une page de statut d’index n’est pas un rapport sur le succès des collaborateurs.

Lorsque les résultats déçoivent, regroupez les causes : contenu manquant, défauts d’indexation, lacunes de vocabulaire, filtres restrictifs ou limites d’accès légitimes. Cela permet d’orienter le problème vers quelqu’un qui peut le corriger, au lieu de traiter chaque requête échouée comme un problème de moteur.

Un clic ne prouve pas le succès : le collaborateur a peut-être ouvert le mauvais document. À l’inverse, un extrait utile peut répondre à la question sans clic. Associez l’analytique agrégée à de courts entretiens et à des tests de tâches, et limitez l’accès aux journaux de requêtes ainsi que leur conservation, car les gens peuvent saisir des informations sensibles dans la recherche.

Gardez des responsabilités simples. Les propriétaires de contenu corrigent le matériel source, un responsable de la recherche s’occupe de la pertinence et de la configuration, et l’équipe technique surveille l’indexation et les défaillances. Réutilisez les mêmes requêtes et rôles de collaborateurs après chaque modification des champs, des moteurs, des permissions ou de l’affichage des résultats.

L’amélioration devient ainsi une partie répétable de la maintenance de l’intranet, plutôt qu’une refonte ponctuelle de la recherche.

Prêt à rendre la recherche d’Open Intranet plus utile ?

Commencez par quelques requêtes difficiles de collaborateurs, les réponses que les personnes devraient atteindre et votre configuration actuelle d’Open Intranet.

Apportez-les à une revue de la recherche avec Droptica, l’équipe derrière Open Intranet. Nous pouvons vous aider à séparer les corrections de contenu des changements de configuration et des travaux d’extension, tout en gardant les règles d’accès de votre organisation au centre de la conception.

Contactez Droptica pour passer en revue vos priorités de recherche et définir ce qu’il faut tester en premier.