Copilot ne trouve pas vos documents SharePoint — et ce n'est pas la faute de Microsoft

Microsoft annonce 20 millions de paid seats Copilot. Les threads Q&A se multiplient sur la même plainte : Copilot ne retrouve pas les documents SharePoint.

Microsoft a annoncé en mars 2026 plus de 20 millions de paid seats Microsoft 365 Copilot, soit un triplement en six mois (WindowsNews, mars 2026). Pendant ce temps, sur le portail Microsoft Q&A, plus de six threads ouverts entre avril et mai 2026 disent la même chose dans des mots différents : « Copilot ne trouve pas mes documents SharePoint », « il invente des réponses », « la recherche est inconsistante » (Microsoft Learn — Q&A, fil ouvert 24 avril 2026). Le 24 avril 2026, un incident référencé sur le support NHSmail décrit une Service Degradation de Copilot Power Platform — users not receiving search results with SharePoint as a knowledge source (NHSmail Support, 24 avril 2026).

Si vous êtes DSI, CDO ou Head of Knowledge Management dans un grand groupe qui a déployé Copilot en 2025, vous avez probablement entendu — ou prononcé — l’une de ces phrases. Et vous avez sans doute écrit à votre TAM Microsoft. C’est l’erreur d’attribution la plus coûteuse de la décennie. Voici pourquoi.

La promesse Copilot vs la frustration terrain

Le scénario type se déroule comme suit. Une grande entreprise déploie Copilot M365. Quelques semaines plus tard, les utilisateurs remontent trois plaintes récurrentes. La première : « Je sais que ce document existe, Copilot ne le trouve pas. » La deuxième : « Il me cite un contenu obsolète au lieu de la dernière version. » La troisième, la plus inquiétante : « Il invente une procédure qui ressemble vaguement à ce qu’on fait, mais qui n’est pas la nôtre. »

La réponse instinctive d’un comité de direction est de mettre la pression sur Microsoft. C’est ce que je vois chaque semaine en clientèle. La réponse instinctive d’une DSI est de relancer un projet de gouvernance d’accès : sensitivity labels, restricted search, audit DLP. C’est ce que pousse l’écosystème de tiers — AvePoint, Syskit, Glean — chacun avec sa boîte à outils (AvePoint Confidence Platform, fév. 2026).

Les deux réflexes loupent la même cible. Microsoft n’a pas un problème de modèle. La plomberie d’accès n’a pas un problème de configuration. Le problème est dans le corpus que Copilot interroge.

Microsoft a documenté le problème — personne ne lit la doc

Le verrouillage technique est public et précis. Microsoft Learn documente, depuis fin 2025, plusieurs contraintes qui suffisent à expliquer une part importante des échecs Copilot que les ICP attribuent à Microsoft.

Premièrement, pour qu’un declarative agent SharePoint parcoure l’intégralité du contenu pertinent, Microsoft recommande de se limiter à vingt fichiers, ou à trois cents pages au total ; pour les fichiers embedded, sept cent cinquante à mille pages par fichier maximum (Microsoft Learn — Optimize Content Retrieval). Au-delà, Copilot ne parcourt plus la totalité du document — il échantillonne. Deuxièmement, pour les knowledge sources d’un agent Copilot Studio, l’upload direct est plafonné à 512 Mo par fichier ; et lorsqu’un agent référence un fichier SharePoint directement, sans que Copilot M365 soit licencié dans le même tenant, la limite chute à 7 Mo pour cause de contraintes mémoire (Microsoft Learn — Copilot Studio quotas). Troisièmement, Restricted SharePoint Search (RSS) est plafonné à cent sites dans la liste autorisée et est documenté par Microsoft comme « short-term solution, not scalable, not a security boundary » (Microsoft Learn — Restricted SharePoint Search). Quatrièmement, l’indexation est quotidienne pour les sites multi-utilisateurs, pas temps réel. Un document publié à 9 h n’est pas garanti d’être interrogeable à 11 h.

Quatre contraintes de documentation officielle. Aucun cabinet de conseil francophone que je connaisse ne les cite ensemble. Aucun comité de pilotage Copilot que j’ai rencontré ne les a vues. Et pourtant : si votre patrimoine SharePoint comporte des fichiers PDF de 80 pages issus du juridique, des decks PPTX de 300 Mo issus de la finance, des bibliothèques de plus de 1 000 documents — autrement dit, si votre SharePoint ressemble à celui d’un grand groupe — alors Copilot ne peut tout simplement pas vous restituer ce que vous attendez.

Le mécanisme : Copilot fait ce qu’on lui dit, votre corpus dit n’importe quoi

Au-delà des contraintes techniques, il y a la qualité documentaire elle-même. Et c’est sur cette couche que le diagnostic devient inconfortable.

Un Copilot M365 — comme un agent Glean, un assistant Sana, un MCP Sinequa — est un système RAG. Il récupère un sous-ensemble de documents jugés pertinents, puis demande à un LLM de répondre à partir de ces documents. La qualité de la sortie est plafonnée par la qualité de ce qui a été récupéré. Or, qu’est-ce qu’un SharePoint d’entreprise réel contient ?

Des doublons divergents : trois versions d’une même procédure, dans trois sites différents, avec trois numéros de page différents. Des contenus obsolètes : une politique RH archivée en 2022 que personne n’a marquée comme telle. Des nommages cryptiques : « doc final v3 vrai final.docx ». Des métadonnées inexistantes : aucun owner, aucune date de revue, aucune classification de sensibilité. Des conflits entre documents : un référentiel sécurité qui dit « mot de passe 12 caractères minimum » et un autre qui dit « 14 caractères ». C’est ce qu’on observe systématiquement quand on audite un référentiel documentaire d’entreprise. Lors d’un premier diagnostic K-AI sur un seul référentiel d’une organisation grand groupe, nous avons détecté plus de 1 300 anomalies — conflits, doublons divergents, contenus obsolètes. Ce n’était qu’un référentiel parmi des dizaines dans cette même maison.

Demander à Copilot de retrouver la procédure d’approbation d’un investissement supérieur à 5 M€ dans ce paysage, ce n’est pas demander un retrieval. C’est demander un miracle. Le LLM ne ment pas — il rapporte fidèlement ce que le retrieval lui a tendu. Et si le retrieval lui a tendu trois versions concurrentes, il en choisit une. Souvent la mauvaise. C’est ce que SPS, agence SharePoint indépendante, formule sans détour : « You cannot get reliable outputs from an unreliable corpus. Garbage in, confident misinformation out, at speed, at scale, to every employee who asks » (SharePointSupport, mai 2026).

La même mécanique explique pourquoi, selon un panel multi-fournisseurs publié en 2026, plus de 70 % des déploiements RAG en entreprise échouent avant la production — et que le retrieval est le point de défaillance dans 73 % des cas (dev.to, 2026 ; Rag About It, 2026). Copilot M365 est un RAG. Il ne fait pas exception à cette règle. Il l’illustre à grande échelle.

RSS, RCD, SAM : pourquoi la plomberie d’accès ne suffira pas

Microsoft propose plusieurs leviers pour réduire ces frottements. Restricted SharePoint Search limite Copilot à une liste de 100 sites autorisés. Restricted Content Discovery (RCD) — annoncé en preview en mars 2026, GA prévu courant 2026 — permet d’exclure du contenu de la recherche organisationnelle même quand l’utilisateur y a accès (Microsoft Learn — Restricted Content Discovery). SharePoint Advanced Management (SAM) propose un cycle de vie de site et des rapports DAG (Data Access Governance) (Microsoft Learn — Get ready for Copilot with SAM).

Ces leviers traitent la plomberie d’accès : qui voit quoi. Ils ne traitent pas la qualité du contenu lui-même. Un document obsolète reste obsolète après avoir été retiré de RSS. Trois versions concurrentes d’une procédure restent trois versions concurrentes après application du sensitivity label. SAM n’a pas été conçu pour gérer la qualité documentaire d’un patrimoine, pas plus que la limite de 100 sites de RSS n’a été conçue pour passer à l’échelle d’un grand groupe — Microsoft l’écrit explicitement (Microsoft Learn — RSS limitations).

C’est une distinction qu’il faut tenir. Microsoft a produit un outil de gouvernance d’accès, pas un outil de qualité documentaire. Glean a produit un knowledge graph cross-SaaS, pas un outil de qualité documentaire. AvePoint a produit des analyses d’engagement et de cleanup massif, pas un outil de qualité documentaire. La couche manquante — l’audit, la déduplication, la détection de conflits, le marquage d’obsolescence, la traçabilité — est ailleurs.

Ce qu’un Document Knowledge Platform fait avant Copilot

C’est exactement la définition d’un Document Knowledge Platform (DKP), telle que je l’ai posée la semaine dernière dans le pillar du 18 mai (K-AI — Démêler KM, Knowledge AI et DKP). Un DKP est la couche en amont du Knowledge AI — en amont de Copilot, de Glean, de Sana, de Sinequa. Sa mission n’est pas de répondre aux questions. Sa mission est de rendre le corpus interrogeable : déduplication, détection de conflits inter-documents, marquage d’obsolescence non déclarée, normalisation des métadonnées, traçabilité de l’origine et de la dernière revue. C’est la transposition au non-structuré de ce qu’un Data Catalog fait depuis dix ans au structuré.

Sur un périmètre audité par K-AI, l’effet est mesurable en quelques semaines : sur un référentiel donné, nous observons typiquement une réduction du volume documentaire de l’ordre de 30 % en une semaine (doublons et obsolètes retirés), puis une réduction des conflits documentaires de l’ordre de 40 % au bout d’un mois de surveillance continue. Ce sont les chiffres d’un référentiel — pas d’un patrimoine entier. Un grand groupe non-tech en compte des dizaines.

Une fois le corpus traité, Copilot fonctionne. Pas miraculeusement — fonctionnellement. Il retrouve ce qu’il doit retrouver, parce qu’il n’y a plus trois versions de la procédure mais une. Il ne fabrique plus une procédure inexistante, parce que la procédure existante a maintenant un owner, une date de revue, et une signature de validation que le LLM peut citer. La performance d’un Copilot — d’un Knowledge AI au sens large — se mesure à la qualité du corpus en entrée, pas à la sophistication du modèle.

C’est pour cette raison que je préfère, quand un comité de direction me dit « Copilot ne fonctionne pas », leur poser une question préalable : avez-vous d’abord audité le corpus ? Dans 80 % des cas, la réponse est non. Dans les 20 % restants, l’audit a été fait à la main, sur Excel, par une équipe Knowledge Management qui n’a vu que ce qu’elle pouvait voir à l’œil nu. C’est précisément ce qu’un DKP outille à grande échelle.

Foire aux questions (FAQ)

Pourquoi Copilot ne trouve-t-il pas mes documents SharePoint ?

Trois familles de causes coexistent. La première est technique : les fichiers dépassent les seuils documentés par Microsoft (vingt fichiers et trois cents pages au total pour un declarative agent SharePoint, 512 Mo en upload Copilot Studio direct, 7 Mo pour un fichier SharePoint accédé directement sans licence Copilot M365 dans le même tenant). La deuxième est la gouvernance d’accès : permissions trop larges, Restricted SharePoint Search activé sur trop ou trop peu de sites, indexation quotidienne (et non temps réel). La troisième — et c’est celle que les comités sous-estiment — est la qualité du corpus lui-même : doublons divergents, contenus obsolètes non marqués, métadonnées manquantes, nommages cryptiques. Les deux premières familles relèvent de Microsoft Learn et de l’écosystème SAM/AvePoint. La troisième relève d’un Document Knowledge Platform.

Quelles sont les limites de taille de fichier Copilot pour SharePoint ?

Microsoft documente plusieurs seuils. Pour qu’un declarative agent SharePoint parcoure intégralement le contenu pertinent, limitez-vous à vingt fichiers ou trois cents pages au total ; pour les fichiers embedded, sept cent cinquante à mille pages par fichier maximum (Microsoft Learn — Optimize Content Retrieval). Pour les knowledge sources d’un agent Copilot Studio, l’upload direct est plafonné à 512 Mo par fichier ; lorsque l’agent référence un fichier SharePoint directement sans que Copilot M365 soit licencié dans le même tenant, la limite chute à 7 Mo (Microsoft Learn — Copilot Studio quotas). Au-delà de ces seuils, le contenu peut être présent dans SharePoint sans être effectivement interrogeable par Copilot.

Faut-il activer Restricted SharePoint Search (RSS) ?

Oui à court terme, comme rampe d’accès pour un déploiement progressif. Non comme stratégie long terme. Microsoft documente RSS comme « short-term solution, not scalable, not a security boundary » et plafonne la liste autorisée à 100 sites. C’est conçu pour vous permettre d’apprivoiser le déploiement, pas pour absorber le périmètre documentaire d’un grand groupe. Au-delà des 100 sites, ou dès que la gouvernance d’accès doit être centrale plutôt que périphérique, la bonne réponse est ailleurs — Restricted Content Discovery, sensitivity labels, et surtout audit du corpus en amont. Source : Microsoft Learn — Restricted SharePoint Search.

Pourquoi Copilot hallucine-t-il sur du contenu SharePoint ?

La plupart des hallucinations Copilot constatées en clientèle ne sont pas des hallucinations au sens strict : ce sont des restitutions fidèles d’un corpus dégradé. Le moteur RAG récupère deux ou trois documents pertinents — par exemple, trois versions concurrentes d’une procédure RH — et le LLM en choisit un pour répondre. Du point de vue de l’utilisateur, la réponse semble inventée parce qu’elle ne correspond pas à la version officielle. En réalité, le LLM a parfaitement fait son travail sur un corpus qui n’avait pas une version officielle. La parade n’est pas dans le LLM — elle est dans la résolution des conflits documentaires, le marquage d’obsolescence, et la nomination d’un owner unique par procédure.

Comment évaluer la qualité de mon corpus SharePoint avant un projet Copilot ?

L’audit doit couvrir six axes mesurables, que K-AI a publiés en méthode le 15 mai 2026 : anomalies internes (ruptures de cohérence dans un même document), conflits inter-documents (deux référentiels qui se contredisent), doublons divergents (plusieurs versions d’un même document), obsolescence non marquée, traçabilité (auteur, date, validation, source de vérité), fraîcheur par segment (K-AI — Audit corpus IA en 6 axes). Chacun de ces axes peut être chiffré, comparé à un seuil d’alerte et tracé dans un journal d’audit conforme à l’Article 12 de l’AI Act. Pour un déploiement Copilot en grand groupe, l’audit du corpus SharePoint devrait précéder l’activation des seats — et pas l’inverse.

Pour aller plus loin

Si vous démarrez un déploiement Copilot M365 sur un patrimoine SharePoint d’envergure et que vous voulez objectiver l’état du corpus avant d’engager le budget seats, contactez-nous : contact@k-ai.ai. Un diagnostic ciblé sur un référentiel pilote livre, en quelques jours, une cartographie des anomalies et un plan d’action priorisé sur l’impact Copilot attendu.

Sources citées

WindowsNews — Microsoft 365 Copilot Hits 20M Paid Seats (mars 2026) — https://windowsnews.ai/article/microsoft-365-copilot-hits-20m-paid-seats-enterprise-ai-adoption-governance-roi.415952
NHSmail Support — Microsoft 365 Alert: Service Degradation Copilot Power Platform — users not receiving search results with SharePoint as a knowledge source (24 avril 2026) — https://support.nhs.net/article/microsoft-365-alert-service-degradation-copilot-power-platform-users-not-receiving-search-results-with-sharepoint-as-a-knowledge-source/
Microsoft Learn — Optimize Content Retrieval in Your Agent — https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/optimize-content-retrieval
Microsoft Learn — Copilot Studio quotas and limits — https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-quotas
Microsoft Learn — Restricted SharePoint Search — https://learn.microsoft.com/en-us/sharepoint/restricted-sharepoint-search
Microsoft Learn — Restricted Content Discovery — https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery
Microsoft Learn — Get Ready for Copilot with SharePoint Advanced Management — https://learn.microsoft.com/en-us/sharepoint/get-ready-copilot-sharepoint-advanced-management
AvePoint — Confidence Platform February Updates (fév. 2026) — https://www.avepoint.com/blog/solutions-blog/avepoint-updates-february-2026
SharePointSupport — SharePoint Copilot-Ready: AI Readiness Guide (mai 2026) — https://sharepointsupport.com/blog/sharepoint-copilot-ai-readiness-enterprise-2026
dev.to — 70% of Enterprise RAG Deployments Fail Before Production (2026) — https://dev.to/gabrielanhaia/70-of-enterprise-rag-deployments-fail-before-production-heres-what-kills-them-26ml
Rag About It — The Engineering Gap: Why 73% of Enterprise RAG Systems Fail (2026) — https://ragaboutit.com/the-engineering-gap-why-73-of-enterprise-rag-systems-fail-where-they-matter-most/