Beaucoup d'équipes se trompent de méthode non par incompétence, mais parce qu'elles appliquent par habitude ce qu'elles connaissent. Or la planification de projet et le rétroplanning agile répondent à deux situations différentes. Cet article n'explique pas les deux méthodes en détail. Il aide à choisir laquelle appliquer, et quoi faire quand le projet ne rentre pas dans une case nette.
Ce que vous choisissez vraiment
En une phrase :
- Planification : le contenu structure la date. On clarifie le travail, les enchaînements et les durées pour faire émerger une date d'engagement défendable.
- Rétroplanning : la date structure le contenu. On part d'une échéance imposée et on décide ce qui est faisable, prioritaire et tenable d'ici le jour J.
C'est aussi, en pratique, ce qui distingue souvent les approches dites traditionnelles (contenu figé, date à construire) des approches plus agiles (échéance posée, contenu à prioriser). Le choix de méthode suit d'abord la contrainte, pas une étiquette.
On retrouve ici le triangle des contraintes : périmètre, délai et moyens. Si la date est figée, le périmètre (ou la charge) doit pouvoir bouger. Si le périmètre est figé, c'est la date (ou les moyens) qui doit s'ajuster. Vouloir tout fixer en même temps, c'est construire un engagement intenable.
Ce n'est pas une guerre de dogmes. C'est un diagnostic de contrainte. Une fois le choix posé, les modes d'emploi pas à pas sont indiqués plus bas.
Cinq questions pour décider
Répondez dans l'ordre. La première réponse franche oriente déjà fortement.
1. La date de fin est-elle déjà imposée ?
- Non (ou « souhaitée », encore négociable) → partez plutôt en planification.
- Oui (lancement, salon, livraison contractuelle, événement) → le rétroplanning devient candidat.
2. Le périmètre peut-il être priorisé ou réduit ?
- Oui → compatible avec un rétroplanning (le contenu est la variable d'ajustement).
- Non (tout le périmètre est figé et dû) → partez en planification : on s'organise autour d'un contenu stable (enchaînements, durées, moyens) pour construire une date défendable. Si une date est déjà imposée en plus, il faudra des moyens supplémentaires ou une renégociation explicite (date ou contenu).
3. Le contenu du projet est-il déjà assez clair ?
- Non → ni l'une ni l'autre méthode ne sauve un flou total. Passez d'abord par un cadrage.
- Oui assez pour lister des livrables ou des éléments → vous pouvez enchaîner sur la méthode choisie.
4. Les dépendances techniques sont-elles structurantes ?
- Oui, et la date doit être défendue → la planification (WBS, réseau, chemin critique) est souvent plus adaptée pour sécuriser l'engagement.
- Secondaire face à une échéance non négociable → le rétroplanning oriente d'abord phases, priorités et capacité.
5. Sur quoi porte l'engagement envers le client ou le sponsor ?
- Sur une date réaliste à construire → planification.
- Sur un jour J déjà annoncé, avec un contenu à arbitrer → rétroplanning.
Lecture rapide des réponses
- Date à estimer + contenu à structurer → planification.
- Date imposée + périmètre négociable → rétroplanning.
- Date imposée + contenu encore flou → cadrer d'abord, puis rétroplanning.
- Date imposée + périmètre non négociable + moyens insuffisants → renégocier (date, moyens ou contenu) ; aucune méthode ne fait tenir l'impossible.
Cas mixtes : quand ce n'est pas binaire
Date « souhaitée » mais présentée comme figée
Souvent la date est politique, pas technique. Test : peut-on encore la déplacer si le contenu le justifie ? Si oui, traitez-la comme une cible et faites une planification pour produire une date défendable. Si non, assumez le rétroplanning et priorisez explicitement.
Socle stable + lot « jour J » flexible
Hybride fréquent : une partie du projet (infrastructure, conformité, socle technique) se prête à une planification ; le lot visible pour l'échéance se gère en rétroplanning (priorisation et capacité). L'erreur est d'appliquer une seule logique à tout le portefeuille d'éléments.
Plusieurs projets, une même équipe
Même si chaque projet a sa méthode, la capacité se joue au niveau de l'équipe. Des cycles partagés et une comparaison charge / capacité sur l'ensemble des projets évitent qu'un rétroplanning « tienne » seulement parce qu'il ignore les autres.
Signaux que vous êtes sur la mauvaise méthode
- Vous construisez WBS, réseau et Gantt pour coller à une date déjà imposée, sans priorisation ni lecture de capacité → vous forcez une planification là où il fallait un rétroplanning.
- Le périmètre change et vous acceptez les demandes de changement sans négocier délai, charge ou contrepartie → vous subissez une dérive au lieu de planifier (ou de renégocier explicitement).
- Vous annoncez une date avant tout cadrage, puis « organisez à rebours » sans liste d'éléments claire → ce n'est ni une bonne planification ni un vrai rétroplanning.
- Tout est « indispensable » et la capacité ne suit pas → la méthode est peut-être bonne, mais l'arbitrage n'a pas été fait.
Que faire une fois le choix posé
Le diagnostic ne remplace pas le mode d'emploi :
- Si la planification s'impose → Comment faire une planification de projet étape par étape.
- Si le rétroplanning s'impose → Comment faire un rétroplanning agile étape par étape.
- Si le contenu est encore trop flou → Comment cadrer un projet avant le lancement.
Synthèse
Choisir une méthode, c'est répondre à une question simple : est-ce la date qui doit émerger du contenu, ou le contenu qui doit s'ajuster à une date déjà fixée ? Les cinq questions ci-dessus, les cas mixtes et les signaux d'erreur évitent d'appliquer par habitude la mauvaise logique. Ensuite seulement, on déroule la méthode choisie.
