Ce que Phil Tetlock m'a appris sur les comités de pilotage.
Une roadmap IT à 3 ans est un forecast que personne n'évalue comme tel. Phil Tetlock a passé vingt ans à mesurer la précision des experts sur des horizons comparables. Ce qu'il a trouvé ne dit pas que les DSIs se trompent : il dit pourquoi ils ne peuvent pas faire autrement, et ce que ça change à la façon dont on devrait construire et gouverner une roadmap.
Quel CIO peut dire que sa roadmap à 3 ans a été respectée ? Quel CIO ose même faire l'exercice de la ressortir ?
Peu. Presque aucun. Non pas parce que les DSIs sont incompétents. Parce que tout le monde sait intuitivement ce que Phil Tetlock a mis 20 ans à démontrer avec des données : les prédictions à moyen terme sont structurellement peu fiables, et le reconnaître explicitement est inconfortable.
Le vrai problème n'est pas l'écart entre la roadmap et la réalité. C'est qu'on ne traite jamais cet écart comme un signal sur la méthode, seulement comme un signal sur le projet. Et qu'en évitant cette distinction, on construit la roadmap suivante avec les mêmes biais.
En 2005, Philip Tetlock publie Expert Political Judgment (Princeton University Press). Pendant vingt ans, il a suivi 284 experts (économistes, politologues, stratèges), enregistré 27 451 prédictions, et les a scorées avec rigueur. Résultat : les experts sont "barely above chance" sur les horizons au-delà de deux ans. La précision décline vers le hasard à cinq ans. Ce n'est pas une critique des individus. C'est une description de la complexité des systèmes sociaux et économiques.
Ce qui aggrave le tableau : les experts les plus confiants ne sont pas les plus précis. Les hedgehogs (ceux qui construisent tout autour d'une grande idée, d'un modèle central, d'une conviction forte) sont toujours moins bons que les foxes, qui agrègent des signaux contradictoires sans prétendre à la cohérence. La certitude est une posture. Pas un indicateur de qualité.
En 2011, l'IARPA (l'agence de recherche des services de renseignement américains) organise un tournoi de forecasting entre six équipes concurrentes. L'enjeu : qui prédit le mieux les événements géopolitiques à moyen terme ? L'équipe de Tetlock et Barbara Mellers, le Good Judgment Project, gagne. Nettement.
Les données produites par ce tournoi sont les plus solides qu'on ait sur la qualité prédictive humaine. Les superforecasters, le top 2% des participants identifiés sur leurs performances passées, ont battu les analystes de la CIA disposant d'informations classifiées de 25 à 30%. Ils ont battu le groupe contrôle de plus de 60%. Et un superforecaster travaillant à 400 jours d'horizon était aussi précis qu'un forecaster ordinaire à 80 jours, soit un avantage de cinq fois sur l'horizon temporel.
Ce n'est pas un don. C'est une méthode. Et la clé de cette méthode, Tetlock l'appelle l'outside view : avant de raisonner sur ce projet particulier, regarder la base rate. Combien de projets comparables, même type, même envergure, même contexte organisationnel, se sont terminés dans les délais et le budget annoncés ?
L'inside view, c'est le mouvement inverse et naturel : "Notre projet est différent. Voilà les raisons pour lesquelles on va réussir là où d'autres ont échoué." C'est le raisonnement qui domine dans presque tous les comités d'investissement IT. Et c'est précisément celui qui produit les prédictions les moins fiables.
Une roadmap IT à 3 ans est un ensemble de prédictions. "Dans 36 mois, nous aurons migré vers le cloud hybride. La dette technique aura été réduite de 40%. Le taux d'adoption des nouveaux outils dépassera 80%."
C'est du forecasting. Formulé sans probabilités. Évalué sans score. Révisé sans trace.
Il n'existe pas, à ce jour, d'étude académique mesurant spécifiquement le taux de réalisation des roadmaps IT à 3 ans. Cette lacune est en elle-même un signal : on ne traite pas la roadmap comme un forecast, donc on ne s'est jamais donné les outils pour l'évaluer comme tel. On n'a même pas cherché à mesurer.
Ce qu'on sait sur les projets IT est déjà éloquent. Selon une étude McKinsey conduite avec le BT Centre for Major Programme Management à Oxford, les grands projets IT dépassent en moyenne leur budget de 45%. Le Department of Defense américain, sur 37 milliards de dollars de dépenses IT en 2020, comptait seulement 35% de projets dans les clous budgétaires. Et Tetlock lui-même l'a écrit sans détour : "there is no evidence that geopolitical or economic forecasters can predict anything ten years out beyond the excruciatingly obviously… In my EPJ research, the accuracy of expert predictions declined toward chance five years out."
La roadmap IT à 3 ans est construite presque invariablement avec l'inside view. On part du projet, de la vision, des ambitions de transformation. Rarement de la base rate : combien de programmes de modernisation du SI de cette envergure, dans une organisation de cette taille, avec ce niveau de dette technique et ce portefeuille applicatif, ont tenu leurs engagements initiaux à 36 mois ? La réponse existe souvent dans la littérature. Elle est rarement intégrée.
Si la roadmap est, par nature, un mauvais outil de prédiction, pourquoi est-elle omniprésente ? Parce qu'elle remplit deux fonctions concrètes que les grandes organisations ne peuvent pas contourner.
La fonction d'alignement. Dans un grand groupe avec plusieurs métiers, des directions régionales, des entités en transformation permanente, le DSI ne peut pas opérer sans un futur partagé. La roadmap crée le référentiel commun sans lequel les arbitrages budgétaires deviennent des négociations ad hoc et les programmes pluriannuels perdent leur légitimité à chaque cycle. Ce n'est pas une prédiction : c'est un contrat organisationnel. Et dans les organisations de grande taille, ce contrat est la condition pour qu'une transformation puisse durer plus longtemps qu'une année fiscale.
La fonction budgétaire. Sans roadmap à 3 ans, pas de budget pluriannuel défendable. La roadmap est la langue dans laquelle le DSI parle à la DAF et au COMEX : elle rend les investissements IT lisibles pour des décideurs qui ne pensent pas en cycles technologiques. C'est un outil de traduction autant qu'un outil de pilotage.
Ces deux fonctions sont légitimes. Nécessaires, même. Le problème n'est pas la roadmap : il est dans ce qu'on fait de sa déclinaison financière.
Parce que la mécanique budgétaire a une logique propre : dès qu'un chiffre est inscrit dans un plan à 3 ans, il tend à devenir une trajectoire de référence. L'année 1 est un budget. L'année 2 est une orientation. L'année 3 est, au sens strict de Tetlock, une hypothèse à peine mieux fondée qu'une extrapolation. Mais dans la plupart des organisations, ces trois années sont gouvernées avec la même rigueur comptable, comme si la précision de l'année 1 se transférait mécaniquement sur l'année 3.
Ce n'est pas la roadmap qui est en cause. C'est l'ancrage de sa déclinaison financière dans le marbre, alors qu'elle n'a qu'une valeur d'orientation.
Le refus de nommer cette distinction a un coût précis : quand la réalité dévie, et elle dévie, on en tire des leçons sur le projet ("on avait sous-estimé la résistance au changement", "on avait surestimé la maturité du prestataire") sans jamais questionner la méthode de construction. La roadmap suivante est bâtie avec le même inside view, la même absence de probabilités explicites, le même défaut d'évaluation a posteriori.
On apprend sur le projet. Pas sur la façon dont on prédit.
Beaucoup d'organisations ont adopté le principe du plan glissant : chaque année, on refait l'exercice de la roadmap à 3 ans. L'horizon avance d'un an, le plan se met à jour, et l'organisation reste en théorie alignée sur un futur toujours actualisé.
Sur le fond, c'est la bonne approche. C'est exactement ce que Tetlock préconise pour les superforecasters : mettre à jour régulièrement ses prédictions à mesure que de nouvelles informations arrivent, plutôt que de s'accrocher à une prévision initiale.
Mais dans la pratique, le plan glissant produit rarement cet effet. Il produit quelque chose de différent : un exercice de forecasting annuel, réalisé avec le même inside view que le précédent, sans évaluer ce que le plan d'il y a un an avait prédit pour l'année qui vient de s'écouler.
C'est là que la valeur s'évapore. Un superforecaster qui met à jour sa prédiction commence par mesurer son écart : qu'est-ce que j'avais prévu ? Qu'est-ce qui s'est passé ? Qu'est-ce que je n'avais pas vu ? Ce n'est qu'après cette étape, inconfortable par construction, qu'il construit sa nouvelle prédiction. C'est cet aller-retour entre prédiction et réalité, entre erreur et calibration, qui produit l'amélioration progressive.
Le plan glissant tel qu'il est pratiqué dans la majorité des grandes organisations saute cette étape. On repart de la situation actuelle pour projeter un nouvel horizon à 3 ans, sans jamais scorer la prévision précédente. On adapte, mais on n'apprend pas.
La valeur du plan glissant est réelle. Mais elle est conditionnelle. Elle ne se réalise que si l'exercice commence par une rétrospective honnête : ligne à ligne, qu'avons-nous prédit l'an dernier pour cette année ? Qu'est-ce qui s'est réalisé ? Pourquoi l'écart, et était-il prévisible ou impossible à anticiper par nature ? Ce n'est qu'à partir de ce bilan que la mise à jour du plan produit quelque chose de plus qu'une réédition améliorée du même optimisme.
Tetlock n'est pas nihiliste. Le Good Judgment Project ne dit pas d'arrêter de prédire : il dit qu'on peut prédire mieux, à condition de changer de méthode. Appliqué aux roadmaps IT, deux changements sont concrets.
Différencier le régime de gouvernance selon l'horizon. Les engagements à 12 mois peuvent être précis, chiffrés, assortis de critères de révision explicites. Les projections à 36 mois doivent être gouvernées comme des hypothèses, avec des fourchettes, des conditions de révision nommées, et une tolérance à l'écart proportionnelle à l'incertitude. Ce n'est pas la même chose de dire "nous livrerons X en décembre" et "nous visons un état cible Y dans 3 ans, sous ces hypothèses." La même rigueur comptable appliquée aux deux horizons produit des comités de pilotage qui évaluent des hypothèses comme si c'étaient des engagements, et des DSIs qui passent leur temps à justifier des écarts que personne ne pouvait éviter.
Intégrer l'outside view dès la construction. Avant de voter la roadmap, poser la question : quelle est la base rate de réussite des projets de ce type dans des organisations comparables ? Les données existent (publications académiques, rapports sectoriels, communautés de DSIs). Elles sont rarement consultées parce que l'inside view est plus confortable, et parce qu'aucun sponsor ne veut entendre au moment de l'investissement que des programmes comparables ont dérivé de 45% en moyenne.
La roadmap IT à 3 ans est-elle utile ? Oui. Est-elle prédictive ? Pas vraiment. Tetlock explique précisément pourquoi, sans que ça soit la faute de personne.
Faut-il s'en passer ? Non. Faut-il la gouverner différemment selon qu'on parle de l'horizon 12 mois ou de l'horizon 36 mois ? Oui, et cette distinction change en profondeur la façon dont on construit les comités de pilotage, dont on évalue les retards, dont on tire les leçons d'un programme qui s'est écarté de sa trajectoire initiale.
La vraie question n'est pas "pourquoi notre roadmap s'est-elle trompée ?" Elle est : "est-ce que notre processus de prédiction est bon ?"
Aucun comité de pilotage IT que j'ai vu ne pose cette question.
Sources :
