Dans le monde de la gestion de projet informatique, le cycle en V a une place importante. Au milieu d’autres méthodologies, comme le modèle en cascade ou le rétroplanning, le cycle en V, utilisé depuis plusieurs décennies, n’a plus à faire ses preuves.
Cependant, face à de nouveaux outils plus récents, comme les méthodes agiles, on peut se demander si continuer de l’utiliser est réellement bénéfique.
Dans cet article, nous allons faire le tour de cette méthodologie de gestion de projet, la définir, en expliquer les bénéfices et ses étapes.
Cycle en V : définition
Né dans les années 1980, le cycle en V (ou V-model, en anglais) est, pour être plus précis, un modèle d’organisation des activités d’un projet. Ce modèle détaille, via un flux descendant puis ascendant (d’où le terme en « V »), les différentes étapes de la vie d’un projet informatique.
Le flux descendant est centré sur l’analyse et la conception du projet, alors que le flux ascendant se concentre sur la phase de validation (divers tests, qu’on détaillera par la suite).
Quant à la phase de développement, elle est à la pointe du V, au croisement de ces deux flux. Elle inclut les étapes de conception détaillée, de mise en oeuvre et de tests unitaires ; avec une boucle entre ces trois éléments pour un développement complet.
Le cycle est en quelque sorte une dérivée, ou évolution, du modèle en cascade, dans le sens où il reprend l’approche séquentielle et linéaire. Comme on le verra, il y a pourtant des différences importantes, avec une plus grosses insistances sur la validation du projet.
Les différentes étapes du cycle en V
Comme on vient de le voir, le cycle en V est constitué de diverses étapes. Si elles peuvent varier légèrement, on retrouve toujours les deux flux, bases du cycle en V, dont voici le découpage général :
Flux descendant
Le flux descendant est celui qui regroupe toute la partie qui précède le développement à proprement parler du projet (le codage). Dans ce flux, on retrouve :
Analyse
Il s’agit à ce niveau d’analyser et synthétiser les besoins du client. Le cycle en V étant fait d’étapes cloisonnées, il est important de bien commencer la pipeline en établissant ici un cahier des charges le plus précis et clair possible. C’est aussi ici qu’on commence à définir les tests qui seront à implémenter dans le flux ascendant.
Conception générale
Dans la phase de conception générale, qui se déroule cette fois uniquement en interne, on définit l’organisation du projet. Cela passe par la définition des besoins (humains, financiers, techniques, etc.), les choix technologiques, les plans de test, etc.
Conception détaillée – Codage
On retrouve ensuite deux étapes, qu’on pourrait regrouper en une car faisant partie du même cycle (avec les tests unitaires dont on reparlera) : la conception détaillée et le développement, le codage. Il s’agit ici de faire la conception détaillée du produit (la conception de chaque élément, fonctionnalité, etc.) tout en développant ces composants.
Flux ascendant
Comme on l’a déjà dit, le flux ascendant est fait pour la validation du projet. On y retrouve toujours la phase de codage (puisque la validation nécessite presque obligatoirement des correctifs), mais aussi toutes les phases de test, que l’on va détailler.
Codage – Tests unitaires
Les tests unitaires sont là pour valider le code en lui-même, et les composants de manière unitaire. C’est principalement le développeur qui est en charge de cette phase.
Les tests d’intégration
Lors des tests d’intégration, on ne teste plus les composants individuellement, mais le produit en lui-même. On vérifie son bon fonctionnement, aussi bien technique que fonctionnel. C’est lors de cette phase qu’on s’assure que le produit corresponde bien au cahier des charges.
Tests d’acceptation
Lors de cette phase de validation, le client, ou utilisateur final, intervient, pour vérifier que le produit fonctionne selon ses attentes et couvre le cahier des charges. C’est ce qu’on appelle plus couramment la phase de recette.
Avantages et inconvénients
Le cycle en V n’est pas la seule méthodologie de gestion de projet. Comme on l’a déjà dit, il y a par exemple le modèle en cascade, itératif, les méthodes agiles, etc.
Alors qu’est ce qui fait que le cycle en V puisse être plus intéressant qu’un autre outil ? En réalité, cela dépend du projet et de vos besoins. Pour y voir plus clair, faisons le tour des avantages et inconvénients de l’utilisation de cette méthode.
Avantages
- L’élaboration d’un plan de tests dès le début du projet. Le flux ascendant étant une grosse composante du cycle en V, on prévoit les futurs tests dès la phase d’analyse, ce qui donne un avantage conséquent sur les autres méthodologies ;
- Parfaitement adapté si le cahier des charges est fixe ;
- La qualité et fiabilité du produit sont maximisés, notamment grâce aux nombreux tests effectués ;
- Grâce à ces mêmes tests, les risques associés à la gestion de projet (retards dûs aux bugs, etc.) sont minimisés.
Inconvénients
- Le cycle en V est une méthodologie rigide. Si les spécifications fonctionnelles initiales viennent à changer (si par exemple le client change d’avis en cours de projet), c’est l’ensemble des prévisions qui doivent être revues, y compris les tests ;
- Point commun avec le modèle en cascade, chaque étape est plus ou moins cloisonnée. Si une phase comporte des erreurs ou des oublis, la suivante s’en retrouve affectée et il est coûteux de revenir en arrière. C’est l’effet tunnel ;
- Le cycle en V devient inutile, voire contre-productif, si votre client tend à changer régulièrement d’avis ou veut un produit évolutif sur le court terme.
Quand utiliser le cycle en V ?
Alors dans quel cas précis utiliser le cycle en V ? Si vous avez lu la liste des avantages et inconvénients, il est facile de répondre à cette question.
Le cycle en V est très utile pour un projet au cahier des charges fini, détaillé, et immuable. Dans ce cas-là, on peut prévoir en amont tout le déroulé du projet, du découpage en composants aux tests finaux. Le développement du projet s’en trouvera parfaitement cadré, et ses chances de réussite maximisées.
En revanche, si votre gestion de projet a besoin de souplesse, si votre client ne sait pas exactement ce qu’il veut par exemple, cette méthodologie n’est pas idéale. Dans ce cas-là, il vaut mieux se tourner vers les méthodes agiles, type Scrum.
Conclusion
Comme on l’a vu, le cycle en V, méthodologie de gestion de projet ayant presque 40 ans, n’a plus à faire ses preuves. Cet outil, qui découle du modèle en cascade, se révèle puissant et idéal dans certains cas.
Pour autant, et même dans une situation idéale, ce n’est pas un outil magique. Toute planification comporte des risques (mauvaises estimations, oublis de tâches, défaillances humaines, etc.) qui peuvent mettre en péril le développement d’un projet informatique. Et le cycle en V ne fait pas exception.
Et vous, avez-vous déjà utilisé le cycle en V sur un projet ? Qu’en avez-vous pensé ?
