Agile ou cycle en V, la réponse courte
Le cycle en V convient quand le besoin est figé et connu dès le départ, avec un cahier des charges stable. La méthode agile s'impose quand le besoin évolue et demande des ajustements en cours de route. Beaucoup de projets réussissent en hybride, en combinant le cadrage du V et la souplesse de l'agile. Il n'y a pas de bonne méthode dans l'absolu, seulement une bonne méthode pour un contexte donné.
Poser la question comme un duel « agile contre cycle en V » est déjà une erreur de départ. Ce ne sont pas deux camps, mais deux réponses à une même question : que fait-on quand le besoin n'est pas encore parfaitement clair ? Le cycle en V parie qu'on peut tout définir avant de commencer. L'agile parie qu'on apprend en construisant. Votre projet penche naturellement vers l'un ou l'autre selon une seule variable : la stabilité de votre besoin.
Le reste de cette page détaille comment fonctionne chaque méthode, les compare sur cinq critères concrets, puis donne des règles de décision claires, avant d'aborder l'approche hybride, celle que je pratique le plus souvent sur le terrain.
Le cycle en V, comment ça marche
Le cycle en V est une méthode de gestion de projet séquentielle, variante de la méthode en cascade (waterfall). Il déroule le projet en deux temps : une descente où l'on définit (besoin, spécifications, conception), puis une remontée où l'on vérifie (tests unitaires, d'intégration, de recette). Chaque phase de définition a sa phase de test en miroir, ce qui forme un V.
Concrètement, on commence par recueillir le besoin et rédiger un cahier des charges, puis les spécifications fonctionnelles et techniques. Vient ensuite la réalisation, au fond du V. Puis on remonte : on teste chaque brique développée face aux spécifications correspondantes, jusqu'à la recette finale qui valide le tout face au besoin initial. La force du modèle est là : rien n'est développé sans qu'on sache déjà comment on le vérifiera.
Cette rigueur a un prix. Le cycle en V suppose que le besoin ne bougera pas une fois validé. Si un changement survient tard, en phase de test, il faut souvent redescendre tout le V pour le répercuter, ce qui coûte cher. C'est une méthode taillée pour les projets prévisibles, où l'on préfère la sécurité d'un plan complet à la souplesse.
La méthode agile, comment ça marche
La méthode agile construit le projet par itérations courtes et répétées, plutôt qu'en une seule séquence. À chaque itération (souvent une à quatre semaines), l'équipe conçoit, développe, teste et livre un incrément utilisable, puis ajuste la suite selon les retours. Le besoin n'est pas figé au départ : il s'affine en avançant, à partir d'un backlog priorisé.
L'agile inverse la logique du V. Au lieu de tout spécifier puis tout construire, on livre vite un premier périmètre restreint, souvent un MVP (produit minimum viable, la plus petite version qui apporte déjà de la valeur), on le confronte au réel, et on corrige le tir. Le cadre le plus répandu est Scrum, qui organise le travail en cycles appelés sprints, avec des rôles et des rituels précis. J'y consacre une page dédiée sur la méthode Scrum.
L'agile brille quand le besoin est flou, mouvant ou soumis à un marché qui bouge. Sa contrepartie : il demande un client réellement disponible pour arbitrer en continu, et il offre moins de visibilité contractuelle sur le coût et le délai finaux, puisque le périmètre reste ouvert. Pour aller plus loin, voir la page méthode agile.
Tableau comparatif : agile vs cycle en V
Cycle en V et agile s'opposent sur cinq critères clés : la nature du besoin (figé contre évolutif), la flexibilité (faible contre forte), la visibilité sur le résultat final (élevée en amont contre progressive), le volume de documentation (lourd contre allégé) et la gestion du risque (concentrée à la fin contre étalée). Le bon choix dépend de celui de ces critères qui pèse le plus dans votre contexte.
Le tableau ci-dessous résume les différences que je regarde en priorité au moment de cadrer un projet :
| Critère | Cycle en V | Méthode agile |
|---|---|---|
| Besoin | Figé et détaillé au départ, dans un cahier des charges | Évolutif, affiné en continu via un backlog priorisé |
| Flexibilité | Faible : un changement tardif coûte cher | Forte : le changement est prévu à chaque itération |
| Visibilité | Le périmètre, le coût et le délai sont connus tôt | Un livrable utilisable à chaque itération, périmètre final ouvert |
| Documentation | Lourde et formelle (spécifications, plans de tests) | Allégée, centrée sur le produit et les échanges |
| Risque | Concentré en fin de projet, à la recette | Étalé et détecté tôt, à chaque livraison |
Quand choisir le cycle en V
Choisissez le cycle en V quand le besoin est stable et bien connu, quand un engagement contractuel ferme sur le prix et le délai est nécessaire, ou quand un cadre réglementaire impose une traçabilité et une documentation complètes. C'est la bonne méthode dès que la prévisibilité compte plus que l'adaptation.
Le cycle en V est le bon choix dans ces situations :
- Le besoin est figé et maîtrisé. Vous savez précisément ce que vous voulez, et cela ne changera pas en cours de route. Le spécifier à l'avance ne fait perdre aucune information.
- Le contrat exige un engagement ferme. Un appel d'offres ou un marché au forfait demande un périmètre, un prix et un délai arrêtés dès la signature. Le V colle à cette logique.
- Le domaine est réglementé ou critique. Santé, banque, industrie, systèmes embarqués : quand chaque exigence doit être tracée et prouvée, la documentation du V devient un atout, pas un poids.
- Les intervenants sont peu disponibles. Si le client ne peut pas s'impliquer en continu, mieux vaut concentrer sa contribution sur un cahier des charges solide en amont.
Quand choisir l'agile
Choisissez l'agile quand le besoin est incertain ou amené à évoluer, quand vous voulez livrer vite pour tester le marché, ou quand le client peut s'impliquer en continu. C'est la bonne méthode pour un produit qui se découvre en avançant, où la capacité à ajuster vaut plus que la garantie d'un plan.
L'agile s'impose dans ces cas de figure :
- Le besoin est flou ou instable. Nouveau produit, marché mouvant, innovation : vous ne pouvez pas tout spécifier au départ parce que vous apprendrez en construisant.
- La rapidité de mise sur le marché prime. Livrer un MVP tôt pour le confronter aux vrais utilisateurs vaut mieux qu'attendre un produit complet mais peut-être hors cible.
- Le client est disponible et engagé. L'agile fonctionne quand quelqu'un peut prioriser le backlog et arbitrer à chaque itération. Sans ce relais, la méthode s'essouffle.
- Vous voulez maîtriser le risque tôt. Les livraisons régulières font remonter les problèmes vite, quand ils sont encore peu coûteux à corriger.
L'approche hybride, le pragmatisme du terrain
L'approche hybride combine les deux méthodes : on cadre le projet globalement comme un cycle en V (budget, grands jalons, périmètre général) et on pilote le développement en itérations agiles. On obtient ainsi la visibilité contractuelle attendue par la direction et la souplesse d'exécution attendue par les équipes. C'est le mode de fonctionnement le plus courant sur les projets digitaux réels.
Dans la réalité des projets que je pilote, le duel pur agile ou cycle en V est rare. La direction financière veut un budget et une date, ce qui pousse vers le V. Les équipes de développement veulent pouvoir ajuster, ce qui pousse vers l'agile. L'hybride réconcilie les deux : on fixe un cadre ferme en périphérie (enveloppe, jalons majeurs, engagements) et on laisse le cœur du développement respirer en sprints.
Cela demande de la rigueur pour ne pas tomber dans le pire des deux mondes : un projet qui aurait la lourdeur documentaire du V sans sa prévisibilité, et le flou de l'agile sans sa réactivité. Le rôle du pilote est justement de doser. Quand cette compétence manque en interne, il est possible d'externaliser le pilotage du projet. Et quel que soit le modèle, la clarté des rôles entre MOA, MOE et AMOA reste déterminante.
Je choisis la méthode selon le projet, pas par idéologie.
J'ai piloté des projets en cycle en V, d'autres en agile, beaucoup en hybride. Aucune de ces méthodes n'est supérieure dans l'absolu : la seule question qui compte est de savoir si votre besoin est stable ou mouvant, et quel niveau d'engagement vous devez tenir. Se ranger dogmatiquement dans un camp, c'est le meilleur moyen d'appliquer la mauvaise méthode au mauvais projet.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des projets digitaux en cycle en V, en agile et en hybride, pour des grands comptes et des PME (TF1, SFR, Orange, SNCF), en faisant le lien entre les équipes techniques et la direction. Découvrir son approche.
À lire ensuite
Réussir la gestion de projet digital
La vision d'ensemble : méthodes, rôles, pilotage et pièges à éviter.
MéthodeLa méthode agile
Itérations, backlog et livraisons régulières : le fonctionnement de l'agile.
Cadre agileLa méthode Scrum
Sprints, rôles et rituels : le cadre agile le plus utilisé en pratique.
PilotageExternaliser le pilotage
Quand et pourquoi confier la direction de projet à un intervenant externe.