Tout comprendre sur la méthodologie du projet cycle V : étapes, avantages et inconvénients
On entend beaucoup parler d’Agilité ces dernières années, au point de croire que tous les projets doivent être Agile et qu’il faille faire table rase des fondamentaux. Pourtant, avant de vouloir tout « agiliser », je tiens à mettre en avant les spécificités de chaque méthode, car elles ont toutes leur propre terrain de jeu. Le projet cycle V est loin d’être obsolète : il reste une référence, notamment pour les systèmes critiques où la sécurité et la traçabilité ne sont pas négociables, comme dans l’industrie, la défense et l’aéronautique.
Dans cet article, je vous propose de découvrir ou redécouvrir cette méthodologie qui est rigoureuse, son fonctionnement en « miroir » et comment elle peut cohabiter avec des approches plus agiles.
Concurrence ou cohabitation avec l’Agilité
Nous entendons beaucoup parler des méthodes agiles, or je trouve qu’avant de faire table rase des méthodes de gestion de projet classiques, comme Waterfall ou encore un projet en cycle V, c’est important de comprendre comment la gestion de projet a évolué.
Et aussi, l’un n’empêche pas l’autre, c’est-à-dire que tous les projets n’ont pas tous la configuration pour être tous agiles. On peut faire cohabiter une gestion de projet classique avec une gestion de projet agile selon les types de projet.
Typiquement, un projet cycle en V demeure une référence pour les projets portant sur les systèmes critiques pour lesquels la sécurité et la fiabilité sont d’une extrême importance.
Tandis qu’un projet en méthode Agile conviendra mieux dans un contexte où les besoins des utilisateurs et l’environnement du projet sont amenés à évoluer régulièrement.
Les 3 grandes qualités d’un projet en cycle en V
J’ai synthétisé ici ce qui fait qu’un projet en cycle en V soit apprécié.
Il y a 4 points positifs :
- Linéaire : l’immense avantage d’un projet en V, c’est qu’il est linéaire, c’est-à-dire qu’il a une série d’étapes, une séquence. Et mine de rien, cela donne de la visibilité sur ce qui est fait et ce qu’il reste à faire étape après étape.
- Qualité et rigueur : Chaque étape de conception du cycle en V se confronte à une phase de test et de validation pour s’assurer que ce qui a été conçu est robuste et conforme.
- Maîtrise des risques : Grâce aux phases de test régulières (vous comprendrez mieux en voyant la graphique de représentation d’un projet en cycle en V) la détection des erreurs est précoce. Comme les erreurs sont détectées plus tôt, cela réduit ainsi les coûts de correction, contrairement à la méthode Waterfall avec une phase de test très tardive.
- La traçabilité : Un projet avec le modèle en V impose une structure documentaire exhaustive. Ce qui est très recherché par des secteurs à risque et fortement règlementé, comme l’aéronautique, le médical et la défense. C’est un moyen de preuve pour montrer que chaque spécification a été testée.
Origine de la méthodologie projet de cycle en V
La méthodologie du cycle en V a émergé au cours des années 1970.
Elle est une évolution directe du modèle en cascade (Waterfall) conceptualisé par Winston W. Royce. Il n’a d’ailleurs pas fallu longtemps pour revoir la copie du Waterfall, puisqu’elle est apparue à la même période (même si tout porte à croire que le modèle en cascade existait bien avant 1970).
La première intention du modèle en V (« V model » ou « Vee model ») est de pallier les insuffisances de son prédécesseur. C’est un Waterfall version 2 en quelque sorte.
Il vient corriger deux défauts majeurs :
- L’isolement des tests : ils intervenaient bien trop loin dans le processus et étaient déconnectés des autres phases.
- La rigidité des corrections : les modifications n’étaient possibles qu’à la toute fin du projet.
Contrairement au modèle Waterfall, le cycle en V introduit une symétrie architecturale où chaque phase de développement est systématiquement confrontée à une étape de validation, ce qui permet de détecter et corriger les erreurs plus rapidement
Standard militaire et montée en popularité
Le cycle en V n’est pas qu’un modèle de projet pour les logiciels commerciaux.
Le modèle de gestion de projet en V a été formalisé chez Hughes Aircraft vers 1982, aux États-Unis, pour répondre aux besoins critiques de la FAA (Federal Aviation Administration). Le défi était de faciliter la détection des défauts dans des architectures logicielles critiques.
Parallèlement, en Allemagne, l’IABG a développé le V-Modell pour le compte du ministère fédéral de la Défense. Ce modèle a été publié officiellement en 1992 et s’est rapidement imposé comme le standard pour l’ensemble de l’administration fédérale allemande.
Évolution du cycle en V vers la flexibilité
Face aux exigences de rapidité de l’industrie moderne, le modèle a évolué en 2005 pour devenir le V-Modell XT (Extreme Tailoring).
Cette version modernisée se distingue par sa grande modularité. Les chefs de projet peuvent en personnaliser la structure selon la taille et les risques de chaque mission.
Aujourd’hui, cette méthodologie de projet en V n’est plus opposée à la flexibilité.
On voit même des modèles de projets hybrides entre cycle en V et les méthodes agiles comme Scrum. Le grand avantage est de garantir une très grande sécurité tout en permettant des cycles itératifs de développement.
Explication de la séquence projet du cycle en V
On appelle cette gestion de projet le cycle en V parce que la représentation graphique de ce cycle est … en V 😄.
Tout comme la gestion de projet Waterfall (cascade) représente une cascade.
Au moins, c’est facile à retenir.
La séquence d’un projet en cycle en V se divise en deux branches symétriques reliées par une étape centrale afin de former la lettre « V ».
Branche descendante
Le point de départ est le besoin global pour aller vers le détail technique.
Elle comprend :
1. L’expression des besoins (attentes et exigences)
2. Spécification : la rédaction des spécifications fonctionnelles
3. Conception générale : c’est l’architecture avec la rédaction du cahier des charges techniques
4. La conception détaillée : il s’agit de la structuration par composants
La pointe du V (Réalisation)
C’est la phase de codage, de création ou encore de construction.
Les spécifications sont transformées en produit concret.
La branche ascendante
On remonte maintenant vers le produit final en vérifiant chaque niveau de conception. Les différentes phases de test n’ont lieu qu’après la phase de réalisation (le bas du V).
Cette branche suit l’ordre suivant :
- Tests unitaires pour vérifier le fonctionnement des composants
- Tests d’intégration pour vérifier les interactions des composants entre eux
- Validation pour vérifier que le produit fonctionne dans son ensemble et répond au besoin initial
- Recette utilisateur (UAT : User Acceptance Test) pour valider que le produit répond aux exigences initiales
Cela sera plus clair avec un schéma (fait maison)
Les tests ne s’enchaînent pas immédiatement dans le temps après une phase de conception.
Les limites d’un projet en cycle en V
Malgré sa robustesse et les 3 grandes qualités que j’ai abordées en début d’article, cette méthodologie présente des faiblesses dans le contexte actuel.
Effet tunnel
Tout comme un projet de type Waterfall, il y a une longue période de temps qui s’écoule entre la définition initiale du besoin et la livraison du produit final auprès des utilisateurs.
Et entre les deux …. silence radio.
Les utilisateurs ont très peu de visibilité sur l’avancement réel du projet jusqu’au moment où le projet arrive enfin et c’est la panique dans les équipes pour expliquer le projet, sensibiliser et former tout en assurant la production en même temps 😩.
Une rigidité de la structure méthodologique
Un projet en cycle en V n’est pas, par son format méthodologique, un projet flexible.
Effectivement, un projet en cycle V repose sur une séquence linéaire où chaque étape doit être finalisée avant de passer à la suivante.
Une fois qu’une phase est achevée, il est difficile et coûteux de revenir en arrière pour intégrer des modifications ou de nouvelles idées. La méthode ne le prévoit pas !
Si vous insistez pour modifier les exigences en cours de réalisation du projet,il faut alors revenir sur plusieurs phases antérieures ce qui entraîne des retards de livraison et des surcoûts.
Où sont les utilisateurs ?
Dans un projet en cycle en V, l’engagement des utilisateurs (du client) est généralement concentré à 2 moments du projet :
- Lors de l’expression des besoins
- Puis pendant la phase de recette utilisateur (UAT)
Il n’y a pas de boucle de rétroaction entre l’équipe projet et le client pendant le développement. Ce qui peut amener à des déceptions des utilisateurs lors de la livraison . Notamment si les développeurs ont interprété les spécifications différemment des attentes réelles du client.
L’engagement du client est généralement concentré au début (analyse des besoins) et à la fin (recette utilisateur ou UAT), sans boucle de rétroaction continue pendant le développement.
Cette absence de contact régulier peut mener à une désillusion à la livraison 😧 si l’équipe de développement a interprété les spécifications différemment des attentes réelles du client. Mais à ce moment-là, il est trop tard.
Des erreurs de conception tardivement repérées
Quoi ?! Me direz-vous.
N’as-tu pas dit Guillaume que le cycle en V est un modèle qui prévoit des tests à chaque niveau ?
Et bien si, c’est vrai.
Néanmoins, comme vous pouvez le voir sur le schéma d’un projet en cycle en V, vous pouvez voir que les problèmes majeurs de conception ou d’architecture ne sont souvent découverts que lors des phases de tests système ou de recette finale.
Le cycle en V est inadapté à certains projets
Le cycle en V repose sur une hypothèse.
Cette hypothèse est que tous les besoins peuvent être identifiés et écrit de manière exhaustive dès le départ.
Par conséquent, le cycle en V n’est pas adapté aux projets innovants, aux projets qui demandent de questionner régulièrement les besoins et faire tester les utilisateurs.
La structure d’un projet en cycle V n’est pas adaptée. Elle peut répondre à des projets industriels et des projets de construction, très peu à des projets applicatifs dont les contours restent flous et dont les cas d’usage évoluent au gré des échanges avec les utilisateurs.
Comment faire du change management dans un projet en cycle V
La conduite du changement (Change Management) dans un projet en cycle en V doit compenser ses faiblesses.
Voici des clés pour bien faire du change management avec ce type de projet.
Clarifier les rôles
Dans un projet en cycle en V, il y a deux personnes avec des rôles clés que vous devez identifier.
Le MOA (Maîtrise d’Ouvrage) qui définit les besoins et le MOE (Maîtrise d’Œuvre) qui est le responsable technique.
Vous aurez besoin de travailler avec ces deux personnes pour bien réaliser le diagnostic change, la stratégie d’accompagnement au changement et les plans associés (communication, formation, accompagnement, mobilisation).
Ils vous apporteront une vision métier et une vision technique dont vous aurez bien besoin.
Réduire l’effet tunnel
Une autre clé est d’instaurer des échanges avec les utilisateurs finaux, notamment entre chaque passage d’étape afin de leur présenter (même en grosse maille) les prototypes, les maquettes pour les rassurer et leur donner de la visibilité sur ce qui va être livré.
Par contre,les demandes de modifications et d’évolutions des utilisateurs ne seront pas forcément prises en compte à moins de retarder le projet.
Pléthore de documentation
Le grand avantage d’un projet en cycle en V (tout comme un projet Waterfall) est la documentation. Il y en a plein !
- La documentation avec l’expression des besoins.
- La documentation des spécifications fonctionnelles.
- La documentation de l’architecture.
- Et la documentation des tests.
Vous pouvez utiliser cette documentation pour construire le programme de formation.
Hybridation (Approche « Wagile »)
Je ne suis pas l’inventeur de ce terme.
L’approche Wagile est une approche.
L’approche Wagile est une méthodologie hybride qui associe la planification rigoureuse du cycle en V et Waterfall à la flexibilité organisationnelle et à la planification itérative d’Agile.
C’est un mix des deux approches, cela apport plus de souplesse avec une planification globale en cycle en V et des développements par itérations courtes (sprints) ce qui permet d’intégrer fréquemment des retours utilisateurs.
Et vous, pour vos projets complexes, quelle approche a votre préférence : la rigueur du Cycle en V ou la flexibilité de l’Agile ?
Au final, le projet cycle V a su évoluer depuis les années 70. S’il a corrigé les défauts du Waterfall, il doit aujourd’hui cohabiter avec l’Agilité. C’est tout l’enjeu de l’approche « Wagile » dont je vous parlais plus haut.
On cherche désormais à prendre le meilleur des deux mondes : la sécurité et la planification rassurante du Cycle en V, couplées à la réactivité des sprints agiles.
Un conseil : ne soyez donc pas dogmatique.
Que vous soyez MOA, MOE ou Change Manager, votre objectif reste le même : livrer un produit de qualité qui sera réellement utilisé. Et peut-être que pour cela, il vous faudra un peu « tordre le cou » à la théorie du V pour y mettre de l’agilité.
