On aurait tendance, et c’est bien naturel, à vouloir satisfaire la demande de nos clients. “Le client est roi”, “il sait ce qu’il lui faut”, bref sa simple commande contient déjà tout, il suffit de la traduire en spec (spécifications fonctionnelles) et de faire ce qu’il demande. Au final, on se rend souvent compte que les utilisateurs n’utilisent pas plus de 50% (si ce n’est 80%) de ce qui a été commandé.

Que faire ?

Si seulement 20% de l’application est utilisée, c’est qu’il n’y avait pas besoin des 80% restant. “Il y a eu confusion entre le besoin et la demande. Les utilisateurs expriment une demande, mais elle ne correspond pas nécessairement à leurs besoins” dit Michel Volle. En effet le client a des besoins légitimes, ses propres besoins. Mais il ne sait pas forcement les exprimer correctement et clairement. Ainsi son expression des besoins est maladroite car pas adapté au sujet, la réalisation d’une application dans notre cas.

Si on prend un parallèle avec un architecte, vous avez certainement en tête la maison de vos rêves, qui, d’après vous, correspond à vos besoins. Vous serez même capable de dessiner la maison si l’architecte vous demande "quel type de maison voulez-vous ?".

Il y a de grandes chances que si l’architecte réalise cette maison, vous ne vous sentiez pas bien dedans, qu’elle ne vous correspond pas.

Par contre si après plusieurs discussion sur votre manière de vivre, vos habitudes, vos envies, vos réticences, ... l’architecte élabore les plans de votre maison, elle ne ressemblera pas à votre dessin mais elle correspondra complétement à vos besoins.

Que voulez vous faire ? Que voulez vous que l’utilisateur fasse ?

Ces deux questions sont essentielles au démarrage d’un projet. Si on réalise une application, il faut absolument poser la question : "que voulez vous résoudre comme problème avec cette application ?"

On pourra ainsi passer de la demande au besoin. En aidant le client à REformuler sa demande en des termes correspondant à ses besoins. Ainsi on découvrira peut-être des choses auquelles il n’aura pas pensé, et on mettra au rebut les fonctionnalités superflues.

Ainsi quand un client dira "faites ce que je vous demande", il faudra lui faire comprendre gentillement mais clairement que ce n’est pas dans son intérêt.

Une histoire faisant le parallèle entre contruction et projet informatique montre bien les dangers d’une mauvaise expression des besoins. C’est àpeine caricaturé.