L’estimation des coûts de projet : simple, mais sans pardon

Le directeur des finances demande un chiffre pour le projet ERP avant le prochain conseil d’administration, dans dix jours. L’intégrateur a envoyé une fourchette, le fournisseur une autre, et personne n’a encore listé les livrables. C’est exactement dans ce contexte que naissent les estimations de coûts de projet qui ne pardonnent pas.

La méthode pour éviter ce piège est simple. C’est son application qui exige de la discipline.

Les statistiques de dépassement citées proviennent d’études publiques de McKinsey et de Panorama Consulting; les pourcentages de contingence sont des repères tirés de la pratique de PlanAxion.

Selon l’étude menée par McKinsey et l’Université d’Oxford sur plus de 5 400 projets TI, les grands projets 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 l’estimation des coûts de projet est-elle simple, mais sans pardon ?

L’estimation des coûts de projet est simple parce qu’elle repose sur trois gestes connus, découper, chiffrer et valider, et sans pardon parce qu’une sous-estimation se paie en dépassement, en portée amputée ou en projet abandonné. La méthode n’a rien de mystérieux. Ce qui manque, presque toujours, c’est le temps qu’on accepte d’y consacrer.

Un changement technologique exige d’abord de choisir la solution en fonction de vos objectifs, puis d’en nommer les grandes composantes : progiciels, processus, changements organisationnels, matériel, infrastructures, intégrations. Tant que ces composantes ne sont pas écrites, tout chiffre est une opinion.

Le coût d’une mauvaise estimation est documenté. McKinsey observe que 17 % des projets TI tournent si mal qu’ils menacent l’existence même de l’entreprise, avec des dépassements supérieurs à 200 %. Et le rapport ERP 2026 de Panorama Consulting indique que plus du quart des organisations ont dépassé leur budget, surtout à cause de technologies additionnelles découvertes en cours de route.

Comment découper le projet en livrables pour estimer les coûts ?

On estime un projet livrable par livrable, en associant à chacun ses inducteurs de coûts, ses types de ressources, ses efforts et ses taux horaires, parce qu’il est beaucoup plus facile de chiffrer dix petits blocs qu’un seul gros. Un livrable qui s’étire sur des mois cache toujours des hypothèses non dites.

Pour chaque livrable, identifiez le ou les inducteurs de coûts qui pèsent le plus : nombre d’interfaces, volume de données à convertir, nombre de sites, nombre de rapports. Associez-y une métrique d’effort, puis répartissez cet effort par type de ressource. Enfin, informez-vous des taux horaires réels de chacune, internes comme externes.

Ne faites pas cet exercice seul, ni à la dernière minute. Faites participer les experts de chaque composante, idéalement ceux qui formeront l’équipe de projet. Une équipe qui a préparé l’estimation s’y tient; une équipe qui la reçoit toute faite en doute dès la première semaine.

Ce découpage a un bénéfice secondaire : il devient la colonne vertébrale du plan de projet TI. Livrables, efforts et ressources sont déjà là; il ne reste qu’à les placer dans le temps.

Comment appliquer la contingence et obtenir un consensus sur le budget ?

La contingence s’applique composante par composante, selon le risque propre à chacune, et le budget devient crédible seulement quand les experts qui l’ont préparé et le promoteur du projet s’entendent sur le chiffre. Un pourcentage unique appliqué à l’ensemble nivelle les risques et protège mal les composantes les plus incertaines.

Voici les repères chiffrés que nous utilisons pour cadrer la discussion :

• 45 % de dépassement budgétaire moyen et 7 % de dépassement d’échéancier pour les grands projets TI (McKinsey et Université d’Oxford, 2012).
• 56 % de valeur livrée en moins par rapport aux prévisions (McKinsey et Université d’Oxford, 2012).
• +15 % de dépassement de coûts pour chaque année additionnelle de durée prévue (McKinsey et Université d’Oxford, 2012).
• 17 % des projets TI deviennent des « cygnes noirs » avec plus de 200 % de dépassement (McKinsey et Université d’Oxford, 2012).
• Plus du quart des organisations en dépassement budgétaire, technologies additionnelles imprévues en cause principale (Panorama Consulting, rapport ERP 2026).
• 450 000 $ US de coût médian de projet et plus de la moitié des organisations dans leur budget (Panorama Consulting, rapport ERP 2025).
• 10 à 15 % de contingence sur une composante bien connue, 25 à 40 % sur une composante jamais réalisée par l’organisation (repères PlanAxion).

Le consensus compte autant que la précision. Il se construit entre le groupe d’experts qui a chiffré et le promoteur qui paiera, et il fonde l’engagement mutuel. Quand un tiers est impliqué, ce consensus devient la base de l’entente contractuelle.

Il arrive souvent que le total dépasse ce que le promoteur espérait. Ne baissez pas le chiffre parce qu’il déplaît. Si le calcul est rigoureux, défendez-le, puis proposez des leviers honnêtes : réduire la portée, changer l’approche ou étaler le projet sur une période plus longue.

Un manufacturier de Drummondville qui coupe 20 % d’une estimation pour plaire au conseil retrouvera ces 20 % dans les demandes de changement, avec intérêts.

Une estimation qu’on rabote pour la faire accepter n’est plus une estimation : c’est une promesse qu’on sait déjà ne pas pouvoir tenir.

Comment valider la précision d’une estimation de coûts ?

On valide une estimation en la comparant à une seconde estimation préparée de façon indépendante, ou aux coûts réels d’un projet comparable terminé avec succès. Les écarts révèlent les hypothèses oubliées et les postes sous-évalués, avant que le projet ne les révèle à votre place.

Si vous en avez les moyens, faites préparer deux estimations en parallèle par des équipes qui ne se parlent pas. Sinon, comparez avec l’historique : c’est pour cela qu’il faut conserver les coûts réels des projets antérieurs.

McKinsey appelle cette pratique la prévision par classe de référence, et cite un fournisseur de soins de santé qui a arrêté un projet d’un milliard de dollars après avoir constaté qu’il était deux fois plus long et deux fois plus cher que tout projet comparable.

Documentez enfin les hypothèses derrière chaque chiffre. Une demande de changement se chiffre en minutes quand les hypothèses de départ sont écrites, et en réunions interminables quand elles ne le sont pas. Cette documentation est aussi votre meilleur outil pour éliminer les incertitudes du projet au fil des phases.

Attention au périmètre : la soumission de l’intégrateur ne couvre qu’une partie de la facture. Nous avons détaillé les coûts réels d’un projet ERP au Québec, incluant le temps interne, la migration des données et la stabilisation, postes qu’aucune estimation de fournisseur n’inclut spontanément.

Combien de temps faut-il investir dans l’estimation des coûts ?

Assez pour découper, chiffrer avec les experts, appliquer une contingence par composante et valider par comparaison, ce qui représente typiquement de deux à quatre semaines pour un projet de taille intermédiaire, selon les observations de PlanAxion. C’est peu à côté de 45 % de dépassement.

Préparer une bonne estimation est relativement facile. La sous-estimer est extrêmement coûteux. L’arbitrage est donc simple : investissez le temps maintenant, ou payez-le plus tard, avec la crédibilité du projet en prime.

Questions fréquentes

Quelle contingence appliquer à une estimation de coûts de projet ?

Appliquez une contingence distincte à chaque composante selon son risque propre, plutôt qu’un pourcentage global. Dans la pratique de PlanAxion, une composante bien connue de l’organisation reçoit de 10 à 15 %, une composante jamais réalisée de 25 à 40 %. Le total pondéré reflète alors le profil de risque réel du projet, pas une moyenne rassurante.

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

Selon McKinsey et l’Université d’Oxford, les grands projets TI dépassent leur budget de 45 % en moyenne, et chaque année additionnelle de durée ajoute 15 % de dépassement. Panorama Consulting identifie le besoin imprévu de technologies additionnelles comme cause principale en 2026. Dans les deux cas, la racine est la même : des composantes découvertes après l’estimation.

Qui devrait participer à l’estimation des coûts d’un projet ?

Les experts de chaque composante de la solution, idéalement les futurs membres de l’équipe de projet, avec le promoteur qui approuvera le budget. Une équipe qui a chiffré elle-même les livrables respecte l’estimation et doute moins de son réalisme. Le gestionnaire de projet coordonne l’exercice, mais il ne devrait jamais le faire seul dans son bureau.

Comment valider une estimation de coûts sans deuxième équipe ?

Comparez-la aux coûts réels de projets antérieurs comparables, dans votre organisation ou dans des rapports publics comme celui de Panorama Consulting, qui situe le coût médian d’un projet ERP à 450 000 $ US en 2025. Conservez systématiquement l’historique de vos projets : c’est la base de données de référence la moins chère et la plus fiable qui existe.