Tout débat sur la gestion de projet finit par retomber sur la même question : faut-il suivre le travail avec un tableau de cartes qui circulent ou avec une timeline et des dépendances ? Kanban et Gantt sont les deux archétypes, et se tromper de méthode est une taxe silencieuse sur toute l'équipe : soit tu traînes des barres sur un diagramme auquel plus personne ne croit, soit tu fixes un tableau incapable de te dire si tu tiendras la deadline.
Voici comment chaque méthode fonctionne vraiment, où chacune gagne, et un guide de décision applicable en cinq minutes.
Kanban vs Gantt : quelle est la vraie différence ?
Version courte : Kanban gère le flux, Gantt gère le temps. Kanban répond à « qu'est-ce qui est en cours et où est-ce que ça bloque ? ». Gantt répond à « qu'est-ce qui se passe quand, et qu'est-ce qui dépend de quoi ? ». Tout le reste découle de cette distinction.
Kanban : né dans les usines Toyota
Kanban (« panneau » en japonais) est apparu à la fin des années 1940 chez Toyota, où l'ingénieur Taiichi Ohno a conçu un système de cartes pour signaler quand réapprovisionner les pièces. Au lieu de pousser du stock en aval sur la base de prévisions, chaque poste tirait le travail seulement quand il avait de la capacité. Dans les années 2000, David Anderson a adapté l'idée aux équipes logicielles, et le tableau Kanban numérique était né.
Trois principes définissent le vrai Kanban — pas juste « des colonnes avec des post-its » :
- Visualiser le flux. Chaque tâche est une carte, chaque étape une colonne (ex. Backlog → En cours → Revue → Terminé). Les problèmes deviennent visibles : un embouteillage dans « Revue », c'est un goulot d'étranglement qu'on repère à trois mètres.
- Limiter le travail en cours (WIP). Chaque colonne a un maximum. Si « En cours » est plafonné à 3 et contient 3 cartes, personne ne démarre une nouvelle tâche : on aide à finir celles en cours. C'est ce mécanisme qui accélère réellement la livraison : moins de multitâche, moins de changements de contexte, des cycles plus courts.
- Tirer, ne pas pousser. Le travail n'entre dans une étape que quand celle-ci a de la capacité libre — exactement comme les bacs de pièces de Toyota.
Tu peux monter un tableau avec limites WIP en une minute avec le Kanban Board gratuit.
Gantt : un siècle de timelines
Le diagramme de Gantt précède Kanban de plusieurs décennies : Henry Gantt l'a popularisé vers 1910–1915, et il a piloté des méga-projets, du barrage Hoover au réseau autoroutier américain. Il reste la colonne vertébrale du BTP, de l'événementiel et de tout lancement avec une date ferme.
Un diagramme de Gantt représente les tâches comme des barres horizontales sur un calendrier :
- Les barres montrent la date de début, la durée et la date de fin de chaque tâche.
- Les dépendances relient les tâches : « le design doit être terminé avant que le développement démarre ». Décale une date, et les barres en aval se décalent avec.
- Le chemin critique est la chaîne de tâches dépendantes qui détermine la date de fin la plus proche possible. Tout retard sur le chemin critique retarde le projet entier ; la marge ailleurs ne compte pas.
- Les jalons marquent les points fixes : contrat signé, salle réservée, version livrée.
Si ton projet a une vraie deadline et de vraies contraintes de séquencement, un Gantt Chart est la seule vue qui te dit si le plan est seulement faisable.
Comparatif face à face
| Critère | Kanban | Gantt |
|---|---|---|
| Question centrale | Qu'est-ce qui circule, qu'est-ce qui bloque ? | Qu'est-ce qui se passe quand ? |
| Flexibilité | Très haute — repriorise à tout moment | Faible — chaque changement se propage |
| Deadlines fermes | Faible — pas de vue « date de fin » native | Excellent — c'est sa raison d'être |
| Dépendances | Non modélisées | Explicites, avec chemin critique |
| Taille d'équipe idéale | 1–10, travail continu | Toutes tailles, mais il faut un responsable du plan |
| Courbe d'apprentissage | Quelques minutes | Quelques heures (dépendances, chemin critique) |
| Coût de maintenance | Quasi nul — on déplace les cartes en travaillant | Réel — les dates doivent rester à jour |
| Échec typique | Le tableau devient un dépotoir | Le diagramme est abandonné au bout de deux semaines |
Lequel choisir ? Guide de décision
Choisis Kanban quand le travail est un flux continu
Si les demandes arrivent en permanence et qu'il n'y a pas de « date de fin » unique — file de support, pipeline de contenu, tri de bugs, maintenance, gestion perso des tâches — Kanban s'impose naturellement. Le travail ne « se termine » jamais : il circule. Pose-toi la question : « Ce tableau servira-t-il encore dans six mois, avec d'autres cartes dessus ? » Si oui, tu es en territoire Kanban.
Choisis Gantt quand la deadline et les dépendances sont réelles
Si le projet a une date de fin fixe et des tâches qui se bloquent réellement entre elles — lancement produit, conférence, migration de site, chantier — il te faut une timeline. Demande-toi : « Si la tâche B démarre avant la fin de la tâche A, est-ce que quelque chose casse ? » Si oui, tu as des dépendances, et un tableau de cartes ne peut pas t'en protéger.
Utilise les deux (la réponse honnête pour beaucoup d'équipes)
Les équipes matures fonctionnent souvent en hybride : un Gantt pour le plan macro (phases, jalons, chemin critique sur plusieurs mois) et un Kanban pour l'exécution micro (les tâches de la semaine qui filent vers « Terminé »). Le Gantt répond aux parties prenantes ; le Kanban anime le daily. Garde juste une seule source de vérité par niveau : les jalons vivent sur la timeline, les tâches vivent sur le tableau.
Les erreurs classiques avec chaque méthode
Erreurs Kanban
- Pas de limite WIP. Un tableau Kanban sans limites WIP, c'est juste une to-do list déguisée. La limite est la méthode — sans elle, tout est « en cours » et rien ne sort.
- Des colonnes qui ne collent pas à la réalité. Si le travail passe réellement par une phase de QA mais que ton tableau n'a pas de colonne QA, le tableau ment.
- Le backlog-cimetière. 200 cartes dans « Backlog », ce n'est pas un plan, c'est du stockage de culpabilité. Élague sans pitié.
Erreurs Gantt
- Le mettre à jour une fois, puis l'abandonner. Le grand classique. Un Gantt dessiné au kickoff et jamais retouché devient de la fiction dès la troisième semaine — pire que pas de diagramme du tout, parce que les gens lui font encore confiance. Bloque 15 minutes par semaine pour mettre à jour le réel.
- La fausse précision. Estimer une tâche à « 3,5 jours » quatre mois à l'avance, c'est de l'astrologie. Raisonne en fourchettes et garde de la marge sur le chemin critique.
- Des dépendances partout. Si chaque tâche est reliée à toutes les autres, le diagramme devient un plat de spaghettis illisible. Ne modélise que les relations bloquantes.
Et pour les projets solo ?
Les deux méthodes se réduisent étonnamment bien à une seule personne :
- Le Kanban solo est excellent pour les freelances qui jonglent entre clients : un tableau, une limite WIP de 2–3, et tu viens de soigner ton propre multitâche.
- Le Gantt solo brille pour tout ce qui a une date : organiser un mariage, écrire un mémoire, lancer un side project. Voir que « la salle doit être réservée 6 semaines avant les invitations » est une dépendance qu'aucune liste ne te montrera.
- Pour la granularité à la journée, complète l'un ou l'autre avec une simple To-Do List pour les tâches du jour et un Agenda pour les engagements horodatés.
En résumé
Ne choisis pas ta méthode par effet de mode — choisis-la selon la forme de ton travail. Flux continu → Kanban. Deadline fixe avec dépendances → Gantt. Gros projet avec exécution continue → les deux. Et quelle que soit ton option, respecte sa règle non négociable : limites WIP pour Kanban, mise à jour hebdo pour Gantt.
Prêt à essayer ? Lance un Kanban Board gratuit ou trace ta timeline avec le Gantt Chart — les deux tournent directement dans ton navigateur. Aucun compte requis.