Excel, Gantt, Jira… et toujours en retard : ce qui change quand vous pilotez par priorités
Votre équipe jongle entre Excel, un Gantt et Jira mais les sprints dérapent quand même ? Voici ce qui change concrètement quand on pilote un portefeuille de projets par priorités plutôt que par outils.
KairoProject
Le sprint planning de mardi matin commence bien. Puis quelqu'un pose la question qui plombe la réunion : « Où en est-on sur le projet Atlas ? » Silence. Le tableau Excel partagé date de la semaine dernière. Le Gantt du chef de projet ne montre que des jalons, pas qui travaille sur quoi. Jira, lui, ne connaît qu'un backlog à la fois : impossible d'y voir la charge réelle de l'équipe sur les trois projets menés en parallèle.
Ce n'est pas un problème d'outil isolé. C'est un problème de superposition. Excel pour le reporting mensuel, un Gantt pour la vue macro, Jira pour l'exécution au quotidien. Trois systèmes, trois vérités partielles, et personne qui puisse répondre en dix secondes à la question qui compte vraiment : quel projet doit passer en premier quand un développeur ne peut être que sur une tâche à la fois ?
Le coût réel n'est pas dans les outils eux-mêmes, mais dans le temps qu'ils font perdre. La réunion de suivi devient une réunion de mise à jour : on passe la moitié du temps à reconstituer la situation, et l'autre moitié à se demander qui doit faire quoi. La décision, elle, attend la semaine suivante.
Ce que vous allez trouver ici
Pas une nouvelle méthode à apprendre par cœur ni un outil de plus à ajouter à la pile. Ce qui change concrètement quand une équipe produit ou IT arrête de piloter par outils pour piloter par priorités, et comment Agile et Scrum s'intègrent dans cette bascule sans rien perdre de leur agilité.
Le problème n'est pas le nombre d'outils, c'est l'absence de priorité commune
Ajouter un tableau Excel de plus, un onglet supplémentaire au Gantt ou un nouveau label dans Jira ne résout rien. Le vrai sujet est ailleurs : aucun de ces outils ne répond à la question « qui doit avoir la priorité, là, maintenant, sur cette ressource ? »
Excel documente un état passé. Le Gantt décrit un projet comme s'il existait seul au monde. Jira organise l'exécution à l'intérieur d'un seul flux de travail. Aucun des trois n'a été conçu pour arbitrer entre plusieurs initiatives qui se disputent les mêmes développeurs, designers ou experts techniques.
Excel
Le Gantt
Jira
Résultat : la priorité entre projets se décide de fait, souvent au profit du client ou du manager le plus insistant de la semaine, et non du projet réellement stratégique.
Les signes qui ne trompent pas
- Vos réunions de suivi commencent toujours par « où en est-on ? », jamais par une décision.
- Une même personne apparaît « disponible » dans trois plannings différents en même temps.
- Chaque chef de projet a sa propre version de la priorité du moment.
- Le retard se découvre en réunion, jamais avant.
Si vous cochez au moins deux de ces cases, le problème n'est pas la compétence de l'équipe. C'est l'absence d'un endroit unique où la priorité se décide.
Piloter par priorités, en une phrase
Piloter par priorités signifie une seule chose concrètement : à tout instant, chaque personne de l'équipe sait sur quel projet elle doit concentrer son attention en premier, et cette priorité est visible de tous, pas négociée en couloir.
C'est le principe central de la méthode de la chaîne critique (Critical Chain Project Management, ou CCPM), popularisée par Eliyahu Goldratt. Plutôt que d'empiler des marges de sécurité invisibles dans chaque tâche, la méthode identifie la ressource ou la séquence qui limite réellement la vitesse de l'ensemble, protège cette contrainte avec une marge unique et visible, et rend la priorité entre projets explicite.
Pas besoin de maîtriser la méthode pour en profiter
Vous n'avez pas besoin de connaître le vocabulaire de la chaîne critique pour bénéficier de ses effets. C'est exactement le rôle d'un outil comme KairoProject : la logique tourne en arrière-plan, vous voyez le résultat.
Là où Agile et Scrum trouvent leur place
C'est le point que beaucoup d'équipes IT redoutent à tort. Non, la CCPM ne remplace pas Scrum. Les deux ne se situent même pas au même niveau.
La CCPM pilote le portefeuille : elle répond à la question « quel projet compte le plus cette semaine, et pourquoi ? ». Agile et Scrum restent la méthode d'exécution à l'intérieur de chaque projet : sprints, rituels, backlog, vélocité. L'un ne remplace pas l'autre, il s'imbrique dedans.
| Niveau | Question à laquelle il répond | Ce qui s'en occupe |
|---|---|---|
| Portefeuille | Quel projet doit avancer en priorité cette semaine ? | Pilotage par priorités (CCPM) |
| Projet | Quelle est la marge de sécurité restante avant le risque de retard ? | Buffer projet, suivi de sa consommation |
| Tâche / sprint | Qui fait quoi, dans quel ordre, cette semaine ? | Agile, Scrum, le backlog Jira |
Le sprint ne disparaît pas. Il continue d'exister exactement comme avant, sauf qu'il se déroule maintenant à l'intérieur d'une priorité de portefeuille claire, au lieu de flotter entre plusieurs projets qui réclament tous l'attention de la même équipe en même temps.
Ce qui change concrètement une fois qu'on bascule
| Avant | Après |
|---|---|
| Trois outils, trois vérités différentes sur l'état des projets | Une seule vue consolidée, partagée par toute l'équipe |
| La priorité se décide au fil de l'eau, souvent par la pression du moment | La priorité est explicite, stable et connue de tous |
| Les marges de sécurité sont dispersées dans chaque ticket Jira, invisibles | Une marge unique par projet, suivie en continu |
| Le multitâche entre projets est subi | Une ressource critique se concentre sur une priorité à la fois |
| Le retard se découvre en réunion de suivi | Le retard se voit venir, avant d'être acté |
Objection n° 1 : « On va perdre notre flexibilité Agile »
C'est la crainte la plus fréquente, et elle part d'un malentendu compréhensible. Piloter par priorités ne touche à rien de ce qui fait la valeur d'Agile à l'intérieur d'un projet : itérations courtes, rétrospectives, capacité à réagir à un changement de scope.
Ce qui change se situe un cran au-dessus. Au lieu que chaque chef de projet négocie individuellement l'attention des mêmes développeurs, la priorité entre projets est fixée une fois, connue de tous, et révisée seulement quand la réalité change vraiment. L'équipe garde sa réactivité au sein du sprint ; elle perd seulement l'ambiguïté sur ce qui doit passer avant quoi entre deux sprints de deux projets différents.
Un exemple concret
Une ressource partagée entre les projets Atlas et Nova sait aujourd'hui qu'Atlas est prioritaire cette semaine. Elle continue de travailler en sprints sur Atlas. Si une urgence légitime surgit sur Nova, la discussion porte sur un changement de priorité assumé, pas sur un arbitrage informel entre deux chefs de projet à bout de nerfs.
Objection n° 2 : « On n'a pas le temps ni le budget de tout migrer »
Deuxième crainte légitime, et bonne nouvelle : la bascule ne demande pas de tout reconstruire d'un coup. Elle peut se faire progressivement, projet par projet, sans toucher à Jira ni aux habitudes de sprint.
- 1
Pas besoin de replanifier quoi que ce soit à ce stade : listez simplement les projets en cours et les personnes qui travaillent sur plusieurs d'entre eux en même temps.
- 2
Dans la plupart des équipes IT, c'est un profil rare : l'architecte, le lead développeur, l'expert sécurité. C'est cette ressource qui détermine réellement la vitesse de tout le portefeuille.
- 3
Une seule liste, visible de toute l'équipe, qui répond à « si je ne peux avancer que sur un projet aujourd'hui, lequel est-ce ? »
- 4
Plutôt que chaque ticket Jira contienne sa propre marge de sécurité cachée, un seul tampon par projet est suivi et consommé au fil de l'avancement réel.
- 5
Rien ne change au niveau de l'exécution. Le pilotage par priorités se superpose à l'existant, il ne le remplace pas.
Ces cinq étapes tiennent dans un atelier d'une demi-journée, pas dans un trimestre de conduite du changement.
Un scénario concret : une équipe produit et trois initiatives
Prenons une équipe produit de huit personnes qui mène trois initiatives en parallèle : la refonte du parcours d'onboarding (Atlas), l'intégration d'un nouveau fournisseur de paiement (Nova), et un chantier de dette technique (Helios).
Nina, l'architecte de l'équipe, est sollicitée sur les trois. Dans le monde Excel + Gantt + Jira, chaque chef de projet planifie comme si Nina lui était entièrement dédiée. Résultat : elle est en réalité sursollicitée, et personne ne le voit avant que les trois projets commencent à glisser en même temps.
Avec un pilotage par priorités, la question change de nature. Ce n'est plus « Nina peut-elle faire les trois ? » mais « quel projet a besoin de Nina en premier, cette semaine ? ». Atlas est désigné prioritaire parce qu'il conditionne un engagement contractuel. Nova et Helios continuent d'avancer sur leurs tâches qui ne dépendent pas de Nina. Dès qu'Atlas n'a plus besoin d'elle, Nina bascule sur Nova selon un ordre décidé à l'avance, pas dans l'urgence d'une réunion de crise.
Rien dans cet exemple ne remet en cause les sprints d'Atlas, de Nova ou d'Helios. Ce qui change, c'est la clarté sur l'ordre dans lequel Nina doit être sollicitée.
Comment KairoProject rend cette bascule concrète
KairoProject a été conçu pour cette situation précise : des équipes qui gèrent plusieurs projets avec des ressources partagées, sans avoir de PMO dédié pour arbitrer à plein temps.
Dès la connexion, le tableau de bord affiche la priorité du moment, la ressource sous tension et l'action à mener, sans calcul manuel ni réunion de consolidation. La méthode de la chaîne critique tourne en arrière-plan ; ce que l'équipe voit, c'est une réponse claire à « sur quoi doit-on avancer aujourd'hui ? ».
Questions fréquentes
Non. Jira reste l'outil d'exécution au niveau des tâches et des sprints. Le pilotage par priorités se situe au niveau du portefeuille, au-dessus de Jira, pas à sa place.
La cartographie initiale des projets et des ressources partagées tient généralement en une demi-journée d'atelier. La priorité explicite entre projets peut être définie dès cette première session.
Oui, et c'est même le cas le plus courant. La CCPM ne remplace pas Scrum : elle décide quel projet doit avoir la priorité entre plusieurs équipes ou plusieurs sprints qui se disputent les mêmes personnes.
Rien n'oblige à les supprimer. Beaucoup d'équipes gardent Excel pour du reporting ponctuel. Ce qui change, c'est que ces outils ne sont plus le lieu où se décide la priorité entre projets.
Sources et lectures complémentaires
- Eliyahu Goldratt, Critical Chain (1997) — la référence fondatrice de la méthode appliquée aux projets. Disponible sur Google Books
- Eliyahu Goldratt & Jeff Cox, The Goal (1984) — le livre à l'origine de la théorie des contraintes. En savoir plus
- The Standish Group, Chaos Report — l'étude de référence sur les taux de réussite des projets IT, régulièrement citée depuis 1994. Voir le site
- Marris Consulting — ressources francophones spécialisées sur la mise en œuvre de la chaîne critique en entreprise. Visiter le site
À lire ensuite
- Qu'est-ce que la chaîne critique ? — les fondations de la méthode avant d'aller plus loin.
- Pourquoi votre planning Gantt devient peu fiable dès que vos projets partagent les mêmes ressources — comprendre le symptôme avant la bascule.
- Comment choisir un logiciel de gestion de projet — le guide complet pour comparer les options au-delà d'Excel.
- Réduire le multitâche dans les équipes projet — approfondir la réponse à l'objection sur la flexibilité Agile.
- Le fever chart de la CCPM — l'indicateur qui rend la priorité visible en un coup d'œil.
2 minutes · résultat personnalisé
Newsletter
Envie d'aller plus loin ?
Recevez régulièrement nos analyses sur la priorisation multi-projets, la Chaîne Critique, les ressources partagées et les pratiques de pilotage.