10 mois de dev, 40% livré, le métier n’a rien vu — bienvenue en cycle en V

Le décor

Une boîte de services financiers lance la refonte de son portail client. 12 personnes dans l’équipe : développeurs, testeurs, un AMOA. Planning initial : 10 mois en cycle en V. Specs → dev → recette → livraison. Classique.

Sauf que 10 mois plus tard, il y a 40% du périmètre livré. Et le métier n’a rien vu. Pas une démo, pas un prototype, rien. Ils attendent. Et ils commencent à s’impatienter sérieusement.

Pourquoi ça a déraillé

Quand on arrive, on comprend vite :

• Un CDC de 180 pages rédigé en début de projet. Depuis, plus aucun échange structuré entre le métier et les dévs. Chacun travaille dans son coin.
• Les specs sont ambiguës sur plein de sujets. Les dévs interprètent, le métier découvrira en recette que c’est pas ce qu’il voulait. On appelle ça l’effet tunnel.
• Pas de priorisation. Tout est « prioritaire », du coup rien ne l’est. L’équipe avance sur 8 sujets en parallèle, aucun n’est fini.
• L’équipe est cramée. 10 mois à bosser sans jamais rien livrer de « fini », c’est épuisant moralement. Zéro sentiment d’accomplissement.

Le directeur de projet envisage de demander 6 mois de plus. Le sponsor hésite à tout arrêter.

Ce qu’on a fait

On n’a pas débarqué en mode « ON VA FAIRE DE L’AGILE » avec des Post-it partout et un coach certifié en lâcher-prise. On a résolu les vrais problèmes du projet avec les outils de Scrum, sans le jargon inutile.

Semaine 1 : le backlog — 180 pages → 85 user stories

On a repris le CDC avec le métier. On a découpé les 180 pages en user stories. Pour chacune, une question simple : « si tu devais livrer le portail dans 3 mois, tu gardes ou tu vires ? ». Résultat : 85 stories, dont 30 identifiées comme MVP.

On a aussi posé une Definition of Done claire : développé + testé + validé par le métier. Plus rien ne sort du sprint sans validation.

Sprint 1 : le déclic

Premier sprint de 2 semaines. Daily de 15 min, planning, review avec le métier, rétro.

Au bout des 2 semaines, le métier a vu quelque chose de fonctionnel pour la première fois en 10 mois. Un truc simple — la page d’accueil avec le dashboard. Mais un truc qui marche, qu’on peut cliquer, qu’on peut critiquer.

La réaction du responsable métier : « Ah mais c’est pas du tout ce que j’avais en tête pour la partie synthèse ». PARFAIT. C’est exactement pour ça qu’on montre tôt. Mieux vaut découvrir le problème au sprint 1 qu’à la recette finale.

Sprints 2-3 : le rythme s’installe

Au sprint 3, la vélocité était stable. L’équipe savait ce qu’elle pouvait livrer en 2 semaines. Le métier avait des demos régulières. Les retours étaient concrets et traités en temps réel.

Et surtout : l’équipe avait retrouvé la pêche. Quand tu livres un truc fini toutes les 2 semaines et que le métier dit « c’est bien », ça change tout.

Mois 3-8 : transférer et se retirer

On n’est pas là pour rester indéfiniment. Au bout de 4 mois, on a formé un Scrum Master interne. On est passé à 1 jour/semaine en accompagnement léger, puis on s’est retiré. L’équipe tournait toute seule.

Le résultat

Ce qu’on en retient

Le V n’est pas « mal » en soi. Mais quand le métier ne sait pas exactement ce qu’il veut tant qu’il ne l’a pas vu, c’est un piège. Tu spécifies dans le vide, tu développes dans le vide, tu découvres les problèmes à la fin quand c’est trop tard.

Scrum n’a pas « sauvé » le projet par magie. Ce qui a marché c’est de rétablir le feedback. Le métier voit, réagit, ajuste. L’équipe livre, progresse, se remotive. C’est un cercle vertueux.

Et la priorisation, c’est juste : accepter qu’on ne peut pas tout faire. Et choisir ce qui compte vraiment. Quand on arrête de vouloir tout faire en même temps, les choses avancent.