Roadmap produit dans Notion : la construire, la tenir, la partager

Une roadmap produit agile dans Notion se construit sur la base des epics, pas sur une liste à part : chaque epic reçoit un horizon (maintenant, ensuite, plus tard) ou un trimestre, une vue timeline les place dans le temps, et un rollup calcule leur avancement à partir des stories terminées. La roadmap se partage ensuite par une vue filtrée, sans exposer le backlog.

Une roadmap promet. C’est sa force et son danger : trop précise, elle devient une liste de dates que l’équipe ne tiendra pas ; trop vague, elle ne sert à personne.

Ce guide montre comment la construire dans Notion pour qu’elle reste honnête, à partir de la structure que j’ai conçue pour ProductOS. Le cadre complet des sprints est dans Scrum dans Notion, et la façon d’écrire les stories dans le backlog produit dans Notion.

Qu’est-ce qu’une roadmap produit agile ?

Une roadmap produit agile montre la direction du produit et les grands chantiers prévus, sans figer le détail du travail. Elle répond à « vers quoi allons-nous, et dans quel ordre ? », là où le backlog répond à « que faisons-nous ensuite, précisément ? ».

Trois traits la distinguent d’un planning classique :

• Elle parle d’objectifs et de chantiers, pas de tâches. Le détail reste dans le backlog.
• Elle est plus précise à court terme qu’à long terme. Ce qui arrive dans les prochaines semaines est daté ; ce qui arrive dans six mois est seulement ordonné.
• Elle change, et c’est prévu. Le Scrum Guide fait du Product Goal l’objectif à long terme de l’équipe : la roadmap en montre le chemin, revu à chaque sprint review.

Roadmap par objectifs ou par epics : laquelle choisir ?

Il existe deux grandes façons de construire une roadmap, et Notion se prête aux deux.

La roadmap par epics

Chaque ligne est un grand chantier : « Paiement en ligne », « Espace client », « Application mobile ». C’est la plus simple à tenir, parce que les epics existent déjà dans votre espace et que les stories y sont reliées. Elle convient à une équipe qui livre des fonctionnalités clairement délimitées.

La roadmap par objectifs

Chaque ligne est un résultat attendu : « Réduire les abandons au paiement », « Faire revenir les utilisateurs chaque semaine ». Les epics se rattachent ensuite à l’objectif qu’ils servent. Elle oblige à justifier chaque chantier, ce qui protège des fonctionnalités ajoutées parce qu’elles plaisent.

Mon conseil : commencez par les epics, puis ajoutez une base « Objectifs » reliée aux epics le jour où les débats de priorité portent plus sur le « pourquoi » que sur le « quoi ». Dans Notion, cela tient en une relation de plus.

Maintenant, ensuite, plus tard, ou par trimestre ?

Le format de la roadmap compte autant que son contenu. Deux formats fonctionnent bien dans Notion.

• Maintenant, Ensuite, Plus tard. Une propriété « Horizon » sur chaque epic, et une vue Kanban groupée dessus. Aucune date n’est promise au-delà du présent, seulement un ordre. C’est le format le plus honnête pour une petite équipe ou un produit jeune.
• Par trimestre. Une propriété « Trimestre visé », ou des dates de début et de fin, et une vue timeline. Il rassure les parties prenantes qui planifient de leur côté : un lancement commercial, une campagne, un recrutement.

Les deux se combinent : la même base Epics peut avoir les deux propriétés et deux vues. L’équipe travaille sur la vue par horizon, la direction lit la vue par trimestre.

Une règle évite la plupart des déceptions : ne datez finement que ce qui entre dans les deux ou trois prochains sprints. Au-delà, un trimestre suffit.

Construire la vue timeline des epics

La vue timeline de Notion place chaque page sur une ligne de temps, à partir d’une propriété date avec début et fin. Sur la base Epics, elle devient la roadmap visuelle. Le fonctionnement général de cette vue est expliqué dans la vue timeline de Notion.

Les réglages qui la rendent utile :

1. Une propriété « Période » de type date, avec une date de début et une date de fin.
2. Un regroupement par projet ou par objectif, si votre espace suit plusieurs produits.
3. L’avancement affiché sur la barre : un rollup sur les stories reliées, qui compte la part des stories terminées.
4. Un filtre qui masque les epics terminés depuis longtemps, pour garder une roadmap qui regarde devant.

L’avancement calculé est la pièce essentielle. Un pourcentage saisi à la main reflète l’optimisme de la personne qui l’écrit ; un rollup sur les stories terminées reflète le travail réellement fait.

Comment relier la roadmap au travail de l’équipe ?

Une roadmap déconnectée du backlog vieillit en quelques semaines. Dans Notion, la relation entre epics et stories fait le lien : chaque story appartient à un epic, chaque epic affiche ses stories dans sa page.

Ce lien sert dans les deux sens :

• De la roadmap vers le travail : en ouvrant un epic, vous voyez ses stories, leur statut et le sprint où elles sont prévues.
• Du travail vers la roadmap : quand une story se termine, l’avancement de son epic bouge tout seul sur la timeline.

En construisant ProductOS, j’ai ajouté une troisième pièce : une base « Releases », reliée aux stories. Une release dit ce qui part en production, et quand. La roadmap montre les chantiers, les releases montrent les livraisons, et les deux restent cohérentes parce qu’elles partagent les mêmes stories.

Comment partager la roadmap aux parties prenantes ?

La direction, les commerciaux ou les clients n’ont pas besoin du backlog. Ils ont besoin de savoir ce qui arrive, et à peu près quand.

Dans Notion, trois options, de la plus simple à la plus fermée :

1. Une page « Roadmap » avec une vue liée de la base Epics, filtrée sur les epics à venir, avec seulement le nom, l’horizon et une phrase de description.
2. Une page partagée en lecture aux personnes concernées, avec des droits limités. Le détail des réglages est dans les permissions Notion en équipe.
3. Une page publiée sur le web, pour une roadmap publique. Attention : une page publiée expose aussi ce qui est rangé sous elle. Gardez-la séparée de vos bases de travail.

Dans tous les cas, ajoutez en tête de page une phrase claire : la roadmap montre une intention, pas un engagement daté. Elle évite bien des malentendus.

Les erreurs qui rendent une roadmap inutile

• Des dates fines à six mois. Elles seront fausses, et l’équipe perdra du temps à les justifier.
• Une liste de fonctionnalités sans ordre. Une roadmap qui met tout au même niveau ne dit rien.
• Un avancement déclaré à la main. Il diverge du travail réel dès la deuxième semaine.
• Une roadmap jamais revue. Prenez cinq minutes à chaque sprint review pour la remettre à jour.
• Une roadmap à part du backlog, dans un tableur ou un outil de présentation : elle ne bouge plus quand le travail avance.

Partir d’un template

ProductOS contient la roadmap décrite ici : les epics dans le temps en vue timeline, les releases et les projets, reliés au backlog, aux sprints et à la documentation de l’équipe. L’avancement des epics se calcule à partir des stories terminées. Un seul paiement couvre toute l’équipe.

Découvrir ProductOS

Questions fréquentes