Voilà un beau titre de billet. Derrière ce titre en fait se cache l'interrogation de savoir finalement quel est notre réel travail en tant qu'informaticien. Je vais sans doute paraphraser ce qui a été dit dans plein d'autres endroits, mais je me jette tout de même à l'eau.

Quand j'observe le tissu actuel des SSII, que ce soit en prestation, ou en régie, la tendance est plutôt à dire que le client arrive avec un besoin le plus "carré" possible, et à nous la charge de le traduire en quelque chose de technique. De cette idée découle le fonctionnement en forfait standard: je fais une phase de conception sur ces besoins, je chiffre, et je vends ce chiffre au client.

La faille dans ce monde merveilleux, tout le monde est plus ou moins d'accord pour dire que c'est ce fameux besoin. Les partisans de la rigidité vont alors dire qu'il faut l'encadrer sévèrement, et une fois qu'il est signé, on y touche plus. Les agilistes disent, non nous allons intégrer ces changements au fils de l'eau, c'est normal. Bien entendu, je suis plus partisan de l'école agile, car ainsi le client peut se rendre compte par lui-même plus vite ce qu'il veut ou pas. Mais à cette activité je voudrai ajouter une subtilité supplémentaire: le client ne connait de toute manière pas son besoin.

En cherchant un peu de documentation sur le sujet, je suis tombé sur une belle analogie qui correspond exactement à ce que j'essayais dire.

Pour traduire rapidement, on peut comparer finalement le travail de consultant à celui d'un médecin: Le patient va sans doute exprimer sa demande sous forme d'un "j'ai besoin de me débarrasser de cette maladie", comme d'un "j'ai mal, donnez moi un médicament". Quand le patient arrive en demandant directement le médicament, c'est là même chose que quand un client nous demande un logiciel spécifique supposé résoudre son problème.

Pourtant, le médecin écoute et pose des questions, malgré ces affirmations initiales, pour découvrir les véritables causes du problème. S'il se contente d'écouter le patient, et de lui donner le médicament demandé alors que ce n'est pas le bon, c'est entièrement sa faute. Il en va de même pour nous: nous devons poser les bonnes questions et correctement analyser pour donner une réponse traitant les racines du problème. Le client ne pouvant pas dire ce qu'il veut, c'est notre travail de le découvrir

Dans la réalité, même dans un processus agile, cela se traduit par toujours rechercher les causes premières. Si le responsable produit me demander "je veux un export excell", ma première question est toujours pourquoi? Et ainsi je découvre que le véritable besoin derrière était du reporting et du décisionnel, et je m'oriente vers cette solution.