Cycle en V et agilité : deux façons de mener un projet

Pourquoi on voit ça

Un projet informatique, ce n’est pas seulement du code. Il faut décider dans quel ordre on fait les choses, quand on montre le résultat au client, et comment on réagit s’il change d’avis. Il existe deux grandes familles de réponses : l’approche prédictive, dont le cycle en V est le représentant le plus connu, et l’approche agile.

En DevOps, tu travailleras presque toujours avec des équipes agiles : livraisons fréquentes, automatisation, retours rapides. Mais beaucoup d’entreprises fonctionnent encore en cycle en V. Tu dois connaître les deux, savoir les comparer honnêtement, et expliquer pourquoi on passe de l’une à l’autre.

Le cycle en V

Le cycle en V découpe le projet en phases qui se suivent. On ne commence une phase que lorsque la précédente est terminée et validée. Le nom vient de sa forme : on descend en précisant de plus en plus, on code à la pointe, puis on remonte en testant de plus en plus large.

La branche descendante : on définit

Phase	Ce qu’on produit
Expression du besoin	Ce que veut le client, dans ses mots (cahier des charges)
Spécifications	Ce que le logiciel devra faire, fonction par fonction
Conception générale	L’architecture : les grands blocs et leurs échanges
Conception détaillée	Le détail de chaque composant

Puis vient le codage, à la pointe du V.

La branche remontante : on vérifie

Chaque phase de test est en face de la phase qu’elle vérifie.

Phase de test	Elle vérifie	En face de
Tests unitaires	Chaque composant, seul	Conception détaillée
Tests d’intégration	Les composants assemblés	Conception générale
Tests de validation	Le logiciel complet, face aux spécifications	Spécifications
Recette	Le client vérifie que son besoin est couvert	Expression du besoin

Contexte, pas à apprendre. Les noms des phases varient un peu d’un livre à l’autre (« analyse », « architecture », « tests système »…). La logique, elle, ne change pas : une descente qui définit, une remontée qui vérifie, et une correspondance niveau par niveau.

Ses points forts

• Clair et rassurant : chacun sait où en est le projet et ce qu’il doit livrer.
• Bien documenté : chaque phase produit un document validé. Utile quand il faut prouver ce qui a été fait.
• Prévisible : périmètre, budget et date sont fixés au départ.
• Tests pensés tôt : dès qu’on écrit une spécification, on sait quel test la vérifiera.

Ses limites

• L’effet tunnel : après les spécifications, le client ne voit plus rien de concret jusqu’à la recette. Cela peut durer des mois.
• Le retour tardif du client : s’il y a eu un malentendu sur le besoin, on le découvre à la fin, quand tout est construit.
• Le changement coûte cher : chaque phase s’appuie sur la précédente. Modifier le besoin en cours de route oblige à reprendre les documents, la conception, le code et les tests.
• Les erreurs de conception se voient tard : un défaut d’architecture n’apparaît qu’aux tests d’intégration, loin du moment où il a été créé.

L’image à garder : tu commandes une maison sur plans, puis tu ne reviens que le jour de la remise des clés. Si la cuisine n’est pas où tu l’imaginais, il est trop tard pour déplacer les murs à bas prix.

Le Manifeste agile

En 2001, dix-sept praticiens du logiciel rédigent un texte très court : le Manifeste pour le développement agile de logiciels. Il tient en 4 valeurs et 12 principes.

Les 4 valeurs

On privilégie…	…plus que
Les individus et leurs interactions	les processus et les outils
Un logiciel opérationnel	une documentation exhaustive
La collaboration avec le client	la négociation contractuelle
L’adaptation au changement	le suivi d’un plan

Attention au sens de « plus que ». Le Manifeste précise que les éléments de droite ont de la valeur. Simplement, quand il faut choisir, ceux de gauche passent en premier. « Agile » ne veut donc pas dire « sans plan » ni « sans documentation ».

L’idée des 12 principes

Tu n’as pas à les réciter. Retiens ce qu’ils disent dans l’ensemble :

• satisfaire le client en livrant tôt et souvent un logiciel utile ;
• accueillir le changement, même tard dans le projet ;
• faire travailler ensemble, au quotidien, les gens du métier et les développeurs ;
• mesurer l’avancement avec du logiciel qui fonctionne, pas avec des documents ;
• garder un rythme soutenable, viser la simplicité ;
• s’arrêter régulièrement pour réfléchir à comment s’améliorer.

L’agilité est donc un état d’esprit. Scrum, que tu verras dans la leçon suivante, est un cadre concret pour l’appliquer.

Itératif et incrémental

Ces deux mots vont ensemble, mais ils ne disent pas la même chose.

Mot	Sens	Image
Itératif	On répète un cycle court : on fait, on montre, on corrige, on recommence	Un sculpteur qui affine sa statue à chaque passage
Incrémental	On livre le produit par morceaux qui fonctionnent et qui s’ajoutent	Un mur qu’on monte rangée par rangée

Une équipe agile fait les deux : à chaque cycle, elle ajoute un morceau utilisable et elle améliore ce qui existe grâce aux retours. Le client n’attend plus la fin : il voit le produit grandir, et il peut réorienter le projet après chaque cycle.

Cycle en V ou agile : le comparatif

Critère	Cycle en V	Agile
Déroulement	Séquentiel, une phase après l’autre	Cycles courts répétés
Besoin	Figé au départ	Peut évoluer à chaque cycle
Livraison	Une seule, à la fin	Fréquente, par morceaux
Retour du client	Tardif (recette)	À chaque cycle
Changement	Coûteux, vécu comme un problème	Attendu et accueilli
Documentation	Complète, à chaque phase	Juste ce qui est utile
Ce qui est fixé	Le périmètre	La durée des cycles
Risque principal	Livrer à l’heure un produit qui ne convient plus	Manquer de vision d’ensemble si le client ne s’implique pas

Dans quels cas chaque approche se défend

Le cycle en V se défend quand le besoin est connu et stable, quand une réglementation impose des preuves écrites à chaque étape (aéronautique, médical, ferroviaire), ou quand une erreur découverte tard serait très grave. Il convient aussi quand le client ne peut pas se rendre disponible pendant le projet.

L’agilité se défend quand le besoin est incertain ou changeant, quand on veut des retours rapides du terrain, et quand le client accepte de s’impliquer régulièrement. C’est le cas de la plupart des applications web et des produits numériques.

Aucune des deux n’est « la bonne » dans l’absolu. La bonne question est : à quel point le besoin risque-t-il de bouger ?

À retenir

• Cycle en V : on descend en définissant (besoin, spécifications, conception générale, conception détaillée), on code, on remonte en testant (unitaires, intégration, validation, recette). Chaque test est en face de la phase qu’il vérifie.
• Ses limites : effet tunnel, retour tardif du client, changement coûteux.
• Manifeste agile (2001) : 4 valeurs, 12 principes. Individus, logiciel opérationnel, collaboration avec le client, adaptation au changement.
• « Plus que » ne veut pas dire « à la place de » : le plan et la documentation gardent de la valeur.
• Itératif : on répète un cycle court pour améliorer. Incrémental : on ajoute des morceaux qui fonctionnent.
• Cycle en V pour un besoin stable et très encadré ; agile pour un besoin incertain et un client disponible.