Exclure un site SharePoint de Copilot : les 3 méthodes en 2026

Depuis le 31 juillet 2026, Microsoft bloque toute nouvelle activation de la recherche SharePoint restreinte. La méthode que la plupart des administrateurs connaissent pour retirer un site des réponses de Copilot n'est donc plus disponible aux nouveaux entrants. Selon Microsoft (Learn, juillet 2026), la fonctionnalité est en cours de mise hors service et les organisations sont orientées vers la découverte de contenu restreint.

Ce changement arrive au moment où les déploiements Copilot s'accélèrent. Il oblige à reposer une question simple : quelles méthodes existent réellement pour empêcher un site SharePoint d'alimenter Copilot, et laquelle correspond à votre situation.

Pourquoi un site SharePoint remonte dans les réponses de Copilot

Microsoft 365 Copilot n'ouvre aucun accès nouveau. Il s'appuie sur les autorisations et les accès déjà en place dans le tenant. Un utilisateur qui n'a pas le droit d'ouvrir un fichier ne le verra pas apparaître dans une réponse Copilot.

Le problème est ailleurs. Copilot transforme un accès théorique en accès effectif. Un site mal configuré restait invisible tant que personne ne le cherchait. Il devient désormais une réponse formulée en langage naturel, restituée en quelques secondes.

Microsoft illustre ce mécanisme avec un exemple explicite. Un site de budgétisation contient des informations sensibles, mais son propriétaire n'a jamais configuré les autorisations correctement ni appliqué de gouvernance des données. Un collaborateur du marketing interroge Copilot sur le budget. Copilot restitue le contenu du site, parce que l'utilisateur dispose techniquement de droits sur ce site.

Une nuance compte ici. Pour un fichier partagé par un lien « Personnes de votre organisation », le contenu n'entre dans le périmètre de Copilot qu'une fois le lien ouvert par l'utilisateur. Une permission directe, l'appartenance au site ou un partage avec EEEU suffisent en revanche : l'utilisateur n'a pas besoin d'avoir déjà consulté le document pour que Copilot le lui restitue.

Ce déplacement change la nature du risque. Avant Copilot, une permission trop large produisait une exposition potentielle. Après Copilot, elle produit une exposition immédiate, à l'échelle de tous les collaborateurs qui savent poser une question. C'est ce que nous détaillons dans notre analyse des 6 risques de sécurité liés à Copilot Microsoft 365.

Un point mérite d'être posé clairement, parce qu'il conditionne tout le reste : aucune des méthodes décrites ci-dessous ne corrige une permission. Selon Microsoft (Learn, 2026), la recherche SharePoint restreinte n'est pas une limite de sécurité et ne modifie pas les autorisations sur les sites. La même réserve s'applique à la découverte de contenu restreint.

Dans un tenant Microsoft 365, exclure un site de Copilot réduit sa visibilité, jamais le périmètre des utilisateurs qui y ont accès.

Ce qui change en 2026 : le retrait de la recherche SharePoint restreinte (Restricted SharePoint Search)

La recherche SharePoint restreinte reposait sur une liste autorisée. L'administrateur y déclarait les sites dont il avait validé les autorisations. Seuls ces sites alimentaient la recherche à l'échelle de l'organisation et les expériences de conversation et d'agent Copilot.

Selon Microsoft (Learn, mise à jour du 6 juillet 2026), la fonctionnalité est en cours de mise hors service et toute nouvelle activation est bloquée depuis le 31 juillet 2026. Le retrait définitif est annoncé pour le 31 janvier 2027 (Message Center MC1395311). Microsoft l'avait toujours présentée comme une mesure temporaire, jamais comme une solution durable.

Ses limites expliquent ce retrait :

• Plafond de 100 sites dans la liste autorisée. Un site hub compte pour une seule entrée, mais ses sites associés sont inclus sans être décomptés.
• Contournement structurel. Un utilisateur retrouve toujours les fichiers qu'il possède, qu'il a récemment consultés ou qui lui ont été partagés directement, même hors liste autorisée. Le total est plafonné aux 2 000 dernières entités.
• Effet de bord sur toute l'organisation. La restriction affecte l'expérience de recherche moderne de tous les utilisateurs, y compris ceux qui n'utilisent jamais Copilot.
• Dégradation des réponses. Copilot dispose de moins de contenu à référencer, ce qui réduit la précision et l'exhaustivité de ses réponses.

La conséquence pratique est double. Les organisations qui n'ont pas encore activé la fonctionnalité ne peuvent plus le faire. Celles qui l'utilisent doivent valider leurs autorisations et planifier sa désactivation avant le 31 janvier 2027. Microsoft a précisé qu'il ne migrerait pas automatiquement les configurations existantes vers la découverte de contenu restreint : sans action, le contenu jusqu'ici masqué pourra redevenir découvrable.

Une organisation qui découvre aujourd'hui un risque de surpartage sur SharePoint ne dispose plus de la recherche SharePoint restreinte comme mesure d'urgence.

Méthode 1, la découverte de contenu restreint (RCD)

La découverte de contenu restreint, ou Restricted Content Discovery, est la méthode que Microsoft recommande désormais. Il s'agit d'un paramètre au niveau du site, applicable à SharePoint uniquement et non pris en charge pour OneDrive.

Ce que RCD fait réellement

Selon Microsoft (Learn, mise à jour du 22 septembre 2026), RCD limite la découverte du contenu d'un site dans les résultats de recherche à l'échelle de l'organisation et dans les réponses de Microsoft 365 Copilot. La fonctionnalité retire également les points d'entrée IA du site : bouton Copilot, menus d'actions IA, création d'agents et création de pages avec IA.

Trois réserves sont documentées par Microsoft. RCD ne modifie aucune autorisation existante. RCD ne retire pas le contenu de l'index de recherche Microsoft 365. Les utilisateurs déjà autorisés continuent d'accéder directement au contenu. La même page indique aussi qu'un utilisateur peut toujours retrouver le contenu qu'il possède ou avec lequel il a récemment interagi, tout en affirmant ailleurs l'inverse pour les fichiers récemment consultés. Ce comportement est à tester dans votre tenant avant de vous y fier.

Prérequis et activation

L'accès à RCD suppose une licence Microsoft 365 Copilot et les prérequis de SharePoint Advanced Management. Selon Microsoft (Learn, 2026), il suffit qu'au moins un utilisateur du tenant dispose d'une licence Copilot pour que les administrateurs SharePoint accèdent aux fonctionnalités SAM associées au déploiement Copilot. Certaines fonctions, comme la restriction de création de sites, exigent en revanche le module complémentaire SAM Plan 1.

L'activation se fait depuis le Centre d'administration SharePoint, menu Sites > Sites actifs, onglet Paramètres du site, option Restreindre le contenu de Microsoft Copilot (libellé anglais : Restrict content from Microsoft Copilot). En PowerShell :

Set-SPOSite -Identity "URL-du-site" -RestrictContentOrgWideSearch $true

La délégation aux administrateurs de site s'active au niveau du tenant :

Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true

Toute modification effectuée par un administrateur de site exige alors une justification, et les événements sont tracés dans le journal d'audit Microsoft Purview.

Le délai de propagation, souvent sous-estimé

RCD est une propriété de site qui doit se propager dans les systèmes d'indexation. Selon Microsoft (Learn, 2026), pour un site contenant plus de 500 000 éléments, la mise à jour peut prendre plus d'une semaine avant d'être pleinement reflétée dans la recherche et dans Copilot.

Sur un site SharePoint de plus de 500 000 éléments, activer RCD la veille d'un déploiement Copilot ne produit aucun effet le jour J.

Méthodes 2 et 3, contrôle d'accès restreint et étiquettes de confidentialité

RCD agit sur la détectabilité. Deux autres approches agissent sur l'accès lui-même, avec des effets très différents.

Le contrôle d'accès restreint, ou Restricted Access Control, réserve l'accès d'un site aux membres d'un groupe désigné. Selon Microsoft (Learn, mise à jour du 30 juillet 2026), les utilisateurs extérieurs au groupe spécifié ne peuvent accéder ni au site ni à son contenu, même s'ils disposaient d'autorisations préalables ou d'un lien de partage. C'est la différence de nature avec RCD : la stratégie prend effet quand l'utilisateur tente d'ouvrir le site ou le fichier.

Le périmètre est large. La stratégie s'applique aux sites connectés à un groupe Microsoft 365, aux sites connectés à Teams, aux sites non connectés à un groupe et à OneDrive, en s'appuyant sur des groupes Microsoft 365 ou des groupes de sécurité Microsoft Entra. L'activation se fait au niveau du tenant avec Set-SPOTenant -EnableRestrictedAccessControl $true, puis site par site avec Set-SPOSite -Identity "URL-du-site" -RestrictedAccessControl $true, en ajoutant au moins un groupe autorisé avec le paramètre -AddRestrictedAccessControlGroups. Pour un site connecté à un groupe, le groupe Microsoft 365 du site sert de groupe par défaut. La stratégie ne modifie pas les autorisations : pour accéder au contenu, l'utilisateur doit à la fois disposer des droits et appartenir au groupe désigné.

Les étiquettes de confidentialité déplacent le contrôle au niveau du fichier. Selon Microsoft (Learn, juin 2026), pour empêcher des fichiers d'être utilisés par les agents, il faut combiner les étiquettes avec la protection contre la perte de données Microsoft Purview, via une stratégie DLP personnalisée utilisant la condition Le contenu contient, puis Étiquettes de confidentialité. Pour Copilot dans son ensemble, la stratégie DLP doit cibler l'emplacement Microsoft 365 Copilot and Copilot Chat, avec la même condition.

L'effet mérite d'être connu avant de choisir cette voie. Les éléments identifiés apparaissent toujours en citation dans la réponse, mais leur contenu n'est pas utilisé pour la générer. Microsoft signale par ailleurs qu'une étiquette de confidentialité ne peut pas encore être appliquée directement à un fichier .agent, et recommande de passer par une condition sur l'extension.

Une annonce récente peut prêter à confusion. Le 24 septembre 2026, Microsoft a annoncé la disponibilité générale d'une fonction commune à Microsoft Purview et Microsoft Entra Global Secure Access. Elle applique les stratégies Purview au niveau du réseau : un document ou un texte sensible peut être bloqué avant d'être envoyé vers un outil d'IA non autorisé, que l'envoi vienne d'un collaborateur ou d'un agent IA agissant pour son compte. Selon Microsoft (Message Center MC1419797), le déploiement doit s'achever fin octobre 2026. Il suppose Global Secure Access, l'inspection TLS et une facturation à l'usage.

Cette fonction traite la sortie des données vers l'IA non autorisée, le « shadow AI ». Elle n'exclut aucun site de Copilot et ne réduit aucune exposition interne : un partage trop large reste lisible par Copilot et par les agents du tenant.

Bloquer la sortie protège la frontière du tenant. Corriger les permissions protège ce qui se trouve à l'intérieur.

Reste une quatrième option, encore largement citée dans les articles francophones : la case Autoriser ce site à apparaître dans les résultats de recherche, paramètre classique de SharePoint. Elle retire le site de la recherche à l'échelle de l'organisation, mais aussi de la recherche interne au site. L'expérience utilisateur se dégrade fortement pour un bénéfice de gouvernance faible.

Le choix se fait sur une seule question : voulez-vous rendre le contenu moins visible, ou en restreindre l'accès. RCD répond à la première, le contrôle d'accès restreint à la seconde.

Le point aveugle : ce que le niveau site ne montre pas

RCD s'applique à un site entier. Or une grande partie de l'exposition se joue au niveau du fichier, à l'intérieur de sites qui ne seront jamais restreints.

Le groupe Everyone except external users, ou EEEU, en est le premier vecteur. Selon Microsoft (Learn, 2026), EEEU représente l'ensemble de l'organisation sans les invités externes, et intervient dans deux scénarios distincts. Le premier est un site public, où EEEU fait partie de l'appartenance au site. Le second est un élément public, quand un utilisateur sélectionne EEEU dans le sélecteur de personnes pour partager un fichier ou un dossier précis.

Ce second cas est le plus difficile à traiter. Le partage est posé par un collaborateur, sur un fichier, à l'intérieur d'un site par ailleurs correctement configuré. Restreindre le site n'a pas de sens, et le partage échappe à toute logique de gouvernance au niveau du site.

Microsoft fournit bien un rapport dédié, mais sa portée est bornée. Les rapports de gouvernance de l'accès aux données identifient les éléments partagés avec EEEU sur les 28 derniers jours, et la vue web affiche les 100 principaux sites concernés. Un partage EEEU posé il y a six mois n'apparaît dans aucun de ces rapports d'activité. Le rapport instantané des permissions le comptabilise bien, mais sous forme de total par site : il ne dit ni quel fichier est concerné, ni qui a posé le partage.

Un détail comptable renforce cet angle mort. Selon Microsoft (Learn, 2026), créer un lien de partage ou accorder un accès à EEEU n'augmente pas automatiquement le nombre d'utilisateurs autorisés affiché dans le rapport de référence des permissions. Microsoft distingue l'exposition potentielle de l'exposition effective, celle-ci ne se matérialisant que lorsque les utilisateurs accèdent réellement au contenu.

Un tableau de bord d'administration qui affiche un nombre d'utilisateurs autorisés stable peut donc masquer une exposition potentielle massive. Ce mécanisme est au cœur des risques de surpartage SharePoint.

Masquer n'est pas corriger : que faire pendant la fenêtre RCD

Microsoft est explicite sur ce point. La découverte de contenu restreint est conçue comme un contrôle de gouvernance temporaire, destiné à donner du temps pour examiner et redimensionner les accès pendant que le déploiement Copilot se poursuit.

Microsoft met également en garde contre un usage excessif. Selon Microsoft (Learn, 2026), restreindre trop de sites réduit la quantité de contenu disponible et affecte la pertinence des réponses générées par l'IA sur l'ensemble du tenant. RCD n'est donc pas une position de repli confortable : plus la fenêtre reste ouverte, plus le déploiement Copilot perd de sa valeur.

Une autre option réduit le volume à traiter sans masquer de site entier. Selon Microsoft (Learn, septembre 2026), les stratégies et étiquettes de rétention Microsoft Purview peuvent désormais inclure une action d'archivage pour SharePoint. Les fichiers inactifs, selon leur date de création ou de dernière modification, sont déplacés vers Microsoft 365 Archive. Ils restent soumis à la rétention et aux conservations légales et restent accessibles à eDiscovery, mais ils sortent de l'indexation de Microsoft 365 Copilot. La fonction exige une licence Microsoft 365 E5 et n'est pas activée par défaut.

L'archivage traite les données dormantes, pas les partages. Un fichier actif partagé avec EEEU n'est pas concerné. De plus, tout utilisateur disposant d'un accès en lecture peut réactiver un fichier archivé : celui-ci redevient alors exploitable par Copilot, avec les mêmes permissions qu'avant.

Archiver réduit ce que Copilot peut voir. Comme RCD, cela ne corrige aucune permission.

La vraie alternative à la restriction, c'est la revue régulière des accès, des droits et des partages. Pas une fois avant le déploiement de Copilot, mais tous les six mois, comme une habitude que chaque utilisateur prend sur ses propres données.

Microsoft va dans ce sens. Sa procédure de sortie de la recherche SharePoint restreinte prévoit de lever la restriction une fois les autorisations validées. Ses politiques d'attestation de site demandent aux propriétaires de confirmer périodiquement les membres, les autorisations et les paramètres de partage de leurs sites.

C'est l'étape de correction qui détermine la durée de la fenêtre. Un administrateur peut activer RCD sur cinquante sites en une journée. Personne ne peut arbitrer seul, à l'échelle d'un tenant, la légitimité de milliers de partages posés par des milliers de collaborateurs sur plusieurs années.

Ce constat oriente la méthode. L'IT orchestre la campagne, définit le périmètre et mesure les résultats. Les propriétaires de données tranchent sur leurs propres partages, parce qu'eux seuls connaissent le contexte de chaque document. Cette logique rejoint celle des campagnes de revue des droits d'accès sur les outils collaboratifs M365.

Selon les données IDECSI (2026), une première campagne DETOX aboutit en moyenne à 7 remédiations par utilisateur, constaté sur plus d'un million d'utilisateurs traités sur la plateforme. Ce volume donne l'ordre de grandeur du travail que RCD se contente de différer. Le retour d'expérience DETOX d'Abeille Assurances et de Louis Dreyfus Company montre cette étape de correction en conditions réelles.

Pour préparer cette étape, notre checklist technique de préparation du tenant M365 à Copilot détaille les contrôles à mener en amont.

Conclusion

Le retrait de la recherche SharePoint restreinte ne supprime pas une capacité, il supprime une illusion. La liste autorisée de 100 sites donnait le sentiment d'un périmètre maîtrisé, alors qu'elle laissait passer tout ce qu'un utilisateur avait déjà consulté ou reçu en partage.

La découverte de contenu restreint est un outil plus granulaire, mais elle ne fait pas disparaître ce contournement : selon la documentation Microsoft, un utilisateur peut toujours retrouver le contenu qu'il possède ou avec lequel il a récemment interagi. Surtout, il faut comprendre ce qu'elle fait : elle achète du temps. Elle ne réduit ni le nombre de personnes ayant accès à un contenu, ni le nombre de partages posés au fil des années. Le compteur tourne pendant que la restriction est active.

La question à se poser avant d'activer RCD n'est donc pas quels sites masquer, mais combien de temps il faudra pour ne plus avoir à les masquer. Un checkup de tenant permet de cartographier les partages à risque et d'estimer cette durée.

Evaluez l'exposition de vos données · Échanger avec un expert IDECSI