Choisir entre la méthode agile et le modèle en cascade (ou « waterfall »), c’est choisir entre tout planifier d’abord puis construire d’une traite, ou construire par cycles courts en ajustant le plan au fil de ce que l’on apprend. Pour la plupart des projets d’application et de site web, la réponse honnête se situe entre les deux : une phase de cadrage et de design figée, puis des cycles de développement courts avec un budget clair. Ce guide explique les deux méthodes en mots simples, les compare côte à côte, montre laquelle convient aux sites web, aux applications et à la marque, et se termine par les contrats adaptés à chacune et une check-list pour choisir.
Agile et cascade : de quoi parle-t-on, simplement ?
Avant de les comparer, il faut débarrasser ces deux mots de leur jargon. Ni l’un ni l’autre n’est une religion. Chacun est une façon de décider quand vous vous engagez sur ce que vous construisez, et combien il en coûte de changer d’avis ensuite.
Le modèle en cascade : décider, puis construire
Le modèle en cascade déroule un projet comme une suite d’étapes. Les besoins sont recueillis et validés, puis viennent le design, le développement, les tests et la mise en ligne. Chaque étape commence quand la précédente est terminée, et revenir en arrière coûte du temps et de l’argent.
Sa force est la prévisibilité. Vous connaissez le périmètre, le prix et la date avant que la première ligne de code soit écrite. Sa faiblesse est qu’il suppose que vous savez tout dès le départ. Quand un vrai utilisateur découvre le produit pour la première fois, vers la fin, il est tard pour apprendre qu’un écran clé ne lui convient pas.
L’agile : construire, apprendre, ajuster
La méthode agile découpe le travail en cycles courts, en général d’une ou deux semaines, souvent appelés sprints. Chaque cycle se termine par quelque chose qui fonctionne et que vous pouvez voir et tester. La liste de ce qu’il faut construire ensuite (le backlog) est réordonnée après chaque cycle, en fonction de ce que l’on a appris.
Sa force est l’adaptabilité. Les erreurs apparaissent tôt, quand elles coûtent peu, et vous pouvez vous arrêter à tout moment avec quelque chose d’utilisable. Sa faiblesse est que le périmètre et le coût final ne sont pas fixés au départ, ce qui inquiète certains acheteurs et fait d’un responsable peu disponible côté client un vrai risque : l’agile exige quelqu’un chez vous qui prend des décisions chaque semaine.
Agile ou cascade : le comparatif
Le tableau ci-dessous présente les différences concrètes que ressent un acheteur, pas la théorie.
| Cascade | Agile | |
|---|---|---|
| Périmètre | Fixé au départ | Évolue cycle après cycle |
| Budget | Prix forfaitaire pour un périmètre fixe | Fixe par cycle ; le total suit le périmètre |
| Quand vous voyez quelque chose qui fonctionne | Vers la fin | Toutes les une à deux semaines |
| Coût d’un changement | Élevé, via des avenants | Faible, absorbé dans le cycle suivant |
| Votre temps nécessaire | Important au début et à la recette | Régulier, chaque semaine |
| Documentation | Détaillée, rédigée en amont | Plus légère, tenue à jour en cours de route |
| Idéal quand | Les besoins sont clairs et stables | Les besoins vont évoluer au fil de l’apprentissage |
| Risque principal | Bien construire la mauvaise chose | Dérive du périmètre et du budget |
Aucune des deux colonnes n’est « meilleure ». Le modèle en cascade échange la souplesse contre la certitude ; l’agile échange la certitude contre la souplesse. Le bon choix dépend de ce que vous savez déjà.
Quelle méthode pour les sites web, les applications et le travail de marque ?
Le type de projet pèse davantage dans le choix de la méthode que les préférences de l’agence. Voici comment se répartissent en général les trois types de projets que nous menons le plus souvent.
Sites web
Un site vitrine ou un site d’entreprise a en général une forme bien connue : un ensemble de pages, un système de gestion de contenu, des formulaires, la visibilité dans les moteurs de recherche. Une grande partie peut être planifiée en amont, ce qui se prête à une structure proche du modèle en cascade pour le cadrage, l’arborescence et le design.
C’est au développement que l’agilité aide. Les contenus arrivent tard, une page a besoin d’une nouvelle section, le client voit la page d’accueil dans un navigateur et veut que le hero fonctionne autrement. Construire par cycles courts sur un site de préproduction permet d’intégrer ces changements sans avenant formel pour chacun. Si vous préparez un budget, notre guide Combien coûte un site internet ? Le guide 2027 détaille où va l’argent à chaque étape de la création de sites web.
Applications
Les applications, qu’il s’agisse d’une app mobile ou d’une application web avec comptes, données et logique métier, sont le terrain où le modèle en cascade pur échoue le plus souvent. Les utilisateurs se comportent d’une manière qu’aucun cahier des charges ne prévoit, les plateformes changent leurs règles, et la fonctionnalité la plus précieuse est souvent celle que personne n’avait notée au départ.
Pour une application, l’agile est presque la norme. Une première version utilisable (le produit minimum viable, ou MVP) est confiée à de vrais utilisateurs le plus tôt possible, et les cycles suivants sont orientés par ce qu’ils en font. Le modèle en cascade garde sa place pour les parties fixes : le modèle de données, les exigences de sécurité, les intégrations avec les systèmes existants et tout ce qu’un régulateur lira.
La marque
L’identité de marque est un tout autre sujet. Elle passe par la stratégie, le concept et la réalisation, et chaque étape dépend de la décision précédente. On ne peut pas raisonnablement faire un logo « en sprints » : une identité se choisit comme un tout, parmi un petit nombre de pistes réfléchies.
Le travail de marque suit donc plutôt une séquence par étapes, proche du modèle en cascade, avec des points de validation, mais en gardant la possibilité de revenir d’un pas quand un concept ne tient pas. Quand nous avons créé l’identité de Nothing To Eat, le logo et sa construction ont été arrêtés d’abord, puis le site web et ses écrans sont venus ensuite, construits sur des décisions déjà prises. Si vous vous demandez où s’arrête l’identité et où commence la perception, notre article Image de marque et identité de marque : la différence, et comment réduire l’écart va plus loin.
Les approches hybrides qui fonctionnent
La plupart des projets réels sont hybrides, qu’on les appelle ainsi ou non. La question utile est de savoir quelles parties sont fixes et lesquelles sont souples. Trois schémas reviennent sans cesse.
Cadrage au forfait, puis sprints
C’est le schéma que nous recommandons le plus. La première phase est un cadrage au périmètre et au prix fixes : objectifs, utilisateurs, contenus, choix techniques, arborescence ou carte des fonctionnalités, et design des écrans clés. Vous savez exactement ce que cela coûte et ce que vous obtiendrez.
Le développement se déroule ensuite en sprints à partir d’un backlog priorisé, avec un budget par sprint et une estimation globale. Vous gardez la certitude là où elle compte (la direction et le design) et la souplesse là où elle rapporte (le développement et les détails).
Cascade avec de l’agile à l’intérieur
Certaines organisations ont besoin d’un contrat fixe et d’une date de lancement fixe : un organisme public, un lancement lié à un événement, un produit réglementé. L’enveloppe extérieure est alors un modèle en cascade, avec un périmètre signé et des jalons, mais chaque jalon est construit en cycles internes courts avec des démonstrations. Le client voit quelque chose qui fonctionne toutes les deux semaines environ, sans que le contrat change de forme.
Agile autour d’un socle fixe
Pour une application, un schéma courant consiste à figer les parties coûteuses à modifier (architecture, modèle de données, sécurité, design system) et à garder en agile tout ce qui repose dessus. Les fonctionnalités montent et descendent librement dans le backlog, parce que les fondations ne bougent pas avec elles.
Quels contrats pour chaque méthode ?
La méthode choisie doit correspondre au contrat signé. Un décalage, par exemple une démarche agile dans un contrat au forfait rigide, est la source de litiges la plus fréquente que nous voyons.
Le forfait
Le forfait convient au modèle en cascade et aux phases à périmètre fixe comme le cadrage ou l’identité de marque. L’agence porte le risque de l’estimation : le périmètre doit donc être écrit avec précision (pages, fonctionnalités, séries de modifications, ce qui est inclus et ce qui ne l’est pas).
Tout ce qui sort de ce périmètre écrit devient un avenant : un court document qui décrit le changement, son coût et son effet sur la date, signé avant le début du travail. Les avenants ne sont pas un piège. Ce sont eux qui gardent un forfait équitable pour les deux parties.
La régie
La régie (temps passé) convient à l’agile. Vous payez le temps réellement passé, en général par sprint ou par mois, selon un taux convenu. Le périmètre peut évoluer librement, parce que le prix suit le travail.
Votre protection, c’est la visibilité, pas un total fixe : un backlog que vous pouvez lire, une démonstration à la fin de chaque cycle, un cumul suivi par rapport à l’estimation, et le droit d’arrêter après n’importe quel sprint en gardant tout ce qui a été construit. Un plafond par mois ou par phase est une demande raisonnable.
Le forfait par sprint
Une voie médiane consiste à fixer un prix pour chaque sprint, avec une équipe et une durée fixes, et une liste souple de ce qu’il contient. Vous savez ce que coûte chaque quinzaine ; l’agence sait sur quoi elle s’engage ; le contenu de chaque sprint est convenu à son lancement.
Si vous réfléchissez à qui confier le travail autant qu’à la façon de contractualiser, notre comparatif Jeune agence ou agence établie : laquelle choisir ? liste les questions à poser aux deux.
Que change l’IA dans cet arbitrage ?
Une partie de l’argument historique en faveur du modèle en cascade tenait au coût : changer de direction voulait dire refaire du travail à la main. C’est moins vrai qu’avant. Chez Odduel, l’IA prend en charge une grande partie de la production répétitive (composants du design system, code front-end, premiers jets, cas de test, premiers jets de traduction) : un cycle produit davantage de choses qui fonctionnent, et un changement de direction coûte moins cher à absorber.
Ce qui ne devient pas moins cher, c’est le jugement. La stratégie, le concept, la direction artistique, la voix de la marque et la relecture finale restent un travail humain, et c’est là que va le budget. D’après notre expérience, cela fait pencher davantage de projets vers les cycles courts : quand construire va vite, mieux vaut voir tôt de vrais écrans que peaufiner un cahier des charges qu’aucun utilisateur n’a testé. C’est ainsi que nous menons nos projets de développement d’applications et de design UX/UI depuis Barcelone et São Paulo.
Comment choisir ? Une check-list
Répondez honnêtement à ces questions. Plus vos réponses tombent à gauche, plus le modèle en cascade vous convient ; plus elles tombent à droite, plus l’agile s’impose.
- Besoins. Pouvez-vous écrire aujourd’hui tout ce que le produit doit faire (cascade), ou en apprendrez-vous l’essentiel par les utilisateurs (agile) ?
- Budget. Vous faut-il un chiffre fixe signé avant le début du travail (cascade), ou pouvez-vous travailler avec un budget mensuel et un cumul suivi (agile) ?
- Échéance. La date est-elle imposée par un élément extérieur (enveloppe en cascade), ou est-ce un objectif que vous pouvez arbitrer contre le périmètre (agile) ?
- Votre temps. Quelqu’un chez vous peut-il relire le travail et prendre des décisions chaque semaine (agile), ou seulement à quelques jalons (cascade) ?
- Utilisateurs. Pouvez-vous mettre une première version entre les mains de vrais utilisateurs (agile), ou rien ne sort-il avant que tout soit terminé (cascade) ?
- Conformité. Un régulateur, une règle d’achat public ou un conseil d’administration exige-t-il un cahier des charges complet en amont (cascade, au moins pour l’enveloppe) ?
- Type de travail. S’agit-il d’une identité de marque (par étapes), d’un site vitrine (hybride) ou d’une application (agile autour d’un socle fixe) ?
Si vos réponses sont partagées, c’est normal. Choisissez une approche hybride et décidez, partie par partie, ce qui est fixe et ce qui est libre.
Questions fréquentes
La méthode agile coûte-t-elle toujours plus cher que le modèle en cascade ?
Non. L’agile peut sembler plus cher parce que le total n’est pas fixé au départ, mais les projets en cascade finissent souvent par payer des avenants et des reprises après la mise en ligne. L’agile consacre le budget à ce dont les utilisateurs ont réellement besoin, et vous pouvez vous arrêter dès que le produit est suffisamment bon. La vraie différence de coût vient de la qualité du pilotage de chacun.
Un contrat au forfait peut-il être agile ?
En partie. Un forfait par phase ou par sprint fonctionne bien avec l’agile, à condition que le périmètre de chacun soit convenu à son lancement. Ce qui échoue, c’est un forfait unique pour une liste fixe de fonctionnalités assorti d’une promesse de souplesse : l’un des deux cède, en général dans un litige.
Quelle méthode pour une refonte de site web ?
En général, une approche hybride. Le cadrage, l’arborescence et le design des pages clés gagnent à être figés et validés ; le développement, la saisie des contenus et les ajustements gagnent à avancer par cycles courts sur un site de préproduction. Le site existant vous apporte beaucoup de connaissances en amont, ce qui rend la partie fixe plus facile à cadrer.
Quelle est la durée d’un sprint dans un projet d’application ?
La plupart des équipes travaillent sur une ou deux semaines. Une semaine garde des retours rapprochés mais laisse peu de place aux fonctionnalités importantes ; deux semaines est l’équilibre courant. Plus que la durée, ce qui compte est que chaque sprint se termine par quelque chose qui fonctionne et que vous pouvez voir et essayer.
Que dois-je fournir dans un projet agile ?
Un product owner de votre côté : une personne qui connaît l’activité, peut fixer les priorités et se rend disponible chaque semaine pour relire le travail et répondre aux questions. Sans elle, l’agile ralentit, parce que l’équipe attend des décisions que personne n’a le pouvoir de prendre.
Si vous avez une application ou un site web en tête et ne savez pas comment le structurer, commencez par un court cadrage au forfait : il vous donne un prix pour le développement, un design sur lequel réagir et les informations pour choisir la méthode en confiance. Découvrez notre approche du développement d’applications, ou parlez-nous de votre projet.
