Méthodologie en cascade : définition, processus et exemples
Nous vivons dans un monde où la méthodologie Agile est omniprésente. Des célèbres géants de la technologie aux petites startups, tout le monde l’utilise pour développer ses produits. En apprenant l’Agile, il se peut que vous soyez déjà tombé sur le terme « méthodologie en cascade ».
La plupart des chefs de projet qui utilisent Agile considèrent la cascade comme une méthodologie dépassée, qui n’a plus sa place en 2023. Mais est-ce vraiment le cas ?
En tant que chef de produit senior, j’ai une grande expérience à la fois en Agile et en cascade. En défense de la méthodologie en cascade, entrons dans le détail de ce qu’elle est, de son fonctionnement et de quand il est pertinent de l’utiliser.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Qu’est-ce que la méthodologie de gestion de projet en cascade ?
La cascade représente le concept de gestion des projets de développement en les divisant en phases distinctes, chacune étant menée de façon séquentielle.
Bien que la division de grands ensembles de travail en petites parties soit un concept utilisé par l’homme depuis la nuit des temps, la « naissance » officielle de la méthodologie en cascade a eu lieu bien plus tard : en 1970, lorsque le Dr Winston W. Royce, éminent informaticien de l’époque, l’a décrite dans son ouvrage « Managing the Development of Large Software Systems ».
Depuis lors, elle est devenue le principal mode de gestion de projet des entreprises logicielles jusqu’à ce que le monde commence à se tourner vers l’Agile au début des années 2000.
À quoi ressemble le cycle de vie du développement logiciel (SDLC) avec la méthode en cascade
Contrairement à la structure itérative et incrémentale de l’Agile, le SDLC pour la cascade a à la fois un point de départ et une fin bien définis. Il divise tout le processus de création d’un logiciel en cinq phases ou jalons différents, et le travail sur une phase ne commence pas tant que la précédente n’est pas terminée. Visuellement, cela ressemble à ceci :
Le travail s’écoule d’une phase à l’autre, puis on atteint la fin et le projet est considéré comme « terminé »—ce qui rend l’approche visuellement similaire à une cascade (d’où le nom).
Voyons maintenant chacune de ces phases dans cette approche linéaire, et en quoi elles consistent.
Phase n°1 : collecte des besoins
Tout commence par la collecte des besoins du projet auprès de l’ensemble des parties prenantes. Durant cette phase, les chefs de projet produisent un document exhaustif et très détaillé qui couvre tous les aspects du projet, des exigences fonctionnelles jusqu’au budget ou au plan de gestion des risques.
Phase n°2 : conception de la solution
En se basant sur les besoins recueillis dans la phase précédente, l’équipe projet commence à formuler puis concevoir la solution. Le terme « conception » ici englobe la structure technique du produit (conception système), la conception visuelle et des interactions (UI/UX design), ainsi que la conception physique (si le produit est physique).
Phase n°3 : implémentation
C’est le moment où le codage effectif a lieu. Vos membres de l’équipe de développement commencent à construire le produit en s’appuyant sur les livrables créés lors de la phase de conception.
Contrairement à l’Agile, où l’on peut librement changer le périmètre du projet ou la conception en permanence, la cascade suppose que vous suivrez le cahier des charges et que votre produit n’« évoluera » pas durant la phase d’implémentation.
Phase n°4 : tests
Dès que l’équipe d’ingénierie logicielle a fini de construire le produit, nous pouvons passer à la phase suivante du plan de projet : les tests. Votre équipe va alors vérifier le produit pour identifier des bugs, failles de sécurité ou défauts d’expérience utilisateur.
Pendant la phase de tests, vous vérifiez également si les fonctionnalités et la conception du produit final correspondent bien au cahier des charges rédigé lors des deux premières phases.
Phase n°5 : déploiement et support après mise en production
En supposant que votre équipe a identifié et corrigé tous les problèmes majeurs du produit, il est temps de publier la version finale et de remettre la solution à vos clients et utilisateurs finaux.
Vos programmeurs passeront alors en mode maintenance, en recueillant en continu les retours clients, en effectuant les corrections nécessaires et en sortant de nouveaux correctifs et mises à jour de votre produit.
Et voilà, votre projet est terminé et vous pouvez passer au suivant !
Alors, devez-vous utiliser la méthode en cascade ?
Si vous, chef de projet adepte de l’Agile (je suppose que c’est votre cas), pensez que cette méthode est dépassée et ne devrait jamais être envisagée, je (avec tout le respect) ne suis pas d’accord avec vous et j’affirme que l’approche en cascade est en réalité le meilleur choix pour certains types de projets.
Laissez-moi vous donner quelques exemples pour illustrer mon propos.
Études de cas : la méthode en cascade à l’œuvre
Comme pour tout concept complexe, quelques exemples concrets peuvent aider à comprendre comment la méthodologie fonctionne dans la réalité. Voici donc quelques illustrations tirées de projets réels (auxquels j’ai pu participer… ou pas) pour vous aider à mieux saisir l’application de l’approche en cascade sur le terrain.
Cas n°1 : Une plateforme de dédouanement pour le gouvernement égyptien
Imaginez que vous faites partie d’une entreprise qui a remporté le contrat pour moderniser les systèmes de commerce international et de dédouanement d’un pays relativement grand, comme l’Égypte.
Ce que souhaite le gouvernement égyptien, c’est un système d’autorité portuaire qui gérera tous les manifestes des navires (un document douanier qui répertorie toutes les marchandises et passagers à bord d’un navire) entrant dans les différents ports d’Égypte.
De plus, ils veulent que ce système s’intègre directement à un autre produit que vous devez développer, lequel traitera toutes les déclarations en douane (aussi appelées SAD ou documents administratifs uniques) du pays. Ce formulaire est très complexe à remplir pour le citoyen lambda ; ils souhaitent donc que vous l’automatisiez pour eux.
L’Égypte possède un système complexe de taxes et de droits de douane, dont les taux varient en fonction du type de marchandises importées, de leur quantité et d’autres facteurs. Comme les citoyens n’ont aucune idée de ces taux, le gouvernement veut que votre application calcule automatiquement tous les montants selon leurs déclarations, puis leur permette de payer directement en ligne avec leur carte bancaire.
Cela ressemble à un projet colossal, pas vrai ? Lors de la finalisation des détails de mise en œuvre, votre direction (et peut-être même le gouvernement égyptien) va vous solliciter, vous le chef de projet, pour savoir comment organiser la réalisation de ce projet.
Pourquoi et comment utiliser la méthode en cascade dans ce cas :
Tout ce que vous développez pour un gouvernement national sera très probablement fondé sur une loi ou une décision ratifiée par le parlement. Ces décisions reprendront tous les aspects du projet, des termes généraux (coût, calendrier…) aux moindres détails de fonctionnement.
On dirait vraiment un cahier des charges, comme dans la première phase de la méthode en cascade, non ? Effectivement, et cela signifie aussi que vous ne pourrez pas vraiment changer en cours de route les détails de mise en œuvre, la conception ou les exigences, comme cela se fait en développement Agile.
J’ai dirigé un produit de ce genre. Un jour, nous avons remarqué qu’en modifiant légèrement la logique métier, l’expérience utilisateur pourrait être grandement améliorée. Nous avons immédiatement partagé notre idée avec le représentant de la douane qui travaillait avec nous.
Eh bien, il a dit non. On pourrait penser qu’il avait tort de refuser une telle suggestion, mais il avait une bonne raison de ne pas pouvoir accepter.
Nos petits ajustements auraient modifié la formule que le gouvernement utilise pour calculer les taxes sur un produit donné. Or, cette formule étant fixée par la loi, la changer aurait nécessité de réunir tout le parlement national et de voter sa modification.
More Articles
- L’IA dans la recherche utilisateur : comment l’IA transforme la compréhension des utilisateurs
- Livraison de produits pensés pour le global sans casse-tête mondial : comment intégrer la localisation dans votre workflow produit
- L’IA dans la planification de sprint : Comment l’IA améliore l’efficacité de l’équipe
Cas n°2 : Le système de commande de vol de l’hélicoptère Ingenuity
Ingenuity est le nom que la NASA a donné à l’hélicoptère high-tech qu’ils ont construit et envoyé sur Mars en 2021. Voici à quoi ressemble le petit bijou.
Imaginez que vous étiez l’heureux chef de projet chargé de développer le logiciel de cette prouesse technologique. Plus précisément, votre équipe devait coder la commande de vol de l’hélicoptère.
Créer un système de commande de vol pour un aéronef (surtout un hélicoptère) est extrêmement difficile. Il faut prendre en compte toutes les lois de la physique qui interagissent avec l’appareil durant le vol et calculer la vitesse de rotation des pales, leur angle, et des millions d’autres paramètres.
Mais votre mission est encore plus ardue : votre hélicoptère devra voler au-dessus d’une autre planète, dont l’atmosphère est 100 fois moins dense que celle de la Terre.
Pourquoi et comment utiliser la méthode en cascade dans ce cas :
À mon avis, la gestion de projet en cascade est ici votre seule option. À l’opposé de la méthode Agile, où l’on construit une petite version (MVP), on la déploie, on l’utilise sur le terrain, on recueille des retours d’expérience puis on améliore progressivement la solution, la moindre erreur aurait ici des conséquences bien trop importantes pour que l’on puisse se permettre ce type de flexibilité.
Pouvez-vous vraiment prendre le risque de créer un MVP bogué d’Ingenuity et de l’envoyer à 140 millions de miles sur Mars ? Il n’y a tout simplement aucun moyen que quiconque accepte cela.
Vous devrez donc construire la version finale et ensuite tester minutieusement tous ses systèmes avant d’avoir la confiance nécessaire pour le placer dans une fusée direction la planète rouge.
Le modèle en cascade est bien vivant !
En fait, il est bien plus populaire que vous ne l’imaginez : la moitié des projets dans le monde utilise encore cette méthodologie de développement.
Bien que l’avènement de l’Agile ait amélioré la vie de nombreux chefs de projet en leur permettant de lancer des produits bien plus tôt et de s’appuyer sur les retours des utilisateurs, la méthode en cascade reste une méthodologie précieuse à adopter pour les projets avec peu de flexibilité et une faible tolérance aux bogues.
J’espère que notre exploration de la méthodologie en cascade vous a plu. Si vous souhaitez en savoir plus sur l’Agile, voici ce que je peux vous proposer :
- Notre guide sur la gestion de produit Agile.
- La compilation des meilleures pratiques pour la gestion de portefeuille Agile.
- Notre sélection des meilleurs outils de gestion de produit Agile.
Ce ne sont que trois des nombreux guides et articles que nous proposons sur la gestion de produit et de projet. Pour en découvrir davantage, abonnez-vous à notre newsletter.
