Un planning qui se recalcule, pas un dessin.

Il y a deux objets qui portent le même nom. Le premier est un dessin : des barres posées à la main, ajustées jusqu'à ce que l'ensemble tombe sur la bonne date. Le second est un calcul : des durées, des liens, un calendrier, et des dates qui en sortent.

Ils se ressemblent beaucoup sur un écran. Ils se distinguent le jour où une tâche prend une semaine de plus. Le premier demande une soirée de reprise, et on la lui accorde de moins en moins souvent. Le second se recalcule pendant qu'on glisse la barre, et il montre immédiatement ce qui vient de bouger trois lots plus loin.

Nous avons écrit un moteur de planification. Ce qui suit est ce qu'on apprend en le faisant, c'est-à-dire en devant décider, ligne de code après ligne de code, ce qu'un planning a le droit de faire tout seul.

Le planning qu'on redessine le vendredi soir

On le reconnaît à un signe qui ne trompe pas : quelqu'un tape des dates sur les tâches.

À partir de là, la mécanique est enclenchée. Chaque date tapée est une affirmation manuelle que plus rien ne vérifie. Quand la réalité bouge, il faut reprendre les dates une par une, en espérant n'en oublier aucune. Comme c'est long, on le fait pour le comité, puis on le fait moins bien, puis on maintient deux vérités : le vrai calendrier dans la tête de l'équipe, et le planning officiel dans l'outil.

Le coût réel n'est pas le temps de reprise. C'est que le planning cesse d'être un instrument de décision. Personne ne lui demande plus « que se passe-t-il si ce lot glisse de deux semaines ? », parce que tout le monde sait que la réponse demanderait une soirée.

La règle d'or : des durées et des liens, jamais des dates

Un planning qui se recalcule se construit avec trois matières et trois seulement.

• Des durées. Combien de temps la tâche prend, indépendamment de quand elle a lieu.
• Des liens. Ce qui doit être vrai pour qu'elle puisse commencer ou finir.
• Un calendrier. Quels jours comptent pour du travail.

Les dates ne sont pas une matière. Ce sont un résultat. Le moteur les déduit, et il les déduit de nouveau à chaque changement. C'est la seule façon d'obtenir un plan qui réagisse, et c'est aussi la seule façon d'obtenir un plan qui puisse être discuté : quand une date déplaît, on ne discute pas de la date, on discute de la durée ou du lien qui la produit. La conversation devient beaucoup plus intéressante.

Une conséquence pratique, et elle est immédiate. Si vous devez taper une date pour obtenir le bon résultat, c'est qu'il manque un lien. Cherchez-le. Il existe presque toujours, et il porte une information que la date efface.

La contrainte de date, le poison lent

Les outils de planification savent tous poser une contrainte : commencer au plus tôt le, finir au plus tard le, doit commencer le. Elles sont utiles. Elles sont aussi le moyen le plus rapide de tuer un planning, parce que chacune est un endroit où le recalcul s'arrête.

Le critère de légitimité tient en une question. Cette date vient-elle de l'extérieur du projet ?

Une fenêtre d'arrêt d'usine, une date contractuelle, une échéance réglementaire, la disponibilité d'un moyen d'essai partagé : oui, ce sont des faits du monde, et une contrainte est la bonne façon de les dire. Une date qu'on souhaite, en revanche, n'est pas une contrainte. C'est un objectif, et un objectif se pose sur un jalon, où il sera confronté au calcul au lieu de le remplacer.

La différence se voit le jour du dérapage. Avec un objectif, le moteur vous montre que vous ne tiendrez pas, et de combien. Avec une contrainte dure, le moteur tient la date et vous ne voyez rien, jusqu'à ce que la réalité tranche à votre place.

Le calendrier ouvré fait la moitié du travail

Un plan calculé en jours calendaires est faux d'environ trente pour cent, et il l'est silencieusement. Cinq jours de travail posés un mercredi se terminent le mardi suivant, pas le dimanche.

Le calendrier ouvré n'est donc pas un réglage de confort. C'est ce qui rend les durées comparables entre elles. Et il doit porter vos exceptions, pas celles d'un autre : les jours fériés du pays où le travail se fait, les fermetures d'entreprise, les semaines d'arrêt technique, les équipes qui travaillent en cinq jours quand d'autres tournent en continu.

C'est un des rares endroits où un outil de planification peut être franchement mauvais sans que cela se voie. Un calendrier faux ne produit aucune erreur visible. Il produit des dates légèrement fausses, partout, qui s'accumulent le long des chaînes de tâches.

Les liens, et ce qu'ils disent vraiment

Un lien entre deux tâches n'est pas une flèche décorative. C'est une phrase logique que le moteur applique à chaque recalcul. Il en existe quatre, et la question n'est pas laquelle est la meilleure, mais laquelle dit la vérité sur votre chantier.

Le lien le plus fréquent est fin à début : la seconde ne peut pas commencer tant que la première n'est pas terminée. C'est aussi le seul que la plupart des équipes utilisent, ce qui produit des plannings en escalier, plus longs que nécessaire, où des travaux qui pourraient se chevaucher s'attendent poliment.

Les trois autres, leurs décalages, et la faute la plus fréquente de toutes, qui consiste à poser un lien pour forcer une date, sont traités ici : les quatre types de dépendances, avec des exemples qui arrivent vraiment.

Le chemin critique, et ce qu'il ne dit pas

Dès que les durées et les liens sont posés, le moteur sait calculer la chaîne de tâches qui commande la date de fin. C'est le chemin critique, et c'est l'information la plus utile d'un planning prédictif.

C'est aussi celle à laquelle on fait dire le plus de bêtises. Qu'il désigne les tâches importantes, ce qui est faux. Qu'il est unique, ce qui est souvent faux. Qu'une tâche qui n'y est pas peut déraper sans conséquence, ce qui est faux et coûteux. Le détail est ici : à quoi sert vraiment le chemin critique.

La référence, sans quoi rien ne se mesure

Un planning qui se recalcule a un défaut : il a toujours l'air juste. À chaque mise à jour, il affiche un plan cohérent, et la mémoire de ce qui était prévu disparaît.

La référence règle cela. C'est un instantané complet du planning à un moment donné, figé, conservé à côté du plan vivant. Pas une capture d'écran, pas un fichier daté dans un dossier partagé : la même structure de données, que le moteur peut comparer barre par barre.

Ce qu'elle vous donne est simple et on ne l'obtient pas autrement : l'écart, tâche par tâche, entre ce qui était prévu et ce qui se passe. C'est la matière du comité de pilotage. Sans référence, on présente une situation. Avec référence, on présente une dérive, ce qui est une information.

Posez la première référence quand le plan est validé, pas avant, et gardez les suivantes plutôt que de les écraser. Une référence remplacée à chaque avenant raconte une histoire où rien n'a jamais dérapé.

La mise à jour hebdomadaire, en vingt minutes

Un planning qui ne se met pas à jour ne vaut rien, quel que soit le moteur. La bonne nouvelle, c'est que la mise à jour d'un plan qui recalcule demande très peu de choses.

Trois questions, par tâche, et rien d'autre.

• A-t-elle commencé ? Si oui, à quelle date réelle.
• Est-elle finie ? Si oui, à quelle date réelle.
• Si elle est en cours, combien de temps reste-t-il ?

La troisième question est celle qui change tout, et elle remplace une question qu'il faut cesser de poser : « tu en es à combien pour cent ? ». Le pourcentage d'avancement est l'indicateur le plus optimiste de la gestion de projet. Il monte vite jusqu'à quatre-vingt dix, puis il y reste trois semaines. Demandez la durée restante. Elle est difficile à surestimer sans mentir, elle entre directement dans le moteur, et elle donne tout de suite une nouvelle date de fin.

Ensuite, on recalcule et on regarde ce qui a bougé. Pas les tâches mises à jour, celles qui ont bougé sans qu'on y touche. C'est là que se trouve l'information de la semaine.

La marge, c'est là que vivent vos risques

La marge d'une tâche est le temps qu'elle peut perdre sans décaler la fin du projet. Sur le chemin critique, elle est nulle par définition.

Cette notion technique a une traduction très concrète en gestion des risques, et les deux sujets se parlent beaucoup moins qu'ils ne le devraient. La marge est l'endroit où les aléas s'absorbent. Un risque qui se produit sur une tâche disposant de quinze jours de marge coûte de l'inconfort. Le même risque sur une tâche critique coûte quinze jours de projet.

Il en découle deux réflexes utiles. D'abord, cotez l'impact d'un risque en regardant la marge de la tâche qu'il touche, pas seulement la gravité de l'événement. Ensuite, quand une réponse au risque consiste à gagner du temps, vérifiez qu'elle en gagne là où il n'y en a pas. La façon d'écrire tout cela est dans notre pilier sur les risques.

Une dernière chose, apprise en construisant le moteur. La marge se déplace. Elle bouge à chaque mise à jour, parfois beaucoup, et une tâche tranquille pendant deux mois peut devenir critique un jeudi matin sans que personne ne l'ait décidé. C'est une raison suffisante pour recalculer chaque semaine, et pour regarder la marge autant que les dates.