Comment gérer plusieurs projets en même temps avec une équipe partagée

Le lundi matin d'un dirigeant d'agence

Huit heures trente. Quatre projets ouverts sur l'écran. Une directrice artistique sollicitée par trois chefs de projet différents avant même d'avoir fini son café. Un client qui rappelle pour une livraison promise vendredi. Un autre projet qui devait démarrer cette semaine et dont personne n'a encore eu le temps de s'occuper.

Ce n'est pas une situation exceptionnelle. Pour la plupart des dirigeants de PME, c'est simplement le lundi.

La question n'est pas de savoir si vous gérez bien ou mal vos projets. La question est de savoir si vous avez les bons outils pour décider quand tout le monde est sollicité en même temps.

Tout le monde est occupé

Et pourtant les projets n'avancent pas assez vite. Le problème n'est pas le manque d'effort.

Pas de visibilité globale

Chaque chef de projet défend son projet. Personne n'a la vue d'ensemble pour arbitrer.

Les arbitrages se font à l'instinct

On répond à la pression du moment, pas à la priorité réelle. Les décisions sont réversibles mais coûteuses.

Ce guide est conçu pour les dirigeants qui gèrent plusieurs projets avec la même équipe et qui cherchent une méthode concrète, pas de la théorie. Il couvre les trois niveaux du problème : le diagnostic (pourquoi ça déraille), l'organisation opérationnelle (comment s'organiser différemment), et le framework de décision (comment arbitrer quand il faut choisir).

Partie 1 — Diagnostic : ce qui déraille vraiment

Le problème n'est pas le nombre de projets

La première erreur est de croire que le problème vient du nombre de projets. En réalité, deux projets mal organisés peuvent générer autant de chaos que six projets bien pilotés.

Ce qui crée la tension, c'est le fait que les mêmes personnes travaillent sur tout en même temps, sans priorité explicite entre les projets. Résultat : personne ne peut se concentrer vraiment sur quoi que ce soit, et chaque projet avance à mi-régime.

Prenons l'exemple d'une agence de communication de douze personnes. Elle gère en parallèle :

• la refonte du site d'un client institutionnel
• une campagne de lancement pour une marque retail
• la production de contenus récurrents pour deux autres clients
• la préparation d'un salon professionnel

Le directeur artistique intervient sur les quatre projets. Le développeur front-end est partagé entre la refonte et les intégrations de la campagne. La cheffe de projet jongle entre les quatre chefs de file client.

Sur le papier, chaque projet a son planning. En pratique, personne ne sait vraiment dans quel ordre travailler quand une même journée concentre des demandes contradictoires.

Les trois mécanismes qui font déraper le portefeuille

Ces mécanismes ne sont pas des fautes de management. Ce sont des effets structurels qui apparaissent dès que les ressources sont partagées.

Le multitâche forcé

Quand une personne alterne entre plusieurs projets dans la même journée, elle ne produit pas la somme des deux. Chaque transition entre contextes — entre la campagne retail et la refonte institutionnelle, par exemple — consomme de l'énergie mentale, génère des erreurs et ralentit l'avancement réel.

Eliyahu Goldratt, dans Critical Chain (1997), a montré que le multitâche non maîtrisé est l'une des causes principales des retards projet. Ce n'est pas que les équipes travaillent mal, c'est qu'elles travaillent sur trop de choses à la fois.

Une ressource en multitâche forcé peut perdre entre 20 et 40 % de son temps effectif en transitions seules. C'est du temps qui n'apparaît dans aucun reporting, mais qui explique pourquoi les projets glissent sans que personne ne soit vraiment fautif.

La priorisation implicite

En l'absence d'une priorité claire au niveau du portefeuille, les membres de l'équipe arbitrent eux-mêmes entre les demandes concurrentes. Ils répondent à la pression du moment : le client le plus insistant, le chef de projet le plus présent, l'urgence la plus visible.

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. Et cette priorisation implicite est rarement cohérente avec ce qui compte vraiment pour l'entreprise.

Les dépendances invisibles entre projets

Dans un portefeuille, un retard sur un projet peut bloquer un autre projet sans que personne ne le voit venir. Le directeur artistique mobilisé à 100 % sur la campagne de lancement n'est plus disponible pour valider les maquettes de la refonte. La refonte accumule deux semaines de retard — non pas à cause d'une erreur, mais à cause d'une dépendance que personne n'avait rendue visible.

Les diagrammes de Gantt individuels ne capturent pas ces tensions. Chaque projet semble cohérent dans son propre planning. C'est l'ensemble qui est fragile.

Partie 2 — Organisation opérationnelle : ce qui doit changer

Règle 1 — Limiter le nombre de projets actifs simultanément

La règle la plus contre-intuitive de la gestion de portefeuille est aussi la plus efficace : lancer moins de projets en même temps.

Tant que tous les projets sont « actifs », les ressources sont dispersées sur tout et ne terminent rien. En réduisant le nombre de projets réellement en cours, on concentre les ressources, on accélère chaque projet individuel, et on livre plus régulièrement.

Le nombre de projets actifs simultanément doit être calibré sur la capacité réelle de la ressource la plus contrainte, pas sur le nombre de projets disponibles ou sur la demande des clients.

Dans notre agence, si le directeur artistique peut gérer sérieusement deux projets en parallèle, c'est le plafond. Le troisième projet attend que l'un des deux soit livré avant de démarrer.

Ce que KairoProject apporte ici : la vue charge ressources permet de voir en temps réel quelles personnes sont en surcharge, sur quels projets, et depuis combien de temps. Elle indique immédiatement si le goulot est saturé et sur quel projet il serait plus pertinent de concentrer sa capacité.

Règle 2 — Rendre la priorité explicite et connue de tous

La priorisation implicite coûte cher. Elle génère des conflits, des décisions incohérentes, et une charge mentale permanente pour les membres de l'équipe qui ne savent jamais sur quoi se concentrer en premier.

La priorité entre projets doit être :

• explicite : écrite, affichée, connue de tous
• stable : elle ne change pas à chaque réunion ou à chaque appel client
• fondée sur des critères objectifs, pas sur la pression du moment

Les critères objectifs les plus fiables pour décider de la priorité entre projets sont :

1. 1
   La contrainte commerciale ou contractuelle : quel projet a les conséquences les plus importantes en cas de retard ?
2. 2
   La tension sur la marge de sécurité : quel projet consomme sa marge trop vite par rapport à son avancement réel ?
3. 3
   La ressource contrainte : quel projet bloque la ressource qui limite l'avancement de tout le portefeuille ?

Une fois la priorité décidée, elle s'applique de façon simple : quand une ressource ne peut pas tout faire en même temps, elle commence par le projet prioritaire. C'est tout.

Ce que KairoProject apporte ici : dès la connexion, le dashboard affiche quel projet mérite l'attention en priorité, avec la cause identifiée — ressource bloquante, buffer consommé, tâche en attente. Ce n'est pas une liste à interpréter, c'est une recommandation d'action directe.

Règle 3 — Suivre l'avancement en flux, pas en pourcentage

Le reporting classique demande à chaque chef de projet un pourcentage d'avancement. Ce pourcentage est rarement fiable : il est souvent estimé à la louche, il ne dit pas où se situe le risque réel, et il ne permet pas de comparer les projets entre eux de façon significative.

Ce qui compte pour piloter un portefeuille, ce n'est pas de savoir qu'un projet est « à 60 % » — c'est de savoir si ce projet avance normalement ou s'il est en train de dériver.

Pour cela, deux données suffisent :

• la progression réelle du projet (quelle part du travail est faite ?)
• la consommation de la marge de sécurité (quelle part du buffer a été utilisée ?)

Un projet à 60 % d'avancement qui a consommé 80 % de son buffer est en danger. Un projet à 40 % d'avancement qui n'a consommé que 25 % de son buffer est en bonne santé. La comparaison entre ces deux données — c'est ce que représente le fever chart — est beaucoup plus parlante qu'un simple pourcentage.

Pour comprendre en détail le fonctionnement du fever chart et son interprétation, le guide dédié explique comment l'utiliser au quotidien.

Ce que KairoProject apporte ici : chaque membre de l'équipe met à jour son propre temps restant estimé — pas un chef de projet central qui consolide les données. Cette mise à jour décentralisée produit une information plus fiable et plus récente, sans générer de charge administrative supplémentaire. Le fever chart se met à jour en temps réel et positionne chaque projet dans une zone verte, orange ou rouge.

Règle 4 — Protéger les ressources contraintes du multitâche

Une fois la ressource contrainte identifiée — le directeur artistique, le développeur senior, l'expert technique — la règle est simple : elle ne doit pas être en multitâche forcé.

Concrètement, cela signifie :

1. 1
   Affecter à cette ressource une seule tâche prioritaire à la fois
2. 2
   Ne pas l'interrompre pour des demandes non prioritaires
3. 3
   Laisser les autres tâches en file d'attente plutôt que de les traiter en parallèle
4. 4
   Valider que la tâche est terminée avant d'en démarrer une nouvelle

Ce principe peut sembler rigide. En pratique, il réduit significativement le temps de livraison de chaque projet — parce que la ressource contrainte avance de façon fluide au lieu de s'éparpiller.

Ce que KairoProject apporte ici : la vue ressources identifie automatiquement quel profil est la contrainte du portefeuille à un instant donné, et sur quelle tâche elle devrait se concentrer. Quand la contrainte change de projet, l'outil le signale.

Partie 3 — Framework de décision : comment arbitrer quand il faut choisir

La situation type : deux projets réclament la même ressource

C'est la situation la plus fréquente et la plus coûteuse en termes de temps de management : deux projets ont besoin de la même personne au même moment, et il faut décider laquelle passe en premier.

Sans méthode, la décision se prend à l'intuition, sous pression, en faveur du client le plus insistant. Avec un framework simple, elle se prend en deux minutes sur des bases objectives.

Voici le framework de décision en quatre questions :

1. 1

   Quel projet a les conséquences les plus importantes en cas de retard ?

   Conséquences contractuelles, impact client, risque commercial. Si l'un des deux projets a des pénalités de retard ou un client stratégique, la réponse est souvent évidente.

2. 2

   Quel projet est le plus sous tension par rapport à sa marge de sécurité ?

   Comparer le buffer consommé et la progression réelle de chaque projet. Le projet qui consomme sa marge trop vite est le plus fragile — même s'il ne crie pas encore.

3. 3

   Combien de temps la ressource est-elle nécessaire sur chaque projet ?

   Si le projet A a besoin de la ressource pour deux jours et le projet B pour une semaine, la réponse peut être de finir d'abord le projet A (court) avant de basculer sur B (long). Terminer une tâche est toujours plus efficace que de l'interrompre à mi-chemin.

4. 4

   La décision est-elle communicable clairement à l'équipe ?

   Une décision d'arbitrage qui ne peut pas être expliquée simplement est une décision qui ne tiendra pas. L'équipe doit comprendre pourquoi le projet A passe avant B — pas juste l'accepter.

Exemple concret : l'agence face à un arbitrage difficile

Notre agence reçoit vendredi après-midi un appel d'un client institutionnel : il veut avancer la livraison de la refonte de son site de deux semaines. En parallèle, la campagne de lancement retail doit livrer ses visuels finaux la semaine prochaine.

Le directeur artistique ne peut pas gérer les deux simultanément.

Appliquons le framework :

Lecture : la campagne retail est plus avancée, sa deadline est non négociable (liée à un événement), et elle ne demande que deux jours de travail pour être terminée. La refonte institutionnelle a un buffer encore sain malgré la demande d'avancement. La décision rationnelle est de terminer d'abord la campagne retail (deux jours), puis de basculer sur la refonte.

Cette décision n'est pas fondée sur l'intuition. Elle est fondée sur des données. Et elle peut être expliquée au client institutionnel de façon transparente.

Quand faut-il réviser les priorités ?

La priorité entre projets n'est pas figée pour toujours, mais elle ne doit pas changer à chaque réunion. Une révision de priorité se justifie dans trois situations :

• un projet livre et libère des ressources pour le suivant
• un événement externe change les enjeux (deadline contractuelle avancée, client perdu, nouvelle opportunité)
• la ressource contrainte change de nature (une personne quitte, une compétence devient disponible)

En dehors de ces situations, la priorité doit rester stable. L'instabilité des priorités est l'une des causes les plus épuisantes de désorganisation dans les équipes partagées.

Ce que KairoProject apporte ici : le dashboard signale automatiquement quand une situation a changé de façon significative — buffer qui franchit un seuil, ressource qui se libère, tâche critique qui se débloque. Cela évite de réviser les priorités en permanence tout en garantissant de ne pas manquer un signal important.

Ce que cette méthode change dans la pratique

Appliquer ces quatre règles et ce framework de décision ne demande pas de refaire tout le système de gestion de projet. Cela demande trois changements concrets.

Un seul endroit pour voir l'état de tous les projets

Fini les réunions de lundi matin pour reconstruire la vue d'ensemble à la main. Un outil de pilotage portefeuille adapté donne cette vue immédiatement — avec l'état de chaque projet, la tension sur les ressources et la priorité recommandée.

Une mise à jour régulière par les équipes elles-mêmes

Chaque membre de l'équipe met à jour son propre avancement — pas un chef de projet qui consolide les informations de tout le monde. Ce modèle de reporting décentralisé, au cœur de la méthode CCPM, produit une information plus fiable, plus récente, et moins chronophage pour tout le monde.

Pour aller plus loin sur les raisons pour lesquelles les projets dérivent même quand tout semble sous contrôle, cet article sur les 7 causes de retard détaille les mécanismes structurels à l'œuvre.

Une décision d'arbitrage explicite et connue de l'équipe

Chaque semaine, la priorité entre projets est affichée et partagée. Les membres de l'équipe savent sur quoi se concentrer en premier. Les demandes contradictoires sont moins fréquentes, et quand elles arrivent, la réponse est claire.

Pour aller plus loin

Ce guide couvre les fondamentaux. Pour approfondir chaque dimension :

• Gestion de portefeuille de projets : méthodes et erreurs à éviter — pour comprendre le pilotage portefeuille dans sa globalité
• Comment prioriser plusieurs projets quand la même équipe travaille sur tout — pour aller plus loin sur les signaux de priorisation
• Pourquoi votre planning Gantt devient peu fiable en multi-projets — pour comprendre les limites des outils traditionnels

Questions fréquentes

Sources et lectures complémentaires

• Eliyahu Goldratt, Critical Chain (1997) — la référence fondatrice de la méthode CCPM appliquée aux projets. Disponible sur Google Books
• PMI Pulse of the Profession — rapport annuel sur les taux de réussite des projets dans le monde. Consulter les rapports PMI
• Chaine-critique.com — ressources en français sur la méthode de la chaîne critique. Visiter le site
• Marris Consulting — cabinet spécialisé en Théorie des Contraintes appliquée aux projets. Visiter le site