#pourprovoquer
Pourquoi votre roadmap technologique est déjà obsolète le jour où vous la présentez
Le mythe du plan à 3 ans dans un secteur qui se réinvente tous les 18 mois — et comment les DSI les plus efficaces ont appris à planifier autrement.
Il y a une scène qui se répète dans la grande majorité des organisations, avec une régularité métronomique et des variantes cosmétiques. Le DSI ou le CTO présente sa roadmap technologique au CODIR ou au Conseil d’Administration. Les slides sont propres, les couleurs cohérentes, les jalons bien répartis sur un axe temporel qui s’étire jusqu’à l’horizon 2027 ou 2028. Tout le monde hoche la tête. La roadmap est approuvée.
Six mois plus tard, la moitié des hypothèses sur lesquelles elle était fondée ont changé. Un an plus tard, elle est silencieusement rangée dans un dossier partagé où personne ne va plus. Dix-huit mois plus tard, une nouvelle roadmap est présentée, avec de nouvelles slides tout aussi propres.
Ce n’est pas un problème d’exécution. C’est un problème de méthode. Et il est temps de le nommer.
Le plan à 3 ans : un artefact managérial qui a survécu à son contexte
La roadmap technologique sur trois ans est un héritage d’une époque où les cycles technologiques étaient longs, prévisibles et relativement stables. Dans les années 1990 et 2000, planifier un déploiement ERP sur trois ans avait du sens : les technologies changeaient lentement, les alternatives étaient limitées, et la principale variable d’ajustement était le budget, pas l’écosystème.
Ce contexte n’existe plus. Les cycles technologiques se sont comprimés de façon dramatique. Les outils qui définissent les meilleures pratiques du secteur en 2024 n’existaient pas sous leur forme actuelle en 2022. Les LLMs ont transformé le développement logiciel en dix-huit mois. Les architectures cloud-native ont rendu obsolètes des choix d’infrastructure qui semblaient raisonnables il y a trois ans.
Planifier la technologie sur trois ans en 2025, c’est un peu comme naviguer avec une carte établie avant que les continents aient pris leur forme actuelle. Elle vous donnera une direction générale. Elle vous fera rater tous les détails qui comptent.
Et pourtant, l’exercice persiste. Parce qu’il rassure. Parce qu’il donne l’illusion du contrôle. Parce que les processus de gouvernance ont été construits pour fonctionner avec ce format. Et parce que personne ne veut être celui qui arrive en CODIR avec un post-it à la place des slides.
Les vraies fonctions d’une roadmap — et pourquoi elles sont rarement assumées
Une roadmap technologique sert en réalité plusieurs fonctions simultanées, et la confusion entre ces fonctions est l’une des sources principales de son inutilité pratique.
La fonction de communication
La roadmap permet de communiquer une direction à des parties prenantes qui n’ont pas le temps ou l’expertise pour s’intéresser aux détails. Elle synthétise une vision en quelques jalons compréhensibles. C’est une fonction légitime — à condition de ne pas confondre la simplification nécessaire pour la communication avec une promesse ferme d’exécution.
La fonction de priorisation
La roadmap force à faire des choix : qu’est-ce qu’on fait d’abord, qu’est-ce qu’on reporte, qu’est-ce qu’on abandonne. C’est sa valeur la plus concrète — et elle se déploie sur un horizon de six à douze mois, pas de trois ans. Au-delà de douze mois, les priorités auront suffisamment changé pour que l’exercice soit largement théorique.
La fonction politique
La roadmap protège le DSI. Elle lui permet de justifier des refus (ce n’est pas dans la roadmap), de défendre des investissements (c’est dans la roadmap), et de documenter les arbitrages qui lui ont été imposés. Cette fonction est rarement explicitée, mais elle est bien réelle. Et elle explique pourquoi certaines roadmaps sont construites non pas pour guider l’exécution, mais pour survivre aux audits.
La grande confusion est de traiter ces trois fonctions comme si elles pouvaient être satisfaites par le même document, sur le même horizon temporel. Elles ne le peuvent pas. Et essayer de le faire produit des roadmaps qui ne servent correctement aucune d’elles.
Ce que font différemment les organisations qui transforment vraiment
Les organisations qui réussissent leur transformation technologique ne planifient pas moins — elles planifient différemment. Quelques observations de terrain qui dessinent un modèle alternatif.
Elles séparent la vision de l’exécution
La vision technologique peut s’exprimer sur un horizon long — trois ans, cinq ans. Mais elle reste délibérément floue sur les détails d’implémentation. Elle décrit une destination, pas un itinéraire. L’itinéraire, lui, se planifie sur six à douze mois, avec des révisions trimestrielles.
Elles ritualisent la remise en question
Les meilleures organisations ont instauré des revues régulières dont l’objectif explicite n’est pas de célébrer l’avancement mais de remettre en question les hypothèses. Qu’est-ce qui a changé depuis notre dernière revue ? Quels choix feraient-on différemment aujourd’hui ? Que doit-on arrêter de faire ?
Elles mesurent autrement
Plutôt que de mesurer l’avancement par rapport aux jalons initiaux — un indicateur qui récompense la conformité au plan initial et pénalise les ajustements intelligents —, elles mesurent par des outcomes : la vélocité des équipes de développement, le temps de mise sur le marché, la satisfaction des utilisateurs, la réduction de la dette technique.
Elles assument l’incertitude publiquement
Les DSI les plus efficaces ont appris à présenter leurs plans avec des niveaux de confiance explicites : ce qu’on va faire dans les six prochains mois (confiance élevée), ce qu’on envisage pour les six mois suivants (confiance moyenne), ce vers quoi on s’oriente au-delà (direction, pas engagement). Cette honnêteté est plus utile — et finalement plus rassurante — que la fausse précision d’un Gantt sur trois ans.
Le vrai sujet : gouvernance et culture de l’incertitude
Le problème de la roadmap figée est en réalité un symptôme d’un problème plus profond : la difficulté des organisations à gouverner dans l’incertitude.
Les processus budgétaires sont construits sur des engagements annuels. Les instances de gouvernance attendent des plans détaillés avant d’allouer des ressources. Les indicateurs de performance récompensent le respect des engagements initiaux. Tout le système pousse à la fausse précision plutôt qu’à l’honnêteté sur l’incertitude.
Changer cela nécessite plus qu’une nouvelle méthode de planification. Cela nécessite une conversation sur ce que la gouvernance attend réellement du leadership technologique — et sur ce qu’il est raisonnable d’attendre dans un environnement qui change plus vite que n’importe quel plan.
La maturité technologique d’une organisation se mesure moins à la qualité de ses roadmaps qu’à sa capacité à les remettre en question quand le contexte l’exige — sans que ce soit vécu comme un échec.
Ce qu’il faut retenir
La roadmap technologique n’est pas un mauvais outil. C’est un outil mal utilisé, sur un horizon trop long, avec des niveaux de détail et de précision qui dépassent ce que n’importe quelle organisation peut raisonnablement prédire dans un environnement technologique en accélération.
Les DSI et CTO qui créent le plus de valeur ne sont pas ceux qui ont les roadmaps les plus belles. Ce sont ceux qui savent quand s’y tenir — et quand les jeter pour recommencer avec de meilleures informations.
Chez Kalyptus, nous rencontrons régulièrement des dirigeants IT confrontés à cette tension entre la demande de planification de leur organisation et la réalité d’un environnement qui ne se laisse pas planifier. C’est l’un des sujets sur lesquels nous aimons échanger — si vous vous reconnaissez dans ce constat, la conversation vaut la peine d’être menée.
Le mythe du plan à 3 ans dans un secteur qui se réinvente tous les 18 mois — et comment les DSI les plus efficaces ont appris à planifier autrement.
Il y a une scène qui se répète dans la grande majorité des organisations, avec une régularité métronomique et des variantes cosmétiques. Le DSI ou le CTO présente sa roadmap technologique au CODIR ou au Conseil d’Administration. Les slides sont propres, les couleurs cohérentes, les jalons bien répartis sur un axe temporel qui s’étire jusqu’à l’horizon 2027 ou 2028. Tout le monde hoche la tête. La roadmap est approuvée.
Six mois plus tard, la moitié des hypothèses sur lesquelles elle était fondée ont changé. Un an plus tard, elle est silencieusement rangée dans un dossier partagé où personne ne va plus. Dix-huit mois plus tard, une nouvelle roadmap est présentée, avec de nouvelles slides tout aussi propres.
Ce n’est pas un problème d’exécution. C’est un problème de méthode. Et il est temps de le nommer.
Le plan à 3 ans : un artefact managérial qui a survécu à son contexte
La roadmap technologique sur trois ans est un héritage d’une époque où les cycles technologiques étaient longs, prévisibles et relativement stables. Dans les années 1990 et 2000, planifier un déploiement ERP sur trois ans avait du sens : les technologies changeaient lentement, les alternatives étaient limitées, et la principale variable d’ajustement était le budget, pas l’écosystème.
Ce contexte n’existe plus. Les cycles technologiques se sont comprimés de façon dramatique. Les outils qui définissent les meilleures pratiques du secteur en 2024 n’existaient pas sous leur forme actuelle en 2022. Les LLMs ont transformé le développement logiciel en dix-huit mois. Les architectures cloud-native ont rendu obsolètes des choix d’infrastructure qui semblaient raisonnables il y a trois ans.
Planifier la technologie sur trois ans en 2025, c’est un peu comme naviguer avec une carte établie avant que les continents aient pris leur forme actuelle. Elle vous donnera une direction générale. Elle vous fera rater tous les détails qui comptent.
Et pourtant, l’exercice persiste. Parce qu’il rassure. Parce qu’il donne l’illusion du contrôle. Parce que les processus de gouvernance ont été construits pour fonctionner avec ce format. Et parce que personne ne veut être celui qui arrive en CODIR avec un post-it à la place des slides.
Les vraies fonctions d’une roadmap — et pourquoi elles sont rarement assumées
Une roadmap technologique sert en réalité plusieurs fonctions simultanées, et la confusion entre ces fonctions est l’une des sources principales de son inutilité pratique.
La fonction de communication
La roadmap permet de communiquer une direction à des parties prenantes qui n’ont pas le temps ou l’expertise pour s’intéresser aux détails. Elle synthétise une vision en quelques jalons compréhensibles. C’est une fonction légitime — à condition de ne pas confondre la simplification nécessaire pour la communication avec une promesse ferme d’exécution.
La fonction de priorisation
La roadmap force à faire des choix : qu’est-ce qu’on fait d’abord, qu’est-ce qu’on reporte, qu’est-ce qu’on abandonne. C’est sa valeur la plus concrète — et elle se déploie sur un horizon de six à douze mois, pas de trois ans. Au-delà de douze mois, les priorités auront suffisamment changé pour que l’exercice soit largement théorique.
La fonction politique
La roadmap protège le DSI. Elle lui permet de justifier des refus (ce n’est pas dans la roadmap), de défendre des investissements (c’est dans la roadmap), et de documenter les arbitrages qui lui ont été imposés. Cette fonction est rarement explicitée, mais elle est bien réelle. Et elle explique pourquoi certaines roadmaps sont construites non pas pour guider l’exécution, mais pour survivre aux audits.
La grande confusion est de traiter ces trois fonctions comme si elles pouvaient être satisfaites par le même document, sur le même horizon temporel. Elles ne le peuvent pas. Et essayer de le faire produit des roadmaps qui ne servent correctement aucune d’elles.
Ce que font différemment les organisations qui transforment vraiment
Les organisations qui réussissent leur transformation technologique ne planifient pas moins — elles planifient différemment. Quelques observations de terrain qui dessinent un modèle alternatif.
Elles séparent la vision de l’exécution
La vision technologique peut s’exprimer sur un horizon long — trois ans, cinq ans. Mais elle reste délibérément floue sur les détails d’implémentation. Elle décrit une destination, pas un itinéraire. L’itinéraire, lui, se planifie sur six à douze mois, avec des révisions trimestrielles.
Elles ritualisent la remise en question
Les meilleures organisations ont instauré des revues régulières dont l’objectif explicite n’est pas de célébrer l’avancement mais de remettre en question les hypothèses. Qu’est-ce qui a changé depuis notre dernière revue ? Quels choix feraient-on différemment aujourd’hui ? Que doit-on arrêter de faire ?
Elles mesurent autrement
Plutôt que de mesurer l’avancement par rapport aux jalons initiaux — un indicateur qui récompense la conformité au plan initial et pénalise les ajustements intelligents —, elles mesurent par des outcomes : la vélocité des équipes de développement, le temps de mise sur le marché, la satisfaction des utilisateurs, la réduction de la dette technique.
Elles assument l’incertitude publiquement
Les DSI les plus efficaces ont appris à présenter leurs plans avec des niveaux de confiance explicites : ce qu’on va faire dans les six prochains mois (confiance élevée), ce qu’on envisage pour les six mois suivants (confiance moyenne), ce vers quoi on s’oriente au-delà (direction, pas engagement). Cette honnêteté est plus utile — et finalement plus rassurante — que la fausse précision d’un Gantt sur trois ans.
Le vrai sujet : gouvernance et culture de l’incertitude
Le problème de la roadmap figée est en réalité un symptôme d’un problème plus profond : la difficulté des organisations à gouverner dans l’incertitude.
Les processus budgétaires sont construits sur des engagements annuels. Les instances de gouvernance attendent des plans détaillés avant d’allouer des ressources. Les indicateurs de performance récompensent le respect des engagements initiaux. Tout le système pousse à la fausse précision plutôt qu’à l’honnêteté sur l’incertitude.
Changer cela nécessite plus qu’une nouvelle méthode de planification. Cela nécessite une conversation sur ce que la gouvernance attend réellement du leadership technologique — et sur ce qu’il est raisonnable d’attendre dans un environnement qui change plus vite que n’importe quel plan.
La maturité technologique d’une organisation se mesure moins à la qualité de ses roadmaps qu’à sa capacité à les remettre en question quand le contexte l’exige — sans que ce soit vécu comme un échec.
Ce qu’il faut retenir
La roadmap technologique n’est pas un mauvais outil. C’est un outil mal utilisé, sur un horizon trop long, avec des niveaux de détail et de précision qui dépassent ce que n’importe quelle organisation peut raisonnablement prédire dans un environnement technologique en accélération.
Les DSI et CTO qui créent le plus de valeur ne sont pas ceux qui ont les roadmaps les plus belles. Ce sont ceux qui savent quand s’y tenir — et quand les jeter pour recommencer avec de meilleures informations.
Chez Kalyptus, nous rencontrons régulièrement des dirigeants IT confrontés à cette tension entre la demande de planification de leur organisation et la réalité d’un environnement qui ne se laisse pas planifier. C’est l’un des sujets sur lesquels nous aimons échanger — si vous vous reconnaissez dans ce constat, la conversation vaut la peine d’être menée.