J’ai eu la chance de commencer à travailler sur des projets Informatiques avant que l’Agile ne débarque! Je vous entends déjà vous émouvoir… “Pourquoi la chance ?” “Quoi? Qu’est ce que tu as contre l’Agile? “… Attendez, laissez-moi m’expliquer… et vous dire ce que j’aime dans la méthode Waterfall ou “cycle en V”!
Aux origines de la cascade…
En termes de gestion de projet, il y a de nombreuses approches et méthodologies disponibles. Parfois même on a l’impression que chacun a la sienne (autrement dit, qu’il n’y a pas de méthode). Une des plus courantes et des plus anciennes dans le domaine de l’IT, c’est la méthode Waterfall, ou cascade en français, également appelée “Cycle en V”.
La méthode a été introduite dans les années 50 pour “processer” le développement d’un logiciel militaire. Le point de départ c’est un besoin, une exigence. La méthodologie prévoit ensuite cinq étapes distinctes : la planification, la spécification, la programmation, les tests et la validation.
La méthode Waterfall a été introduite en 1970 par le Dr. Winston W. Royce. Elle doit son nom à sa ressemblance visuelle avec une chute d’eau. Le projet, découpé en phases successives, progresse de haut en bas, comme une cascade. C’est une approche linéaire où chaque étape suit la précédente de manière rigide.
Le principe de cette méthodologie projet c’est bien le côté séquentiel et successif des différentes étapes. Chaque étape doit être complétée avant de passer à la suivante.
Les étapes successives de la méthode Waterfall
L’analyse des besoins est la première étape. Elle est cruciale car elle définit le cadre du projet, ses objectifs et les exigences du client. C’est souvent ce qu’on appelle le Cadrage. Et c’est bête à dire mais c’est sans doute une des étapes les plus importantes. On l’a déjà vu dans d’autres approches, telles que le Lean 6 Sigma (DMAIC). Si on n’est pas clair sur les objectifs et les moyens alloués au projet, c’est en général le meilleur moyen de se planter!
Après le cadrage, la phase de conception démarre. Cette étape transforme les besoins en “spécifications”. Le but ici est, finalement, de traduire le besoin pour le(s) développeur(s). Il faut que le besoin métier soit clairement expliqué et découpé en tâches qui vont pouvoir être “dispatchées” entre les différents membres de l’équipe de développement (ex. les pages seront structurées de telle ou telle façon, les différentes fonctionnalités sont décrites, etc…). La spécification permet en fait aussi de “démultiplier” les ressources utilisées. En effet, c’est le responsable ou l’expérimenté qui va concevoir, écrire ou valider les spécifications qui pourront ensuite être prises en charge par un profil plus junior (on lui “mâche le travail”).
Enfin! La troisième étape arrive et on rentre dans le dur! Les équipes de développement mettent en œuvre ces spécifications pour réaliser (“implémenter” en mauvais français) le produit. Ils développent les différentes pages et fonctionnalités qui ont été spécifiées à l’étape précédente.
Les tests visent ensuite à s’assurer que le produit est sans failles et répond aux exigences initiales. Ces tests sont en général réalisés d’abord par l’équipe de développement avant d’être remis à une équipe de testeurs.
Et finalement on arrive ainsi à l’étape de validation. Cette étape permet au donneur d’ordre initial de valider ce qui a été réalisé. C’est également l’étape qui permet de basculer vers la maintenance du produit. On sort alors du mode projet et on suit la vie du produit après sa mise en service et en utilisation régulière.
Les limites de la méthode Waterfall
Par contre, la rigidité de la méthode Waterfall peut aussi être un inconvénient. Dans un environnement de projet dynamique où les besoins peuvent changer rapidement, la structure linéaire de la méthode Waterfall peut se révéler inefficace. En effet, une fois qu’une phase est terminée, il est difficile de revenir en arrière sans perturber l’ensemble du projet.
De même, la méthode est souvent critiquée pour “l’effet tunnel” qu’elle peut produire. En effet sur des gros projets (IT ou autres), cette approche peut entraîner des délais importants avant d’avoir quelque chose “à montrer” aux utilisateurs… En tout cas quelque chose de plus compréhensible pour eux que des spécifications techniques!!
Ainsi, la méthode Waterfall est souvent comparée à des approches plus flexibles, comme la méthode Agile. Cette dernière, plus itérative, permet des modifications en cours de projet et met en avant les prototypages et les démonstrations régulières.
Pourquoi je dis que j’ai eu la chance de démarrer avec le Waterfall?
A mon sens, c’est une très bonne méthode pour apprendre à travailler. La méthode est certes rigide mais du coup très claire! On a des jalons pour chaque étape; des modèles et des livrables à chaque étape; tout est “cadré”. Idéal pour débuter.
On a tendance à opposer Waterfall et Agile, mais c’est souvent parce qu’on pense qu’Agile signifie Anarchie… et qu’il y a beaucoup de laisser-faire pour les équipes. Dans les faits, il y a surtout de la responsabilisation dans l’Agile et des règles à respecter. Du coup être passé par la case Waterfall sensibilise à la nécessité d’avoir et de respecter des règles du jeu “rigide”.
Je vois aussi un autre avantage à cette méthode par rapport aux approches plus agiles et participatives. C’est celui de “préserver” les équipes techniques. En effet, le séquentiel impose un mode “guichet”: les spécifications doivent arriver prêtes à l’emploi pour les développeurs. Ces derniers appliquent sans se poser (trop) de question. C’est bien sûr un peu réducteur mais d’un autre côté, j’ai pu constater à plusieurs reprises que mettre un développeur directement en face d’un Product Owner n’est pas toujours efficace.
Enfin, la méthode Waterfall reste à mon avis, très utile pour les projets où les exigences sont clairement définies et peu susceptibles de changer. Mais aussi dans les contextes où il y a beaucoup de réglementaire. Car in fine, il faudra bien respecter un cahier des charges et valider les réalisations à l’aune du cahier des charges initial. Si vous prenez la construction d’un avion ou des échanges (par ex interbancaires ou EDI), on mesure bien l’importance de la “norme” qu’il faut respecter dans le projet.
Ce sont notamment ces qualités qui expliquent que la méthode Waterfall ait été aussi populaire et compte encore des afficionados.
L’importance de la méthode Waterfall dans la gestion de projet est donc indéniable. Sa structure séquentielle donne de l’ordre et de la clarté à la gestion de projet. Chaque phase est clairement définie et dispose de livrables spécifiques, ce qui facilite le suivi du projet. Malgré sa rigidité, elle reste une méthode efficace, surtout dans les contextes où la flexibilité n’est pas nécessaire ou souhaitable.
Pour moi, la méthode Waterfall est un pilier de la gestion de projet et quasiment indispensable quand on démarre. Malgré l’émergence de nouvelles approches, elle conserve une place de choix dans le paysage de la gestion de projet. Elle offre aux chefs de projet un cadre solide et prévisible pour la réalisation de leurs objectifs.
