Roadmap publique depuis votre issue tracker, trois colonnes

Une roadmap publique est une liste de ce que vous prévoyez de construire, publiée là où les clients peuvent la voir. Le mot qui fait le travail est prévoyez : une roadmap est un ensemble de promesses sur l’avenir, et chaque élément dessus est un que vous tiendrez ou qu’on verra que vous n’avez pas tenu. C’est la raison d’en publier une, et c’est aussi la raison pour laquelle la plupart des roadmaps publiques deviennent obsolètes en un trimestre. La version qui survit est petite, dérivée de données que vous maintenez déjà, et connectée à l’autre bout au changelog, pour qu’une promesse devienne un fait sans que personne ne la ressaisisse.

À quoi sert une roadmap publique ?

Une roadmap publique dit à une cliente avec une demande que sa demande a été entendue, avant qu’elle soit livrée. C’est la moitié précoce de la fermeture de boucle : “planifié” répond à la question “quelqu’un a-t-il lu ça”, et “en construction” répond à “est-ce vraiment en train d’arriver”. Aucune des deux ne remplace la dernière étape, prévenir la demandeuse quand c’est livré, mais toutes deux réduisent le nombre de gens qui demandent entre-temps.

Ça fait aussi une chose pour l’équipe : ça force un engagement public, ce qui est le remède le moins cher connu contre un backlog qui cache silencieusement quatre cents éléments que personne ne construira.

Trois colonnes, dans un ordre fixe, suffisent. Une quatrième colonne (“en considération”, “en révision”, “backlog”) est là où les bonnes intentions deviennent un musée, et c’est la première que les clients apprennent à ignorer.

Votre roadmap devrait-elle être publique ?

Rendez-la publique si vous pouvez la garder petite et honnête ; gardez-la privée si l’alternative est une longue liste de peut-être. Le coût d’une roadmap publique n’a rien à voir avec sa publication : chaque élément dessus est maintenant une question que quelqu’un posera, en support, dans les appels de vente et dans les conversations de renouvellement. Dix éléments que vous construirez sont un atout. Soixante éléments que vous pourriez construire sont soixante conversations futures sur pourquoi non.

Deux raisons honnêtes de ne pas publier : vos plans changent plus vite qu’un trimestre, ou votre concurrence lit votre roadmap plus attentivement que vos clients. Les deux sont réelles, et les deux se résolvent en publiant moins plutôt que rien : seulement “en construction”, avec “planifié” gardé en interne, dit quand même à une demandeuse que son issue bouge.

Comment construit-on une roadmap publique à partir d’issues GitHub ?

Mettez un label par colonne sur les issues que vous suivez déjà, et rendez les issues étiquetées comme la roadmap. Rien n’est ressaisi, la roadmap ne peut pas dériver du travail, et la même issue qui a commencé comme demande d’une cliente se déplace à travers les colonnes sans changer d’identité.

Le mécanisme, tel qu’on l’exécute :

1. Un label par colonne, avec préfixe fixe : roadmap:planned, roadmap:building, roadmap:shipped. Toute issue dans un repository connecté qui en porte un apparaît dans cette colonne. Une issue sans aucun d’eux n’est pas sur la roadmap, ce qui est la plupart des issues, ce qui est correct.
2. Les colonnes sont un tableau ordonné, toujours dans le même ordre. Planifié, en construction, livré. Pas une map indexée par nom, pour qu’une lectrice (ou un widget) n’ait jamais à deviner la séquence.
3. Si une issue porte deux labels, le plus avancé gagne. Quelqu’un ajoutera roadmap:shipped avant de retirer roadmap:planned ; une machine à états guidée par “quel webhook est arrivé en dernier” mettrait l’élément dans des colonnes différentes selon l’ordre de livraison. Décider uniquement à partir de l’ensemble de labels rend la réponse la même quel que soit l’ordre d’arrivée des événements.
4. Livré est un état de label comme les autres. La carte se déplace quand l’issue reçoit roadmap:shipped, ou est fermée alors qu’elle le porte. La carte elle-même ne lie pas vers l’entrée de changelog ; l’entrée, rédigée à partir de la pull request qui a fermé l’issue, est l’endroit où vivent les détails.
5. Servez-la comme données. La roadmap est un document JSON avec ces trois colonnes, publié à côté du flux de changelog avec les mêmes en-têtes de cache, pour qu’un site docs, un widget ou une page de statut puissent la rendre sans seconde intégration. La documentation du flux a la forme exacte.

Un label est peu demander à une mainteneuse, et c’est toute l’intégration. Aucun tableau à garder synchronisé, aucun outil séparé où se connecter, et la demande que la cliente a classée est l’élément sur la roadmap ; quand c’est livré, c’est le même élément.

Que ne devrait pas contenir une roadmap publique ?

Elle ne devrait pas contenir de dates, d’estimations, ni rien dont vous auriez honte qu’on vous demande dans neuf mois. Les dates sont l’erreur classique : un trimestre sur une roadmap devient un engagement dans un deck de vente devient un ticket appelé “vous avez dit Q3”. Les colonnes disent assez. “En construction” signifie déjà “assez bientôt que quelqu’un y est”.

Elle ne devrait pas non plus contenir le backlog interne. Une roadmap avec trois cents éléments est un problème de recherche, pas une promesse, et la cliente qui trouve sa demande en position 212 a appris quelque chose que vous ne vouliez pas lui dire.

Comment la roadmap se connecte-t-elle au changelog ?

La roadmap et le changelog décrivent les mêmes issues de deux côtés, l’un pour l’avenir et l’autre pour le passé. Personne ne déplace une carte sur un tableau séparé. Une mainteneuse change le label sur l’issue sur laquelle elle travaillait déjà, l’entrée est rédigée à partir de la pull request, et quand une personne approuve cette entrée, une demandeuse dont le feedback via le widget est devenu cette issue y est prévenue. Déplacer la carte vers livré reste une étape à part, le label roadmap:shipped, alors intégrez-la à la même relecture ; approuver l’entrée ne le fait pas pour vous.

C’est la même boucle que décrit l’article sur la boucle de feedback du côté du changelog ; la roadmap est ce que la cliente voit au milieu de ça. Le récap outils de changelog couvre quels produits offrent une vue roadmap et lesquels la traitent comme un tableau séparé, ce qui est la différence qui décide si elle reste exacte.

À quoi ressemble une bonne roadmap publique ?

Elle a l’air courte, et chaque élément dessus est une issue que n’importe qui peut ouvrir. Le test est de savoir si une cliente peut aller d’un élément à la discussion derrière lui, et d’un élément livré à l’entrée qui décrit ce qui a réellement changé. Une roadmap qui est une liste de noms de fonctionnalités sans entrée est une brochure.

Un exemple travaillé, comme le JSON qu’un widget irait chercher :

{
  "columns": [
    { "column": "planned", "hasMore": false, "items": [
      { "id": "6b0c1f...", "column": "planned",
        "publicTitle": "Saved views on the inbox",
        "publicDescription": "Keep a filter you use often and come back to it.",
        "publishedAt": "2026-09-16T10:04:11.000Z" }
    ]},
    { "column": "building", "hasMore": false, "items": [
      { "id": "71a4e2...", "column": "building",
        "publicTitle": "Roadmap column in the widget",
        "publicDescription": "See what is coming without leaving the page.",
        "publishedAt": "2026-09-12T08:20:02.000Z" }
    ]},
    { "column": "shipped", "hasMore": false, "items": [
      { "id": "5c9d70...", "column": "shipped",
        "publicTitle": "Feedback filed as labelled issues",
        "publicDescription": "Widget submissions arrive as issues your triage already handles.",
        "publishedAt": "2026-09-02T15:41:37.000Z" }
    ]}
  ],
  "enabled": true,
  "language": "en"
}

Trois éléments sur trois colonnes forment une roadmap publique parfaitement bonne. Elle dit ce qui arrive, ce qui se passe, et ce qui s’est passé, et chaque ligne est vérifiable. Cinq autres formats, de Now/Next/Later à la roadmap par résultats, sont présentés avec des exemples d’éléments dans exemples de roadmap produit.

FAQ

Combien d’éléments une roadmap publique devrait-elle avoir ? Le moins possible que vous puissiez défendre. Moins de dix au total est normal pour un petit produit ; plus de trente en “planifié” est un backlog déguisé en roadmap.

Une roadmap publique devrait-elle avoir des dates ? Non. Les colonnes communiquent une séquence sans créer d’échéance. Si une cliente a besoin d’une date, c’est une conversation, pas un élément de roadmap.

Les clients devraient-ils voter sur les éléments de la roadmap ? Les votes mesurent qui s’est présenté, pas ce qui compte. Un commentaire sur l’issue expliquant la solution de contournement qu’ils utilisent aujourd’hui vaut plus que cinquante votes, et ça coûte quelque chose à qui vote, ce qui est le point.

Que se passe-t-il pour un élément de roadmap annulé ? Retirez le label et dites pourquoi sur l’issue. Un “on ne va pas faire ça” public fait partie de la boucle, et c’est le message que la plupart des équipes n’envoient jamais.

Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs, Comparatif d'outils de changelog