Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école après le cycle en cascade, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

 

On peut y distinguer 3 grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Les différentes étapes

Le cycle en V est constitué de 8 étapes qui ont toutes leur importance.

• Expression de besoin : Le client exprime son besoin, en décrivant les usages correspondant au produit fini tel qu’il peut l’imaginer. Cela doit répondre aux questions « Que veut-on ? » et « À quel coût ? ».
• Spécifications fonctionnelles : C’est le cahier des charges exact du produit final, tel que le désire le client. Il doit couvrir l’intégralité des cas d’utilisation du produit, en expliquant ce qu’il doit faire et non pas comment il va le faire.
• Spécifications techniques : C’est une traduction des spécifications fonctionnelles en termes techniques. C’est durant l’élaboration des specs techniques que sont choisies les technologies à mettre en oeuvre pour développer le produit, et qu’est conçue l’architecture logicielle du produit.
• Codage : C’est la phase de réalisation à proprement parler, pendant laquelle sont développées des briques qui sont ensuite assemblées pour créer le produit fini.
• Tests unitaires : Ces tests interviennent à un niveau « atomique ». Chaque brique logicielle a été modélisée puis codée durant les étapes précédentes. Les tests unitaires assurent que ces briques respectent de manière individuelle leur cahier des charges.
• Tests d’intégration : Ce sont là les premiers tests grandeur nature du produit fini. On s’assure qu’il suit les indications des spécifications techniques.
• Validation : Le produit est à ce moment testé en regard de la spécification fonctionnelle. Toutes les utilisations qui y ont été définies doivent pouvoir se vérifier dans les faits.
• Mise en production et recette : Le produit est vérifié une dernière fois en pré-production, avant d’être mis en production. Le client procède à la recette, pour vérifier que son expression de besoin est respectée.

La pratique

Malheureusement, si le cycle en V est limpide d’un point de vue théorique, son application réelle est très difficile. Dans une grande majorité de cas, on voit des organisations qui ressemblent plutôt à ce schéma :

 

• La phase de conception se réduit à 2 étapes.
  • Les spécifications fonctionnelles, qui représentent l’ensemble des besoins du client et/ou définissent ce que doit faire le produit fini.
  • Les spécifications techniques, qui détaillent comment le produit va être réalisé techniquement.
• La phase de validation contient juste 3 étapes.
  • Les tests d’intégration, pendant lesquels on vérifie que l’intégralité du produit est valide techniquement.
  • Les tests de validation, qui sont un mélange de tests techniques et fonctionnels, et sur lesquels le client se base souvent pour décider du lancement du produit.
  • La recette, qui est utilisée pour vérifier que le produit est valide par rapport aux spécifications fonctionnelles, mais qui a tendance à n’intervenir qu’après la mise en production (ou bien elle est tronquée en pré-production, ce qui aboutit à mettre des bugs en production).

Une telle organisation possède encore des avantages structurels assez convaincants, car elle définit toujours les différentes étapes de la réalisation d’un projet. Mais bien souvent, on se retrouve en réalité avec une organisation qui ressemble plutôt à quelque chose comme ça :

 

Mon expérience

Je ne pense pas qu’on puisse encore de nos jours envisager d’appliquer cette méthode de manière stricte en entreprise. Je vois le cycle en V comme étant un modèle standardisé, un fonctionnement idéal vers lequel on voudra tendre. Pour faire une analogie dans le domaine des réseaux, c’est un peu comme le modèle OSI, qui décrit 7 couches réseau (depuis la couche physique jusqu’à la couche applicative) ; alors que le protocole utilisé par les trames circulant sur les réseaux Ethernet n’est constitué que de 4 couches, qui reprennent à leurs comptes les mêmes fonctions que les 7 couches définies de manière théorique.

Le plus gros problème avec le cycle en V, c’est que dans la réalité il est quasiment impossible d’obtenir des spécifications fonctionnelles (ou techniques) qui se suffisent à elles-mêmes et qui ne seront pas impactées par la suite. C’est souvent pendant l’implémentation du produit que l’on identifie les cas limites et les problèmes conceptuels. Dans ce cas, une stricte application de cette méthode forcerait à reprendre le cycle depuis le début, en intégrant au niveau fonctionnel les remontées d’ordre technique, ce qui implique des délais conséquents.

Et au final, c’est bien ça le problème de cette méthode : son manque de souplesse. C’est pour cela que d’autres types d’organisations sont apparues, et nous verrons cela très bientôt.

Edit

Pour aller plus loin, je vous conseille de lire mon article consacré aux méthodes agiles.

Quel logiciel pour gérer ses projets ?

Pour gérer efficacement vos projets en utilisant la méthode du cycle en V, je vous conseille Skriv, l’outil que j’ai développé. Comme je l’ai déjà expliqué sur ce blog (quand j’ai créé ma startup et quand j’ai lancé le logiciel), j’ai développé cet outil de gestion de projets avant tout pour mon propre usage, à partir des besoins que j’avais lorsque j’étais directeur technique.

Skriv s’adapte à votre manière de travailler, et il vous fait gagner en productivité grâce à son approche différente (en résumé, il connait votre workflow, ce qui lui permet d’automatiser des tâches répétitives qui sont habituellement faites manuellement ; les autres outils sont basés sur de la simple gestion de tâches, c’est un principe qui n’a pas changé depuis 30 ans). Et quand je dis qu’il est plus simple à utiliser que ses concurrents, ce n’est pas une promesse en l’air.

Essayez-le gratuitement, vous ne le regretterez pas !