Un planning projet web ressemble souvent à un diagramme de Gantt propre : des barres colorées, une date de mise en ligne en rouge à droite, et tout le monde d'accord en réunion de lancement. Trois semaines plus tard, les textes ne sont pas arrivés, le prestataire attend des accès qu'il n'a jamais demandés par écrit, et la date reste la même sur le document parce que personne n'ose y toucher.
J'ai appris à tenir un planning en production audiovisuelle, où la date de diffusion ne bouge pas : on ajuste tout le reste, jamais elle. Aujourd'hui je pilote seul des missions courtes, où je conçois et je mets en œuvre moi-même, et je construis mes plannings dans l'autre sens : d'abord les dépendances, ensuite les durées, enfin les dates. Voici la méthode, ce qu'elle doit aux références de la gestion de projet, et ce qu'elle ne règle pas pour vous.
01Ce qu'un planning projet web doit montrer avant les dates
Un planning répond à trois questions, dans cet ordre : qui attend quoi, de qui, et qu'est-ce qui se décale si ça n'arrive pas. Les dates viennent après, comme une conséquence. Un planning qui commence par les dates répond à une autre question (quand voudrait-on avoir fini ?), et il devient faux dès qu'une seule attente a été oubliée.
Sur un projet web, les attentes sont nombreuses et rarement techniques. Le développement attend la maquette validée. La maquette attend les contenus, ou au moins leur structure. La mise en ligne attend la recette, le nom de domaine, les textes légaux, parfois un service tiers qui doit ouvrir un compte. Chacune de ces flèches a un propriétaire, et c'est souvent quelqu'un qui n'est pas dans l'équipe projet.
Ce que je veux voir sur un planning, c'est donc un réseau plutôt qu'une liste : des tâches, des flèches entre elles, et un nom sur chaque flèche. Le Gantt peut venir ensuite. Il se dessine presque seul à partir de ce réseau.
02Lister les dépendances, y compris celles qui ne sont pas des tâches
La gestion des dépendances projet commence par une question posée tâche par tâche : qu'est-ce qui doit être fini avant que celle-ci puisse commencer ? C'est l'exercice que décrit Charles Jones dans un article du Project Management Institute sur le passage de l'organigramme des tâches au chemin critique. Il insiste sur une distinction que je trouve très utile en réunion : les dépendances obligatoires et les dépendances discrétionnaires, qui ne sont que la « façon habituelle » de faire. Beaucoup d'équipes prennent les secondes pour les premières et s'interdisent de mener deux chantiers en parallèle.
Sur un site, l'exemple classique est l'enchaînement maquette, contenus, puis développement. Rien n'oblige à attendre les textes définitifs pour développer les gabarits, à condition d'avoir leur structure et leur longueur. Rien n'oblige non plus à attendre la fin du développement pour rédiger les mentions légales.
Viennent ensuite les dépendances qui ne ressemblent pas à des tâches. Ce sont elles qui cassent les plannings que je vois passer :
- une validation, parce que quelqu'un doit dire oui et que ce quelqu'un a un agenda ;
- un accès : DNS, compte d'hébergement, outil de mesure d'audience, back-office d'un partenaire ;
- un document, comme la spécification d'une intégration, une charte ou une liste de redirections ;
- une décision entre deux options, ou un arbitrage de budget ;
- un tiers : un prestataire, un éditeur de logiciel, un service juridique.
Dans mes machines de contenu, j'ai un statut pour ce cas : « en attente ». Il signale qu'une décision humaine doit être prise, et la machine ne traite jamais un sujet dans cet état. Je fais la même chose dans un planning. Une tâche qui attend une décision porte le nom de la personne qui doit la prendre et la date à laquelle il me la faut. Sans ce nom, l'attente reste invisible jusqu'au jour où elle bloque.
03Du rétroplanning au chemin critique, pas à pas
Le rétroplanning projet part de la date qui ne bouge pas et remonte le temps. C'est la bonne façon de commencer quand la date vous est imposée : un lancement, un salon, une campagne déjà achetée. Mais un rétroplanning seul ne dit pas où est le danger. Pour ça, il faut le chemin critique.
Étape 1 : poser la date fixe et ce qui doit être vrai ce jour-là
J'écris en une ligne ce qui doit être en ligne à la date, et ce qui peut attendre une deuxième version. C'est le moment de couper, pas trois jours avant.
Étape 2 : lister les tâches et leurs prédécesseurs
Une ligne par tâche, un verbe et un objet (« rédiger les pages services », « configurer les redirections »), et pour chacune ce qui doit être fini avant. Un tableur suffit, avec quatre colonnes : tâche, prédécesseurs, propriétaire, durée.
Étape 3 : estimer les durées
J'y reviens dans la section suivante, parce que c'est là que les plannings se mentent à eux-mêmes.
Étape 4 : trouver le chemin critique
Le chemin critique projet est la plus longue chaîne de tâches dépendantes. Jones le définit simplement : ce sont les activités dont la marge est nulle ou négative, qui ne peuvent pas glisser sans décaler la fin du projet. Un logiciel de planification le calcule, mais sur un projet web de taille raisonnable, on le trouve à la main en suivant les flèches.
Étape 5 : remonter depuis la date fixe
Je place les tâches du chemin critique en partant de la date et en remontant. Si la première tombe avant aujourd'hui, le planning n'est pas tenable tel quel : il faut couper du périmètre, paralléliser une dépendance discrétionnaire ou déplacer la date. Autant le savoir le premier jour.
04Estimer des durées qu'on peut défendre
Une durée annoncée en réunion est presque toujours trop courte. Le Trésor britannique l'écrit sans détour dans son guide sur le biais d'optimisme : ceux qui évaluent un projet ont tendance à être trop optimistes, et les durées doivent être ajustées explicitement à partir de projets passés ou comparables. Bent Flyvbjerg, dans sa synthèse des biais en gestion de projet, range l'erreur de planification et le biais d'optimisme parmi les dix principaux, et voit dans l'oubli des projets comparables une raison majeure de leur sous-performance.
Concrètement, je fais quatre choses.
Je demande trois estimations au lieu d'une : si tout va bien, si les problèmes habituels arrivent, si presque tout va mal. La méthode PERT, que rappelle Jones, combine les trois en une durée en général un peu plus longue que la valeur probable. L'intérêt est surtout dans la conversation : la personne qui estime peut dire son incertitude sans passer pour quelqu'un qui gonfle ses chiffres.
Je convertis les heures en jours avec la disponibilité réelle. L'article de Jones donne un exemple parlant : 60 heures de travail, pour une personne disponible à 50 %, avec 6,5 heures productives par jour, font environ 18,5 jours, et non la « semaine et demie » qu'on annonce spontanément.
Je précise l'unité. « Dix jours », ce sont dix jours calendaires, dix jours ouvrés, ou dix jours de travail étalés sur un mois ? Tant que la question n'est pas tranchée, le chiffre ne veut rien dire.
Enfin, je sépare la marge de l'estimation. Crispin Piney, dans un article de PM Network sur chemin critique et chaîne critique, distingue la marge qui découle des dépendances et le tampon, du temps alloué volontairement pour absorber les écarts. Je préfère un tampon visible, posé avant la date fixe et suivi chaque semaine, à des marges cachées dans chaque tâche que personne ne peut piloter.
05Tenir le planning quand une dépendance glisse
Il y a toujours une dépendance qui glisse. L'enjeu est de le voir tôt et de savoir quoi en faire.
Mon premier réflexe vient de mes machines de contenu, où une vérification qui n'a pas eu lieu compte comme un échec, jamais comme un succès par défaut. Dans un planning, une dépendance non confirmée est en retard. Un « les textes arrivent la semaine prochaine » sans date ni nom ne vaut pas une livraison.
Deuxième réflexe : regarder si la tâche en retard est sur le chemin critique. Si elle a de la marge, je note et je continue. Si elle est critique, le retard se reporte sur la date de fin, et il faut choisir : consommer le tampon, couper du périmètre, ajouter quelqu'un, ou annoncer un décalage. Ce choix ne m'appartient pas toujours. Quand il dépasse mon autorité, il part au comité de pilotage du projet, avec les options écrites.
Troisième réflexe : versionner. Le calendrier de mes machines de contenu est un fichier versionné, et changer la cadence revient à changer les dates prévues, pas à réécrire la machine. Pour un planning, c'est la même idée que pour une spécification d'intégration qui bouge à chaque réunion : une nouvelle version datée, avec ce qui a changé, pour que tout le monde parle du même document. Un planning modifié en silence perd la confiance de l'équipe en deux itérations.
06Ce que cette méthode ne règle pas
Elle ne rend pas possible une date impossible. Elle la rend visible plus tôt, ce qui est déjà beaucoup, mais quelqu'un devra encore choisir entre le périmètre et la date. Si vous attendez d'un planning qu'il fasse ce choix à votre place, il vous décevra.
Elle ne remplace pas le cadrage. Si l'objectif du site ou son périmètre ne sont pas clairs, le réseau de dépendances sera faux dès le départ. C'est pour ça que je fais d'abord un cadrage court du projet, avant de poser le moindre planning.
Elle a aussi un coût : une demi-journée avec les bonnes personnes autour d'un tableur, puis des relances régulières sur les dépendances externes. Sur un très petit site, fait par une seule personne en quelques jours, je ne la déroule pas en entier. Une liste des accès et des validations à obtenir suffit.
Enfin, le goulot n'est pas toujours là où on le cherche. Sur une mission, ce n'était pas la production qui ralentissait tout, c'était la mise en ligne, faite à la main. Le chemin critique m'a montré où regarder. Il ne m'a pas dit quoi changer.
07Par où commencer lundi
Reprenez votre planning actuel et, pour chaque tâche, écrivez ce qu'elle attend et de qui. Marquez les attentes qui ne sont pas des tâches : validations, accès, décisions. Cherchez la chaîne la plus longue, puis comparez sa durée au temps qui vous reste avant la date qui ne bouge pas. Si l'écart est négatif, vous le saurez lundi plutôt que la veille de la mise en ligne, et la recette avant mise en production gardera sa place dans le calendrier.
Si vous voulez un regard extérieur sur un planning en cours ou à construire, cela fait partie des missions de direction de projet que je mène. On peut en parler.