« Faut-il être agile ? » est sans doute la question la plus mal posée en gestion de projet. Elle sous-entend que l'agilité serait systématiquement supérieure au cycle en cascade (Waterfall) — ce qui est faux. Les deux approches répondent à des contextes différents, et le vrai travail du chef de projet est de choisir celle qui correspond à son terrain, pas à la mode du moment.
Le cycle en cascade : la logique séquentielle
Le modèle en cascade planifie le projet de bout en bout avant de démarrer l'exécution : cadrage, conception, réalisation, tests, livraison — chaque phase se termine avant que la suivante commence.
Ses forces : - Une visibilité complète sur le coût et le délai dès le départ, précieuse pour les projets à budget fixe ou contractuel. - Une documentation exhaustive, utile dans les secteurs réglementés (aéronautique, santé, construction). - Une gouvernance simple à auditer : chaque jalon est validé avant de passer au suivant.
Ses limites : - Une faible tolérance au changement : modifier le besoin en cours de route est coûteux. - Un risque découvert tardivement : les défauts ne sont souvent visibles qu'à la phase de test, loin de leur origine.
L'agilité : la logique itérative
Les approches agiles (Scrum, Kanban...) découpent le travail en cycles courts, avec des livraisons fréquentes et des ajustements continus en fonction des retours.
Ses forces : - Une capacité à absorber le changement de besoin sans tout remettre à plat. - Une valeur livrée plus tôt : on voit un résultat concret dès les premières itérations. - Une amélioration continue intégrée au processus (rétrospectives).
Ses limites : - Une prévisibilité budgétaire et calendaire plus difficile à garantir en amont. - Une exigence forte de disponibilité et d'implication du client/sponsor tout au long du projet. - Une gouvernance qui peut sembler floue pour des organisations habituées au reporting classique.
Les critères concrets pour trancher
| Critère | Plutôt cascade | Plutôt agile |
|---|---|---|
| Le besoin est-il stable et bien compris dès le départ ? | Oui | Non, il va évoluer |
| Le client/sponsor peut-il s'impliquer régulièrement ? | Peu disponible | Disponible et engagé |
| Le secteur impose-t-il une documentation contractuelle stricte ? | Oui | Non |
| La valeur doit-elle être visible rapidement ? | Peu critique | Critique |
| L'équipe est-elle habituée à l'auto-organisation ? | Non | Oui |
Le piège du choix binaire
Dans la pratique, beaucoup d'organisations utilisent des approches hybrides : un cadrage global en amont façon cascade (pour sécuriser budget et périmètre macro), puis une exécution agile en itérations pour la partie la plus incertaine du projet. C'est particulièrement pertinent pour des projets de transformation digitale, où certaines briques (infrastructure, conformité) sont stables et d'autres (expérience utilisateur, fonctionnalités) doivent s'ajuster au fil de l'eau.
Ce qu'il faut retenir
Le choix de méthodologie n'est pas une question d'opinion ni de tendance : c'est une décision de gestion des risques. Posez-vous une seule question avant de trancher : « Où se situe l'incertitude la plus critique de mon projet — sur le quoi, ou sur le comment ? »
Si l'incertitude porte sur le besoin lui-même, l'agilité protège mieux le projet. Si le besoin est stable et que l'incertitude porte sur l'exécution technique, la cascade reste souvent plus efficace. Un bon chef de projet ne défend pas une méthodologie : il l'adapte au risque réel du projet qu'il pilote.