Tout projet comporte des dizaines, parfois des centaines de tâches. Certaines peuvent glisser de quelques jours sans conséquence sur la date de livraison. D’autres, si elles prennent du retard, décalent mécaniquement la fin du projet. La méthode du chemin critique (Critical Path Method, ou CPM) permet d’identifier précisément ces tâches déterminantes et de concentrer l’attention là où elle compte vraiment.
Le principe en une phrase
Le chemin critique est la séquence la plus longue de tâches dépendantes dans un projet. Sa durée totale définit la durée minimale du projet: il est impossible de terminer plus vite que ce que ce chemin impose, sauf à raccourcir l’une de ses tâches ou à en exécuter certaines en parallèle. Les tâches situées sur ce chemin ont une marge nulle, ce qui signifie que tout retard sur l’une d’elles retarde d’autant la date de fin.
D’où part-on? Du WBS au réseau de dépendances
La méthode du chemin critique ne fonctionne pas dans le vide. Elle s’appuie sur une décomposition préalable du travail, typiquement une WBS (Work Breakdown Structure, l’organigramme des tâches), qui fournit la liste des activités à réaliser. Le CPM ajoute à cette liste deux informations essentielles: la durée estimée de chaque tâche et les liens de dépendance entre elles. Dans la chaîne de planification, le CPM constitue le chaînon logique entre le WBS et le diagramme de Gantt: le WBS décompose le travail en tâches, le CPM établit leurs dépendances et identifie la séquence critique, puis le Gantt projette le tout sur un calendrier pour en donner une représentation visuelle.
Ces dépendances prennent plusieurs formes. La plus courante est la relation fin-début: la tâche B ne peut commencer qu’une fois la tâche A terminée. Dans un projet de rénovation de bureau, par exemple, on ne peut poser le revêtement de sol qu’après avoir terminé les travaux d’électricité encastrée. C’est cette logique de séquencement, et non le calendrier, qui détermine la structure du réseau.
Comment calculer le chemin critique
Le calcul repose sur deux passes successives à travers le réseau de tâches.
La passe avant (forward pass) parcourt le réseau du début vers la fin. Pour chaque tâche, on calcule la date de début au plus tôt (Early Start) et la date de fin au plus tôt (Early Finish), en tenant compte des dépendances. Quand une tâche a plusieurs prédécesseurs, elle ne peut commencer qu’après la fin du dernier d’entre eux. La date de fin au plus tôt de la dernière tâche donne la durée minimale du projet.
La passe arrière (backward pass) parcourt le réseau en sens inverse, depuis la fin du projet. On calcule pour chaque tâche la date de début au plus tard (Late Start) et la date de fin au plus tard (Late Finish), c’est-à-dire les dates limites au-delà desquelles un retard impacterait la livraison.
La différence entre le début au plus tard et le début au plus tôt donne la marge (ou float) de chaque tâche. Les tâches dont la marge est nulle forment le chemin critique. Selon une étude publiée dans la Harvard Business Review dès 1963, environ 10% seulement des tâches d’un grand projet se trouvent sur le chemin critique, ce qui explique pourquoi cette identification est si précieuse: elle permet de focaliser la surveillance sur une fraction ciblée du plan.
Un exemple concret
Prenons un projet simplifié de lancement d’un espace de coworking comportant cinq tâches principales:
- Études de faisabilité (2 semaines)
- Travaux d’aménagement (6 semaines, après études)
- Sélection du mobilier (3 semaines, après études)
- Installation du mobilier (2 semaines, après travaux ET sélection)
- Mise en service (1 semaine, après installation)
La passe avant identifie deux chemins possibles. Le premier passe par les études, les travaux, l’installation et la mise en service: 2 + 6 + 2 + 1 = 11 semaines. Le second passe par les études, la sélection du mobilier, l’installation et la mise en service: 2 + 3 + 2 + 1 = 8 semaines. Le chemin le plus long (11 semaines) est le chemin critique. La sélection du mobilier dispose de 3 semaines de marge: elle peut commencer jusqu’à 3 semaines après la fin des études sans retarder le projet.
Ce que le chemin critique ne dit pas
La fiabilité du chemin critique dépend directement de la qualité des estimations de durée qui le nourrissent, et ces estimations restent par nature incertaines. La technique PERT (Program Evaluation and Review Technique), développée à la même époque que le CPM, tente de pallier cette limite en travaillant avec trois estimations par tâche (optimiste, probable, pessimiste) plutôt qu’une seule, ce qui introduit une dimension probabiliste dans l’analyse. Cette incertitude se double d’un angle mort sur les ressources: une tâche peut afficher une marge théorique confortable, mais si la seule personne qualifiée pour la réaliser est déjà mobilisée sur une tâche critique, sa marge réelle tombe à zéro. L’analyse du chemin critique gagne donc à être complétée par un nivellement des ressources pour refléter la réalité opérationnelle. Il faut enfin surveiller les chemins quasi-critiques avec autant de vigilance que le chemin critique lui-même, car un chemin dont la marge ne dépasse pas deux jours peut basculer au moindre imprévu, et les projets ne manquent jamais d’imprévus.
Du calcul à la pratique quotidienne
Sur le terrain, le chemin critique n’est pas un calcul qu’on fait une fois pour l’afficher dans un diagramme de Gantt. C’est un outil de pilotage vivant qui doit être recalculé chaque fois que les durées, les dépendances ou les contraintes évoluent. Les logiciels de planification modernes (MS Project, Primavera, ou même des outils plus légers) le recalculent automatiquement à chaque mise à jour du plan.
L’intérêt principal du CPM pour un chef de projet n’est pas mathématique: c’est un outil de communication et de décision. James E. Kelley Jr., co-inventeur de la méthode chez DuPont en 1957, soulignait déjà que l’objectif premier du CPM était de rendre les arbitrages de planification explicites et discutables. Quand un retard survient sur une tâche critique, le chemin critique rend visible l’impact sur la date de fin du projet et permet de poser la bonne question: faut-il comprimer la tâche en y ajoutant des ressources (crashing), exécuter certaines tâches en parallèle malgré le risque accru (fast-tracking), ou accepter le décalage et en informer les parties prenantes?