Idée principale

Une roadmap fixe une direction, et c'est sa fonction. Le même geste produit un effet de verrouillage : une fois les places attribuées, un sujet qui n'en a pas ne peut plus être traité, quelle que soit son évidence.

Les sujets perdus par ce verrouillage ont un profil régulier. Ce sont de petites améliorations très utiles, très attendues, dont la valeur n'est pas discutée — mais trop petites pour mériter une place de roadmap, ou trop opportunistes pour attendre le prochain cycle. Un export texte imparfait qui évite à un client d'aller chercher des données dans dix écrans en fait partie : il ne deviendra jamais un sujet de roadmap, et il fait gagner plusieurs heures.

Le défaut n'est donc pas un défaut d'application — il ne se corrige pas en tenant mieux la roadmap. Il est le revers exact de ce qui la rend utile, et il appelle un dispositif séparé plutôt qu'un assouplissement.

Pourquoi c'est important

Cela empêche deux réactions également mauvaises : ajouter une colonne d'exceptions, ce qui défait la contrainte ; ou nier le problème, ce qui laisse l'équipe contourner la roadmap en cachette.

Cela donne aussi une lecture juste des demandes de dérogation. Elles ne sont pas toutes des tentatives de passer devant : une partie signale exactement ce que le format ne sait pas traiter.

Nuances et limites

Le verrouillage n'est pas toujours un coût. Dans une organisation qui se disperse, empêcher les petites opportunités est précisément l'effet recherché, et le sacrifice est assumé.

Et l'évidence de la valeur, invoquée pour contourner, est souvent une illusion : beaucoup de « petits sujets évidents » n'en sont pas, et la roadmap les aurait écartés à raison.

Questions ouvertes

• Quelle part de la capacité d'une équipe peut rester hors roadmap sans que la direction affichée devienne fictive ?