Suivi budget projet : repérer ladérive avant la dernière facture

Le scénario est presque toujours le même. Les devis sont signés, le projet démarre, les factures arrivent une par une et chacune semble raisonnable. Puis vient la dernière, et le total dépasse ce que l'entreprise avait en tête. Personne n'a menti. Simplement, personne ne regardait le bon chiffre au bon moment.

Le suivi budget projet fait partie de mon travail de direction de projet digital, à côté du planning et des décisions. J'ai appris à tenir un budget, un planning et une équipe face à une date qui ne bouge pas lors de mes débuts en production audiovisuelle, et j'en ai gardé quelques habitudes. Voici comment je passe des devis à un budget de référence, ce que je suis chaque mois, comment je repère une dérive et ce que j'en fais.

01Pourquoi le budget d'un projet digital dérive sans prévenir

Les projets informatiques ont une particularité que la moyenne cache. Bent Flyvbjerg et Alexander Budzier ont étudié 1 471 projets informatiques dans un article paru dans la Harvard Business Review : le dépassement de coût moyen était de 27 %, mais un projet sur six dépassait en moyenne de 200 %, avec près de 70 % de retard. Le danger n'est donc pas le petit dépassement que tout le monde attend. C'est le projet qui part très loin, et qu'on ne voit pas partir.

La seconde cause est plus banale : on estime trop bas. Le Trésor britannique le dit sans détour dans sa note sur le biais d'optimisme. Ceux qui chiffrent un projet ont tendance à être trop optimistes, et il faut corriger les estimations de coût et de durée à partir de projets passés ou similaires.

Sur un projet digital, j'ajoute trois raisons que je vois souvent. Le périmètre grossit par petites touches, chacune trop petite pour mériter un avenant. Le travail interne (relectures, contenus, recette) n'est dans aucun devis. Et l'avancement se déclare au jugé : une tâche reste « presque finie » pendant des semaines.

02Du devis au budget de référence

Le total des devis signés n'est pas un budget. C'est la partie visible. Avant le premier euro dépensé, j'écris un budget de référence, daté, qui servira de mètre étalon jusqu'à la fin.

Ce que j'ajoute aux devis

1. Le temps interne : qui, dans l'entreprise, va relire, valider, produire des contenus, tester, et combien de jours cela représente.
2. Les coûts récurrents qui démarrent pendant le projet : licences, hébergement, outils.
3. La recette et les corrections qui suivent la mise en ligne, rarement chiffrées au bon niveau.
4. Une réserve, séparée des lignes, avec une règle écrite : qui peut y puiser, pour quel type de dépense, et à partir de quand on prévient le sponsor.

Pour fixer la réserve, je préfère regarder dehors que dedans. Dans un entretien avec Rita McGrath, Bent Flyvbjerg décrit la prévision par classe de référence : au lieu d'additionner les coûts de l'intérieur, on regarde ce qu'ont réellement coûté des projets du même type, et on part du principe que le sien fera pareil. Si vous avez des projets passés dans l'entreprise, leurs dépassements valent mieux que n'importe quelle intuition.

Je découpe ce budget par livrable, pas par fournisseur. « Catalogue produit en ligne » se suit mieux que « agence A ». Et je le versionne. Sur une intégration entre un ERP et un site marchand, la spécification bougeait presque à chaque réunion, et je l'ai fait évoluer version après version pour que tout le monde parle du même document. Un budget de référence se traite de la même façon : quand il change, il prend un nouveau numéro, et l'ancien reste lisible. Ce travail se fait au moment du cadrage du projet, pas après.

03Suivre trois chiffres chaque mois, pas un total de dépenses

Le réflexe courant consiste à comparer ce qu'on a dépensé à ce qu'on avait prévu de dépenser. Ce chiffre seul ne dit rien : avoir dépensé la moitié du budget à mi-parcours est une bonne nouvelle si la moitié du travail est faite, une mauvaise si un quart seulement l'est.

La méthode de la valeur acquise règle ce problème. Le Project Management Institute en a publié un guide de lecture avec un exemple simple : un projet de 100 000 dollars, au quatrième mois. Le travail prévu à cette date valait 40 000, le travail réellement fini en vaut 36 000, et 45 000 ont été dépensés. On obtient 80 cents de travail pour chaque dollar dépensé, et si rien ne change, le projet finira autour de 125 000. Le dépassement se voit au quatrième mois au lieu du dixième.

Pas besoin d'un logiciel pour l'appliquer. Le même guide rappelle que la méthode marche sur un petit projet, et en agile, à condition de ne compter un élément comme fini que lorsqu'il est réellement terminé et accepté.

Le tableau que je tiens

Une ligne par livrable, et ces colonnes :

• le budget de la ligne, tiré de la référence ;
• ce qui devait être fini à cette date, en part du budget de la ligne ;
• ce qui est fini et accepté, avec la même unité ;
• ce qui a été dépensé ou engagé ;
• un statut vert, orange ou rouge ;
• pour tout orange ou rouge, une phrase de cause et la décision demandée.

Une règle vient de mes machines de contenu. Dans la machine qui écrit ce blog, une vérification qui n'a pas eu lieu donne un rouge, jamais un vert par défaut. Au budget, c'est pareil : une ligne dont les factures ou l'avancement ne sont pas à jour n'est pas « dans les clous », elle est inconnue, et je l'affiche comme telle.

04Repérer une dérive avant la dernière facture

Le guide du PMI sur la valeur acquise donne deux conseils que j'applique. D'abord, lire la tendance plutôt qu'un point : un mois en dessous de la courbe peut être du bruit, trois mois de suite forment une tendance. Ensuite, se méfier de l'avancement subjectif. Une tâche annoncée à 90 % trois semaines d'affilée n'est pas à 90 %.

Les signaux que je surveille sur un projet digital :

• une ligne qui consomme plus vite qu'elle ne livre, même légèrement ;
• des petites demandes acceptées en réunion sans être chiffrées ;
• un fournisseur qui attend une validation interne, pendant que son équipe reste mobilisée ;
• un retard sur le planning, qui finit presque toujours par coûter quelque chose.

Le dernier point est la raison pour laquelle je suis le budget avec le planning construit sur les dépendances, et non à côté. Quand plusieurs fournisseurs travaillent en parallèle, l'attente de l'un devient la facture de l'autre, un sujet que je détaille dans l'article sur la coordination de plusieurs prestataires.

Reste la question humaine. Dans le même entretien, Bent Flyvbjerg insiste sur un point : le dirigeant doit remercier la personne qui vient dire que le projet dérape, sinon les problèmes restent cachés des mois. Je pose la même règle dans mes propres outils : un orange ne passe qu'avec une explication écrite. Un statut orange qui arrive tôt, avec sa cause, se traite. Le même écart découvert à la fin devient une dispute.

05Traiter un écart : une décision, un nom, une date

Un écart ne sert à rien s'il reste un chiffre dans un tableau. Le PMI recommande de finir chaque revue par une décision et un responsable, et propose quatre options que je reprends telles quelles : surveiller, corriger, faire remonter, replanifier.

Ma façon de préparer une décision

1. Vérifier que l'écart est réel : une facture arrivée en retard ou un avancement mal saisi créent de faux écarts.
2. Nommer la cause en une phrase : « trois écrans ajoutés au tunnel de commande sans avenant », pas « dérive sur le lot 2 ».
3. Proposer deux ou trois options chiffrées : retirer une fonctionnalité de la première version, puiser dans la réserve, décaler un lot, augmenter le budget.
4. Dire laquelle je recommande, et pourquoi.
5. Écrire la décision prise, avec qui la porte et pour quand.

Ces décisions remontent au sponsor ou au comité de pilotage quand elles dépassent ce que l'équipe projet peut engager. Une leçon de mission me sert ici : un rapport mensuel qui part seul et un comité qui décide valent mieux qu'un tableau de bord qu'on ne lit pas. Le tableau part donc quelques jours avant la réunion, et la séance sert à trancher, pas à découvrir.

Ce que ce suivi ne fait pas

Il ne rattrape pas un budget de départ irréaliste. Si la référence est fausse, on mesure des écarts par rapport à une fiction. Il a aussi un coût : tenir l'avancement réel ligne par ligne demande une heure ou deux par mois, et des fournisseurs qui acceptent de partager leur consommation. Sur un projet de quelques semaines avec un seul prestataire, je me contente souvent d'un point à mi-parcours et d'une règle simple sur les demandes nouvelles. Je suis formé Scrum Master et Product Owner, et sur un projet en sprints, je lis plutôt le budget comme un nombre de sprints restants face au périmètre restant.

06Par où commencer pour votre prochain projet

Si vous avez un projet en cours, commencez par une seule chose : reprenez vos devis et écrivez ce qu'ils ne couvrent pas. Le temps interne, les licences, la recette, la réserve. Vous aurez votre premier budget de référence, et probablement une surprise.

Ensuite, choisissez le jour du mois où le tableau part, et la personne qui le reçoit. Trois chiffres par ligne, une phrase par écart, une décision demandée. Le reste vient avec la pratique.

C'est une partie de ce que je fais en direction de projet digital, souvent dès le cadrage. Si votre budget vous inquiète, on peut en parler.