Pourquoi votre planning Gantt devient peu fiable dès que vos projets partagent les mêmes ressources

Le planning semblait bon

Le planning était propre. Les tâches étaient bien découpées, les dépendances tracées, les durées estimées avec soin. Le chef de projet avait passé du temps dessus.

Trois semaines plus tard, le projet accuse deux semaines de retard.

Pas à cause d'une erreur grossière. Pas à cause d'un événement imprévisible majeur. Mais parce que le développeur principal était aussi sur le projet B. Parce que le designer avait une livraison urgente sur le projet C. Parce que l'expert métier, sollicité pour valider une étape clé, était en déplacement pour le projet D.

Le planning était correct dans son périmètre. Il était aveugle à tout ce qui l'entourait.

C'est la limite fondamentale du diagramme de Gantt dans un environnement multi-projets : il décrit un projet comme s'il existait seul au monde.

Le Gantt fonctionne bien — jusqu'à ce que les projets entrent en compétition

Il faut être précis ici, parce que la nuance compte.

Le diagramme de Gantt est un outil de planification séquentielle. Il représente des tâches dans le temps, leurs dépendances, leurs durées. Pour un projet isolé, avec des ressources dédiées, il remplit parfaitement son rôle : il donne une vision claire de ce qui doit être fait, dans quel ordre, et sur quelle période.

Ce n'est pas un mauvais outil. C'est un outil conçu pour un contexte précis — et ce contexte correspond de moins en moins à la réalité des organisations modernes.

Aujourd'hui, la plupart des équipes gèrent plusieurs projets simultanément, avec les mêmes personnes. Un bureau d'études, une ESN, un département IT, un cabinet de conseil — leurs ressources ne sont pas affectées à un seul projet. Elles naviguent en permanence entre plusieurs priorités, plusieurs chefs de projet, plusieurs délais.

Dans ce contexte, le Gantt individuel de chaque projet reste techniquement cohérent. Mais l'ensemble devient structurellement fragile.

Le vrai problème n'est pas le planning

Quand un projet dérape, la réaction naturelle est de chercher l'erreur dans le planning lui-même : une durée mal estimée, une dépendance oubliée, un risque non anticipé.

C'est parfois vrai. Mais dans les environnements multi-projets, la cause la plus fréquente n'est pas dans le planning — elle est dans ce que le planning ne montre pas.

Ce que le Gantt d'un projet individuel ne montre pas :

• La charge simultanée de chaque ressource sur les autres projets
• Les conflits de priorité entre chefs de projet sur la même personne
• L'impact d'un retard sur un projet A sur la disponibilité des ressources pour le projet B
• Le multitâche forcé et le temps perdu aux transitions

Ces éléments sont invisibles dans un Gantt de projet. Ils sont pourtant la cause principale des retards dans la plupart des organisations qui gèrent plusieurs projets en parallèle.

Les ressources partagées changent tout

Voici un exemple concret pour ancrer le problème.

Projet A : refonte d'une interface client. Durée estimée : 8 semaines. Projet B : intégration d'un nouveau module ERP. Durée estimée : 10 semaines.

Les deux projets démarrent au même moment. Ils partagent trois ressources clés :

• Le développeur senior (Marc) : affecté à 60 % sur A, 40 % sur B dans les plannings respectifs.
• Le designer UX (Sophie) : affecté à 50 % sur A, 50 % sur B.
• L'expert métier (Julien) : sollicité en validation sur A et B, supposément disponible à la demande.

Sur le papier, les deux Gantt sont cohérents. Chaque chef de projet a planifié en tenant compte de la disponibilité partielle des ressources.

Ce que les Gantt ne montrent pas :

La semaine 3, le projet B prend du retard sur une tâche critique. Le chef de projet B sollicite Marc à 80 % pour rattraper. Marc est toujours à 60 % sur A dans le planning de A — mais en réalité, il est surchargé. Il fait les deux en mode dégradé.

La semaine 4, Sophie doit livrer deux maquettes simultanément pour A et B. Elle produit les deux, mais en deux fois plus de temps que prévu — parce qu'elle passe la moitié de son énergie à gérer les allers-retours de contexte entre deux univers graphiques différents.

La semaine 5, Julien est en déplacement pour un client. Les deux projets attendent sa validation. Personne ne l'avait planifié dans les Gantt respectifs — parce que chaque chef de projet supposait qu'il serait "disponible à la demande".

À la semaine 8, le projet A a 3 semaines de retard. Le projet B en a 4. Les deux Gantt initiaux étaient corrects. La réalité du système, elle, n'était pas visible.

Pourquoi le multitâche détruit la fiabilité des plannings

Le multitâche est l'un des destructeurs de planning les plus sous-estimés en gestion de projet.

Quand une ressource alterne entre deux tâches ou deux projets, elle ne produit pas la somme des deux. Elle produit moins, parce que chaque transition entre contextes a un coût réel : le temps de reprendre le fil, de retrouver l'état mental nécessaire, de relire ce qui avait été fait.

Ce coût de transition — appelé context switching dans la littérature sur la productivité — est difficile à quantifier, mais ses effets sont bien documentés. Une ressource qui alterne entre deux tâches complexes peut perdre 20 à 40 % de son temps effectif en transitions seules.

Ce que ça signifie pour le planning :

Une tâche estimée à 5 jours pour une ressource dédiée peut prendre 8 à 9 jours si cette ressource est en multitâche forcé. Le Gantt affiche 5 jours. La réalité livre 8 ou 9.

Et comme les plannings multi-projets sont construits en séquence — la tâche suivante commence à la fin de la précédente — ce glissement initial se propage sur toutes les tâches aval. Un retard de 3 jours sur une tâche peut se transformer en 2 semaines de décalage sur la date de fin.

Les coûts cachés que le Gantt ne comptabilise pas

Au-delà du multitâche, les environnements multi-projets génèrent des coûts invisibles qui n'apparaissent dans aucun planning Gantt.

Le temps d'attente

Quand une ressource est occupée sur un autre projet, les tâches qui en dépendent attendent. Ce temps d'attente n'est pas planifié — il s'insère dans le calendrier sans être visible, et allonge la durée réelle du projet sans que personne ne l'ait anticipé.

La confusion de priorités

Dans un environnement multi-projets sans arbitrage explicite, les ressources reçoivent des demandes de plusieurs chefs de projet en parallèle. En l'absence d'une priorité claire au niveau du portefeuille, elles arbitrent elles-mêmes — souvent en fonction de la pression du moment, pas de l'importance stratégique.

Résultat : les projets les plus "bruyants" avancent, les autres attendent. Ce n'est pas une décision de management — c'est une absence de décision qui se manifeste comme une décision par défaut.

L'optimisation locale

Chaque chef de projet optimise son propre projet. C'est rationnel à son niveau. Mais cette optimisation locale peut dégrader le système global : mobiliser une ressource critique pour avancer sur un projet peu prioritaire, au détriment d'un projet stratégique.

Les goulets invisibles

Dans un portefeuille de projets, certaines ressources sont des contraintes systémiques : elles limitent le débit de l'ensemble. Un expert rare, une équipe sous-dimensionnée, un validateur incontournable. Si personne n'a de vue sur la charge de ces ressources à l'échelle du portefeuille, le goulet reste invisible — et continue de ralentir tous les projets qui en dépendent.

Le planning est statique, mais le système est dynamique

Un diagramme de Gantt est une photographie. Il représente une réalité à un instant donné : les ressources disponibles, les durées estimées, les dépendances connues.

Mais un portefeuille de projets est un système vivant. Les ressources changent de disponibilité. Les priorités se modifient. Des tâches prennent plus de temps que prévu. De nouveaux projets arrivent en cours de route et se disputent les mêmes ressources.

Le Gantt, lui, ne se met pas à jour automatiquement pour refléter ces réalités. Il reste la photographie initiale — de plus en plus décalée par rapport à ce qui se passe réellement.

Le problème de la mise à jour manuelle

Dans les organisations qui gèrent de nombreux projets, maintenir les Gantt à jour est une activité à part entière. Et souvent, cette mise à jour est incomplète, tardive, ou abandonnée sous la pression du quotidien. Les plannings affichés ne reflètent plus la réalité — mais les décisions continuent d'être prises en s'appuyant dessus.

C'est peut-être la limite la plus sérieuse : non pas que le Gantt soit structurellement faux, mais qu'il soit structurellement en retard sur la réalité dans les environnements dynamiques.

Pourquoi les retards se propagent plus vite en environnement multi-projets

Dans un projet isolé, un retard sur une tâche peut être absorbé : on récupère sur une autre tâche, on replanifie, on arbitre localement.

Dans un environnement multi-projets à ressources partagées, le même retard a un effet multiplicateur.

La mécanique de propagation :

1. La tâche T1 du projet A prend 3 jours de retard.
2. La ressource R, qui devait démarrer T2 sur le projet B après T1, est retardée de 3 jours.
3. T2 sur B alimente T3 sur B, qui alimente T4 sur B — le retard se propage.
4. Pendant ce temps, R était aussi attendue sur T5 du projet C la semaine suivante — ce projet est maintenant retardé avant même d'avoir commencé sa phase critique.

Ce n'est pas une situation exceptionnelle. C'est la dynamique normale d'un portefeuille de projets à ressources partagées, sans mécanisme de protection ni de priorité explicite.

Et cette propagation est invisible dans les Gantt individuels — parce que chaque Gantt ne voit qu'un projet à la fois.

Ce que les managers de projets ont vraiment besoin de voir

Après avoir décrit ce qui casse, posons la question utile : qu'est-ce qu'un manager opérationnel, un PMO, ou un dirigeant a réellement besoin de voir pour piloter un portefeuille de projets ?

La charge réelle des ressources clés

Pas leur affectation théorique projet par projet, mais leur charge consolidée sur l'ensemble du portefeuille. Qui est surchargé ? Qui est sous-utilisé ? Qui est la ressource contrainte qui ralentit tout le reste ?

Les priorités explicites entre projets

Quand une ressource ne peut pas tout faire en même temps, il faut décider quel projet passe en premier. Cette décision ne peut pas être laissée à la discrétion de la ressource elle-même, ni se résumer au projet dont le chef de projet est le plus insistant. Elle doit être une décision de management, explicite et connue de tous.

La santé globale du portefeuille, pas le statut de chaque tâche

Dans un portefeuille de 8 projets, personne ne peut suivre l'avancement de chaque tâche. Ce dont les décideurs ont besoin, c'est d'une lecture synthétique : quels projets sont sains, quels projets sont sous tension, où se concentre le risque.

Les signaux d'alerte avant le retard

La plupart des systèmes de reporting projet signalent les retards quand ils sont déjà là. Ce qu'il faut, c'est les voir venir : une ressource qui s'approche de la surcharge, un buffer qui se consomme plus vite que l'avancement ne progresse, une tâche critique qui attend depuis trop longtemps.

Une meilleure approche : priorités, contraintes et flux

Il ne s'agit pas ici de proposer une méthode magique. La complexité des environnements multi-projets ne disparaît pas parce qu'on change d'outil ou de méthode.

Mais il existe des approches qui ont été précisément conçues pour ce contexte — et qui adressent les angles morts du Gantt individuel.

Raisonner en contrainte, pas en tâche

La gestion de projet par la chaîne critique (Critical Chain Project Management, CCPM) part d'un principe différent : au lieu de planifier toutes les tâches en parallèle et d'espérer que les ressources suivront, on identifie d'abord la contrainte — la ressource ou la séquence de tâches qui détermine réellement la durée du projet — et on organise le planning autour d'elle.

Dans un environnement multi-projets, cela signifie aussi identifier la ressource contrainte à l'échelle du portefeuille : quel est le goulot qui limite le débit de l'ensemble ?

Protéger le flux plutôt que les dates individuelles

Dans une approche classique, on surveille si chaque tâche respecte sa date. Dans une approche orientée flux, on surveille si la contrainte avance — et si la marge de sécurité (le buffer) est consommée de façon proportionnelle à l'avancement.

C'est le principe du fever chart : un indicateur simple qui synthétise la santé d'un projet en deux variables — avancement et consommation du buffer — plutôt qu'en centaines de lignes de Gantt.

Établir une priorité explicite au niveau du portefeuille

La priorité entre projets ne peut pas être implicite dans un environnement multi-projets. Elle doit être affichée, connue de toutes les ressources, et stable — ou du moins cohérente dans ses changements.

Sans cette priorité explicite, les ressources arbitrent elles-mêmes. Et leur arbitrage, rationnel à leur niveau, peut être incohérent à l'échelle du portefeuille.

Limiter les projets actifs simultanément

L'une des intuitions les plus contre-intuitives de la gestion de projet moderne : lancer moins de projets en même temps permet souvent de les livrer plus vite tous.

Quand le portefeuille est surchargé, toutes les ressources sont en multitâche, tous les projets avancent lentement, et aucun ne finit à temps. En limitant le nombre de projets actifs simultanément à la capacité réelle du système — en particulier à la capacité de la ressource contrainte — les projets en cours avancent plus vite, et les projets en attente démarrent dans de meilleures conditions.

Quand le Gantt garde toute sa pertinence

Cette analyse ne doit pas être lue comme une condamnation du Gantt. Ce serait inexact et peu utile.

Le diagramme de Gantt reste un outil pertinent dans plusieurs contextes :

Projets à ressources dédiées. Quand une équipe est entièrement affectée à un seul projet pendant sa durée, le Gantt décrit fidèlement la réalité. Les conflits de ressources inter-projets n'existent pas.

Phase de cadrage et de communication. Pour présenter la structure d'un projet, communiquer sur la séquence des livrables, ou aligner les parties prenantes sur les grandes phases, le Gantt est un outil de communication efficace et universellement compris.

Projets courts et séquentiels. Sur des projets de 2 à 4 semaines avec une équipe stable, la dynamique multi-projets n'a pas le temps de produire ses effets. Le Gantt suffit.

Support à la planification initiale. Avant même de parler de ressources et de contraintes, structurer la logique d'un projet — quelles tâches, dans quel ordre, avec quelles dépendances — est une étape nécessaire. Le Gantt est un outil adapté pour cela.

La limite n'est pas dans l'outil lui-même. Elle est dans l'usage qu'on en fait comme instrument de pilotage unique dans des environnements pour lesquels il n'a pas été conçu.

Ce que ça change concrètement

Questions fréquentes