Gestion des délais : chemin critique, marge et compression du planning

Un planning n'est pas une liste de dates. C'est un modèle de la façon dont le travail dépend d'autres travaux, et son vrai résultat est la réponse à une seule question : quelles activités, si elles prennent un jour de retard, décalent la date de fin d'un jour ? Tout le reste (le diagramme à barres, le rapport de jalons, l'histogramme des ressources) n'est que de la présentation posée sur ce modèle.

Ce guide construit ce modèle pas à pas sur un petit exemple que vous pouvez suivre avec un crayon, puis explique quoi en faire : niveler les ressources, comprimer un planning trop long et garder une référence de base pertinente quand la réalité s'en écarte. Il suppose que vous disposez déjà d'une décomposition du travail, sujet traité dans le guide les fondamentaux de la gestion de projet.

Des lots de travail à l'enchaînement des activités

La planification commence par transformer chaque lot de travail en une ou plusieurs activités (les verbes, là où la structure de découpage contenait les noms), puis par décider de ce qui doit précéder quoi. Deux disciplines portent leurs fruits immédiatement : chaque activité a exactement un responsable, et chaque activité a un critère d'achèvement clair, pour qu'un « en cours » ne puisse pas durer des semaines.

Il existe quatre types de dépendances, et choisir le bon évite une bonne part de sérialisation artificielle.

La relation FD couvre l'immense majorité des cas. DD et FF permettent de modéliser honnêtement un travail qui se chevauche au lieu d'imposer une fausse séquence. DF est rare et apparaît surtout lors des bascules.

L'avance est une attente négative : on démarre un successeur avant la fin de son prédécesseur, par exemple en lançant les tests d'intégration deux jours avant que le dernier composant soit terminé. Le décalage est une attente imposée qui ne consomme aucun effort : le séchage du béton, un préavis réglementaire de deux semaines, une réindexation de base de données qui tourne la nuit. Modélisez les décalages explicitement plutôt que de gonfler la durée d'une activité : un décalage n'a pas de coût et ne peut pas être raccourci en ajoutant des ressources, et le cacher dans une durée fait mentir le planning sur ces deux points.

Distinguez les dépendances obligatoires, inhérentes au travail, des dépendances discrétionnaires, qui traduisent une préférence ou une habitude. C'est en général dans les dépendances discrétionnaires que la compression du planning trouve sa marge de manœuvre : signalez-les dès leur création.

Estimer les durées

Trois techniques couvrent l'essentiel des besoins, et on les combine généralement.

L'estimation par analogie extrapole à partir d'une activité passée comparable : la dernière migration de taille similaire a pris neuf jours, celle-ci est un peu plus grosse, comptons douze. Rapide, peu coûteuse, et elle ne vaut que ce que vaut la comparaison.

L'estimation paramétrique s'appuie sur un taux mesuré : 40 écrans à 1,5 jour par écran font 60 jours. C'est la technique la plus défendable quand ce taux existe vraiment, et dangereuse quand le paramètre est inventé pour justifier un chiffre.

L'estimation à trois points rend l'incertitude explicite avec une valeur optimiste, une valeur la plus probable et une valeur pessimiste. La forme pondérée par une loi bêta, associée à PERT, est la suivante :

Expected duration   te = (O + 4M + P) / 6
Standard deviation  sd = (P - O) / 6

Backend build:  O = 6 days, M = 9 days, P = 18 days
   te = (6 + 36 + 18) / 6 = 10 days
   sd = (18 - 6) / 6 = 2 days

Interpretation: ~10 days expected; roughly 95% confidence
of finishing within te + 2sd = 14 days.

Remarquez comment la longue traîne tire la valeur attendue au-dessus de la valeur la plus probable : cette asymétrie est la réalité des activités logicielles, où les choses tournent mal plus souvent qu'elles ne se passent exceptionnellement bien. Le dimensionnement relatif au niveau de l'équipe est un autre outil pour une autre question, traité dans estimation et planification.

Un chemin critique calculé pas à pas

Prenons une petite livraison de neuf activités. Les durées sont exprimées en jours ouvrés.

La passe avant se fait de gauche à droite et calcule le début et la fin au plus tôt de chaque activité. Une activité démarre dès que tous ses prédécesseurs sont terminés : quand plusieurs convergent, on retient la fin la plus tardive. La passe arrière repart ensuite de la fin du projet, de droite à gauche, et calcule le début et la fin au plus tard de chaque activité sans repousser cette date de fin ; quand une activité a plusieurs successeurs, on retient le début au plus tard le plus précoce.

Le projet dure 29 jours, et il existe deux chemins critiques : A–B–D–G–H–I et A–C–E–G–H–I totalisent tous deux 29 jours. Seule F dispose d'une marge, de neuf jours : les scripts sont prêts au jour 15, mais la répétition de la migration ne peut pas commencer avant la fin des tests d'intégration au jour 24. La marge libre de F est elle aussi de neuf jours, puisque la retarder jusque-là ne décale le début au plus tôt d'aucun successeur.

Deux enseignements pratiques en découlent. D'abord, les scripts de migration ne sont pas urgents : emprunter ce développeur pendant une semaine ne coûte rien. Le planning vous montre où se trouve vraiment la marge, ce que l'intuition fait rarement. Ensuite, comme deux chemins sont critiques, raccourcir uniquement le développement du backend ne change strictement rien : le chemin du frontend court toujours jusqu'au jour 19. C'est l'erreur la plus courante en compression de planning, et elle n'apparaît que si l'on calcule le réseau au lieu de juger à l'œil sur le diagramme à barres.

Présenter et niveler

Un diagramme de Gantt représente le réseau sous forme de barres sur un calendrier. Il est excellent pour communiquer et désastreux comme outil de planification à lui seul, car un diagramme dessiné à la main encode des dates sans dépendances : quand une barre bouge, aucune autre ne suit, et le plan devient discrètement une fiction. Générez toujours le diagramme à partir du réseau. Affichez le chemin critique dans une couleur distincte, représentez les jalons par des losanges, et résistez à l'envie de montrer quatre cents lignes à un comité de pilotage quand neuf barres de synthèse suffisent à porter le message.

Les jalons sont des repères de durée nulle qui marquent un état significatif : conception approuvée, environnement d'intégration disponible, recette utilisateur signée. Ils se prêtent mieux au reporting que les pourcentages parce qu'ils sont binaires. Un graphique de tendance des jalons, qui trace la date prévue de chaque jalon à chaque période de reporting, est le rapport de planning le plus instructif qui soit : une courbe qui dérive régulièrement vers la droite révèle un problème des mois avant que le jalon soit manqué.

Viennent ensuite les conflits de ressources. Le nivellement des ressources ajuste le planning pour que la demande ne dépasse jamais la disponibilité ; comme il peut retarder des activités, il peut repousser la date de fin du projet et changer le chemin critique. Le lissage des ressources n'ajuste les activités qu'à l'intérieur de leur marge disponible : la date de fin est préservée, mais la demande n'est aplanie que dans la limite de cette marge. Si un même spécialiste intervient sur les deux chemins critiques de l'exemple ci-dessus, le nivellement allongera le projet, et aucun reporting n'y changera rien.

Comprimer un planning

Quand la date de fin calculée est postérieure à la date exigée, il existe exactement deux techniques légitimes, plus une alternative honnête.

Le crashing ajoute des ressources aux activités critiques pour les raccourcir. Cela coûte de l'argent et n'a rien de linéaire : doubler l'équipe divise rarement la durée par deux, et ajouter des personnes à un travail déjà en cours le ralentit généralement. Comprimez en priorité l'activité critique dont le jour gagné coûte le moins cher, et recalculez le réseau après chaque étape, car la compression change le chemin critique.

Reprenons l'exemple en supposant que l'échéance soit de 25 jours au lieu de 29 :

Accélérer H fait gagner un jour sur les deux chemins pour 2 000 : c'est clairement la première étape. Accélérer G fait gagner un jour de plus sur les deux chemins pour 6 000. Accélérer D ou E ne rapporte rien si l'on ne comprime pas les deux, soit 13 000 au total pour deux jours. Atteindre 25 jours coûte donc 21 000 et touche quatre activités, alors que le réflexe intuitif « accélérons le backend » aurait dépensé 8 000 pour ne rien gagner.

Le fast tracking fait se chevaucher des activités prévues en série, généralement en transformant une dépendance fin à début en dépendance début à début avec une avance. Il ne coûte rien en argent mais achète un risque de reprise : démarrer le frontend avant la fin de la conception des interfaces signifie qu'une partie sera construite deux fois. Appliquez le fast tracking d'abord aux dépendances discrétionnaires, jamais aux obligatoires, et consignez le risque supplémentaire dans le registre des risques.

L'alternative honnête consiste à réduire le périmètre. C'est généralement moins cher et plus sûr que l'une ou l'autre technique, et c'est pourtant l'option que l'on évoque en dernier.

Référence de base, changements et suivi

Une fois le planning validé, figez-en une copie : c'est la référence de base. Tout ce qui suit se mesure par rapport à elle, et elle ne change que par une demande de modification approuvée. Sinon, le plan est discrètement réécrit chaque mois pour coller à la réalité, et le projet semble dans les temps jusqu'au jour où il ne l'est plus.

Un processus de changement qui fonctionne : une analyse d'impact sur les délais, les coûts et les risques ; une décision prise par la personne qui détient l'autorité à ce seuil ; une nouvelle référence de base uniquement si le changement est approuvé ; et une trace conservée de la référence précédente. Redéfinir la référence de base est légitime après un vrai changement de périmètre, et illégitime quand il s'agit d'effacer un écart.

Suivez l'avancement par rapport au réseau, et non par rapport au temps calendaire écoulé. Les questions à se poser chaque semaine : une activité critique est-elle en retard ? Quelle part de marge a été consommée sur les chemins quasi critiques ? Les prévisions des jalons dérivent-elles ? Une hypothèse de dépendance a-t-elle été invalidée ? L'écart de délai exprimé en coûts est traité dans la gestion de la valeur acquise, qui convertit la même information en argent et vous fournit un indice dont vous pouvez suivre la tendance.

Points clés à retenir

• Un modèle de planning sert à identifier les activités qui ne peuvent pas glisser ; le diagramme à barres n'est que de la présentation, et en dessiner un sans réseau de dépendances produit un plan incapable de réagir.
• Utilisez les quatre types de dépendances et modélisez les décalages explicitement au lieu de gonfler les durées ; signalez les dépendances discrétionnaires, car c'est là que la compression trouve de la marge.
• Calculez les marges par une passe avant et une passe arrière ; la marge totale se mesure par rapport à la date de fin, la marge libre est celle qui n'affecte aucun successeur.
• Un réseau peut avoir plusieurs chemins critiques, et n'en comprimer qu'un seul ne rapporte rien : recalculez toujours après chaque étape de compression.
• Le nivellement peut repousser la date de fin, le lissage non ; si un spécialiste se trouve sur deux chemins critiques, le planning s'allongera.
• Figez une référence de base et ne la modifiez que par des décisions tracées ; redéfinir la référence pour effacer un écart détruit le seul repère dont vous disposiez.