Le choix entre Agile et Waterfall détermine le modèle de coûts, le profil de risque et le rythme de reporting d'un projet logiciel avant même qu'une seule ligne de code ne soit écrite. Tout le monde a son avis sur la question. Et le plus souvent, privilégier une méthodologie revient à rejeter totalement l'autre.
Imaginez la différence entre un canal et une rivière. Un canal est étudié, budgété et creusé une fois pour toutes, et il achemine l'eau exactement là où vous avez décidé qu'elle devait aller. Une rivière, elle, trace son propre lit et finit par arriver à destination, mais pas forcément par le chemin que vous aviez tracé. Aucune de ces deux méthodes n'est meilleure pour déplacer l'eau. Tout dépend du terrain.
En résumé : utilisez le modèle en cascade lorsque les exigences sont stables, que l'environnement extérieur est peu susceptible de changer et qu'un périmètre et un budget fixes sont plus importants que la capacité d'adaptation. Utilisez l' approche agile lorsque la vision du produit peut évoluer, lorsque vous avez besoin d'un logiciel fonctionnel rapidement, ou lorsque le coût de développement d'un produit inadapté pendant six mois est plus élevé que celui d'une replanification toutes les deux semaines.
Le modèle Waterfall est-il mort ? L'Agile l'a-t-il remplacé ? L'un est-il meilleur que l'autre ? Cet article fait le point sur l'état actuel des deux méthodes, répond aux questions qui se posent réellement lors des réunions de cadrage et explique pourquoi chez Imaginary Cloud nous avons choisi l'Agile plutôt que le Waterfall, et dans quels cas nous ne le ferions toujours pas.
La méthodologie en cascade tire son nom de ses phases séquentielles, disposées de manière descendante à l'image d'une cascade, où chaque étape constitue un maillon entre le début et la fin du projet. Winston Walker Royce l'a décrite en 1970 dans son article Managing the Development of Large Software Systems pour les actes de la conférence IEEE WESCON. À l'origine, elle prévoyait cinq phases distinctes : les exigences, la conception, l'implémentation, la vérification et la maintenance.
Voici l'aspect que les articles comparatifs ont tendance à omettre. Royce a présenté le modèle séquentiel pur comme une version « risquée et vouée à l'échec », avant de consacrer le reste de son article à plaider en faveur d'itérations entre les phases. Ce que la plupart des gens appellent « Waterfall », c'est le schéma, et non l'argumentation qui l'accompagne.
Des variantes ont vu le jour au fil des décennies, mais la logique est restée la même. Une fois une phase terminée, son résultat devient l'élément d'entrée de la suivante, qui débute immédiatement après. Sa simplicité l'a rendue facile à comprendre et à adopter. La méthode Waterfall garantit que chaque phase est achevée avant que la suivante ne commence, évitant ainsi que le développement ne démarre avant la fin de la conception, ce qui est souvent source d'incohérences. Ce modèle repose également sur le postulat qu'il est possible d'estimer le coût et l'effort global d'un projet dès la phase des exigences. Cela reste vrai tant que les exigences elles-mêmes ne changent pas.
Le modèle en cascade n'a jamais été la seule approche possible. Il a toutefois fallu attendre 2001 pour qu'il soit confronté à un changement de paradigme fondamental. Quelle en est la cause ? L'Agilité.
Les principes du développement incrémental étaient déjà utilisés, dispersés au sein de différents processus. Ce n'est qu'en 2001, avec le Manifeste pour le développement agile de logiciels, que l'Agilité telle que nous la connaissons a été introduite et popularisée. Ce document très simple, rédigé par un groupe de développeurs à Snowbird, dans l'Utah, a bouleversé les conventions du développement logiciel en un instant. Soudain, une véritable alternative à la méthode en cascade voyait le jour.
Les cycles de l'Agilité, traditionnellement appelés sprints, apportent de la valeur de manière cumulative, chaque cycle s'inscrivant dans une vision globale menant à l'achèvement du projet. C'est là qu'elle se distingue le plus de la méthode en cascade. Cette approche privilégie la flexibilité. Elle permet des incréments réguliers et réduit le temps consacré à la planification en travaillant par blocs de temps plus courts : des périodes fixes d'une ou deux semaines dans lesquelles le travail est intégré, plutôt que l'inverse. Chaque itération livre un logiciel fonctionnel à sa clôture, en planifiant l'étape immédiate avec plus de précision que les étapes ultérieures.
Le mécanisme qui permet cela est le backlog : une liste ordonnée de tout ce dont le produit pourrait avoir besoin, à partir de laquelle chaque sprint puise les éléments les plus précieux. Le changement est géré en réorganisant cette liste, et non en rouvrant un plan.
De nombreuses variantes adoptent l'Agilité comme philosophie, tout comme des déclinaisons se sont développées autour de la méthode en cascade. DSDM, le développement piloté par les fonctionnalités (FDD), l'Extreme Programming et, probablement la plus populaire, Scrum, s'appuient toutes sur l'Agilité pour mener à bien le développement de logiciels. À vrai dire, l'étiquette importe bien moins que la capacité à réellement reprioriser le backlog, ce que la plupart des utilisateurs omettent discrètement de faire.
Il y a presque autant de personnes pour dire que Waterfall est mort que pour affirmer qu'Agile n'est qu'une tendance insignifiante. Il n'y a rien de mal à avoir des avis divergents. Examinons les faits, car les données ont évolué depuis les enquêtes que la plupart des articles continuent de citer.
Pendant des années, la référence était l'enquête Stack Overflow Developer Survey de 2018, qui situait Agile à environ 85 % et Waterfall autour de 15 %. Ce chiffre a mal vieilli, et non pas parce que Waterfall s'est effondré. Il a vieilli parce que la question a changé. Les enquêtes ultérieures ont cessé de présenter une distinction claire entre les cadres de travail : Les enquêtes plus récentes de Stack Overflow auprès des développeurs ont déplacé leur attention vers les outils et l'adoption de l'IA, et le rapport State of Agile de Digital.ai (le baromètre le plus cité du secteur) a totalement abandonné la question « quel cadre de travail utilisez-vous ? » dans son édition 2025, après dix-sept ans d'utilisation.
Ce qui a remplacé ce duel est une troisième voie évidente : l'hybride. Selon le 18e rapport State of Agile (Digital.ai, 2025), environ 74 % des organisations utilisent désormais des approches hybrides ou développées en interne plutôt qu'un cadre pur unique, contre environ 10 % dix ans plus tôt. Le même rapport révèle que seulement 13 % des entreprises affirment qu'Agile est profondément ancré dans leur fonctionnement ; la plupart le décrivent comme présent, mais pas pleinement opérationnel. Parallèlement, le rapport Pulse of the Profession du Project Management Institute indique depuis des années que plus de la moitié des organisations utilisent encore des méthodes traditionnelles et structurées dans une partie de leur portefeuille.
En y regardant de plus près, l'histoire n'est pas celle de la mort de Waterfall et de la victoire d'Agile. C'est celle du déclin des approches « pures » au profit du juste milieu. Deux conclusions s'imposent :
L'agilité a mis en lumière de réelles faiblesses du modèle en cascade, et cela ne fait aucun doute : la difficulté de corriger les problèmes identifiés lors des phases initiales, et l'obligation de mener tout le processus à terme avant de disposer d'un logiciel fonctionnel, avec une grande part d'incertitude entre les deux. Mais choisir l'un plutôt que l'autre dans le seul but d'être meilleur est une illusion. Cela masque généralement l'absence totale de processus rigoureux.
| Dimension | Modèle en cascade | Approche Agile |
|---|---|---|
| Exigences | Fixes et validées avant le début de la conception | Destinées à évoluer ; affinées à chaque itération |
| Modèle de coût | Estimation globale du projet réalisée au préalable | Estimé par itération en fonction du budget en cours |
| Profil de risque | Concentré à la fin, lors de l'intégration et des tests | Réparti sur l'ensemble des sprints et identifié tôt |
| Documentation | Exhaustive, produite phase par phase | Plus légère, produite là où elle apporte une réelle valeur |
| Implication des parties prenantes | Concentrée au niveau des exigences et de la recette | Continue, avec une revue à chaque sprint |
| Rythme de livraison | Une seule livraison à la fin | Logiciel fonctionnel à la fin de chaque sprint |
| Gestion du changement | Demande de modification formelle, généralement renégociée | Repriorisé dans le backlog lors de la prochaine session de planification |
| Projets les plus adaptés | Périmètre et environnement stables, travaux soumis à de fortes exigences de conformité | Périmètre incertain, marchés en évolution, nouveaux produits |
La méthode Waterfall est le choix le plus judicieux pour les projets stables. La planification approfondie intervient en amont, en tenant compte de tous les facteurs (internes et externes) susceptibles d'influencer l'exécution. Quelle que soit l'envergure du projet, Waterfall est adapté aux environnements qui ne sont pas amenés à évoluer pendant la phase de construction. Pour ce type de travail, Waterfall était la meilleure approche avant l'arrivée de l'Agile, et elle le reste. Si vous pouvez planifier l'intégralité du projet à l'avance dans un environnement à faible risque, le diviser en sprints n'apporte aucune valeur ajoutée. Concentrez-vous plutôt sur le résultat final.
L'Agile est la solution idéale pour les projets à la nature plus flexible et imprévisible. Si la vision du produit est susceptible d'évoluer en fonction de la dynamique du marché, construisez et adaptez-vous avec l'Agile. C'est également la meilleure méthode pour éviter qu'un projet ne s'enlise dans des mois de développement sans résultats concrets. Chaque sprint se termine par un point de contrôle permettant au product owner de tester et de valider le travail accompli. De plus, un MVP s'intègre naturellement dans ce rythme.
Dans les projets évolutifs gérés avec Waterfall, l'absence de points de contrôle crée des risques, car les problèmes identifiés à la fin sont plus complexes à résoudre. Le temps supplémentaire consacré à la planification globale du projet ne garantit pas que la conception et le développement se dérouleront sans accroc jusqu'au terme. La plupart des problèmes sont aussi indésirables qu'imprévisibles.
Avant même de choisir une méthodologie, quatre facteurs déterminent la marche à suivre. Positionnez votre projet sur chaque ligne ci-dessous : plus il se situe à gauche, plus la méthode Waterfall est pertinente ; plus il se situe à droite, plus l'approche Agile s'impose. Un partage équilibré n'est pas une indécision, c'est la preuve qu'une approche hybride est nécessaire.
Choisir entre Agile et Waterfall ne relève pas du simple marketing. Se tromper de méthode, c'est en payer le prix en temps et en efforts. Pour quiconque valide un budget, quatre conséquences sont déterminantes.
La prévisibilité budgétaire. Waterfall vous fournit un chiffre unique dès le départ, ce qui est idéal pour un rapport de direction. Ce chiffre n'est toutefois fiable qu'autant que les exigences qui le sous-tendent ; la prévisibilité est réelle si le périmètre est strictement figé, mais illusoire dans le cas contraire. Agile vous offre plutôt un taux de consommation maîtrisé : moins de certitude sur le total, mais plus de visibilité sur la valeur acquise chaque mois.
L'exposition au changement. Avec Waterfall, toute modification après validation fait l'objet d'une demande de changement, renégociée en termes de prix et de délais. Dans les projets à prix fixe que nous avons menés ou repris, c'est généralement lors de ces renégociations que les marges et les plannings s'effritent. Avec Agile, le changement est absorbé par une repriorisation du backlog ; son coût correspond donc à ce qu'il remplace.
Le délai avant la première valeur. Waterfall livre la valeur en une seule fois, à la fin. Agile livre un élément utilisable à chaque sprint, ce qui est crucial lorsque votre produit doit être présenté à des utilisateurs, un régulateur ou un investisseur avant que le périmètre complet ne soit finalisé. C'est aussi pourquoi un MVP s'intègre naturellement dans un processus agile, mais difficilement dans une approche waterfall.
Gouvernance et reporting. Waterfall mesure l'avancement par rapport à un plan, ce qui est rassurant pour un comité de pilotage mais peut masquer les risques d'intégration jusqu'à un stade avancé. Agile rend compte de logiciels fonctionnels, plus difficiles à embellir, et nécessite des parties prenantes capables de s'impliquer toutes les deux semaines plutôt que chaque trimestre.
Peu d'organisations avec lesquelles nous travaillons utilisent l'un ou l'autre de ces modèles sous leur forme pure, ce qui, comme le montrent les données ci-dessus, en fait désormais la majorité plutôt que l'exception. Le modèle que nous observons le plus souvent est une structure par phases au niveau du programme, avec des jalons, des budgets et des points de contrôle de conformité fixes, et une exécution agile au sein de chaque phase. La découverte et l'architecture sont planifiées en amont, puis la réalisation s'effectue par sprints dans ce cadre.
Cela fonctionne lorsque la limite est délibérée. Cela échoue lorsqu'elle est accidentelle : un périmètre, une date et un budget fixes, avec des sprints ajoutés sans aucune marge de manœuvre. Les sprints ne créent pas de flexibilité par eux-mêmes. C'est la capacité à modifier les priorités qui le permet.
Un cas concret permet de rendre les compromis moins abstraits. FlippedNormals, une place de marché dédiée à l'art numérique et aux ressources 3D, nous a sollicités car sa plateforme avait dépassé ses capacités initiales : elle reposait sur WordPress, et cette technologie était devenue un frein à sa croissance. La mission consistait à migrer la place de marché hors de WordPress vers une plateforme sur mesure et à transférer l'infrastructure sur AWS pour la rendre plus évolutive. Le temps était compté, car la pile technologique existante entravait directement l'activité.
C'est précisément le type de projet où le choix de la méthodologie prend tout son sens. Une refonte avec migration pour une place de marché en activité ne peut pas se résumer à un cahier des charges figé et prévisible sur lequel on s'engage une fois pour toutes. C'est une cible mouvante où le coût d'une erreur s'accumule chaque semaine où l'ancienne plateforme reste en ligne. Nous avons donc procédé par étapes, en déployant la nouvelle plateforme par tranches et en tenant l'entreprise informée à chaque étape clé, plutôt que de disparaître pendant trois mois en espérant que tout se passe bien.
Le principe général reste valable quel que soit le chiffre exact : lorsque la technologie devient un frein et que le temps presse, la livraison incrémentale permet de réduire les risques progressivement au lieu de tout miser sur un lancement unique et risqué.
Pourquoi préférons-nous l'Agile au cycle en V ? Laissons de côté les slogans du type « le cycle en V est mort, vive l'Agile ». En règle générale, aucune méthode n'est intrinsèquement supérieure à l'autre, et il est le plus souvent erroné de penser le contraire. Nous avons longtemps pratiqué le cycle en V avant de passer à l'Agile, car nous avons constaté qu'il était plus adapté à la nature de la plupart de nos projets.
Dans notre processus de développement , nous avons adopté Scrum, une déclinaison de l'Agile, avec quelques ajustements pour répondre aux besoins de nos clients. La phase de découverte précède une phase de preuve de concept pouvant aboutir à un MVP, suivie d'une série de sprints apportant une valeur ajoutée incrémentale. Chaque sprint se clôture sur une définition du « terminé » convenue avec le client, afin que ce terme ait la même signification pour les deux parties.
Nos projets concernent principalement de nouveaux produits numériques dont les exigences évoluent au fil de nos apprentissages, ce qui correspond précisément au contexte pour lequel l'Agile a été conçu. Si nous devions gérer une intégration à périmètre fixe avec une échéance réglementaire, le calcul serait différent, et nous le dirions. Ce serait une erreur de considérer cette méthode comme la meilleure pour chaque projet, c'est pourquoi nous l'évaluons et l'adaptons lorsque nécessaire. Les solutions universelles n'ont pas leur place ici.
Oui, et c'est ce que fait la plupart des organisations aujourd'hui. L'approche hybride courante conserve une structure par phases au niveau du programme, avec des jalons fixes et des points de contrôle de conformité, tout en appliquant une livraison agile au sein de chaque phase. Cela fonctionne lorsque la frontière entre le fixe et le flexible est délibérée, mais échoue lorsque le périmètre, les délais et le budget sont tous fixés simultanément.
Aucune n'est intrinsèquement moins chère. Waterfall fournit une estimation unique dès le départ, ce qui est économique si les exigences restent stables, mais coûteux si les demandes de modification s'accumulent. Agile utilise un budget continu et réduit le coût de développement de fonctionnalités inutiles, mais le coût total final est moins prévisible au début.
Waterfall s'adapte plus naturellement à un prix fixe pour un périmètre fixe, car les deux parties s'accordent sur ce qui est acheté avant le début des travaux. Agile peut être contracté à prix fixe en plafonnant le budget et la durée plutôt que le périmètre, avec un backlog priorisé à l'intérieur de cette limite.
Oui. Il reste courant dans les secteurs réglementés, les marchés publics et les projets d'intégration avec des dépendances externes strictes, où la documentation, les points de contrôle et un périmètre défini sont des exigences contractuelles plutôt que des préférences.
Waterfall, ou une approche hybride, est plus fréquente lorsque les auditeurs exigent des preuves à chaque étape. Agile peut répondre aux mêmes exigences, mais la documentation et la traçabilité doivent être intégrées dans la définition du « terminé » (definition of done) plutôt que d'être tenues pour acquises.
Commencez par évaluer la stabilité des exigences. Si le périmètre peut être défini dès maintenant et restera inchangé, Waterfall est viable. Si découvrir une erreur de conception tardive s'avère coûteux, choisissez Agile. Examinez ensuite les modalités contractuelles, la disponibilité des parties prenantes et les preuves de conformité requises — soit les quatre critères mentionnés ci-dessus.
La méthode Waterfall termine chaque phase avant de passer à la suivante et livre le produit final en une seule fois. La méthode Agile fonctionne par itérations courtes qui livrent chacune un logiciel fonctionnel, ce qui permet d'affiner les besoins au fur et à mesure que le produit prend forme.
Waterfall n'est pas mort et Agile n'est pas forcément le meilleur choix en soi. Considérer l'une ou l'autre de ces méthodes comme une évidence est une approche risquée pour le développement logiciel. Ces dernières années, « être Agile » est devenu un argument marketing, et tout ce battage médiatique masque la véritable utilité de Waterfall et d'Agile.
Analysez donc le terrain avant de choisir votre voie. La stabilité des exigences, le coût du changement, le modèle contractuel et les preuves de conformité sont les quatre critères déterminants. Comprenez les besoins de votre projet, choisissez la méthode adaptée et adaptez-vous au fur et à mesure.
Vous réfléchissez au modèle de livraison pour votre prochain projet ? Nous serions ravis d'en discuter avec vous, y compris dans les cas où Waterfall est la solution la plus pertinente. Prendre rendez-vous et nous définirons ensemble l'approche la plus adaptée en fonction de vos exigences, de vos contraintes et de votre modèle contractuel.
Gestionnaire de contenu, éditeur de texte et présentateur d'idées stratégiques, tout en étant un fervent amateur des arts cinématographiques et de la narration visuelle.
People who read this post, also found these interesting:
.webp)
