Couper le périmètre avant d'écrire la première ligne

Premier rendez-vous. Le client sort sa liste, soigneusement préparée : une trentaine de fonctionnalités, des écrans déjà imaginés, parfois des maquettes. Il est sûr de lui. Et c’est là, précisément, que se joue la réussite ou l’échec du projet — bien avant la première ligne de code.

Parce que cette liste, presque toujours, n’est pas le produit. C’est un empilement de solutions à un problème que personne n’a encore formulé clairement. La compétence la plus rentable, ce n’est pas de tout construire vite : c’est de décider, calmement, ce qui ne sera pas construit.

Regarder le travail réel avant d’écrire un cahier des charges

Avant de cadrer quoi que ce soit, je passe du temps à observer comment les gens travaillent vraiment. Sur un SaaS de pilotage pour boulangerie, le besoin initial réclamait une application web et mobile, tous les modules d’un coup. Sur le papier, ambitieux. Dans les faits, un tunnel de plusieurs mois avant le moindre retour utilisateur.

On a tout redécoupé pour démarrer sur un seul MVP web, validable vite. Le reste est passé en phases distinctes. Moins flatteur à présenter, infiniment plus sûr à livrer.

Chaque fonctionnalité a une facture cachée

On croit qu’ajouter une fonctionnalité, c’est écrire un peu de code. C’est faux. C’est du code à tester, à documenter, à maintenir, à expliquer — pour toujours. La bonne question n’est jamais « est-ce utile ? ». Presque tout est vaguement utile. La vraie question, plus dure, c’est : « est-ce utile au point de mériter sa dette ? »

Livrer petit pour apprendre vite

Un MVP volontairement réduit, mis en production en cinq semaines, apprend plus sur le produit que six mois de spécifications. L’usage réel tranche en un après-midi des débats qu’aucune réunion ne tranche jamais.

La vraie discipline, ici, ce n’est pas technique. C’est de résister à l’envie d’avoir raison tout de suite — et d’accepter que le produit, c’est le terrain qui le dessine, pas le rendez-vous de cadrage.