Un client arrive rarement avec un besoin brut. Il arrive avec une solution déjà en tête : « il me faut une application », « il faut refaire le site », « on a besoin d'un tableau de bord ». Ce n'est pas un problème en soi, mais ce n'est pas non plus le point de départ. Le point de départ, c'est ce qui se passe aujourd'hui sans cet outil, et ce qui coince précisément.
Séparer le besoin de la solution imaginée
Avant de parler technologie, je pose des questions sur l'usage réel : qui va s'en servir, à quelle fréquence, et qu'est-ce qui est fait à la place aujourd'hui — un fichier Excel, un échange d'e-mails, une tâche manuelle répétée. Souvent, la réponse à ces questions change complètement le périmètre du projet, parfois en le simplifiant, parfois en révélant un besoin plus large que celui formulé au départ.
Les questions qui reviennent à chaque fois
- Qui utilise ça, et combien de fois ? Un outil utilisé une fois par mois n'a pas les mêmes exigences qu'un outil ouvert vingt fois par jour.
- Que se passe-t-il sans cet outil aujourd'hui ? Le contournement actuel en dit souvent plus sur le vrai besoin que la demande initiale.
- Qu'est-ce qui doit marcher dès le premier jour, et qu'est-ce qui peut attendre ? Confondre les deux fait gonfler le budget et retarder la mise en ligne sans raison.
- Qui décide que c'est réussi ? Dans mon expérience, un critère de succès flou est ce qui fait le plus souvent traîner un projet en longueur.
Pourquoi ça évite les mauvaises surprises
Un projet bien cadré change moins en cours de route, et ce n'est pas de la chance : c'est que les décisions difficiles ont été prises tôt, quand elles coûtent une conversation, plutôt que tard, quand elles coûtent une refonte. C'est aussi pour ça que je reste seul interlocuteur du premier échange à la mise en ligne : les réponses à ces questions ne se perdent pas dans un relais entre un commercial, un chef de projet et un développeur, elles guident directement le code que j'écris.
Ce cadrage ne prend pas des semaines. Souvent, une heure de discussion suffit à clarifier l'essentiel — et cette heure-là est presque toujours plus rentable que n'importe quelle heure de développement qui suivrait un mauvais départ.