Comment éliminer les incertitudes d’un projet ?

Le comité de pilotage se réunit pour la troisième fois. Le choix entre l’intégrateur de Montréal et celui de Québec est encore reporté : on attend une dernière référence client. Pendant ce temps, l’équipe ne peut ni planifier la migration ni réserver les experts. Éliminer les incertitudes d’un projet, c’est d’abord reconnaître que l’attente coûte plus cher que la décision.

Les chiffres cités proviennent d’études publiques de McKinsey et du PMI ; ils portent sur de grands projets et servent de repères, non de prévision pour votre projet.

Selon McKinsey, en collaboration avec l’Université d’Oxford, les grands projets TI dépassent leur budget de 45 % et leur échéancier de 7 % en moyenne, tout en livrant 56 % moins de valeur que prévu.

Pourquoi les incertitudes d’un projet sont-elles indissociables des risques ?

Parce qu’un risque est, selon la définition du PMBOK rappelée par le PMI, un événement ou une condition incertaine qui, s’il survient, affecte les objectifs du projet : sans incertitude, il n’y a pas de risque, seulement des problèmes. Le processus d’identification des incertitudes va donc directement de pair avec la gestion des risques.

Gérer les risques et réduire les incertitudes réclame toute l’habileté du chargé de projet. Il doit établir les risques possibles, mettre en place des actions qui donnent un meilleur contrôle pendant la réalisation, et garder en tête les objectifs à atteindre. Ces actions se résument presque toutes à une chose : des prises de décision.

L’incertitude liée à la gestion de projet est inévitable. Le travail du chargé de projet ne consiste pas à la faire disparaître, mais à valider et clarifier les hypothèses une à une, pour que le projet devienne plus clair et plus simple pour les équipes qui y participent.

Où se cachent les incertitudes dans un projet TI ?

Dans toutes les facettes du projet, mais surtout dans le processus de réalisation : l’approche, le découpage en phases, la preuve de concept, l’approbation des livrables, les approvisionnements et le recours à des partenaires externes. Chacune de ces dimensions est une question à laquelle personne n’a encore répondu au moment du lancement.

Les questions concrètes : procède-t-on en agile ou par itérations planifiées ? Faut-il prévoir plusieurs phases ? Quel type de preuve de concept mène-t-on, et sur quel périmètre ? Qui approuve les livrables, et selon quels critères ? Comment gère-t-on les approvisionnements ? Fait-on appel à des partenaires extérieurs ? Ces questions forment l’arsenal du chargé de projet. Elles doivent recevoir une réponse rapide et précise.

Le coût de l’attente est mesuré. Les repères tirés de l’étude McKinsey et Oxford, menée sur plus de 5 400 projets TI :

• 45 % : dépassement de budget moyen des grands projets TI (budget initial supérieur à 15 millions de dollars américains).
• 7 % : dépassement d’échéancier moyen de ces mêmes projets.
• 56 % : valeur livrée en moins par rapport aux bénéfices prévus.
• La moitié des grands projets TI analysés dépassent massivement leur budget, les projets logiciels étant les plus exposés.

Pourquoi chaque décision crée-t-elle de nouvelles incertitudes ?

Parce que choisir une solution élimine l’incertitude de devoir choisir, mais active aussitôt le doute sur la justesse du choix : si le doute persiste, de nouvelles décisions et actions s’imposent. C’est normal. Certaines incertitudes ne se résolvent jamais entièrement, puisque chaque décision ouvre la porte à des situations imprévisibles.

Prenons une analogie. Pour voyager de Montréal à Québec, il faut d’abord choisir le véhicule. Ensuite l’itinéraire : la Rive-Sud ou la Rive-Nord, le vieux pont de Québec ou le pont Pierre-Laporte. Chaque choix ferme une question et en ouvre une autre. Mais sans les décisions de départ, le voyage n’a pas lieu.

En voiture, les moyens de gérer les risques sont standardisés : ceinture, assurance, météo. En gestion de projet, ils varient d’un cas à l’autre, et chaque situation est plus complexe. Jumelée à la gestion des risques, la réduction des incertitudes fait avancer le projet avec prévoyance, au lieu de le laisser en suspens.

Le plus grand risque n’est-il pas de ne pas décider ?

Oui : ne pas prendre une décision n’est ni une sécurité ni une option, c’est un risque en soi, parce qu’il maintient toutes les incertitudes ouvertes et retarde toutes les décisions suivantes. Le bon chargé de projet accélère donc le processus décisionnel en plus de prévoir des plans pour réduire les incertitudes. Sans cela, il devra gérer des imprévus sans préparation.

Reporter une décision ne réduit pas le risque, il en change seulement le propriétaire : c’est l’équipe qui le porte à votre place.

Le comité de pilotage qui attend une dernière référence client depuis trois séances en est l’exemple parfait. Pendant l’attente, l’estimation des coûts du projet repose sur des hypothèses que personne ne peut valider, et chaque semaine de flottement se retrouve au budget.

C’est précisément ce que révèle un examen de santé de projet mené par un tiers : la liste des décisions en attente, leur âge et ce qu’elles bloquent. Dans les projets que nous accompagnons, cette liste explique plus de retards que tous les problèmes techniques réunis.

Comment réduire concrètement les incertitudes d’un projet ?

Tenez un registre des hypothèses, donnez à chaque décision ouverte un propriétaire et une date limite, testez les hypothèses critiques par une preuve de concept ciblée, et faites de la revue des décisions un point fixe du comité de pilotage. Quatre gestes simples, rarement faits ensemble.

Le registre des hypothèses est le plus négligé. Chaque hypothèse du plan de projet TI, sur la disponibilité des équipes, la qualité des données ou la date de livraison d’un fournisseur, est une incertitude déguisée en certitude. La nommer permet de la valider ou de la remplacer par une décision.

Le rapport Pulse of the Profession 2025 du PMI, fondé sur plus de 3 000 professionnels de projet, insiste sur le sens des affaires : comprendre le contexte, savoir naviguer dans l’organisation et faire avancer les choses. Autrement dit, la capacité de faire prendre des décisions, pas seulement de les documenter.

En allant de l’avant avec une solution choisie, les étapes suivantes deviennent plus faciles à visualiser et à définir. Il est alors plus simple de prendre les prochaines décisions et de diminuer les incertitudes. C’est un cercle vertueux, à condition d’oser le premier tour.

Peut-on vraiment éliminer les incertitudes d’un projet ?

Non, mais on peut les remplacer une à une par des décisions datées, assumées et révisables, ce qui est exactement ce qu’on attend d’un chargé de projet. Un projet clair n’est pas un projet sans inconnues. C’est un projet où l’équipe sait lesquelles restent ouvertes, qui doit les fermer et avant quand. Le reste s’appelle de la gestion des risques, et elle commence toujours par une décision.

Questions fréquentes

Quelle est la différence entre une incertitude et un risque de projet ?

Une incertitude est une question sans réponse : quelle approche, quel fournisseur, quel périmètre. Un risque est un événement incertain qui, s’il survient, a un effet positif ou négatif sur les objectifs du projet, selon la définition du PMBOK rappelée par le PMI. Chaque incertitude non tranchée alimente un ou plusieurs risques ; chaque décision en ferme certains.

Peut-on éliminer toutes les incertitudes d’un projet ?

Non. L’incertitude est inhérente à tout projet, et chaque décision en crée de nouvelles. L’objectif réaliste est de la réduire progressivement : valider les hypothèses, trancher les questions ouvertes à temps et documenter ce qui reste inconnu. Un projet où l’équipe sait ce qu’elle ignore est déjà mieux géré qu’un projet qui prétend tout savoir.

Pourquoi les grands projets TI dépassent-ils autant leur budget ?

Selon McKinsey et l’Université d’Oxford, qui ont analysé plus de 5 400 projets TI, les grands projets dépassent leur budget de 45 % en moyenne et livrent 56 % moins de valeur que prévu. Les causes tiennent souvent à des décisions prises trop tard : périmètre flou, hypothèses jamais validées et choix technologiques reportés jusqu’au moment le plus coûteux.

Comment accélérer les décisions dans un projet sans les bâcler ?

Donnez à chaque décision un propriétaire, une date limite et l’information minimale requise pour trancher. Une preuve de concept ciblée de quelques semaines vaut mieux que six mois d’analyse. Fixez aussi la règle du comité de pilotage : une décision reportée deux fois est escaladée. La vitesse vient de la clarté du processus, pas de la précipitation.