Comprendre la méthodologie de projet Waterfall et ses 6 étapes

Si l’on remonte aux origines de la gestion de projet moderne, on tombe inévitablement sur la méthodologie waterfall. Cette méthodo est née dans l’industrie lourde, elle a été théorisée pour l’informatique par Winston W. Royce dans les années 1970.

Cette structure de projet est linéaire et elle a été longtemps la norme (et même imposée par la Défense américaine !).

Mais comment fonctionne concrètement ce modèle de gestion projet divisé en 6 phases distinctes ? Je vous explique tout ce qu’il faut savoir sur cette méthode « en cascade ».

Pourquoi c’est important de connaître la méthodologie Waterfall

De plus en plus de projets

Nous connaissons, depuis de nombreuses années, des incertitudes géopolitiques, de grandes avancées technologiques, de nouveaux moyens d’accéder à ces technologies (smartphone, tablette, lunettes connectées, smartwatch …), ainsi que de nouvelles manières de s’informer et de se divertir.

Ces projets sont de plusieurs types :

• Des projets portant sur l’organisation du travail.
• Des projets pour le changement et le déploiement de logiciels.
• Des projets sur leur infrastructure informatique.
• Des projets sur la gestion des données.
• …

Ordo ab Chao : du chaos naît l’ordre

(je connais quelques locations latines 😁)

Afin d’organiser et de structurer les projets, les organisations ont besoin d’avoir une structure. Une séquence d’action qui permet de savoir ce qui est fait, ce qu’il reste à faire et qui le fait.

La méthodologie projet Waterfall (que l’on peut traduire par l’approche cascade) est un pilier de la gestion de projet, car elle offre un cadre de travail extrêmement structuré et prévisible. Je détaillerai les différentes phases d’un projet type Waterfall.

Cette méthodologie projet est particulièrement appropriée pour les projets où les exigences sont fixes et où les objectifs clairement définis dès le départ.

Voici les grands avantages de l’approche en cascade :

• Les objectifs sont clairs : l’attendu final du projet est clair et défini, du coup, les équipes impactées par le projet ont une vision nette et précise du résultat final.
• Budget et calendrier définis. La planification rigoureuse permet d’estimer les coûts totaux ainsi que les délais.
• Discipline. Du fait de la rigueur du planning, de la rigueur budgétaire et également de la rigueur de la méthode, l’équipe projet doit être très disciplinée. Chaque phase projet doit être validée avant de passer à la suivante, ce sont des passages de jalon.
• Facilité à intégrer de nouveaux membres dans l’équipe projet. Comme la méthodologie est très rigoureuse avec les différentes phases, un nouvel arrivant dans le projet peut facilement se repérer sur le calendrier projet et à quoi ressemble l’attendu final. C’est un gros avantage.

Il existe bien sûr d’autres méthodologies projet, comme le cycle en V, la méthodologie de projet Agile, Scrum, Prince 2, Kanban, le diagramme de Gantt. J’en parlerai dans d’autres articles 😉.

Maintenant que vous comprenez l’importance d’une méthodologie projet ainsi que les avantages de l’approche waterfall, je vous propose de faire un peu d’histoire.

Origine de la méthodologie Waterfall

Le modèle Waterfall est considéré comme la méthode de gestion de projet la plus ancienne.

Les premières traces de cette méthodologie Waterfall (j’ai l’impression d’être un archéologue) ont été trouvées dans les industries de la construction et de l’ingénierie lourde. Des industries dans lesquelles les contraintes matérielles imposaient de ne pas revenir sur la conception une fois les travaux commencés.

L’apparition dans le domaine logiciel de Waterfall est généralement attribuée à l’informaticien Winston W. Royce en 1970 (voir ci dessous), bien qu’il y ait des doutes qui soient exprimées sur la vraie date de création de ce modèle.

Extrait de Managing the Development of Large Software Systems (Voici le papier d’origine)

Ce qui est paradoxal, c’est que, dans son article original, Royce présentait ce modèle linéaire (étape par étape) comme risqué et préconisait l’utilisation de boucles de rétroaction (tiens, tiens), mais l’industrie a principalement adopté la version linéaire pour son grand avantage de contrôle.

Pour la petite histoire, le département de la Défense des États-Unis a ensuite cimenté cette approche en l’adoptant comme norme (DOD-STD-2167) en 1985 pour le développement de logiciels critiques.

Comment est organisée cette méthodologie

L’organisation de la méthodologie Waterfall repose sur une séquence divisée en phases distinctes. Comme vous devez l’avoir compris, Waterfall est un mot anglais qui se traduit par le mot cascade.

Ce qui implicitement induit que le flux de travail ne se déplace que dans une seule direction (pas de rétroaction donc … hélas).

Voici les six phases de la méthodologie Waterfall :

1. Analyse des des besoins: Collecte de toutes les données et les besoins du client pour écrire un cahier des charges.
2. Conception et spécification: Traduction des besoins en spécifications techniques et fonctionnelles. Cela comprend l’architecture logicielle et les maquettes.
3. Développement : Les travaux commencent soit par le codage, soit par la construction (si on n’est pas dans une phase logicielle). Ces travaux se basent scrupuleusement sur les spécifications fonctionnelles.
4. Tests / Vérifications : Une équipe (différente de celle qui code) teste et vérifie la conformité du produit par rapport aux exigences initiales et identifie les bugs. C’est dans cette phase qu’ont lieu les UAT (User Acceptance Testing), c’est la phase de recette finale avant le déploiement.
5. Déploiement : Livraison du produit final à l’utilisateur ou mise en production.
6. Maintenance : C’est un suivi pour corriger les bugs et faire les mises à jour nécessaires.

Les limites de la méthodologie Waterfall

Waterfall a beau être la première méthodologie de gestion de projet, cela n’en fait pas une méthode sans défauts. La plupart d’entre eux s’expliquent par la rigidité de ce système.

Voici les défauts d’un projet Waterfall :

L’effet tunnel

Vous avez dû entendre cette expression de temps en temps. Un silence radio s’installe souvent entre la définition des besoins et le déploiement du projet. Les utilisateurs finaux sont au courant que le projet commence, puis ils sont sans nouvelles pendant plusieurs mois (voir années) et ensuite, d’un coup, on leur annonce que le projet va être livré.

L’inflexibilité

Les nouvelles idées ou nouveaux besoins sont très peu pris en compte.

Je parlais précédemment des boucles de rétroaction, c’est à dire qu’il y a des allers-retours réguliers entre ceux qui sont développés et les besoins des utilisateurs finaux et bien, cela n’existe pas dans une gestion de projet en cascade.

Une fois que le cahier des charges est rédigé, il est extrêmement difficile et coûteux de revenir dessus pour intégrer de nouveaux cas d’usage ou s’adapter à une évolution du marché.

Des tests tardifs

Comme la phase de tests n’intervient qu’au moment du cycle 4, les erreurs de conception ainsi que les difficultés d’utilisation sont découvertes trop tard.

Les retours des utilisateurs finaux (lors des UAT) sont également bien tardifs, ce qui peut entraîner l’échec du projet ou une adoption partielle de leur part.

L’obsolescence

Pour les projets particulièrement longs, il y a un risque réel de livrer un produit qui ne répond plus aux besoins réels de l’utilisateur qui ont pu évoluer depuis le début du projet.

Comment faire de l’accompagnement au changement pour un projet avec la méthodologie waterfall

L’accompagnement au changement dans un projet Waterfall doit s’appuyer sur la structure rigide du modèle.

Voici les piliers pour bien faire le change management sur ce type de projet.

Clarifier les rôles

Chaque organisation et également chaque méthodologie de projet attribuent des rôles qui parfois diffèrent.

Mettez au clair les rôles de chacun afin de bien identifier vos interlocuteurs clés.

En règle général, dans un projet de type Waterfall, c’est la maîtrise d’ouvrage (MOA), qui définit les besoins, et la maîtrise d’oeuvre (MOE), qui est le responsable de la technique.

Vous aurez besoin de ces deux interlocuteurs, ainsi que du chef de projet, tout en vous assurant qu’ils ont bien la vision métier et technique pour réaliser vos livrables clés, comme l’analyse d’impacts, la stratégie d’accompagnement au changement …

Tirez profit de la documentation

Le grand avantage de la méthodologie projet Waterfall, c’est que la documentation est présente et structurée.

Profitez de cette documentation afin d’élaborer vos plans de formation, les cas d’usage et toute la documentation de formation utilisateurs avant la phase de déploiement.

Impliquer les utilisateurs

Bien que cette méthodologie projet n’implique que très peu les utilisateurs finaux, vous pouvez « finauder ».

Par finauder, j’entends de faire en sorte que des utilisateurs clés soient présents lors de la définition des besoins et lors de la recette finale (UAT : tests d’acceptation utilisateur).

Grâce à cette implication, vous saurez ce que pensent les utilisateurs, vous saurez là où ils seront à l’aise.

Donner de la visibilité

L’autre grande force d’un projet de type Waterfall, c’est sa prévisibilité. Vous savez quand termine et quand commence chaque phase projet.

Profitez-en pour donner de la visibilité en communiquant dès qu’une phase se termine et qu’une nouvelle commence en partageant des informations comme :

• Un rappel sur le cycle projet en cours / qui s’achève
• Pourquoi ce projet : donner du sens et du contexte
• Expliquez ce qu’il s’est passé dans l’achèvement de la phase
• Faites témoigner des personnes du projet.

Pour conclure, la méthodologie waterfall est loin d’être une relique du passé. Même si elle peut sembler rigide face aux nouvelles approches plus « agiles », elle reste une référence pour les projets où la visibilité et la maîtrise budgétaire sont prioritaires.

Si vos besoins sont clairs et figés (comme dans le BTP ou l’industrie lourde), c’est une structure rassurante qui apporte cet « ordre » nécessaire face au chaos. En revanche, gardez bien en tête sa principe limite : l‘effet tunnel est son talon d’Achille.

À vous de « finauder » pour maintenir le lien avec vos utilisateurs tout au long de cette fameuse cascade ! 😉