Sur les portefeuilles que je pilote - 8 à 20 M€ de budget annuel -, l’atterrissage budgétaire se tient à moins de 5 % d’écart entre le budget initial et la clôture des comptes. Ce résultat ne tient pas à un don de prévisionniste : il tient à un système qui maintient l’information de pilotage à jour, en continu, sans dépendre d’une consolidation mensuelle. Cet article décrit ce système.
Le pilotage IT, bien que faisant partie des fondamentaux de l’activité du DSI, demeure aussi l’une des plus difficiles à tenir sur la durée. S’il est plutôt aisé de constituer un instantané des budgets, de l’avancement roadmap / projets, créer un système complet permettant de maintenir à jour ces informations en continu et sans compter uniquement sur la bonne volonté des équipes opérationnelles est un véritable défi.
Loin des paillettes de la stratégie et de l’innovation, l’activité de pilotage demeure pourtant le socle fondamental de ce qu’une direction ou qu’un actionnaire attend, pour répondre en un clin d’œil aux questions suivantes :
- Quelle est la trajectoire de l’IT à 12-18 mois ?
- Sur quoi travaille-t-on actuellement ?
- Est-on dans les budgets ?
- Comment prendre en charge ce nouveau sujet ? Quels sont les arbitrages à prendre sur la roadmap ?
Les outils de pilotage de type PPM (Project Portfolio Management comme Clarity, ServiceNow, MS Project), et Knowledge management (Confluence, Sharepoint …) cumulent rarement plusieurs usages. Ils sont pour la plupart spécialisés sur leur zone d’excellence, et sont donc plutôt adaptés à des structures de grande taille. À l’inverse, le cumul de fichiers Excel pour les budgets, le suivi projets, etc. constitue un risque majeur pour votre activité : suppression de données maladroite, fichier corrompu, déplacement de fichier, multi-versions anarchiques …
Après avoir passé plusieurs années à tester les solutions du marché, j’ai finalement pris mes habitudes sur Notion. Si ce produit lancé en 2016 peut paraître impressionnant au premier abord, sa souplesse, sa communauté active, ses qualités naturelles pour le knowledge management et l’intégration native de l’IA le rendent très attractif pour les DSI.
Les premières licences acquises, partir d’une page entièrement vide peut être déroutant. Cet article vous aidera à vous lancer sur les premières bases de données qui centraliseront la connaissance dans votre DSI, et vous mettra le pied à l’étrier pour concevoir, jour après jour, le système qui correspond à votre organisation.
Cinq databases, un seul système
Un cockpit de pilotage DSI dans Notion tient en un socle minimal de 5 databases reliées : Applications, Budget / Projets, Consommation, Comités, Tâches. Ce socle pourra être agrémenté de bases complémentaires, selon vos usages et besoins réels :
- référentiel des contrats (à lier par application et par ligne budgétaire),
- référentiel des risques (à lier aux projets et aux applications),
- annuaire des intervenants, internes et prestataires (à lier aux tâches et aux projets),
- référentiel des décisions (à lier aux applications, aux budgets, aux projets et aux comités),
- référentiel des roadmaps,
- référentiel des partenaires,
- référentiel des tickets métier,
- plan de charge …
Le principe qui gouverne tout le reste et qui constitue la force de Notion : une seule saisie, plusieurs lectures. Une ligne budgétaire se saisit une fois, reliée à son projet et à son application. Ensuite, elle se lit partout, à l’instar d’un prisme, à travers des vues adaptées aux usages : dans l'atterrissage budgétaire, dans la fiche projet, dans le support de comité. Le comité de pilotage n'est pas un document à produire chaque mois : c'est une vue filtrée d'un système complet perpétuellement à jour. La reconstruction mensuelle du support - et les heures de consolidation qui l'accompagnent - disparaît purement et simplement.
C'est ce qui distingue un cockpit d'une collection de tableaux : sans relations entre les databases, vous maintenez cinq fichiers. Avec ce cockpit, vous pilotez désormais un système, alimenté en continu par vos équipes.
Le schéma des relations du socle :
Database 1 - Applications : le référentiel du SI
Le point d'ancrage. Chaque application du parc y vit avec ses propriétés clés : criticité, responsable métier, coût récurrent, statut (en production, en projet, à décommissionner).
Relations : vers les projets qui la font évoluer, vers les lignes budgétaires qu'elle consomme.
Ce que ça change : quand un DG demande « combien nous coûte cet outil, tout compris ? », la réponse est une fiche - pas trois jours de consolidation. Le budget Run cesse d'être une masse opaque : il se ventile application par application et par nature de dépense (infra, licence, maintenance …)
Database 2 - Budget / Projet - le tout-en-un suffisant pour les équipes de 5 à 30 personnes
Une base de données peut traiter deux objets métier intrinsèquement liés. Sur un modèle un brin “simpliste” mais suffisant pour de petites équipes, les lignes budgétaires sont ventilées entre le Run et le Build.
Le build, ce sont vos projets, et le run, vos dépenses régulières pour maintenir votre SI en conditions opérationnelles. Une propriété “Type” permettant de discriminer les Projets des autres dépenses suffit pour créer cette dichotomie.
Pour traiter les aspects budget et projet au sein d’une même base, il suffit de créer des vues distinctes de la base de données dans lesquelles on n’affiche que les propriétés nécessaires :
D'expérience, c'est la database que les équipes s'approprient le plus vite : elle correspond à ce qu'un DSI manipule déjà au quotidien. La logique de relations, elle, s'acquiert collectivement : relier chaque nouvel enregistrement à son application doit devenir un réflexe d'équipe, sinon les vues filtrées deviennent silencieusement incomplètes. C'est le premier point de discipline que j'installe en mission.
Relations : chaque ligne pointe vers son application ou son projet. Aucune ligne orpheline : c'est la règle de gestion la plus rentable du cockpit.
Cette database bouge peu en cours d'exercice. C'est le référentiel du budget voté, celui qu'on oppose au réalisé. Le mouvement, lui, est ailleurs, dans la base de données “Consommation”.
Database 3 - Consommation : le réalisé, au fil de l'eau
Commandes, factures, jours consommés. Chaque enregistrement est relié à sa ligne budgétaire - et hérite donc de son projet et de son application.
Pour éviter aux collaborateurs et prestataires de manipuler la base de données, il est possible de concevoir dans Notion un formulaire de saisie de compte-rendu d’activité. Les données saisies dans le formulaire alimentent alors automatiquement la base de données “Consommation”, et mettent à jour le Réalisé sur la table Budget/Projets, par rollup.
Un point de vigilance : le formulaire ne choisit pas la ligne budgétaire à la place du répondant. Un contrôle rapide des saisies de la semaine, via une vue dédiée, reste nécessaire pour garantir que chaque déclaration est reliée à la bonne ligne.
C'est la séparation Budget / Consommation qui rend l'atterrissage budgétaire possible sans retraitement : l'écart entre l'enveloppe et le consommé se calcule en continu, par rollup. Sur les missions que je pilote, c'est cette mécanique qui permet de tenir un atterrissage maîtrisé - parce que la dérive se voit le mois où elle commence, pas à la clôture.
Database 4 - Comités : l'instance n'est qu'une vue
Chaque nature de comité - COPIL projet, comité budgétaire, revue de portefeuille - existe comme enregistrement. Une bonne pratique consiste à intégrer l’ensemble des comités d’un même type (d’un même projet par exemple) au sein d’une même page.
- Cela permet d’agréger l’ensemble de la connaissance du pilotage du projet à un seul et même endroit, en s’économisant des clics superflus. C’est d’autant plus pratique pour comparer en séance les éléments partagés au comité C-1.
- Cela décuple les capacités de l’agent IA Notion : avec toute l’information à un seul endroit, vous pourrez utiliser l’agent IA intégré à Notion pour toutes sortes de questions, comme par exemple :
Une limite à anticiper : sur un projet long, la page unique enfle. Le bon réflexe consiste à ouvrir une nouvelle page par exercice ou par phase, en gardant la précédente en lien - la continuité de lecture est préservée, la page reste maniable.
La préparation d'un comité change de nature : plus de support à reconstruire, une vue filtrée sur les projets et les écarts du périmètre, plus la page du comité pour tracer les décisions. Les décisions cessent de vivre dans des comptes rendus Word que personne ne rouvre : elles sont reliées aux projets qu'elles concernent.
Database 5 - Tâches : une saisie, deux lectures
Le grain le plus fin du cockpit, et le plus quotidien. Chaque tâche porte son responsable, son échéance, son statut - et ses relations : le projet ou la ligne budgétaire qu’elle sert, le comité où elle est suivie.
Quand chaque collaborateur tient sa liste dans son coin - un carnet, un fichier, un outil personnel -, la consolidation au niveau projet devient un travail en soi. Centraliser les tâches dans une database unique inverse la mécanique. Le collaborateur travaille dans une vue filtrée sur son nom, qui devient sa to-do list quotidienne. Le chef de projet et le comité lisent les mêmes enregistrements, agrégés par projet - sans relance ni recopie.
Relations : vers le projet ou la ligne budgétaire concernée, vers le comité où l’action est suivie.
Ce que ça change : les actions décidées en comité ne se perdent plus dans un compte rendu. Elles naissent dans la database, reliées à leur projet et affectées à un responsable. À l’instance suivante, la revue des actions est une vue filtrée - pas une chasse aux engagements oubliés.
Les trois vues qui servent en comité
Le cockpit se juge à ce qu'il produit en instance. Trois vues font l'essentiel :
- Le portefeuille par statut - tous les projets, groupés par avancement, budget en rollup. La vue d'arbitrage : ce qui avance, ce qui attend une décision, l’avancement projet en 2 lignes généré par l’IA sur la base du contenu de la page projet (ainsi, si la page est actualisée régulièrement, le temps de consolidation du portefeuille tend vers 0 !)
- L'atterrissage budgétaire - enveloppes vs consommé, par application et par projet. La vue qui parle aussi à votre DAF : c'est le reporting que votre COMEX comprend sans glossaire.
- L'ordre du jour filtré - les tâches en attente et les décisions à arbitrer sur le périmètre du comité. La vue qui transforme la réunion : on arbitre au lieu de restituer.
Qui voit quoi : des accès réglés dès la conception
Un cockpit contient des données sensibles : enveloppes budgétaires, coûts par prestataire, arbitrages. Notion permet de régler les accès finement - à condition d'y penser dès la conception, pas après le premier incident. Trois règles suffisent pour une petite DSI :
- Séparer les espaces. Les databases Budget / Projets et Consommation vivent dans un espace d'équipe restreint (DSI, voire DSI + DAF). Les vues qui en découlent - portefeuille, atterrissage - se partagent, elles, plus largement.
- Traiter les externes en invités. Un prestataire accède au formulaire de saisie et à ses tâches - pas aux enveloppes, ni aux coûts des autres intervenants.
- Vérifier ce qu'un partage emporte. Dans Notion, une page partagée expose ses sous-pages : avant d'ouvrir un accès, contrôler ce qu'il embarque.
La mise en place : ce que vous prenez en main dès J+1
Cette architecture se met en place en quelques heures pour un utilisateur averti. La reprise de l'existant n'est pas un chantier : vos fichiers Excel actuels s'importent en quelques clics (import CSV), et le passage à l'exercice suivant ne demande aucune duplication - la propriété « exercice » des lignes budgétaires suffit à filtrer les vues sur l'année en cours. Ce qui se prend en main immédiatement : Projets et Budget - les équipes y retrouvent leurs objets de travail quotidiens.
Deux points demandent un accompagnement, et mieux vaut en prendre conscience :
- La database Tâches. C’est celle qui demande le plus d’accompagnement : elle ne produit ses effets que si chacun abandonne sa liste personnelle au profit de la base commune. Les vues personnelles par collaborateur rendent la bascule indolore : chacun y retrouve sa to-do list, le portefeuille y gagne une consolidation sans relance.
- La discipline des relations. Un enregistrement mal relié n'est pas faux : il est invisible. Il disparaît des vues filtrées sans déclencher d'alerte. La parade tient en deux points :
Rien de tout cela n'est un problème d'outil. C'est une pratique de pilotage - et elle s'installe en quelques semaines.
Limites assumées : la simplicité est la condition de l'adoption
Notion n'est ni un ERP ni un outil de gestion de portefeuille lourd. Pour une PME-ETI et des équipes de quelques dizaines de personnes, c'est précisément sa force - à une condition : rester sobre.
Ma règle de conception : une trame globale simple, affinée au fur et à mesure des besoins réels. Chaque propriété ajoutée doit être lue par quelqu'un et servir une décision. Un modèle surchargé de propriétés devient incompréhensible, puis plus maintenu, puis abandonné. Une interface soignée pour vos pages Notion telle que vous en trouverez sur la Marketplace ne sauve pas une usine à gaz qu'une manipulation maladroite ou malheureuse suffit à casser.
Le meilleur signal qu'un cockpit fonctionne, je l'observe en fin de mission : le client le fait évoluer sans moi. Sur une mission récente, l'équipe a ajouté ses propres propriétés et monté une vue dédiée au suivi d'un projet particulier - sans rien casser, parce que la trame était simple. C'est exactement l'objectif.
Car ma conviction, au fond, tient en une phrase : les outils de pilotage appartiennent au client, pas au consultant. Un cockpit que vous ne pouvez pas faire vivre seul n'est pas un livrable : c'est une dépendance. L'appropriation interne n'est pas un bonus de fin de mission ; elle conditionne la réussite du pilotage.
Pour assurer la pérennité du cockpit, une bonne pratique consiste à nommer deux ou trois power-users au sein de l’équipe, dont les missions seront :
- d’accompagner les utilisateurs dans la prise en main de l’outil et de résoudre leurs petits soucis du quotidien
- de vérifier régulièrement (de manière hebdomadaire) que des enregistrements “fantômes” qui ne sont liés à rien ne soient pas en base, et de procéder à leur nettoyage
- de collecter les besoins d’évolution de l’équipe, de les challenger, et de les implémenter une fois à l’aise avec la configuration Notion
Et maintenant ?
Si votre pilotage repose aujourd'hui sur des fichiers dispersés et des supports de comité reconstruits chaque mois, cette architecture est un point de départ concret. Reproduisez-la. Et si vous voulez gagner du temps sur la mise en place - règles de ventilation budgétaire, discipline de saisie, appropriation par les équipes -, c'est mon métier.
Réservez 30 minutes pour diagnostiquer votre pilotage →
Pour aller plus loin : le CIO-Office externalisé pour DSI · Une gouvernance DSI centralisée dans Notion · Un budget IT lisible en Run/Build*
