Discovery client : besoin réel, critères, victoire à 30 jours

Pourquoi ce module

C'est la moitié non technique du métier, celle que les ingénieurs préparent le moins, et celle sur laquelle les boucles d'entretien FDE éliminent le plus.

Pas parce qu'elle est plus difficile. Parce que les candidats techniques la considèrent comme secondaire, arrivent sans histoire à raconter, et répondent en généralités là où on attend un cas précis avec des noms, des chiffres et une décision qui a fâché quelqu'un.

Objectifs pédagogiques

1. Conduire une discovery et distinguer le besoin exprimé du besoin réel
2. Transformer un besoin en critères de succès mesurables
3. Cartographier les parties prenantes et anticiper qui peut bloquer
4. Concevoir une victoire à 30 jours et dire ce qu'elle exclut
5. Gérer le désaccord entre sponsor et utilisateur final
6. Organiser le transfert pour pouvoir partir

Plan détaillé

1. Le besoin exprimé n'est pas le besoin réel
2. Les questions qui ouvrent
3. Les critères de succès
4. La carte des parties prenantes
5. La victoire à 30 jours
6. Quand le sponsor et l'utilisateur divergent
7. Le transfert
8. Ce qui décide vraiment d'une mission
9. Glossaire du module

1. Le besoin exprimé n'est pas le besoin réel

Un client ne décrit presque jamais son problème : il décrit la solution qu'il a imaginée. « Un chatbot sur nos documents » est déjà une réponse — à une question que personne n'a formulée.

Le travail de discovery consiste à remonter d'un cran : quel est le problème dont ce chatbot serait la solution ? Souvent, la réponse ouvre d'autres solutions, plus simples et plus utiles.

🎯 La question qui remonte d'un cran. « Si ce système existait déjà et marchait parfaitement, qu'est-ce qui serait différent lundi matin, pour qui ? »

Elle force à décrire un changement observable chez une personne identifiée. Une réponse floue à cette question est un signal fort : le besoin n'est pas mûr, et construire tout de suite serait construire la mauvaise chose.

2. Les questions qui ouvrent

💡 La cinquième question est la plus rentable. Un système qui automatise une tâche menace toujours quelqu'un : celui dont c'était le savoir-faire, celui qui contrôlait l'accès à l'information, celui qui avait proposé une autre solution l'an dernier. Les projets d'IA ne meurent presque jamais de problèmes techniques ; ils meurent d'une opposition qu'on n'avait pas vue.

3. Les critères de succès

C'est le livrable de la discovery, et le seul qui protège tout le monde.

Les trois propriétés d'un bon critère : il est mesurable sans jugement, il est daté, et quelqu'un est d'accord pour être jugé dessus.

🎯 La formule à connaître. « Un critère de succès sur lequel personne n'accepte d'être jugé n'est pas un critère : c'est un souhait. Je le fais valider par écrit par le sponsor avant d'écrire une ligne de code — pas pour me couvrir, mais parce que l'exercice de le formuler révèle systématiquement un désaccord qu'on n'avait pas vu. »

4. La carte des parties prenantes

Le principe : identifier tôt qui peut dire non, et aller le voir avant qu'il ne le dise. Un RSSI consulté en semaine 2 est un allié qui pose ses conditions ; le même consulté en semaine 12 est un obstacle qui découvre un fait accompli.

L'expert métier mérite une attention particulière. C'est lui qui détient le savoir que le système va encoder, et c'est souvent lui qui a le plus à perdre. Le faire contribuer — à la validation des réponses, au jeu d'évaluation, au vocabulaire — le transforme d'opposant potentiel en garant. C'est aussi, accessoirement, la meilleure source de cas de test qui existe.

5. La victoire à 30 jours

30-day win : un premier livrable utile et utilisé, obtenu vite.

Ce que ce n'est pas : une démonstration. Une démo tourne sur des données choisies devant un public bienveillant. Une victoire à 30 jours tourne sur les vraies données, avec de vrais utilisateurs, et elle a le droit d'échouer.

Ce qu'elle produit vraiment — et c'est la réponse attendue :

1. De la confiance, parce qu'on a livré quelque chose plutôt que promis
2. De l'information, parce que le contact avec le réel invalide toujours une hypothèse
3. Une décision, parce qu'on sait alors si le projet mérite d'être industrialisé

⚠️ Ce qu'il faut savoir dire non. Une victoire à 30 jours suppose d'exclure : pas de multi-tenant, pas de kill switch, pas d'optimisation de coût. Un candidat qui décrit une victoire à 30 jours contenant toute l'industrialisation n'a pas compris l'exercice. Il faut savoir énoncer ce qu'on ne fait pas encore et pourquoi c'est acceptable à ce stade — et le dire au client avant, pas après.

6. Quand le sponsor et l'utilisateur divergent

C'est la question de mise en situation la plus fréquente, et elle a une mauvaise réponse évidente : « je fais ce que dit le sponsor, c'est lui qui paie ».

La réponse complète, à savoir dérouler :

« D'abord, je ne tranche pas moi-même : ce n'est pas mon rôle et je n'en ai pas la légitimité. Je rends le désaccord explicite, par écrit, aux deux — souvent ils ne savaient pas qu'ils n'étaient pas d'accord.

Ensuite je cherche le fait qui tranche. Le sponsor veut un chatbot, les techniciens veulent une recherche : je vais mesurer combien de fois par jour un technicien cherche une information, et sous quelle forme il la veut quand il a les mains dans un équipement. Un fait observé déplace une discussion d'opinion.

Puis je fais arbitrer par le sponsor — mais un sponsor informé, ce qui n'est pas la même chose qu'un sponsor obéi. Et je trace la décision et son motif, parce que dans six mois quelqu'un demandera pourquoi on a fait ce choix.

Le point que je ne lâche pas : si l'utilisateur final n'adopte pas, le projet échoue, quel que soit l'avis du sponsor. Ça, c'est mon rôle de le dire. »

💡 Pourquoi cette réponse marque. Elle montre qu'on comprend une chose que beaucoup d'ingénieurs ignorent : l'adoption n'est pas une conséquence de la qualité technique. Un système excellent que personne n'utilise est un échec complet, et c'est le mode d'échec le plus fréquent des projets d'IA en entreprise.

7. Le transfert

Le succès d'un FDE se mesure à sa capacité à partir. Un système que seul le FDE sait faire tourner est un échec, même s'il fonctionne parfaitement.

Ce qu'un transfert réussi comporte :

🎯 La question de suivi. « Comment savez-vous que le transfert a réussi ? » — « Quand l'équipe cliente a modifié le système sans moi et que l'évaluation est repassée au vert. Tant que ça n'est pas arrivé au moins une fois, le transfert n'est pas fait, il est annoncé. »

8. Ce qui décide vraiment d'une mission

8.1 Un cadrage est terminé quand il produit un jeu de données

La mesure fait partie du cadrage, pas de la livraison. Un cadrage est terminé quand il a produit un jeu de cas d'évaluation issu du réel — pas quand tout le monde est d'accord sur un document.

C'est la différence structurelle avec le conseil : la sortie d'un cadrage FDE est un jeu de données, pas un document. À dire tel quel en entretien ; c'est une phrase qui situe immédiatement le métier.

8.2 La baseline avant le cas d'usage

Un sponsor demande d'automatiser un processus dont le taux de réussite manuel est déjà de 96 %.

Une baseline haute est une raison de changer de cible, pas un défi à relever. Il reste 4 % à gagner, au prix d'un système qui devra faire mieux qu'un humain compétent — et l'échec est visible tandis que le gain ne l'est pas.

Mesurer la baseline avant de choisir le cas d'usage évite de construire quelque chose d'impressionnant sans valeur mesurable.

Et le cas inverse — un processus entièrement nouveau, sans aucune baseline humaine :

On construit un plancher : une recherche par mots-clés, un moteur de règles, ou un simple appel de modèle non agentique. Sans ce plancher, « l'agent fait 82 % » est ininterprétable.

Le corollaire, sévère et juste : définir le succès après avoir vu le résultat rend le projet infalsifiable.

8.3 Le corpus trié — 94 % en pilote, 71 % en production

L'écart le plus classique, et sa cause :

Celui qui a constitué le corpus du pilote a choisi les bons documents — d'ordinaire sans s'en rendre compte. Il a pris les manuels propres, complets, bien numérisés.

Le réflexe FDE : demander tôt COMMENT le jeu pilote a été constitué. La réponse prédit l'écart de production mieux que n'importe quel benchmark. « On a pris ce qu'on avait sous la main » et « on a extrait aléatoirement de la GED » ne donnent pas le même projet.

8.4 La demande facile hors périmètre

Un client demande quelque chose hors du cas d'usage, mais facile à faire. Dire oui semble générer de la bonne volonté.

Le mode de défaillance est l'absorption : devenir la paire de bras du client et ne jamais livrer le système qui justifie le tarif.

La ligne est fonctionnelle, pas contractuelle — on ne répond pas « ce n'est pas dans le contrat », on répond en termes de trajectoire : « Je peux le faire, et ça décale d'une semaine la mise en production. On arbitre ? » Le client tranche en connaissance de cause, et l'arbitrage est tracé.

8.5 Quand le sponsor part

Le sponsor exécutif quitte l'entreprise en cours de mission. Ce qui détermine la survie :

Un chiffre publié et de vrais utilisateurs. Ce sont les deux seuls actifs qui survivent à un champion.

Un projet porté uniquement par une relation meurt avec elle. Un projet dont dix techniciens dépendent quotidiennement, et dont un chiffre a circulé en comité, se défend tout seul. C'est une raison de plus pour laquelle la victoire visible sous 30 jours est structurelle, pas cosmétique.

8.6 Capitaliser, sinon c'est du conseil

Pourquoi transformer ses apprentissages terrain en frameworks partagés plutôt que de les garder locaux ?

Sans capitalisation, le modèle est du conseil : 100 jours par client, indéfiniment. C'est l'objection historique au modèle Palantir — et sa réponse.

C'est le retour à la boucle du module F0 : le FDE rapporte au produit. Un FDE dont les apprentissages restent chez un seul client n'a pas fait la moitié de son travail.

8.7 Le savoir pour lequel un FDE est payé

Le savoir générique est le niveau dont le prix tend vers zéro. La valeur migre vers le goulot d'étranglement : implanter l'intelligence dans une organisation vivante — avec ses données réelles, ses contraintes non écrites et ses gens.

À garder pour la question « pourquoi ce métier ne disparaît-il pas avec des modèles plus capables ? »

8.8 Annoncer un risque à quelqu'un d'agacé

Compétence notée en boucle d'entretien FDE, et souvent ratée.

La première formulation s'entend comme une excuse — un défaut de votre outil, que vous invoquez pour ne pas faire ce qu'on vous demande. La seconde s'entend comme un risque dont l'interlocuteur est responsable.

Le principe : traduire une propriété technique en conséquence concrète dans son monde à lui. Ce n'est pas de la rhétorique, c'est la seule façon de transférer une décision à celui qui doit la prendre.

8.9 Les trente premiers jours, concrètement

Question fréquente, et les réponses vagues y sont éliminatoires. Le déroulé attendu :

🎯 La raison du résultat visible est politique, pas méthodologique. Ce n'est pas « pour valider techniquement » — c'est parce qu'un projet sans chiffre publié ne survit pas au départ de son sponsor (§ 8.5), ni au prochain arbitrage budgétaire. À dire ainsi : la raison est politique, et l'assumer montre qu'on comprend l'organisation.

La relance : « semaine 1, et personne ne vous accorde de temps. » — On va voir les opérationnels plutôt que les managers, on observe le travail réel plutôt que de demander des réunions, et on lit les tickets — qui disent la vérité sur les problèmes que personne ne raconte en réunion.

8.10 « Nos données sont un chaos » — et il le sait

Piège classique : le candidat saisit la perche et fait du désordre un préalable. C'est l'erreur.

Ne jamais présenter les données en désordre comme un bloqueur — ça s'entend comme une excuse préparée. Des données en désordre sont la norme, pas l'exception. Un FDE qui a besoin de données propres pour travailler n'a pas sa place chez un client.

La conduite correcte :

1. Nommer les problèmes précis qui affectent CE cas d'usage — pas le désordre en général. « 40 % des notices n'ont pas de référence équipement exploitable » est actionnable ; « vos données sont sales » ne l'est pas.
2. Chiffrer ce que chacun coûte en récupération : ce défaut-là coûte tant de points de rappel.
3. Séparer ce qu'on peut contourner de ce qu'on ne peut pas. La plupart se contourne.
4. La demande devient alors restreinte et précise, donc accordable — « il me faut la table de correspondance des références, pour ces 300 équipements » s'obtient ; « il faut nettoyer votre GED » ne s'obtient jamais.

⚠️ Le cadrage à éviter absolument : le « chantier de nettoyage commun ». Il n'aboutit pas, il n'a pas de fin définissable, et il transforme votre mission en projet de gouvernance de données dont personne ne veut porter le budget.

La relance : « débrouillez-vous, on n'a pas de bande passante. » — Réponse : d'accord, et voici ce que ça coûte en résultat. On construit sur les données telles quelles, on mesure, et le chiffre obtenu devient l'argument pour la correction ciblée. Un défaut chiffré se corrige ; un défaut déploré ne se corrige jamais.

9. Glossaire du module

Atelier (90 min)

1. Remonter d'un cran (20 min) — pour trois demandes clients formulées en solution, retrouvez le problème sous-jacent et proposez une solution différente de celle demandée.
2. Réécrire des critères (20 min) — transformez quatre souhaits flous en critères mesurables, datés, avec un responsable.
3. La question qui manque (15 min) — « qui serait mécontent si ça marchait ? » Appliquez-la à un projet que vous connaissez. Écrivez les noms.
4. La mise en situation (35 min) — l'épreuve la plus rentable du module. « The sponsor wants a chatbot, the technicians want a search box. What do you do? » Déroulez les quatre étapes en anglais, puis les relances : « et si le sponsor refuse d'entendre ? », « combien de temps y passez-vous avant de construire quand même ? »

Pour aller plus loin

• 🎯 Parcours : F7 — Déploiement entreprise ← → F9 — L'entretien FDE
• 📚 Approfondissement : M8 — Specs-as-code et PRD et M11 — ROI et adoption
• 🛠 Entraînement : thème client_discovery de la banque fransys-fde — 12 QCM. C'est le thème à travailler en premier si vous venez d'un profil technique.