Une recherche SharePoint qui ne renvoie rien pour un seul utilisateur, alors que tout le monde est OK ? Voici une méthode éprouvée pour diagnostiquer rapidement, corriger les doublons d’identité (All People) et rétablir l’index — avec le cas réel SP709902.
Vue d’ensemble de la question
Un site SharePoint Online fonctionnait normalement pour toute l’organisation, sauf pour une collaboratrice qui, depuis environ une semaine, ne recevait plus aucun résultat — même avec la requête générique *. La page affichait : « Something went wrong, please refresh to try again ». Les autres utilisateurs du même site et du même groupe de filtrage Web n’étaient pas affectés.
Symptômes constatés
- Aucune réponse dans la zone de recherche (même avec
*). - Message d’erreur générique lors du chargement des résultats (Something went wrong…).
- Accès direct aux documents toujours possible via Fichiers récents (ce qui indique que l’accès aux contenus n’est pas en cause).
Tests déjà effectués (sans succès)
- Vidage du cache et des cookies navigateur.
- Réinstallation / utilisation de Chrome et Edge.
- Connexion sur un autre poste avec un profil Windows vierge.
- Vérification des autorisations sur le site et les bibliothèques.
Réponse & solution
Incident Microsoft en cours
Au moment des faits, Microsoft avait signalé l’incident SP709902 : Users’ SharePoint Online content search results may be missing or may disappear when pages load. Le problème provenait d’une discordance dans l’index de recherche provoquant une propagation incorrecte des propriétés de contrôle d’accès (ACL). En clair, l’index « croyait » que l’utilisateur n’était pas autorisé à voir les résultats, d’où le : zéro résultat + erreur générique.
Diagnostic local complémentaire
Outre cet incident global, une incohérence locale a été détectée : dans Paramètres du site ▸ Autorisations avancées ▸ Tous les utilisateurs (aussi appelée liste « All People » ou User Information List), l’administrateur a découvert deux entrées pour la collaboratrice :
- un ancien compte Microsoft (désuet, ancien UPN ou entrée invitée) ;
- le compte actif actuel.
La présence de cette identité historique créait une collision qui bloquait l’affichage des résultats, car l’index et les ACL ne faisaient plus correspondre correctement l’utilisateur réel à l’identité référencée par le site.
Remédiation
- Supprimer les entrées obsolètes dans Tous les utilisateurs (All People / User Information List).
- Ré‑ajouter uniquement le compte actuel dans les groupes SharePoint pertinents (Membres, Visiteurs, Propriétaires… selon besoin).
- Demander à l’utilisateur de se déconnecter / reconnecter et forcer une actualisation (CTRL + F5).
Résultat : la recherche a immédiatement retrouvé son fonctionnement normal.
Pourquoi ce cas survient
Dans SharePoint Online, la recherche repose sur un index qui stocke des pointeurs vers les contenus et une représentation des autorisations (via des propriétés de sécurité). Lorsque l’identité d’un utilisateur apparaît plusieurs fois dans un site (ancien UPN, compte invité B2B, duplication lors de migrations/synchronisations), l’index peut « accrocher » la mauvaise identité, ou bien l’ACL calculée ne correspond plus à l’identité avec laquelle l’utilisateur s’authentifie réellement. Un incident global de propagation des ACL (comme SP709902) peut amplifier ou révéler ce type d’incohérence utilisateur unique.
Procédure détaillée étape par étape
Valider la portée du problème
- Tester avec un autre compte membre du même groupe : si les résultats s’affichent, le problème est spécifique à l’utilisateur.
- Tester dans un autre site : si la recherche fonctionne ailleurs, la cause est probablement locale au site concerné.
Vérifier l’état du service
Dans le Centre d’administration Microsoft 365 ▸ Santé du service, consulter les incidents en cours. En présence d’un incident lié à la recherche/indexation (ex. SP709902), planifier les actions en minimisant les changements structurels et privilégier un nettoyage d’identité ciblé.
Inspecter Tous les utilisateurs (All People)
Dans le site concerné :
- Ouvrir Paramètres du site ▸ Autorisations du site.
- Cliquer sur Paramètres avancés des autorisations puis Tous les utilisateurs (ou All People / User Information List).
- Rechercher le nom / l’adresse de la personne concernée.
- S’il y a plusieurs entrées pour la même personne (ancien UPN, compte invité, variation de domaine), supprimer les entrées obsolètes (gardez uniquement l’identité actuelle).
Astuce : si l’entrée « Tous les utilisateurs » n’est pas visible, utilisez la vue classique Personnes et groupes depuis les paramètres avancés ou passez par un administrateur SharePoint pour l’ouvrir avec les autorisations appropriées. Sur un site moderne, l’option peut être masquée ; la manipulation reste possible via les paramètres hérités.
Ré‑ajouter le compte actif aux bons groupes
- Dans Personnes et groupes, vérifiez les groupes Membres du site, Visiteurs et Propriétaires (selon votre modèle d’autorisations).
- Ajoutez le compte actuel (UPN valide) et évitez les adresses obsolètes ou alias historiques.
Reindexer une bibliothèque ou le site
Si la recherche reste muette après correction des identités, lancez une réindexation ciblée :
- Bibliothèque ▸ Paramètres ▸ Paramètres avancés ▸ Autoriser l’indexation : Oui ▸ Ré‑indexer.
- Pour tout le site : Paramètres du site ▸ Recherche et disponibilité hors connexion ▸ Ré‑indexer ce site.
La réindexation reconstruit les pointeurs et les ACL stockées dans l’index.
Tester proprement
- Demander à l’utilisatrice une reconnexion (session neuve) et un CTRL + F5.
- Exécuter un test simple : requête
*, puis un mot‑clé unique présent dans un document connu, puis un filtre (type, date, auteur).
Scripts d’administration utiles (optionnel)
Nettoyer les doublons d’identité via PnP PowerShell
Exécutez ces commandes sur le site concerné :
# Connexion au site
Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/MonSite -Interactive
# Lister les utilisateurs du site correspondant à l'adresse
Get-PnPUser | Where-Object { $_.LoginName -match "[utilisatrice@contoso.com](mailto:utilisatrice@contoso.com)" } |
Select-Object Id, LoginName, Email
# Supprimer l'entrée obsolète (remplacez par l'Id trouvé)
Remove-PnPUser -Identity
# Ré-ajouter le compte actif dans le groupe adéquat
Add-PnPUserToGroup -Identity "Membres du site" -LoginName "[utilisatrice@contoso.com](mailto:utilisatrice@contoso.com)" Contrôler les doublons dans Azure AD / Entra ID
Les comptes invités ou anciens UPN peuvent persister. Vérifiez l’existence d’objets redondants :
# Connexion Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
# Rechercher l'utilisateur par UPN
Get-MgUser -UserId "[utilisatrice@contoso.com](mailto:utilisatrice@contoso.com)" | Select-Object Id, UserPrincipalName, Mail, ExternalUserState
# Lister d'éventuels comptes invités homonymes
Get-MgUser -Filter "mail eq '[utilisatrice@contoso.com](mailto:utilisatrice@contoso.com)'" | Select-Object Id, UserPrincipalName Si un « invité » (B2B) ou un ancien UPN cohabite avec le compte actif, mettez à jour les appartenances aux groupes et supprimez les références obsolètes dans les sites où elles subsistent.
Diagnostic rapide par périmètre
| Observation | Interprétation | Piste prioritaire | Action |
|---|---|---|---|
| Seule une personne n’a aucun résultat | Incohérence d’identité / ACL | Doublon « All People », compte invité, UPN changé | Nettoyage Tous les utilisateurs + ré‑ajout du compte |
| Tous les utilisateurs du site sont impactés | Problème d’index / schéma / incident global | Service Health, réindexation du site | Ré‑indexer et surveiller l’incident |
| La recherche est vide mais « Fichiers récents » fonctionne | Accès OK, index défaillant pour l’identité | ACL d’index non alignées | Nettoyer l’identité + ré‑indexer |
| La recherche fonctionne dans d’autres sites | Problème local au site | User Information List du site | Supprimer les entrées obsolètes dans le site |
Informations complémentaires utiles
| Étape préventive | Objectif | Commande/Emplacement |
|---|---|---|
| Vérifier les comptes en double | Éliminer les collisions d’identité | Paramètres du site ▸ Autorisations ▸ Tous les utilisateurs |
| Re‑indexer une bibliothèque ou un site | Régénérer l’index si la recherche reste vide après correction des autorisations | Bibliothèque ▸ Paramètres ▸ Paramètres avancés ▸ Autoriser l’indexation : Oui ▸ Ré‑indexer |
| Examiner Azure AD | Détecter d’anciens objets (comptes synchronisés, invités, B2B) | Azure AD ▸ Users |
| Ouvrir un ticket Microsoft 365 | Escalader rapidement les incidents globaux | Centre d’administration M365 ▸ Aide & support |
Checklist d’intervention
- Confirmer que le problème touche un seul utilisateur dans un seul site.
- Vérifier la Santé du service (incidents en cours, ex. SP709902).
- Comparer le UPN et l’adresse utilisée par l’utilisatrice dans M365 vs SharePoint (éviter tout alias obsolète).
- Ouvrir Tous les utilisateurs du site et supprimer les entrées obsolètes (ancien compte, invité, UPN précédent).
- Ré‑ajouter uniquement le compte actif aux groupes requis.
- Ré‑indexer la bibliothèque ou le site si nécessaire.
- Faire tester par l’utilisatrice avec une session neuve et une recherche
*.
Bonnes pratiques pour éviter la récidive
- Purger régulièrement les comptes inactifs et invités devenus inutiles.
- Utiliser un compte de test propre pour isoler les problèmes de profil utilisateur.
- Suivre le Service Health Dashboard afin d’être alerté des incidents majeurs affectant la recherche/indexation.
- Lors des changements d’UPN ou de migrations, planifier un passage de nettoyage dans Tous les utilisateurs des sites critiques.
- Éviter les ajouts manuels de comptes invités en doublon si un compte interne existe déjà.
FAQ ciblée
Pourquoi « Fichiers récents » affiche des contenus alors que la recherche est vide ?
« Fichiers récents » s’appuie sur l’historique d’activité et les accès directs de l’utilisateur. La recherche, elle, interroge l’index global avec prise en compte des ACL. Si l’identité est en conflit, l’index peut « cacher » les résultats, sans empêcher l’accès direct aux fichiers connus.
Dois-je modifier le schéma de recherche ou les propriétés gérées ?
Dans un cas utilisateur unique, non. Concentrez-vous sur l’identité dans le site (Tous les utilisateurs) et la réindexation. Le schéma intervient plutôt pour des problèmes de pertinence, de mappage de colonnes ou de résultats à l’échelle du tenant.
Et si l’utilisateur a changé d’adresse e‑mail / UPN récemment ?
C’est un déclencheur classique de doublon. Nettoyez l’ancienne identité dans chaque site critique puis ré‑ajoutez le compte actif dans les bons groupes. Vérifiez également qu’aucun compte invité de même nom ne perturbe la résolution d’identité.
Est‑ce que supprimer l’utilisateur dans « Tous les utilisateurs » supprime ses contenus ?
Non. Vous supprimez la référence de sécurité dans le site, pas les contenus. Les documents restent intacts. Après ré‑ajout du compte actif, l’accès est rétabli et l’index reflète la bonne ACL.
Exemple de plan de remédiation documenté
Pour formaliser le correctif dans un runbook, vous pouvez consigner les informations suivantes :
- Contexte : Utilisatrice A, site B, depuis J‑7, « Something went wrong » + zéro résultat, « Fichiers récents » OK.
- Hypothèse : collision d’identité + incident SP709902.
- Actions :
- Audit Tous les utilisateurs : 2 entrées trouvées.
- Suppression entrée obsolète ; conservation du compte actif.
- Ré‑ajout du compte actif au groupe Membres.
- Réindexation de la bibliothèque principale Documents.
- Reconnexion de l’utilisatrice et test avec
*.
- Résultat : résultats de recherche de nouveau visibles, erreur disparue.
- Prévention : revue trimestrielle des comptes invités / historiques, consigne UPN dans la checklist de transfert/départ.
Points d’attention
- Un doublon dans All People peut persister même après la suppression d’un compte dans Entra ID ; il faut parfois nettoyer site par site.
- La réindexation est un rafraîchissement logique de l’index ; elle ne change ni l’URL des documents ni les autorisations réelles.
- Évitez de multiplier les comptes invités pour des utilisateurs internes ; préférez le compte interne unique.
Conclusion
Lorsqu’un seul utilisateur n’obtient plus de résultats de recherche dans SharePoint Online, la cause la plus efficace à traiter est souvent une incohérence d’identité dans le site (doublon, compte invité, ancien UPN), parfois mise en lumière par un incident de propagation d’ACL côté service (ex. SP709902). Le correctif éprouvé : purger les identités obsolètes dans « Tous les utilisateurs », ré‑ajouter le compte actif dans les groupes adéquats, puis ré‑indexer si nécessaire. En procédant ainsi, la recherche retrouve généralement son comportement normal immédiatement après l’actualisation de session.
Récapitulatif opérationnel
- Vérifier la portée (un seul utilisateur / un seul site).
- Contrôler la Santé du service (incident de recherche en cours ?).
- Nettoyer les doublons d’identité dans Tous les utilisateurs.
- Ré‑ajouter le compte valide aux groupes requis.
- Ré‑indexer la bibliothèque ou le site si besoin.
- Tester avec session neuve et requête
*.