LogicielsGestion de projetTendancesRoadmap projet : 5 modèles réels d’agences françaises avec template Notion (2026)

Roadmap projet : 5 modèles réels d’agences françaises avec template Notion (2026)

Sophie Martin
Sophie Martin
12 min

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

Notion Notion Site officiel Lire notre test
Julien Morel Testé par Julien Morel

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

Notez cet article

Partager cet article

Recherche globale

Recherchez parmi les agences, logiciels et articles de La Fabrique du Net.