Roadmap projet : 5 modèles réels d’agences françaises avec template Notion (2026)
Les 12 premiers résultats Google sur “template roadmap projet” pointent tous vers des modèles génériques Asana, Monday ou Notion publics. Aucune ne montre ce qu’une équipe produit livre vraiment à son comité produit. Voici 5 formats de roadmap, illustrés sur 5 types de projet (SaaS B2B, refonte e-commerce, app mobile native, refonte site corporate, projet IA générative), avec un encart “ce que ça force à faire, ce que ça pardonne mal” pour chacun. Template Notion combiné à télécharger en fin d’article. Les chiffres d’adoption viennent de l’enquête annuelle de ProductPlan (State of Product Management 2024, plus de 2 000 PM sondés) et de la Pulse of the Profession 2024 du Project Management Institute.
Qu’est-ce qu’une roadmap projet (et pourquoi ce n’est pas un Gantt)
Une roadmap projet répond à la question “où va-t-on et pourquoi”, pas “qui fait quoi quand”. C’est une distinction utile à poser dès la première réunion produit. Trois différences concrètes :
| Dimension | Gantt | Roadmap |
|---|---|---|
| Granularité | Tâche (1 à 5 jours) | Initiative ou objectif (1 à 8 semaines) |
| Audience | Équipe projet et PMO | Comité produit, sponsor, parties prenantes |
| Date | Précise (J0 + 28 jours) | Approximative (T2 2026, ou “fin avril”) |
| Engagement | Contrat de livraison | Direction validée, ajustable |
Un comité produit veut comprendre pourquoi on fait X avant Y. Une roadmap le montre. Un Gantt épuise visuellement la même audience. ProductPlan note dans son rapport 2024 que 64 % des PM jugent que leurs parties prenantes lisent leur roadmap “parfois” ou “rarement” : signe que la lisibilité est le premier problème, pas le contenu.
[Schéma : comparatif visuel Gantt vs Roadmap sur le même projet 6 mois, mise en lumière des différences d’audience]
Les 4 formats de roadmap les plus répandus
D’après le State of Product Management 2024 de ProductPlan, les listings d’Atlassian et les benchmarks publics de Productboard :
| Format | Cas typique | Quand le préférer |
|---|---|---|
| Roadmap par thèmes (now/next/later) | Produit en croissance, scope flou au-delà de 3 mois | Audience produit + sponsor, pas d’engagement de date |
| Roadmap par jalons trimestriels (Q1/Q2/Q3/Q4) | ETI, COMEX, planification annuelle | COMEX qui veut voir le rythme à l’année |
| Roadmap par release | App mobile, SaaS avec versions majeures | Sortie publique avec critères d’acceptation chiffrés |
| Roadmap par OKR | Équipes produit matures, scaleups | Quand on parle résultat, pas livrable |
Chaque format ci-dessous illustre un cas d’usage différent. À choisir selon votre audience principale.
Format 1. Roadmap SaaS B2B (format now/next/later, 6 mois)
Considérons une équipe produit-tech de 9 personnes sur un SaaS B2B (gestion locative, ARR 4 M EUR) qui pilote une refonte sur 6 mois. Le PO est dédié 80 % de son temps, le COMEX pousse plus d’idées que la roadmap ne peut en absorber. C’est le cas d’école du format now/next/later.
La roadmap type
| Now (6 sem.) | Next (sem. 7 à 16) | Later (sem. 17 à 24) |
|---|---|---|
| Refonte tunnel onboarding (NPS onboarding 24 vers 45) | Module reporting v2 (rétention 30 j de 71 % à 78 %) | API publique (revenue mix B2B partenaires) |
| Migration auth SSO (top 10 clients ent.) | Refactor module quittancement | Mobile app v1 |
| Bug critique sync compta | Permissions granulaires | Marketplace add-ons |
| Refonte UX tableau de bord principal |
Ce que ce format force à faire
Apprendre à dire non. Le COMEX pousse 4 initiatives par trimestre, le format now/next/later remplace “on fait ça en juin” par “c’est en next, tranché en revue mensuelle”. Sur 6 mois, des initiatives passent de later à now (décision board), d’autres tombent.
ProductPlan recommande systématiquement d’ajouter une colonne “parked” pour stocker les idées tranchées comme abandonnées avec date et raison. Faute de quoi, elles reviennent par la fenêtre tous les 4 mois.
Ce qui marche
- Revue mensuelle de 90 min avec sponsor + 2 acteurs métier (et personne d’autre).
- Critères “Definition of Done” associés à chaque initiative (NPS, rétention, taux d’adoption).
- Pas d’engagement de date sauf sur le Now (et même là, fourchette à 2 semaines près).
Format utilisé : Notion + base “Initiatives” liée
Format reproductible dans le template combiné téléchargeable en fin d’article.
Format 2. Roadmap refonte site corporate (format jalons, 4 mois)
Considérons une refonte de site corporate pour un acteur SaaS B2B, équipe agence de 5 personnes + 2 côté client, format mixte cycle en V allégé (UX et UI) + Scrum (build). C’est le cas type où le sponsor veut un repère temporel précis.
La roadmap type
| Jalon | Semaine | Livrables | Validation |
|---|---|---|---|
| J1 Cadrage UX | S2 | Bête à cornes, user flow 4 personas, audit existant | DG client + Resp. marketing |
| J2 Architecture I/A | S4 | Sitemap v2, wireframes basse fidélité 22 pages | DG + Resp. marketing + SEO |
| J3 Design system | S7 | Maquettes HF homepage + 3 templates | DG + Direction artistique |
| J4 Build front | S11 | Intégration des 22 pages + composants réutilisables | CTO client + équipe agence |
| J5 Recette et SEO | S14 | Migration contenu, redirections 301, recette technique | CTO + Resp. SEO |
| J6 Mise en ligne | S16 | Bascule prod, monitoring, formation back-office | CTO + Resp. marketing |
Ce que ce format force à faire
Sur ce format jalons, la roadmap ne montre pas le pourquoi, mais l’enchaînement. C’est l’outil que le sponsor regarde 5 minutes au COPIL pour savoir si on est en retard ou pas. Pour le pourquoi, on garde une 1-pager séparée (le brief de cadrage). Atlassian recommande explicitement de ne pas vouloir tout faire dire à un seul document : un seul artefact qui essaie de répondre à tout devient un artefact que personne ne lit. Séparer le pourquoi du quand est une règle d’hygiène.
Ce qui marche
- Les jalons sont des décisions Go/No-Go, pas des dates de livraison.
- Chaque jalon a un sponsor unique qui valide.
- Glissement autorisé de 1 semaine sans escalade, au-delà = comité de pilotage exceptionnel.
Format 3. Roadmap app mobile native (format release, 9 mois)
Considérons le développement d’une app mobile native iOS et Android pour une marketplace de services, équipe de 11 personnes (1 PM, 2 designers, 4 devs iOS, 4 devs Android), 9 mois jusqu’à la v1.0. C’est le cas type où chaque release doit obéir à des critères chiffrés, pas à une date.
La roadmap type
| Release | Sortie cible | Périmètre fonctionnel | Critères de sortie |
|---|---|---|---|
| Alpha interne | Semaine 12 | Inscription, recherche, fiche prestataire | 0 crash bloquant, 80 % unit tests |
| Beta fermée (200 users) | Semaine 20 | Réservation, paiement, messagerie | NPS > 25, CR < 5 % |
| Beta ouverte (2 000 users) | Semaine 28 | Avis, notifications push, profil | NPS > 35, conv recherche-réservation > 8 % |
| v1.0 public | Semaine 36 | Tout + onboarding et marketing | Validation stores, support en place |
| v1.1 (post-launch) | Semaine 40 | Programme parrainage, deeplinks | Métriques v1 stables 30 j |
Ce que ce format force à faire
Se poser une question saine : “qu’est-ce qui doit être vrai pour livrer cette release ?” Pas une date. Une condition. Si la beta fermée n’atteint pas NPS 35, la beta ouverte glisse. Si on l’avait gérée en jalons date, on aurait livré une beta dont on savait qu’elle déclencherait des désabonnements.
L’ajustement le plus fréquent dans ce format : sortir la dette tech et les bugs prioritaires des releases (sinon elles deviennent fourre-tout).
Ce qui marche
- Critères de sortie de release quantifiés (NPS, crash rate, conversion).
- Chaque release a une “definition of awesome” et pas seulement une “definition of done”.
- Releases courtes (4 à 8 semaines), pas de release de 6 mois.
Format 4. Roadmap refonte e-commerce (format OKR, 5 mois)
Considérons la refonte d’un site e-commerce mode (CA 12 M EUR/an), migration de Magento vers Shopify Plus, équipe de 8 personnes, 5 mois. C’est le cas type où le COMEX veut parler résultat business, pas livrable technique. ProductPlan recommande de limiter à 3 à 5 objectifs par trimestre, avec 2 à 4 key results chacun.
La roadmap type (OKR Q2-Q3)
Objectif 1 : Augmenter le taux de conversion mobile de 1,8 % à 2,5 % – KR1 : Tunnel de paiement refondu (livré S8) – KR2 : Express checkout Apple/Google Pay (livré S10) – KR3 : Personnalisation homepage par segment (livré S14)
Objectif 2 : Réduire le délai préparation commande de 36 h à 18 h – KR1 : Intégration WMS temps réel (livré S6) – KR2 : Notification picker (livré S9) – KR3 : Dashboard SLA (livré S12)
Objectif 3 : Faire passer le NPS client de 31 à 45 – KR1 : Refonte parcours retour (livré S11) – KR2 : Refonte page produit avec preuve sociale (livré S13) – KR3 : Service client intégré (livré S16)
Ce que ce format force à faire
Parler résultat, pas livrable. Le COMEX, au début, tique : “on ne sait plus ce qu’on livre”. Le contournement classique : ajouter une colonne “projet sous-jacent” à chaque KR. Six mois après, on découvre qu’une roadmap peut être pilotée par la donnée, pas par le scope. Atteinte partielle des objectifs ? Normal, c’est l’esprit OKR (les “stretch goals” doivent être ambitieux et ne sont pas tous atteints).
Limite à respecter : 3 objectifs maximum par trimestre, pas plus, sous peine de dilution.
Format 5. Roadmap projet IA générative (format now/next/later, 4 mois)
Considérons l’intégration d’un assistant IA dans un outil métier B2B (assurance), équipe de 4 personnes (1 PM, 1 prompt engineer, 2 devs). C’est le cas où le scope bouge tous les 15 jours, où il faut un format souple.
La roadmap type
| Now (4 sem.) | Next (sem. 5 à 10) | Later (sem. 11 à 16) |
|---|---|---|
| Mise en place pipeline RAG sur 2 000 docs | Connexion à 6 sources internes supplémentaires | Fine-tuning sur 500 cas annotés |
| Premier assistant restreint (3 cas usage) | Évaluation H2H vs équipe humaine | Mode “co-pilote” intégré CRM |
| Garde-fou hallucination (citation obligatoire) | Mesure adoption (DAU/MAU agents) | API externe partenaires |
Ce que ce format force à faire
Sur un projet IA, le scope bouge en continu. Now/next/later est le seul format qui survit aux 4 premiers mois. Ajouter une colonne “cancelled” avec la raison est crucial : modèles de coût qui ne tiennent pas, cas d’usage que les utilisateurs n’adoptent pas. Sans documentation, le COMEX redemandera ces sujets 4 mois plus tard.
Pratique utile : inclure un budget de tokens explicite dans la roadmap, par initiative. Sans ça, la facture mensuelle est découverte après coup.
Notre template Notion combiné à télécharger
Le template Notion inclut :
- 4 vues prêtes à l’emploi : now/next/later, jalons trimestriels, releases, OKR.
- Une base “Initiatives” avec champs standardisés (sponsor, statut, métrique cible, date approximative, dépendances).
- Une base “Décisions” pour tracer les arbitrages roadmap.
- Une vue “Parked” pour les sujets abandonnés (avec raison et date).
- Une page “Comité produit” prête à projeter en réunion.
Téléchargement : Template Notion (markdown) | Template Excel | Template Google Sheets (xlsx à importer)
[Capture : aperçu Notion du template, vue principale now/next/later avec 12 initiatives mockées]
3 pièges classiques à éviter
Piège 1. Une roadmap engageante sur 12 mois
Les roadmaps engageantes sur 12 mois sont obsolètes la plupart du temps avant le mois 4. Atlassian comme ProductPlan recommandent de tenir 6 mois maximum sur les détails et de donner juste une direction au-delà (par thèmes, pas par initiatives).
Piège 2. Confondre roadmap produit et roadmap projet
Roadmap produit = horizon long, parle aux utilisateurs et au marché. Roadmap projet = horizon livraison, parle au sponsor et à l’équipe. Les deux peuvent exister en parallèle. Les mélanger = personne ne lit ni l’une ni l’autre.
Piège 3. Aucune date du tout
Le format now/next/later sans repère temporel devient flou. Mettez des fourchettes (“Now = 6 prochaines semaines”) au lieu de dates précises. Vos parties prenantes ont besoin d’un repère, même approximatif.
FAQ
À quelle fréquence faut-il mettre à jour sa roadmap ?
Mensuelle pour les sujets “Now”. Trimestrielle pour la vue d’ensemble. Et ad hoc à chaque décision stratégique qui rebattrait les cartes (levée, pivot, départ exec). Atlassian recommande d’embarquer la mise à jour de la roadmap dans les rituels d’équipe plutôt que d’en faire un exercice ponctuel : c’est la condition pour qu’elle reste un single source of truth.
Notion ou Productboard pour une roadmap produit ?
Notion convient parfaitement jusqu’à une équipe produit de 8 à 10 personnes. Productboard (ou Aha!) deviennent rentables au-delà, surtout si vous gérez du feedback utilisateur entrant à structurer en parallèle. Coût indicatif 2026 : Productboard Pro autour de 25 EUR/utilisateur/mois, Aha! Roadmaps autour de 60 EUR/utilisateur/mois. Le State of Product Management 2024 de ProductPlan note qu’une majorité d’équipes utilisent désormais un outil dédié plutôt qu’un tableur, mais qu’environ un tiers restent encore sur Excel ou des slides.
Une roadmap est-elle un engagement contractuel ?
Non, et c’est même important de le poser dans le préambule. Une roadmap = direction validée, ajustable. Un Gantt projet = engagement de livraison. Si votre sponsor traite la roadmap comme un contrat, vous avez un problème de cadrage initial qu’aucun outil ne résoudra.
Combien d’initiatives en parallèle dans la zone “Now” ?
3 à 5 max pour une équipe produit-tech de 6 à 9 personnes. Au-delà, vous ne livrez plus, vous éparpillez. La règle qui marche en pratique : “une initiative = un PM dédié + une équipe focus”. Pas de PM partagé entre 3 initiatives, sauf à accepter que les 3 prennent 50 % de retard.
Faut-il afficher la roadmap publiquement (clients, prospects) ?
Sur un SaaS B2B, oui, partiellement. Une roadmap publique avec les 4 à 6 grandes initiatives du semestre est devenue un standard de transparence attendu. Les détails (KR, jalons internes, dépendances) restent en interne. Productboard et Notion permettent les deux vues depuis la même base.
Sources
- State of Product Management 2024, ProductPlan : productplan.com/the-state-of-product-management-annual-report– Pulse of the Profession 2024, Project Management Institute : pmi.org/learning/thought-leadership/pulse– Agile roadmaps: Build, share, use, and evolve, Atlassian : atlassian.com/agile/product-management/roadmaps– Now-Next-Later roadmap explained, Product School : productschool.com/blog/product-strategy/now-next-later-roadmap– Product Roadmap Guide, Productboard : productboard.com/product-roadmap-guide
Logiciels recommandés Gestion de projet




