Qu'est-ce que Waterfall en termes simples ?
Waterfall est une approche linéaire et séquentielle de la gestion de projet où vous terminez entièrement une phase avant de passer à la suivante – comme l'eau qui coule le long d'une série de marches. Vous recueillez toutes les exigences en premier, puis concevez, puis construisez, puis testez, puis déployez. Il n'y a pas de retour en arrière. C'est l'approche 'mesurer deux fois, couper une fois' : une planification extensive en amont pour éviter les changements ultérieurs.
Waterfall répond à la question : 'Comment livrer un résultat prévisible lorsque les exigences sont claires et stables ?'
Le flux linéaire : Pourquoi on l'appelle Waterfall
Waterfall tire son nom de la représentation visuelle de son processus – comme l'eau qui cascade le long d'une falaise, vous ne pouvez pas remonter le courant. Une fois qu'une phase est validée avec l'approbation des parties prenantes, vous passez irréversiblement à la suivante. Revenir en arrière est coûteux, nécessitant souvent des processus formels de contrôle des changements et des retouches.
Le modèle Waterfall a été décrit pour la première fois par Winston W. Royce dans un article de 1970 sur le développement logiciel (bien que, ironiquement, il le critiquait plutôt que de le défendre). Il est devenu la méthodologie dominante car il reflétait la façon dont les produits physiques étaient construits depuis des siècles – de l'architecture à la fabrication.
Ce modèle est issu de la fabrication et de la construction où les livrables physiques rendent l'itération coûteuse. Vous ne pouvez pas 'dé-couler' du béton, déconstruire un pont ou rappeler un million d'unités fabriquées à moindre coût. L'hypothèse est que les exigences peuvent être entièrement définies en amont et resteront stables.
Les 5 phases de Waterfall (en détail)
Chaque phase a des livrables spécifiques qui doivent être complétés et approuvés avant que la phase suivante ne commence. Cela crée des jalons clairs et une documentation à chaque étape.
Collecte et analyse des exigences
Toutes les exigences sont collectées, analysées et documentées en détail en amont. Cela aboutit généralement à un document d'exigences commerciales (BRD) ou à une spécification des exigences logicielles (SRS) complet que les parties prenantes approuvent. L'objectif est de capturer chaque fonctionnalité, contrainte et critère d'acceptation avant le début de la conception. Les changements après cette phase déclenchent des processus formels de contrôle des changements.
Conception du système
Sur la base des exigences, les architectes et les concepteurs créent des spécifications techniques détaillées. Pour les logiciels, cela inclut l'architecture du système, les schémas de base de données, les conceptions d'interface et la documentation technique. Pour la construction, cela inclut les plans, les calculs d'ingénierie et les spécifications des matériaux. Cette phase produit le 'plan' qui guide l'implémentation.
Implémentation (Construction)
La phase de construction ou de codage réelle. Les développeurs, ingénieurs ou constructeurs créent le produit selon les spécifications de conception. En logiciel, le code est écrit module par module. En construction, le travail physique commence. La clé : les constructeurs suivent le plan exactement comme spécifié, avec un minimum de déviation.
Vérification (Tests)
Les tests et l'assurance qualité valident que le produit répond aux exigences initiales. Les testeurs comparent la fonctionnalité réelle aux documents d'exigences. Les bugs sont enregistrés, corrigés et retestés. Cette phase se poursuit jusqu'à ce que le produit réponde aux critères d'acceptation prédéfinis. Les tests ont lieu après la fin de la construction – pas pendant.
Déploiement et maintenance
Le produit achevé est déployé ou livré au client. Le projet se clôture formellement avec la documentation et le transfert. La maintenance commence – gestion des corrections de bugs, des mises à jour et du support opérationnel. Le produit entre dans son cycle de vie opérationnel, souvent géré par une équipe différente.
La promesse "blindée" : La prévisibilité
La plus grande force de Waterfall est la prévisibilité. Parce que tout est planifié en amont, vous pouvez répondre à trois questions critiques avant le début des travaux : 'Combien cela coûtera-t-il ?' 'Quand sera-ce terminé ?' et 'Qu'est-ce qui sera exactement livré ?' C'est pourquoi les directeurs financiers, les services d'approvisionnement et les agences gouvernementales préfèrent souvent Waterfall – cela permet des contrats à prix fixe, des prévisions budgétaires et une responsabilité claire.
⚠️ Le hic : Cette promesse ne tient que si la portée ne change pas. Au moment où les exigences changent en cours de projet, la certitude des coûts et des délais s'évapore – souvent de manière spectaculaire.
La courbe du coût du changement
L'un des concepts les plus importants dans Waterfall est de comprendre comment le coût des changements s'intensifie à mesure que le projet progresse. Corriger un bug ou modifier une exigence coûte exponentiellement plus cher dans les phases ultérieures :
| Phase | Relative Cost | Why |
|---|---|---|
| Exigences | 1x | Modifier un document est peu coûteux |
| Conception | 5x | La refonte impacte plusieurs systèmes |
| Implémentation | 10x | Réécrire du code ou reconstruire est coûteux |
| Vérification | 20x | Les bugs trouvés nécessitent des tests de régression |
| Maintenance | 100x | Les changements en production affectent les utilisateurs |
En revanche, l'Agile maintient ce coût relativement stable car les changements sont attendus et incorporés continuellement à travers de courtes itérations.
Avantages et inconvénients de Waterfall
Avantages
- Jalons et livrables clairs et prévisibles
- Facile à comprendre et à gérer pour les organisations traditionnelles
- Les exigences bien documentées soutiennent la conformité et les audits
- Permet des contrats à prix fixe et une budgétisation précise
- Fonctionne bien lorsque les exigences sont vraiment stables et bien comprises
- Transferts clairs entre équipes spécialisées (concepteurs, développeurs, testeurs)
Défis
- •Découverte tardive des problèmes – les tests ont lieu à la fin
- •Difficile et coûteux d'adapter les changements d'exigences
- •Les utilisateurs ne voient pas le produit fonctionnel avant très tard
- •Risque de livrer quelque chose que les utilisateurs ne veulent pas réellement
- •Le processus lourd en documentation peut ralentir les progrès
- •Long délai de mise sur le marché car rien n'est livré tant que tout n'est pas terminé
Quand utiliser Waterfall
Waterfall est le bon choix lorsque certaines conditions sont remplies :
Use Waterfall When:
- •Les exigences sont parfaitement claires et peu susceptibles de changer
- •La technologie est mature et bien comprise
- •La conformité réglementaire exige une documentation préalable étendue
- •Vous travaillez avec des contrats à prix fixe nécessitant des spécifications détaillées
- •Les livrables physiques rendent l'itération coûteuse (construction, fabrication)
- •Les parties prenantes ont besoin d'engagements fermes en matière de budget et de calendrier dès le départ
Quand Waterfall pourrait ne pas être idéal
- •Les exigences sont floues ou susceptibles d'évoluer
- •Vous construisez des produits innovants où l'apprentissage est essentiel
- •La pression du temps de mise sur le marché exige une livraison rapide
- •Les utilisateurs doivent fournir des retours pendant le développement
- •L'environnement du projet est dynamique et imprévisible
Exemple concret : Projets de construction
La construction d'un pont est le projet Waterfall par excellence. Avant le début de la construction, les ingénieurs passent des mois (parfois des années) sur les exigences : analyse du trafic, calculs de charge, évaluations d'impact environnemental et approbations des parties prenantes. Ensuite, des conceptions détaillées sont créées – chaque boulon, poutre et câble est spécifié. Ce n'est qu'après l'approbation des plans que la construction physique commence. Vous ne pouvez pas couler les fondations, décider à mi-chemin que le pont devrait être 20 % plus long et itérer à partir de là. Le coût du changement dans la construction physique rend Waterfall non seulement approprié, mais nécessaire.
Points clés à retenir
- 1Waterfall est séquentiel et linéaire – chaque phase se termine avant que la suivante ne commence
- 2Il excelle lorsque les exigences sont stables, bien définies et peu susceptibles de changer
- 3Le coût des changements augmente de manière exponentielle à mesure que le projet progresse
- 4Il offre une prévisibilité pour la budgétisation, la planification et la conformité
- 5Pas un échec – juste conçu pour des circonstances différentes de l'Agile
- 6Souvent combiné avec l'Agile dans des approches hybrides pour des projets complexes
