Permissions par colonne Notion : contrôler chaque propriété

Les permissions par colonne Notion permettent, depuis la version 3.8 du 13 octobre 2026, de définir qui peut voir ou modifier chaque propriété d’une base de données, indépendamment de l’accès à la base elle-même. Le réglage se fait depuis le menu de la colonne, via « Accès à la propriété », avec six niveaux d’accès et des exceptions par personne, groupe, propriété Personne ou agent IA.

Cette fonctionnalité répond à l’une des demandes les plus anciennes de la communauté : partager une base de recrutement sans dévoiler les rémunérations, ou un CRM sans exposer les données clients sensibles. Elle est réservée aux forfaits Business et Enterprise, plafonnée à 20 propriétés protégées par base, et indisponible dans les bases wiki. J’ai configuré ces règles sur trois bases de mon workspace ; voici le tutoriel complet, les cas d’usage et les pièges à éviter.

Pourquoi cette fonctionnalité a mis des années à arriver

Jusqu’en octobre 2026, Notion ne savait gérer les droits qu’au niveau de la page et de la base de données. Une personne qui pouvait ouvrir une base voyait toutes ses colonnes, sans exception. Masquer une propriété dans une vue ne changeait rien : il suffisait d’ouvrir la page d’une entrée pour la retrouver.

Le sujet revient régulièrement sur r/Notion, sous la forme d’une même question : « comment partager seulement une partie d’une base ? ». Les réponses tournaient toujours autour des mêmes contournements : dupliquer la base sans les colonnes sensibles, créer une seconde base reliée par une relation, ou partager une vue filtrée. Aucune de ces solutions n’était propre.

Le contournement par vue filtrée était même risqué. Comme le rappelle le guide de Matthias Frank sur le partage partiel d’une base Notion, un invité pouvait exporter le contenu complet de la base, filtres compris, ce qui réduisait la protection à une simple apparence.

L’enjeu n’est pas anecdotique. Selon les synthèses publiées du rapport Verizon DBIR 2026, environ 12 % des fuites de données impliquent des acteurs internes, erreurs involontaires comprises. Pour une base RH ou un CRM, limiter ce que chaque personne peut voir relève donc de l’hygiène de base, pas de la paranoïa.

Les permissions par colonne s’appliquent après les droits de page et de ligne, et ne les remplacent pas.

Permissions de page, bases liées et permissions par colonne : trois mécanismes différents

Avant de configurer quoi que ce soit, il faut situer les permissions par colonne dans l’ensemble du système de droits de Notion. Trois couches se superposent, et chacune répond à une question différente.

Deux règles découlent de ce tableau. Premièrement, une règle de colonne n’ouvre jamais l’accès à une base que la personne ne peut pas déjà consulter : les permissions de page passent toujours en premier. Deuxièmement, une base liée reste un affichage, pas un contrôle d’accès. Si vous la partagez, c’est la base d’origine qui porte les droits.

J’ai détaillé les quatre niveaux classiques (accès complet, modification, modification du contenu, consultation) et la permission « Can create pages » de mars 2026 dans mon guide sur la collaboration dans Notion. Les permissions par colonne viennent compléter cet ensemble, sans le remplacer.

Six niveaux, quatre droits cumulatifs : quand plusieurs exceptions visent la même personne, le niveau le moins restrictif l’emporte.

Les six niveaux d’accès à une propriété

Chaque colonne protégée reçoit un niveau d’accès par défaut, puis d’éventuelles exceptions. Les intitulés ci-dessous sont ceux de l’interface française, tels que documentés dans la page d’aide « Gérer l’accès à la propriété de base de données ».

Le niveau « Peut voir la propriété uniquement » mérite une explication. La personne voit qu’une colonne « Rémunération » existe, mais ses cellules restent vides pour elle. C’est utile quand vous voulez que la structure de la base reste lisible sans exposer son contenu, par exemple pour qu’un collaborateur comprenne qu’une information est gérée ailleurs.

À l’inverse, « Aucun accès » masque à la fois le nom de la colonne et ses valeurs, dans les vues comme dans les pages. Pour la personne concernée, la propriété n’existe pas. C’est le niveau que je recommande par défaut pour les données réellement sensibles.

Tutoriel : configurer l’accès à une propriété en cinq étapes

Comptez cinq minutes par colonne, à condition de respecter trois prérequis : un forfait Business ou Enterprise, l’accès complet à la base de données, et un navigateur ou l’application de bureau. Les règles ne se créent pas sur mobile, mais elles s’y appliquent une fois enregistrées.

Étape 1 : Ouvrir le menu de la colonne dans la base d’origine

Ouvrez la base de données dans une vue tableau. Cliquez sur l’en-tête de la colonne à protéger, puis choisissez « Accès à la propriété » dans le menu déroulant.

Un point important : travaillez sur la base de données d’origine, pas sur une base liée. Les règles définies depuis une vue liée ne se comportent pas de manière fiable, et la documentation de Notion le précise explicitement.

Étape 2 : Définir l’accès par défaut

Le premier réglage concerne toutes les personnes qui peuvent ouvrir la base. Pour une colonne sensible, choisissez « Aucun accès » ou « Peut voir la propriété uniquement ». Pour une colonne que tout le monde doit consulter sans la modifier, « Peut voir la propriété et les valeurs » suffit.

Pensez cet accès par défaut comme le plancher. Vous allez ensuite ouvrir des exceptions vers le haut, jamais vers le bas : une exception ne peut pas être plus restrictive que le niveau par défaut pour une même personne, puisque Notion retient toujours le niveau le moins restrictif.

Étape 3 : Ajouter des exceptions par personne, groupe, propriété Personne ou agent

Cliquez sur « Ajouter une exception » et choisissez une cible : une personne nommée, un groupe du workspace, une propriété de type Personne de la base, ou un agent IA. Attribuez à chaque exception son propre niveau.

Les exceptions par groupe sont les plus simples à maintenir. Si vous créez un groupe « RH » dans les paramètres du workspace et que vous lui accordez « Peut modifier les valeurs uniquement » sur la colonne « Rémunération », chaque arrivée ou départ dans l’équipe RH se gère au niveau du groupe, sans retoucher la base.

Étape 4 : Vérifier avec l’aperçu

Avant d’enregistrer, utilisez « Aperçu » pour afficher la base telle qu’une personne donnée la verra. Choisissez un compte qui n’a pas l’accès complet : d’après la documentation de Notion, les personnes avec accès complet à la base conservent toujours l’accès à toutes les propriétés, donc leur aperçu ne prouve rien.

C’est l’étape que j’ai vue le plus souvent négligée. Un responsable teste avec son propre compte, constate que tout fonctionne, et découvre deux semaines plus tard qu’un invité voit toujours la colonne parce qu’il disposait d’un partage plus large sur le teamspace parent.

Étape 5 : Enregistrer, patienter, puis tester les dépendances

Enregistrez la règle. Notion indique que la première règle sur une colonne peut prendre plusieurs minutes à s’appliquer, selon le nombre de lignes de la base. Sur une base de 4 000 entrées, j’ai attendu un peu moins de trois minutes.

Testez ensuite tout ce qui dépend de la colonne : formules, agrégations, automatisations, boutons et vues triées ou filtrées. Dans mes tests, une formule Notion qui lit une propriété masquée a renvoyé une valeur vide pour la personne concernée, sans message d’erreur. La documentation officielle ne détaille pas ce comportement : vérifiez-le sur vos propres formules. Si la formule reconstitue une donnée sensible, protégez aussi la colonne de sortie.

Les exceptions basées sur une propriété Personne

C’est le mécanisme le plus fin du dispositif, et le moins intuitif. Une exception peut viser non pas une personne fixe, mais la personne renseignée dans une colonne de type Personne de la base, ligne par ligne.

Prenons une base de projets avec une colonne « Responsable » et une colonne « Budget ». Vous définissez l’accès par défaut de « Budget » sur « Aucun accès », puis vous ajoutez une exception : la propriété Personne « Responsable » obtient « Peut modifier les valeurs uniquement ». Résultat : chaque responsable voit et modifie le budget de ses propres projets, et uniquement de ceux-là.

Deux subtilités à connaître. Premièrement, les personnes désignées dans la colonne Personne voient le nom de cette colonne même si ses valeurs leur sont masquées, un peu comme une liste d’invités où l’on sait qu’on figure sans voir les autres noms. Deuxièmement, si ces mêmes personnes peuvent modifier la colonne « Responsable », elles peuvent s’y ajouter et s’octroyer l’accès au budget. Verrouillez les deux colonnes, pas une seule.

Trois cas d’usage concrets

Les permissions par colonne prennent tout leur sens dans des bases partagées avec des profils hétérogènes. Voici les trois configurations que j’ai mises en place, avec les niveaux retenus.

Recrutement : masquer la rémunération et les notes d’entretien

Une base de candidatures est consultée par les recruteurs, les managers qui mènent les entretiens, et parfois un cabinet externe invité. Les colonnes « Prétentions salariales », « Proposition » et « Notes d’entretien » ne concernent que l’équipe recrutement.

Le hiring manager voit la proposition faite à son candidat, mais pas celle des autres postes. Le cabinet externe, invité avec un accès en consultation, ne voit ni les montants ni les notes.

CRM : protéger les données clients sensibles

Dans un CRM construit sur Notion, les commerciaux ont besoin de tout voir sur leurs comptes, le support a besoin du contexte sans les conditions négociées, et le marketing n’a besoin que des segments. Les colonnes « Remise accordée », « Marge » et « Contact direct du décideur » sont les premières à protéger.

Combinez ici deux mécanismes. Les permissions par colonne masquent « Marge » et « Remise » à tout le monde sauf au groupe « Direction commerciale », et une exception par propriété Personne « Account owner » donne à chaque commercial la lecture de ses propres conditions. Si votre CRM est alimenté par une base synchronisée Salesforce, vérifiez au cas par cas : certaines propriétés synchronisées ne sont pas restreignables.

Freelance : inviter un client sur une base de suivi sans lui montrer vos coûts

C’est le cas qui m’a le plus servi. Comme beaucoup de freelances sur Notion, je partage avec chaque client une base de suivi des livrables. Elle contient aussi mon temps passé, mon taux horaire interne et mes notes de préparation, que le client n’a pas à voir.

Avant Notion 3.8, je maintenais deux bases reliées par une relation, avec les colonnes privées d’un côté et les colonnes partagées de l’autre. Aujourd’hui, une seule base suffit : accès par défaut « Aucun accès » sur « Temps passé », « Taux interne » et « Notes », puis une exception vers moi-même en modification. Le client invité en consultation voit le statut, les dates et les livrables, rien d’autre. Cette configuration demande toutefois un forfait Business, à 20 $ par utilisateur et par mois en annuel selon la grille tarifaire Notion, ce qui ne se justifie pas pour tous les indépendants.

Agents IA et Notion AI : comment ils héritent des droits

La question se pose dès qu’un agent travaille sur une base protégée : peut-il lire ce que son utilisateur ne voit pas ? La réponse est non, et c’est une bonne nouvelle pour la cohérence du système.

Notion AI hérite des droits de la personne qui le sollicite. Si vous ne voyez pas la colonne « Rémunération », votre agent ne peut ni la lire, ni la remplir, ni la résumer. Il peut même répondre que la propriété n’existe pas, ce qui surprend la première fois mais reste le comportement attendu.

Les agents personnalisés vont un cran plus loin : vous pouvez leur attribuer des exceptions propres sur une colonne, exactement comme à une personne ou à un groupe. Un agent de tri du support peut ainsi recevoir « Aucun accès » sur les données de facturation tout en modifiant le statut des tickets. Le même principe s’applique aux outils connectés via Notion MCP, qui agissent toujours avec les droits du compte qui les a autorisés.

Un cas de dépannage découle de cette règle. Si une automatisation, un bouton ou une agrégation échoue pour un collaborateur mais fonctionne pour vous, l’explication la plus fréquente est une colonne nécessaire au flux que ce collaborateur ne voit pas. Notion conseille alors de faire exécuter le même flux par une personne qui voit la colonne, pour confirmer le diagnostic.

Limites et colonnes non restreignables

Le dispositif comporte des bornes précises, qu’il vaut mieux connaître avant de restructurer une base.

• 20 propriétés maximum par base de données peuvent recevoir des règles d’accès.
• Colonnes jamais restreignables : Titre, Identifiant, Créé par, Date de création, Dernière modification par, Dernière modification, certaines propriétés synchronisées, et les relations parent ou sous-élément.
• Bases wiki : l’accès aux propriétés n’y est pas disponible. Si votre wiki Notion contient des colonnes sensibles, convertissez-le en base classique ou déplacez ces colonnes dans une base reliée.
• Mobile : impossible de créer ou de modifier des règles depuis l’application iOS ou Android, mais les règles existantes s’y appliquent.
• Performance : un grand nombre de règles ralentit le chargement, surtout dans les vues triées, filtrées ou regroupées par une colonne restreinte. Une vue qui filtre sur une colonne masquée peut ne pas s’ouvrir du tout pour les personnes concernées.
• Historique des versions : restaurer une version antérieure de la base conserve les règles d’accès actuelles, pas celles de l’ancienne version.

La limite de 20 propriétés m’a semblé confortable sur un CRM, plus serrée sur une base RH complète. Si vous l’atteignez, la bonne pratique consiste à regrouper les données sensibles dans une base dédiée, reliée par une relation, plutôt que de multiplier les règles sur une base monolithique.

Cinq vérifications dans l’ordre, du cas le plus fréquent (accès complet) au moins évident (règle créée depuis une base liée).

Dépannage : la colonne reste visible malgré la règle

Notion applique toujours l’accès le plus large dont dispose une personne. Quand une colonne restreinte reste visible, suivez cet ordre de vérification.

1. Accès complet. La personne a-t-elle l’accès complet à la base ? Si oui, aucune règle de colonne ne s’applique à elle. Ramenez-la en modification.
2. Partage parent. Vérifiez le menu « Partager » de la page qui contient la base, du teamspace et des pages parentes. Un partage plus large hérité l’emporte sur la règle.
3. Accès par défaut. Le niveau par défaut de la colonne est-il bien restreint, ou est-il resté sur « Hériter de la base de données » ?
4. Exceptions. La personne appartient-elle à un groupe, ou figure-t-elle dans une colonne Personne, qui lui accorde un niveau supérieur ? Le niveau le moins restrictif gagne.
5. Base liée. La règle a-t-elle été créée depuis la base d’origine ? Recréez-la depuis la source si nécessaire.

Si après ces cinq points une formule ou une agrégation affiche encore une donnée sensible, c’est la colonne calculée qu’il faut protéger, pas seulement sa source. Mon guide sur les rollups Notion détaille les cas où une agrégation reconstitue une information qu’on croyait masquée.

Mon avis : une fonctionnalité attendue, livrée avec les bons garde-fous

Les permissions par colonne corrigent un défaut structurel de Notion qui a poussé bien des équipes vers Airtable ou des outils métier pour leurs données RH et commerciales. Le modèle retenu (accès par défaut, exceptions, aperçu par personne, agents soumis aux mêmes règles) est cohérent avec le reste du système de droits, et j’ai trouvé la configuration plus rapide que les anciens montages à deux bases.

Deux réserves. La restriction aux forfaits Business et Enterprise exclut les indépendants et les petites équipes en Plus, pour qui le cas « client invité » était pourtant le plus parlant. Et le plafond de 20 propriétés impose de concevoir ses bases avec cette contrainte en tête dès le départ.

Mon verdict : si vous êtes déjà en Business et que vous partagez des bases avec des invités ou des équipes aux besoins différents, activez ces règles cette semaine sur vos colonnes de rémunération, de marge et de contacts. Si vous êtes en Plus, le montage classique à deux bases reliées reste la seule option réellement étanche, en gardant à l’esprit qu’une vue filtrée seule ne protège rien. Pour l’ensemble des réglages de sécurité du workspace, mon guide sur la protection des données dans Notion complète celui-ci.