Six méthodes reviennent dans presque toutes les discussions de gestion de projet : la cascade, le cycle en V, PRINCE2, Scrum, Kanban et le Lean. Elles ne s'opposent pas comme on le raconte souvent. Elles répondent à des situations différentes, et elles se distinguent surtout par un point : ce qui est figé au départ, et ce qui reste négociable.
L'approche traditionnelle : on décide tout, puis on exécute
C'est la plus ancienne, et elle reste la plus répandue. Le projet avance en étapes ordonnées : définition, planification, exécution, suivi, clôture. Chaque phase se termine avant que la suivante commence.
Ce qui caractérise cette famille tient en une phrase : le contenu est fixe, le délai et le budget s'ajustent. Le client sait ce qu'il veut. On le note, on le chiffre, on le construit.
La conséquence est directe. Revenir en arrière coûte cher, parfois très cher. Le cahier des charges doit donc être solide avant le premier jour de production, ce qui suppose un cadrage sérieux en amont.
L'avantage est réel et on l'oublie souvent : quand le plan tient, les dépassements n'arrivent pas. Un projet bien cadré et exécuté en séquence se livre à la date annoncée.
La cascade : le modèle d'origine
La cascade est la forme pure de cette approche. Chaque phase dépend entièrement de la précédente, et rien ne remonte.
Sa rigidité porte un nom sur le terrain : l'effet tunnel. Le client valide un document en janvier, ne voit rien pendant six mois, et découvre le résultat en juillet. Si sa compréhension du besoin a évolué entre temps, personne ne s'en est aperçu.
Elle fonctionne bien sur les petits projets dont le produit final est connu d'avance. Un déménagement, une mise en conformité, un chantier dont les plans sont validés.
Le cycle en V : la cascade avec des tests
Le cycle en V corrige le principal défaut de la cascade : l'absence de vérification avant la fin.
Le projet n'est plus un bloc unique. Il se décompose en composants. La branche descendante reprend les phases de la cascade, de l'expression du besoin à la réalisation. La branche montante valide chaque niveau en miroir, avec des tests qui associent le client.
Les retours en arrière deviennent possibles, à condition qu'ils restent locaux. On corrige un composant, pas l'architecture.
Le cycle en V demande du budget, une équipe qui connaît son métier, et un client capable d'exprimer ses attentes puis de les valider par étapes. C'est la méthode dominante dans l'industrie et l'embarqué, là où un défaut découvert tard coûte davantage que le protocole de test lui-même.
PRINCE2 : un cadre de gouvernance, pas une façon de produire
PRINCE2 est né dans l'administration britannique. PROMPT en 1979, renommé PRINCE en 1989, révisé en PRINCE2 en 1996. L'acronyme signifie Project IN Controlled Environments.
Il ne dit pas comment fabriquer. Il dit qui décide, sur quels critères, à quel moment. Trois piliers : l'organisation, la gestion, le contrôle. Sept processus, sept thèmes, sept principes, et un comité de pilotage qui autorise chaque phase.
C'est utile quand le projet engage plusieurs entités, qu'il faut tracer les décisions, et que la question « qui a validé quoi » se posera un jour. C'est disproportionné pour une équipe de cinq personnes dans une même pièce.
PRINCE2 se combine d'ailleurs avec les autres. Rien n'empêche une gouvernance PRINCE2 au-dessus d'équipes qui travaillent en Scrum.
L'approche agile : on fixe le rythme, pas le contenu
Le Manifeste Agile date de 2001. Dix-sept praticiens du développement logiciel, réunis dans l'Utah, écrivent quatre valeurs en une page.
- Les personnes et leurs interactions, avant les processus et les outils.
- Un produit qui fonctionne, avant une documentation exhaustive.
- La collaboration avec le client, avant la négociation contractuelle.
- L'adaptation au changement, avant le suivi d'un plan.
Le mot important de ces quatre lignes est « avant ». Le manifeste hiérarchise, il n'élimine pas. Un projet agile sans documentation ni contrat n'est pas agile, il est mal tenu.
Le renversement porte sur ce qui est figé. Ici le délai et l'équipe sont fixes, le contenu s'ajuste. On travaille par cycles courts, on livre un incrément à la fin de chacun, on le montre, on écoute, on corrige la suite.
Cela suppose un client réellement disponible. C'est la condition que personne n'écrit dans les contrats et qui décide pourtant du résultat. Un client injoignable pendant trois semaines transforme un sprint en devinette.
Scrum : le cadre agile le plus répandu
Scrum organise le travail en sprints de une à quatre semaines. Trois rôles : product owner, scrum master, équipe de développement. Un backlog priorisé, une revue à chaque fin de sprint, une rétrospective pour ajuster la manière de travailler.
Le cadre est plus contraignant qu'il n'y paraît. Les rituels sont obligatoires, le périmètre d'un sprint ne bouge pas une fois lancé, et le rôle de product owner suppose quelqu'un qui décide vraiment.
Scrum convient aux projets dont le contenu évoluera de toute façon, et où l'équipe peut livrer quelque chose d'utilisable toutes les deux semaines. Si le premier livrable exploitable arrive au bout de six mois, le cadre tourne à vide.
Kanban : rendre le flux visible
Kanban signifie « carte de signalisation » en japonais. La méthode vient des ateliers Toyota des années 1950, où ces cartes déclenchaient le réapprovisionnement.
Le principe tient en un tableau : des colonnes qui représentent les étapes du travail, des cartes qui avancent de l'une à l'autre. Chacun voit où en est chaque tâche, sans réunion.
La règle qu'on oublie le plus souvent est la limite de travail en cours. Un Kanban sans plafond par colonne devient une liste de tâches décorée. C'est la limite qui révèle les goulots d'étranglement : quand une colonne sature, le problème se voit.
Kanban se marie bien avec d'autres approches. Beaucoup d'équipes pilotent en Scrum et visualisent en Kanban. Il convient particulièrement au travail continu, au support, à la maintenance, à tout ce qui arrive sans se planifier.
Lean : chasser ce qui ne produit pas de valeur
Le Lean vient du même terreau industriel japonais. Son objet est le gaspillage : l'attente, la reprise, le déplacement inutile, la production de ce que personne n'a demandé.
La démarche part du client pour définir ce qui a de la valeur, puis remonte le flux pour supprimer le reste. Les problèmes se traitent là où ils se produisent, avec les gens qui font le travail.
C'est moins une méthode de projet qu'une manière de faire fonctionner une organisation. Elle demande un engagement de la direction, et une culture où signaler un dysfonctionnement ne se retourne pas contre celui qui le signale.
Le Lean donne ses meilleurs résultats sur des processus qui se répètent d'un projet à l'autre. Sur un projet unique en son genre, il y a peu de gaspillage identifiable puisqu'il n'y a pas de référence.
Ce qui distingue vraiment ces méthodes
La ligne de partage n'est pas agile contre traditionnel. Elle passe par une question : que savez-vous au départ ?
Si le contenu est connu et stable, une approche séquentielle le livre plus vite et moins cher. Si le contenu se découvre en avançant, une approche itérative évite de construire pendant six mois quelque chose qui ne servira pas.
Trois facteurs pèsent davantage que le choix de la méthode elle-même : la disponibilité réelle du commanditaire, l'expérience de l'équipe, et le coût d'une erreur découverte tard. Un projet dont le client répond une fois par mois ne sera pas agile, quel que soit le vocabulaire employé dans les réunions.
Nous avons consacré un article entier à cette décision, avec les questions à se poser et les signaux qui indiquent qu'on s'est trompé : comment savoir quelle méthode appliquer selon votre projet.
Ce que toutes ces méthodes ont en commun
Aucune ne vous dispense de savoir de quoi le projet est fait.
La cascade demande le découpage avant de commencer. Scrum le demande au fil de l'eau, sprint après sprint. Le moment change, le travail reste le même : identifier les livrables, comprendre ce qui bloque quoi, estimer les durées.
C'est pour cette raison que les structures de découpage et les réseaux de dépendances traversent les époques et les écoles. Ils décrivent le projet, pas la façon de l'organiser.
Le diagramme de Gantt illustre bien la confusion courante. On le range du côté traditionnel, alors qu'il n'est qu'une représentation dans le temps. Ce qui pose problème, ce sont ses usages : un Gantt dessiné à la main sans réseau de dépendances derrière est un dessin, et il se périme en trois semaines.
Structurer un projet avec Orchesia, quelle que soit la méthode
Orchesia ne vous impose pas de méthode. Il outille ce qui leur est commun.
Le point d'entrée est une carte mentale : le projet se décompose en objectifs, puis en livrables, puis en tâches. Le découpage se construit avec l'équipe, sur une vue faite pour ça. Que vous le fassiez intégralement au départ ou cycle après cycle, l'outil est le même.
Vient ensuite le réseau de dépendances. Ce qui bloque quoi se déclare une fois, et le planning en découle. Le chemin critique et les marges se calculent, se recalculent à chaque changement de durée, et disent de combien la date peut glisser.
Le suivi se lit ensuite selon vos habitudes : liste de tâches, Gantt, tableau Kanban, charge par personne. Ce sont des vues sur la même structure, pas quatre outils à tenir à jour séparément.
Deux modes couvrent les deux familles. Le mode structuré part du contenu et calcule la date. Le mode simplifié part d'une date imposée et remonte la chaîne, ce que nous appelons le rétroplanning.
Reste la question qui décide de tout, et qu'aucun logiciel ne tranchera à votre place : savez-vous, aujourd'hui, ce que votre projet doit produire ? Si oui, planifiez. Sinon, itérez, et gardez de la marge.
