Un projet prend du retard. La date de mise en service, elle, n’a pas l’intention de bouger.
La solution paraît alors évidente : ajouter des ressources, faire appel à un prestataire, autoriser des heures supplémentaires, mobiliser une équipe supplémentaire… Bref, mettre les moyens pour aller plus vite. Le crash program en gestion de projet désigne, dans le langage courant de certaines entreprises, ce dispositif d’accélération. Dans les référentiels de management de projet, on parlera plus précisément de crashing.
L’expression est spectaculaire. Elle pourrait laisser penser que le projet vient de rencontrer un mur. C’est presque l’inverse : il s’agit justement d’essayer de l’atteindre plus vite.
Derrière le terme se cache surtout une vraie question de pilotage : combien sommes-nous prêts à dépenser pour gagner du temps ?
Le crash program existait avant la gestion de projet moderne
L’expression anglaise crash program désigne un programme engagé rapidement et de manière intensive pour répondre à une urgence ou respecter une échéance. Mais c’est avec le développement de la méthode du chemin critique, à la fin des années 1950, que cette logique va prendre une signification beaucoup plus précise en gestion de projet.
À la fin des années 1950, DuPont et Remington Rand développent ce qui deviendra la Critical Path Method (CPM), méthode du chemin critique. Et, dès les travaux de 1957, la relation entre durée et coût est au centre du modèle.
Pour chaque activité, les concepteurs distinguent notamment une durée « normale » et une durée minimale accélérée, appelée crash duration. Réduire la durée nécessite généralement davantage de ressources et augmente donc le coût direct de l’activité.
Le problème posé il y a près de 70 ans ressemble donc beaucoup à celui d’un chef de projet aujourd’hui : comment raccourcir le projet avec le plus faible surcoût possible ?
Crash program ou crashing ?
Dans le vocabulaire courant, crash program désigne plutôt le dispositif exceptionnel mis en place pour accélérer un projet.
Dans le vocabulaire du PMI, le terme technique est crashing. Le lexique du PMI publié en 2026 le définit comme une technique de compression du planning destinée à raccourcir sa durée au plus faible coût additionnel, notamment par l’ajout de ressources.
PRINCE2 et l’IPMA ne formalisent pas cette technique sous ce nom. Dans PRINCE2, la même logique se traduit par l’Exception Plan : lorsqu’un projet menace de dépasser ses tolérances de délai ou de coût, le chef de projet formalise un scénario de récupération soumis à décision du comité de pilotage. Dans l’Individual Competence Baseline de l’IPMA, l’arbitrage délai-coût relève de la compétence de pilotage sans faire l’objet d’une technique nommée.
Autrement dit, faire du crashing ne consiste pas simplement à demander à tout le monde de courir plus vite.
La convergence est réelle entre les trois référentiels. Le vocabulaire, lui, varie.
Encore faut-il courir au bon endroit.
Tout commence par le chemin critique
Imaginons un projet qui doit se terminer dans 12 semaines mais dont la nouvelle prévision indique désormais 14 semaines. Il faut gagner 2 semaines.
Le premier réflexe pourrait consister à rechercher toutes les tâches susceptibles d’être accélérées.
Mauvaise idée ! Si une activité dispose de 3 semaines de marge et qu’on réduit sa durée d’une semaine, le projet terminera exactement à la même date. Nous aurons simplement réussi à dépenser davantage sans gagner une seule journée.
Le crashing porte donc prioritairement sur les activités du chemin critique, puisque ce sont elles qui déterminent la durée du projet. Et après chaque compression significative, le chemin critique doit être recalculé : un autre chemin peut devenir critique à son tour.
Le chemin critique a cette mauvaise habitude : lorsqu’on commence à s’occuper sérieusement de lui, il peut déménager.
Combien coûte une journée gagnée ?
Prenons une activité critique prévue sur 10 jours pour un coût de 30.000 €.
En mobilisant une équipe supplémentaire, elle pourrait être réalisée en 6 jours pour 42.000 €. Le projet gagne donc 4 jours pour un surcoût de 12.000 €.
Le coût marginal de compression est alors : 12.000 € / 4 jours = 3.000 € par jour gagné.
Supposons qu’une autre activité critique puisse gagner 2 jours pour seulement 4.000 €, soit 2.000 € par jour.
À conditions comparables, il est rationnel de commencer par la seconde.
C’était déjà la logique du modèle historique du CPM : rechercher les activités permettant de réduire le délai avec la pente de coût la plus faible, puis recalculer le projet au fur et à mesure.
Le crash program augmente-t-il forcément le budget ?
Le coût direct des activités accélérées augmente généralement. On peut mobiliser davantage de collaborateurs, acheter une prestation supplémentaire, payer des heures supplémentaires, accélérer une livraison ou faire intervenir une expertise externe. Vu uniquement depuis le budget du projet, le crash program ressemble donc assez fortement à une mauvaise nouvelle.
Mais l’analyse ne doit pas s’arrêter là.
Un surcoût direct peut permettre d’économiser ailleurs
Raccourcir la durée du projet peut réduire certains coûts liés au temps : prestations prolongées, location de moyens, structures temporaires, assistance externe ou autres coûts dépendant réellement de la durée.
Les travaux historiques sur le crashing recherchaient d’ailleurs déjà cet arbitrage entre augmentation des coûts directs et diminution des coûts indirects liés à la durée du projet.
Attention cependant : un coût interne de structure ne disparaît pas nécessairement parce qu’un projet se termine 15 jours plus tôt. Une économie calculée dans un modèle n’est pas automatiquement une économie comptable sonnante et trébuchante.
Et surtout, une journée gagnée peut avoir de la valeur
Imaginons maintenant qu’un projet nécessite 80.000 € supplémentaires pour avancer la date de mise en service de 3 semaines.
Budgétairement, le constat est simple : le coût du projet augmente de 80.000 €.
Mais si ces 3 semaines permettent d’éviter 150.000 € de pénalités ou de dégager 250.000 € de marge supplémentaire grâce à une commercialisation plus rapide, la lecture économique change totalement.
Le coût du projet augmente, mais son business case peut s’améliorer.
C’est probablement l’un des enseignements les plus importants du crash program : le moins cher n’est pas toujours de dépenser le moins possible.
Crash program et suivi budgétaire : ne pas cacher le surcoût
Une décision de crashing doit donc être identifiable dans le pilotage financier.
Il faut distinguer le coût additionnel décidé pour accélérer le projet d’une simple dérive budgétaire.
Si 100.000 € supplémentaires ont été volontairement engagés pour sécuriser une échéance stratégique, les présenter quelques semaines plus tard comme un banal dépassement de coûts ferait perdre une partie de l’information de pilotage.
Le chef de projet doit pouvoir expliquer la chaîne de décision : délai menacé → scénario d’accélération → coût supplémentaire → délai gagné → bénéfice attendu.
La prévision à terminaison doit naturellement intégrer les nouveaux coûts. Une modification de la référence budgétaire, en revanche, dépendra des règles de gouvernance et du processus de maîtrise des changements de l’organisation.
Modifier une prévision et modifier une référence ne sont pas la même chose.
Et le fast tracking ?
Il existe une autre technique classique de compression du planning : le fast tracking.
Cette fois, on ne met pas nécessairement davantage de moyens sur une activité. On modifie plutôt l’ordonnancement en faisant se chevaucher des activités qui devaient initialement se succéder.
Le crashing achète principalement du temps avec des ressources supplémentaires. Le fast tracking achète du temps en acceptant davantage de risque, notamment celui de devoir reprendre du travail commencé trop tôt.
Les deux techniques peuvent naturellement être combinées.
Il faut simplement éviter une troisième technique, beaucoup plus répandue mais curieusement absente des référentiels : annoncer une nouvelle date de fin sans changer ni les moyens, ni l’organisation, ni le périmètre.
Avant de lancer un crash program
La bonne question n’est donc pas « Combien coûte le retard ? » ni même « Combien coûtera le crash program ? » Il faut comparer les 2.
Une analyse sérieuse cherche à savoir quelle activité critique peut être accélérée, combien coûte chaque unité de temps gagnée, quels nouveaux risques sont créés et quelle valeur économique possède le délai récupéré.
Le crash program n’est donc pas une fuite en avant budgétaire. Bien utilisé, c’est un arbitrage délai-coût.
Et sa règle pourrait finalement tenir en une phrase : on ne cherche pas à terminer plus vite à n’importe quel prix ; on cherche à savoir quel prix il est rationnel de payer pour terminer plus vite.
Laisser un commentaire