Pourquoi l'IA se trompe-t-elle toujours ? Elle n'est pas bête, c'est vous qui ne l'avez pas dit clairement
Commençons par une scène que vous avez très probablement déjà vécue.
Vous demandez à l’IA de vous fabriquer quelque chose, vous attendez le résultat plein d’espoir, et ce qui sort est à des années-lumière de ce que vous aviez en tête. Vous corrigez une phrase, elle se trompe ailleurs, vous faites plusieurs allers-retours, et vous finissez agacé, avec cette phrase qui vous vient : « Cette IA, elle vaut pas mieux que ça. »
Ces derniers mois, j’utilise l’IA au travail quasiment tous les jours, et je tombe tous les jours dans ce piège. Mais à force d’y tomber, j’ai changé d’avis. Parce que j’ai découvert une régularité qui remet à sa place : le même besoin, formulé autrement, elle le réussit du premier coup.
Une fois ou deux, c’est une coïncidence ; dix fois sur douze, ça ne l’est plus. Petit à petit, j’ai dû l’admettre : quand l’IA se trompe, la plupart du temps ce n’est pas qu’elle est bête, c’est que je ne l’ai pas dit clairement.
Ce n’est pas de la magie ; derrière se cache une vérité très simple, simple au point d’en être un peu cruelle :
L’IA ne lit pas dans les pensées. Elle fait seulement ce que vous « dites », pas ce que vous « pensez ».
Le besoin qui est dans votre tête, lui, est en relief — il a un contexte, des hypothèses implicites dont vous n’avez même pas conscience, tout un jeu d’évidences du genre « mais enfin c’est clair, non ? ». Or la phrase que vous tapez dans la fenêtre de dialogue n’en garde souvent qu’une fine pellicule. L’IA ne reçoit que cette pellicule ; le reste, elle ne peut que le deviner. Si elle devine juste, c’est votre chance ; si elle devine faux, vous la trouvez encore idiote.
Une fois cette chose comprise, j’ai arrêté de me demander « quelle IA est la plus intelligente » et je me suis mis à m’exercer à quelque chose de bien plus précieux : comment transférer intégralement, dans la fenêtre de dialogue, ce besoin en relief qui est dans ma tête. Cet article, c’est toute ma méthode. Tout est copiable tel quel, il n’y a pas une seule ligne de savoir secret qui exigerait du talent.
Et je dois le dire : pour les product managers, c’est une excellente nouvelle. Décrire un besoin, c’est depuis toujours le savoir-faire du PM. Avant, vous expliquiez le besoin aux développeurs ; maintenant, vous l’expliquez à l’IA — la seule différence, c’est que le développeur comble avec son expérience ce que vous n’avez pas dit, et qu’il revient vous poser des questions ; l’IA, elle, est plus obéissante et plus « honnête », elle fait exactement ce que vous dites, ni plus ni moins. Donc, face à l’IA, vous devez dire les choses un tout petit peu plus clairement qu’à un développeur. Ce tout petit peu, c’est le seuil, et c’est aussi la ligne de partage.
Un besoin que l’IA réussit du premier coup a cinq pièces
En décortiquant les besoins que j’avais « dits clairement », j’ai découvert qu’ils réunissaient toujours cinq choses. Dès qu’il en manque une, l’IA décide à ma place sur cette pièce-là.
Pas besoin de tout écrire à chaque fois, façon dissertation en cinq points. Mais il faut avoir ces cinq cases en tête — avant d’envoyer, jetez un œil : la case qui reste vide, c’est là que l’IA fera à sa tête.
Pièce n° 1 : quoi — d’abord nommer les choses précisément
La plus basique, et aussi la plus facile à bâcler.
Vous dites « fais-moi un truc de gestion des utilisateurs » : ce « truc », c’est quoi ? Une page ? Un tableau ? Tout un back-office ? L’IA ne peut qu’en deviner un.
Reformulé : « fais une page de liste des utilisateurs, un tableau qui affiche l’avatar, le nom, l’e-mail, la date d’inscription, le statut. » — elle sait aussitôt par où commencer.
Le principe tient en une phrase : remplacez les mots vagues comme « truc », « fonctionnalité », « module » par des noms concrets. Page, tableau, bouton, formulaire, graphique, fenêtre modale. Si vous êtes capable de dire ce que c’est vraiment, l’IA peut suivre.
Pièce n° 2 : pour qui, pourquoi — le maillon le plus souvent oublié, et le plus précieux
Ce maillon-là, les gens au profil technique l’oublient justement souvent, alors que c’est précisément le terrain du PM — vous êtes fait pour vous soucier de « qui l’utilise, et pourquoi ».
Comparez. Vous dites « fais un tableau de bord et mets-y toutes sortes de données » : elle vous empile un écran de graphiques que vous ne regarderez probablement jamais.
Reformulé : « fais un tableau de bord que le responsable de magasin consulte chaque matin. Ce qui l’intéresse le plus, c’est combien on a vendu hier, si c’est en hausse ou en baisse par rapport à avant-hier, et quelle catégorie se vend le mieux ; mets ces trois-là bien en évidence, le reste au second plan. »
Vous voyez la différence ? En ajoutant « qui l’utilise + ce qui l’intéresse le plus », l’IA sait ce qu’il faut mettre en avant et ce qu’il faut estomper — elle commence à avoir un « point fort », au lieu d’étaler toutes les informations à plat.
J’en ai presque pris l’habitude désormais : après chaque besoin, j’ajoute une phrase « c’est pour qui, et quel problème veut-il résoudre ». Cette phrase-là vaut souvent plus que toute la description qui précède.
Pièce n° 3 : la forme concrète — dites « à quoi ça ressemble »
L’idée, dans votre tête, a une image ; mais vous ne lâchez qu’un mot abstrait.
« Fais une fonction de filtre » — l’IA ne sait pas sur quoi vous voulez filtrer, ni comment.
« Au-dessus du tableau, ajoute une rangée de filtres : un sélecteur de plage de dates, un menu déroulant “Statut” (Tous / Actif / Désactivé), un champ de recherche (par nom ou par e-mail) ; le filtrage est instantané, ça se rafraîchit dès qu’on choisit, sans avoir à cliquer sur “Valider”. » — là, elle peut reproduire au millimètre.
Pas besoin de savoir concevoir ; il vous suffit de décrire en langage courant l’image que vous avez en tête : quels blocs, ce qu’est chaque bloc, où on le place, comment on s’en sert. Si vous arrivez à le décrire, elle arrive à le reproduire ; si vous n’y arrivez pas, c’est que vous-même n’y avez pas encore réfléchi clairement — et tant mieux, c’est un signal, je vous expliquerai plus loin comment le retourner pour vous aider à y voir clair.
Pièce n° 4 : les limites — la ligne de partage entre « ça a l’air de tourner » et « ça marche vraiment »
Sur ce maillon, je vais m’attarder un peu, parce que c’est la vraie différence entre un débutant et un PM.
Le débutant ne décrit que le « cas normal » : l’utilisateur remplit bien sagement, les données sont toutes correctes, le réseau ne coupe jamais. Mais dans le monde réel, l’utilisateur remplit n’importe comment, les données sont parfois vides, le réseau se coupe, la saisie est parfois trop longue. On appelle ça les « cas limites », et c’est ce dont le PM doit le plus se soucier, et ce qu’il faut le plus explicitement dire à l’IA.
Vous dites « fais un formulaire de retour avec nom, e-mail, contenu, et un bouton d’envoi » : elle vous livre le chemin normal et considère que le travail est fait.
Si vous disiez plutôt :
« …attention à ces cas : si le format de l’e-mail est incorrect, affiche une alerte en rouge sous le champ et empêche l’envoi ; si le contenu du retour est vide, le bouton d’envoi reste inactif ; après un envoi réussi, vide le formulaire et affiche “Merci pour votre retour” ; en cas d’échec (par exemple réseau coupé), ne vide pas ce que l’utilisateur a déjà saisi et affiche “Échec de l’envoi, réessayez”. »
Ces quelques lignes en plus, c’est le professionnalisme du PM. L’IA est parfaitement capable de gérer tout ça, mais si vous ne le dites pas, elle ne fait par défaut que le « chemin normal ». Listez-lui les limites, et elle vous fait tout du premier coup.
Au passage, « ce qui compte comme “fini” » et « ce qu’on ne fait pas » font aussi partie des limites, et sont tout aussi importants à dire. Une phrase du genre « pour cette version, on ne fait que la liste et le filtre, pas encore l’ajout/suppression/modification » vous épargne un tas de choses dont vous ne voulez pas ce tour-ci.
Pièce n° 5 : la référence — donnez-lui un étalon
Le style, les couleurs, l’expérience — ces choses de l’ordre du « ressenti » sont les plus dures à décrire avec des mots. Le plus simple : donnez une référence.
« Rends les couleurs jolies, pro » — « joli », « pro », cent personnes en ont cent compréhensions.
« Couleur principale : le bleu de la marque #3B82F6 ; pour l’ensemble des couleurs et des blancs, inspire-toi du style épuré et sobre du site de Stripe. » — elle a un étalon, plus besoin de deviner à l’aveugle votre « joli ».
Une référence, ça peut être une valeur de couleur, un produit que vous trouvez réussi (« comme Notion »), un standard. Donnez une référence, et l’IA n’a plus à parier sur vos goûts.
Les cinq « flous » les plus courants, et comment les corriger
Ce qui précède, c’était l’analyse par le positif. Voici les cinq pièges que je vois le plus souvent, et dans lesquels je tombe le plus souvent moi-même, à passer en revue un par un.
Piège n° 1, trop vague. « Fais-moi une belle page » — elle vous livre un truc médiocre, et vous n’arrivez même pas à dire ce qui cloche. La correction : poussez d’un cran vers le concret, remplacez les adjectifs par des noms et des détails.
Piège n° 2, donner des ordres sans donner de contexte. « Ajoute une fonction d’export » — exporter quoi ? Vers où ? Dans quel format ? L’ajouter où ? La correction : complétez « où + exporter quoi + dans quel format », par exemple « en haut à droite de la page des rapports, ajoute un bouton “Exporter” ; au clic, exporte le tableau sous les filtres actuels au format CSV en téléchargement ».
Piège n° 3, tout balancer d’un coup. Vous entassez quinze besoins dans un seul message, le résultat est un fouillis, et vous ne savez même pas par où corriger. La correction : à petits pas rapides, un seul besoin à la fois. Montez d’abord le squelette, faites-le tourner pour voir le résultat, puis ajoutez-les un par un. C’est la règle la plus importante de toutes, sans exception.
Piège n° 4, pas de référence, la laisser deviner vos goûts. La correction est à la pièce n° 5 : donnez une valeur de couleur, un produit de référence, un standard.
Piège n° 5, ne dire que le normal, pas l’anormal. La démo se déroule sans accroc, mais dès que de vrais utilisateurs l’essaient, tout casse de mille façons. La correction : avant d’envoyer le besoin, posez-vous trois questions — que se passe-t-il si les données sont vides ? si l’utilisateur remplit n’importe comment ? si le réseau coupe ? Écrivez les réponses dans le besoin.
Trois gestes : faire passer l’IA de « main » à « cerveau »
Ce qui précède maîtrisé, vous dépassez déjà la plupart des gens. Les trois gestes ci-dessous, c’est ce que j’utilise pour faire passer l’IA de « une paire de mains obéissantes » à « un cerveau qui pense avec moi ».
Geste n° 1 : faites-lui d’abord vous poser des questions, sans se précipiter. C’est le geste que j’utilise le plus, et le plus contre-intuitif : plus un besoin est important, moins il faut lui demander de le faire d’emblée ; demandez-lui d’abord de vous questionner.
« J’ai une idée : faire un outil de collecte et d’analyse des retours clients. Ne te lance pas tout de suite — pose-moi d’abord les cinq questions les plus cruciales, pour cerner l’utilisateur cible, l’usage principal, les fonctions indispensables et les limites. »
Les questions qu’elle soulève, neuf fois sur dix, c’est exactement là où vous-même n’avez pas encore les idées claires. Le fait d’y répondre, c’est justement le processus qui force le besoin à passer d’« une masse floue » à « une ligne nette ». Une fois vos réponses données, elle a déjà en main un besoin complet, et ce qu’elle produit est forcément juste. Le fond de ce geste, c’est utiliser l’IA pour vous aider à voir clair, et pas seulement à produire — une fois que c’est clair, réussir vient tout seul.
Geste n° 2 : donnez un exemple positif et un contre-exemple. Quand les mots n’y suffisent pas, l’exemple est le plus rapide, surtout pour « je veux ça, pas ça ».
« Aide-moi à écrire le message qui s’affiche au clic sur ce bouton. Ça doit ressembler à ça : court, parlé, rassurant — “Enregistré, tranquille.” Pas à ça : jargon administratif, verbeux — “Votre opération a été soumise au serveur avec succès et une persistance des données a été menée à bien.” »
Un exemple positif plus un contre-exemple sont plus efficaces que trois lignes d’adjectifs.
Geste n° 3 : faites-lui reformuler pour confirmer, avant de se lancer. Quand le besoin est complexe, demandez-lui d’abord de reformuler sa compréhension ; vous confirmez que c’est bon, puis elle fait.
« Le besoin que je viens de décrire, ne le fais pas encore. Confirme-le-moi en trois phrases : ce que tu comptes faire, en combien de blocs, et s’il y a des points dont tu n’es pas sûr. Une fois que j’ai confirmé, tu commences. »
Cette étape coûte trente secondes et vous épargne une demi-heure de refonte. Pendant qu’elle reformule, vous découvrez souvent sur le moment « tiens, ici ce que j’ai dit ne correspond pas à ce que je pensais » — profitez-en, tant qu’elle n’a pas commencé, corrigez vite.
Un parcours de bout en bout : d’une phrase floue à un succès du premier coup
Mettons tout ça bout à bout, et suivons un vrai déroulé. Supposons que dans ma tête il n’y ait qu’une phrase floue : « Je veux un truc pour voir les retours des utilisateurs. »
Première étape, je ne me précipite pas pour lui demander de faire, je lui demande d’abord de m’aider à voir clair (geste n° 1) : je lui fais poser cinq questions cruciales. Elle va demander : qui l’utilise (un collègue des opérations) ? D’où viennent les retours (un fichier CSV) ? Qu’est-ce qu’on veut le plus en tirer (savoir vite de quoi les gens se plaignent le plus) ? Faut-il trier par gravité (oui) ? Faut-il un filtre pour cette version (pas pour l’instant) ?
Deuxième étape, je rassemble les réponses en un besoin complet, et les cinq pièces sont pile réunies : pour les opérations, dans le but de voir vite de quoi les utilisateurs se plaignent le plus (pour qui, pourquoi) ; en haut, une zone d’upload pour envoyer le CSV, en dessous s’affichent automatiquement les retours regroupés par thème, combien de retours par catégorie, quel pourcentage, triés par nombre (quoi, forme) ; si le CSV est vide ou mal formaté, afficher « Échec de lecture, vérifiez le format », et pour cette version pas encore de filtre ni de recherche (limites) ; épuré et sobre, couleur principale #3B82F6, en s’inspirant de la mise en page de Notion (référence). Monte d’abord ça avec de fausses données, et lance un service local pour que je prévisualise.
Troisième étape, une fois que ça tourne et que je vois le résultat, j’ajoute à petits pas (la correction du piège n° 3) : un à la fois — « après chaque thème, ajoute une barre de progression qui montre le pourcentage », « au clic sur un thème, déplie les trois retours bruts de cette catégorie », « colore les thèmes selon la gravité : rouge pour la fréquence élevée, jaune pour moyenne, gris pour basse ».
Quatrième étape, je lui fais trouver elle-même les problèmes : « clique partout où c’est cliquable, repère les erreurs, les blocages, ce qui ne correspond pas aux attentes, et dresse une liste. »
Pendant tout le parcours, je n’ai pas écrit une ligne de code, mais chaque étape a été dite très clairement. C’est ça, le quotidien aujourd’hui — vous vous chargez de voir clair et de dire clair, elle se charge de produire.
Pour finir
Avant d’appuyer sur Entrée, je passe généralement dix secondes à repasser mentalement ces cases : quoi (est-ce un nom concret ?), pour qui et pourquoi, à quoi ça ressemble, les limites (données vides, saisie n’importe comment, échec, ce qu’on ne fait pas — tout est dit ?), la référence, et — cette fois, n’ai-je proposé qu’un seul besoin ? Sur ces six, si quatre ou cinq passent, elle réussit en gros du premier coup.
Les gens qui savent utiliser l’IA sont de plus en plus nombreux, mais ceux qui savent dire clairement un besoin restent depuis toujours une minorité. La première chose est un seuil, tout le monde peut le franchir ; la seconde est une ligne de partage, elle sépare les gens en deux camps.
Et vous, en tant que product manager, vous êtes depuis toujours celui qui comprend le mieux l’utilisateur, le mieux ce qui compte, le mieux ces limites dont personne ne se soucie à votre place. Ce qui vous manque n’a jamais été tout ça, c’est l’habitude de le dire à voix haute. Entraînez-vous un mois, et vous découvrirez que ce n’est pas l’IA qui est devenue plus intelligente, c’est vous qui avez enfin appris à transmettre intégralement, ce besoin qui est dans votre tête.
Discussion