Dans le cadre de notre service Notion Officer, où nous restons présents dans les espaces de nos clients pour assurer un accompagnement mensuel, nous réalisons des nettoyages de bases de données, des revues du système et, plus généralement, des audits de bonnes pratiques.
Même si nous proposons des formations, des workshops et que nous partageons des guides de bonnes pratiques, il nous arrive de temps en temps de tomber sur des histoires d'horreur 👻 comme la suivante.
Le cas des 12 bases de données d'événements
Imaginez la scène :
Une page « Événements » avec 12 bases de données différentes, une pour chaque mois de l'année, toutes sur la même page. (À cela s'ajoute le fait qu'elles ont en réalité été créées dans la section « Private » d'un utilisateur précis, d'où le No access).
Quand nous voyons une chose pareille, nous ne la traitons pas seulement comme un « chaos à remettre en ordre ». Nous y voyons une occasion de renforcer des concepts clés et de mieux comprendre pourquoi, dans Notion, lorsqu'il s'agit de bases de données, moins, c'est presque toujours mieux.
Car il ne s'agit pas seulement d'esthétique ou d'« ordre visuel ». Avoir 12 bases de données (une par mois) au lieu d'une seule base bien conçue a des implications techniques, de maintenance et de scalabilité pour les équipes. Même si Notion ne « plante » pas et ne renvoie pas d'erreurs, le système devient plus fragile et plus difficile à tenir dans la durée.
Reprenons point par point :
1. Performance et chargement de la page
Chaque base de données est un bloc à part entière, qui a un poids au sein du système : elle a son propre schéma, ses propres vues, ses actions, ses filtres et sa logique.
- 12 bases de données = 12 blocs ou moteurs que Notion doit charger et recalculer.
- Sur des pages comportant beaucoup de bases de données, le chargement initial est plus lent et le défilement paraît moins fluide, surtout sur des machines plus anciennes ou avec des connexions lentes.
Avec une seule base de données bien conçue, Notion peut réutiliser la structure et les données dans plusieurs vues.
Avec 12 bases qui, au fond, représentent la même chose, le système travaille inutilement : nous consommons davantage de ressources sans en tirer le moindre bénéfice réel.
2. Scalabilité : quand le système doit grandir ou changer
C'est ici que le « on corrigera ça plus tard » devient un piège. Chaque fois que vous voulez modifier la structure :
- Ajouter un champ comme Responsable, Type d'événement ou Statut.
- Ajuster les options d'un select ou d'un status
- Modifier une formule ou un filtre
Avec une seule base, vous le faites une seule fois. Avec 12 bases, vous le faites 12 fois.
Ce n'est pas seulement plus de travail : c'est un terrain miné pour les erreurs et pour la perte d'homogénéité.
Que pourrait-il se passer ?
On met à jour une base de données mais les autres restent en décalage, d'autres ont des options différentes… et, petit à petit, les données cessent d'être comparables.
Ce n'était pas le cas de cette base de données, mais si l'on ajoute en plus des automatisations (internes à Notion ou externes), le problème se multiplie et l'on se retrouve face à un vrai casse-tête : toute logique reposant sur des déclencheurs comme « quand un événement est créé » doit prendre en compte 12 origines distinctes. Et si vous devez apporter des changements, là encore, vous devez les faire 12 fois.
3. Analyse et reporting : le véritable enfer
Quand les données sont éclatées entre 12 bases différentes, voir l'année complète n'est plus quelque chose de possible et devient un véritable numéro d'équilibriste.
- Pour répondre à une question aussi simple que « combien d'événements avons-nous eus cette année ? », vous devez mélanger des informations provenant de 12 endroits différents.
- Des questions comme « combien d'événements de chaque type avons-nous organisés ce trimestre ? » exigent soit une base agrégatrice supplémentaire, soit 12 filtres manuels et des vues dupliquées.
Avec une seule base d'événements, en revanche :
- Vous filtrez par date :
ce mois-ci,90 derniers jours,ce trimestre, etc. - Vous regroupez par
mois,type d'événement,client,statut, selon l'axe que vous voulez. - Vous construisez des dashboards qui s'alimentent toujours à la même source maîtresse.
Quand les données sont fragmentées :
- Le filtre par date ne fonctionne qu'à l'intérieur de chaque base.
- Il n'existe pas de vue globale véritablement vivante qui nous donne une information annuelle.
- Le moindre dashboard se transforme en une page faite de silos séparés au lieu d'un système propre, capable de monter en charge à l'échelle de l'équipe et du temps — par exemple, pour comparer une année à une autre.
4. Des données incohérentes au fil du temps
Quand le modèle est dupliqué, l'incohérence n'est pas une éventualité — c'est un fait. Ce n'est qu'une question de temps avant que le système ne se casse.
Avec le temps, il est fréquent de voir des choses comme :
- Janvier a
Type d'événementavec les options A, B, C. - Avril a A, B, D.
- Septembre a A, C, D et un mystérieux « À revoir » ou un « En pause » dont personne ne sait qui l'a ajouté.
Résultat : vous ne pouvez ni regrouper ni compter en toute confiance, parce que chaque mois parle une langue légèrement différente.
5. Le coût mental pour l'équipe
Au-delà de l'aspect technique, nous ne devons jamais oublier le facteur humain. Avoir plusieurs sources d'information génère des frictions, qui se traduisent presque toujours par ceci : les gens se perdent, se lassent et finissent tout simplement par ne plus enregistrer l'information parce qu'ils ne lui font pas confiance. Or un système où les données ne sont pas correctement saisies est un système qui perd de la valeur.
C'est aussi beaucoup plus difficile à enseigner et à documenter :
- Il est bien plus simple de dire :
« Nous avons une base de données Événements. Toujours là. On filtre par date. »
- Que d'expliquer :
« Chaque mois a sa propre base. Voici janvier, voici février… et si vous voulez voir toute l'année, allez sur ce dashboard spécial qui mélange plusieurs choses. »
6. Et les limites de Notion ? Ne vaut-il pas mieux « découper » pour alléger ?
Les pages Notion supportent bien plus que 12 bases de données. Le problème ne sera pas « je vais manquer de mémoire ». Ce qui affecte réellement les performances, c'est la combinaison de plusieurs facteurs :
- Beaucoup de bases de données sur la même page.
- Beaucoup de vues complexes (filtres, regroupements, formules) actives en même temps.
- Si les vues ou les bases de données n'ont pas de limite sur le nombre de lignes à afficher, elles chargeront énormément d'informations.
C'est pourquoi, du point de vue de la conception du système, il vaut généralement mieux : Une base de données unique, bien pensée, bien structurée et dotée de bonnes vues, plutôt que de nombreuses petites bases qui représentent la même chose découpée artificiellement.
7. En conclusion : mieux vaut presque toujours une seule source de vérité
Quand il s'agit de bases de données dans Notion, moins, c'est mieux.
N'oubliez pas de créer une seule base de données d'événements, avec :
- Des propriétés claires.
- Des vues (onglets) par mois, trimestre, type d'événement, statut, client, équipe, etc.
- Des filtres par date bien définis.
Mieux encore :
- Rapide à charger.
- Facile à maintenir.
- Scalable quand le système grandit.
- Fiable au moment d'analyser et de prendre des décisions.
Les systèmes qui passent réellement à l'échelle sont ceux qui disposent d'une seule source de vérité pour chaque type d'information. Tout le reste n'est que vues, filtres et façons de regarder les mêmes données.
Et dans Notion, cela commence presque toujours par une décision simple, mais puissante :
Une base bien conçue, plutôt que douze qui racontent la même histoire séparément. Ce n'est là qu'une des nombreuses bonnes pratiques que nous transmettons dans nos formations Notion.
La plus recommandée à ce jour est notre bootcamp d'architectes parce qu'elle comprend des sessions en direct et du mentorat Notion.
À la prochaine !