En début de carrière, j’ai longtemps cru que bien comprendre les besoins d’un utilisateur, c’était une question de méthode. Agile, user stories, rituels Scrum bien tenus. J’ai appris que c’était surtout une question de patience, et d’accepter que les gens ne savent souvent pas ce qu’ils veulent jusqu’à ce qu’ils le voient (ou jusqu’à ce qu’on leur pose les bonnes questions).

Ce qui ne marchait pas

Chez Psynapse, j’ai construit un CRM à destination de thérapeutes. Pas des développeurs, pas des product owners rompus aux wireframes. Des gens dont le métier, c’est l’accompagnement humain, et qui n’avaient pas de vocabulaire pour me dire ce dont ils avaient besoin en termes de logiciel.

Au début, je procédais comme sur n’importe quel projet : je posais des questions, je notais les réponses, je revenais avec un prototype. Et je me retrouvais systématiquement avec quelqu’un qui me disait “oui, c’est ce que j’avais demandé… mais ce n’est pas ce que je voulais.” Ca m’a cassé les dents pas mal de fois.

Ce qui a changé la donne

Ce qui a changé la donne, c’est d’arrêter de poser des questions sur l’outil pour poser des questions sur le travail. Pas “vous voulez un formulaire ou une liste ?” mais “quand vous cherchez les infos d’un patient, qu’est-ce qui vous prend du temps aujourd’hui ?”. La différence est énorme. La deuxième question laisse émerger quelque chose de vrai, une douleur réelle, pas une représentation de solution.

Même posture, autre public

Quelques années plus tard, je suis sur une mission dans un grand groupe industriel, en prestation DevOps sur des outils utilisés par des équipes de simulation et de data science. Des ingénieurs brillants, spécialistes de leur domaine, qui n’ont pas toujours les mots pour ce qu’ils attendent d’une plateforme. Et j’ai réalisé que tout ce que j’avais appris avec ces utilisateurs non-techniciens s’appliquait exactement ici.

Quand quelqu’un me dit “j’ai besoin que le déploiement soit plus simple”, il me dit en réalité quelque chose comme : “aujourd’hui je perds du temps sur un truc qui n’est pas mon cœur de métier, et ça m’énerve.” La solution peut être un pipeline, une interface, une doc, ou carrément supprimer une étape. Mais si je pars sur le premier truc qui me paraît logique, je risque de construire à côté.

Ca ne change pas la stack. Kubernetes reste Kubernetes. Mais ça change la façon dont j’écoute avant de concevoir, et ça change ce que je priorise quand j’ai plusieurs choses à faire.

Je ne pense pas que cette posture soit “naturelle” pour tout le monde dans les métiers techniques. On a tendance à vouloir résoudre vite, parce que résoudre c’est ce qu’on fait bien. Le risque, c’est de résoudre le mauvais problème avec beaucoup de soin.

Ce que j’ai appris avec des utilisateurs non-techniciens, et que j’applique encore aujourd’hui avec des ingénieurs, c’est qu’un besoin mal formulé n’est pas un problème de communication de leur côté. C’est une invitation à creuser un peu plus.