Glean vs alternatives souveraines : ce que les RSSI doivent savoir
Les outils de recherche d'entreprise augmentée par l'IA ont atteint leur maturité commerciale. Glean dispose d'une base de clients enterprise significative et d'une liste d'intégrations impressionnante. Microsoft Copilot for M365 est disponible dans toutes les organisations qui utilisent déjà Office 365. Ces deux solutions ont des avantages réels, des références clients convaincantes, et une équipe commerciale qui sait parler à la direction générale.
Ce que ces équipes commerciales ne mettent pas en avant, c'est la question qui devrait précéder toute évaluation pour une entreprise française régulée : où vont mes données lors de l'inférence, et qui peut y accéder légalement ? La réponse à cette question devrait structurer le RFP avant même que les démonstrations commencent — pas parce que les fournisseurs sont de mauvaise foi, mais parce que leur architecture crée structurellement des expositions incompatibles avec certains cadres réglementaires.
Ce que Glean fait bien
Soyons précis sur ce que Glean réussit, parce que la comparaison honnête exige de commencer par là.
Glean excelle dans la recherche unifiée sur les outils SaaS d'entreprise. Sa proposition de valeur est de connecter les sources fragmentées — outils de messagerie interne, espaces de stockage collaboratif, wikis, systèmes de gestion de projets, CRM — et de permettre une recherche sémantique sur l'ensemble de cet environnement hétérogène. Pour une organisation dont la connaissance est dispersée dans des dizaines d'outils SaaS, Glean résout un problème réel : l'inaccessibilité de la connaissance inter-silos.
L'interface est bien conçue, l'adoption utilisateur est rapide, et les capacités de personnalisation — résultats filtrés par rôle, par équipe, par contexte — sont avancées. Pour les entreprises qui opèrent dans un environnement SaaS homogène et sans contraintes de souveraineté particulières, Glean est un outil performant qui répond à un vrai problème opérationnel.
Le problème, c'est que ce profil d'entreprise sans contraintes de souveraineté exclut la majorité des grandes organisations françaises régulées.
Les limites critiques pour les entreprises françaises régulées
Glean est une entreprise américaine dont l'infrastructure est hébergée sur des cloud providers américains. L'inférence — le traitement de vos requêtes et de vos documents pour générer des réponses — se passe sur cette infrastructure. Pour une entreprise française soumise à des obligations de confidentialité réglementaire, plusieurs problèmes surgissent.
Le CLOUD Act. Comme toute entreprise de droit américain, Glean est potentiellement soumise au Cloud Act, qui autorise les autorités américaines à exiger la production de données même hébergées hors des États-Unis. Un datacenter en Europe ne protège pas contre cette obligation légale si l'opérateur est américain. Pour des données financières, des analyses stratégiques, ou des documents soumis à un secret professionnel, cette exposition est incompatible avec une politique d'IA souveraine sérieuse. Comme l'explore l'article sur la sécurité des IA d'entreprise au-delà de la conformité SOC 2, la protection contractuelle et la garantie architecturale sont deux choses distinctes — et dans les contextes régulés, seule la seconde suffit.
L'absence de mode air-gap. Glean ne propose pas de déploiement on-premise ou air-gap. L'architecture est cloud-native par conception. Il n'existe pas d'option pour exécuter l'inférence dans votre propre infrastructure. Pour les organisations dont la politique de sécurité exige que les données sensibles ne quittent pas le périmètre, Glean n'est architecturalement pas une option envisageable, indépendamment des garanties contractuelles proposées.
La visibilité limitée sur les logs d'inférence. Quand un utilisateur fait une requête sur Glean, quels logs sont produits, où sont-ils conservés, et qui peut y accéder chez Glean ? Ces questions ont des réponses contractuelles, mais pas de réponses architecturales vérifiables. Pour un RSSI qui doit rendre compte à une autorité de contrôle d'un incident impliquant des données sensibles, la distinction entre "contractuellement protégé" et "architecturalement impossible" est fondamentale. Seule la seconde constitue une garantie audit-ready.
Les droits d'audit DORA. Pour les entités financières soumises au Digital Operational Resilience Act, DORA exige des droits d'audit complets sur les prestataires ICT critiques. Les conditions d'audit de Glean — comme celles de la plupart des SaaS cloud — se limitent à des certifications standardisées (SOC 2 Type II, ISO 27001). Elles ne permettent pas à une entité financière supervisée d'exercer les droits d'audit directs que DORA impose. Pour les assureurs et les établissements financiers, ce point peut être éliminatoire.
Microsoft Copilot M365 : même problème, dépendance renforcée
Microsoft Copilot for Microsoft 365 présente un profil similaire sur les dimensions souveraineté, avec une complication supplémentaire : la dépendance à l'écosystème Microsoft.
Microsoft propose des options de résidence des données en Europe (EU Data Boundary) et s'engage à ne pas utiliser les données client pour entraîner ses modèles dans le cadre de son offre entreprise. Ces engagements sont contractuellement réels. Ils ne résolvent pas le problème CLOUD Act — Microsoft est une entreprise de droit américain — et ils ne permettent pas de déploiement hors de l'infrastructure Microsoft. La souveraineté reste une souveraineté contractuelle, pas une souveraineté architecturale.
La dépendance à l'écosystème Microsoft ajoute un risque stratégique distinct. Une organisation qui déploie Copilot comme couche d'IA sur M365 construit une dépendance profonde envers un seul fournisseur : traitement de texte, email, stockage documentaire, visioconférence, ET intelligence artificielle. DORA considère explicitement cette concentration comme un risque ICT à gérer et à documenter. Les entités financières qui reposent intégralement sur Microsoft pour leur infrastructure numérique font face à des exigences de documentation et de plans de continuité qui peuvent être difficiles à satisfaire.
Par ailleurs, Copilot M365 opère sur les données présentes dans l'environnement M365. Si votre base documentaire est fragmentée entre M365 et d'autres systèmes — ERP, GED métier, bases réglementaires sur des infrastructures spécifiques — Copilot ne couvre pas l'ensemble de la connaissance d'entreprise. C'est une limite fonctionnelle importante pour les cas d'usage de knowledge management complet dans les grandes organisations.
Ce que les RSSI doivent exiger dans un RFP IA
La grille d'évaluation pour un RSSI qui évalue des solutions de knowledge management IA doit inclure, comme prérequis non négociables, les dimensions suivantes :
Architecture d'inférence. L'inférence s'exécute-t-elle dans votre infrastructure, ou dans celle du prestataire ? Peut-on obtenir une documentation architecturale — pas seulement contractuelle — qui démontre que les données ne quittent pas le périmètre lors du traitement ? La réponse doit être vérifiable, pas seulement déclarée.
Localisation des représentations sémantiques. Les représentations vectorielles de vos documents sont-elles stockées dans votre infrastructure ou dans celle du prestataire ? Ces représentations ne sont pas le texte original, mais elles permettent une reconstruction partielle du contenu — leur localisation est soumise aux mêmes exigences de souveraineté que les documents sources.
Mode déconnecté ou air-gap. Existe-t-il un mode de déploiement dans lequel le système fonctionne sans aucune dépendance réseau externe lors de l'inférence ? Pour les environnements fortement régulés ou traitant des données classifiées, la réponse doit être oui, avec une documentation architecturale à l'appui.
Piste d'audit structurée. Le système génère-t-il une piste d'audit complète de chaque requête, chaque document récupéré, chaque citation produite ? Cette piste est-elle stockée dans votre infrastructure, sous votre contrôle, dans un format exploitable pour les auditeurs réglementaires ? La capacité à démontrer, lors d'un contrôle, ce que votre IA a utilisé pour produire une réponse spécifique est une exigence réglementaire croissante — en matière de Glass Box AI, le principe est que chaque sortie doit être traçable jusqu'à sa source.
Droits d'audit sur le prestataire. Dans quelle mesure pouvez-vous exercer des droits d'audit directement chez le prestataire ? Pour les entités soumises à DORA, la réponse doit aller au-delà des certifications standardisées et permettre des audits directs conformément aux exigences réglementaires en vigueur.
Isolation des espaces de connaissance. Pour les organisations avec plusieurs entités, clients, ou projets sensibles, le système permet-il une isolation stricte des bases documentaires ? Peut-on garantir qu'une requête dans un contexte donné ne peut jamais atteindre les documents d'un autre contexte ? Cette exigence, détaillée dans l'analyse du risque de contamination croisée dans les cabinets de conseil, est critique pour toute organisation gérant plusieurs mandats confidentiels simultanément.
Le positionnement des alternatives souveraines
Les alternatives souveraines à Glean et Copilot se positionnent précisément sur les limites que ces outils présentent pour les entreprises régulées. Elles partagent plusieurs caractéristiques : déploiement on-premise ou en infrastructure privée, inférence sans appel à des API externes, piste d'audit structurée conservée dans l'infrastructure du client, et isolation des espaces de connaissance par entité ou projet.
La comparaison fonctionnelle est honnête : les outils souverains ont généralement moins d'intégrations SaaS prêtes à l'emploi que Glean, et moins d'intégration avec l'écosystème M365 que Copilot. Pour les entreprises dont la base documentaire est principalement dans des systèmes on-premise, des GED métier, ou des documents réglementaires sur des serveurs internes, cette limite est moins contraignante qu'il n'y paraît.
Scabera est conçu pour le cas d'usage knowledge management en infrastructure privée : indexation de documents internes, retrieval grounded et cité sous forme de Glass Box AI, déploiement sans dépendance à des API cloud externes. Pour les RSSI dont le mandat inclut la souveraineté des données d'entreprise et la conformité DORA/NIS2, c'est l'architecture qui élimine les compromis réglementaires plutôt que de les gérer contractuellement.
La question n'est pas "Glean ou souverain?" — c'est "quel niveau d'exposition résiduelle êtes-vous prêt à accepter, et que se passe-t-il quand votre RSSI devra justifier ce choix devant un auditeur réglementaire ?" Pour les entreprises françaises régulées, la réponse tend de plus en plus vers une exigence architecturale de souveraineté, pas seulement contractuelle.
Pour voir comment Scabera se positionne face aux outils de knowledge management cloud dans un contexte réglementé français, demandez une démonstration.