Vous cherchez à n’afficher dans Microsoft Lists que les lignes appartenant au groupe du lecteur (PU Group, GR&A Group) ? Voici des stratégies éprouvées — sécurité par élément et automatisation Power Automate — avec procédures détaillées, modèles de flux et bonnes pratiques.
Restreindre la visibilité des éléments d’une Microsoft List en fonction d’un groupe SharePoint
Vue d’ensemble de la question
Objectif : faire en sorte que les membres de chaque groupe SharePoint (« PU Group » et « GR&A Group ») ne voient que les éléments dont la colonne Division/Group correspond à leur propre groupe. Autrement dit, on veut une sécurité par élément (item‑level security) gouvernée par une colonne métier.
Réponse & solutions proposées
| Approche | Ce qu’elle permet | Étapes essentielles | Limites / points d’attention |
|---|---|---|---|
| Permissions item par item (native) | Sécuriser réellement chaque élément | 1. Clic droit › Gérer l’accès › Paramètres avancés. 2. Arrêter l’héritage des autorisations. 3. Supprimer les groupes par défaut (Members, Visitors). 4. Accorder l’accès uniquement au groupe concerné (PU Group ou GR&A Group). | • Fastidieux si la liste est longue. • 50 000 éléments avec autorisations uniques max. • Les propriétaires du site voient toujours tout. |
| Automatisation avec Power Automate | Appliquer la méthode ci‑dessus automatiquement à chaque création/modification | Créer un flux : – Déclencheur « When an item is created or modified ». – Action « Stop sharing an item or a file ». – Action « Grant access to an item or a file » ciblant le groupe indiqué dans la colonne Division/Group. | • Requiert un peu de développement Power Automate. • Les versions gratuites du service suffisent en général. |
| Solutions de contournement | Réduire l’exposition sans sécuriser | – Vues filtrées par groupe. – Listes distinctes par division. – Bibliothèque de documents avec dossiers et autorisations. | • Les vues filtrées n’empêchent pas l’accès via la recherche ou via les API. • Plus de listes / sites = plus de maintenance. |
Informations complémentaires utiles
- Audience targeting (ciblage d’audience) ne fonctionne actuellement que sur des pages, des webparts ou des documents, pas sur une colonne de liste SharePoint Online.
- Si vous optez pour les autorisations uniques à grande échelle, surveillez les performances : au‑delà de 5 000 éléments avec héritage rompu, l’affichage peut ralentir.
- Pour un déploiement à long terme, envisagez de :
- Centraliser les règles dans Power Automate (plus simple à maintenir que du code PnP/PowerShell) ;
- Documenter la procédure de récupération des droits pour un administrateur (en cas d’erreur de flux) ;
- Utiliser des Groupes Microsoft 365 plutôt que des groupes SharePoint classiques si plusieurs services (Teams, Planner, etc.) partagent la même population d’utilisateurs.
Pourquoi les vues filtrées ne suffisent pas
Une vue filtrée masque visuellement des lignes, mais n’empêche ni la recherche, ni l’accès direct par URL, ni l’accès via les API (Graph/REST). Dès que la donnée est sensible, la seule mesure robuste est la sécurité par élément (autorisations uniques). Les vues servent au confort, pas à la protection.
Architecture recommandée
- Une seule liste (source de vérité) avec une colonne Division/Group (type : Choix ou Texte), contenant exactement les libellés de vos groupes (ex. PU Group, GR&A Group).
- Deux groupes cibles dans le site SharePoint : PU Group et GR&A Group. Idéalement, mappez-les à des Groupes Microsoft 365 si vous utilisez Power Automate.
- Un flux Power Automate qui :
- romp le lien d’héritage pour l’élément (stop sharing),
- attribue le rôle Lecture ou Modification au groupe qui correspond à la valeur de la colonne,
- gère les changements (si un élément passe de PU → GR&A, les anciennes autorisations sont retirées avant d’accorder les nouvelles).
Guide pas à pas — méthode native sur un élément
- Ouvrez l’élément dans votre liste > Gérer l’accès > Paramètres avancés.
- Cliquez sur Arrêter l’héritage des autorisations.
Option : ne pas copier les autorisations existantes pour repartir d’une page blanche. - Supprimez l’accès des groupes par défaut (Members, Visitors) si présents.
- Ajoutez uniquement le groupe cible (ex. PU Group) avec le niveau de permission désiré (Lecture ou Modification).
- Validez et testez avec un utilisateur de ce groupe : il doit voir l’élément ; un utilisateur de l’autre groupe ne doit pas le voir.
Cette opération est sûre mais manuelle. Elle devient vite chronophage au‑delà de quelques dizaines d’éléments.
Automatiser avec Power Automate — conception du flux
Objectif : reproduire automatiquement la séquence « rompre l’héritage → accorder au bon groupe → retirer l’ancien groupe si besoin ». Le flux s’exécute à chaque création et à toute modification de la colonne Division/Group.
Pré‑requis
- Connecteur SharePoint configuré (site et liste).
- Deux groupes opérationnels (PU Group, GR&A Group). Pour un fonctionnement optimal des actions « Grant access », visez des Groupes Microsoft 365 (adressables par e‑mail). Les groupes SharePoint « classiques » peuvent nécessiter l’approche REST décrite plus bas.
- Colonne Division/Group non vide à la création d’un élément (prévoyez une validation de formulaire ou un flux de correction).
Étapes type du flux
- Déclencheur : When an item is created or modified.
- Récupérer l’élément (Get item) pour disposer de toutes les valeurs (dont Division/Group).
- Condition : si Division/Group est vide, terminer (ou notifier).
- Stop sharing an item or a file : rompt l’héritage et réinitialise les accès.
- Grant access to an item or a file : accorde l’accès Lecture ou Modification au groupe correspondant à la valeur de la colonne.
- Si Division/Group = PU Group → accorder à PU Group.
- Si Division/Group = GR&A Group → accorder à GR&A Group.
- Option : si vous gérez des changements de valeurs, ajoutez une branche pour retirer l’ancien groupe (via REST) si l’action « Stop sharing » n’est pas systématique.
- Journalisation : ajoutez un commentaire dans un champ « Historique » ou postez un message Teams pour tracer les décisions d’accès.
Conseils d’implémentation
- Idempotence : supportez la ré‑exécution en appliquant « Stop sharing » avant chaque « Grant access ». Vous êtes alors sûr de l’état final.
- Conditions ciblées : pour éviter un coût inutile, exécutez les actions seulement si la colonne Division/Group a changé.
- Gestion des erreurs : entourez les actions de Scope avec run‑after sur has failed/has timed out pour créer une alerte et un plan de reprise (re‑tentative ou escalade).
- Tests multi‑profils : validez avec un membre de chaque groupe et avec un propriétaire de site (qui voit tout par conception).
Modèle de table de correspondance (recommandé)
Pour éviter de coder en dur des noms de groupes dans le flux, créez une petite liste « ACL Mapping » qui joue le rôle d’annuaire de sécurité.
| Division/Group | Type de principal | Identifiant (e‑mail ou ID) | Rôle par défaut |
|---|---|---|---|
| PU Group | Microsoft 365 Group | pu-group@contoso.com | Lecture |
| GR&A Group | Microsoft 365 Group | gra-group@contoso.com | Lecture |
Dans le flux, lisez cette table pour déterminer dynamiquement le destinataire et le rôle, ce qui facilite la maintenance (ajout d’un nouveau groupe sans changer le flux).
Approche avancée — Appels REST SharePoint
Si vous devez cibler des groupes SharePoint classiques ou si votre environnement restreint l’action « Grant access », utilisez l’action Send an HTTP request to SharePoint avec les endpoints REST ci‑dessous.
1) Rompre l’héritage des autorisations
POST /_api/web/lists/getbytitle('NomDeLaListe')/items(@{triggerOutputs()?['body/ID']})/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)
2) Récupérer l’ID du rôle « Read » ou « Edit »
GET /_api/web/roledefinitions/getbyname('Read')
GET /_api/web/roledefinitions/getbyname('Edit')
Stockez l’Id retourné pour l’appel suivant.
3) Récupérer l’ID du groupe SharePoint cible
GET /_api/web/sitegroups/getbyname('PU Group')
GET /_api/web/sitegroups/getbyname('GR&A Group')
4) Accorder le rôle au groupe
POST /_api/web/lists/getbytitle('NomDeLaListe')/items(@{triggerOutputs()?['body/ID']})/roleassignments/addroleassignment(principalid={GroupId}, roledefid={RoleId})
Cette approche est 100 % côté SharePoint et fonctionne même si l’action « Grant access » n’accepte pas vos groupes. Prévoyez un Scope d’annulation en cas d’échec (ex. revenir à un état par défaut : accès lecture pour les propriétaires seulement).
Alternative scriptée — PnP PowerShell
Pour des opérations de masse (migration initiale, rattrapage d’éléments historiques), un script PnP PowerShell est pratique.
# Connexion
Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/MonSite -Interactive
# Paramètres
$listName = "NomDeLaListe"
# Exemple : appliquer le groupe selon la colonne Division/Group
$items = Get-PnPListItem -List $listName -PageSize 2000
foreach ($item in $items) {
$division = $item["Division/Group"]
if ([string]::IsNullOrWhiteSpace($division)) { continue }
```
# Rompre l'héritage
Set-PnPListItemPermission -List $listName -Identity $item.Id -InheritPermissions:$false
# Retirer les groupes par défaut (exemple)
# Remove-PnPListItemPermission -List $listName -Identity $item.Id -Group "Members"
# Remove-PnPListItemPermission -List $listName -Identity $item.Id -Group "Visitors"
# Accorder selon la valeur
$targetGroup = if ($division -eq "PU Group") { "PU Group" } else { "GR&A Group" }
Set-PnPListItemPermission -List $listName -Identity $item.Id -Group $targetGroup -AddRole "Read"
```
} Exécutez d’abord sur un sous‑ensemble d’éléments et journalisez ce que le script fait (CSV d’audit conseillé).
Design de la colonne Division/Group : choix pratiques
| Type de colonne | Avantages | Inconvénients | Quand l’utiliser |
|---|---|---|---|
| Choix (Choice) | Simple, stable, pas de dépendance annuaire. | Risque d’erreurs de saisie si l’option « Saisies multiples » est activée. | Listes avec peu de groupes relativement fixes. |
| Texte (une ligne) | Liberté totale (utile avec une table de mapping). | Pas de validation native. | Quand un mapping externe détermine l’accès. |
| Personne ou groupe | Peut référencer des M365 Groups (via e‑mail) et des personnes. | Selon les environnements, moins fluide avec des groupes SharePoint « classiques ». | Si vous utilisez « Grant access » basé sur l’adresse e‑mail. |
Performance & limites à connaître
- Scopes d’autorisations uniques : évitez d’approcher 50 000 éléments avec héritage rompu dans une même liste. Au‑delà, SharePoint protège la plate‑forme et des opérations de maintenance deviennent difficiles.
- Seuil d’affichage 5 000 : construisez des vues indexées (filtres sur colonnes indexées) pour conserver des affichages réactifs.
- Débit des flux : par lots massifs, cadencez (retard aléatoire, Concurrency Control) pour éviter les collisions sur un même élément.
Plans de test (checklist)
- Création d’un élément avec Division/Group = PU Group → visible pour PU, invisible pour GR&A.
- Modification de l’élément en GR&A Group → PU perd l’accès, GR&A le gagne.
- Utilisateur propriétaire du site → voit tous les éléments.
- Recherche SharePoint : un utilisateur GR&A ne trouve pas un item PU (sécurité efficace au niveau index).
- Appel REST (ou via Excel/PowerQuery) par un utilisateur non autorisé → accès refusé.
Gouvernance & exploitation
- Journal : ajoutez une colonne « Accès défini le … » (date/heure) et « Flux / version » pour diagnostiquer.
- Procédure de secours : documentez « comment redonner l’accès aux administrateurs » (héritage → restaurer, ou attribution manuelle d’un rôle).
- Évolutions : si de nouveaux groupes apparaissent, mettez à jour la liste de mapping et ajoutez une règle au flux.
- Formation : expliquez la différence entre « masquer par vue » et « protéger par permission ».
Dépannage — erreurs fréquentes
| Symptôme | Cause probable | Correctif |
|---|---|---|
| Un membre GR&A voit des éléments PU. | L’héritage n’a pas été rompu, ou un lien de partage a été généré. | Exécutez « Stop sharing » puis « Grant access ». Supprimez les liens de partage. |
| « Grant access » échoue pour un groupe SharePoint. | Action basée sur Graph attend des destinataires adressables par e‑mail. | Utilisez l’approche REST (roleassignments) ou mappez vers un Microsoft 365 Group. |
| La modification de Division/Group n’a pas mis à jour les droits. | Le flux ne déclenche pas sur cette colonne ou la condition ignore les changements. | Assurez le déclenchement « created or modified » et ajoutez une condition « si la valeur a changé ». |
| Ralentissements lors de l’affichage de la liste. | Trop d’éléments avec héritage rompu ; vue non indexée. | Indexez les colonnes de filtre et scindez si nécessaire (archivage par année, ou listes par département). |
Modèle de flux — pseudo‑logique
Trigger: When an item is created or modified
Get item
If (isNullOrEmpty(DivisionGroup)) → Terminer/Notifier
If (DivisionGroup changed?) → Oui:
Stop sharing item
Switch (DivisionGroup):
Case "PU Group": Grant access → PU Group (Read/Edit selon règle)
Case "GR&A Group": Grant access → GR&A Group
Écrire journal (qui a accès, date)
Sinon:
Terminer (aucun changement d’accès)
Bonnes pratiques de sécurité
- Principe du moindre privilège : n’accordez que Lecture si l’édition n’est pas nécessaire.
- Minimiser les propriétaires : rappelez qu’ils voient tout par conception (et doivent être peu nombreux).
- Éviter les partages ad hoc : interdisez les liens de partage anonymes sur le site si les données sont sensibles.
FAQ
Q : Les « Autorisations au niveau des éléments » de la liste (Paramètres avancés) ne suffiraient‑elles pas ?
R : Ce réglage ne permet que « les utilisateurs ne peuvent voir que les éléments qu’ils ont créés ». Ici, on veut une visibilité par groupe, donc il ne répond pas au besoin.
Q : Peut‑on masquer une colonne différente selon le groupe ?
R : SharePoint ne propose pas de masquage conditionnel de colonnes par permissions. Pour cela, envisagez des formulaires personnalisés (Power Apps) ou des règles d’affichage, mais cela ne remplace pas les permissions d’accès aux éléments.
Q : Que se passe‑t‑il si un utilisateur appartient aux deux groupes ?
R : Il verra les éléments des deux groupes. Si ce n’est pas souhaité, créez des groupes mutuellement exclusifs ou implémentez une logique métier plus fine (ex. un groupe « Surclassement » qui l’emporte).
Q : Et la recherche Microsoft 365 ?
R : L’index respecte les permissions : un utilisateur ne peut pas trouver (ni ouvrir) ce à quoi il n’a pas accès.
Checklist de déploiement
- ✔︎ Colonne Division/Group prête et obligatoire.
- ✔︎ Groupes cibles créés et peuplés.
- ✔︎ Flux Power Automate déployé, journalisé, testé.
- ✔︎ Vues indexées construites (par division, par statut, par date).
- ✔︎ Procédure d’escalade documentée (rétablir l’héritage, remise d’accès).
- ✔︎ Communication envoyée aux équipes (ce que l’on voit/ne voit pas).
En synthèse : pour restreindre la visibilité dans Microsoft Lists « par groupe », la seule approche réellement protectrice est de rompre l’héritage et d’appliquer des autorisations uniques par élément. Faites‑le manuellement pour des besoins ponctuels, ou automatiquement avec Power Automate pour une gouvernance durable. Les vues filtrées et autres contournements restent utiles pour l’ergonomie, mais ne constituent pas une mesure de sécurité.