Le problème : un chiffre sans son contexte
Sur un projet long, la question revient sans cesse : qu’avions-nous promis, et sur quelles hypothèses ? L’offre est passée par cinq versions avant la signature. Le taux horaire d’une catégorie a été corrigé deux ans plus tard. L’organisation a changé et certains postes ont disparu. Dans un tableur ou un outil qui ne garde que l’état courant, chacune de ces évolutions réécrit le passé : l’offre d’origine ne peut plus être reconstituée, et un écart constaté aujourd’hui ne se distingue plus d’une correction de référentiel.
Une révision est un instantané complet
Dans Waterfall, tout ce qui se saisit sur un projet se saisit dans une révision. Elle contient :
- ses structures de coûts : la structure principale (planning et devis), et le cas échéant les différentiels d’avenants et le devis propre de chaque risque ;
- les valeurs du référentiel qu’elles emploient : rôles de ressources, calendriers, catégories de coût et taux horaires ;
- les paramètres qui l’ont calculée ou qualifiée : son année de référence, le taux d’inflation et la probabilité de gain du projet.
Une révision porte en outre un nom de version et une description, où le chef de projet consigne ses hypothèses. Une réorganisation ou une correction de taux, des années plus tard, ne la déplace pas : elle conserve les taux qui ont servi à la calculer.
En cours d’élaboration, puis marquée
Une révision connaît deux états. En cours d’élaboration, elle est l’endroit où tout se passe : la saisie, les imports, la réestimation. Un projet n’en a jamais qu’une à la fois. Marquée, elle est figée et ne se modifie plus par aucun moyen, ni saisie, ni import, ni traitement automatique. Le travail continue alors dans la révision suivante, qui reprend les structures de la dernière révision marquée.
Comme une étiquette dans un gestionnaire de versions, une révision marquée ne bouge plus.
Une révision en cours peut être abandonnée tant qu’elle n’est pas marquée : le projet revient alors à son état à la dernière révision marquée.
Pendant l’offre : l’historique des négociations
Pendant le chiffrage, chaque version remise au client est une révision marquée. Le périmètre retiré à la demande de l’acheteur, l’hypothèse de sous-traitance abandonnée, le risque ajouté après la visite du site : tout reste consultable, version par version. Deux révisions marquées se comparent : tâches ajoutées, retirées ou modifiées (dates, durée, état), et écarts de montants par nature de coût et par sous-projet.
À chaque nouvelle révision, Waterfall retient l’année courante comme année de référence. Quand elle change, il présente catégorie par catégorie le taux conservé et le taux du référentiel pour la nouvelle année, et le chef de projet accepte ou refuse chaque mise à jour. Une offre ne change donc jamais de taux à l’insu de son auteur.
La contractualisation : désigner la révision de référence
À la signature, le chef de projet désigne parmi les révisions marquées celle qui fait foi : la révision de référence. Elle fixe le budget de référence, la réserve pour risques, les dates contractuelles et la valeur planifiée. Cette désignation se corrige tant qu’elle n’a eu aucune conséquence, c’est-à-dire tant qu’aucun coût réel n’a été importé et qu’aucune révision n’a été marquée depuis. Au-delà, la référence ne se déplace plus qu’à la contractualisation d’un avenant.
Pendant l’exécution : une révision par revue
Chaque revue périodique produit une révision : le chef de projet met à jour le planning et le reste à engager, réexamine les risques, importe les coûts réels, puis marque la révision. Les indicateurs de cette révision sont calculés à sa date de marquage et conservés. C’est cette suite d’instantanés qui permet de tracer l’évolution des indices revue après revue, ou le diagramme temps/temps, qui montre comment la date prévue de chaque jalon a glissé d’une revue à l’autre.
Tâches et lignes gardent leur identité d’une révision à l’autre, la lignée. C’est elle qui permet de comparer deux révisions, de suivre une tâche dans le temps, et de réimporter un fichier Excel ou MS Project sans créer de doublons.
Un cycle de vie déduit des faits
Un projet traverse six états : Créé, Chiffrage, En cours, puis l’un des trois états terminaux, Terminé, Perdu ou Abandonné. Les deux premières transitions ne se commandent jamais à la main, elles se déduisent de faits. Le projet passe en Chiffrage dès sa première révision, et En cours dès qu’il porte à la fois une révision de référence et le code projet de l’ERP. Un statut que l’on fait avancer à la main finit par décrire l’intention de celui qui a cliqué ; déduit d’un fait, il reste vrai sans que personne ait à y veiller.
Les seules décisions humaines sont les sorties. Elles sont confirmées, datées, éventuellement motivées, et irréversibles : un projet clos devient une archive en lecture seule, entièrement consultable. Sa valeur est justement d’être relu, pour chiffrer le suivant ou pour justifier le précédent.