Le cycle en V, ce n’est pas de la gestion de projet, mais de l’ingénierie système.
Parler d’hybride, agile ou cycle en V, ce n’est pas de la gestion de projet.
Imaginer que le périmètre est figé en cycle en V est irréaliste.
Ce serait bien de rappeler ces fondamentaux pour éviter des erreurs de mise en œuvre ensuite.

Jean-Charles SAVORNIN, MGP, PMP

De très juste remarques… d’où ce billet écrit conjointement avec Jean-Charles !

Le cycle en V est un modèle de cycle de développement d’un système qui se caractérise par un flux d’activités descendant qui détaille le système jusqu’à sa réalisation, et un flux ascendant, qui assemble le système en vérifiant sa qualité.

Cette approche associe chaque activité de définition ou conception à une activité d’intégration, vérification ou validation.

Comme indiqué par Jean-Charles, le cycle en V bien que souvent considéré comme du management de projet, est en fait de l’ingénierie système, et les 2 sont nécessaires et complémentaires !

Le cycle en V (ingénierie) se concentre sur le développement du système, c’est-à-dire et pour simplifier le livrable technique du projet, alors que le management de projet va se concentrer plus largement sur toutes les activités menant à la réalisation des bénéfices attendus par les utilisateurs, clients, et autres parties prenantes : pilotage financier, volet logistique, pilotage des fournisseurs, formation des utilisateurs ou exploitants, conduite du changement, maîtrise des risques et opportunités, …

Le cycle en V n’est donc pas une méthode management de projet.

Les grandes étapes du cycle en V

La branche descendante

Vous y détaillez le produit jusqu’à sa réalisation. Expression des besoins, analyse, conception, développement des livrables (matériels, logiciels, processus opérationnels…).

Le cycle en V requiert dans la branche descendante de réaliser une conception générale du système dans son ensemble, puis une conception détaillée de chaque composant.

Le développement se fait ensuite composant par composant.

La branche ascendante

Vous y avez pour objectif de valider le produit jusqu’à son acceptation par les clients. Il comprend principalement une série de tests unitaires, d’intégration puis de bout en bout jusqu’à pouvoir vérifier que le produit répond bien aux exigences.

Dans la branche ascendante, on va effectuer des tests unitaires de chaque composant, les intégrer dans le système (assembler ces composants), puis réaliser un test d’intégration.

Vérification et la validation confirment non seulement que le système répond à la conception, mais qu’il répond aux exigences des clients.

Limites et Risques principaux avec le cycle en V

#1 – Approche assez théorique

Le Cycle en V propose en réalité une approche assez théorique qui ne s’applique qu’à un système relativement simple, réalisé en un exemplaire, et pas au développement d’un système complexe à multiples niveaux de décompositions.

#2 – Représentation parfois trompeuse

Si le cycle en V représente un cycle de vie, les éléments le composant sont bien des activités et non des phases.

Appliquer cette représentation stricto sensu sans apporter de nuance conduit aux risques récurrents présentés ci-après.

#3 – Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit).

Cette représentation induit le risque important de se rendre compte au cours de la mise en œuvre finale que les spécifications initiales étaient incomplètes, fausses, voire irréalisables. De fait, les processus se chevauchent et peuvent s’étendre sur plusieurs phases du projet.

#4 – Évolution des besoins

Comme le déroulement du cycle en V peut être assez long (plusieurs mois au minimum), vous avez de fortes chances pour que de nouveaux besoins requis par les clients et peut-être plus importants ou critiques au business que ceux en cours de développement apparaissent. Hors l’approche vous incite à figer le plus possible un jeu d’exigences au départ afin d’y répondre avec un livrable complet avant de considérer de nouveaux besoins.

#5 – Démobilisation et turnover

Plus le cycle en V dure longtemps et plus grands seront les risques de démobilisation de vos clients (et équipes de développement). L’effet ‘tunnel’ du cycle en V (on ne voit la lumière / le résultat qu’à la sortie du cycle en V) ne favorise pas la visibilité par les clients des réelles avancées sur votre projet lors de revues intermédiaires comme ce serait le cas avec une approche Agile.

Quels remèdes ?

Afin de pallier ces travers, l’Association Française de l’Ingénierie Système préconise une approche par les processus.

Sur vos projets, à défaut d’utiliser les approches itératives dites Agiles, un compromis pour vous consiste à appliquer un cycle en V le plus court possible et à faire évoluer vos livrables sous forme de versions. Vous prenez ainsi en compte le fait que le livrable ne sera pas parfait au départ et que vous l’améliorerez au fil des versions.

En vous rapprochant ainsi des Sprints et Releases des approches Agiles, votre cycle en V court vous permet de montrer plus rapidement des livrables concrets et utilisables aux clients.

Vous pourrez aussi à la fin de chaque version bénéficier du retour d’expérience de la ou des versions précédentes.

Sources et références :

• Découvrir et comprendre l’ingénierie système, Ouvrage collectif AFIS, 2009
• NASA systems engineering handbook, National Aeronautics and Sapce Administration, 2007
• System Engineering Guidebook, INCOSE, 2018
• System Engineering Hanbook, INCOSE, 2015