Un tableau de bord utile tient en trois bases et quatre vues. Voici comment le construire, dans quel ordre, et surtout ce qu'il ne faut pas y mettre.

La plupart des tableaux de bord Notion meurent de la même façon : ils sont trop riches. Trente indicateurs, six vues par base, des formules que plus personne ne relit, et au bout de deux mois personne ne les ouvre. Ce tutoriel décrit l’inverse.

Ce qu’un tableau de bord doit faire, et ne pas faire

Un tableau de bord sert à déclencher une décision. C’est son seul critère de réussite. Un chiffre qui ne peut changer aucune décision n’a rien à y faire, même s’il est intéressant.

Le test est simple, et il élimine la majorité des indicateurs qu’on est tenté d’afficher : si ce nombre double demain, que faites-vous différemment ? Si la réponse est « rien », l’indicateur sort.

Deuxième principe : un tableau de bord n’est pas un outil de saisie. S’il faut le remplir à la main chaque semaine, il ne sera pas rempli. Tout ce qui peut se déduire d’une donnée déjà présente doit se déduire, pas se ressaisir.

La structure : trois bases, pas trente

C’est l’étape qu’on est tenté de sauter et c’est la seule qu’on ne peut pas corriger après coup sans tout reprendre.

La base des clients ou comptes

Une ligne par entité avec qui vous travaillez. Peu de propriétés : un nom, un statut, un responsable. La tentation est d’y mettre le chiffre d’affaires ou le nombre de projets ; il ne faut pas, ces valeurs se calculent depuis les autres bases et une valeur recopiée finit toujours par diverger.

La base des projets ou affaires

Le cœur du système. Une ligne par projet, reliée à un client, avec un statut, une date de début, une date cible et un responsable. Le statut mérite qu’on s’y arrête : trois ou quatre valeurs suffisent, et elles doivent correspondre aux étapes que votre équipe nomme spontanément, pas à celles d’un modèle trouvé en ligne.

La base des tâches ou du temps

Une ligne par unité de travail, reliée à un projet. C’est elle qui alimente tout le reste. Si vous ne suivez pas le temps, cette base porte quand même les tâches, et le tableau de bord perdra seulement la dimension charge.

Les relations, qui sont le vrai sujet

Les trois bases se relient : tâche vers projet, projet vers client. C’est cette chaîne qui permet de remonter une information sans jamais la ressaisir. Une erreur classique consiste à relier aussi les tâches aux clients directement, « pour aller plus vite ». Cela crée deux chemins vers la même information, qui finissent par se contredire.

Les rollups, qui font le travail

Un rollup remonte une valeur depuis les lignes reliées. Sur la base des projets, un rollup compte les tâches non terminées. Sur la base des clients, un rollup compte les projets actifs. Trois ou quatre rollups suffisent à alimenter un tableau de bord entier, et ils se recalculent seuls.

Les quatre vues qui servent réellement

  • Ce qui est en retard. Un filtre sur la date cible dépassée et le statut non terminé. C’est la vue la plus consultée et souvent la seule qui déclenche une action.
  • Ce qui arrive cette semaine. Même base, filtre sur les sept prochains jours. Elle sert à préparer, pas à constater.
  • La charge par personne. Un regroupement par responsable, avec le compte de tâches ouvertes. Elle rend visible le déséquilibre avant qu’il ne devienne un retard.
  • Les projets par statut. Une vue en colonnes, qui donne l’état d’ensemble en un coup d’oeil.

Quatre vues, pas quinze. Chaque vue supplémentaire divise l’attention et, en pratique, personne n’en consulte plus de trois régulièrement.

Ce qu’il faut automatiser, et ce qu’il ne faut pas

Notion sait déclencher des actions, et il est tentant de tout brancher. Deux automatisations rapportent presque toujours, les autres rarement.

La première : créer la ligne depuis l’endroit où l’information arrive vraiment. Un formulaire de votre site, une boîte mail partagée, un canal de discussion. Tant que quelqu’un doit recopier à la main, il oubliera, et la base sera incomplète donc inutilisable.

La seconde : signaler ce qui bascule en retard, dans l’outil que la personne concernée ouvre déjà. Une alerte qui vit uniquement dans Notion suppose que quelqu’un pense à regarder.

Ces deux connexions passent par une plateforme d’automatisation. Nous comparons les principales dans Make ou Zapier, et la démarche complète est décrite sur la page automatisation des processus.

Ce qu’il ne faut pas automatiser : la mise à jour croisée de deux bases dans les deux sens. Cela paraît élégant et cela produit des boucles dont on ne sort pas.

Les cinq erreurs qu’on voit le plus souvent

Elles se ressemblent d’une équipe à l’autre, et toutes se corrigent plus facilement avant qu’après.

  • Recopier une valeur au lieu de la relier. Le nom du client écrit à la main dans la base des tâches, parce que c’est plus rapide sur le moment. Six mois plus tard, trois orthographes coexistent et aucun regroupement ne fonctionne.
  • Multiplier les statuts. Neuf valeurs paraissent plus précises que quatre. En pratique, personne ne sait choisir entre « en cours » et « en traitement », les deux se remplissent au hasard, et la vue par statut cesse de vouloir dire quelque chose.
  • Créer une base par client. C’est l’erreur la plus coûteuse, parce qu’elle est irréparable sans tout refaire. Une base par client interdit toute vue transversale : on ne peut plus répondre à « qu’est-ce qui est en retard, tous clients confondus ».
  • Écrire des formules qu’on ne saura plus relire. Une formule imbriquée sur quatre niveaux fonctionne le jour où on l’écrit et devient intouchable ensuite. Quand une formule dépasse deux lignes, il vaut mieux ajouter une propriété intermédiaire, même si c’est moins élégant.
  • Confondre le tableau de bord et l’archive. Garder tout l’historique dans la même base ralentit les vues et noie ce qui est actif. Ce qui est terminé depuis plus d’un an se déplace dans une base d’archive, consultable et hors du chemin.

Le point commun de ces cinq erreurs est qu’aucune ne se voit le jour où elle est commise. Elles se paient toutes au même moment : quand quelqu’un pose une question transversale et que la structure ne sait pas y répondre.

Les limites de Notion sur ce terrain

Notion est excellent pour un tableau de bord d’équipe et il atteint son plafond plus vite qu’on ne le pense. Trois signaux annoncent ce plafond.

Les vues qui manipulent plusieurs milliers de lignes deviennent lentes, et l’optimisation ne suffit plus. Les droits fins par ligne restent hors de portée, ce qui pose un problème dès que plusieurs clients ne doivent pas se voir. Et le calcul historique, c’est-à-dire suivre l’évolution d’un chiffre dans le temps, demande des contorsions.

Le moment de partir n’est donc pas une question de goût. Nous détaillons ces bascules dans Monday ou Notion, et le passage à un outil de suivi commercial dédié sur la page intégration CRM.