Diagramme de Gantt vs Kanban

« Faut-il utiliser un diagramme de Gantt ou un tableau Kanban ? » est une question posée comme si les deux étaient des marques rivales d'une même chose. Ce n'est pas le cas. Ils répondent à des questions différentes, et les frictions ressenties par les équipes viennent généralement du fait de forcer l'un à faire le travail de l'autre. Un diagramme de Gantt est un plan déployé dans le temps. Un tableau Kanban est une vue du travail tel qu'il circule à travers ses étapes. Une fois qu'on les voit ainsi, le choix — et l'intérêt d'utiliser les deux — devient beaucoup plus clair.

Ce qu'est un diagramme de Gantt

Un diagramme de Gantt place les tâches sur un calendrier. Chaque tâche est une barre dont la position et la longueur indiquent quand elle a lieu et combien de temps elle dure, et des flèches entre les barres indiquent les dépendances : ce qui doit attendre quoi. Sa seule raison d'être est de répondre à des questions de temps : quand cela se terminera-t-il, qu'est-ce qui se chevauche, et quelle tâche en retard entraîne le reste avec elle. C'est fondamentalement un outil pour planifier à l'avance et s'engager sur un enchaînement.

Ce qu'est Kanban

Un tableau Kanban est un ensemble de colonnes représentant les états que traverse un travail — classiquement À faire, En cours, Terminé, même si les tableaux réels ajoutent des étapes comme Révision ou Bloqué. Chaque tâche est une carte, et gérer le travail consiste à déplacer les cartes vers la droite au fur et à mesure de leur avancement. Kanban est issu du système de production de Toyota et a été adapté au travail intellectuel à la fin des années 2000. Ses idées centrales sont visualiser le flux et limiter le travail en cours (WIP) : on plafonne le nombre de cartes pouvant se trouver dans une colonne à la fois, ce qui oblige l'équipe à terminer des tâches avant d'en commencer de nouvelles. Kanban se soucie peu des dates. Il se soucie du flux, du débit, et de ne pas surcharger les personnes.

Comparaison côte à côte

	Diagramme de Gantt	Tableau Kanban
Organisé par	Temps (un axe calendaire)	État (colonnes d'étapes de travail)
Meilleure question à laquelle il répond	Quand cela sera-t-il terminé, et dans quel ordre ?	Sur quoi travaille-t-on en ce moment, et qu'est-ce qui est bloqué ?
Dépendances	Indiquées explicitement par des flèches	Largement invisibles
Gère le changement en	Replanifiant le calendrier	Repriorisant la prochaine carte
Le plus efficace pour	Échéances fixes, séquence connue	Travail continu et évolutif
Effort pour rester à jour	Plus élevé — les dates demandent un entretien	Plus faible — il suffit de déplacer les cartes

Ce en quoi chacun excelle vraiment

Le diagramme de Gantt l'emporte sur la prévision. Si votre projet a une échéance réelle et des tâches qui dépendent les unes des autres, rien ne vaut un diagramme de Gantt pour voir la forme de l'ensemble avant de commencer. Il fait apparaître le chemin critique — la chaîne de tâches qui détermine la date de fin — pour que vous sachiez où un retard fait vraiment mal. C'est aussi le meilleur outil pour communiquer un plan à quelqu'un en dehors de l'équipe : un sponsor comprendra un diagramme de Gantt en quelques secondes et ne lirait jamais un tableau de quarante cartes.

Kanban l'emporte sur le présent. Pour un travail continu où les priorités changent semaine après semaine — une file de support, un flux de contenu, un arriéré de maintenance —, Kanban demande bien moins d'effort et se révèle bien plus honnête. Il n'y a aucun calendrier à entretenir, ni aucune fiction consistant à prétendre savoir ce que l'on fera dans six semaines. Les limites de WIP font quelque chose qu'un diagramme de Gantt ne peut pas faire : elles empêchent activement une équipe de commencer plus qu'elle ne peut en terminer, ce qui est la cause la plus courante de voir tout être « en cours » sans que rien ne soit fait.

Ce dernier point mérite un exemple concret. Imaginez une équipe de quatre personnes avec onze choses « en cours » — tout le monde est occupé, et rien n'est livré, car chaque tâche attend quelqu'un qui est déjà accaparé par trois autres. Fixez une limite de WIP de, disons, cinq cartes sur la colonne En cours, et la dynamique s'inverse : avant que quiconque puisse prendre une nouvelle carte, une carte existante doit être terminée et avancer. La capacité inoccupée se retrouve dirigée vers le déblocage plutôt que vers le démarrage d'une énième tâche. Un diagramme de Gantt n'a pas de levier équivalent : il vous montrera bien volontiers onze barres qui se chevauchent et appellera cela un plan.

Là où chacun montre ses limites

Un diagramme de Gantt peine lorsque le plan n'est pas prévisible. Un travail exploratoire, guidé par la recherche, ou qui change rapidement, tourne en dérision un calendrier détaillé : on passe plus de temps à redessiner les barres qu'à faire le travail, et les dates assurées du diagramme deviennent un handicap. Il se périme aussi dès que l'on cesse de le mettre à jour ; un plan tracé une fois puis abandonné est de la décoration, pas de la gestion.

Kanban peine lorsque le temps et l'ordre des opérations comptent vraiment. Un tableau vous montrera bien volontiers une colonne de cartes sans aucun indice que trois d'entre elles doivent se produire dans un ordre précis, ou qu'une échéance incontournable arrive dans deux semaines. Les dépendances sont largement invisibles sur un tableau Kanban, et « quand cela sera-t-il terminé ? » est une question à laquelle il ne répond qu'avec des statistiques de débit passé, pas avec une date que l'on peut inscrire dans un contrat. Pour un projet avec une date de lancement et un réseau de prérequis, un tableau seul vous laissera filer devant les problèmes sans les voir venir.

Utiliser les deux ensemble

Le schéma mature adopté par de nombreuses équipes consiste à les faire fonctionner à des altitudes différentes. Le diagramme de Gantt porte le plan : les phases, les jalons, les dépendances, l'échéance — la carte de la direction que prend le projet sur le prochain trimestre. Le tableau Kanban fait tourner les journées : la tranche de ce plan pour la quinzaine en cours, découpée en cartes que l'équipe fait avancer entre À faire, En cours et Terminé. Le diagramme de Gantt répond à « sommes-nous dans les temps pour le lancement ? » ; le tableau répond à « que fait chacun aujourd'hui ? ».

Concrètement : une équipe logicielle pourrait tenir son plan de sortie sous forme de diagramme de Gantt — conception, construction, tests, livraison, avec les dépendances et la date de sortie déjà tracées — pendant que les développeurs travaillent entièrement à partir d'un tableau Kanban, sans jamais toucher au diagramme au jour le jour. Lors du point hebdomadaire, l'avancement du tableau est reporté dans le diagramme pour vérifier que l'échéance tient toujours. Un projet de construction, en revanche, vit bien davantage du côté de Gantt, car la séquence est rigide et des fondations retardées ne peuvent tout simplement pas être repriorisées. Une équipe marketing qui mène des campagnes continues pourrait vivre presque entièrement sur Kanban, ne se tournant vers un diagramme de Gantt que lorsqu'apparaît un lancement avec une date incontournable.

Alors, lequel utiliser ?

S'il faut n'en choisir qu'un, choisissez selon la nature du travail, pas selon vos goûts. Piloté par les échéances, riche en dépendances, à expliquer aux parties prenantes — Gantt. Fluide, évolutif, centré sur le débit — Kanban. Mais méfiez-vous du raisonnement « l'un ou l'autre ». Ils sont complémentaires précisément parce qu'ils sont différents : l'un est le plan, l'autre est l'exécution. Les équipes qui peinent sont généralement celles qui utilisent un tableau pour gérer un projet à échéance, ou un diagramme de Gantt pour gérer un flux sans fin définie. Adaptez l'outil à la question, et les deux deviennent un plaisir à utiliser.

Questions fréquentes

Peut-on utiliser un diagramme de Gantt et un tableau Kanban en même temps ?

Oui, et c'est ce que font de nombreuses équipes. Le schéma courant consiste à conserver le plan global — phases, jalons, dépendances, échéance — dans un diagramme de Gantt, et à gérer le travail au quotidien sur un tableau Kanban. Le diagramme répond à « sommes-nous dans les temps ? » ; le tableau répond à « que faisons-nous maintenant ? ».

Kanban est-il meilleur qu'un diagramme de Gantt pour les équipes Agile ?

Pour un travail continu, basé sur le flux et aux priorités changeantes, Kanban convient généralement mieux aux équipes Agile car il n'y a pas de calendrier fixe à entretenir. Mais même les équipes Agile se tournent vers un diagramme de Gantt lorsqu'il existe une échéance externe incontournable ou un plan de sortie avec de réelles dépendances à communiquer.

Un tableau Kanban montre-t-il les dépendances ?

Pas naturellement. Un tableau montre l'état de chaque tâche mais indique peu de choses sur les tâches qui doivent se produire avant d'autres, ou sur le moment où elles doivent se produire. Si la séquence et les dates comptent pour votre projet, c'est exactement là qu'un diagramme de Gantt trouve sa place aux côtés du tableau.

Lequel est le plus facile à tenir à jour ?

Un tableau Kanban, en général — le mettre à jour revient simplement à glisser une carte vers la colonne suivante. Un diagramme de Gantt demande plus d'entretien, car les durées et les dates doivent être ajustées à mesure que la réalité évolue, ce qui est le prix de la prévision qu'il vous offre.