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, 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 9 étapes qui ont toutes leur importance.

• Étude de faisabilité : Il s'agit de l'étude préalable que le client doit réaliser avant de commencer à définir son besoin de manière plus précise. Cela doit répondre aux questions "Que veut-on ?", "Est-ce réalisable ?" 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.
• Modélisation et conception : Il s'agit de la phase technique pendant laquelle l'architecture logicielle du produit est détaillée. Tous les différents modules logiciels sont exposés, ainsi que leurs entrées-sorties. Les choix techniques les plus pointus sont résolus durant cette étape.
• 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.
• Recette : Le produit est vérifié une dernière fois avant d'être mis en production.

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 à intervenir après la mise 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.