Dans la dernière année, j’ai recommencé à utiliser Notion. On l’avait utilisé en 2019-2020 chez Amplio avant de passer à Jira et Confluence. Le concept de base était génial et me rappelait d’ailleurs Podio, utilisé dans le temps de Karelab. Même idée: créer nous-mêmes les objets qu’on veut gérer en définissant les propriétés et les relations entre les objets. Ça peut paraître complexe au départ, mais dès qu’on a un minimum de background avec les bases de données, on comprend rapidement tout le potentiel.
Dans tous les cas, ça faisait quelques années que je n’étais pas retourné voir ce que Notion était devenu. Jusqu’à ce qu’un collègue chez illuxi m’en reparle et m’explique qu’il l’utilisait dans sa vie perso autant que professionnelle.
Le premier élément qui a attiré mon attention, c’est qu’il utilisait Notion pour enregistrer les meetings. Notion créait ensuite un résumé et des action items automatiquement. Interesting!
Notion a repiqué ma curiosité et je suis allé voir par moi-même.
Quelques mois plus tard chez illuxi, on migrait Confluence vers Notion pour y gérer les opérations et la documentation 😉.
Et j’ai fait la même chose avec Marcan et Co: J’utilise Notion pour gérer projets, tâches, clients, banques d’heures, etc.
J’aime tellement ça que j’y ai aussi déplacé la gestion de ma vie perso et familiale.
J’utilisais TickTick pour mes tâches perso. J’ai tout déplacé dans Notion.
Tout est maintenant dans Notion
Aujourd’hui, mon Notion, c’est une série de bases de données reliées entre elles.
À la base, agissant comme CRM et système de gestion de projets, il y a les bases de données Organisations, Personnes, Projets et Tâches. Les Organisations ont des Personnes, les Projets appartiennent à des Organisations et les Tâches à des Projets.
Pour les activités d’hébergement de Marcan et Co., j’ai créé les bases de données Domaines, afin de centraliser l’ensemble des domaines qu’on gère, Hébergements pour les hébergements de nos clients et Serveurs pour documenter sur quel serveur se trouve chaque hébergement.
Les clients nous envoient des demandes et, comme on ne veut pas gérer ça par courriel, j’ai créé une base de données Tickets.
Pour gérer le recrutement, nous avons Postes et Candidats. Un agent Notion y génère même automatiquement une analyse d’adéquation entre le poste et le candidat.
Finalement, nous travaillons généralement en banque d’heures avec nos clients. Il nous fallait donc une base de données Transactions d’heures afin de pouvoir suivre l’état de chaque banque d’heures.
Et au centre de tout ça, la base de données Meetings qui documente chaque rencontre, liée aux personnes, aux projets et aux organisations concernés.
Bref, tout est connecté. C’est ce qui fait la force du système. « One ring system to rule them all »: la business, le perso et la famille.
Mais comment gérer les accès, me direz-vous? Parce que les utilisateurs de l’équipe Marcan et Co. n’ont rien à faire dans les projets familiaux, right? Et vice-versa.
Quelle excellente question 🙋!
Espace d’équipe, groupes, accès et permissions
Donc, j’ai deux types d’utilisateurs: les gens de l’équipe Marcan et Co. et ma famille. Ces deux types d’utilisateurs n’ont rien à voir l’un avec l’autre et il est essentiel de gérer correctement qui a accès à quoi.
Il faut donc un accès à l’enregistrement près, pas à la page ou à la base de données.
Étape 1: un espace commun
J’ai d’abord créé un deuxième espace d’équipe, que j’ai appelé Commun. Par défaut, personne n’y a accès à moins d’y être invité. Une fois invités, les membres y auront un accès complet (en fait, pas vraiment, mais, voir plus bas…).
Dans cet espace, j’ai créé une page que j’ai nommée Protégés et dont j’ai configuré les permissions pour que personne n’y ait accès. J’y ai déplacé toutes mes bases de données.
J’ai ensuite invité les utilisateurs de l’équipe Marcan et Co. et les utilisateurs de la famille dans ce nouvel espace d’équipe.
Résultat: ils sont membres, mais ils ne voient rien, puisque tout est sous la page Protégés. La porte est là, mais elle est barrée.
On commence avec toutes les portes fermées, et on débarre seulement les portes nécessaires. Si vous êtes un brin geek, vous avez déjà reconnu le principe du « least privilege access » 🤓.
Étape 2: on crée des clés
Dans la base Organisations, j’ai ajouté une propriété de type Utilisateur que j’ai appelée Accès. Puis, dans les permissions de cette base, j’ai créé une règle d’accès: si un utilisateur est mentionné dans le champ Accès d’une fiche, il a accès à cette fiche.
Par exemple, dans l’organisation ABC inc., j’ai ajouté les utilisateurs de l’équipe Marcan et Co. dans le champ Accès. Dans l’organisation Famille, j’ai ajouté ma conjointe et les enfants.
Évidemment, pour ne pas ajouter les utilisateurs un par un, j’avais précédemment créé deux groupes d’utilisateurs: Business et Famille. Ce sont ces groupes que j’ai ajoutés au champ Accès, et non les utilisateurs individuels.
OK, chaque groupe a maintenant accès à son organisation.
Sauf que dans une fiche d’organisation, on affiche les personnes, les projets et les rencontres liés. Et ça, ils ne le voient pas encore.
Étape 3: l’héritage
Dans Projets, même recette: une propriété Accès, une règle, et j’ai ajouté les bons groupes sur les bons projets.
C’est dans la base Tâches que ça devient intéressant. Ajouter manuellement un groupe sur chaque tâche, ça n’a pas de sens.
J’ai donc ajouté deux propriétés. Une propriété Accès, pour les cas particuliers. Et une agrégation (un champ de type Roll-up) qui va chercher la valeur du champ Accès dans le projet lié à la tâche.
La règle d’accès dit: un utilisateur voit la tâche s’il est dans Accès de la tâche ou dans Accès du projet.
Autrement dit, si un utilisateur a accès au projet, il a accès à toutes ses tâches. Automatiquement.
Pour la base Personnes, même principe que pour les tâches. Une propriété Accès pour les cas particuliers, et une agrégation qui va chercher la valeur du champ Accès dans l’organisation liée à la personne. Si un utilisateur a accès à l’organisation, il a accès à toutes ses personnes.
Pour Rencontres, même principe que pour les tâches. Une agrégation va chercher l’Accès des projets liés à la rencontre. Et un champ Accès propre à la rencontre, pour les exceptions.
La règle: un utilisateur voit la rencontre s’il est dans Accès de la rencontre ou dans Accès du projet.
La plupart du temps, c’est le projet qui décide. Une rencontre n’existe pas dans le vide, elle appartient à un projet. Si un utilisateur fait partie du projet, il fait partie de ses rencontres. Je crée la rencontre, je la lie au projet, et les bonnes personnes la voient.
Mais parfois, quelqu’un doit voir une rencontre précise sans avoir accès au reste du projet. Un invité ponctuel, une rencontre à laquelle il a participé. Dans ce cas, je l’ajoute dans Accès de la rencontre, et c’est tout. Il voit cette rencontre-là. Rien d’autre.
Étape 4: une seule porte d’entrée
OK, les accès et les permissions sont bien configurés. Encore faut-il que les utilisateurs s’y retrouvent.
J’ai donc créé une page d’accueil dans l’espace Commun, accessible à tous ses membres. J’y ai ajouté deux vues: une des Projets, et une des Tâches en colonnes, façon Kanban.
Comme les accès sont gérés au niveau de l’enregistrement, tout le monde ouvre la même page, mais personne n’y voit le même contenu. L’équipe Marcan et Co. y trouve ses projets et ses tâches. La famille, les siens.
Une seule page. Zéro duplication. Chacun voit seulement ce qui le concerne.
Et en entreprise?
Mon cas mélange la famille et la business. Mais le même enjeu se pose dans n’importe quelle PME qui travaille dans Notion.
Prenez une agence qui y gère ses clients, ses projets et ses rencontres. Un jour, elle engage un pigiste pour un mandat. La semaine suivante, un client demande à suivre l’avancement de son projet. Puis un sous-traitant a besoin des notes de rencontre d’un dossier précis.
La même mécanique s’applique.
Le pigiste est ajouté dans Accès du projet. Il voit les tâches et les rencontres de ce projet. Rien d’autre.
Le client est ajouté dans Accès de son organisation et de son projet. Il suit ses livrables et ses rencontres. Jamais celles des autres clients.
Et le jour où le mandat se termine? On le retire du champ Accès du projet. L’accès aux tâches et aux rencontres tombe d’un coup, partout. Seules les exceptions ajoutées à la main restent à nettoyer.
Des briques, pas un building
Notion ne m’a pas livré ce système clé en main. Il m’a donné des briques: des bases de données, des propriétés, des relations, des agrégations, des règles d’accès.
Le reste, c’est de l’architecture.
Qui doit voir quoi? Qu’est-ce qui hérite de quoi? Où sont les exceptions, et qui les gère? Ce sont exactement les questions qu’on se pose en concevant une plateforme SaaS. Sauf qu’ici, les réponses tiennent en quelques propriétés, sans une ligne de code.
C’est ce qu’on oublie souvent avec les outils no-code. Et encore plus maintenant avec l’IA. Le vibe coding rend la construction plus rapide, mais il ne dessine pas nécessairement l’architecture qui vous convient. Un Notion mal pensé devient rapidement un endroit où tout le monde voit tout. Ou pire, où plus personne ne trouve rien.
Prendre le temps de réfléchir au modèle avant de cliquer partout, ça change tout.
Aujourd’hui, l’équipe voit ses clients. La famille voit la famille.
Et chacun est chez soi.
Maintenant, il me reste juste à trouver comment faire pour que les enfants fassent leurs tâches pour vrai 😅.
Une réponse