Méthodes de gestion de projet : cycle en V, cascade, agile, hybride

Une méthode de gestion de projet se choisit d’abord sur une question : le besoin peut-il être figé avant de lancer la réalisation ? Les autres critères, coût d’un changement tardif, obligation de qualifier ou de certifier le produit, possibilité de le livrer par morceaux, ne viennent qu’après.

Cette page, l’un des guides du dossier sur la gestion de projet technique, compare les quatre démarches qui structurent un projet technique, cascade, cycle en V, agile et hybride, sur les mêmes critères, et dit pour chacune dans quelle situation elle échoue. C’est ce qui manque aux listes de méthodes : chacune a ses avantages, mais toutes perdent quelque part.

Méthode, méthodologie, approche : de quoi parle-t-on ?

Le vocabulaire de la gestion de projet n’est pas fixé, et les mêmes mots désignent des choses différentes selon les auteurs.

• Une approche (prédictive, adaptative, hybride) est la logique d’ensemble : le projet est-il planifié en entier au départ, ou découvert au fil des itérations ?
• Une méthode de gestion de projet (cascade, cycle en V, Scrum, Kanban) décrit l’organisation du travail : les phases ou les cycles, les rôles, les réunions, les livrables.
• Une méthodologie est l’ensemble des méthodes, règles et modèles qu’une entreprise adopte pour tous ses projets : on parle de la méthodologie maison d’un bureau d’études.
• Un outil (diagramme de Gantt, tableau Kanban, registre des risques) sert une méthode sans la définir.

Cette page compare les méthodes ; le choix de l’approche en découle, et les outils viennent ensuite.

Les quatre méthodes comparées sur les mêmes critères

Le PMBOK, le guide de référence du Project Management Institute, range les démarches en trois familles : prédictive (le périmètre, le délai et le coût sont fixés tôt), adaptative (le périmètre se précise au fil des itérations) et hybride (un mélange des deux). La cascade et le cycle en V sont prédictifs, l’agile est adaptatif.

La ligne qui décide est la première. Si vous ne savez pas répondre à « le besoin sera-t-il le même dans six mois ? », vous ne pouvez pas choisir de méthode : commencez par écrire le besoin.

Cascade : des phases qui se suivent

La cascade enchaîne les phases dans l’ordre : besoin, conception, réalisation, essais, mise en service. Chaque phase produit un livrable validé avant que la suivante commence, et le planning se tient au diagramme de Gantt. C’est la démarche des projets dont le résultat est connu d’avance : un bâtiment, une ligne de production, le déménagement d’un atelier.

Pour quel projet : un équipement spécifié par un cahier des charges, un fournisseur qui fabrique sur plans, des travaux avec des corps de métier qui se succèdent. L’exemple fictif suivi dans ce dossier, le remplacement d’une ligne de conditionnement, en relève : besoin écrit en février, commande en mars, recette en usine en juin, réception en août, selon les étapes d’un projet décrites de l’expression du besoin à la clôture.

Quand elle échoue :

• le besoin était mal compris et on le découvre à la recette, quand tout est fabriqué ;
• un changement arrive tard : il faut revenir plusieurs phases en arrière, et le délai saute ;
• le client ne voit rien pendant des mois, et ce qu’il voit à la fin ne correspond pas à ce qu’il imaginait ;
• l’incertitude technique est forte : on planifie une réalisation que personne ne sait encore faire.

Le signal d’alerte : des demandes de modification qui s’accumulent pendant la réalisation.

Comment la sécuriser : investir dans la définition du besoin avant tout le reste (analyse fonctionnelle, cahier des charges avec critères et niveaux), faire valider ce besoin par les utilisateurs et pas seulement par le commanditaire, et poser une revue de conception où le client voit les plans avant la fabrication. Une procédure écrite de demande de modification, avec son impact sur le délai et le coût, évite que les changements entrent sans décision.

Cycle en V : chaque niveau a son essai

Le cycle en V est une cascade où chaque étape de conception a son étape de vérification en miroir. La branche descendante précise le produit à chaque niveau un peu plus finement : besoin, spécification du système, conception générale, conception détaillée. Au fond du V, on réalise. La branche montante vérifie dans l’ordre inverse : essais unitaires contre la conception détaillée, essais d’intégration contre la conception générale, validation du système contre la spécification, recette contre le besoin.

Chaque niveau est vérifié contre le document qui l’a défini, et une matrice de traçabilité relie chaque exigence à l’essai qui la prouve. C’est ce qu’exigent les secteurs où un produit doit être qualifié ou certifié avant d’être utilisé : ferroviaire, aéronautique, automobile, dispositifs médicaux, équipements de sécurité.

Pour quel projet : un produit complexe, décomposé en sous-ensembles, avec des preuves à fournir à un organisme de certification ou à un client exigeant.

Quand il échoue :

• la spécification arrive tard ou incomplète, et toute la branche descendante se construit sur du sable ;
• un défaut d’exigence n’apparaît qu’à la validation, en haut du V : on le corrige en redescendant tous les niveaux, puis en remontant tous les essais ;
• le projet est petit : la documentation de chaque niveau coûte plus que le produit.

Le signal d’alerte : une matrice de traçabilité qui a des trous, des exigences sans essai ou des essais sans exigence.

Comment le sécuriser : écrire chaque exigence avec la façon de la vérifier dès la branche descendante, faire relire les spécifications par ceux qui feront les essais, et prévoir des maquettes ou des prototypes partiels pour lever tôt les doutes sur les exigences les plus risquées. Le cycle en V ne dit pas qu’il faut attendre le bas du V pour essayer quoi que ce soit : il dit que chaque niveau doit être prouvé.

Agile : livrer par incréments

L’agilité vient du développement logiciel. Le Manifeste agile, publié en 2001 par dix-sept praticiens, pose quatre valeurs : les individus et leurs interactions plus que les processus et les outils, des logiciels opérationnels plus qu’une documentation exhaustive, la collaboration avec le client plus que la négociation contractuelle, l’adaptation au changement plus que le suivi d’un plan. Le texte reconnaît la valeur des seconds éléments, mais privilégie les premiers.

Deux méthodes dominent :

• Scrum organise le travail en sprints d’une durée fixe d’un mois au plus. Chaque sprint part d’un objectif, puise dans une liste priorisée (le backlog), livre un incrément utilisable et se termine par une revue avec les parties prenantes et une rétrospective de l’équipe. Le Scrum Guide de 2020 définit trois responsabilités : le product owner, qui ordonne le backlog et répond de la valeur du produit ; le scrum master, qui fait fonctionner la méthode ; les développeurs, qui réalisent l’incrément.
• Kanban visualise le flux de travail sur un tableau en colonnes (à faire, en cours, fait) et limite le nombre de tâches en cours : une colonne pleine bloque l’entrée de nouvelles tâches tant qu’une autre n’est pas sortie.

Pour quel projet : un logiciel, un outil interne, un service numérique, tout produit que l’on peut livrer en morceaux utilisables et dont l’utilisateur est disponible pour réagir.

Quand l’agile échoue :

• un composant a un délai d’approvisionnement de vingt semaines : on ne l’itère pas, on le commande une fois, et il faut avoir figé ses caractéristiques avant ;
• le produit doit être qualifié sur une configuration figée : chaque itération remet la qualification en cause ;
• le client n’est pas disponible pour les revues, et les incréments s’empilent sans retour ;
• le contrat est au forfait sur un périmètre figé : l’agilité promet de changer ce que le contrat interdit de changer.

Le signal d’alerte : des sprints qui se terminent sans incrément utilisable, ou un backlog que personne ne priorise.

Avec un produit physique, l’agile s’adapte en partie. Ce qui passe bien : les itérations courtes de conception (modèles 3D, prototypes imprimés, essais sur maquette), les revues régulières avec l’utilisateur, le tableau Kanban pour les tâches de l’équipe. Ce qui passe mal : les achats à long délai, les outillages de série, les essais de qualification, qui demandent une configuration figée et datée. Les équipes de développement de produits physiques qui travaillent en agile gardent donc des jalons fixes pour ces étapes, ce qui les rapproche d’un hybride.

Hybride : décider où passe la frontière

La plupart des projets techniques ne sont ni purement prédictifs ni purement adaptatifs. Une démarche hybride l’assume : elle applique une démarche prédictive à ce qui est figé et coûteux à changer, et une démarche adaptative à ce qui peut évoluer.

Sur l’exemple du dossier, la ligne de conditionnement suit une cascade : cahier des charges, commande, fabrication, recette en usine, installation, réception, avec des jalons fixes. Le logiciel de supervision qui collecte les arrêts et la cadence de la ligne peut, lui, avancer par itérations de quelques semaines pendant la fabrication, avec les opérateurs qui l’utiliseront. Les deux se retrouvent à un jalon commun : les essais sur site, où le logiciel doit lire la vraie ligne.

Pour quel projet : un produit mécatronique, un prototype de recherche et développement, une installation industrielle avec son système d’information.

Quand l’hybride échoue :

• la frontière n’est jamais décidée, et chaque équipe applique sa méthode à tout ;
• deux plannings coexistent sans se parler, le Gantt des jalons d’un côté, le backlog de l’autre, et personne ne voit que l’itération 6 dépend de la livraison d’un capteur ;
• le comité de pilotage attend d’une équipe agile les engagements de délai d’une équipe en cascade.

Le signal d’alerte : deux réunions de suivi qui ne partagent aucun jalon.

Comment l’organiser : écrire dans la note de cadrage ce qui suit chaque démarche, et pourquoi ; tenir un seul planning de haut niveau qui porte les jalons du matériel et les fins d’itération du logiciel ; désigner un responsable de l’intégration qui suit les dépendances entre les deux mondes ; et faire coïncider au moins une revue d’itération avec chaque jalon du matériel. Sur l’exemple, la revue d’itération de fin juin tombe pendant l’installation : c’est le moment de brancher le logiciel sur la ligne réelle.

Choisir en pratique : trois questions au cadrage

Le choix se fait au cadrage, en réunion, avec le commanditaire et les futurs utilisateurs. Trois questions suffisent dans la plupart des cas, dans cet ordre.

1. Le besoin peut-il être figé avant la réalisation ? Si l’utilisateur sait écrire ce qu’il attend, avec des critères et des niveaux, la réponse est oui. S’il dit « on verra en le voyant », la réponse est non.
2. Le produit doit-il être qualifié ou certifié niveau par niveau ? Une réglementation, un client ou un organisme de certification qui exige des preuves par sous-ensemble oriente vers le cycle en V.
3. Peut-on livrer des morceaux utilisables en cycles d’un mois au plus ? Un logiciel, un service, un outil interne le permettent ; une machine, un bâtiment, une ligne de production ne le permettent pas.

Oui à la première et à la deuxième : cycle en V. Oui à la première seulement : cascade. Non à la première et oui à la troisième : agile. Non à la première et non à la troisième : hybride, avec des itérations là où elles sont possibles et des jalons ailleurs. Le pilier du dossier présente cet arbre de décision sous forme de schéma.

Deux questions de second rang affinent : le coût d’un changement tardif (élevé pousse vers le prédictif), et la disponibilité de l’utilisateur (faible rend l’agile difficile, quelle que soit la nature du produit).

Quand chaque méthode perd

Lisez ce tableau comme une liste de vérifications au moment du cadrage : si votre projet coche une case de la deuxième colonne pour la méthode envisagée, changez de méthode ou traitez le risque dès le départ.

PERT, Lean, PRINCE2 : méthodes ou outils ?

Les listes de « méthodes de gestion de projet » mélangent des démarches et des outils. Trois noms reviennent souvent.

• PERT et chemin critique sont des techniques de planification : un réseau de tâches et de dépendances, un calcul des dates au plus tôt et au plus tard, une identification des tâches sans marge. Elles servent dans une cascade comme dans un hybride, et s’affichent le plus souvent sous forme de diagramme de Gantt.
• Le Lean est une démarche d’amélioration continue née dans l’industrie automobile : supprimer les gaspillages, fluidifier le flux. Il inspire Kanban, mais il pilote une production, pas un projet borné dans le temps.
• PRINCE2 est un cadre de gouvernance de projet, d’origine britannique : il organise le projet en étapes de management, avec des rôles et des points de décision. Il se combine avec une réalisation en cascade ou en agile.

Aucun ne remplace le choix entre prédictif, adaptatif et hybride : ils s’y ajoutent.

Ce que la méthode ne choisit pas pour vous

Une méthode de gestion de projet fixe un cadre ; la réussite du projet dépend encore de l’équipe, des objectifs et des ressources qu’on lui donne.

Choisir une démarche ne règle pas tout. Quatre décisions restent à prendre, quelle que soit la méthode.

• Le contrat avec les fournisseurs. Un forfait sur un périmètre figé va avec une démarche prédictive ; une régie ou un contrat par lots d’itérations va avec l’agile. Un contrat au forfait sur un projet agile fabrique des conflits à chaque revue.
• Les rôles. Le chef de projet d’une cascade et le product owner de Scrum n’ont pas les mêmes responsabilités : le premier tient le délai, le coût et le périmètre ; le second ordonne le backlog et répond de la valeur. Dans un hybride, il faut dire qui arbitre entre les deux.
• Les outils. Un diagramme de Gantt pour les jalons, un tableau Kanban pour les tâches de l’équipe, un registre des risques pour tous : la méthode dit ce qu’on suit, pas avec quel logiciel.
• Le niveau de documentation. Le cycle en V en exige beaucoup, l’agile en demande moins mais pas zéro : un produit livré doit rester maintenable par quelqu’un qui n’était pas dans l’équipe.

Le verdict selon votre projet

• Si vous achetez un équipement industriel spécifié

  (ligne, machine, installation) : la cascade, avec un cahier des charges fonctionnel solide et des jalons de recette.

• Si votre produit doit être qualifié ou certifié

  le cycle en V, avec une matrice de traçabilité tenue dès la spécification.

• Si vous développez un logiciel ou un outil interne

  avec des utilisateurs disponibles : l’agile, en sprints d’un mois au plus, ou en flux Kanban pour la maintenance évolutive.

• Si votre projet mêle matériel et logiciel

  l’hybride, avec la frontière écrite dans la note de cadrage et un jalon commun d’intégration.

• Si votre projet dure moins de trois mois avec une équipe de trois personnes

  une liste de tâches, un tableau Kanban et une revue par semaine suffisent ; une méthode lourde coûterait plus que le projet.

Une dernière règle : une méthode se choisit au cadrage et s’écrit. Changer de méthode en cours de route est possible, mais c’est une décision de comité, pas une dérive.