« On voudrait un chatbot pour répondre aux questions des clients. » J'ai entendu cette phrase des dizaines de fois. Derrière, presque jamais le même problème : parfois un délai de réponse trop long, parfois une base de connaissance introuvable, parfois trois personnes qui répondent la même chose de trois façons différentes, parfois un service saturé qu'on n'ose pas renforcer. Le chatbot est la solution que la personne a vue quelque part. Le travail de discovery consiste à retrouver ce qu'elle cherchait à régler.
Pourquoi la demande arrive toujours en solution
Ce n'est pas un défaut de l'interlocuteur, c'est la manière normale de penser. On formule ce qu'on veut par la première forme concrète qui vient à l'esprit. Un dirigeant qui a vu une démonstration convaincante la transpose sur son propre contexte, et c'est un signe d'intérêt, pas de naïveté.
Le piège est ailleurs : si tu prends la demande au pied de la lettre, tu livres exactement ce qui a été demandé, tout le monde est poli à la recette, et l'usage retombe en un mois. Personne n'aura menti. Le besoin n'aura simplement jamais été formulé.
Pendant trois ans, comme coach produit à beta.gouv.fr, l'incubateur de services numériques de l'État à la DINUM, j'ai accompagné des Startups d'État. La discipline y est très explicite : une équipe doit démontrer qu'un problème existe et qu'il touche des gens réels avant d'obtenir la suite. On ne présente pas un outil, on présente ce qu'on a observé sur le terrain. Cette contrainte-là est la meilleure école de discovery que je connaisse, et elle s'applique telle quelle à un besoin IA.
Démonter une demande d'outil
Ma technique tient en un mouvement : remonter du geste vers la conséquence, puis redescendre vers les alternatives.
Quand on me dit « il nous faut un assistant qui résume les comptes rendus », je ne discute ni du modèle ni du format du résumé. Je demande qui lit ces comptes rendus, quand, et ce que cette personne en fait ensuite. Trois fois sur cinq, on découvre que personne ne les lit vraiment, qu'un destinataire cherche une seule information précise, et que le vrai besoin est un champ dans un tableau partagé.
Ce n'est pas de la ruse. C'est simplement admettre que la personne connaît son travail mieux que toi, et que ton apport consiste à poser les questions qu'elle n'a pas eu le temps de se poser.
La grille en sept questions
Je mène ces entretiens en quarante-cinq minutes, avec la personne qui fait le travail — pas seulement celle qui le pilote. Sept questions, toujours dans cet ordre.
1. Raconte-moi la dernière fois que ça s'est produit. Une occurrence datée, pas une généralité. Le récit fait apparaître les détours que la description théorique gomme.
2. Combien de fois par semaine ? La fréquence transforme une gêne en cas d'usage. Un irritant vécu deux fois par an ne justifie aucun projet, même s'il est douloureux.
3. Qu'est-ce que tu fais juste avant, et juste après ? C'est là que se cachent les vraies frictions. Souvent le geste qu'on veut automatiser est court, et c'est la préparation qui coûte une heure.
4. Qu'est-ce qui se passe si personne ne le fait ? Question inconfortable, très efficace. Elle sépare le travail nécessaire du travail hérité. Certaines tâches n'ont plus de destinataire depuis longtemps.
5. Comment tu t'en sors aujourd'hui quand ça coince ? Les contournements existants sont une mine. Un tableur bricolé par quelqu'un vaut une spécification complète : il montre exactement quelles informations comptent.
6. À quoi ressemblerait un bon résultat, et qui en juge ? Si personne ne sait dire ce qu'est une bonne réponse, aucune évaluation ne sera possible plus tard. Mieux vaut le découvrir maintenant.
7. Si on ne pouvait rien automatiser, qu'est-ce que tu changerais ? Ma question préférée pour finir. Elle libère la parole et fait remonter des solutions d'organisation qui coûtent dix fois moins cher.
Le but n'est pas de collecter des réponses. C'est de sortir de l'entretien en sachant décrire le problème sans prononcer le nom d'un outil.
Ce qui rate dans ces entretiens
Interroger uniquement les managers. Ils décrivent le processus tel qu'il devrait être. L'écart avec le processus réel est souvent le sujet principal.
Poser des questions au futur. « Est-ce que tu utiliserais un assistant qui… ? » Les gens répondent oui par politesse. Une question au futur ne produit aucune information exploitable ; une question au passé, si.
Prendre le premier « ça nous ferait gagner du temps » pour une réponse. Combien de temps, sur quel geste, pour qui ? Sans ces précisions, tu n'as rien.
Faire trop d'entretiens. Cinq à huit personnes sur un même processus suffisent presque toujours. À partir du sixième, on entend les mêmes phrases. Continuer devient une manière élégante de repousser la décision.
Ce que la discovery doit produire
Trois éléments, pas plus. Un problème formulé sans nom d'outil dedans, avec sa fréquence et les personnes concernées. Un critère de succès dont quelqu'un est juge. Une liste d'options, dont au moins une sans IA.
Cette dernière ligne est importante. Une discovery honnête aboutit régulièrement à « change le formulaire d'entrée » ou « supprime cette validation ». Ça ne dévalorise pas le travail fait — ça évite de payer six mois de développement pour un problème d'organisation.
Le geste à essayer cette semaine
À la prochaine demande d'outil qu'on t'adresse, ne réponds pas sur l'outil. Demande simplement : « raconte-moi la dernière fois ». Puis tais-toi et laisse parler. Ce silence-là fait remonter plus d'information que trois ateliers.