Cycle en V : étapes, atouts et quand préférer l’agile

Le cycle en V est un cycle de développement séquentiel dans lequel chaque étape de spécification, sur la branche descendante, est mise en regard du niveau de test qui la vérifiera sur la branche montante. Dessiné en V, il définit à la descente ce qui sera construit et démontre à la montée que cela a été correctement construit. C’est un raffinement du modèle en cascade, pas une alternative à celui-ci.

La branche descendante

Analyse des besoins, spécification fonctionnelle, conception architecturale, conception détaillée : chaque niveau précise le précédent et produit un document qui servira de référence à un niveau de test. Toute la discipline du modèle est là — on ne spécifie pas un niveau sans savoir déjà comment il sera vérifié.

La branche montante

Les tests unitaires valident la conception détaillée, les tests d’intégration l’architecture, les tests système la spécification fonctionnelle, et la recette les besoins initiaux. Chaque test répond à un document écrit du côté opposé du V, ce qui rend la couverture traçable et auditable.

Atouts et limites

Le cycle en V est fort là où les besoins sont stables et où la preuve est exigée : industries réglementées, systèmes embarqués, livraisons critiques ou contractuelles. Sa limite est symétrique — un changement découvert sur la branche montante coûte cher, car il invalide des documents produits des mois plus tôt. Il suppose qu’on puisse savoir ce que l’on veut avant de l’avoir vu.

Choisir entre V, cascade et agile

Le vrai critère n’est pas la mode, mais la volatilité du besoin et le coût d’un changement tardif. Des exigences stables, contractuelles, certifiables appellent un cycle en V ; un produit exploratoire, dont l’utilisateur découvre le besoin en s’en servant, appelle une livraison itérative. La plupart des organisations finissent par pratiquer les deux, parfois au sein d’un même programme : une phase de validation en V, un incrément produit en sprints.

Piloter les deux dans le même portefeuille

FoxPlan n’impose pas une méthode unique : un projet peut être planifié en Gantt avec phases, jalons et dépendances, ou suivi sur un tableau Kanban, et les deux alimentent la même charge des ressources, le même budget et le même reporting de portefeuille. La méthode reste un choix de projet ; la consolidation reste globale.