Pas encore décidé ne veut pas dire peu faisable

Pourquoi les roadmaps IA ont besoin d’un backlog d’arbitrages, pas seulement d’un backlog de cas d’usage.

En juin 2026, BCG a interrogé 11 749 salariés dans quatorze marchés : parmi ceux qui utilisent l’IA régulièrement, 42 % gagnent au moins une journée par semaine, mais 66 % n’ont reçu aucune consigne sur l’usage de ce temps.

Ce chiffre dit qu’un gain apparaît sans que personne ait décidé de ce qu’il devient, et cette absence de décision se retrouve à l’échelle des processus. Prenons les notes de frais, un cas d’usage que tout le monde a vu passer : un assistant vérifie les justificatifs, repère les anomalies et monte le dossier, si bien qu’un travail de préparation qui occupait plusieurs personnes se réduit fortement.

Le salarié, lui, est remboursé au même rythme qu’avant, puisque son dossier attend toujours deux validations successives, celle de son manager puis celle du contrôle de gestion. La seconde a été ajoutée après un incident, plusieurs années plus tôt, quand ni les seuils ni les contrôles automatiques n’étaient ceux d’aujourd’hui ; personne ne la défend vraiment, personne ne l’a rouverte non plus, parce que le projet n’avait pas mandat pour cela.

Le résultat se lit différemment selon l’endroit où l’on se place : c’est une réussite pour qui mesure le temps de préparation, et un non-événement pour qui attend son remboursement. Le processus n’a pas bougé, il est seulement mieux alimenté, et c’est précisément ce qui manque à beaucoup de roadmaps IA : rien n’y signale que cette seconde validation mériterait d’être rediscutée, ni qui aurait le pouvoir de le faire.

Ce qui demande du travail, ce qui demande une décision

La plupart des exercices de priorisation croisent la valeur d’un cas d’usage avec sa faisabilité, ce qui évite de lancer des projets séduisants sur le papier mais impossibles à livrer : on y regarde la qualité des données, les capacités techniques, le coût d’intégration, les compétences disponibles et le délai avant les premiers résultats.

L’exercice est utile, et le problème vient plutôt de tout ce que le mot « faisabilité » finit par absorber. Une technologie immature, une donnée inexploitable ou une intégration trop coûteuse rendent un cas d’usage coûteux à construire ; supprimer une validation, attribuer la responsabilité d’une donnée, redéfinir un rôle ou arrêter une activité ne coûtent, eux, presque rien à construire, mais supposent qu’une décision soit prise, souvent au-dessus de l’équipe qui porte le cas d’usage. Dans une grille unique, ces deux natures d’obstacle se traduisent de la même façon : la note baisse.

Elles n’appellent pourtant pas la même réponse, puisqu’un obstacle technique se lève avec du travail, un investissement ou une autre solution, alors qu’un obstacle organisationnel attend qu’une personne ou une instance exerce son mandat. Certains sujets réunissent les deux : désigner le propriétaire d’une donnée n’en améliore pas la qualité du jour au lendemain, mais réconcilier les versions dans un tableur ne dira jamais qui fera autorité ensuite. À force de confondre les deux, un arbitrage qui n’a pas encore été rendu finit par compter comme une raison de ne pas lancer le sujet.

Le déclassement silencieux

Personne ne s’oppose à ces sujets ; ils sortent du portefeuille sans que la question soit posée.

Le mécanisme est ordinaire : les équipes remontent les irritants qu’elles rencontrent et imaginent les solutions qui tiennent dans leur périmètre, tandis que les sujets transverses dépendent d’acteurs absents de l’atelier, qu’il s’agisse d’une autre direction, du propriétaire d’un processus, du détenteur d’un budget ou d’une instance de contrôle. Cette dépendance dégrade la faisabilité, le sujet descend dans le classement, les cas locaux et réversibles remontent, et le sponsor valide une roadmap cohérente, raisonnable et livrable.

Déclasser un sujet se défend, puisqu’aucune organisation ne peut traiter toutes ses dépendances en même temps. Le défaut vient après, lorsqu’un sujet écarté pour une raison organisationnelle ne reçoit ni décideur, ni échéance, ni valeur associée : il ne recule pas dans la file, il en sort.

Les quick wins gagnent souvent cette sélection, et c’est tant mieux, puisqu’ils rendent du temps à des équipes saturées, prouvent que les outils servent à quelque chose, développent les compétences et révèlent des problèmes que les présentations de cadrage ne montrent pas ; il serait d’ailleurs difficile de demander du temps à une équipe sans lui en avoir d’abord rendu. Reste qu’ils sont rapides et peu risqués parce qu’ils demandent peu d’arbitrages extérieurs à l’équipe, ce qui limite d’autant leur portée : ils installent la confiance dont la suite aura besoin, mais leur accumulation ne change pas la manière dont l’organisation fonctionne.

Le travail change plus vite que les décisions qui l’organisent

Les études récentes ne démontrent pas ce mécanisme, elles en montrent les effets à grande échelle. Les chiffres cités plus haut viennent de la quatrième enquête AI at Work de BCG, qui ajoute un résultat utile : les répondants des entreprises ayant redessiné leurs processus ont 24 points de probabilité en plus de constater une amélioration mesurable de la performance. Workday et Hanover Research relèvent de leur côté que, dans 89 % des organisations interrogées, moins de la moitié des rôles ont été adaptés aux capacités de l’IA. Or redéfinir un rôle est un arbitrage et non un chantier de delivery : que les rôles n’aient pas bougé indique que ces arbitrages n’ont pas été rendus.

Le décalage est le même dans les deux cas : des gains apparaissent dans le travail quotidien bien avant que l’organisation ait décidé ce qu’elle voulait en faire, et comme une journée libérée n’a pas de destination naturelle, les agendas la remplissent.

Le deuxième backlog

Un backlog de cas d’usage dit ce que les équipes vont construire, pas ce que l’organisation accepte de trancher.

Un diagnostic IA gagnerait à produire deux listes tenues ensemble. La première est familière, c’est le backlog de delivery, qui rassemble ce qu’il faut construire ou modifier, du produit à l’agent, de l’intégration au jeu de données, du processus à la formation. La seconde contient ce que l’organisation doit décider pour que la valeur visée devienne accessible : quelle validation reste nécessaire, qui possède la donnée de référence, qui a le dernier mot, quel niveau de risque est accepté, quel rôle évolue, quelle activité s’arrête, à quoi sert le temps libéré.

Ces décisions existent déjà, dispersées dans les risques, les dépendances, les prérequis, les comptes rendus ou une case « à escalader ». Les réunir dans une vue n’ajoute pas une couche de gouvernance, cela évite qu’une décision nécessaire soit traitée comme un obstacle extérieur au programme.

Pour que ce backlog d’arbitrages ne soit pas un registre de décisions rebaptisé, chaque arbitrage reste relié aux cas d’usage qu’il conditionne et porte :

• la décision attendue et l’instance capable de la rendre ;
• les options ouvertes, y compris le maintien de la situation actuelle ;
• les risques, le coût et la réversibilité de chaque option ;
• la valeur déjà accessible sans cette décision ;
• la valeur additionnelle qui en dépend, avec son niveau de preuve ;
• l’échéance, et ce qui se passe si rien n’est décidé.

Un même arbitrage conditionne souvent plusieurs cas d’usage ; il figure alors une seule fois, relié à chacun d’eux et à la valeur qu’ils placent sous cette décision, faute de quoi le portefeuille compte deux fois la même valeur et disperse une décision unique entre plusieurs équipes.

Revenons aux notes de frais. Le delivery réduit déjà le temps de préparation et documente le taux d’anomalies détectées, ce qui donne la matière à présenter à la direction financière. L’arbitrage porte alors sur trois options : maintenir la seconde validation, la supprimer en dessous d’un seuil, ou la remplacer par un contrôle a posteriori sur échantillon ; cette dernière peut être testée un trimestre puis abandonnée si les anomalies remontent, ce qui la rend plus facile à accorder qu’une suppression définitive.

L’écart entre la valeur déjà acquise et celle qui dépend de la décision chiffre la part de valeur placée sous arbitrage, qu’elle relève d’une hypothèse, d’une observation en pilote, d’une mesure ou d’une extrapolation. Le dirigeant garde ainsi la main, puisqu’il tranche à partir de ce que le delivery a produit plutôt que sur une promesse.

Le lien joue dans les deux sens : le delivery fournit les preuves qui permettent de décider, et les décisions ouvrent au delivery un périmètre qu’il ne pouvait pas franchir seul.

Trois ajustements dans la priorisation

D’abord, désagréger la faisabilité en cinq critères distincts : faisabilité technique, disponibilité des données, capacité de delivery, intensité du changement et arbitrage requis. Un arbitrage peut légitimement peser sur le séquencement, à condition de rester visible séparément et de déclencher son propre parcours, au lieu d’être fondu dans une note unique.

Ensuite, donner à chaque sujet un statut explicite : démarrer, expérimenter pour produire une preuve, soumettre à arbitrage ou abandonner. Seul le dernier fait sortir un sujet de la roadmap, et « pas encore décidé » ne veut pas dire « peu faisable ».

Enfin, revoir les arbitrages à une cadence alignée sur celle du delivery, sans créer pour autant un comité de plus : dans l’instance la plus proche qui dispose du mandat. Un sujet de donnée, de risque ou de responsabilité n’a pas toujours besoin de remonter au comité exécutif, il a besoin d’arriver devant ceux qui peuvent le trancher.

Une organisation peut identifier ses opportunités, prioriser ses cas d’usage et livrer des résultats tout en évitant sa propre transformation, parce que ses méthodes rendent très visible ce qu’il faut construire et beaucoup moins les décisions dont dépend la portée de ce qui sera livré. La prochaine revue de portefeuille est le bon endroit pour reprendre chaque cas d’usage et nommer la décision qu’il attend, ainsi que la personne qui peut la rendre.

Sources

• BCG, AI at Work: Why Strategy Matters More Than Tools, juin 2026
• BCG, AI Is Reshaping Jobs Faster Than Companies Are Reshaping Work, 3 juin 2026
• Workday / Hanover Research, Companies Are Leaving AI Gains on the Table, janvier 2026