Le bon interlocuteur, et autres leçons de conception

Depuis un moment, mon travail commence rarement par du code. Il commence par des réunions, des comptes rendus, des user stories et un backlog. Sur Isra Voyages, une plateforme de réservation de voyages organisés, j'ai tenu ce rôle de conception et de Business Analyst. Et la leçon la plus utile n'a rien à voir avec la méthode. Elle tient dans une question : à qui je parle vraiment ?

Le besoin bouge, toujours

Un besoin, ce n'est jamais un document figé qu'on vous remet. C'est une idée qui se précise au fil des échanges, qui change quand le client voit la première maquette, qui se contredit parfois d'une réunion à l'autre. J'ai appris à spécifier dans cette incertitude : figer ce qui est stable, laisser des portes ouvertes sur le reste, et surtout écrire pour pouvoir revenir en arrière sans tout casser. Les user stories, les diagrammes, le prototype : tout ça sert autant à décider qu'à documenter.

Le bon interlocuteur change tout

Voici la vraie leçon. Sur un projet, la personne qui finance n'est presque jamais celle qui connaît le métier au quotidien. Au début d'Isra, on échangeait avec les bons décideurs côté budget, mais pas avec ceux qui gèrent réellement les départs, les quotas et les inscriptions. Résultat : des allers-retours, des specs à moitié justes, du temps perdu.

Le jour où on a parlé aux personnes qui font tourner Isra tous les jours, tout est allé plus vite. Les questions trouvaient des réponses précises, les cas limites sortaient d'eux-mêmes. Depuis, ma première tâche sur un projet n'est plus d'écrire une ligne de spec. C'est d'identifier qui sait, et de m'assurer que je lui parle en direct.

Le mail est un piège

Corollaire du point précédent. Un client occupé ne répond pas à un mail qui contient dix questions. Il le lit, se dit qu'il répondra plus tard, et il oublie. On relance, poliment, une fois, deux fois. Le projet attend.

J'ai fini par changer de canal. Quand un sujet bloque, je n'écris plus, j'appelle, ou je cale une visio de vingt minutes. En vingt minutes de voix, on tranche ce qui aurait pris deux semaines de mails sans réponse. Le mail garde une utilité réelle : tracer une décision une fois qu'elle est prise. Pas pour la prendre.

Ce que je ne vous vends pas

La conception, ce n'est pas confortable. On spécifie dans le flou, on prend des décisions qu'on devra peut-être défaire, et on encaisse des arbitrages clients frustrants, parfois contre l'avis qu'on défendait. Une partie de la documentation qu'on soigne ne sera jamais lue. Et pour quelqu'un qui aime coder, passer des jours en réunions et en tableaux plutôt que dans l'éditeur, ça demande un vrai changement de posture. Je ne prétends pas que ça me plaît tous les jours.

Verdict

On imagine la conception comme un travail de méthode : les bons templates, le bon découpage, le bon outil. C'est incomplet. Un projet ne cale presque jamais sur la méthode. Il cale sur l'accès à la bonne personne, et sur le bon canal pour lui parler. La vraie compétence de Business Analyst, ce n'est peut-être pas de savoir écrire une user story. C'est de savoir à qui la faire valider.