Cycle en V en gestion de projet : définition et méthode

Définition du cycle en V

Le cycle en V en gestion de projet découle du modèle en cascade théorisé dans les années 1970, qui permet de représenter des processus de développement de manière linéaire et en phases successives.

Ce mode de gestion de projet a été développé dans les années 1980 et appliqué au champ des projets industriels, puis étendu aux projets informatiques. Il a été remis en cause à partir du début des années 2000, sous l’effet de l’accélération des changements technologiques, favorisant davantage les méthodes dites « agiles ».

La lettre V fait référence à la vision schématique de ce cycle, qui prend la forme d’un V : une phase descendante suivie d’une phase ascendante. Le cycle en V associe à chaque phase de réalisation une phase de validation, comme l’illustre le schéma ci-dessous :

 

Avantages de cette méthodologie

Le principal avantage du cycle en V est qu’il évite de revenir en arrière incessamment pour redéfinir les spécifications initiales, comme un cliquet. Chaque phase de conception demande la rédaction d’une documentation précise et exhaustive, où chaque point doit être validé par le produit final. Dès lors qu’une étape est validée, on ne revient pas en arrière et on passe à l’étape suivante sur une base solide ; c’est la principale force du cycle en V.

De par son aspect à la fois rigoureux et intuitif, le cycle en V demeure un processus facile à mettre en œuvre. Le travail préalable de définition des spécifications en début de projet fait que, une fois lancé, l’ensemble des étapes est connu des collaborateurs, qui peuvent se repérer facilement dans la temporalité du projet et connaître la finalité de leurs tâches. De la même manière, les documentations nécessaires à chaque étape sont réplicables d’un projet sur l’autre dans leur structure (cahiers des charges, cahiers de test…).

En général, le cycle en V est plus adapté aux structures multisites, car il ne demande pas de réunions quotidiennes, mais seulement des réunions de pilotage actant le passage d’une phase à l’autre. Son aspect linéaire autorise donc une organisation géographique éclatée, où le côtoiement des collaborateurs n’est pas clé dans le processus.

Inconvénients

L’inconvénient principal du cycle en V se résume en deux mots : l’effet tunnel. Après une phase de définition précise du produit auquel doit l’équipe doit aboutir, le projet est lancé dans un « tunnel » constitué des phases évoquées plus haut. Mais que faire si les spécifications initiales sont dépassées ? Si le besoin du client vient à changer, ou a été mal exprimé ? Le cycle en V supporte donc mal les changements, ce qui est à la fois sa force et sa principale faiblesse.

Il offre ainsi moins de réactivité par rapport au contexte technologique et économique, aux demandes du client, aux événements inopinés ; la prise de risque s’en trouvera systématiquement limitée. L’effet tunnel est aussi induit par le travail conséquent de production de la documentation en début de projet, qui n’est plus rectifiable par la suite. Enfin, l’image du tunnel illustre le temps (parfois très) long qui sépare l’expression du besoin de la recette du produit final.

Cycle en V vs. méthodes agiles

De façon générale, l’on peut affirmer que le cycle en V se focalise sur le processus, tandis que les méthodes agiles privilégient le produit.

Dans le cadre des méthodes agiles (Scrum, XP, RAD, …), le projet s’affine par  itérations , à travers la répétition d’un cycle d’opérations (le  sprint  dans le cadre de la méthode Scrum ). Comme nous l’avons vu, le cycle en V définit l’intégralité du produit final dès les premières étapes, et ne laisse que peu de place à l’adaptation dans la suite du cycle.

Ensuite, les méthodes agiles permettent d’élaborer le produit par  incrémentation . On produit un peu plus à chaque fois, morceau par morceau, pour aboutir au résultat final. Le cycle en V concentre au contraire la réalisation de l’ensemble dans une seule phase, qui est intégralement conçue en amont et vérifiée en aval.

Ce manque d’adaptation et de flexibilité du cycle en V a précisément conduit à l’émergence des méthodes agiles, en particulier dans le domaine du logiciel et du marketing, pour répondre aux changements de plus en plus rapides des technologies et des demandes des consommateurs.

Mise en œuvre du cycle en V

Pour quels projets ?

Au regard des éléments exposés précédemment, les éléments suivants favorisent l’utilisation du cycle en V :

• Des exigences très précises émises par le client, par exemple dans le cadre d’un appel d’offres.
• La présence d’un prestataire, qui maîtrise l'ensemble des étapes de réalisation et requiert ainsi moins de communication entre les différents acteurs.
• La possibilité de suivre un cahier des charges inchangé du début à la fin, de par la nature du produit ou du projet.
• Un projet où l’environnement technologique évolue très peu, limitant ainsi les risques de décalage inhérents à l’effet tunnel.

Une phase cruciale : la conception

Les besoins du client doivent être recueillis de manière exhaustive et rigoureuse. Les spécifications fonctionnelles doivent faire l’objet d’un processus de validation suivi et définitif. Elles doivent synthétiser les demandes du client tout en couvrant l’ensemble du programme du projet.

La description des moyens pour parvenir au produit final, quant à elle, ne doit intervenir qu’au stade des spécifications techniques (conception générale), de façon à éviter que les moyens ne définissent la fin !

Qui valide ?

Last but not least , par défaut, le cycle en V définit des étapes sans en définir les rôles ou les responsabilités. Il convient donc en début de projet de désigner les personnes ou les entités qui joueront le rôle de (par niveau de détail croissant) :

• Maîtrise d’ouvrage (fonctionnel), ou MOA
• Maîtrise d’œuvre (système), ou MOE
• L’équipe architecturale, ou de conception générale (technique, métier)
• L’équipe de développement (par composant)

Les rôles sont indiqués par séquence du cycle en V dans le schéma ci-dessus.

Voir également une autre méthodologie de projet.