Une roadmap communique la direction du produit sur plusieurs mois. En agile, elle s'exprime en objectifs et en thèmes, pas en liste de fonctionnalités datées.

Pourquoi pas de dates fermes lointaines

Promettre « la fonctionnalité X le 15 juin » trois mois à l'avance revient à s'engager sur des hypothèses qui changeront. À la première priorité qui bascule, la roadmap datée devient fausse et personne ne lui fait plus confiance.

La roadmap par horizons

• Maintenant : ce sur quoi l'équipe travaille, assez précis.
• Bientôt : les prochains objectifs, sans détail de réalisation.
• Plus tard : les grandes directions, volontairement floues.

Plus l'horizon est lointain, moins on est précis — comme pour la planification agile.

Exprimer des objectifs, pas des solutions

« Réduire le nombre de clientes qui ne comprennent pas leur solde » est un objectif de roadmap. « Ajouter une infobulle sur l'écran points » est une solution possible parmi d'autres — elle appartient au backlog, pas à la roadmap.

Réviser la roadmap

Une fois par mois ou par trimestre, avec les parties prenantes : ce qui a avancé, ce qui a changé, pourquoi. La roadmap est un support de conversation, pas un contrat.

Exemple concret : la roadmap de l'application de fidélité pour le trimestre : « Maintenant — rendre les points clairs et fiables. Bientôt — faciliter l'utilisation des points en caisse. Plus tard — ouvrir aux partenaires. » Aucune date de fonctionnalité, des objectifs que tout le monde comprend.

À vous de jouer : formulez, pour un produit que vous connaissez, un objectif de roadmap pour « maintenant » et un pour « plus tard ».