Architecture de recherche fédérée : ServiceNow, SharePoint et CMS

Le problème de l'architecture de recherche fédérée dans le milieu de travail moderne

L'architecture de recherche fédérée est le modèle de conception dont la plupart des entreprises ont maintenant besoin — et celui que la majorité des projets TI internes ratent encore. La raison est simple. La réponse que cherche votre employé ne se trouve plus dans un seul système. Elle se trouve à la fois dans les billets ServiceNow, les politiques SharePoint, le CMS d'entreprise et une poignée d'outils SaaS que personne n'a cartographiés sur le schéma TI.

Chacun de ces systèmes possède sa propre boîte de recherche. Aucun d'entre eux ne communique avec les autres. Par conséquent, l'employé ouvre cinq onglets, abandonne et contacte un collègue. Multipliez cela par une main-d'œuvre de 5 000 personnes et vous obtenez un coût de productivité qui rivalise discrètement avec tout autre poste sur la table du DSI.

Cependant, la solution n'est pas un portail de plus. La solution est une décision d'architecture sur le « où » et le « comment » indexer, sécuriser et exposer le contenu. C'est précisément cette décision que cet article décortique.

Ce que signifie vraiment l'architecture de recherche fédérée

Une architecture de recherche fédérée indexe le contenu provenant de plusieurs systèmes sources dans une seule couche de récupération unifiée et respectueuse des permissions. Les systèmes sources restent exactement là où ils sont. Pendant ce temps, une seule requête traverse l'ensemble et retourne un jeu de résultats classé et filtré selon les droits.

Il est utile de distinguer trois modèles qu'on confond souvent :

• Fédération vraie (diffusion au moment de la requête). La couche de recherche diffuse la requête à chaque système source au moment de l'appel et fusionne les résultats. C'est en temps réel, mais lent et difficile à classer de façon cohérente.
• Index unifié (indexation et consolidation). Chaque source est indexée selon un horaire, normalisée dans un index unique et classée avec un seul modèle de pertinence. Rapide à la requête, mais l'index peut accuser un léger retard sur la source.
• Hybride. La plupart des plateformes d'entreprise — Coveo, Glean, Elastic Workplace Search — adoptent par défaut un index unifié, complété d'appels en direct ciblés pour les sources qui changent vite, comme les incidents ServiceNow.

En pratique, lorsque les DSI disent “ architecture de recherche fédérée ”, ils entendent presque toujours par là le modèle hybride. C'est le modèle que le reste de cet article suppose.

Les trois sources que chaque DSI doit fédérer : ServiceNow, SharePoint et CMS

Presque tous les projets de recherche en milieu de travail en entreprise aboutissent aux trois mêmes sources principales. Elles se comportent très différemment, et l'architecture doit en tenir compte.

• ServiceNow contient des articles de base de connaissances, des éléments de catalogue et l'historique des incidents. Les permissions sont définies par table, par ACL et par rôle utilisateur. La documentation pour développeurs de ServiceNow explique en détail le modèle de tables et d'ACL. Le contenu change rapidement ; l'index doit donc être rafraîchi en quasi temps réel sur les tables de connaissances.
• SharePoint Online stocke les politiques, les sites de projet, les pages d'intranet et les documents partagés, avec des permissions héritées de Microsoft Entra ID. La documentation officielle de Microsoft SharePoint décrit le modèle de sites, de bibliothèques et de permissions uniques que l'index doit refléter à l'identique.
• L'intranet ou le CMS d'entreprise (souvent WordPress, AEM, Sitecore ou un CMS headless) publie les communications, le contenu RH et des pages d'atterrissage soignées. Les permissions sont habituellement publiques pour les employés authentifiés, mais les brouillons et le contenu réservé à une division doivent être filtrés.

Chaque source a son propre schéma, son propre modèle d'accès et son propre rythme de changement. Par conséquent, la couche de fédération n'est pas un seul connecteur. C'est un portefeuille de connecteurs, lié par un seul modèle d'identité.

Connecteurs, robots d'indexation et couche de fédération

Une architecture de recherche fédérée qui fonctionne comporte quatre pièces mobiles :

1. Connecteurs sources. Un par système — ServiceNow, SharePoint, CMS, plus tout autre système qui compte. Chaque connecteur s'authentifie, pagine et synchronise le contenu de façon incrémentale.
2. Un index unifié. Un index physique unique (ou logique réparti sur plusieurs partitions) où chaque document, peu importe la source, possède des champs normalisés : title, body, URL, source, last_modified et security_identities.
3. Une couche de pertinence et de classement. Un seul modèle — pas un par source — qui classe l'ensemble du contenu. C'est le classement appris par apprentissage automatique qui empêche SharePoint d'écraser ServiceNow.
4. Une couche API de requête et d'interface. Un seul point de terminaison que l'intranet, le module Teams ou un agent conversationnel appelle. L'authentification est transmise pour que la couche du dessous applique le filtrage de sécurité.

Surtout, ce n'est pas dans la couche de fédération que la sécurité s'applique. Elle s'applique une couche plus bas, dans l'index lui-même. C'est ce détail qui casse la plupart des architectures de recherche fédérée maison.

Indexation respectueuse des permissions : où la plupart des architectures de recherche fédérée échouent

Si une architecture de recherche fédérée ne peut pas prouver, au moment de la requête, qu'un utilisateur voit uniquement ce qu'il avait déjà le droit de voir, elle ne devrait pas être mise en production. C'est le mode d'échec le plus courant — et celui qui fait bloquer les projets par les équipes de sécurité et de conformité.

Le modèle sûr est appelé sécurité par liaison précoce. Au moment de l'indexation, le connecteur extrait la liste de contrôle d'accès complète de chaque document directement du système source — groupes Entra ID pour SharePoint, tables de rôles pour ServiceNow, indicateurs de capacités pour le CMS. Ces identités sont stockées avec le document dans l'index. Au moment de la requête, la couche de recherche résout les identités effectives de l'utilisateur et les utilise comme filtre contre l'index. L'utilisateur est mathématiquement incapable de voir un document auquel il n'a pas droit.

À l'inverse, la liaison tardive indexe le contenu sans métadonnées de permissions et vérifie chaque résultat contre le système source au moment de la requête. C'est plus simple en apparence. C'est aussi ce qui s'écroule en charge, fuit des résultats pendant les pannes, et qui finit le plus souvent par être reconstruit dans l'année. La documentation de la plateforme Coveo détaille comment les permissions sources et les identités de sécurité se mappent dans un index unifié à liaison précoce.

C'est aussi pour cela qu'une architecture de recherche fédérée est autant un projet de sécurité qu'un projet de recherche. Nous avons écrit un article compagnon plus approfondi sur la recherche d'entreprise respectueuse des permissions qui détaille davantage le modèle à liaison précoce.

La génération augmentée par récupération (RAG) au-dessus de l'architecture de recherche fédérée

Une architecture de recherche fédérée est aussi la bonne fondation pour un assistant d'IA générative — et un mauvais endroit pour sauter des étapes. Le modèle s'appelle la génération augmentée par récupération, ou RAG. Le modèle ne répond jamais à partir de son seul pré-entraînement. Au contraire, il récupère les documents les plus pertinents et filtrés selon les droits depuis l'index unifié, puis produit une réponse fondée sur ce contenu, avec citations.

Deux règles d'architecture gardent le RAG sûr en entreprise :

• Le modèle ne lit jamais que ce que l'utilisateur pouvait déjà ouvrir. L'étape de récupération utilise le même filtre de permission que l'interface utilisateur de recherche. Il n'y a pas de “compte de service IA” séparé et privilégié lisant tout.
• Chaque réponse cite ses sources. Les citations ne sont pas un détail d'expérience utilisateur — elles sont la piste d'audit qui permet à la conformité d'approuver le déploiement au départ.

En bref, on ne boulonne pas le RAG sur un LLM public en espérant que ça marche. On le bâtit par-dessus une architecture de recherche fédérée déjà sécurisée, et on traite le LLM comme une couche de présentation au-dessus de contenu que l'index a déjà validé. Pour la perspective DSI plus large, notre intranet propulsé par l'IA présente la valeur d'affaires de cette approche.

Coveo vs Microsoft 365 Copilot vs Glean vs RAG sur mesure : une lecture architecturale

Le choix de fournisseur dans ce domaine est surtout un choix d'architecture déguisé. Voici la carte honnête.

• Coveo est conçu sur mesure pour un index unifié et conscient des permissions couvrant Microsoft, ServiceNow, Salesforce, les CMS et les partages de fichiers. Il s'adapte le mieux lorsqu'une “véritable fédération entre des sources non-Microsoft” est une exigence stricte et lorsque l'entreprise utilise déjà Coveo sur son site web public.
• Microsoft 365 Copilot est exceptionnel à l'intérieur du graphe Microsoft 365. En revanche, dès qu'une réponse dépend de ServiceNow, du CMS d'entreprise ou d'un SaaS tiers, il s'affaiblit. La documentation officielle de Microsoft 365 Copilot est honnête sur les connecteurs qui sont de première classe et ceux qui ne le sont pas.
• Glean est un produit ciblé de recherche en milieu de travail et de RAG. Excellente expérience sortie de boîte, mais c'est un nouveau fournisseur, avec sa propre revue de sécurité et son propre cycle d'approvisionnement.
• RAG sur mesure sur une base de données vectorielle (pgvector, Pinecone, Weaviate) donne une flexibilité maximale. Cela vous rend aussi responsable des connecteurs, de la récupération respectueuse des permissions, du réglage de la pertinence et des opérations — un travail qui prend généralement 18 mois aux équipes pour être bien fait.

Il n'y a pas de gagnant universel. La bonne architecture dépend de l'endroit où vit votre contenu, de ce que vous possédez déjà, et de la préférence de la sécurité — un fournisseur à certifier, ou trois.

Un plan de déploiement de l'architecture de recherche fédérée en 90 jours

Une architecture de recherche fédérée n'a pas besoin d'un programme pluriannuel pour livrer de la valeur. Selon nos projets d'entreprise en recherche et découverte menés dans des secteurs réglementés, ce profil de 90 jours fonctionne :

1. Jours 1 à 15 — Inventaire des sources et des identités. Répertoriez tous les systèmes, tous les modèles d'autorisation et tous les fournisseurs d'identité. Déterminez ce qui doit réellement figurer dans l'index. La plupart des projets constatent que 30% du contenu “ important ” est constitué de doublons ou de données périmées.
2. Jours 16 à 45 — Pilotez une source avec sécurité à liaison précoce. Commencez avec une base de connaissances ServiceNow ou une bibliothèque SharePoint. Validez que le filtre de permissions bloque ce qu'il doit bloquer, avec l'équipe de sécurité dans la pièce.
3. Jours 46 à 75 — Ajoutez la deuxième et la troisième source. SharePoint et le CMS. Ajustez le modèle de pertinence maintenant qu'il y a du contenu de plusieurs sources qui se font concurrence.
4. Jours 76 à 90 — Activez la couche de réponse générative. Uniquement après que la qualité de récupération est solide. Livrez les citations dès le premier jour. Formez des évaluateurs de qualité de recherche, pas seulement les utilisateurs finaux.

Surtout, traitez le lancement comme le lancement d'un produit — pas comme un projet TI. La qualité de la recherche se dégrade sans propriétaire ; nommez-en un avant la mise en production.

Comment Sengo conçoit des architectures de recherche fédérée pour les entreprises

Sengo conçoit des architectures de recherche fédérée comme l'équipe de sécurité veut qu'elles soient bâties — liaison précoce, propices à l'audit et ancrées dans votre fournisseur d'identité actuel. Notre équipe inclut un ancien développeur backend Coveo, donc nous comprenons les connecteurs, les identités de sécurité et les modèles de pertinence au niveau où la plupart des projets restent coincés. Nous sommes partenaire officiel d'implémentation de Coveo, aux côtés des principales plateformes CMS et DXP, ce qui nous permet de conseiller de façon neutre sur la pertinence d'une architecture basée sur Coveo, sur Microsoft 365 Copilot, sur Glean ou sur un RAG sur mesure pour votre environnement.

Nous avons livré des projets de recherche d'entreprise et de plateforme numérique pour des organisations telles que iA Groupe financier, le Cirque du Soleil et LCI Éducation. Notre équipe bilingue est basée au Québec, ce qui élimine la friction pour les opérations canadiennes qui doivent servir leurs employés en français et en anglais depuis le même index.

Si votre entreprise utilise déjà Coveo ou Microsoft 365 côté public, votre architecture de recherche fédérée est plus proche que vous ne le pensez. Cartographions le chemin le plus court depuis les systèmes que vous possédez déjà vers un lieu de travail où chaque employé trouve ce dont il a besoin — en toute sécurité.