Roadmap agile : comment les product managers la construisent

Qu’est-ce qu’une roadmap agile ?

C’est un plan d’action, dont le product manager est responsable, qui décrit comment un produit va évoluer dans le temps. Elle se distingue d’une roadmap classique sur trois points :

• Elle est organisée autour d’objectifs et d’hypothèses, pas d’une liste de livrables datés.
• Elle est révisée en continu, au rythme de ce que l’équipe apprend.
• Elle sert de contexte aux sprints : les product owners s’en servent pour préparer la planification, et plusieurs équipes agiles peuvent partager la même roadmap.

Elle doit être réactive aux pivots. Mais réactive ne veut pas dire instable : chaque changement doit avoir une raison.

Concrètement, une roadmap agile répond à trois questions que se posent toutes les équipes : sur quoi travaillons-nous maintenant, qu’est-ce qui vient ensuite, et pourquoi dans cet ordre ? Si votre roadmap ne permet pas d’y répondre en une minute, elle n’aide pas encore à planifier.

Comment le product manager la conçoit

Le point de départ n’est pas la liste des demandes reçues. C’est une question de fond : quel est le chemin le plus court vers le market fit, ou, s’il est atteint, vers les indicateurs qui comptent ?

Pour y répondre, le product manager formule des hypothèses en croisant trois sources : la vision stratégique, les retours du marché et les contraintes techniques. Ces hypothèses deviennent des initiatives, placées dans le temps. Je recommande de tenir en parallèle la roadmap produit et la roadmap des hypothèses : la seconde explique la première.

Petite équipe ou grande organisation

Dans une équipe de cinq à dix personnes, la roadmap tient sur une page. Le product manager la construit presque seul, en discutant au fil de l’eau avec les développeurs et le dirigeant. Le risque n’est pas la lourdeur, c’est l’implicite : chacun croit partager la même priorité jusqu’au jour où deux personnes découvrent qu’elles ne parlaient pas de la même chose. Écrivez-la, même courte.

Dans une organisation de plusieurs équipes, la roadmap devient un outil de coordination. Il faut un niveau commun (objectifs, grandes initiatives, dépendances) et un niveau par équipe, plus détaillé. Le risque s’inverse : trop de niveaux, trop de revues, et une roadmap qui décrit l’organigramme plutôt que le produit. La règle que j’applique : chaque initiative du niveau commun a une seule équipe qui la porte, même si d’autres y contribuent.

Les questions à se poser pour chaque initiative

Avant d’ajouter une initiative, passez-la au crible :

1. Quelle est sa priorité par rapport aux objectifs stratégiques et aux hypothèses à valider ?
2. Quand prévoit-on de la traiter ?
3. Y a-t-il des échéances que l’équipe doit connaître : réglementaires, contractuelles, commerciales ?
4. Quelles sont ses dépendances, internes ou avec d’autres équipes ?
5. Quelle équipe la porte, et a-t-elle la capacité nécessaire ?
6. Peut-on garder les équipes stables, ou faut-il les réorganiser ?
7. Si l’on réorganise, a-t-on prévu le temps de montée en compétence ?

La dernière question est presque toujours oubliée. Elle explique une bonne partie des retards.

De quoi est faite une roadmap agile

Un axe temporel adapté

Les éléments doivent s’enchaîner logiquement. L’axe peut être précis (trimestres) ou volontairement flou : « maintenant », « ensuite », « plus tard ». Le format « maintenant, ensuite, plus tard » est devenu courant parce qu’il assume l’incertitude : plus l’horizon est lointain, moins il est détaillé. Choisissez l’axe selon votre contexte, et gardez en tête qu’il servira en réunion de planification de sprint.

Des éléments décrits complètement

Une roadmap contient des epics (des fonctionnalités qui s’étalent sur plusieurs sprints), des fonctionnalités, des chantiers techniques, parfois des actions issues des rétrospectives. Les epics et fonctionnalités sont décrites avec leur contexte, leur objectif, une user story représentative et une définition de « terminé ».

Ce niveau de description permet aux développeurs de comprendre l’intention et de travailler de façon autonome sans compromettre la suite. Si votre outil permet de relier chaque élément à une hypothèse, avec une étiquette ou un champ, faites-le : c’est ce que je décris dans créer une roadmap agile dans Asana.

Un exemple de planification trimestrielle

Exemple fictif, pour rendre la méthode concrète. Un éditeur de logiciel B2B qui gère les interventions de techniciens. Deux équipes de cinq développeurs, un product manager, un designer. Objectif de l’année : réduire le départ des clients de taille moyenne. Hypothèse prioritaire du trimestre : ces clients partent parce que la planification des techniciens leur prend trop de temps.

1. Calculer la capacité réelle

Un trimestre, c’est six sprints de deux semaines. Deux équipes de cinq développeurs offrent sur le papier soixante sprints-personne. Dans cet exemple, l’équipe réserve 30 % pour la maintenance, les bugs, le support et les congés, d’après ce qu’elle a réellement consommé les trimestres précédents. Il reste quarante-deux sprints-personne pour la roadmap. C’est ce chiffre, pas le premier, qui sert à planifier.

2. Placer les initiatives

Total engagé : trente-huit sprints-personne sur quarante-deux. La marge restante n’est pas du confort, c’est ce qui absorbe l’imprévu sans faire sauter la roadmap.

3. Prévoir la décision de mi-trimestre

Les suggestions automatiques ne sont engagées que si la mesure confirme le gain de temps à la fin du sprint 3. Le seuil est écrit avant de commencer : par exemple, une baisse d’au moins un tiers du temps de planification chez les clients pilotes. Sinon, les quatorze sprints-personne repartent vers une autre hypothèse. Cette décision prévue rend la roadmap à la fois engageante et souple.

4. Communiquer à chaque public

Une page pour la direction : objectif, hypothèse, décision de mi-trimestre. Le détail pour les équipes. Le seul « maintenant » pour les commerciaux, qui ne doivent pas vendre le « plus tard ».

Le cycle de planification

Une roadmap agile vit selon un cycle simple :

1. Brouillon par le product manager, à partir des hypothèses et des objectifs.
2. Revue avec les équipes : objections, risques techniques, estimations grossières. Les ajustements se font sans trahir les fondamentaux : chaque élément garde une raison d’être.
3. Publication dans l’outil de travail, avec notification des personnes concernées.
4. Découpage des éléments proches en items de backlog lors du grooming.
5. Revue trimestrielle : confronter la roadmap aux hypothèses validées ou invalidées, et l’ajuster.

Ce rythme fonctionne quelle que soit la taille de l’organisation. Quand une roadmap concerne plusieurs équipes, la revue trimestrielle devient le moment où l’on inspecte, adapte et communique ensemble. L’implication des équipes à chaque étape est le sujet de roadmap agile : comment impliquer vos équipes.

Impliquer les équipes sans créer un comité

Consulter tout le monde ne veut pas dire décider à vingt. Quatre règles gardent la revue utile :

• Un seul décideur par roadmap, connu de tous. La matrice RASCI sert précisément à l’écrire.
• Des commentaires écrits avant la réunion : le brouillon circule quelques jours avant, et la réunion ne traite que les objections.
• Des questions précises plutôt qu’un « qu’en pensez-vous ? » : quel risque technique voyez-vous, quelle dépendance manque, qu’est-ce que vos clients vont mal comprendre ?
• Un journal des décisions : ce qui a été tranché, par qui, et pourquoi. Il évite de rouvrir les mêmes débats à chaque trimestre.

Les développeurs apportent les risques et les estimations, les équipes métier apportent le terrain et les échéances. Ni les uns ni les autres ne votent la priorité : ils l’éclairent.

Les erreurs à éviter, et comment les repérer

Chacune de ces erreurs laisse des traces visibles bien avant de coûter cher.

Avec le recul

J’ai écrit la première version de cet article en 2022, après plusieurs années de produit, surtout en startup. Depuis, j’ai porté des roadmaps dans des contextes très différents : la transformation IA d’un contact center chez Home Partners of America, puis la direction produit de Dotworld, où nous avons livré quatre SaaS en six mois. Voici ce que je garde, ce que je nuance, et ce qui a changé.

Ce que je garde

Une roadmap organisée autour d’objectifs et d’hypothèses, révisée à un rythme connu. Je n’ai jamais vu une roadmap de livrables datés survivre à un trimestre sans être réécrite en silence. Je garde aussi la question de la montée en compétence : elle explique encore une bonne part des retards que je rencontre.

Ce que je nuance

J’écrivais que le format « maintenant, ensuite, plus tard » assume l’incertitude. C’est vrai pour l’équipe. Pour une direction ou un client, il peut ressembler à une absence d’engagement. Dans les organisations plus grandes, j’ajoute donc quelques engagements datés, assumés comme tels, ceux qui dépendent d’une contrainte externe, et je les distingue visuellement du reste. Une roadmap peut contenir des dates ; elle ne doit pas en être faite.

Je nuance aussi l’idée d’un product manager qui rédige seul le brouillon. Dans une petite équipe, c’est efficace. Dans une organisation de plusieurs centaines de personnes, le brouillon gagne à être co-écrit avec le responsable technique et un responsable métier, sinon la revue tourne à la négociation.

Ce que les assistants IA ont changé

La partie rédactionnelle est devenue rapide : description d’epics, user stories, synthèse de dizaines d’entretiens clients. Un prototype cliquable qui prenait une semaine se fait souvent en une journée. Cela change l’économie de la roadmap : tester une hypothèse coûte moins cher, donc on peut en tester davantage avant d’engager une équipe pour un trimestre.

La difficulté de fond, elle, n’a pas bougé : il faut choisir. Un assistant produit vingt initiatives plausibles en une minute, et rien ne dit lesquelles reposent sur un vrai problème. Les synthèses doivent être vérifiées contre les sources : une citation client déformée dans un résumé peut orienter un trimestre entier. Relire, comparer aux sources, repérer ce qui a été inventé : c’est la règle que j’applique et que j’enseigne.

Le reste tient à l’organisation. Les 70 % organisationnels dont je parle pour les projets IA valent aussi pour la roadmap : qui décide, qui est consulté, à quel rythme on révise. L’outil accélère l’écriture ; il ne tranche pas.

Et l’IA dans tout ça ?

Les initiatives IA elles-mêmes demandent une planification différente. Leur résultat est incertain : on ne sait pas à l’avance quelle qualité le système atteindra sur vos données. Planifiez-les comme des hypothèses, avec un seuil de qualité à atteindre et une décision prévue si le seuil n’est pas atteint. C’est la différence entre une roadmap qui accumule les POC et une roadmap qui met des systèmes en production, comme je l’explique dans du POC IA à la production.

Dans l’exemple trimestriel plus haut, des suggestions d’affectation fondées sur un modèle suivraient exactement le même schéma : un seuil de qualité mesuré sur des cas réels, une date de décision, et un plan de repli. Pour choisir par où commencer, voyez choisir les premiers usages IA d’une équipe ; pour vérifier ensuite le gain réel, relecture comprise, mesurer le gain de temps de l’IA.