Trois causes reviennent, et aucune n'est un problème d'outil. Elles se repèrent avant de lancer le premier chantier, ce qui est le seul moment où les corriger coûte peu.

Une roadmap digitale bien faite finit rarement à la poubelle. Elle finit dans un dossier partagé, consultée trois fois le premier mois, puis jamais. Les chantiers, eux, se lancent au fil des urgences, dans un ordre qui n’a plus rien à voir avec le document.

Ce n’est presque jamais une question de qualité du document. Trois causes reviennent, et elles se corrigent.

Cause 1 : la roadmap décrit des projets, pas des décisions

Une roadmap classique aligne des chantiers avec des trimestres : refonte du site, mise en place du CRM, automatisation de la facturation. Cela se lit bien et cela ne se déploie pas, parce qu’un chantier n’est pas une décision : c’est le résultat d’une décision qui n’a pas été écrite.

Derrière « mise en place du CRM » se cachent au moins quatre arbitrages : quel processus commercial on modélise, qui saisit, ce qu’on reprend de l’ancienne base, et qui administre après. Tant qu’ils ne sont pas posés, le chantier ne démarre pas vraiment, il tourne en réunion.

La correction est simple et inconfortable : pour chaque ligne de la roadmap, écrire la décision qu’il faut prendre avant, qui la prend, et à quelle date. Une roadmap de dix lignes devient alors une liste de quinze décisions, dont on découvre souvent que la moitié n’appartient à personne.

Cause 2 : personne n’a le mandat de trancher

C’est la cause la plus fréquente et la moins avouée. La roadmap est validée par un comité, ce qui donne une impression d’engagement collectif, mais aucun nom n’est attaché à aucun arbitrage.

Le résultat est prévisible : chaque décision remonte, redescend, revient en réunion. Le chantier n’est pas bloqué par une difficulté technique, il est bloqué par une chaîne de validation que personne n’a mesurée.

Le test qui révèle le problème tient en une question : pour ce chantier, qui peut dire non tout seul ? Si la réponse demande plus de cinq secondes, ou si elle contient un « ça dépend », le chantier glissera. Ce n’est pas une hypothèse, c’est ce qu’on observe systématiquement.

La correction consiste à nommer, par chantier, une personne dont l’arbitrage ne se rouvre pas. Cela suppose d’accepter qu’elle se trompe parfois. Une décision imparfaite prise en une semaine bat une décision juste prise en trois mois, parce que la seconde arrive après que le contexte a changé.

Cause 3 : le coût de fonctionnement n’a jamais été chiffré

Les roadmaps chiffrent la construction et oublient l’entretien. C’est ce qui les rend séduisantes au moment de la validation et intenables au bout d’un an.

Chaque chantier livré ajoute une charge récurrente : quelqu’un doit surveiller les automatisations, corriger les flux quand un outil connecté change, tenir la qualité de la donnée, appliquer les correctifs de sécurité. Cette charge est invisible tant qu’elle est petite, puis elle sature la personne qui la porte, et les chantiers suivants attendent.

Le calcul à faire avant de valider est celui-ci, chantier par chantier : combien d’heures par mois, et qui les prend sur son temps ? Une roadmap dont la somme dépasse ce que l’équipe peut absorber n’est pas ambitieuse, elle est fausse.

C’est aussi ce qui permet de trancher entre internaliser et externaliser, non par principe mais sur un chiffre.

Ce qui change quand on corrige les trois

La roadmap raccourcit. C’est le signe le plus fiable que le travail a été fait : une liste de quatre chantiers réellement décidés, dotés d’un arbitre et dont la charge d’entretien est chiffrée, remplace une liste de douze intentions.

L’ordre change aussi, souvent radicalement. Le chantier qu’on voulait faire en premier parce qu’il est visible passe derrière celui qui débloque les autres. Une automatisation qui libère cinq heures par semaine finance, en temps, les chantiers suivants ; une refonte de site n’en libère aucune.

Enfin, les réunions changent de nature. On n’y présente plus l’avancement, on y prend les décisions écrites en face de chaque ligne. C’est plus court et beaucoup plus désagréable, ce qui est bon signe.

À quoi ressemble une ligne correctement annotée

La théorie se comprend vite et se met en pratique mal. Voici la même ligne de roadmap avant et après, sur un exemple générique.

Avant. « T2 : mise en place du CRM. » Une ligne, un trimestre, un porteur implicite. Elle se valide sans discussion parce qu’il n’y a rien à discuter.

Après. La même ligne devient quatre décisions datées, chacune avec un nom.

  • Quel processus commercial on modélise : celui que l’équipe pratique, ou celui qu’on voudrait qu’elle pratique ? Décision du directeur commercial, avant le début du trimestre.
  • Qui saisit, et qu’est-ce qui est obligatoire ? Trois champs obligatoires remplis toujours valent mieux que douze remplis une fois sur deux. Même arbitre, même date.
  • Ce qu’on reprend de l’ancienne base, et ce qu’on archive. Décision partagée avec la personne qui connaît réellement l’état des données, généralement pas celle qui pilote le projet.
  • Qui administre l’outil une fois livré, et sur quel temps ? Décision de direction, parce qu’elle engage une charge récurrente.

La ligne a triplé de volume et le chantier a gagné sa seule chance de démarrer à l’heure. On observe presque toujours la même chose au passage : une des quatre décisions n’appartenait à personne, et c’est précisément celle qui aurait bloqué le projet en cours de route.

Cet exercice a un effet secondaire utile. Il rend visible le fait qu’un chantier de trois mois demande souvent deux semaines de décisions préalables, ce qui explique mieux que n’importe quel discours pourquoi le trimestre précédent n’a rien livré.

Le test en cinq minutes

Prenez votre roadmap actuelle et, pour chaque ligne, répondez à trois questions.

  • Quelle décision doit être prise avant que ce chantier démarre, et est-elle écrite quelque part ?
  • Qui peut la trancher seul, par son nom ?
  • Combien d’heures par mois ce chantier coûtera-t-il une fois livré, et sur le temps de qui ?

Une ligne qui laisse une seule de ces trois questions sans réponse ne se déploiera pas. Ce n’est pas une prédiction pessimiste, c’est simplement qu’il lui manque ce qu’il faut pour démarrer.

C’est le travail que nous faisons en amont d’un projet, et il occupe l’essentiel de nos missions de stratégie digitale. La partie visible, les chantiers eux-mêmes, vient après et va vite quand cette partie est faite.