Cycle en V vs Agile : pourquoi votre façon de penser vous fait échouer (et comment la corriger)

Vous avez été formé au cycle en V.
Vous savez structurer, planifier, sécuriser.

Et pourtant, dès que vous passez à l’agile… quelque chose ne fonctionne pas.

Les projets dérapent.
Les équipes ne réagissent pas comme prévu.
Et à l’examen PSM, certaines réponses “logiques” deviennent fausses.

Le problème n’est pas votre niveau.
Le problème, c’est votre manière de penser le projet et c’est exactement ce que l’examen PSM met à l’épreuve.

Comprendre cette bascule est indispensable pour travailler efficacement en agile… et réussir les certifications Scrum.

👉 À l’examen PSM, cette différence change complètement la manière de répondre : ce qui semble logique en cycle en V est souvent faux en Scrum.

Ce que le cycle en V ne peut plus offrir

Le cycle en V fonctionne remarquablement bien dans des environnements stables, où les besoins sont clairs dès le départ et peu susceptibles d'évoluer. Sa force est sa rigueur : chaque phase est validée avant de passer à la suivante, ce qui limite les risques de régression et facilite la gestion documentaire.

Mais cette même rigueur devient son talon d'Achille dès que le contexte se complexifie. Lorsque les besoins évoluent en cours de projet — ce qui est aujourd'hui la règle plutôt que l'exception — le cycle en V génère un "effet tunnel" redoutable : le client découvre le produit fini après des mois de développement, parfois pour constater qu'il ne correspond plus à ses attentes réelles. Les corrections sont alors coûteuses, les délais s'allongent, la valeur délivrée s'érode.

C'est précisément ce constat qui a conduit dix-sept experts du développement logiciel à se réunir à Snowbird, Utah, en février 2001. Leur conclusion a donné naissance au Manifeste Agile — un texte court, mais fondateur, qui propose quatre valeurs essentielles : privilégier les individus et leurs interactions plutôt que les processus ; livrer des logiciels fonctionnels plutôt qu'une documentation exhaustive ; collaborer avec le client plutôt que négocier des contrats ; et s'adapter au changement plutôt que suivre un plan figé.​​

L'agilité : un changement de paradigme, pas de méthode

Il serait réducteur de présenter l'agilité comme une simple alternative méthodologique au cycle en V. C'est avant tout un changement de posture face à l'incertitude. Là où le " V "cherche à éliminer l'inconnu dès la phase de spécification, l'agilité assume que l'inconnu est inhérent à tout projet complexe — et organise le travail pour le gérer en continu.

Concrètement, cela se traduit par des cycles courts et itératifs, appelés sprints dans Scrum, au cours desquels l'équipe livre un incrément fonctionnel, testé et potentiellement utilisable. À chaque fin de sprint, on inspecte ce qui a été produit, on recueille les retours, et on adapte la suite. Ce processus — transparence, inspection, adaptation — constitue les trois piliers de l'empirisme sur lequel repose Scrum.​​

Contrairement au cycle en V où le triangle temps/coût/périmètre est figé contractuellement dès le départ, l'agilité revisite ce modèle : le temps et les ressources sont fixes (la durée du sprint, la composition de l'équipe), mais le périmètre est variable, ajusté sprint après sprint en fonction de la valeur réellement perçue. Ce n'est plus "comment livrer tout ce qui est prévu dans les délais ?" mais "comment maximiser la valeur délivrée avec les ressources disponibles ?"​​

Scrum en pratique : les repères essentiels

Scrum est aujourd'hui le framework agile le plus utilisé au monde. Il structure le travail autour de trois rôles complémentaires :

• le Product Owner, qui définit et priorise la valeur dans le Product Backlog ;

• les Developers, qui s'auto-organisent pour produire l'incrément à chaque sprint ;

• et le Scrum Master, qui facilite le cadre, lève les obstacles et accompagne l'équipe dans sa progression.​

Ce dernier rôle surprend souvent les praticiens du cycle en V : le Scrum Master n'est pas un chef de projet. Il ne distribue pas les tâches, ne valide pas les livrables, ne pilote pas le planning. Il est un leader serviteur, au service de l'équipe et de l'organisation, dont la valeur se mesure à la fluidité qu'il crée — pas au contrôle qu'il exerce.​​

Cinq événements rythment chaque sprint :

• le Sprint Planning (définir l'objectif et le travail du sprint),

• le Daily Scrum (synchronisation quotidienne des Developers),

• la Sprint Review (présentation de l'incrément aux parties prenantes),

• la Sprint Retrospective (amélioration continue du fonctionnement de l'équipe),

• et le Sprint lui-même, conteneur de tous les autres.

Chacun de ces événements a une durée maximale — le timebox — qui garantit le rythme sans laisser place à la dérive.​​

Ce que cette transition révèle à l'examen

Comprendre l'agilité depuis le cycle en V, c'est aussi apprendre à raisonner différemment. Les réflexes acquis en environnement prédictif — planifier en détail avant d'agir, tester en fin de cycle, centraliser les décisions chez le chef de projet — sont précisément ceux que les certifications Scrum comme le PSM I et le PSM II cherchent à dépasser.​​

Un candidat qui pense en "V" aura tendance à prolonger un sprint si le travail n'est pas terminé, à abaisser les critères de qualité pour livrer plus vite, ou à voir le Daily Scrum comme une réunion de reporting hiérarchique.

Ces trois erreurs font échouer une grande partie des candidats — même expérimentés — et elles sont toutes issues du même malentendu fondamental : confondre Scrum avec un cycle en V accéléré.​

Maîtriser cette distinction, c'est donc à la fois progresser dans sa pratique professionnelle et se préparer efficacement aux certifications Scrum. Les deux avancent ensemble.​​

👉 À l’examen PSM : toute réponse qui positionne le Scrum Master comme un chef de projet est incorrecte.

Vers une pratique agile authentique

La transition du cycle en V vers l'agilité ne s'opère pas en quelques jours. Elle demande de désapprendre certains automatismes, d'accepter l'incertitude comme donnée de travail, et de faire confiance à une équipe auto-organisée plutôt qu'à un plan exhaustif.

Le plus efficace est souvent de commencer par Kanban — plus accessible, sans rupture brutale avec les habitudes existantes — avant d'adopter Scrum sur des projets à plus forte complexité. Quelle que soit la trajectoire choisie, l'essentiel est d'intégrer l'empirisme comme boussole : inspecter régulièrement, adapter en continu, et toujours raisonner en termes de valeur délivrée.

Comprendre l’agilité est une première étape.
Savoir raisonner correctement à l’examen PSM en est une autre.

Pour passer de la théorie à la réussite :

• PSM I : entraînez-vous sur les pièges classiques, sécurisez votre score et évitez les erreurs de raisonnement.

• PSM II : travaillez la posture attendue et les situations complexes de l’examen.

• L’Agilité pour tous : consolidez vos fondamentaux pour éviter les confusions entre cycle en V et Scrum.

Disponibles en PDF sur ce site et en version Kindle et brochée sur Amazon.

Ne vous contentez pas de comprendre l’agilité. Apprenez à répondre juste et à réussir dès le premier passage.