Roadmap produit : le modèle Excel et un exemple sur douze mois
Une roadmap produit est le document qui répartit dans le temps les problèmes qu’un produit va traiter, avec pour chacun le résultat attendu et sa mesure. Elle ne contient ni tâches ni dates de livraison précises.
Page mise à jour le 12 septembre 2026. Modèle relu et remis à jour à chaque millésime.
Une roadmap produit n’est pas un planning déguisé. C’est la liste des problèmes que vous vous engagez à traiter, dans quel ordre et pour quel résultat mesuré, sans promettre de dates au jour près sur des sujets que personne n’a encore conçus. Voici le modèle Excel, la vue en trois horizons et l’exemple rempli sur un cas d’application mobile.
Roadmap produit et planning : deux documents, deux publics
La confusion coûte cher et elle est facile à lever. Un planning répond à la question « quand cela sera-t-il livré ». Une roadmap produit répond à la question « quels problèmes traitons-nous, dans quel ordre, et pourquoi ceux-là ». Le planning appartient à la conduite de projet, il se remplit une fois que le périmètre est conçu et chiffré. La roadmap appartient au produit, elle existe avant, et elle survit à toutes les versions.
La conséquence pratique est qu’une roadmap ne devrait pas porter de dates au jour près au-delà du trimestre en cours. Une date précise sur un sujet non conçu est une promesse invérifiable, et elle se retourne contre l’équipe au premier retard. Le trimestre est la maille qui tient : assez précise pour engager, assez large pour absorber la réalité de la conception.
La deuxième différence tient à ce qu’on écrit dans les lignes. Un planning liste des tâches. Une roadmap liste des thèmes et des résultats. « Développer l’écran de fidélité » est une tâche. « Faire de la fidélité une raison d’ouvrir l’application chaque semaine » est un thème, et il laisse ouverte la question de savoir comment on y arrive, ce qui est précisément le travail de l’équipe.
Enfin, les publics diffèrent. Le planning sert à l’équipe et au prestataire. La roadmap sert aux personnes qui financent, aux boutiques, aux équipes commerciales, à tous ceux qui ont besoin de savoir où va le produit sans avoir besoin de savoir comment il est construit. C’est pour cela qu’elle se lit en trente secondes.
La vue en trois horizons, et ce qu’on met dans chacun
Cette répartition porte un nom que vous croiserez partout en anglais, Now-Next-Later, et qui se traduit sans perte : Maintenant, Ensuite, Plus tard. Elle a un mérite que le diagramme à barres n’a pas : elle rend visible le niveau d’engagement. Chaque colonne porte une promesse différente, et cette différence doit être écrite en tête du document pour que personne ne lise la troisième colonne comme la première.
- Maintenant. Ce qui est engagé, conçu, chiffré et en cours. Le périmètre est connu, la mesure de succès est posée, la date de mise en ligne est annonçable. Deux à quatre lignes, pas davantage : une équipe qui a huit sujets en cours n’en a en réalité aucun.
- Ensuite. Ce qui est décidé et priorisé, mais pas encore conçu dans le détail. On connaît le problème et la mesure visée, pas la solution. L’horizon est le trimestre suivant. C’est la colonne qui bouge le plus, et c’est normal.
- Plus tard. Ce qui est envisagé, sans engagement de date ni de contenu. Cette colonne sert surtout à montrer que les demandes reçues ne sont pas perdues. Elle évite la moitié des relances, à condition de dire explicitement qu’elle n’engage à rien.
Le tableur propose les deux vues côte à côte, la vue par trimestre pour les comités et la vue en trois horizons pour l’équipe et les parties prenantes. Les deux sont alimentées par le même onglet de saisie, ce qui évite la situation classique de deux roadmaps qui divergent au bout de six semaines.
Une règle de discipline vaut la peine d’être tenue : rien n’entre dans la colonne Maintenant sans mesure de succès écrite. Pas un indicateur vague, une valeur cible et la source du chiffre. « Part des commandes passées à l’avance, lue dans le rapport de caisse, cible 15 % ». Cette exigence élimine à elle seule la moitié des sujets qui encombrent les roadmaps, parce qu’elle oblige à dire ce qu’on attend vraiment.
Ce qu’on écrit dans une ligne, et ce qu’on n’y écrit pas
Une ligne de roadmap tient en cinq colonnes. Le thème, formulé du point de vue du résultat. Le problème qu’il traite, en une phrase, avec le chiffre qui l’a fait remonter. La mesure de succès, chiffrée et datée. Le trimestre visé. Le statut. Le tableur ajoute une colonne de commentaire pour la dernière décision prise, ce qui évite de rouvrir trois fois le même débat.
Ce qu’on n’écrit pas : les tâches, les technologies, les noms de prestataires, les estimations détaillées. Ces éléments existent ailleurs, dans le backlog et dans le devis. Les faire entrer dans la roadmap la transforme en document de suivi que plus personne ne lit en dehors de l’équipe, et lui fait perdre sa fonction première, qui est de servir de support de décision.
Sur une application mobile, une contrainte mérite sa propre ligne dès la première version : le rythme des mises à jour et la validation par les magasins d’applications. Une fonctionnalité livrée n’est pas une fonctionnalité disponible tant que la version n’est pas validée puis installée par les utilisateurs. Les équipes qui découvrent ce délai après coup annoncent des dates qu’elles ne tiennent pas, sans rien avoir fait de mal.
Enfin, la roadmap se révise à échéance fixe. Un rendez-vous trimestriel d’une heure, avec les trois mêmes questions : qu’est-ce qui a été livré et qu’est-ce que cela a produit, qu’est-ce qui change dans le contexte, qu’est-ce qu’on déplace. Une roadmap révisée quatre fois par an reste crédible. Une roadmap révisée au fil de l’eau par courriel ne l’est plus au bout de six semaines.
Le document
Les fichiers ci-dessous sont libres d’usage, y compris pour un projet commercial. Ils portent le nom du site en pied de page, rien d’autre : ni logo imposé, ni mention à conserver. Le formulaire plus haut sert à les recevoir par courriel, le téléchargement direct fonctionne sans rien laisser.
Un exemple rempli : le cas fictif Rondo
Extrait de la roadmap du cas d’école fictif Rondo, une application inventée pour la démonstration : commande à l’avance et fidélité pour un réseau de soixante-deux boulangeries indépendantes. Le tableur contient la version complète, sur quatre trimestres.
- Maintenant · T1
- Commander avant de venir. Problème : 11 minutes d’attente moyenne relevées entre 7 h 30 et 9 h, 1 client sur 5 repart. Mesure : 15 % des tickets du matin marqués « commande app » à 6 mois. Statut : en cours, 6 boutiques pilotes.
- Maintenant · T1
- Fidélité utilisable sans carte. Problème : la carte papier est présentée dans 12 % des passages. Mesure : 40 % de présentation à 9 mois, lue dans le rapport de caisse. Statut : en cours.
- Ensuite · T2
- Rendre la commande du matin réflexe. Problème : 62 % des utilisateurs ne commandent qu’une fois. Mesure : 30 % de clients ayant commandé au moins quatre fois dans le mois. Solution non arrêtée.
- Ensuite · T2
- Donner aux boutiques la main sur leur catalogue. Problème : les ruptures sont signalées par téléphone au siège. Mesure : délai moyen de mise à jour d’un produit épuisé sous 2 minutes. Solution non arrêtée.
- Plus tard
- Commande pour une équipe ou un bureau. Demandé par 9 boutiques. Aucun engagement de date ni de contenu.
- Plus tard
- Retrait sans contact au comptoir. Dépend du renouvellement du parc de caisses. Aucun engagement.
Ce qui est remarquable dans cet extrait tient en deux points. Aucune ligne ne nomme d’écran ni de technologie, y compris dans la colonne Maintenant. Et les deux lignes de la colonne Ensuite annoncent explicitement que la solution n’est pas arrêtée, ce qui protège l’équipe le jour où elle proposera autre chose que ce que tout le monde avait en tête.
Les erreurs qui coûtent le plus cher
- Des dates précises sur des sujets non conçus. Annoncer le 14 mars pour une fonctionnalité dont personne n’a encore écrit les stories crée une dette de crédibilité. Le trimestre est la bonne maille au-delà de l’horizon immédiat, et il suffit à tout le monde.
- Une roadmap qui liste des fonctionnalités. Une liste de fonctionnalités se périme dès qu’une meilleure solution apparaît, et elle empêche l’équipe de la proposer. Écrivez le problème et le résultat attendu, laissez la solution ouverte tant qu’elle n’est pas conçue.
- La colonne Plus tard utilisée comme cimetière. Si tout ce qui est refusé y atterrit, la colonne devient une liste de deux cents lignes que personne ne relit. Gardez-la courte et dites clairement, par écrit, qu’elle n’engage à rien.
- Aucune mesure de succès. Une ligne sans valeur cible ni source de chiffre ne permet jamais de dire si le sujet a fonctionné. Un an plus tard, l’équipe ne sait pas ce qu’elle doit continuer ni ce qu’elle doit arrêter.
- Le délai de publication mobile oublié. Une version livrée n’est pas une version disponible. Le passage par les magasins d’applications puis l’installation par les utilisateurs s’étalent, et une roadmap qui les ignore annonce systématiquement trop tôt.
Roadmap produit et devis : ce que le prestataire en fait
Une agence qui voit la roadmap chiffre différemment. Elle sait ce qui arrive au trimestre suivant, donc elle peut proposer une architecture qui l’accueille au lieu d’une architecture à refaire. C’est l’un des rares documents qui fait baisser le coût total d’un projet simplement parce qu’il a été partagé.
La roadmap sert aussi à découper la commande. Plutôt qu’un lot unique difficile à comparer, vous obtenez un premier lot correspondant à la colonne Maintenant, chiffré précisément, et une estimation indicative pour la suite. Les devis deviennent comparables, et vous gardez la main pour changer de prestataire entre deux lots.
Pour la suite, le cahier des charges d’application mobile détaille le lot engagé, la grille de lecture d’un devis vous aide à comparer les propositions poste par poste, et les ordres de grandeur de prix donnent l’enveloppe par niveau d’ambition.
Les autres modèles de la rubrique
Deux documents souvent confondus
| Critère | Roadmap produit | Planning de projet |
|---|---|---|
| Question posée | Quels problèmes traitons-nous, et pourquoi ceux-là ? | Quand chaque tâche sera-t-elle terminée ? |
| Unité de la ligne | Un thème et un résultat mesuré | Une tâche et une charge |
| Maille de temps | Le trimestre, ou trois horizons | Le jour, ou la semaine |
| Public | Direction, métier, partenaires | Équipe et prestataire |
| Rythme de révision | Trimestriel, à date fixe | Hebdomadaire |
Roadmap produit : questions fréquentes
Qu’est-ce qu’une roadmap produit ?
C’est le document qui répartit dans le temps les problèmes qu’un produit va traiter, avec pour chacun le résultat attendu et sa mesure. Elle se lit en trente secondes, elle ne contient ni tâches ni technologies, et elle sert de support de décision aux personnes qui financent le produit et à celles qui l’utilisent.
Quelle différence entre une roadmap produit et un planning ?
La roadmap dit quels problèmes on traite et dans quel ordre, à la maille du trimestre. Le planning dit quand chaque tâche sera livrée, à la maille de la semaine. La roadmap précède le planning et lui survit : elle existe avant que le périmètre soit conçu, et elle continue après chaque mise en ligne.
Sur quelle durée faut-il construire une roadmap produit ?
Quatre trimestres est un horizon raisonnable, avec un niveau d’engagement décroissant. Le trimestre en cours est engagé et daté. Le suivant est décidé mais pas conçu. Les deux derniers sont indicatifs. Au-delà d’un an, une roadmap d’application mobile devient un exercice de style : le marché et les systèmes d’exploitation bougent trop.
À quelle fréquence faut-il mettre à jour une roadmap produit ?
À date fixe, une fois par trimestre, en une heure et avec les mêmes trois questions : ce qui a été livré et ce que cela a produit, ce qui a changé dans le contexte, ce qu’on déplace. Les mises à jour au fil de l’eau, par courriel, font perdre la trace des décisions et vident le document de sa valeur en quelques semaines.
Faut-il montrer la roadmap produit à son prestataire ?
Oui, et le plus tôt possible. Une agence qui connaît les deux trimestres suivants propose une architecture qui les accueille, au lieu d’une architecture optimisée pour le seul premier lot. C’est l’un des rares documents dont le partage fait baisser le coût total du projet plutôt que de l’augmenter.
Un avis technique sur votre périmètre en trente minutes ?
Décrivez votre application en quinze minutes : vous repartez avec un avis technique sous 48 h. Périmètre, technologies pertinentes et ordre de grandeur budgétaire. Sans engagement.
Ou par téléphone 06 32 64 24 80
Les modèles de documents de projet
Expression de besoin, note de cadrage, user stories, matrice de priorisation, roadmap produit : les documents s’enchaînent, et le même cas d’école fictif les traverse tous.