Méthode waterfall et cycle en V : quand les choisir

La méthode waterfall, ou modèle en cascade, est une approche de gestion de projet qui enchaîne des phases strictement séquentielles — recueil du besoin, conception, réalisation, tests, mise en service — chacune devant être achevée et validée avant que la suivante ne commence. Le cycle en V en est une variante, organisée autour de la validation.

Les deux sont presque toujours racontés de la même manière : une méthode ancienne et rigide, corrigée par l’agilité. Cette lecture escamote deux choses. D’abord que la cascade et le cycle en V ne sont pas le même modèle. Ensuite qu’il subsiste des cas où le séquentiel est le choix rationnel. Sans plaidoyer pour autant : les limites du waterfall sont réelles et elles sont dites ici.

Méthode waterfall : définition et phases du modèle en cascade

Le principe tient en une règle : on n’entame pas une phase tant que la précédente n’est pas terminée et validée. Le projet descend palier après palier, sans retour en arrière prévu — d’où l’image de la cascade. On parle aussi de gestion de projet traditionnelle ou d’approche prédictive : périmètre, coût et délai sont réputés connus dès le départ, et le pilotage consiste à tenir cette trajectoire.

Ce qui fait tenir le modèle, c’est le document. Chaque phase produit un livrable écrit — cahier des charges, dossier de conception, plan de tests — validé formellement, qui sert de contrat d’entrée à la suivante. Cette validation, appelée jalon, est le vrai mécanisme de contrôle : c’est là que le projet est autorisé à continuer.

Les phases du modèle en cascade

Le découpage varie selon les auteurs, mais l’ossature reste stable :

• Expression du besoin : recueil des exigences, dans un cahier des charges.
• Conception : architecture générale, puis conception détaillée des composants.
• Réalisation : développement ou fabrication, sur la foi des seuls documents.
• Tests : vérification de la conformité à ce qui a été spécifié.
• Mise en service : déploiement, reprise des données, formation.
• Maintenance : corrections et évolutions une fois le produit en exploitation.

Point à retenir pour lire les schémas qui circulent : les tests forment ici une phase, après la réalisation. C’est ce point que le cycle en V modifie.

Ce que Royce a réellement écrit en 1970

Le modèle est attribué à l’ingénieur américain Winston W. Royce, dans une communication intitulée Managing the Development of Large Software Systems, présentée à la conférence IEEE WESCON en août 1970. Premier fait qui surprend : le mot « waterfall » n’y figure nulle part. Il a été accolé plus tard au schéma en escalier de sa figure 2.

Le second contresens est plus lourd : Royce ne recommande pas ce déroulé purement séquentiel. Il le décrit, puis écrit noir sur blanc qu’il le juge dangereux.

Je crois en ce concept, mais la mise en œuvre décrite ci-dessus est risquée et invite à l’échec. (« I believe in this concept, but the implementation described above is risky and invites failure. »)

Suivent cinq correctifs destinés à rendre le modèle viable, dont faire le travail deux fois — une première version tenant lieu de simulation — et impliquer le client entre la définition du besoin et la livraison. Le prototype jetable et la présence du client en cours de route annoncent ce que l’agilité systématisera trente ans plus tard : le modèle en cascade tel qu’il s’est diffusé est une version amputée de son texte fondateur.

Cycle en V : les deux branches et ce qui le distingue de la cascade

Le cycle en V, ou V-model en anglais, est un modèle séquentiel issu de l’ingénierie système, la discipline qui conçoit des systèmes complexes mêlant matériel et logiciel. Il reprend l’enchaînement de la cascade mais le plie en deux : la branche descendante décompose le besoin jusqu’au composant, la branche montante recompose et vérifie. Le point bas du V est la réalisation.

La branche descendante : du besoin au composant

La descente procède par niveaux d’abstraction décroissants : besoin utilisateur, spécification du système, architecture, conception détaillée. La particularité du modèle est qu’à chaque palier on rédige en même temps le plan de test qui servira à valider ce palier lors de la remontée. Le test cesse d’être une activité de fin de projet : il devient un livrable de la conception.

La branche montante : chaque niveau a son test

La remontée exécute ces plans dans l’ordre inverse, en assemblant le système. À chaque étage, le test répond au niveau de conception qui lui fait face :

• Tests unitaires — face à la conception détaillée : chaque composant fait-il ce qui était prévu ?
• Tests d’intégration — face à l’architecture : les composants communiquent-ils comme spécifié ?
• Tests système — face à la spécification : l’ensemble est-il conforme au document de référence ?
• Recette — face au besoin initial : le produit répond-il au problème posé par l’utilisateur ?

Cette symétrie produit une matrice de traçabilité qui relie chaque exigence au test qui la couvre. Aucune exigence ne peut échapper à une vérification sans que cela se voie — c’est exactement ce qu’un auditeur vient chercher.

Cascade ou cycle en V : la différence en une phrase

Dans la cascade, les tests sont une phase, placée à la fin. Dans le cycle en V, ils sont une structure : chaque niveau de conception définit, en même temps qu’il s’écrit, le critère qui le déclarera valide. Le corps de connaissances de l’ingénierie système range les deux dans la même famille, l’approche de développement séquentielle, le V se distinguant par la place donnée à la vérification. Le cycle en V est une cascade qui a pris au sérieux la question « comment saurons-nous que c’est bon ? ».

Waterfall vs agile : ce qui s’oppose réellement

L’opposition est presque toujours résumée à la documentation : le waterfall en produirait trop, l’agile pas assez. Le résumé est mauvais. La fracture porte sur le moment où l’on s’engage sur le périmètre. Un projet séquentiel décide de ce qui sera livré au tout début, quand l’information est la plus pauvre. Une démarche agile diffère cette décision et la révise à mesure que l’usage renseigne l’équipe : c’est la dernière des 4 valeurs agiles, « l’adaptation au changement plus que le suivi d’un plan », dont le texte figure dans mon article sur le manifeste Agile.

Le reste en découle : spécifications complètes et avenants d’un côté, livraisons fréquentes et priorités révisables de l’autre. Ce ne sont pas deux niveaux de rigueur, mais deux réponses à une même question — à quel moment accepte-t-on de décider ?

Critère	Modèle en cascade	Cycle en V	Approche agile
Origine	Génie logiciel, années 1970	Ingénierie système	Manifeste de 2001
Découpage	Phases successives	Phases appariées à des niveaux de test	Itérations courtes et répétées
Place des tests	Une phase, après la réalisation	Un niveau par phase de conception, défini en amont	Continus, dans chaque itération
Engagement sur le périmètre	Au départ, dans le cahier des charges	Au départ, dans les spécifications	Révisé à chaque itération
Coût d’un changement tardif	Très élevé, passe par un avenant	Très élevé, impacte la traçabilité	Absorbé par la réorganisation des priorités
Première version utilisable	En fin de projet	En fin de projet	Dès les premières itérations

Les limites réelles du séquentiel

Elles se ramènent toutes à la longueur de la boucle de retour. Une erreur sur le besoin — une fonctionnalité que personne n’utilisera, un parcours mal compris — est commise en phase 1 et découverte en phase 5, quand tout a été conçu et construit autour d’elle. La correction ne coûte plus une ligne dans un document : elle coûte une reprise en chaîne. C’est l’effet tunnel, avec une conséquence financière négligée : la valeur n’arrive qu’à la fin, la dépense a commencé le premier jour.

Deux effets secondaires aggravent le tableau. Puisque tout changement passe par un avenant, chacun a intérêt à sur-spécifier au départ « au cas où », ce qui gonfle le périmètre de fonctionnalités décidées sans preuve. Et sur dix-huit mois, le marché et l’équipe ont changé avant la livraison : c’est ce qu’un framework agile cherche à traiter, et la raison d’être de ce qu’on appelle une transformation agile.

Les chiffres sur l’échec des projets : une source à écarter

Presque tous les articles sur le waterfall citent les mêmes pourcentages de projets « en échec », issus du CHAOS Report du Standish Group. Ces chiffres ont fait l’objet d’une critique publiée dans IEEE Software par J. Laurenz Eveleens et Chris Verhoef, The Rise and Fall of the Chaos Report Figures : en appliquant les définitions du Standish Group à leur propre jeu de données, les auteurs les jugent trompeuses, unilatérales, faussant la pratique de l’estimation et aboutissant à des chiffres dépourvus de sens. Je ne les reprends donc pas : les limites décrites ci-dessus se démontrent sans eux.

En vidéo : « Waterfall et Cycle en V » (La gestion de projet facile), une mise en regard des deux modèles séquentiels, en français.

Quand la méthode waterfall reste le bon choix

Le séquentiel n’est pas un retard de modernité : c’est la réponse aux projets où l’on ne peut pas apprendre en livrant. Trois situations le justifient encore, et elles se cumulent souvent.

Une contrainte réglementaire ou de sûreté

Dans le dispositif médical, l’aéronautique, le ferroviaire ou l’automobile, un organisme extérieur exige la preuve que chaque exigence est couverte par une vérification, et que rien n’a changé sans que la chaîne soit rejouée. Le cycle en V produit cette preuve par construction : sa matrice de traçabilité est le dossier de conformité. Le corps de connaissances de l’ingénierie système cite d’ailleurs l’aérospatial, la santé, la défense et le génie civil comme terrains naturels du séquentiel. Ce n’est pas un choix de culture, c’est une condition d’accès au marché.

Un produit matériel ou une livraison irréversible

Une carte électronique, un moule d’injection, la mise à feu d’un lanceur : le coût du changement n’y est pas progressif, il est discret et parfois définitif. L’itération repose sur une hypothèse qui n’est plus vérifiée ici, celle d’un correctif quasi gratuit et immédiat. C’est aussi ce qui rend la notion de MVP inopérante sur un produit physique certifié : la version minimale doit déjà être conforme, donc complète.

Une prestation au forfait, un périmètre réellement figé

Un contrat au forfait engage un prestataire sur un périmètre, un prix et une date. Le modèle qui correspond à cet engagement est séquentiel : poser un cadre itératif par-dessus sans toucher au contrat ne crée que de la confusion, puisque l’équipe est invitée à réviser des priorités que le contrat lui interdit de réviser. Le sujet est contractuel avant d’être méthodologique. Il en va de même des périmètres réellement fermés — migration à iso-fonctionnalités, mise en conformité dictée par un texte : rien à découvrir, seulement à exécuter proprement.

Le test honnête tient en trois questions, à poser avant de choisir :

• Le besoin est-il réellement connu ? Non pas « avons-nous un cahier des charges », mais « quelqu’un a-t-il déjà fait exactement cela ».
• Un retour d’usage changerait-il quelque chose ? Si la réponse est non, l’itération n’apporte que du surcoût de coordination.
• Une obligation externe impose-t-elle la séquence ? Un référentiel, un auditeur, un contrat, une contrainte physique de fabrication.

Ce que l’agile a emprunté au séquentiel

L’agilité n’a pas fait table rase du séquentiel : elle en a conservé les mécanismes, ramenés à une échelle plus petite et plus fréquente.

• La définition écrite du besoin est passée du cahier des charges aux user stories et à la spec produit : plus courtes et révisables, mais écrites.
• Le jalon de validation est devenu la revue de fin d’itération : même fonction, autoriser la suite, à quelques semaines au lieu de quelques mois.
• Les tests dérivés des exigences, cœur du cycle en V, se retrouvent dans les critères d’acceptation écrits avant le développement.
• La planification subsiste sous la forme d’un backlog produit ordonné, qui est un plan, simplement révisable.
• La boucle elle-même précède l’agilité : la roue de Deming formalisait déjà l’amélioration par cycles courts.

L’hybride, la situation la plus fréquente

Peu d’organisations pratiquent l’un ou l’autre à l’état pur : un cadrage séquentiel en amont — budget, macro-périmètre, jalons contractuels — puis une réalisation itérative dans cette enveloppe. Le montage tient à une condition : que l’engagement pris en haut soit exprimé en objectifs, pas en liste de fonctionnalités. Ce qui échoue, c’est la juxtaposition non dite — une équipe en sprints sous un comité de pilotage qui exige toujours le périmètre complet à date fixe. Le cadre de travail vient ensuite et pèse moins : les différences entre Scrum et Kanban, ou entre méthode agile et Scrum, ne règlent aucun problème contractuel.

Un mot pour finir. Après plus de dix ans passés dans des environnements produit, je constate que le modèle affiché décide rarement de l’issue : ce qui décide, c’est le contrat et le coût d’une erreur découverte tard. Une organisation engagée sur un périmètre figé à douze mois travaille en séquentiel, quel que soit le nom donné à ses réunions. Le waterfall n’est pas dépassé : il est juste dans un domaine étroit, et source d’ennuis partout ailleurs. Savoir de quel côté de cette frontière se situe votre projet vaut mieux que de choisir un camp.

FAQ — Tout savoir sur le waterfall et le cycle en V

Quelle est la différence entre la méthode waterfall et le cycle en V ?

Les deux sont séquentiels, mais ils traitent les tests différemment. Dans la cascade, les tests forment une phase unique placée après la réalisation. Dans le cycle en V, chaque niveau de conception définit dès sa rédaction le test qui le validera, et la remontée du V exécute ces tests dans l’ordre inverse de la descente.

Quelles sont les étapes de la méthode waterfall ?

Six phases enchaînées : expression du besoin, conception, réalisation, tests, mise en service et maintenance. Chacune se termine par une validation formelle, appelée jalon, qui autorise le passage à la suivante. Le découpage exact varie selon les secteurs, mais cette ossature se retrouve dans toutes les variantes du modèle en cascade.

Comment traduit-on waterfall et cycle en V ?

« Waterfall » se traduit par modèle en cascade, méthode en cascade ou approche séquentielle. Le cycle en V se dit V-model ou V-shaped model en anglais. On rencontre aussi les expressions gestion de projet traditionnelle et approche prédictive, qui désignent la même famille de modèles.

Quels sont les avantages et les inconvénients de la méthode waterfall ?

Ses avantages : une trajectoire lisible dès le départ, une traçabilité complète entre exigences et vérifications, et un engagement contractuel simple à formuler. Ses inconvénients : une boucle de retour très longue, un coût de changement tardif élevé, un effet tunnel avant la première livraison, et une incitation à sur-spécifier le périmètre au départ.

Dans quels secteurs le cycle en V est-il encore utilisé ?

Partout où une autorité extérieure exige de démontrer la couverture de chaque exigence par un test : dispositif médical, aéronautique, ferroviaire, spatial, nucléaire, défense, automobile embarqué. Il reste également courant dans les projets d’ingénierie mêlant matériel et logiciel, où une correction après fabrication coûte beaucoup plus cher qu’un correctif logiciel.

Peut-on combiner la méthode agile et le waterfall ?

Oui, et c’est le montage le plus répandu : un cadrage séquentiel en amont, puis une réalisation itérative à l’intérieur de l’enveloppe ainsi fixée. La condition est que l’engagement pris en haut porte sur des objectifs et un budget, pas sur une liste exhaustive de fonctionnalités à date fixe — sinon l’équipe reçoit l’ordre de s’adapter et l’interdiction de changer quoi que ce soit.