Dans Microsoft Planner, l’ajout d’une pièce jointe renvoie « You no longer have access to #FILENAME# » pour toute une équipe, via Teams ou le web. Ce guide montre le diagnostic, la cause SharePoint et un correctif durable, avec vérifications et scripts PowerShell.
Ce que vous observez
- L’erreur apparaît pour tous les membres d’un même groupe Microsoft 365 (et non pour l’ensemble du tenant), que Planner soit utilisé via Teams ou via tasks.office.com/planner.microsoft.com.
- La création d’un nouveau groupe fonctionne : l’ajout de fichiers y est possible, ce qui exclut un incident global côté service.
- Les utilisateurs impactés disposent de postes différents (OS, version de Teams, navigateur) : le problème n’est pas lié au poste client.
Ce qui se passe réellement côté Microsoft 365
Lorsqu’un utilisateur ajoute une pièce jointe à une tâche Planner, le fichier est téléversé dans la bibliothèque SharePoint “Documents” du site associé au groupe Microsoft 365/équipe Teams. Planner ne gère pas les droits de manière autonome : il s’appuie sur les autorisations SharePoint et sur l’appartenance au Microsoft 365 Group.
Si l’utilisateur n’a pas au minimum l’autorisation Contribuer (ou “Modifier”) sur la bibliothèque Documents, l’upload échoue et Planner affiche : “You no longer have access to #FILENAME#”. Autrement dit, le message d’erreur Planner est la conséquence d’un accès en écriture manquant sur SharePoint.
Où finissent les fichiers ?
- Chemin standard :
Documents/Planner/ouDocuments/Attachments/sur le site d’équipe SharePoint. - Dans un canal standard de Teams, le plan Planner stocke dans le site d’équipe principal.
- Dans un canal privé ou partagé, les fichiers ciblent le site SharePoint dédié au canal. Ce détail est crucial : corrigez les droits au bon endroit.
Mapping des rôles : Microsoft 365 Group → SharePoint
| Rôle Microsoft 365 Group | Groupe SharePoint associé | Droits effectifs sur “Documents” | Impact sur Planner |
|---|---|---|---|
| Owner | Site Owners | Contrôle total | OK (création, modification, pièces jointes) |
| Member | Site Members | Modifier / Contribuer | OK (ajout de fichiers autorisé) |
| Visitor (lecture) | Site Visitors | Lire | Échec (impossible d’uploader, erreur d’accès) |
| Invité (Guest) | Variable (souvent Visitor) | Souvent Lire uniquement | Échec sauf si droits “Members” ou équivalent |
Correctif rapide et validé
- Vérifier l’appartenance au groupe
Centre d’administration Microsoft 365 → Groupes → sélectionner le groupe → Membres.
- Déplacer les utilisateurs listés en Visitors (ou dans un rôle personnalisé en lecture seule) vers Members.
- Alternativement, attribuer un rôle ou une autorisation équivalente à Contribuer sur SharePoint.
- Contrôler les autorisations SharePoint
Sur le site SharePoint de l’équipe : Paramètres → Autorisations du site → Bibliothèque Documents.
- Vérifier qu’il n’y a pas de rupture d’héritage ou un niveau personnalisé restrictif empêchant l’écriture.
- Le plus simple et durable : accorder Contribuer ou Modifier au groupe Microsoft 365 complet plutôt qu’à des comptes individuels.
- Valider la résolution
- Demander aux utilisateurs de fermer et rouvrir Planner/Teams (renouvellement des jetons Azure AD).
- Créer une tâche de test et ajouter un fichier pour confirmer.
Contrôles complémentaires si l’erreur persiste
Si les utilisateurs ont bien les droits “Members” mais que l’erreur apparaît encore, examinez les situations suivantes.
| Contrôle | Pourquoi | Que faire |
|---|---|---|
| Quota ou verrouillage en lecture seule du site SharePoint | Un site ReadOnly ou sans stockage disponible empêche tout upload | Dans l’administration SharePoint, vérifier Stockage et État du site; lever un verrouillage ReadOnly si présent |
| Versioning / Approbation exigeant validation | Si “Exiger l’approbation du contenu” est activé, Planner n’orchestre pas l’état “En attente” | Dans la bibliothèque → Paramètres de version, désactiver l’approbation ou revenir aux paramètres par défaut pour tester |
| Check‑out obligatoire (extraction requise) | Planner ne réalise pas de check‑out/check‑in | Désactiver l’option “Exiger l’extraction des documents” dans les paramètres avancés de la bibliothèque |
| “Limited‑access user permission lockdown” (verrouillage) | Peut réduire silencieusement l’accès de certains utilisateurs | Désactiver la fonctionnalité au niveau du site ou accorder explicitement les droits au groupe Members |
| Règles DLP / stratégie de condition d’accès | Une politique peut bloquer le téléversement de certains contenus ou depuis des appareils non gérés | Vérifier dans le centre de conformité et les politiques d’accès conditionnel; tester depuis un appareil conforme |
| Synchronisation d’appartenance Teams ↔ Azure AD en retard | Les droits sont corrects, mais le jeton ne les reflète pas encore | Retirer/réajouter l’utilisateur au groupe ou attendre ~1h et le faire se reconnecter |
Procédure détaillée pas à pas
Identifier le site SharePoint concerné
- Depuis l’équipe Teams : ouvrir l’onglet Fichiers puis Ouvrir dans SharePoint pour atteindre le site associé au canal standard.
- Si la tâche Planner est rattachée à un canal privé/partagé, ouvrir le SharePoint du canal (URL distincte) : c’est ce site qui porte les droits à corriger.
Vérifier l’héritage des autorisations
- Sur le site SharePoint → Paramètres → Autorisations du site → Paramètres avancés.
- Ouvrir la bibliothèque Documents → Paramètres → Autorisations pour cette bibliothèque.
- Si l’alerte “Cette liste possède des autorisations uniques” apparaît, cliquer sur Restaurer l’héritage (si conforme à votre gouvernance) ou ajuster explicitement les rôles.
Assigner les droits au bon périmètre
- Privilégier des droits au niveau du groupe Microsoft 365 (Owners/Members) plutôt que des attributions individuelles.
- Éviter les combinaisons contradictoires (ex. un utilisateur à la fois Visitor et Member au travers de différents groupes).
Réglages de bibliothèque à vérifier
- Paramètres de version : désactiver temporairement l’approbation de contenu et le check‑out obligatoire pour tester.
- Limites de taille : s’assurer que la taille des fichiers ne dépasse pas les limites effectives (tenant/politique).
- Nom de fichier : supprimez caractères non pris en charge (par ex. certains symboles) et chemins trop longs.
Renouveler le jeton de session
- Dans Teams bureau : Se déconnecter puis se reconnecter, ou quitter complètement le client (icône barre des tâches → Quitter) et relancer.
- Dans un navigateur : Ctrl+F5 ou suppression du cache, puis reconnexion.
Cas particuliers et pièges fréquents
- Membres ajoutés comme “Visitors” : scénario classique après une personnalisation SharePoint. Solution : remonter les comptes dans Members ou appliquer un rôle Contribuer.
- Invités externes : par défaut en lecture. Accorder un rôle d’édition seulement si c’est conforme à la stratégie d’externalisation de votre organisation.
- Canaux privés/partagés : chacun possède un site SharePoint distinct ; corrigez les droits sur le bon site, pas seulement sur le site d’équipe principal.
- Étiquettes de confidentialité (Sensitivity labels) avec gestion des permissions : elles peuvent restreindre l’ajout de fichiers pour certains publics.
- Fonctionnalité “Limited‑access lockdown” : activée par erreur, elle bride les pages et documents pour les utilisateurs en accès limité.
- Politiques d’accès conditionnel/sessions (app enforced restrictions) : en mode navigation restreinte, l’upload peut être bloqué.
Diagnostics avancés pour administrateurs
Vérifier l’appartenance via SharePoint Online Management Shell
La commande suivante permet de confirmer la présence d’un utilisateur et son niveau de droit :
# Lister les groupes et leurs membres sur un site
Get-SPOSiteGroup -Site <URL_DU_SITE> | Get-SPOUser
Audit rapide avec PnP.PowerShell
# 1) Connexion interactive au site
Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/EquipeX -Interactive
# 2) Vérifier si la bibliothèque Documents a des autorisations uniques
$list = Get-PnPList -Identity "Documents"
$list.Title
$list.HasUniqueRoleAssignments
# 3) Lister les attributions de rôles sur la bibliothèque
Get-PnPProperty -ClientObject $list -Property RoleAssignments
$list.RoleAssignments | ForEach-Object {
$principal = Get-PnPProperty -ClientObject $_ -Property Member, RoleDefinitionBindings
[PSCustomObject]@{
Principal = $principal.Member.Title
Roles = ($principal.RoleDefinitionBindings | Select-Object -ExpandProperty Name) -join ", "
}
} | Sort-Object Principal | Format-Table -AutoSize
# 4) (Option) Restaurer l'héritage si une personnalisation bloque l'écriture
# ATTENTION: effectue une remise à plat des autorisations spécifiques à la bibliothèque
Set-PnPList -Identity "Documents" -ResetRoleInheritance
# 5) (Option) Accorder explicitement "Contribute" au groupe de Members
$grp = Get-PnPGroup -AssociatedMemberGroup
Add-PnPListRoleAssignment -List "Documents" -Principal $grp -RoleDefinition "Contribute" Repérer les canaux spéciaux
# Identifier les sites SharePoint des canaux privés/partagés d'une équipe donnée (exemple indicatif)
# (Les URL se terminent souvent par -PrivateChannel ou contiennent le nom du canal)
# Une fois identifié, répétez le contrôle des autorisations sur ce site précis.
Tests ciblés
- Avec un compte impacté, ouvrir le site SharePoint et tenter un upload manuel dans Documents. Si l’écriture échoue, le problème est côté SharePoint.
- Créer une tâche test dans Planner et joindre un fichier léger (ex. 10 Ko). Si OK, répéter avec un fichier plus volumineux.
Bonnes pratiques de gouvernance
- Administrer par le groupe : gérez l’accès via Owners/Members/Guests du Microsoft 365 Group, pas via des ajouts individuels sur SharePoint.
- Éviter les ruptures d’héritage sur la bibliothèque Documents sauf cas d’usage clairement justifié et documenté.
- Standardiser les paramètres de version (pas d’approbation obligatoire ni de check‑out requis) pour les bibliothèques supportant des applications comme Planner.
- Documenter le fonctionnement : pièces jointes Planner → Documents/Planner (ou Documents/Attachments), et rappeler les droits minimum requis.
- Former les propriétaires d’équipes à ne pas dégrader les membres en Visitors lorsqu’ils souhaitent “protéger” des dossiers ; créer plutôt une bibliothèque dédiée en lecture seule.
- Superviser les sites avec des autorisations uniques et corriger proactivement.
FAQ express
Pourquoi l’erreur mentionne « #FILENAME# » alors que le fichier n’existe pas encore ?
Planner tente de créer le fichier dans SharePoint, mais l’opération échoue à cause d’un droit manquant ; le message remonte alors un accès refusé sur le nom ciblé.
Changer les droits dans Teams suffit‑il ?
Oui, si vous modifiez l’appartenance Owners/Members/Guests du Microsoft 365 Group : cela se propage à SharePoint. En revanche, des personnalisations locales de la bibliothèque peuvent encore bloquer l’écriture.
Combien de temps pour que le correctif soit effectif ?
La propagation est généralement rapide, mais les jetons de session peuvent mettre un certain temps à refléter les changements. Demandez une reconnexion et testez à nouveau.
Dois‑je recréer l’équipe ou la bibliothèque ?
Non. En corrigeant les droits comme ci‑dessus, l’ajout de pièces jointes dans Planner refonctionne sans recréation d’équipe ni de bibliothèque.
Checklist de validation
| Étape | Action | Résultat attendu |
|---|---|---|
| Membres | Les utilisateurs sont dans Members (pas seulement Visitors) | Écriture autorisée par défaut |
| Bibliothèque | Aucune rupture d’héritage qui retire l’écriture aux Members | “Documents” hérite des droits du site |
| Paramètres | Pas d’approbation de contenu ni de check‑out obligatoire | L’upload via Planner est fluide |
| Verrous | Site non ReadOnly, stockage suffisant | Opérations d’ajout possibles |
| Politiques | DLP / accès conditionnel compatibles avec l’upload | Pas de blocage côté sécurité |
| Jetons | Reconnexion Planner/Teams après corrections | Les nouveaux droits sont pris en compte |
Exemples de remédiation
Cas A : tous les membres sont “Visitors” par erreur
- Dans Microsoft 365 Admin, basculer les utilisateurs impactés dans Members.
- Sur SharePoint, vérifier que Site Members ont au moins Modifier sur Documents.
- Rouvrir Planner → test d’ajout de fichier → OK.
Cas B : bibliothèque “Documents” avec autorisations uniques
- Constater HasUniqueRoleAssignments = True via PnP.PowerShell.
- Réinitialiser l’héritage ou réattribuer Contribute explicitement au groupe Members.
- Revalider avec un compte utilisateur impacté.
Cas C : plan hébergé dans un canal privé
- Ouvrir le SharePoint du canal privé (URL distincte).
- Répéter la vérification des droits sur Documents.
- Accorder Contribuer aux Members du canal privé puis retester.
Informations utiles à garder en tête
- Les fichiers sont créés dans :
Documents/Planner/ouDocuments/Attachments/. - Test rapide : se connecter avec un compte impacté sur le site SharePoint et téléverser un fichier. Si l’écriture échoue ici, le souci est côté SharePoint (droits/verrous/politiques).
- Administrateurs PowerShell :
Get-SPOSiteGroup -Site <URL> | Get-SPOUserpermet de confirmer la présence d’un utilisateur et un niveau équivalent à “Contribute”.
En résumé
L’erreur Planner “You no longer have access to #FILENAME#” est le symptôme d’un manque d’autorisations d’écriture sur la bibliothèque SharePoint Documents du site associé (équipe/group). En replaçant les utilisateurs dans Members, en corrigeant l’héritage et en désactivant les réglages bloquants (approbation de contenu, check‑out obligatoire, verrouillage), l’upload redevient opérationnel. Pensez à renouveler les sessions (Planner/Teams) et à vérifier les politiques de sécurité si le problème persiste.
Objectif opérationnel : garantir que le groupe Microsoft 365 (Owners/Members) dispose au minimum de Contribuer sur la bibliothèque Documents du bon site SharePoint (équipe ou canal privé/partagé). Une fois ce principe respecté, l’ajout de pièces jointes dans Planner fonctionne sans recréer ni l’équipe ni la bibliothèque.