Un an sans feedback utilisateur : pourquoi le faux Agile tue vos projets SaaS

J'ai vécu une situation aberrante chez un client récemment. Un an. Un an entre le brief initial et le premier déploiement en production. Un an sans le moindre feedback d'utilisateur réel.

Voici exactement ce qui s'est passé : brief exhaustif rédigé, envoyé à une agence, semaines de validation sur de superbes maquettes Figma, et finalement un SaaS poussé en production bien après que le marché avait eu le temps de changer deux fois de cap.

Ce n'est pas une exception. C'est un pattern que je vois régulièrement. Et en 2026, c'est du suicide business.

Le "Cycle en V" déguisé en Agile

Ce que ces projets ont en commun, c'est une confusion fondamentale entre la forme et le fond. On affiche des sprints, des backlogs, des réunions de sprint review - mais en réalité, on applique un Cycle en V classique : tout est défini au départ, rien n'est confronté à la réalité avant la fin.

L'agile n'est pas un vocabulaire. C'est une philosophie d'exécution fondée sur une seule hypothèse : vous ne savez pas ce que vos utilisateurs veulent vraiment avant qu'ils l'utilisent vraiment.

Quand votre process ressemble à :

1. Brief complet
2. Spécifications fonctionnelles exhaustives
3. Maquettes Figma validées par dix personnes
4. Développement en silo pendant 9 mois
5. Livraison "grand soir"

...alors vous faites du Cycle en V. Peu importe le nom que vous mettez dessus.

Trois raisons pour lesquelles cette approche échoue systématiquement

1. Figma n'est pas un produit

Valider des écrans immobiles et esthétiques, c'est facile - et c'est trompeur. Une maquette Figma ne se confronte jamais à la réalité de la production : les lenteurs d'API, les temps de chargement réels, les erreurs inattendues, et surtout la logique d'un utilisateur qui clique là où vous n'avez pas prévu.

Le retour utilisateur sur une maquette mesure une chose : est-ce que l'utilisateur comprend l'interface. Ça ne mesure pas si le produit est utile, fiable, ou désirable. Ce sont trois questions différentes, et seule la mise en production peut répondre aux deux dernières.

J'ai vu des équipes passer trois semaines à débattre de la couleur d'un bouton en comité, pour découvrir six mois plus tard que la feature entière n'était pas utilisée. Le bouton, bleu ou vert, était secondaire. Le problème était en amont : la feature ne répondait pas au bon besoin.

2. Le marché bouge plus vite que votre agence

Ce que vous avez briefé il y a douze mois est déjà en partie obsolète aujourd'hui. Les usages changent, les concurrents sortent des MVP en trois semaines, les attentes des utilisateurs évoluent.

Pendant que vous validez des wireframes, quelqu'un d'autre livre. Pendant que vous rédigez les spécifications de votre fonctionnalité différenciante, un concurrent la pousse en beta et commence à collecter des retours. Vous arrivez sur un marché que vous pensiez connaître, avec une solution pensée pour ce marché tel qu'il était un an plus tôt.

Dans les startups early-stage, un an d'avance ou de retard peut faire la différence entre capturer une fenêtre de marché et la rater.

3. Le coût de correction est multiplié par 100

C'est la règle la mieux documentée du génie logiciel, et la moins appliquée.

Un bug ou un mauvais choix fonctionnel découvert en phase de conception coûte une heure de discussion. Le même problème découvert après un an de développement coûte des semaines de refactoring, des dizaines de milliers d'euros de temps de développement, et souvent six mois de délai supplémentaire pour repartir dans la bonne direction.

Se rendre compte qu'une feature est inutile ou mal conçue après un an de développement, c'est jeter à la poubelle tout ce qui a été investi - et recommencer avec le même processus, donc les mêmes risques.

La règle d'or du Product Management : le pragmatisme d'exécution

Le bon processus n'est pas de tout spécifier parfaitement avant de commencer. C'est de réduire au maximum la distance entre l'idée et le feedback réel.

Concrètement :

Définir le plus petit périmètre utile (MVP). Pas un produit complet, pas une v1 avec toutes les fonctionnalités imaginées - juste ce qui permet de valider l'hypothèse centrale. Qu'est-ce que les utilisateurs doivent pouvoir faire pour que vous sachiez si le produit est dans la bonne direction ?

Le coder proprement. La vitesse ne justifie pas la dette technique. Un MVP bien architecturé peut évoluer ; un MVP bâclé devient un mur. La qualité du code et la rapidité d'exécution ne sont pas opposées - elles dépendent toutes les deux des bons choix techniques dès le départ.

Le mettre en production en moins de 6 semaines. C'est le délai cible. Pas parfait, mais fonctionnel. Avec de vrais utilisateurs, dans de vraies conditions.

Laisser les utilisateurs le casser, puis itérer. C'est là que commence le vrai travail. Les bugs remontés, les features mal comprises, les workflows inattendus - c'est cette information qui oriente les itérations suivantes.

Moins de réunions de cadrage, moins de fantasmes sur Figma, plus de code en production.

Ce que ça implique concrètement pour votre organisation

Ce changement de méthode n'est pas qu'une question de process - il demande une culture différente.

Côté client/startup : accepter qu'un MVP ne soit pas beau ni complet. La v1 n'est pas là pour impressionner - elle est là pour apprendre. Si vous êtes gêné de montrer votre v1 à vos utilisateurs, vous avez attendu trop longtemps.

Côté technique : choisir une stack qui permet d'itérer vite sans s'enfermer. Une architecture qui permet de changer une feature en deux jours vaut plus qu'une architecture parfaite qui prend trois mois à modifier.

Côté agence ou prestataire : livrer des versions intermédiaires accessibles toutes les deux semaines, pas un livrable final un an plus tard. Si votre agence ne peut pas vous donner accès à une version de staging régulièrement, c'est un signal fort.

Le critère d'évaluation que j'utilise systématiquement

Quand j'entre sur un projet en tant que CTO, une des premières questions que je pose est simple : quel est le délai entre une idée et son premier test en production ?

Si la réponse dépasse six semaines pour une feature standard, il y a un problème - soit dans le process, soit dans la stack, soit dans l'organisation de l'équipe.

Ce délai est mesurable, il est réductible, et il est directement corrélé à la capacité du produit à s'adapter et à progresser.

---

Un délai d'un an entre la première idée et le premier test en prod, c'est un an de marché perdu, un an de feedback ignoré, et potentiellement des centaines de milliers d'euros investis dans la mauvaise direction.

La bonne nouvelle : ce n'est pas une fatalité. Avec les bons choix techniques et le bon process, six semaines est un objectif atteignable pour la grande majorité des MVP - y compris pour des produits complexes.