L’éléphant dans la salle
Printemps 2026, Paris. Un groupe de collaborateurs d’une entreprise française spécialisée dans la technologie. Ils viennent de plusieurs pays et travaillent dans des fonctions support, déploiement et IT. Les échanges se déroulent en anglais. Les parcours sont variés, tout comme les personnalités autour de la table.
Nous travaillons ensemble sur les fondamentaux de la gestion de projet.
L’entreprise mène plusieurs dizaines de projets transverses en parallèle. Les équipes évoluent dans un environnement agile, à un rythme soutenu. Pourtant, la formation est orientée vers une approche plus classique, dite prédictive.
Nous abordons successivement le phasage, la note de cadrage et la matrice RACI. L’ambiance est bonne, chacun participe activement.
Puis l’après-midi arrive.
Quand l’éléphant entre dans la pièce
Nous travaillons sur l’organigramme des tâches (WBS). Les participants découpent un projet afin d’identifier les livrables, le travail à réaliser et les premières estimations. Dans un second temps, ils réfléchissent à l’ordonnancement des activités et aux dépendances.
Avant leur restitution, je projette un exemple de WBS issu d’un projet aéronautique.
Avec le recul, ce n’était probablement pas le meilleur choix pour démontrer la simplicité de l’outil.
L’atmosphère change. Les visages se ferment. Je sens qu’il faut nommer « l’éléphant dans la pièce ».
L’un des participants, que nous appellerons Glenn, prend alors la parole :
« Julien, on ne voit pas vraiment l’utilité de cet exercice. C’est très lourd de décomposer tout un projet. Et puis, pourquoi définir des dépendances ? Chaque tâche suit une autre, c’est logique. Ça ne sert à rien ! »
Écouter avant de convaincre
Je respire calmement.
Je sais qu’il ne sert à rien de défendre immédiatement une technique. Il faut d’abord comprendre ce qui se joue.
Je reformule simplement :
« Vous n’avez pas le temps de faire ce type de découpage. Vous gérez déjà de nombreux projets et vous cherchez avant tout à avancer sans créer davantage de travail. Dans votre contexte, cette technique vous paraît trop lourde par rapport à la valeur qu’elle apporte. C’est bien cela ? »
La majorité des participants acquiesce.
Glenn reste toutefois agacé. Il vient de consacrer du temps à un exercice dont il ne perçoit pas les bénéfices.
Je décide alors de changer de rythme.
Nous passons à un dernier exercice plus léger et je propose de reprendre le sujet le lendemain matin, avec un regard neuf.
Je rappelle également un principe essentiel :
Toutes les techniques présentées pendant la formation sont des approches de référence. Chacun doit ensuite retenir ce qui lui est utile et les adapter à son propre environnement.
Préparer le deuxième jour
Le soir même, je prépare quelques supports supplémentaires afin d’expliquer plus clairement la différence entre le WBS et les dépendances.
Le WBS permet de décomposer le périmètre d’un projet afin de mieux comprendre le travail à réaliser et d’établir des estimations réalistes.
L’analyse des dépendances permet ensuite d’organiser les activités dans le bon ordre et d’anticiper les contraintes.
Je prépare les questions… et surtout les réponses.
Le déclic
Le lendemain matin, tout le monde est à l’heure.
J’ouvre la journée avec une pointe d’humour :
« Nous allons parler du sujet préféré de Glenn : l’organigramme des tâches. »
La salle éclate de rire. La tension est retombée.
J’explique alors que la décomposition d’un projet ne doit pas devenir un exercice gigantesque. Elle doit simplement atteindre le niveau de détail nécessaire pour comprendre le travail, répartir les responsabilités et construire un planning ainsi qu’un budget réalistes.
Nous revenons ensuite sur les dépendances :
- quelles activités doivent réellement être terminées avant d’en commencer d’autres ;
- quelles tâches peuvent être réalisées en parallèle ;
- où risquent d’apparaître les points de blocage.
Puis je pose une dernière question :
Que se passe-t-il lorsqu’on n’identifie jamais les dépendances d’un projet ?
Cette fois, le silence est différent.
Glenn hoche la tête.
Le groupe a compris.
Au-delà de la technique
Leur réaction révélait finalement une problématique plus large : comment faire avancer des projets transverses sans autorité directe, sans alourdir les processus et sans démobiliser les équipes ?
J’ai donc réorienté une partie de la formation afin d’accorder davantage de place à la dimension humaine, à la motivation, aux relations transverses et à la gestion des désaccords.
À la fin de la session, Glenn vient me voir :
« Désolé si j’ai un peu fait dérailler la formation. »
Je lui réponds que c’est souvent dans ces moments-là que l’apprentissage devient le plus riche.
Une formation ne déraille pas parce qu’un participant remet son contenu en question. Elle déraille lorsque le formateur refuse d’entendre ce que cette contestation révèle.
Il ne s’agissait pas uniquement d’une explication technique. Il fallait d’abord écouter une frustration, lui laisser une place, puis reprendre le travail.
Une véritable relation de confiance venait de se construire.
Il est 18 heures. Je range mes affaires et repars vers le métro.
Dehors, il fait encore beau.
