Vous avez ouvert un diagramme de Gantt, vous l’avez trouvé clair, et vous ne l’avez jamais rouvert. Le problème n’est pas le graphique, c’est ce qu’il ne montre pas.
Ce qu’est un diagramme de Gantt, et ce qu’il n’est pas
Un diagramme de Gantt représente les tâches d’un projet sous forme de barres horizontales posées sur une échelle de temps. La position de chaque barre indique quand la tâche commence, sa longueur indique combien de temps elle dure, et le fait que deux barres se chevauchent indique que deux tâches se déroulent en même temps. C’est tout. Cette simplicité est sa force : on lit un calendrier de projet en quelques secondes, sans avoir à ouvrir un tableau ni à compter des lignes.
Cette simplicité est aussi la source de tous les malentendus. Un diagramme de Gantt n’est pas un plan de projet. Il ne dit pas pourquoi une tâche existe, qui l’a demandée, ce qu’elle doit produire ni comment on saura qu’elle est terminée. Il ne dit pas non plus si les durées affichées sont réalistes : une barre de trois semaines s’affiche exactement pareil qu’elle repose sur une estimation solide ou sur une intuition prise en réunion. Le graphique donne une forme visuelle à des données que quelqu’un a saisies, et il leur donne une apparence d’exactitude qu’elles n’ont pas forcément.
Il faut donc le voir pour ce qu’il est : une représentation de dates, pas une garantie sur ces dates. Un diagramme de Gantt qui semble impeccable peut décrire un projet qui va droit dans le mur, simplement parce que les durées saisies sont optimistes. À l’inverse, un diagramme d’apparence brouillonne, avec des barres qui se chevauchent partout, peut décrire un projet parfaitement maîtrisé où plusieurs personnes travaillent effectivement en parallèle. La forme du graphique ne dit rien de la santé du projet.
Ce que le diagramme apporte réellement, c’est une chose qu’aucune liste ne donne : la vision simultanée de la durée et du chevauchement. Sur une liste, deux tâches prévues la même semaine se lisent l’une après l’autre, comme si elles se suivaient. Sur un diagramme, elles apparaissent l’une au-dessus de l’autre, sur la même colonne de dates, et l’on voit immédiatement qu’elles vont mobiliser les mêmes semaines. C’est la seule information que le format ajoute vraiment, et c’est déjà beaucoup quand une petite équipe doit décider ce qu’elle peut tenir.
Le distinguer d’un rétroplanning et d’une simple liste de tâches
Trois documents décrivent le même projet et sont couramment confondus, alors qu’ils ne répondent pas à la même question. La liste de tâches répond à la question du quoi : ce qu’il y a à faire, dans un ordre quelconque, sans notion de durée. Le rétroplanning répond à la question du quand commencer : on part de la date de livraison imposée et on remonte le temps, tâche par tâche, jusqu’à trouver la date à laquelle il faut démarrer pour tenir l’échéance. Le diagramme de Gantt, lui, répond à la question de la simultanéité : il montre ce qui se passe en même temps.
Cette distinction n’est pas académique, elle a une conséquence pratique immédiate. Si vous avez une date de fin imposée par un client et que vous ne savez pas quand démarrer, c’est un rétroplanning qu’il vous faut, pas un diagramme. Si vous savez déjà quand tout commence et que votre vraie question est de savoir si votre équipe pourra absorber la charge de mars, c’est un diagramme qu’il vous faut. Utiliser l’un à la place de l’autre produit un document joli et inutile.
| Document | Ce qu’il montre | Ce qu’il apporte en plus | Ce qu’il déclenche |
|---|---|---|---|
| Liste de tâches | Ce qu’il y a à faire, et qui s’en occupe | Rien sur le temps | La répartition du travail |
| Rétroplanning | La date de démarrage nécessaire pour tenir la fin | Le sens de lecture inversé, depuis l’échéance | La décision de lancer ou de renégocier la date |
| Diagramme de Gantt | La durée de chaque tâche et son chevauchement avec les autres | La simultanéité, lisible d’un coup d’oeil | L’arbitrage sur la charge et sur les priorités d’une période |
Les trois documents peuvent coexister sur un même projet, et c’est même le cas le plus confortable. La liste alimente le diagramme, puisque ce sont les mêmes tâches. Le rétroplanning sert une fois, au lancement, pour fixer la date de démarrage. Le diagramme sert ensuite tout au long du projet, à chaque fois qu’il faut décider si l’on peut accepter une demande supplémentaire sans faire glisser le reste.
Les quatre éléments qui composent un diagramme de Gantt
Un diagramme de Gantt se compose de quatre éléments, et chacun peut manquer sans que le graphique cesse de s’afficher. C’est précisément ce qui rend le format traître : un diagramme incomplet ne signale pas qu’il est incomplet, il s’affiche simplement avec moins de choses dedans.
L’échelle de temps
C’est l’axe horizontal, gradué en jours, en semaines ou en mois. Le choix de la granularité n’est pas cosmétique. Une échelle en mois sur un projet de six semaines écrase tout : les tâches deviennent des traits minuscules et le chevauchement devient illisible. Une échelle en jours sur un projet de deux ans produit un graphique si large que personne ne le fait défiler jusqu’au bout. La bonne granularité est celle qui fait tenir le projet entier sur un écran tout en gardant les barres distinguables.
Les barres de tâches
Chaque barre représente une tâche, son début et sa fin. C’est l’élément central, et le seul qui soit strictement indispensable. Une barre longue ne signifie pas que la tâche est difficile, seulement qu’elle occupe une longue période : une tâche d’une heure étalée sur trois semaines d’attente s’affiche comme une barre de trois semaines, exactement comme une tâche qui mobilise quelqu’un à plein temps pendant trois semaines. Le diagramme mesure du calendrier, pas de l’effort.
Les jalons
Un jalon marque un point de contrôle dans le temps, sans durée. C’est une date à laquelle quelque chose doit être acquis : une validation obtenue, une livraison faite, une décision prise. Sur le graphique, il n’apparaît pas comme une barre mais comme un repère ponctuel. La question de savoir ce qui mérite d’être un jalon et ce qui n’est qu’une tâche importante mérite d’être tranchée avant de dessiner quoi que ce soit, et elle se traite indépendamment du diagramme, comme le montrent les critères de franchissement des jalons de projet.
Les liens de dépendance
Une dépendance relie deux tâches et indique que la seconde ne peut pas commencer avant que la première soit terminée. C’est l’élément que l’on omet en premier, et c’est aussi celui dont l’absence change le plus la nature du document. Nous y revenons en détail plus loin, parce que c’est l’un des deux malentendus majeurs sur ce format.
| Élément | Ce qu’il représente | Ce qui se passe quand il manque |
|---|---|---|
| Échelle de temps | La période couverte par le projet | Impossible, elle est toujours présente, mais une mauvaise granularité rend le graphique illisible |
| Barre de tâche | Le début, la fin et la durée d’une tâche | La tâche n’apparaît pas du tout, le planning paraît plus léger qu’il ne l’est |
| Jalon | Un point de contrôle daté, sans durée | Le projet se lit comme un flux continu, sans moment où l’on décide de continuer ou non |
| Lien de dépendance | L’enchaînement obligatoire entre deux tâches | Le diagramme montre des dates côte à côte, mais aucun retard ne se propage et il n’y a pas de chemin critique |
La règle des deux dates : pourquoi une tâche sans date de début est invisible
Voici le point qui explique les diagrammes de Gantt décevants, et il tient en une phrase : une tâche ne peut être dessinée que si elle possède une date de début et une date de fin. Une barre a besoin d’un point de départ et d’un point d’arrivée sur l’axe du temps. S’il manque l’un des deux, il n’y a rien à tracer, et la tâche n’apparaît pas.
Ce comportement est parfaitement logique, et c’est précisément ce qui le rend dangereux. Le graphique ne signale pas ce qu’il a écarté. Il n’affiche pas de ligne vide, pas d’avertissement, pas de compteur des tâches non représentées. Il dessine ce qu’il peut dessiner, et se tait sur le reste. Vous obtenez donc un planning qui paraît propre, aéré, maîtrisé, alors qu’il est troué. Et comme ce qui manque ne s’affiche pas, personne ne le voit.
Retournez le raisonnement et vous obtenez un outil de contrôle gratuit. Si votre diagramme vous semble étrangement léger par rapport à ce que vous savez du projet, si vous cherchez des yeux une tâche dont vous êtes certain qu’elle est en cours et que vous ne la trouvez pas, ce n’est pas le projet qui est simple : ce sont vos dates qui sont incomplètes. Le diagramme de Gantt n’est pas d’abord un outil de planification, c’est un révélateur de la qualité de votre saisie.
Dans une petite structure, les tâches qui manquent de dates ne sont pas réparties au hasard. Ce sont presque toujours les mêmes profils qui passent à travers : les tâches créées à la volée pendant une réunion, celles qu’on a notées pour ne pas oublier sans savoir encore quand les traiter, celles qui attendent une réponse extérieure et dont on a laissé la date de fin vide en se disant qu’on la mettrait plus tard, et celles que quelqu’un s’est attribuées sans passer par le circuit habituel. Ce sont rarement des tâches sans importance. Ce sont souvent celles qui posent problème.
La correction est mécanique et prend peu de temps. Avant chaque revue de planning, filtrez les tâches du projet sur l’absence de date de début ou de date de fin, et traitez la liste obtenue avant de regarder le diagramme. Deux cas se présentent : soit la tâche a une date qu’on n’avait pas saisie, et on la saisit ; soit elle n’en a réellement pas parce qu’elle dépend d’un événement extérieur, et il faut alors décider consciemment de la laisser hors du planning, en sachant qu’elle en est absente. La différence entre les deux situations est énorme : dans un cas on a un trou involontaire, dans l’autre on a une décision assumée.
Les dépendances : ce que le Gantt montre et ce qu’il ne calcule pas
Le deuxième malentendu est plus subtil, parce qu’il porte sur ce que les gens croient lire. Devant une succession de barres décalées, où chacune commence à peu près là où la précédente s’arrête, l’oeil reconstruit spontanément un enchaînement. On lit une chaîne : d’abord ceci, ensuite cela, donc si le premier glisse, tout le reste glisse. C’est une inférence humaine, pas une propriété du graphique.
Sans liens de dépendance explicitement renseignés, un diagramme de Gantt est une juxtaposition de barres, pas un enchaînement. Chaque barre a été positionnée à la main, par quelqu’un qui a saisi deux dates. Le décalage apparent entre deux tâches ne traduit aucune règle : il traduit seulement le fait que la personne qui a saisi les dates les a choisies ainsi. Rien dans le graphique ne dit qu’une tâche doit attendre l’autre.
Les conséquences sont directes et coûteuses. Si vous décalez une barre de deux semaines parce que la tâche a pris du retard, rien d’autre ne bouge. Les tâches qui, dans la réalité du projet, ne peuvent pas commencer avant celle-là restent affichées à leurs dates initiales, et le diagramme continue d’afficher un calendrier devenu faux. Aucun retard ne se propage automatiquement. Et la notion de chemin critique, cette succession de tâches dont le moindre retard décale la fin du projet, n’existe tout simplement pas : elle se calcule à partir des dépendances, et s’il n’y a pas de dépendance, il n’y a rien à calculer.
Faut-il pour autant renseigner toutes les dépendances ? Dans une petite structure, la réponse est presque toujours non, et pour une raison pratique : les saisir prend du temps, les maintenir en prend encore plus, et un réseau de dépendances mal tenu est plus trompeur qu’un réseau absent. La position raisonnable consiste à ne pas prétendre avoir ce que l’on n’a pas. Si vos dépendances ne sont pas renseignées, alors votre diagramme est un calendrier, et il faut le lire comme un calendrier : il vous dit ce qui est prévu quand, et c’est à vous, humain, de savoir ce qui casse quand une barre bouge.
Ce savoir, dans une petite équipe, existe rarement sur le papier. Il tient dans la tête de la personne qui pilote le projet, et il ne devient visible que lorsqu’un retard survient. C’est exactement ce qui rend utile un travail séparé d’identification de ce qui menace le calendrier, indépendamment du graphique, comme le décrit l’approche de la gestion des risques projet.
Les jalons sur un Gantt : un repère, pas une période
Un jalon n’a pas de durée. C’est une date à laquelle un état doit être atteint, pas une période pendant laquelle on travaille. Cette différence de nature explique pourquoi les jalons s’affichent différemment des tâches : là où une tâche occupe une plage de temps, un jalon occupe un point.
La confusion apparaît quand on transforme en jalon quelque chose qui est en réalité une tâche. Préparer un dossier de recette prend du temps, mobilise quelqu’un, et devrait donc être une barre. Obtenir la validation de ce dossier est un jalon : c’est une décision, elle tombe à une date, elle ne se travaille pas. Si vous inscrivez la préparation comme un jalon, vous perdez la seule chose que le graphique sait faire, montrer la charge sur une période, et vous vous retrouvez avec un projet qui a l’air vide entre deux repères.
L’erreur inverse existe aussi et coûte plus cher. Transformer une décision en barre de trois semaines donne l’impression que la validation est un processus étalé, alors qu’elle est un moment. Le résultat pratique : personne ne sait quel jour il faut relancer le client, puisque le graphique affiche une plage plutôt qu’une échéance. Les jalons servent précisément à créer ces moments où l’on s’arrête, où l’on vérifie et où l’on décide de continuer ou non. C’est ce qui les rend utiles à quiconque prépare un comité de pilotage, puisque ce sont les seuls points du calendrier qui appellent une décision plutôt qu’un simple constat d’avancement.
L’avancement affiché : pourquoi une barre à moitié colorée ne veut pas dire moitié faite
Beaucoup de diagrammes remplissent partiellement les barres pour montrer l’avancement. Une barre à moitié colorée suggère naturellement que la tâche est à mi-parcours. C’est rarement ce que le remplissage signifie, et il vaut la peine de savoir d’où vient ce pourcentage avant de s’appuyer dessus.
Il n’existe que deux origines possibles. Soit quelqu’un a saisi un pourcentage à la main, et dans ce cas la barre affiche une opinion : celle de la personne qui a estimé son propre avancement, avec l’optimisme qui accompagne cet exercice. Soit le pourcentage est déduit automatiquement du statut de la tâche, et dans ce cas il ne prend qu’un petit nombre de valeurs : vide quand la tâche n’a pas démarré, à moitié quand elle est en cours, pleine quand elle est terminée.
Cette seconde mécanique mérite d’être comprise, parce qu’elle produit un effet contre-intuitif. Une tâche commencée ce matin et une tâche qu’il reste une heure à finir affichent exactement le même remplissage : toutes les deux sont en cours, donc toutes les deux à moitié. Le graphique ne fait aucune différence entre elles. Vous pouvez donc avoir un projet dont toutes les barres sont à moitié remplies, ce qui donne une impression rassurante de progression régulière, alors que la moitié des tâches viennent tout juste de démarrer.
La conclusion pratique est simple : ne pilotez pas sur le remplissage des barres. Pilotez sur les dates, qui ne mentent pas. Une tâche dont la date de fin est dépassée et dont le statut n’est pas terminé est un fait, pas une appréciation. Une tâche dont la date de début est passée et dont le statut n’a pas bougé est un fait également. Ces deux signaux se lisent sans interprétation et sans avoir besoin de croire qui que ce soit sur parole.
Construire son premier diagramme de Gantt, étape par étape
La méthode qui suit ne demande aucun outil particulier et se tient en une petite heure pour un projet de taille moyenne. Elle a surtout l’avantage de produire un diagramme qui reste vrai quelques semaines plus tard, ce qui est le vrai critère de réussite.
Commencez par lister les tâches sans penser aux dates. L’erreur classique consiste à dater au fur et à mesure, ce qui pousse à inventer des dates pour des tâches qu’on n’a pas encore vraiment définies. Écrivez d’abord tout ce qu’il y a à faire, à un niveau de découpage où chaque ligne représente entre un et dix jours de travail. Plus fin, vous produirez un graphique illisible. Plus grossier, vous obtiendrez cinq barres énormes qui ne vous apprendront rien.
Estimez ensuite la durée de chaque tâche, séparément de sa date. Durée et date sont deux informations distinctes que l’on confond souvent : une tâche peut durer deux jours de travail et s’étaler sur trois semaines parce qu’on attend une réponse entre les deux. Notez la durée calendaire, celle qui va réellement s’afficher, et pas la charge de travail. Si l’écart entre les deux est important sur beaucoup de tâches, votre vraie question n’est pas le planning mais le plan de charge, qui traite de la répartition de l’effort et non des dates.
Placez alors les dates de début, en partant du début du projet et en avançant. Pour chaque tâche, posez-vous une seule question : qu’est-ce qui doit être fini pour que celle-ci puisse commencer ? Vous n’êtes pas obligé de saisir la dépendance dans l’outil, mais vous devez vous poser la question, parce que c’est elle qui détermine la date. Une tâche que vous placez sans savoir répondre à cette question est une tâche que vous placez au hasard.
Ajoutez les jalons en dernier, et soyez avare. Un projet de trois mois qui compte quinze jalons n’a pas quinze moments de décision, il a une liste de tâches déguisée. Trois à cinq jalons sur un projet de cette taille suffisent : ce sont les moments où, si le résultat n’est pas là, on arrête et on reparle du reste.
Vérifiez enfin que rien ne manque. Cette étape est celle que tout le monde saute, et c’est la seule qui protège du planning troué décrit plus haut. Comparez le nombre de tâches de votre liste et le nombre de barres de votre diagramme. Si les deux nombres diffèrent, la différence correspond exactement aux tâches auxquelles il manque une date.
| Tâche | Date de début | Date d’échéance | Durée en jours | Statut |
|---|---|---|---|---|
| Cadrage du besoin avec le client | 2 mars | 6 mars | 5 | Terminée |
| Rédaction du cahier des charges | 9 mars | 20 mars | 12 | Terminée |
| Validation client du cahier des charges | 23 mars | 27 mars | 5 | En cours |
| Développement du premier lot | 23 mars | 17 avril | 26 | En cours |
| Recette interne du premier lot | 20 avril | 24 avril | 5 | Non démarrée |
| Formation des utilisateurs | 27 avril | 30 avril | 4 | Non démarrée |
Ce tableau mérite d’être lu attentivement, parce qu’il contient une information que le graphique correspondant montrerait immédiatement : la validation client et le développement du premier lot démarrent le même jour. Dans la réalité, développer avant que le cahier des charges soit validé est un pari. Sur une liste de tâches, ce chevauchement passe inaperçu. Sur un diagramme, les deux barres se superposent visuellement et la question se pose d’elle-même.
À quelle fréquence le mettre à jour, et qui doit le tenir
Un diagramme de Gantt qui n’est pas mis à jour devient faux très vite, et un diagramme faux est pire qu’aucun diagramme, parce qu’il fait prendre des décisions sur des dates périmées. La question de la fréquence n’est donc pas une question de confort mais de fiabilité.
Le rythme utile est hebdomadaire, et il ne demande pas une réunion. Il demande qu’une personne, une fois par semaine, ouvre le projet et fasse trois choses : marquer terminées les tâches qui le sont, corriger les dates de fin de celles qui ont visiblement glissé, et repérer celles dont la date de début est passée sans que rien n’ait démarré. Cette opération prend un quart d’heure sur un projet de taille moyenne. Elle n’a pas besoin d’être faite en groupe, et elle est d’ailleurs plus rapide et plus honnête faite seule.
Un rythme mensuel donne une illusion de suivi. Sur un projet de trois mois, une mise à jour mensuelle produit trois photographies, dont la dernière arrive quand le projet est fini. Entre deux photographies, le diagramme affiche des dates qui datent de plusieurs semaines, et l’écart entre l’affichage et la réalité grandit tous les jours sans que personne ne le mesure.
| Point de comparaison | Mise à jour hebdomadaire | Mise à jour mensuelle |
|---|---|---|
| Délai de détection d’un glissement | Une semaine au maximum | Jusqu’à un mois, souvent après coup |
| Capacité à réagir avant l’échéance | Réelle, il reste du temps pour décaler ou renforcer | Faible, l’échéance est souvent déjà passée ou imminente |
| Charge de suivi | Un quart d’heure par semaine, seul, sans réunion | Une session longue, à reconstituer un mois entier de mémoire |
| Fiabilité de ce qui est affiché | Le graphique reflète la semaine en cours | Le graphique reflète un état ancien de plusieurs semaines |
Sur qui doit tenir le diagramme, la réponse pratique est : une seule personne, et de préférence celle qui pilote le projet au quotidien. Un planning tenu par plusieurs mains devient incohérent, parce que chacun corrige selon sa lecture et que personne ne voit l’ensemble. En revanche, cette personne n’a pas à deviner : ce sont les personnes qui font le travail qui savent où elles en sont, et le rôle de celle qui tient le planning est de leur poser la question, pas d’estimer à leur place.
Quand un simple tableau suffit encore, et quand il ne suffit plus
Le diagramme de Gantt n’est pas toujours le bon format, et le choisir trop tôt fait perdre du temps. Un tableau à quatre colonnes, tâche, responsable, échéance, statut, suffit largement tant que trois conditions sont réunies : les tâches se suivent plutôt qu’elles ne se chevauchent, une seule personne ou presque travaille sur le projet, et l’horizon tient dans quelques semaines.
Dans cette configuration, la simultanéité, seule information que le diagramme ajoute, n’a rien à montrer. Si les tâches s’enchaînent les unes après les autres, le graphique affichera un escalier de barres qui ne vous apprendra rien de plus que la liste triée par date. Vous aurez payé un coût de mise en place et de maintenance pour une information nulle.
Le tableau cesse de suffire dès qu’apparaît l’une de ces trois situations. Première situation : plusieurs personnes travaillent en parallèle et vous devez savoir qui est pris quand. Deuxième situation : plusieurs projets se disputent les mêmes personnes, et la question devient de savoir si mars tient debout tous projets confondus. Troisième situation : un client ou une direction demande à voir le calendrier, et une liste de dates ne se lit pas en réunion alors qu’un graphique se comprend en quelques secondes.
Cette troisième situation mérite d’être prise au sérieux, parce qu’elle est souvent la vraie raison pour laquelle on construit un diagramme. Ce n’est pas un défaut. Communiquer un calendrier est un usage légitime, à condition de savoir que c’est celui-là que l’on sert. Un diagramme construit pour être montré et un diagramme construit pour piloter ne demandent pas le même niveau de détail : le premier gagne à rester grossier, le second doit descendre au niveau de la tâche réelle.
Un cas concret : un glissement repéré grâce au chevauchement de deux barres
Prenons le projet du tableau plus haut, une prestation de trois mois avec une formation utilisateur prévue fin avril. Au moment de la mise à jour de la semaine du 23 mars, la personne qui tient le planning constate deux choses banales prises séparément.
Premièrement, la validation client du cahier des charges, prévue du 23 au 27 mars, n’a pas démarré : le client n’a pas encore renvoyé ses retours. Deuxièmement, le développement du premier lot, prévu du 23 mars au 17 avril, a bien démarré comme prévu. Rien d’alarmant dans ces deux constats isolés, et sur une liste de tâches triée par échéance, ils s’affichent à deux endroits différents sans se rencontrer.
Sur le diagramme, les deux barres se superposent visuellement, et la superposition pose immédiatement la question : on développe pendant qu’on attend la validation de ce qu’on développe. Tant que la validation arrive dans les jours qui suivent, le pari est raisonnable. Si elle traîne trois semaines, une partie du développement sera à refaire, et la barre de développement ne s’arrêtera pas le 17 avril.
La personne qui pilote décide donc de ne pas attendre. Elle relance le client le 25 mars en expliquant précisément l’enjeu : chaque jour de retard sur la validation est un jour de développement fait à l’aveugle. La validation arrive le 31 mars, avec quatre jours de retard. Le développement a donc travaillé quatre jours sur une base non validée, ce qui reste absorbable, et la formation de fin avril n’est pas menacée.
Ce qui a rendu cette relance possible n’est pas une alerte automatique, puisqu’il n’y en a pas. C’est le fait d’avoir regardé le graphique, d’avoir vu deux barres se chevaucher, et d’avoir compris ce que ce chevauchement impliquait. Le diagramme n’a rien calculé. Il a simplement montré, sur la même colonne de dates, deux informations qui étaient déjà là mais que personne n’avait mises côte à côte. C’est exactement le service qu’il rend, et c’est aussi le seul.
Cette lecture gagne à être consignée quelque part, parce qu’elle disparaît sinon avec la semaine. Noter ce qui a été vu, ce qui a été décidé et ce que cela a produit constitue la matière du suivi réel du projet, où l’on retrouve les arbitrages plutôt qu’une succession de pourcentages. C’est aussi ce qui relie le graphique au reste de la démarche de gestion de projet, dont il n’est qu’un instrument parmi d’autres.
Les erreurs qui reviennent et comment chacune se corrige
Les difficultés rencontrées avec ce format se ramènent à un petit nombre de causes, et chacune se corrige sans changer d’outil.
| Erreur | Signal visible | Cause probable |
|---|---|---|
| Le planning paraît trop léger | Moins de barres que de tâches dans la liste du projet | Des tâches n’ont pas les deux dates, elles sont donc absentes du graphique |
| On croit lire un enchaînement | Une barre décalée ne décale rien d’autre | Aucune dépendance renseignée, le graphique est un calendrier et non une chaîne |
| Toutes les barres sont à moitié remplies | Le projet semble progresser régulièrement, sans jamais rien terminer | L’avancement est déduit du statut, une tâche à peine commencée s’affiche comme une tâche presque finie |
| Le graphique est illisible | Il faut faire défiler longtemps, ou les barres sont des traits | Découpage trop fin, ou échelle de temps mal choisie par rapport à la durée du projet |
| Le diagramme est faux en réunion | Les dates affichées ne correspondent pas à ce que dit l’équipe | Mise à jour trop espacée, le graphique reflète un état ancien |
| Les jalons ne servent à rien | On les franchit sans jamais s’arrêter | Ce sont des tâches déguisées, sans critère de décision attaché |
Une dernière erreur mérite d’être signalée à part, parce qu’elle ne se voit pas sur le graphique : construire le diagramme une fois, au lancement, pour le dossier, et ne plus jamais l’ouvrir. Un diagramme de Gantt n’a d’utilité que dans la répétition. Celui qui sert une fois est un document de présentation, ce qui est un usage légitime, mais il ne faut pas croire qu’il pilote quoi que ce soit. La différence entre les deux usages tient dans un seul comportement : est-ce que quelqu’un l’ouvre chaque semaine ?
Sur les projets qui mobilisent plusieurs personnes en parallèle, cette relecture hebdomadaire gagne à se faire en regardant le calendrier de l’équipe en même temps que celui du projet, puisque les deux se contredisent régulièrement. Un projet peut être parfaitement planifié et rester intenable si les personnes concernées sont déjà prises ailleurs, ce que seul le planning d’équipe met en évidence.
Le diagramme de Gantt dans Djaboo
Djaboo est un logiciel de gestion tout-en-un pour TPE et PME. Chaque projet y dispose d’un onglet Gantt, et il existe en plus une vue Gantt qui regroupe tous les projets en cours et non démarrés. Chaque tâche y apparaît sous forme de barre : sa date de début donne le début de la barre, sa date d’échéance en donne la fin, et la couleur de la barre dépend du statut de la tâche. Les jalons du projet apparaissent sur la vue du projet, à leur date d’échéance. Ce diagramme est également consultable par le client depuis son portail.
Quatre limites doivent être dites clairement. Une tâche qui n’a pas à la fois une date de début et une date d’échéance n’apparaît pas du tout dans le diagramme. Il n’existe aucun lien de dépendance entre les tâches : le champ existe mais reste vide, donc aucun retard ne se propage et il n’y a pas de chemin critique. L’avancement affiché n’est pas un pourcentage saisi mais une valeur déduite du statut : une tâche terminée s’affiche pleine, une tâche en cours s’affiche à moitié, et toutes les autres s’affichent vides, ce qui signifie qu’une tâche commencée ce matin et une tâche presque finie s’affichent exactement pareil. Enfin, un jalon occupe une seule journée à l’écran, et pas une période.
Ces limites étant posées, deux usages restent parfaitement solides. Le premier consiste à renseigner systématiquement les deux dates sur chaque tâche, sous peine de la rendre invisible : c’est la condition d’entrée dans le diagramme, et elle ne souffre pas d’exception. Le second consiste à se servir du Gantt comme d’un contrôle de saisie plutôt que comme d’un tableau de bord. Une tâche dont vous savez qu’elle est en cours et que vous ne voyez pas sur le diagramme n’est pas une tâche oubliée par l’outil : c’est une tâche mal renseignée, et le graphique vient de vous le signaler gratuitement.
Lu de cette façon, le diagramme cesse d’être un livrable pour devenir un instrument de vérification. Il ne vous dira pas si votre projet va bien, aucun graphique ne le fait. Il vous dira si vos données sont complètes, et c’est la condition pour que tout le reste, les revues, les arbitrages et les relances, repose sur quelque chose de réel.
Un diagramme de Gantt ne montre que ce qui possède deux dates. Il reste donc muet sur tout ce que vous avez oublié de renseigner, et cette absence ne s’affiche nulle part : c’est à vous d’aller la chercher, en comparant le nombre de barres au nombre de tâches réelles du projet.
Et sans liens de dépendance, il montre des dates côte à côte sans jamais dire ce qui casse quand l’une glisse. Déplacer une barre ne déplace rien d’autre. Le graphique vous donne à voir la simultanéité, ce qui est déjà précieux quand une petite équipe doit arbitrer une charge, mais il vous laisse la responsabilité entière de savoir quelles tâches dépendent de quelles autres.
