La roadmap est l’un des terrains de friction les plus classiques entre les équipes qui travaillent en mode agile et celles qui fonctionnent en cycle en V. Rien d’étonnant : les premières cherchent à enchaîner des tests pour dérisquer la suite, tandis que les secondes ont déjà figé, parfois sur plusieurs mois, l’ensemble des décisions à exécuter.
Mais d’où vient réellement cette différence ?

Plutôt que de théoriser d’emblée, commençons par une scène que tout product manager a déjà vécue. Une situation simple, concrète, presque banale… et qui révèle, mieux que n’importe quel schéma, de quel type de roadmap nous parlons vraiment.

Il est 9h chez NovaMove, une PME spécialisée dans les déménagements professionnels.
Depuis un an, l’entreprise tente de digitaliser son expérience client en lançant une application : suivi du devis, préparation, checklist, notifications. Dans la salle de réunion, un problème urgent occupe tout le monde : des clients se plaignent de ne pas comprendre où en est leur déménagement. Un irritant simple, mais explosif.

Marc, responsable des opérations, ouvre la réunion : « On reçoit douze réclamations par jour. Les gens ne savent jamais si l’équipe arrive à l’heure, si le volume a bien été validé, si la facture est correcte. Ça nous coûte du temps, et ça dégrade notre NPS. Il faut corriger ça au plus vite. »

Sofia relève les yeux de son ordinateur : « C’est exactement ce qu’on voit aussi dans l’app.
Les utilisateurs se connectent mais n’y reviennent pas. Ils n’ont pas assez d’informations pendant les jours critiques. »

Cette fois, tout le monde parle du même problème : l’information client n’est pas assez transparente.

Deux approches, un même irritant

Marc projette son Gantt : « Pour régler ce problème, on peut accélérer le projet du “Portail Client Web”. On a planifié : analyse ce mois-ci, conception en juillet, développement en août, tests en septembre, go-live en octobre. C’est un projet classique : quelques écrans, du workflow, une intégration interne. »

Il explique calmement : « Le risque principal, pour nous, c’est de ne pas tenir le planning.
Les commerciaux attendent ce portail depuis un an. On ne peut pas s’éparpiller. »

Sofia prend la parole, visiblement en désaccord : « Je comprends, mais ce que tu proposes met trop de temps. On ne sait même pas si un portail complet va vraiment résoudre ce problème précis. Peut-être que les clients veulent juste une notification simple : “Votre équipe arrive dans 30 minutes.” »

Marc fronce les sourcils : « On ne peut pas envoyer ce genre de notification sans vérifier la cohérence logistique derrière. Ça peut devenir un cauchemar opérationnel si ce n’est pas fiable. »

Projet vs Produit : Deux risques opposés

Léa lève doucement la main, le ton calme mais ferme, comme pour ramener tout le monde au même point. « Attendez. Vous n’êtes pas en désaccord… vous ne parlez simplement pas du même risque. Et c’est normal que vos roadmaps ne se ressemblent pas. »

Elle se rapproche de l’écran où s’affiche le Gantt de Marc et désigne les blocs bleus qui s’enchaînent. « Marc, toi, tu gères un risque projet. Ce qui te fait peur, c’est très clair :
— mal dimensionner les efforts,
— livrer en retard,
— cramer les équipes en route. »

Elle se tourne vers lui, presque complice : « Dans ton contexte, ton Gantt est cohérent. Tu maîtrises le périmètre, tu connais le métier, et le ‘Portail Client Web’… c’est exactement le genre de sujet où votre expertise opère depuis des années. »

Léa se tourne maintenant vers Sofia, qui garde les bras croisés mais le regard déterminé.
« De ton côté, Sofia, le risque n’est pas le même. Toi, tu portes un risque produit. Ce qui t’inquiète, c’est autre chose :
— bâtir un portail que personne n’utilisera vraiment,
— passer à côté de la véritable attente des clients,
— investir des semaines sur un pari qui ne résout pas le problème. »

Elle adoucit la voix : « Ton objectif, ce n’est pas de livrer pour livrer. C’est de comprendre ce qui améliore réellement l’expérience client… et ça, tu ne peux le découvrir qu’en testant. »

Léa recule d’un pas pour embrasser l’ensemble de l’équipe du regard. « Vous traitez le même irritant, le même sujet… mais pas avec la même incertitude. Et c’est exactement pour ça que vos approches divergent. »

La roadmap agile

Sofia rallume son écran et projette sa roadmap. Trois colonnes sobres : Now, Next, Later. Rien d’alourdi, juste l’essentiel.

« Pour moi, on commence simple. NOW :
— on prototype une notification SMS “Votre équipe est en route”,
— on l’envoie à une trentaine de clients cette semaine,
— et on mesure immédiatement l’impact : moins d’appels ? moins de réclamations ? Plus de clarté ? »

Elle passe à la colonne d’à côté.
« NEXT :
— si ça marche, on l’intègre proprement dans l’app,
— si ça ne marche pas, on change de piste : peut-être une timeline dans l’application, ou un message automatique après validation du volume. On explore. »

Enfin, elle pointe la dernière colonne.
« LATER :
— le portail complet… si les tests montrent que c’est réellement nécessaire. »

Un silence s’installe. Marc se frotte le menton, surpris. « Attends… tu es en train de me dire qu’avant de lancer un portail à 150 000 €, tu veux vérifier si une simple notification peut régler 60 % du problème ? »

Sofia incline la tête. « Exactement. Si ça suffit, on gagne du temps, de l’argent, et on réduit la frustration client immédiatement. Et on évite trois mois de développement inutile. »

Marc laisse échapper un demi-rire, un peu désarmé. « Et si votre test foire complètement ? »

« Alors on aura appris vite », répond Sofia sans hésiter. « Quelques jours de travail, pas trois mois. Et on réoriente. Peut-être que ton portail sera la bonne solution, peut-être pas. Mais cette fois, on le saura… au lieu de simplement y croire. »

Analyse

La scène qui s’est déroulée entre Marc, Sofia et Léa illustre parfaitement l’origine profonde des tensions autour de la roadmap. À première vue, ils parlaient du même problème – les clients ne reçoivent pas suffisamment d’information pendant leur déménagement – mais leurs manières d’y répondre divergeaient complètement. La raison ne tient pas à la personnalité des acteurs, mais à la nature du risque que chacun gère et, par extension, au modèle opérationnel auquel il appartient.

Lorsque Marc défend son Gantt, il ne parle pas seulement d’un outil : il expose le fonctionnement du mode projet, hérité d’années de pratique dans un métier stable et maîtrisé.
Pour lui, comme pour toute organisation qui répète un processus connu depuis vingt ans, les décisions clés sont déjà prises : le périmètre est clair, les étapes sont définies, les risques identifiés. Dans ces conditions, il est logique de planifier l’ensemble sur une longue période avec :

  • un périmètre fixé dès le départ,

  • une séquence d’étapes linéaires,

  • une allocation de ressources prédéfinie.

Le cycle en V – ou mode projet – fonctionne très bien quand l’incertitude est faible, comme pour les déménagements que NovaMove gère depuis deux décennies. L’entreprise sait estimer un volume, prévoir une équipe, calibrer un devis, anticiper les aléas.
Dans ce contexte, le dérisquage n’a pas besoin d’être systématique : il a déjà été réalisé au fil des années.

À l’inverse, la réaction de Sofia mettait en avant une autre logique : celle du mode produit, propre aux environnements où la solution n’est pas connue d’avance.
L’application mobile de NovaMove n’est pas un service historique : c’est un levier de croissance encore expérimental, soumis à des comportements utilisateurs imprévisibles. Ici, le risque n’est pas de rater un planning : c’est de construire quelque chose d’inutile, de mal ciblé ou de trop coûteux pour l’impact réel.

Sofia raisonne en termes :

  • d’hypothèses,

  • de tests,

  • de signaux faibles,

  • d’apprentissage,

  • d’impact business.

Son rôle n’est pas d’exécuter une feuille de route figée, mais de réduire l’incertitude sur ce qui crée vraiment de la valeur pour le client. C’est ce qui explique pourquoi son format « Now / Next / Later » est volontairement flexible : il projette des problèmes à résoudre, pas des solutions figées.

Les différences de structures d’équipes

La scène montre également que la roadmap n’est pas un outil neutre : elle reflète la structure même de l’organisation.

  • Le mode projet fonctionne avec des équipes temporaires, constituées pour livrer un périmètre défini puis dissoutes. Leur performance se mesure à la capacité à livrer les fonctionnalités prévues, dans le délai prévu.

  • Le mode produit, à l’inverse, repose sur des équipes durables, assignées à un périmètre fonctionnel ou à un segment utilisateur. Elles existent tant que le produit ou leur périmètre fonctionnel existe. Leur performance se mesure à l’impact généré : rétention, satisfaction, engagement, revenu…

La scène se conclut sur une évidence que la discussion a rendue tangible :

Les roadmaps d’un projet et d’un produit ne peuvent pas se construire de la même manière.

  • Une roadmap projet anticipe : elle est fondée sur la certitude, la séquence et la coordination.

  • Une roadmap produit explore : elle est fondée sur l’apprentissage, l’adaptation et la réduction d’incertitude.

C’est pourquoi un projet peut être prévu sur trois ans, avec un ensemble de fonctionnalités prédéfinies, alors qu’un produit s’exprime plutôt sous la forme :

  • d’objectifs business à atteindre,

  • d’hypothèses à tester,

  • et d’un format dynamique du type Now / Next / Later qui accepte, voire recherche, le changement.

Une arnaque ?

Certains pourraient réagir : « Ton approche fonctionne avec cinq développeurs dans une jeune startup, mais pas pour orchestrer dix équipes interconnectées ». Et ils auraient d’une certaine manière raison : j’ai volontairement simplifié. Dès que l’on passe à l’échelle, le sujet n’est plus uniquement la forme de la roadmap, mais la gouvernance des dépendances, la gestion des contraintes externes, des plages de capacité et des engagements transverses.

Dans ces contextes, un diagramme de Gantt garde son utilité : il visualise le séquençage, les enchaînements critiques et les risques de collision. Mais il ne crée pas l’adaptabilité. Celle-ci provient d’autres mécanismes : cadences communes (PI Planning, Scrum of Scrums), priorisation (WSJF, coût du retard), objectifs partagés (OKR) et ops produit pour structurer les pratiques entre équipes. Ce sont ces artefacts organisationnels — et non l’outil — qui permettent d’ajuster le plan quand la réalité change.

Le modèle Now / Next / Later joue un rôle différent : c’est une représentation par horizons. Il simplifie la communication, expose l’incertitude de façon explicite et évite les fausses promesses. Certaines équipes l’utilisent comme support quotidien, d’autres comme outil de synchronisation directionnelle, mais il ne suffit pas à lui seul pour gérer des dépendances lourdes ou des contraintes réglementaires.

La vraie difficulté, lorsqu’on travaille avec plusieurs équipes, vient des types de dépendances :

  • techniques (un module doit être prêt avant un autre),

  • organisationnelles (équipes différentes, priorités divergentes),

  • capacitaires (mêmes experts sur plusieurs sujets),

  • externes (partenaires, régulateurs, fournisseurs).
    C’est leur orchestration qui conditionne la prévisibilité autant que l’agilité — plus encore que le format de la roadmap. Ce sujet mériterait un article entier à lui seul.

Mais tout ça, ce sera le sujet d’un autre article…

ARTICLES CONNEXESPLUS DE L'AUTEUR