Le modèle en cascade (waterfall) est un modèle de processus séquentiel qui découpe un projet en phases successives, des exigences jusqu’à l’exploitation. Chaque phase ne démarre qu’une fois que la précédente a livré son résultat. Winston W. Royce a décrit cette séquence en sept étapes à la conférence IEEE WESCON de 1970 et jugeait lui-même sa forme pure risquée.
Qu’est-ce que le modèle en cascade ?
Le modèle en cascade est un modèle de processus linéaire dans lequel un projet parcourt ses phases une seule fois et dans un ordre fixe. Le résultat d’une phase constitue l’entrée de la suivante. Dans un diagramme de Gantt, cela dessine l’escalier typique qui donne son nom au modèle.
Quatre éléments font d’un projet un modèle en cascade :
- des phases avec un début et une fin clairs, par exemple la conception ou les tests ;
- des livrables par phase, comme le cahier des charges, les spécifications ou le rapport de tests ;
- des jalons à la fin de chaque phase, où le client ou la direction de projet valide le résultat (voir l’entrée du glossaire sur les jalons en gestion de projet) ;
- des dépendances fin-début entre les phases : la phase 2 démarre à la fin de la phase 1.
D’où vient la méthode en cascade ?
La méthode en cascade vient du génie logiciel. Winston W. Royce l’a présentée en 1970 dans son article Managing the Development of Large Software Systems (Proceedings IEEE WESCON, août 1970, pages 1 à 9). Sa figure 2 montre sept étapes : exigences système, exigences logicielles, analyse, conception du programme, codage, tests et exploitation.
Royce jugeait cette séquence pure dangereuse. Juste sous la figure, il écrit : « I believe in this concept, but the implementation described above is risky and invites failure » (je crois à ce concept, mais la mise en œuvre décrite est risquée et appelle l’échec). Son argument : les tests en fin de cycle sont le premier moment où le système se comporte réellement. Si un défaut de conception y apparaît, le projet revient au point de départ, et Royce prévoit alors jusqu’à 100 % de dépassement de délai ou de coût.
Comme remède, il recommande cinq compléments : concevoir le programme en premier, documenter la conception, le faire deux fois (d’abord en pilote), planifier et surveiller les tests, impliquer formellement le client. Royce n’emploie jamais le mot « cascade ». Selon l’état actuel des connaissances, il apparaît pour la première fois en 1976 chez Thomas E. Bell et T. A. Thayer, dans une contribution à la 2e International Conference on Software Engineering qui cite Royce.
Quelles sont les phases du modèle en cascade ?
En pratique, le modèle en cascade compte le plus souvent six phases : exigences, conception, réalisation, tests, mise en service et maintenance. Royce distinguait sept étapes ; les manuels regroupent souvent exigences système et logicielles. L’essentiel est le livrable de chaque phase.
| Phase | Livrable | Jalon en fin de phase |
|---|---|---|
| 1 Exigences | Cahier des charges : que doit faire le système ? | Cahier des charges validé |
| 2 Conception | Spécifications et architecture : comment le construire ? | Conception validée |
| 3 Réalisation | Système complet et fonctionnel | Gel du code |
| 4 Tests | Rapport de tests, défauts corrigés | Recette prononcée |
| 5 Mise en service | Système installé, utilisateurs formés | Mise en production |
| 6 Maintenance | Corrections et mises à jour en exploitation | Fin du contrat ou remplacement |
À quoi ressemble un projet en cascade ? Un exemple
Un éditeur de logiciels développe pour un promoteur immobilier un portail client où les acheteurs consultent leurs choix de finitions et les dates du chantier. Le promoteur paie un prix forfaitaire et le cahier des charges est figé avant la signature. Le projet dure 18 semaines jusqu’à la mise en production.
Portail client en mode cascade
Six phases, cinq jalons, toutes les phases liées fin-début
Trois chiffres de l’exemple montrent comment le modèle calcule :
- Retard : si le promoteur valide le cahier des charges avec une semaine de retard, la mise en production passe de la semaine 18 à la semaine 19. Toutes les phases sont sur le chemin critique, donc chaque retard repousse la fin.
- Poids des phases : la réalisation occupe 8 semaines sur 18 (44 %), les tests seulement 3 semaines (17 %).
- Retour en arrière : si les tests de la semaine 15 révèlent un défaut de conception, l’équipe refait conception (3 semaines), réalisation (8 semaines) et tests (3 semaines). Cela fait 14 semaines ; la mise en production passe de la semaine 18 à la semaine 32, soit 78 % plus tard. C’est précisément le risque contre lequel Royce mettait en garde.
Existe-t-il un modèle de projet en cascade ?
Oui. Merlin Project propose deux modèles gratuits qui représentent un projet par phases avec jalons. Le modèle Développement de logiciel découpe un développement en phases d’évaluation, de conception, de spécification, de développement, de tests et de livraison ; des jalons de décision comme « Spécification terminée » séparent les phases. Le modèle Maison individuelle applique la même logique à un planning de chantier, de l’avant-projet au gros œuvre.
Modèle en cascade pour Merlin Project
Le modèle contient les phases typiques d’un projet de développement avec des jalons entre elles. Téléchargez le fichier, supprimez les phases inutiles et ajoutez vos activités. Le modèle existe en français, anglais, allemand et espagnol.
Ouvrir le modèle Développement de logiciel
Vous démarrez sans Merlin Project ? Reprenez la structure de l’exemple sous forme de tableau. Chaque ligne devient une activité ou un jalon, et la colonne « Prédécesseur » définit la dépendance fin-début :
| N° | Activité | Type | Durée | Prédécesseur |
|---|---|---|---|---|
| 1 | Recueillir les exigences | Activité | 3 semaines | aucun |
| 2 | Cahier des charges validé | Jalon | 0 | 1 |
| 3 | Conception et spécifications | Activité | 3 semaines | 2 |
| 4 | Conception validée | Jalon | 0 | 3 |
| 5 | Réalisation | Activité | 8 semaines | 4 |
| 6 | Gel du code | Jalon | 0 | 5 |
| 7 | Tests système et recette | Activité | 3 semaines | 6 |
| 8 | Recette prononcée | Jalon | 0 | 7 |
| 9 | Mise en service et formation | Activité | 1 semaine | 8 |
| 10 | Mise en production | Jalon | 0 | 9 |
| 11 | Maintenance | Activité | continue | 10 |
Quand utiliser la méthode en cascade, et quand l’éviter ?
La méthode en cascade convient lorsque les exigences sont fixées avant le démarrage et changent peu pendant la réalisation. Les cas typiques sont la construction, les projets soumis à autorisation administrative et les contrats au forfait. Sur une maison, le toit vient après les murs, car la structure n’admet pas d’autre ordre.
La cascade convient lorsque
- client et équipe peuvent fixer les exigences par écrit avant le démarrage,
- les autorités, les auditeurs ou le contrat exigent des validations à des points fixes,
- un prix forfaitaire ou une date fixe est convenu,
- des dépendances physiques imposent l’ordre (d’abord les fondations, puis les murs).
La cascade ne convient pas lorsque
- les exigences naissent des retours des utilisateurs,
- l’équipe doit montrer tôt une version intermédiaire qui fonctionne,
- le marché ou la technique évoluent pendant le projet,
- un test tardif entraîne un retour en arrière coûteux, comme dans l’exemple.
Cascade, agile ou hybride : quelle différence ?
La cascade planifie tout le projet à l’avance et livre à la fin ; les méthodes agiles comme Scrum planifient en cycles courts et livrent un résultat utilisable après chaque cycle. La gestion de projet hybride combine les deux : phases et jalons pour le cadre, travail agile à l’intérieur d’une phase.
| Critère | Cascade | Agile (p. ex. Scrum) | Hybride |
|---|---|---|---|
| Planification | Tout le projet avant le démarrage | Par sprint, un mois au plus | Phases au départ, tâches par phase |
| Changements | Par demande de modification formelle | À tout moment via le backlog | Dans le cadre de la phase |
| Implication du client | Aux jalons | À chaque revue de sprint | Aux jalons et aux revues |
| Livraison | Une fois à la fin | Après chaque sprint | Par phase ou version |
| Vue typique | Diagramme de Gantt | Tableau Kanban | Gantt et Kanban couplés |
Notre article sur la gestion de projet hybride explique comment les équipes construisent ce mélange.
Planifier un projet en cascade dans Merlin Project
Merlin Project représente la structure en cascade dans la vue Répartition du travail : la structure à gauche, le diagramme de Gantt à droite. Pour reproduire l’exemple :
- Ouvrez Présentation > Répartition du travail > Entrée et créez chaque phase comme groupe. Avec Ctrl+Cmd+→, vous indentez les activités sous leur phase.
- Ajoutez un jalon à la fin de chaque phase avec Insertion > Jalon (Cmd+Alt+M). Il apparaît sous forme de losange dans le diagramme de Gantt.
- Sélectionnez phases et jalons dans leur ordre et choisissez Structure > Lien > Fin - Début (Ctrl+Cmd+L). Merlin Project lie la sélection dans l’ordre.
- Activez Présentation > Afficher le chemin critique pour faire ressortir la chaîne qui fixe la mise en production.
- Le jour de la validation, saisissez cette date dans le champ Date de référence des réglages du projet. La vue Comparaison plan/réel (temps) montre alors chaque écart par rapport à cette ligne de base.
Phases et jalons dans la Répartition du travail
L’exemple de la documentation Merlin montre un déménagement de bureaux en trois phases. Un jalon suit chaque groupe, et les flèches du diagramme de Gantt montrent les dépendances fin-début.
Une ligne de base sans étape supplémentaire
Merlin Project conserve tout l’historique du projet dans le document. Vous n’avez donc pas à enregistrer de ligne de base à la main : une date dans le champ Date de référence suffit, et des barres de référence grises montrent la période planifiée à ce moment-là. Détails dans la leçon sur la comparaison plan/réel.
Pour la phase de réalisation, la voie hybride vaut le détour. Appuyez sur F2 pour afficher la vue détaillée et choisissez-y le tableau Kanban. Sélectionnez la phase en haut : le tableau du bas n’affiche que ses activités. Faites glisser une carte de « Backlog » vers « Achevé », et Merlin Project fixe l’avancement de l’activité à 100 % ; la barre du diagramme de Gantt l’affiche aussitôt.
Cascade en haut, Kanban en bas
En haut, le plan des phases avec jalons ; en bas, le tableau Kanban de la phase sélectionnée. Les deux vues montrent les mêmes activités, et chaque modification apparaît aussitôt dans les deux.
Si vous avez des questions sur cet article de blog ou si vous souhaitez en discuter, nous attendons avec impatience votre contribution dans notre forum.
Questions fréquentes
Quel est un exemple de modèle en cascade ?
Un portail client au cahier des charges figé : exigences (3 semaines), conception (3 semaines), réalisation (8 semaines), tests (3 semaines) et mise en service (1 semaine) se suivent. Chaque phase se termine par un jalon comme « Cahier des charges validé ». La mise en production intervient après 18 semaines. La construction d’une maison individuelle suit la même logique.
Quelles sont les étapes de la méthode waterfall ?
En pratique, six : exigences, conception, réalisation, tests, mise en service et maintenance. Winston W. Royce listait sept étapes en 1970, car il séparait exigences système et exigences logicielles. Chaque phase livre un résultat vérifiable, comme le cahier des charges ou le rapport de tests.
Existe-t-il un modèle gratuit de gestion de projet en cascade ?
Oui. Le modèle « Développement de logiciel » pour Merlin Project contient des phases avec jalons de décision, le modèle « Maison individuelle » un planning de chantier par phases. Les deux se téléchargent gratuitement dans la rubrique des modèles. Merlin Project s’essaie gratuitement pendant 30 jours.
Qui a inventé le modèle en cascade ?
La séquence remonte à Winston W. Royce, qui l’a décrite en 1970 dans « Managing the Development of Large Software Systems ». Royce jugeait lui-même la forme pure risquée et recommandait des boucles de retour et un pilote. Le nom « cascade » apparaît d’abord en 1976 chez Thomas E. Bell et T. A. Thayer.
Quelle est la différence entre cascade et cycle en V ?
Les deux enchaînent les phases de façon séquentielle. Le cycle en V associe en plus à chaque phase de conception un niveau de test correspondant, par exemple les exigences à la recette et l’architecture aux tests d’intégration. La cascade classique place tous les tests dans une seule phase en fin de projet.
La méthode en cascade est-elle agile ?
Non. La méthode en cascade planifie tout le projet avant le démarrage et livre une seule fois à la fin. Les méthodes agiles comme Scrum planifient en sprints d’un mois au plus (Scrum Guide 2020) et livrent après chaque sprint. Les approches hybrides utilisent les phases en cascade comme cadre et travaillent en agile à l’intérieur d’une phase.
