Lors d’un partage OneDrive, le volet affiche encore l’ancien profil d’un collaborateur réembauché. Résultat : le lien pointe vers un identifiant obsolète et renvoie « Accès refusé ». Voici la procédure fiable pour corriger et éviter la réapparition du problème.
Vue d’ensemble du problème
Dans OneDrive (depuis le web ou l’application), vous sélectionnez un fichier et lancez le partage : la zone de saisie Personnes propose bien l’adresse habituelle de l’utilisateur, mais la « carte » de la personne (nom affiché, poste, photo, etc.) correspond à son ancien profil. Ce n’est pas qu’une simple coquille : sous le capot, OneDrive/SharePoint associe encore ce contact à l’ancienne identité (ancien objet Entra ID/Azure AD). Le lien de partage est donc généré pour cet identifiant obsolète, ce qui aboutit, côté destinataire, à une erreur d’autorisation :
- « Access denied » / « Accès refusé » lors de l’ouverture du lien ;
- impossibilité de voir le fichier malgré l’envoi réussi du lien ;
- recherche SharePoint/OneDrive qui continue à suggérer l’ancien affichage.
Pourquoi cela survient‑il ?
OneDrive s’appuie sur SharePoint Online. Dans chaque collection de sites (dont les OneDrive personnels), SharePoint maintient une liste cachée d’utilisateurs (« User Information List », abrégé UserInfo) qui référence toute personne ayant déjà interagi avec ce site (accès, partage, autorisations, etc.). Lorsque l’on supprime un compte puis qu’on réutilise la même adresse UPN pour créer un nouvel objet Entra ID (cas classique d’un réembauchage), l’entrée ancienne de la liste UserInfo persiste ; elle n’est pas fusionnée automatiquement avec la nouvelle identité. Résultat : le sélecteur de personnes (People Picker) et certaines opérations de partage ressortent encore l’ancien profil, générant des permissions pour le mauvais claim/SID.
Ce phénomène est local au site concerné : votre tenant peut contenir le bon utilisateur, mais le OneDrive personnel (qui est une collection de sites dédiée) conserve une entrée périmée. D’où la nécessité d’agir directement sur ce OneDrive pour purger l’enregistrement obsolète.
Solution express (recommandée)
Procédure minimale et sûre, réalisée pendant la session de dépannage :
| Étape | Interface | Action clé |
|---|---|---|
| 1 | OneDrive (propriétaire du fichier) | Dans l’URL du site personnel, ajouter :/_layouts/15/people.aspx?MembershipGroupId=0 pour ouvrir « Personnes et groupes ». |
| 2 | Sélectionner le compte qui porte l’ancien nom → Actions ▸ Supprimer de la collection de sites. | |
| 3 | Re‑partager le fichier : le nouveau profil est alors utilisé et l’accès fonctionne. | |
| 4 | Centre d’administration Microsoft 365 (option si l’utilisateur ne peut pas suivre l’étape 1) | Utilisateurs actifs → rechercher le propriétaire du fichier → onglet OneDrive → Créer un lien. Ouvrir le lien, répéter l’étape 1 pour supprimer le compte obsolète, puis re‑partager. |
Procédure détaillée pas à pas
Méthode A — depuis le OneDrive du propriétaire (la plus rapide)
- Demander au propriétaire du OneDrive (la personne qui partage le fichier) d’ouvrir son OneDrive web.
- Dans la barre d’adresse, compléter l’URL par :
/_layouts/15/people.aspx?MembershipGroupId=0
et valider. On arrive sur la page Personnes et groupes de la collection de sites, qui liste les utilisateurs du site connus. - Rechercher la personne réembauchée. On peut généralement distinguer deux entrées candidates :
- une entrée associée à l’ancien affichage (nom/prénom obsolètes),
- et, parfois, la nouvelle (après que l’utilisateur a été réinvité ou a tenté un accès).
- Sélectionner la mauvaise/ancienne entrée puis cliquer Actions ▸ Supprimer. Cette action n’efface pas l’utilisateur du tenant ; elle supprime seulement l’enregistrement local UserInfo du OneDrive.
- Revenir sur le fichier initial et partager à nouveau vers la même adresse e‑mail. Cette fois, OneDrive recrée une entrée propre pour le nouvel objet Entra ID, et le destinataire peut ouvrir le lien sans erreur.
Astuce : si le partage utilise des liens à accès direct (spécifiques aux personnes), vérifiez également le volet Gérer l’accès et retirez manuellement l’ancienne personne si elle y figure encore.
Méthode B — depuis le Centre d’administration Microsoft 365 (si assistance requise)
- Ouvrir le Centre d’administration Microsoft 365 et aller dans Utilisateurs actifs.
- Chercher le propriétaire du OneDrive, ouvrir sa fiche, onglet OneDrive, puis cliquer Créer un lien pour accéder à son OneDrive en tant qu’administrateur.
- Une fois dans ce OneDrive, ajouter à l’URL :
/_layouts/15/people.aspx?MembershipGroupId=0,
supprimer l’entrée utilisateur obsolète (mêmes étapes que ci‑dessus), puis re‑partager le fichier incriminé.
Méthode C — PowerShell (pour opérer à distance ou en masse)
Lorsque la correction doit être faite par un administrateur, sans interaction avec le propriétaire, ou sur plusieurs OneDrive/sites, utilisez SharePoint Online Management Shell.
# 1) Se connecter à l'Admin SharePoint Online
Connect-SPOService -Url https://<votre-tenant>-admin.sharepoint.com
# 2) Supprimer l'entrée UserInfo de l'ancien profil sur un OneDrive personnel
Remove-SPOUser -Site https://-my.sharepoint.com/personal/ -LoginName [user@domaine.com](mailto:user@domaine.com)
# Alternative pour un site d'équipe (avec claim complet membership)
Remove-SPOUser -Site https://.sharepoint.com/sites/ -LoginName "i:0#.f|membership|[user@domaine.com](mailto:user@domaine.com)" Après suppression, demandez au propriétaire de repartager le contenu (ou faites‑le vous‑même si vous avez le contexte). SharePoint créera la nouvelle entrée UserInfo alignée sur l’objet Entra ID actuel.
Contrôles et validations
- Vérifier la disparition de l’ancien compte dans « Personnes et groupes » du OneDrive : il ne doit plus apparaître.
- Tester en navigation privée : ouvrir le lien avec un navigateur InPrivate/Incognito connecté au compte réembauché.
- Confirmer le partage ciblé : dans Gérer l’accès, l’utilisateur doit apparaître une seule fois avec le nouveau nom.
- PowerShell : lister les utilisateurs connus du site et s’assurer que l’ancien login n’y figure plus.
Get-SPOUser -Site https://<url-du-site-ou-onedrive> | Select LoginName, DisplayName
Signes qui confirment le diagnostic
| Symptôme | Interprétation | Action associée |
|---|---|---|
| Volet de partage montre l’ancien nom | UserInfo contient une entrée périmée | Supprimer l’utilisateur depuis « Personnes et groupes » |
| Le destinataire reçoit « Access denied » | Le lien cible l’ancien claim/SID | Re‑partager après purge de l’ancien compte |
| Deux entrées semblables existent | Anciens et nouveaux objets Entra ID cohabitent | Supprimer la plus ancienne (affichage obsolète) |
Cas particuliers et pièges à éviter
- Membre d’un groupe SharePoint : si l’ancien utilisateur est encore membre d’un groupe (par exemple « Visiteurs »), le simple retrait de UserInfo peut être recréé lors d’un accès via ce groupe. Inspectez Personnes et groupes ▸ Groupes et retirez‑le aussi des groupes concernés.
- Invité (Guest) : les invités se manifestent avec des suffixes
#EXT#ou des claims spécifiques. Assurez‑vous de retirer la bonne identité (externe vs interne) si l’utilisateur a changé de statut entre temps. - Synchronisation AD Connect : si l’objet provient d’AD on‑premises, vérifiez que la suppression recrée bien un nouvel objectId côté Entra ID, et laissez la réplication se stabiliser avant de tester les partages.
- Liens « Toute personne disposant du lien » : ce scénario est différent ; le problème décrit concerne des partages ciblés sur des personnes. Les liens anonymes ne s’appuient pas sur UserInfo.
- Recherche et People cards : l’index peut mettre un peu de temps à refléter le nouveau profil (cache). L’accès, lui, doit fonctionner immédiatement après la purge + re‑partage.
Bonnes pratiques lors des réembauches
- Purger l’ancien objet Entra ID avant de créer le nouveau (supprimer l’ancienne identité puis vérifier son absence des listes d’utilisateurs récentes).
- Laisser un délai de propagation (idéalement 24 h) ou, a minima, forcer la synchronisation côté identité avant de tester les partages sensibles.
- Mettre à jour les attributs (Intitulé de poste, service, téléphone) pour éviter toute confusion dans les recherches et cartes de personnes.
- Informer les propriétaires de contenu critique (équipes juridiques, finance, RH) pour qu’ils régénèrent les partages clés après la réembauche.
- Standardiser un check post‑onboarding : ouverture de OneDrive, vérification de l’accès à une ressource partagée, validation des cartes de personnes.
Grâce à ces opérations, le partage utilisera le nouveau claim/SID de l’utilisateur réembauché et l’erreur « Access denied » disparaîtra.
Playbook d’intervention
- Identifier un propriétaire de fichier chez qui le symptôme est visible.
- Ouvrir son OneDrive et accéder à Personnes et groupes via
/_layouts/15/people.aspx?MembershipGroupId=0. - Supprimer l’entrée correspondant à l’ancien affichage du réembauché.
- Re‑partager le fichier et valider l’accès côté destinataire.
- Si la manœuvre est à répéter sur plusieurs OneDrive, basculer sur l’option PowerShell (
Remove-SPOUser).
Scripts PowerShell prêts à l’emploi
Supprimer un utilisateur obsolète d’un OneDrive personnel
# Connection à l'Admin SharePoint
Connect-SPOService -Url https://<votre-tenant>-admin.sharepoint.com
# Paramètres
$site = "https://-my.sharepoint.com/personal/"
$login = "[user@domaine.com](mailto:user@domaine.com)" # ancienne identité à purger
# Exécution
Remove-SPOUser -Site $site -LoginName $login
# Vérification
Get-SPOUser -Site $site | Where-Object { $_.LoginName -like "*$($login.Split('@')[0])*" } | Select LoginName, DisplayName Appliquer la correction en lot (liste de OneDrive)
Connect-SPOService -Url https://<votre-tenant>-admin.sharepoint.com
$usersToClean = @(
@{ Site = "https://-my.sharepoint.com/personal/alice_contoso_com"; Login = "[user@domaine.com](mailto:user@domaine.com)" },
@{ Site = "https://-my.sharepoint.com/personal/bob_contoso_com"; Login = "[user@domaine.com](mailto:user@domaine.com)" }
)
foreach ($entry in $usersToClean) {
try {
Write-Host "Nettoyage de $($entry.Login) sur $($entry.Site)..." -ForegroundColor Cyan
Remove-SPOUser -Site $entry.Site -LoginName $entry.Login
Write-Host "OK" -ForegroundColor Green
}
catch {
Write-Host "Échec: $($_.Exception.Message)" -ForegroundColor Red
}
} Checklist de diagnostic
| Question | Oui | Non | Commentaire |
|---|---|---|---|
| Le OneDrive du propriétaire est accessible ? | Obtenir un lien d’admin via M365 si besoin | ||
| L’ancien affichage apparaît dans le volet de partage ? | Confirme l’hypothèse UserInfo | ||
| L’entrée obsolète a été supprimée dans « Personnes et groupes » ? | Étape critique | ||
| Le fichier a été re‑partagé après purge ? | Regénère des permissions propres | ||
| Le destinataire ouvre le lien sans erreur ? | Tester en navigation privée |
Questions fréquentes
Supprimer l’utilisateur dans « Personnes et groupes » supprime‑t‑il ses données ?
Non. Vous ne supprimez que la référence locale du site. Le compte Entra ID et ses données associées ne sont pas affectés.
Pourquoi faut‑il re‑partager après la purge ?
Parce que le lien antérieur a été créé pour l’ancien claim/SID. Re‑partager force OneDrive/SharePoint à regénérer une permission pour la nouvelle identité.
Combien de temps pour que tout se mette à jour ?
La suppression dans UserInfo est immédiate. Les caches d’affichage (People cards, recherche) peuvent prendre plus de temps, mais l’accès au fichier doit fonctionner tout de suite après le re‑partage.
Et si la personne fait partie d’un groupe Microsoft 365 ?
Retirer l’entrée UserInfo ne modifie pas l’appartenance au groupe. Si l’accès vient du groupe, assurez‑vous que le groupe contient bien la nouvelle identité et pas l’ancienne.
Exemples d’erreurs courantes et équivalents
| Message | Contexte | Remède |
|---|---|---|
| Access denied / Accès refusé | Ouverture d’un lien ciblé | Purger UserInfo, re‑partager |
| Vous n’avez pas l’autorisation | Accès direct via URL | Réattribuer l’accès à la nouvelle identité |
| Impossible de trouver l’utilisateur | People Picker simplifie l’affichage | Ouvrir « Personnes et groupes » pour voir la liste réelle |
Bonnes pratiques d’administration (récapitulatif)
- Prévoir un runbook réembauche incluant la vérification des partages OneDrive/SharePoint critiques.
- Automatiser, si possible, une vérification post‑création de l’identité (validation d’ouverture de fichiers partagés de référence).
- Conserver un journal d’intervention par OneDrive (qui, quand, quelle entrée supprimée) pour audit interne.
- Informer les équipes support que l’URL
/_layouts/15/people.aspx?MembershipGroupId=0est l’outil le plus rapide pour traiter les incohérences d’identités dans un site.
Référence technique (rappel)
- UserInfo : liste cachée par site qui référence les utilisateurs connus du site (incluant les anciens).
- UPN réutilisé ≠ même identité : l’objet Entra ID change (nouvel objectId), d’où les incohérences si l’ancien reste en cache.
- Remove‑SPOUser : commande clé pour retirer une entrée d’utilisateur d’un site/OneDrive.
Exemples concrets
Un employé interne quitte l’entreprise, son compte est supprimé. Six mois plus tard, il est réembauché avec la même adresse. Un manager tente de lui partager un budget dans OneDrive : le volet de partage propose encore l’ancien profil. Le lien est envoyé, mais l’employé tombe sur « Access denied ». Après ouverture de Personnes et groupes et suppression de l’entrée obsolète, un nouveau partage est effectué : l’accès fonctionne instantanément.
Modèle de message à envoyer au propriétaire
Bonjour,
Nous avons identifié que le partage OneDrive vers <Prénom Nom> utilisait un ancien profil.
Merci d’ouvrir votre OneDrive et de coller ceci à la suite de l’URL :
/_layouts/15/people.aspx?MembershipGroupId=0
Dans « Personnes et groupes », supprimez l’entrée portant l’ancien nom de <Prénom Nom>,
puis re‑partagez le fichier. L’accès fonctionnera aussitôt.
Merci !Conclusion
Quand OneDrive affiche l’ancien profil d’un collaborateur réembauché, le problème n’est pas l’adresse e‑mail mais la référence locale UserInfo qui pointe vers l’ancienne identité. La correction tient en trois actions : purger l’entrée obsolète depuis « Personnes et groupes », re‑partager le contenu, puis vérifier l’accès côté destinataire. Pour les cas à grande échelle, Remove‑SPOUser s’intègre aisément dans vos scripts d’exploitation. Avec ces pratiques et quelques réflexes d’administration, vous supprimez durablement l’erreur « Access denied » liée aux réembauches et garantissez une expérience de partage conforme aux attentes.
Annexe : méthodes alternatives (PowerShell)
Rappel des commandes de la session :
# Exécuter côté SharePoint Online Management Shell
Remove-SPOUser -Site https://tenant-my.sharepoint.com/personal/USER_SITE -LoginName user@domaine.com
ou, depuis un site d’équipe classique :
Remove-SPOUser -Site https://tenant.sharepoint.com/sites/SITE -LoginName "i:0#.f|membership|user@domaine.com"
Résumé opérationnel (TL;DR) : la suggestion d’un ancien profil dans OneDrive lors d’un partage vers un réembauché vient d’une entrée périmée dans la liste cachée UserInfo du OneDrive. Ouvrez /_layouts/15/people.aspx?MembershipGroupId=0, supprimez l’entrée obsolète, re‑partagez. Si besoin, utilisez Remove‑SPOUser pour automatiser.