Une feuille de route qui ne nomme aucune décision est un inventaire.

Trois symptômes d’un inventaire déguisé

Une feuille de route peut avoir toutes les apparences d’un plan et n’en être pas un. Trois signes le révèlent assez vite, et ils apparaissent généralement ensemble.

• Les mêmes sujets reviennent d’un trimestre à l’autre, légèrement reformulés, sans jamais être ni livrés ni abandonnés.
• Personne ne sait dire pourquoi une initiative est placée avant une autre, au-delà d’un ordre de saisie.
• Une même initiative est comprise différemment selon l’équipe interrogée, et l’écart n’apparaît qu’au moment de l’estimation.

Dans les trois cas, le document décrit des travaux souhaités sans décrire ce qui empêche d’y aller. Il fonctionne comme un inventaire : utile pour savoir ce qui existe, inutile pour savoir quoi faire lundi.

Ce qu’est réellement une décision

Une décision n’est pas une tâche, et ce n’est pas non plus une préférence. C’est un choix entre des options qui s’excluent, dont les conséquences engagent plusieurs équipes, et qui coûte cher à défaire une fois pris.

« Refondre le portail client » n’est pas une décision, c’est un chantier. Les décisions qu’il contient, elles, sont identifiables : le portail conserve-t-il son propre référentiel de comptes ou s’appuie-t-il sur celui de l’ERP ? les partenaires y accèdent-ils, ou traite-t-on d’abord les clients directs ? l’authentification existante est-elle conservée pendant la transition ? Tant que ces questions restent ouvertes, aucune estimation n’a de sens, parce que chaque équipe chiffre une version différente du projet.

Un test simple permet de séparer les deux : si deux personnes compétentes peuvent répondre différemment sans que l’une ait tort, c’est une décision. Si la réponse est évidente une fois posée, c’est une tâche.

Un retard s’explique rarement par un manque de capacité. Il s’explique presque toujours par un arbitrage que personne n’avait la responsabilité de rendre.

Enregistrer la décision, pas seulement l’annoncer

Les équipes techniques ont formalisé cette pratique depuis longtemps sous le nom de registre de décisions d’architecture. Le principe est modeste : chaque décision structurante fait l’objet d’une note courte, versionnée avec le code ou la documentation, qui indique le contexte, les options envisagées, le choix retenu et ses conséquences assumées.

Le format est documenté publiquement et repris dans les guides d’architecture de Microsoft, qui insistent sur un point souvent négligé : une décision n’est pas immuable. Elle peut être remplacée par une décision ultérieure, et c’est précisément la trace de ce remplacement qui a de la valeur.

Rien n’oblige à réserver cette pratique à l’architecture logicielle. Les choix de gouvernance, de périmètre, de modèle de données ou de responsabilité entre équipes se prêtent au même traitement, et bénéficient du même effet : quelqu’un peut, dix-huit mois plus tard, comprendre pourquoi l’organisation a fait ce choix sans avoir à retrouver la personne qui l’a pris.

Relire la trajectoire à date fixe

Une feuille de route décrit un futur qui change. Ce qui distingue un plan vivant d’un document abandonné n’est pas sa précision initiale, mais l’existence d’un moment prévu pour le confronter à la réalité.

Trois questions suffisent à cette relecture, et elles se posent mieux ensemble que séparément : quelles décisions sont encore en attente, et qui les bloque ? quelles décisions prises se sont révélées inexactes, et que faut-il remplacer ? quelles dépendances ont changé depuis la dernière fois ?

Les organisations qui tiennent cette discipline racontent souvent le même effet secondaire : la feuille de route rétrécit. Les initiatives que personne ne peut débloquer sortent du document au lieu d’y séjourner indéfiniment, et ce qui reste devient défendable devant une direction. Une trajectoire courte et tranchée vaut mieux qu’un inventaire complet que personne ne relit.