Property access dans Notion : comment fonctionnent les permissions par colonne

Jusqu'à présent, ouvrir une page de base de données Notion impliquait de voir toutes ses propriétés. Vous pouviez contrôler qui accédait à chaque page, mais ne pouviez pas masquer une colonne précise ni autoriser une personne à modifier un champ sans toucher aux autres.

Cela change avec Property access, le nom officiel des permissions par propriété ou par colonne. Cette fonctionnalité permet de décider qui voit chaque propriété, qui peut modifier ses valeurs et qui ne devrait même pas savoir qu'elle existe.

Cette nouveauté complète une partie importante du modèle de permissions de Notion, mais ajoute aussi à la complexité déjà élevée de la gestion des permissions dans Notion, surtout avec des grandes équipes.

Une chose doit être claire : Property access ne remplace pas les permissions de base de données ni le page-level access. Chaque couche résout un problème différent, et dans ce post, nous nous concentrerons uniquement sur cette nouvelle fonctionnalité fraîchement sortie de Notion.

Les trois couches de permissions dans Notion

Depuis quelques années déjà, nous répétons que bien gérer les permissions dans Notion est l'une des tâches les plus compliquées qui soient.

Cependant, pour l'instant, à un niveau macro, la façon la plus simple de comprendre les différentes couches de permissions est de les voir comme une cascade :

1. L'accès à la base de données définit le point de départ.

Ici, vous décidez si les utilisateurs ont accès ou non à l'ensemble de la base de données et avec quel type de permission.

2. Page-level access décide quelles pages précises une personne peut voir.

Ici, vous pouvez décider si un utilisateur a accès à une ou plusieurs pages spécifiques d'une base de données à laquelle il n'a pas accès.

Il peut aussi arriver qu'un utilisateur ait un accès limité à l'ensemble de la base de données avec une permission Can View, et qu'il ait une permission Can Edit pour les pages dont il est responsable ou qu'il a créées.

3. Property access décide quelles propriétés il peut voir ou modifier une fois dans une page à laquelle il a accès.

L'idée ici est que l'utilisateur puisse voir l'ensemble ou certaines pages de la base de données sans voir toutes les colonnes, uniquement celles qui l'intéressent ou celles auxquelles il a accès.

Dans ce sens, si vous donnez accès à une propriété à un utilisateur mais qu'il n'a pas accès à la page, il ne verra ni la colonne ni la page.

Que sont les permissions par colonne dans Notion

Les permissions par colonne dans Notion permettent d'établir une règle différente pour chaque propriété d'une base de données, à condition d'avoir un plan Business ou Enterprise. Chaque règle combine un niveau par défaut avec des exceptions pour des personnes, des groupes, des propriétés de type Personne ou des agents.

Par exemple, vous pouvez :

• Afficher le Statut à toute l'équipe, mais autoriser uniquement la personne assignée à le modifier.
• Masquer les Notes internes aux clients et invités.
• Montrer le Budget à un département sans autoriser sa modification.
• Permettre à un agent de mettre à jour le Statut de documentation sans lui donner accès au budget ni aux notes du client.
• Masquer les champs internes sur les pages publiées sur le web.

Avant, ces cas finissaient souvent en bases dupliquées, vues séparées ou automatisations qui copiaient les données d'un endroit à l'autre. Désormais, une seule base peut servir plusieurs audiences sans montrer les mêmes propriétés à toutes.

Comment configurer les permissions par propriété

Les règles sont créées dans la base d'origine depuis une vue tableau. Elles ne se configurent pas depuis une vue liée.

1. Ouvrez la base de données d'origine sur web ou desktop.
2. Ouvrez le menu de la propriété que vous voulez contrôler.
3. Sélectionnez Property access.
4. Définissez l'accès par défaut pour les personnes qui peuvent déjà ouvrir la base.
5. Ajoutez des exceptions pour des personnes, des groupes, des propriétés de type Personne ou des agents.
6. Choisissez le niveau correspondant pour chaque exception.
7. Utilisez Preview pour vérifier le résultat comme une autre personne.
8. Enregistrez la règle.

Un cadenas identifie les propriétés qui ont leur propre règle. Vous pouvez aussi appliquer la même configuration à plusieurs propriétés.

La première règle peut mettre quelques minutes à s'enregistrer car Notion doit déplacer les informations de cette colonne. Le temps augmente avec les bases contenant beaucoup de lignes.

Les six niveaux d'accès

Les permissions par colonne offrent six niveaux d'accès qu'il faut comprendre pour ne pas exposer de données sensibles :

1. Inherit from database. La propriété suit la permission générale que la personne a sur la base.
2. Can edit property & values. Peut modifier la configuration de la propriété et ses valeurs.
3. Can edit values only. Peut mettre à jour les valeurs, mais pas modifier la propriété.
4. Can view property & values. Voit la propriété et ses valeurs, sans pouvoir les modifier.
5. Can view property only. Sait que la propriété existe, mais ne voit pas ses valeurs.
6. No access. La propriété et ses valeurs sont masquées.

Dans la plupart des systèmes, les options les plus utiles seront Can edit values only, Can view property & values et No access. Elles permettent de séparer opération, consultation et confidentialité sans céder le contrôle du schéma de la base.

Can view property only a des cas d'usage plus spécifiques. Elle peut servir à montrer qu'une approbation ou un audit existe sans révéler son contenu. Si le champ n'apporte rien à cette audience, le masquer entièrement crée généralement une expérience plus épurée.

Un exemple pratique

Maintenant que nous avons passé en revue les permissions par colonne, tant de façon générale que plus spécifique, illustrons tout cela avec un exemple.

Imaginez une base de projets où toute l'équipe doit consulter le statut, mais où seule la personne responsable peut le modifier.

La règle pour Statut serait :

• Accès par défaut : Can view property & values.
• Exception : la personne indiquée dans Owner.
• Accès de l'exception : Can edit values only.

Le résultat semble simple, mais une deuxième question se pose : qui peut modifier Owner ?

Si n'importe qui peut s'assigner comme responsable, cette personne peut aussi obtenir la permission de modifier le Statut. C'est pourquoi, quand une exception dépend d'une propriété Personne, il faut protéger à la fois le champ final et le champ qui accorde l'accès.

Limitations et erreurs fréquentes

Full access gagne toujours

Les personnes avec Full access sur la base conservent un accès total à toutes ses propriétés. Une règle de colonne ne peut pas les restreindre.

C'est pourquoi les tests doivent être faits avec une personne qui n'a pas Full access. Tester uniquement en tant qu'administrateur peut donner une fausse image du résultat.

La permission la plus large s'applique

Si quelqu'un correspond à plusieurs exceptions, Notion applique la moins restrictive. De même quand une autre permission de la base ou de la page accorde un accès supérieur.

Quand une restriction ne fonctionne pas, il faut vérifier la configuration complète de Share, l'accès par défaut et toutes les exceptions.

Formules, rollups, boutons et automatisations respectent aussi les permissions

Un flux peut échouer ou renvoyer un résultat inattendu si la personne qui l'exécute n'a pas accès à une propriété nécessaire. Il faut tester chaque formule, bouton et automatisation avec les permissions réelles de son audience, pas en tant qu'administrateur.

Si une formule utilise des informations sensibles, il convient aussi de vérifier si son résultat révèle indirectement la donnée masquée.

Toutes les propriétés ne peuvent pas être restreintes

Actuellement, ces règles ne peuvent pas être appliquées à :

• Title;
• ID;
• Created by;
• Created time;
• Last edited by;
• Last edited time;
• certains types de propriétés synchronisées;
• relations de sous-éléments ou pages parentes.

Property access n'est pas non plus disponible dans les bases de données wiki.

Trop de règles peuvent affecter les performances

Les bases avec beaucoup de règles peuvent charger plus lentement, surtout si leurs vues filtrent, trient ou regroupent par des propriétés restreintes. La solution n'est pas d'ajouter une règle à chaque colonne sans un modèle préalable.

Comment concevoir un modèle de permissions qui ne casse pas

Un bon point de départ serait :

• Administrateurs : Full access aux bases qu'ils gèrent.
• Équipe : Can edit content ou un niveau inférieur, sans permission de modifier le schéma.
• Collaborateurs externes : accès à des pages précises via page-level access.
• Agents : uniquement les pages et propriétés dont chaque workflow a besoin.
• Propriétés sensibles : No access ou lecture seule par défaut, avec des exceptions explicites.

Gérez l'accès via des groupes dans la mesure du possible. Il est plus facile de vérifier un groupe Finance ou People Ops que de maintenir une liste d'exceptions personne par personne. Rappelez-vous que les invités ne peuvent pas appartenir à des groupes.

Ensuite, configurez base, page et propriété dans cet ordre. Enfin, testez et vérifiez aussi les vues liées, formules, boutons, modèles de base de données et automatisations.

FAQ sur Property access

Property access et page-level access sont-ils la même chose ?

Non. Page-level access contrôle quelles pages quelqu'un peut ouvrir. Property access contrôle quelles colonnes il peut voir ou modifier dans une page qu'il peut déjà ouvrir.

Les permissions par colonne donnent-elles accès à une page ?

Non. La personne a besoin d'un accès préalable à la base ou à cette page précise.

Puis-je masquer une propriété à une personne précise ?

Oui. Vous pouvez définir No access comme niveau par défaut et ajouter des exceptions pour les personnes ou groupes qui doivent la voir. Vous pouvez aussi créer une exception individuelle plus restrictive, tant qu'une permission plus large ne l'annule pas.

Puis-je restreindre des propriétés pour quelqu'un avec Full access ?

Non. Il faudrait d'abord réduire sa permission générale sur la base.

Puis-je autoriser quelqu'un à modifier des valeurs sans modifier la colonne ?

Oui. Utilisez Can edit values only.

Cela fonctionne avec les agents Notion ?

Oui. Les agents peuvent recevoir leurs propres permissions sur des propriétés. Notion AI hérite généralement des permissions de l'utilisateur qui l'exécute.

Est-ce disponible sur tous les plans ?

Non. La configuration de Property access est disponible sur Business et Enterprise.

Comment nous pouvons vous aider chez noxen studio

Les permissions par propriété permettent de maintenir une source unique de vérité pour plusieurs audiences. Le difficile n'est pas d'activer le menu, mais de décider ce que chaque rôle doit voir, d'éviter les voies d'auto-escalade et de vérifier que les vues et automatisations fonctionnent toujours.

Chez noxen studio, nous concevons l'architecture, les groupes, les règles d'accès et les tests par profil. Nous vérifions aussi quelles données chaque agent IA devrait consulter ou modifier. Le résultat est un système où chaque personne peut faire son travail sans recevoir plus d'accès que nécessaire.

Si vous voulez revoir les permissions et l'architecture de votre workspace, dites-nous ce dont vous avez besoin et réservez une discovery call.