Publier une feuille de route revient à publier des intentions dans un format que les lecteurs interprètent comme des promesses. Le bénéfice est réel, le malentendu aussi, et il vient de la mise en forme plus que du contenu.
La réponse courte. Rendre sa roadmap publique donne de la visibilité, ouvre la discussion et oblige à clarifier ses priorités. Cela crée aussi quatre risques concrets, dont le plus fréquent est qu'une intention affichée devienne un engagement aux yeux du client. La parade tient à la façon d'exprimer l'incertitude, pas au fait de publier moins.
Les bénéfices, sans les surestimer
La discussion devient possible. Un lecteur qui voit un sujet mal cadré peut le dire avant que le travail commence. C'est le gain le plus concret et le moins souvent cité.
Les questions répétitives diminuent. « Est-ce que vous prévoyez X » se pose une fois sur une page publique au lieu de dix fois en support.
Les priorités doivent être écrites. L'exercice de publication force à trancher des choses qui restaient floues en interne. Beaucoup d'équipes découvrent leurs propres arbitrages en les rédigeant.
Le produit paraît vivant. Pour un produit jeune, c'est un signal que la page de fonctionnalités ne donne pas.
En revanche, aucune donnée publique solide ne permet de dire que publier sa roadmap améliore la rétention d'un pourcentage donné. Les bénéfices ci-dessus sont observables ; le lien chiffré avec la rétention ne l'est pas.
Les quatre risques
Une intention lue comme un engagement. Le risque principal. Un élément affiché « en cours » devient, dans l'esprit du lecteur, une chose qui arrive bientôt. Il fonde parfois une décision d'achat dessus.
Les dates. Une date publiée est retenue même assortie de réserves. La règle la plus sûre est de ne pas en publier ; à défaut, un trimestre plutôt qu'un mois.
La visibilité concurrentielle. Réelle mais souvent surévaluée. Connaître vos intentions n'aide un concurrent que si l'exécution est triviale. Le cas qui mérite attention est celui d'un sujet différenciant sur lequel vous avez de l'avance.
La roadmap réduite à un classement de votes. Publier un tableau ordonné par nombre de voix crée l'attente que le haut de liste soit construit dans l'ordre. Les votes sont un signal de fréquence, pas une décision, et l'affichage doit le refléter.
Communiquer l'incertitude
C'est le cœur du sujet. Une roadmap publique honnête distingue les degrés de certitude au lieu de tout présenter au même niveau.
| Niveau | Formulation utile | Ce que le lecteur doit comprendre |
|---|---|---|
| En cours | « En construction » | Cela arrive, sans date promise |
| Décidé | « Prévu » | Nous le ferons, l'ordre peut bouger |
| À l'étude | « À l'étude » | Nous y réfléchissons, cela peut ne pas se faire |
| Écarté | « Non prévu », avec la raison | Cela n'arrivera pas, n'attendez pas |
La dernière ligne est celle qu'on omet et celle qui rapporte le plus. Une roadmap qui ne contient que des choses à venir laisse toutes les autres demandes dans un état indéterminé. Dire non explicitement libère le lecteur, et évite qu'il attende deux ans.
Les colonnes doivent aussi pouvoir reculer. Un sujet qui passe de « prévu » à « à l'étude », avec une phrase d'explication, coûte bien moins cher qu'un sujet qui reste affiché « prévu » pendant dix-huit mois.
Building in public n'est pas tout publier
La démarche est souvent confondue avec la transparence intégrale, qui n'est ni tenable ni utile.
Ce qui gagne à être public : ce qui est en cours, ce qui est décidé, ce qui est écarté et pourquoi, et ce qui vient d'être livré, via le changelog.
Ce qui gagne à rester interne : les hypothèses non validées, les arbitrages liés à des contraintes techniques, les échéances commerciales, et les sujets qui dépendent d'un client identifiable.
La frontière raisonnable est celle de l'utilité pour le lecteur. Une information qui ne l'aide pas à décider quoi que ce soit n'a pas besoin d'être publiée pour prouver une bonne intention.
Questions fréquentes
Faut-il publier des dates ?
Le plus souvent non. Une date sert surtout à celui qui la lit pour planifier, et elle sera retenue littéralement. Un ordre relatif et des statuts clairs répondent au même besoin sans créer d'engagement.
Que faire quand un élément est abandonné ?
Le dire, avec la raison, et le laisser visible un temps. Un élément qui disparaît sans explication est remarqué, et interprété plus sévèrement que l'abandon lui-même.
Une roadmap publique convient-elle à tous les produits ?
Pas toujours. Sur des marchés très concurrentiels ou avec des cycles longs, une version restreinte aux clients existants est un compromis raisonnable et conserve l'essentiel du bénéfice.
Faut-il laisser les utilisateurs voter dessus ?
Le vote se prête mieux à une page de demandes qu'à la roadmap elle-même. Mélanger les deux fait passer le message que le classement décide, ce qui n'est pas le cas.
Pour aller plus loin
- Comment un changelog public renforce la confiance client
- Du feedback aux fonctionnalités : le framework SaaS
- Utiliser les votes de fonctionnalités pour réduire le churn
Afficher des statuts clairs vaut mieux que d'afficher des dates. Voyez la feuille de route et les tarifs.