Bonjour ! Dans la leçon précédente, nous avons vu comment estimer l'effort nécessaire pour réaliser les "briques" de travail d'un projet, que ce soit en temps ou en points de complexité. Nous savons maintenant estimer la taille d'une tâche. La prochaine question logique est : dans quel ordre devons-nous les faire ?
Un projet n'est presque jamais une simple liste de tâches que l'on peut exécuter dans n'importe quel ordre. Certaines tâches doivent en précéder d'autres, certaines peuvent être faites en parallèle. Cet enchevêtrement de relations s'appelle les dépendances.
Dans cette leçon, nous allons explorer l'importance de la gestion de ces dépendances et d'un concept qui en découle directement : le chemin critique. Comprendre ces notions est fondamental pour tout chef de projet, car elles permettent de construire un planning réaliste, d'identifier les risques majeurs et de concentrer l'énergie de l'équipe là où elle a le plus d'impact. C'est l'outil de base pour répondre de manière crédible à la question "Quand est-ce que ce sera fini ?".
1. Les dépendances : les liens invisibles du projet
Avant de pouvoir planifier quoi que ce soit, il faut comprendre comment les tâches sont liées entre elles. En gestion de projet, une dépendance est une relation qui lie deux tâches, où le début ou la fin de l'une est conditionné par le début ou la fin de l'autre.
L'article suivant, du site Office Timeline, offre une excellente introduction aux quatre principaux types de dépendances.
Méthode du chemin critique et dépendances expliquées
Pour bien commencer, il est essentiel de maîtriser le vocabulaire des dépendances. Cet article explique très clairement les quatre types de relations qui peuvent exister entre les tâches.
Lisez la section intitulée "Que sont les dépendances en gestion de projet?". Concentrez-vous sur la définition des quatre types de dépendances (Fin–Début, Début–Début, Fin–Fin, Début–Fin) et leurs exemples.
Pour résumer et appliquer ces concepts à votre domaine, voici des exemples tirés d'un projet de développement web :
-
Fin–Début (FD) : La plus courante. La tâche A doit finir avant que la tâche B ne commence.
- Exemple : Le design de la maquette de la page d'accueil (A) doit être finalisé avant que le développement front-end de cette page (B) puisse commencer.
-
Début–Début (DD) : La tâche B ne peut commencer que si la tâche A a déjà commencé. Elles peuvent ensuite se dérouler en parallèle.
- Exemple : L'écriture des tests d'intégration pour un module (B) peut commencer dès que le développement du module (A) a débuté.
-
Fin–Fin (FF) : La tâche B ne peut pas se terminer tant que la tâche A n'est pas terminée.
- Exemple : La migration complète des données de la base de production (B) ne peut être considérée comme terminée tant que la phase de vérification finale des données (A) n'est pas finie.
-
Début–Fin (DF) : La plus rare et la moins intuitive. La tâche B ne peut pas se terminer avant que la tâche A n'ait commencé.
- Exemple : Le support de l'ancienne version du site (B) ne peut pas être arrêté tant que la formation des utilisateurs sur la nouvelle version (A) n'a pas commencé.
Identifier correctement ces liens est la première étape de la construction de tout planning cohérent.
Testez votre compréhension !
Dans un projet de refonte d'une application, identifiez le type de dépendance pour chaque scénario :
- La mise en production de la nouvelle version ne peut pas commencer tant que la campagne de communication n'est pas prête à être lancée.
- La documentation technique finale ne peut être achevée qu'après la fin des derniers tests de performance.
- Le développement du back-end doit commencer pour que l'équipe front-end puisse commencer à travailler avec l'API (même si celle-ci n'est pas encore complète, via des "mocks").
Show answer
- Fin–Début (FD) : La campagne doit être prête (Fin A) avant de pouvoir mettre en production (Début B).
- Fin–Fin (FF) : Les tests doivent être finis (Fin A) pour pouvoir finaliser la documentation (Fin B).
- Début–Début (DD) : Le développement back-end doit avoir commencé (Début A) pour que le développement front-end puisse commencer (Début B).
2. Le chemin critique : la colonne vertébrale de votre projet
Une fois que nous avons identifié les tâches et leurs dépendances, nous pouvons les visualiser comme un réseau. Ce réseau est composé de plusieurs "chemins" possibles du début à la fin du projet.
Le chemin critique est tout simplement la plus longue séquence de tâches dépendantes. La durée totale de ce chemin détermine la durée minimale de votre projet.
La caractéristique essentielle des tâches situées sur le chemin critique est qu'elles n'ont aucune marge de manœuvre (appelée "marge" ou "flottement"). Tout retard sur l'une de ces tâches entraînera inévitablement un retard de la date de fin du projet.
La vidéo suivante montre de manière très pratique comment le chemin critique est représenté dans un logiciel de gestion de projet et ce que cela implique.
MS Project ● Le Chemin Critique ● Simple
Pour voir ce que cela signifie concrètement, regardons cette vidéo qui explique et montre le chemin critique dans un outil très répandu, MS Project. Notez bien la distinction visuelle entre les tâches critiques et non-critiques.
Regardez le début de la vidéo de 00:00 à 04:10. Concentrez-vous sur la définition du chemin critique, comment il est visualisé (en rouge), et la notion de 'marge' pour les tâches non critiques (en bleu).
Comme vous l'avez vu, les tâches qui ne sont pas sur le chemin critique possèdent une certaine "marge". Elles peuvent prendre un peu de retard sans impacter la date de livraison finale. C'est une information cruciale.
Voici une autre visualisation de ce concept, via un diagramme de Gantt, un outil que vous utiliserez souvent.
3. L'importance pour le chef de projet
Savoir identifier le chemin critique n'est pas un simple exercice théorique. C'est l'un des outils de pilotage les plus puissants à votre disposition.
a) Focaliser l'attention et gérer les risques
Le chemin critique vous indique où regarder. Si une tâche sur ce chemin prend du retard, c'est une alerte rouge pour le projet. En revanche, si une tâche non-critique dérape un peu, vous avez de la flexibilité. Cela vous permet de hiérarchiser les problèmes et de ne pas vous laisser submerger par des urgences qui n'en sont pas vraiment.
b) Optimiser les ressources et accélérer le projet
Imaginez que votre direction vous demande de livrer le projet plus tôt. Votre premier réflexe pourrait être de mettre plus de développeurs sur la première tâche disponible. C'est une erreur si cette tâche n'est pas sur le chemin critique !
Pour réduire la durée totale du projet, vous devez impérativement raccourcir la durée d'une ou plusieurs tâches du chemin critique. Accélérer une tâche non-critique ne fera qu'augmenter sa marge, sans aucun bénéfice pour la date de livraison.
La vidéo précédente l'explique très bien.
MS Project ● Le Chemin Critique ● Simple
Le chemin critique est l'outil principal pour piloter les délais. Regardons la suite de la vidéo pour comprendre comment on peut utiliser cette information pour accélérer un projet.
Regardez la section de 07:22 à 09:04, puis le résumé de 10:05 à 10:46. Notez bien sur quelles tâches il faut agir si l'on veut réduire la durée totale du projet.
c) Communiquer de manière crédible
Le chemin critique est votre meilleur allié pour justifier un planning auprès des parties prenantes. Vous pouvez expliquer factuellement : "Nous ne pouvons pas commencer le développement de la fonctionnalité X avant d'avoir finalisé l'architecture de la base de données Y, car cette tâche est sur le chemin critique. Tout retard sur Y impactera directement la livraison finale."
Pour synthétiser tous ces avantages, je vous propose de lire le résumé suivant.
Méthode du chemin critique et dépendances expliquées
L'article d'Office Timeline que nous avons déjà consulté propose un excellent résumé des bénéfices de cette méthode.
Lisez la section "Pourquoi utiliser la méthode du chemin critique ?". Cela vous donnera une vue d'ensemble claire des avantages de cette approche.
Conclusion et transition vers l'Agile
La méthode du chemin critique est un pilier de la gestion de projet dite "prédictive" ou "Waterfall". Vous vous demandez peut-être sa pertinence dans un monde Agile comme Scrum, qui est votre objectif. La réponse est : elle est fondamentale, mais appliquée différemment.
Dans un projet Scrum, on ne va généralement pas calculer le chemin critique complet pour les 12 prochains mois. L'incertitude est trop grande. Cependant, la conscience des dépendances reste primordiale pour le Product Owner lorsqu'il ordonne le Product Backlog. Il est impossible de développer une page de profil utilisateur (story A) avant d'avoir un système d'authentification (story B). La story B doit donc être priorisée avant la A.
Au niveau d'un Sprint, l'équipe de développement peut mentalement (ou sur un tableau blanc) tracer les mini-dépendances entre les tâches du Sprint Backlog pour s'organiser efficacement sur deux semaines.
L'article d'Office Timeline (LINK) mentionne d'ailleurs cette distinction dans sa FAQ, sous la question "Où la méthode du chemin critique est-elle utilisée ?".
En résumé, voici les points clés à retenir :
- Les dépendances lient les tâches entre elles et définissent l'ordre d'exécution logique d'un projet. Il en existe 4 types principaux : Fin-Début, Début-Début, Fin-Fin, et Début-Fin.
- Le chemin critique est la séquence de tâches la plus longue, qui détermine la durée minimale du projet.
- Les tâches du chemin critique ont une marge nulle. Tout retard sur l'une d'elles retarde l'ensemble du projet.
- Identifier et surveiller le chemin critique permet de focaliser les efforts, de gérer les risques plus efficacement et d'optimiser l'allocation des ressources pour respecter les délais.
Nous avons maintenant bouclé les fondamentaux de la gestion de projet : décomposer (WBS/Epics), estimer (points/temps) et séquencer (dépendances/chemin critique).
Dans le prochain module, nous plongerons au cœur de votre objectif : maîtriser le cadre Scrum. Nous commencerons par ses fondations, les valeurs et principes du Manifeste Agile, qui sous-tendent toute la philosophie de cette approche. Vous verrez alors comment ces concepts de planification s'intègrent dans un cycle de développement adaptatif et itératif.