Budget projet digital : comment le construire, provisionner les aléas et le suivre en comité

Le budget d'un projet digital se vote une fois et se discute tout le reste de l'année. Entre le chiffrage initial et la facture finale, l'écart tient rarement à une erreur de calcul : il tient à ce que le budget n'a jamais décrit la même chose que le projet. Licences, prestataires, temps des équipes métiers, adoption, exploitation : chacune de ces lignes se trompe à sa manière. Ce guide propose une méthode en six étapes pour construire un budget projet digital solide, loger les aléas dans une provision que le comité maîtrise, puis suivre la dépense sans attendre le dépassement. Une trame prête à l'emploi clôt le propos.

En résumé

Les projets informatiques dépassent leur budget plus souvent qu'on ne le dit, et de façon asymétrique : McKinsey et l'université d'Oxford relèvent, sur plus de 5 400 grands projets (budget initial supérieur à 15 millions de dollars), 45 % de dépassement en moyenne. La cause dominante est comportementale (optimisme, périmètre flou) plus que technique. La parade tient en six gestes : cadrer le périmètre avant de chiffrer, chiffrer par blocs en incluant l'interne, l'adoption et trois ans d'exploitation, annoncer la fiabilité de l'estimation, isoler une provision d'aléas pilotée par le comité, débloquer le budget par tranches, suivre le reste à faire plutôt que le consommé. Les ordres de grandeur de provision donnés ici sont des conventions de pratique, pas des résultats d'étude.

Pourquoi le budget d'un projet digital dérive-t-il presque toujours ?

Commençons par les ordres de grandeur, en précisant leur périmètre. L'étude McKinsey et université d'Oxford (2012) porte sur plus de 5 400 projets informatiques de grande taille, dont le budget initial dépassait 15 millions de dollars : le budget a été dépassé de 45 % en moyenne, le calendrier de 7 %, et la valeur livrée s'est située 56 % sous les prévisions. Les auteurs notent aussi qu'environ un projet sur six tourne si mal qu'il menace l'existence même de l'entreprise (dépassements supérieurs à 200 %). Une enquête antérieure de Bent Flyvbjerg et Alexander Budzier, publiée dans la Harvard Business Review en 2011 sur 1 471 projets, aboutissait à un dépassement moyen de 27 %, avec un projet sur six affichant +200 % de coûts et près de 70 % de retard.

Cette forme est le vrai enseignement. Les dépassements ne se répartissent pas autour d'une moyenne comme des erreurs aléatoires : la distribution est asymétrique, avec une queue épaisse de cas extrêmes. Flyvbjerg et ses coauteurs (2018) l'écrivent sans détour : le dépassement de coûts est systématiquement à queue épaisse, et ses causes sont d'abord comportementales (optimisme, déclarations stratégiquement favorables au moment de défendre un projet) plutôt que techniques. Traduction pour un décideur : une provision « de 10 % pour l'imprévu », calibrée sur la moyenne, protège contre le petit écart et reste muette face au gros.

Le secteur public, qui publie ses chiffres, offre un contrepoint utile. Le panorama de la direction interministérielle du numérique (DINUM), dans sa 18e édition de décembre 2023, suivait 48 grands projets numériques de l'État pour 3,6 milliards d'euros d'engagement. La dérive budgétaire moyenne y était de 10,8 %, contre 24 % un an plus tôt et 32 % en 2016, selon la synthèse du Monde Informatique (22 mai 2024). Le progrès est réel. Il s'accompagne pourtant d'une hausse de 60 % des budgets cumulés entre 2016 et fin 2023 : un indicateur de dérive peut s'améliorer pendant que la facture s'alourdit.

Que doit contenir le budget d'un projet digital ?

La plupart des budgets se limitent à ce qui fait l'objet d'un devis ou d'une commande. Or un projet digital consomme au moins cinq familles de coûts, dont trois n'apparaissent jamais dans une proposition commerciale.

• Les coûts de réalisation (build). Prestations de conception et de développement, intégration, licences et abonnements de la première année, infrastructure. C'est la ligne que l'on sait chiffrer, donc celle qui occupe tout l'espace dans la discussion.
• Les coûts internes. Temps des équipes métiers, de la DSI, du juridique, des achats et de la direction de projet. Rarement facturé, souvent le premier goulot d'étranglement, et presque toujours absent du budget présenté en comité.
• Les coûts d'adoption. Formation, conduite du changement, accompagnement, support de lancement. Un outil livré et non utilisé coûte autant qu'un outil adopté.
• Les coûts d'exploitation (run) sur trois ans. Licences récurrentes, maintenance, hébergement, évolutions mineures, monitoring. Sur de nombreux projets, le run cumulé finit par dépasser le build.
• Les provisions. Une réserve pour aléas (risques identifiés) et une réserve de gestion (arbitrages de périmètre). Nous y reviendrons à l'étape 4.

Le tout se lit sur un horizon de trois ans, pas sur l'exercice budgétaire. C'est précisément ce que les arbitrages annuels masquent, et ce que le budget DSI 2027 ou le budget IA 2027 cherchent à rendre visible à l'échelle de l'ensemble du portefeuille.

Comment construire le budget d'un projet digital en six étapes ?

Étape 1 : Quel périmètre et quelle décision le budget doit-il servir ?

Le budget est la traduction chiffrée d'un périmètre. Avant la première ligne, rédigez en une page ce que le projet livre, ce qu'il ne livre pas, qui le sponsorise et quelle décision le comité devra prendre sur la base du budget : engager, engager par tranches, ou renoncer. Un projet dont le périmètre tient en une demi-page se chiffre mieux qu'un projet « d'envergure » décrit en trois phrases enthousiastes.

Étape 2 : Comment chiffrer par blocs sans oublier les coûts invisibles ?

Découpez le périmètre en blocs fonctionnels (par exemple : socle technique, parcours client, intégrations, reprise de données, formation) et chiffrez chaque bloc selon les cinq familles de coûts. Exigez des prestataires un chiffrage par bloc plutôt qu'un forfait global : l'arbitrage ultérieur du comité (reporter un bloc, en retirer un autre) devient possible, ce qu'un total indivisible interdit.

Pour les coûts internes, demandez à chaque responsable métier un nombre de jours par phase, validé par son manager. Ce n'est pas de la comptabilité analytique : c'est une manière de rendre visible que le projet consomme de la capacité d'équipes déjà saturées. Si cette capacité n'existe pas, le planning est faux avant d'avoir commencé.

Étape 3 : Quelle méthode d'estimation, et avec quel niveau de confiance ?

Un chiffre unique donne une impression de précision que l'état d'avancement ne justifie jamais au démarrage. Présentez systématiquement une fourchette, et dites à quel stade du projet elle se resserre. Trois méthodes se combinent utilement : l'estimation par blocs avec les équipes de réalisation, l'analogie avec un projet comparable mené dans votre entreprise, et la comparaison avec une classe de référence externe.

Cette dernière méthode, popularisée par Flyvbjerg sous le nom de reference class forecasting, consiste à regarder comment se sont terminés les projets du même type plutôt qu'à extrapoler le plan du projet courant. Même sans base de données externe, un registre interne des cinq ou six derniers projets de votre direction (budget annoncé, budget final, cause principale d'écart) vaut mieux que l'intuition de l'équipe porteuse.

Étape 4 : Comment provisionner les aléas sans les cacher dans les lignes ?

Deux réserves, deux propriétaires, deux règles d'usage.

La provision pour aléas couvre les risques identifiés et chiffrés : un prestataire clé qui se retire, une intégration plus complexe que prévu, une reprise de données de mauvaise qualité. Elle est constituée à partir d'un registre de risques, pas d'un pourcentage plaqué. La réserve de gestion couvre les arbitrages de périmètre que le comité décidera d'engager en cours de route. Dans les deux cas, la règle est la même : le chef de projet ne l'utilise pas seul, le comité l'autorise et en est informé à chaque réunion.

Quant au niveau, aucun consensus d'étude ne permet d'annoncer un pourcentage universel. À titre de convention de pratique, que vous devrez ajuster à votre contexte, on retient plus volontiers une provision de l'ordre de 10 à 15 % lorsque le périmètre est stabilisé et les technologies maîtrisées, et de 20 à 30 % lorsque le périmètre est incertain ou que la technologie est nouvelle pour l'entreprise. Ce sont des hypothèses de travail, pas des constats, et la forme de la dérive décrite plus haut rappelle qu'aucune provision ne couvre à elle seule un scénario extrême : c'est le découpage en tranches qui le fait.

Un mot sur les projets d'IA, où l'estimation est plus fragile qu'ailleurs : Mary Mesaglio, analyste chez Gartner, a affirmé en 2024 lors du Gartner Symposium en Australie que des erreurs d'estimation de 500 à 1 000 % étaient possibles sur les coûts de l'IA générative (propos rapportés par The Register).

Étape 5 : Pourquoi débloquer le budget par tranches ?

Le meilleur outil contre la dérive extrême reste le découpage. McKinsey et Oxford recommandent des jalons de décision rigoureux, des cycles de livraison courts et des contrôles de qualité intégrés. En pratique : le comité engage une première tranche (cadrage, prototype, premier lot livrable), puis débloque la suivante à la vue de résultats vérifiables, pas de présentations. Ce déblocage par tranches prend tout son sens dans une revue trimestrielle du portefeuille de projets, qui permet de réallouer la capacité d'un projet à l'autre.

Chaque tranche a trois attributs écrits : un montant, un livrable observable, un critère d'arrêt. Le critère d'arrêt est le plus important et le moins souvent rédigé. Sans lui, un projet qui dérive n'a pas de point de sortie : il continue parce que les sommes déjà engagées rendent l'arrêt coûteux à défendre. La question de savoir quand renoncer est traitée plus en détail dans notre analyse sur l'arbitrage du portefeuille de projets digitaux et l'arrêt des projets.

Étape 6 : Quels indicateurs suivre en comité, et lesquels ignorer ?

Un tableau de bord budgétaire utile tient en cinq indicateurs, présentés à chaque comité :

• Budget engagé : ce qui est contractuellement commandé.
• Budget consommé : ce qui est facturé ou imputé.
• Reste à faire estimé : la prévision, mise à jour par l'équipe projet, de ce qu'il reste à dépenser pour livrer le périmètre. C'est l'indicateur central.
• Consommation des provisions : ce qui a été prélevé, pour quel motif, avec quelle autorisation.
• Valeur livrée : les livrables observables, rapportés au budget consommé.

Le consommé seul est le plus trompeur de ces indicateurs : un projet à 50 % de budget consommé peut être à 30 % de réalisation, ou à 70 %. Ce qui compte pour la décision, c'est la prévision à terminaison (consommé plus reste à faire) comparée au budget autorisé. Quand l'écart dépasse un seuil convenu à l'avance (nous suggérons 10 % pour une tranche), le comité se réunit en séance dédiée pour décider : poursuivre, redimensionner ou arrêter. Notre analyse sur le comité de pilotage et l'arbitrage détaille la tenue d'une telle séance.

Quelles erreurs fréquentes éviter dans le budget d'un projet digital ?

Les mêmes causes reviennent d'un projet à l'autre, et aucune n'exige d'outil sophistiqué pour être évitée.

Laisser les coûts internes hors du budget. Ils n'ont pas de facture, donc pas de ligne. Leur absence rend le calendrier irréaliste, car il suppose une disponibilité que personne n'a confirmée.

Dissimuler la provision dans chaque ligne. Quand chaque fournisseur ajoute sa marge de sécurité, le total est gonflé, et personne ne sait ce qui reste. Une provision unique, visible et pilotée par le comité vaut mieux que dix réserves invisibles.

Oublier le run. Le projet livré, la dépense continue : licences, hébergement, support, évolutions. Un budget qui s'arrête à la mise en production sous-estime le coût total du projet sur trois ans.

Multiplier les prestataires sans coordination budgétaire. Chaque agence ou intégrateur gère son enveloppe ; personne ne pilote l'ensemble. L'article sur la coordination des prestataires digitaux montre comment organiser ce pilotage, et le rôle d'une AMOA digitale peut y contribuer.

Quelle trame de budget projet digital utiliser ?

Voici une trame que vous pouvez recopier dans un tableur ou un document de cadrage. Elle est volontairement courte : un budget qu'on ne relit pas ne protège de rien.

Le bloc d'identification

Intitulé du projet, sponsor, propriétaire du budget, décision attendue du comité, date de la prochaine revue.

Le bloc de chiffrage

Pour chaque bloc fonctionnel, cinq lignes : réalisation, coûts internes en jours, adoption, exploitation sur trois ans, et risques associés. En bas : total, fourchette basse et fourchette haute, niveau de confiance (faible, moyen, élevé) et date à laquelle la fourchette se resserrera.

Le bloc des provisions

Montant de la provision pour aléas, lié à un registre de risques ; montant de la réserve de gestion ; règle d'autorisation (qui décide, à partir de quel montant, qui est informé).

Le bloc des tranches

Pour chaque tranche : montant, livrable observable, critère d'arrêt, date de décision de la tranche suivante.

Le bloc de suivi

Les cinq indicateurs de l'étape 6, avec leur seuil d'alerte, et la date de chaque comité budgétaire.

Pour fixer les idées, voici un exemple illustratif, construit pour montrer la mécanique et non issu d'un cas réel : une ETI refond son portail clients avec un budget de réalisation de 400 000 euros. Elle ajoute 120 jours de temps interne, un budget d'adoption de 40 000 euros et un run de 60 000 euros par an, soit 180 000 euros sur trois ans. Le périmètre étant encore partiellement incertain, elle constitue une provision d'aléas de 25 % sur la réalisation, soit 100 000 euros, autorisée par le comité. Le budget présenté ne s'intitule pas « 400 000 euros » mais « entre 620 000 et 720 000 euros sur trois ans hors temps interne, engagé en trois tranches ». La décision du comité change de nature : elle porte sur une trajectoire, non sur un chiffre.

Un budget de projet digital n'est pas un devis agrégé : c'est un engagement de gouvernance. Celui qui le signe accepte une fourchette, une provision qu'il ne maîtrise pas seul, des tranches qui peuvent s'arrêter. Cet engagement a un coût politique à court terme, puisqu'il rend le projet plus difficile à vendre qu'un chiffre unique et rond. Il en a un autre, bien plus lourd, quand il manque : le dépassement se découvre à l'automne suivant, quand les marges de manœuvre sont épuisées. La question à poser avant le prochain comité n'est donc pas « combien coûte ce projet », mais « à quel moment, et sur quelle information, accepterons-nous de l'arrêter ».

Le regard de digitalie_

Chez digitalie_, nous considérons qu'un budget de projet se juge à sa capacité à produire une décision, pas à son montant. Nos accompagnements de pilotage de programmes digitaux commencent presque toujours par la même séance : réécrire le périmètre, séparer provisions et lignes de réalisation, fixer les critères d'arrêt avant le premier jour de développement. Si vous préparez les arbitrages de 2027 et souhaitez confronter votre trame budgétaire à un regard extérieur, nous proposons un échange de 30 minutes. Notre approche du pilotage est détaillée sur la page transformation digitale.

Questions fréquentes

Comment établir le budget d'un projet digital ?

Cadrez d'abord le périmètre, puis chiffrez par blocs fonctionnels en cinq familles de coûts : réalisation, temps interne, adoption, exploitation sur trois ans et provisions. Présentez une fourchette plutôt qu'un chiffre unique, découpez l'engagement en tranches avec critère d'arrêt, et suivez le reste à faire à chaque comité.

Quelle provision prévoir pour les aléas d'un projet digital ?

Aucune étude n'impose un pourcentage universel. En pratique, on retient souvent 10 à 15 % quand le périmètre est stable, 20 à 30 % quand il est incertain. Fondez surtout la provision sur un registre de risques chiffrés, et faites-la autoriser par le comité plutôt que par le chef de projet.

Pourquoi les projets informatiques dépassent-ils leur budget ?

Selon Flyvbjerg et ses coauteurs, les causes dominantes sont comportementales : optimisme, périmètre mal défini, déclarations trop favorables au moment de défendre le projet. McKinsey et Oxford relèvent 45 % de dépassement moyen sur de grands projets. Les dépassements sont asymétriques : quelques cas extrêmes pèsent lourd.

Quels coûts oublie-t-on le plus souvent dans un budget de projet digital ?

Trois familles échappent souvent au budget présenté : le temps des équipes internes, qui n'est pas facturé, les coûts d'adoption (formation, accompagnement) et l'exploitation sur trois ans (licences, hébergement, maintenance, évolutions). Les inclure change le montant et la décision du comité.

Quels indicateurs suivre pour piloter le budget en comité ?

Cinq indicateurs suffisent : budget engagé, budget consommé, reste à faire estimé, consommation des provisions et valeur livrée. Le plus utile est la prévision à terminaison, c'est-à-dire le consommé plus le reste à faire, comparée au budget autorisé. Le consommé seul rassure à tort.

Sources

1. Bloch M., Blumberg S., Laartz J., « Delivering large-scale IT projects on time, on budget, and on value », McKinsey & Company (avec l'université d'Oxford), 1er octobre 2012. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

2. Flyvbjerg B., Budzier A., « Why Your IT Project May Be Riskier Than You Think », Harvard Business Review, septembre 2011 (1 471 projets ; synthèse consultée via Information Age). https://www.information-age.com/private-sector-it-projects-just-as-bad-as-in-public-sector-26565/

3. Flyvbjerg B. et al., « Five Things You Should Know about Cost Overrun », Transportation Research Part A, 2018. https://ses.library.usyd.edu.au/handle/2123/28479

4. DINUM, Panorama des grands projets numériques de l'État, 18e édition, décembre 2023, d'après Le Monde Informatique, 22 mai 2024. https://www.lemondeinformatique.fr/actualites/lire-la-facture-des-grands-projets-it-de-l-etat-s-envole-93785.html

5. The Register, « Gartner Symposium : AI cost estimates », 9 septembre 2024 (propos de Mary Mesaglio, Gartner). https://www.theregister.com/2024/09/09/gartner_synmposium_ai_opinion/