Le cycle en V

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 !

10 commentaires pour “Le cycle en V

  1. c’est très intéressant mais il faudrait aussi penser à mettre un projet et son développement avec cette méthodologie, comme ça les intéressés peuvent avoir les explications et la marche à suivre avec la méthodologie en V

  2. Bonjour

    Merci beaucoup pour l’explication, ca m’a aidé pour le projet de site e-commerce.

  3. Je pense qu’il y a une erreur dans ces explications, car elles mélangent les phases de spécification et de conception. La conception n’est pas la spécification, c’est la modélisation du système à partir des spécifications.
    Je pense aussi qu’il est faux de dire qu’il est impossible d’obtenir des spécifications fonctionnelles: c’est juste très difficile, car il faut capter le besoin du client, et le traduire sous forme de specs. C’est la phase critique du projet car elle conditionne le reste, elle demande beaucoup d’écoute, de compréhension et d’aller et retour entre le client et le rédacteur. Etre un bon spécificateur est un réel talent, avec une forte plus value.

  4. @ouargh : Ne jouons pas sur les mots. Oui, il est très difficile d’obtenir des spécifications fonctionnelles. Voir d’ailleurs mes articles sur les spécifications à problème (1, 2, 3). Pour la différence entre conception et spécification, c’est plus une question de savoir où placer un curseur, à mes yeux. En tout cas, dans une équipe agile, ce genre de distinction a peu de sens.

  5. J’aime bien la phrase théorique « 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. »

    Car elle vraiment à côté de la plaque. De nos jours, la techno et l’architecture doivent être choisies bien en amont, car les écosystèmes techniques ne sont pas équivalents. Dit autrement, il y a deux problèmes majeurs avec cette théorie :
    1) Selon la techno choisie, les spécs fonctionnelles sont impactés. Telle techno ne permettra pas d’avoir un site mobile, telle autre d’avoir des boutons qui clignotent, telle autre d’avoir des données toujours à jour, etc…2crire des SF « dans l’absolu » sans tenir compte de cela est en effet ubuesque
    2) Les technos ont leur domaines de prédilection. Par exemple javascript pour le mobile, PHP pour les CMS, Java pour les applis internes, etc.. personne n’aura l’idée d’utiliser du JS pour un CMS (à part quelques geeks). Du coup, l’ensemble des fonctionnalités prioritaires, et le choix de la techno, sont liés. Cela pose un gros problème aux commerciaux, qui, ne connaissant que rarement la technique, ont tendance à tout vendre comme possible, sans tenir compte des impact des technos…

  6. @Thomas : Hum oui et non. Certes, dans une certaine mesure, la technique peut impacter le fonctionnel. Mais si un besoin fonctionnel précis a été exprimé dans la spec fonctionnelle, et que ce besoin n’est pas adressable avec les moyens techniques habituellement mis en œuvre dans l’équipe/l’entreprise, c’est au moment de la spec technique que l’on va réfléchir aux technos à déployer pour remplir le besoin.

    En tout cas, c’est l’optique du cycle en V. Sur des projets informatiques gérés en méthodologie agile, on procédera différemment. Mais ce n’était pas le but de l’article 🙂

  7. Intéressant. J’ai beaucoup utilisé cette méthode et je continue à l’appliquer aujourd’hui. Je connais également SCRUM que j’ai utilisé une fois partiellement. Actuellement, beaucoup de personnes tendent à dénigrer cette méthode de cycle en V en pointant tous ces inconvénients. Je pense que c’est aussi facile de pointer les inconvénients des méthodes Agiles qui sont aussi nombreux. Malgré tout, l’utilisation d’une méthode, quelqu’elle soit est souvent plus efficace que pas de méthode du tout. Les grandes difficultés que j’ai pu observer :
    Tous les acteurs impliqués ne connaissent pas la méthode ou pire, ne sont pas d’accord sur la méthode ou son application.
    Les personnes qui interviennent n’ont pas les compétences requises.
    Les objectifs du projets (qualité, délais, couts) ne sont pas compatibles avec les moyens.
    Enfin, je suis convaincu que le pragmatisme doit toujours être de mise : Appliquer une méthode de manière scolaire consomme souvent une énergie inappropriée et n’aboutit pas forcément à la meilleure solution : il faut régulièrement définir comment on va appliquer la méthode aux cas à gérer, et quelquefois combiner plusieurs méthodes.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.