Une journée de product manager à l'ère de l'IA : comment j'ai transformé une phrase en prototype cliquable

Commençons par un fait concret. Mercredi dernier, en début d’après-midi, une idée floue m’a traversé l’esprit : « j’aimerais un petit truc pour noter mes dépenses au fil de l’eau. » Un peu plus de deux heures plus tard, mon collègue cliquait pour de vrai sur mon téléphone — il appuyait sur « ajouter une dépense », saisissait un montant, choisissait une catégorie, et de retour sur l’écran d’accueil il voyait combien il avait dépensé ce mois-ci, avec un camembert découpé en plusieurs parts. Sans écrire une seule ligne de code.

Si je raconte ça, ce n’est pas pour dire à quel point l’IA est bluffante. C’est pour pointer une chose contre-intuitive : beaucoup s’imaginent qu’avec l’arrivée de l’IA, un product manager doit vite se mettre à programmer pour ne pas être remplacé. Or, ce que je ressens depuis six mois, c’est exactement l’inverse — la barrière pour écrire du code s’effondre à toute vitesse, et ce qui devient vraiment précieux, et rare, c’est tout autre chose : savoir formuler une idée assez clairement pour que l’IA la fasse juste du premier coup.

Dans cet article, je ne vais pas défendre cette idée en soi, je vais raconter comment je m’y prends concrètement. Je prends comme exemple ce petit outil de suivi des dépenses et je le décortique étape par étape, y compris les pièges dans lesquels je suis tombé. Si vous aussi vous avez une idée que vous ruminez depuis longtemps sans jamais l’avoir lancée, vous devriez pouvoir tenter le coup vous-même après lecture.

Première étape : ne pas se précipiter à lui demander de faire, mais le laisser me questionner d’abord

Quand j’ai commencé à fabriquer des choses avec l’IA, l’erreur que je faisais le plus souvent, c’était de lui balancer telle quelle la phrase floue que j’avais en tête — « fais-moi une appli de suivi des dépenses » — puis d’attendre qu’elle me sorte un produit fini.

Le résultat était toujours le même : elle me livrait ce qu’elle croyait que je voulais, à des kilomètres de ce que j’avais dans la tête. Je corrigeais un peu, elle dérapait un peu, et on passait notre temps à se deviner l’un l’autre, jusqu’à ce que ça me mette hors de moi.

Puis j’ai changé une habitude — c’est l’affaire d’une phrase, mais l’effet est démesuré : je ne lui demande plus de faire directement, je la laisse d’abord me questionner. Je dis quelque chose comme : « je veux faire un petit outil de suivi des dépenses, mais n’écris rien pour l’instant. Commence par me poser 5 questions, pour éclaircir tout ce que tu as besoin de savoir mais que je n’ai pas encore précisé. »

Alors elle demande : pour qui, juste toi ou plusieurs personnes ? Faut-il des catégories, et tu les définis toi-même ou je t’en pré-remplis quelques-unes ? Les montants distinguent-ils recettes et dépenses ? Les données restent-elles stockées en local sur le téléphone, ou faut-il pouvoir les consulter depuis un autre appareil ? Faut-il des alertes de budget ?

Vous voyez, ces questions portent toutes exactement sur les zones qui, dans ma tête, étaient une bouillie confuse, des choses que je n’avais pas tranchées. C’est elle qui, à ma place, a fait remonter le « qu’est-ce que je veux au juste ». Une fois ces 5 questions répondues, la forme de la chose devient d’abord claire dans ma propre tête. Et à ce moment-là, quand je la laisse se mettre au travail, la probabilité que ça marche du premier coup grimpe énormément.

Le piège dans lequel je suis tombé : les deux minutes gagnées en sautant cette étape, vous les rembourserez plus tard en deux heures. Une fois, agacé par ses questions, je lui ai dit de foncer ; elle a produit un truc complet en fonctionnalités mais qui n’était absolument pas ce que je voulais, et le temps de tout retravailler, il aurait mieux valu tout recommencer. Aujourd’hui, cette étape, je ne la saute jamais.

Deuxième étape : ne modifier qu’une seule chose à la fois

La première version sort, ça se clique, mais forcément quelque chose cloche. Et là un deuxième piège vous attend : lui déballer d’un coup les dix choses qui vous déplaisent.

« La couleur de l’accueil est trop pâle, les icônes des catégories sont moches, je veux changer les couleurs du camembert, le bouton pour ajouter une dépense est trop petit, et au fait est-ce que le montant peut afficher automatiquement les décimales, ah oui et tant qu’à faire ajoute une recherche… »

Avant, je faisais exactement ça, pour aller vite. Résultat : elle corrige, la couleur est bonne, mais elle a oublié l’histoire du bouton ; ou alors le bouton est réglé, mais le camembert est de nouveau cassé. Dès qu’il y a beaucoup de changements, elle en néglige certains, et vous-même n’arrivez plus à démêler quelle phrase a produit quel effet, ni laquelle elle a discrètement laissée de côté.

Maintenant je ne formule qu’un seul changement à la fois, et une fois dit, je clique sur le téléphone pour vérifier que ce point-là est bon, avant de passer au suivant. Lent ? Ça en a l’air. Mais chaque pas est solide, sans retour en arrière. J’ai calculé qu’en procédant ainsi, on arrive au bout bien plus vite qu’en « tout disant d’un coup puis en retravaillant tout ensemble », et surtout je sais à chaque instant où j’en suis.

Ce n’est pas une astuce d’IA, c’est la règle la plus élémentaire de la fabrication d’un produit : de petits pas, chacun vérifiable. Sauf que l’IA écrase à ce point le coût de chaque pas qu’il n’y a plus aucune raison de vouloir en avaler trop d’un coup.

Une parenthèse : comment formuler chaque changement pour que l’IA le comprenne

J’ai dit « ne modifier qu’une chose à la fois », mais « une seule » ne suffit pas — l’essentiel, c’est comment vous formulez cette seule chose. C’est, dans tout cet article, le point que je trouve le plus concret et le plus immédiatement efficace.

Le plus gros piège dans lequel je suis tombé, c’est d’avoir donné mes instructions à l’IA avec des adjectifs. « Rends l’accueil plus joli », « rends le bouton plus élégant », « rends la couleur plus classe » — dès que je prononce ces phrases, je lui rends tout le pouvoir de décision, parce que « joli » ou « classe », chez elle, ça a dix mille interprétations, elle en pioche une au hasard, et ce n’est le plus souvent pas celle que vous vouliez.

Ensuite je me suis forcé à changer sur deux points : donner un point de référence, donner un état, pas d’adjectifs.

Donner un point de référence, c’est ne pas dire « rends ça plus joli », mais dire « les cartes de l’accueil, pour les marges, inspire-toi de WeChat Read : trois ou quatre éléments par écran, pas serrés ». Elle sait aussitôt ce que vous voulez — parce que vous lui avez donné une chose concrète sur laquelle s’aligner, et non une appréciation floue qu’elle interprète à sa guise.

Donner un état, c’est ne pas dire « gère le cas où il n’y a pas de dépense », mais dire « quand il n’y a aucune dépense, l’accueil affiche au centre une ligne en gris : “Aucune dépense pour l’instant, appuyez sur + en bas à droite pour en ajouter une”, et n’affiche pas un camembert vide ». Dites à quoi l’écran doit ressembler précisément dans chaque état — avec des données, sans données, en cours de chargement, en erreur. Plus vous êtes précis, moins elle a de marge pour « improviser » une version que vous ne vouliez pas.

Ma vérification, aujourd’hui, c’est : une fois l’instruction formulée, je la relis pour voir s’il y a des adjectifs dedans. S’il y a des mots comme « joli, élégant, classe, optimise-moi ça », je m’arrête et je les traduis en « inspire-toi de quoi, à quoi ça ressemble précisément ». Ce petit geste m’est plus utile que n’importe quelle astuce d’IA que j’aie apprise.

Troisième étape : mettre de vraies données dès la première version, pas du « texte d’exemple »

C’est, à mon avis, le point le plus facile à négliger, et pourtant celui qui pèse le plus sur le résultat.

Beaucoup, en faisant un prototype, ont l’habitude de laisser d’abord l’IA monter une « ossature » — avec dedans « Titre 1 », « contenu factice », « 000,00 € » et autres faux-semblants, en se disant « la structure est bonne, on remplira le contenu plus tard ».

Je ne fais plus comme ça. Dès la première version, je lui fais mettre de vraies données. Pour cet exemple de suivi des dépenses, je lui ai directement fait pré-remplir quelques dépenses réelles de la veille : petit-déjeuner 12, taxi 28, courses 63, et une dépense qui faisait vraiment mal, les 2000 de l’inscription de mon enfant à une activité.

Pourquoi ? Parce que les fausses données vous trompent. Quand tout est à « 000,00 € », l’interface a l’air nette et bien rangée, et vous vous dites « c’est très bien ». Mais dès qu’on y met un chiffre réel comme « 2000 », un montant aux nombres de chiffres irréguliers, tous les problèmes surgissent d’un coup : dès que le montant s’allonge, il vient buter contre le bord droit de l’écran ; le camembert, écrasé par cette part de 2000, réduit les autres dépenses à des tranches quasi invisibles ; et un nom de catégorie un peu long suffit à déformer toute la mise en page.

Ces pièges, avec de fausses données vous n’en voyez aucun, et une fois en ligne ils s’écrasent tous sur le visage de vrais utilisateurs. Avec de vraies données, ils se révèlent dès la première version, entre vos mains, et plus ils se révèlent tôt, moins ils coûtent cher à corriger — à ce stade c’est l’affaire d’une ligne à changer ; attendre que les utilisateurs vous engueulent après le lancement, c’est une tout autre histoire. Mon habitude aujourd’hui : dès qu’un vrai chiffre est disponible, je refuse le texte factice — le plus réel, le plus extrême possible : le nom le plus long, le montant le plus grand, l’état le plus vide (à quoi ressemble l’interface quand il n’y a pas la moindre dépense ?), tout ça doit se voir dès la première version.

Quatrième étape : toujours cliquer soi-même sur un vrai appareil

Une fois le prototype fait, l’IA vous annonce en général avec beaucoup d’assurance « c’est terminé, toutes les fonctionnalités sont implémentées ».

Cette phrase, n’en croyez pas un mot. Ce n’est pas qu’elle mente, c’est qu’elle n’a pas de mains, elle ne peut pas vraiment cliquer.

J’en ai fait les frais. Une fois, elle m’a juré que l’ajout, la suppression et les statistiques étaient tous en place, et comme je ne trouvais aucune faille dans la logique du code non plus, je l’ai crue. Résultat, mon collègue prend l’appli, ajoute une dépense, très bien ; puis appuie sur cette dépense pour la supprimer — aucune réaction. Le bouton de suppression, elle l’avait dessiné, mais l’action « et une fois qu’on appuie, ça supprime vraiment », elle l’avait oubliée, sans même le savoir elle-même, tout en me disant « c’est terminé ».

Depuis, je me suis fixé une règle d’airain : tout « c’est terminé » ne compte que si je parcours moi-même, de mes propres mains, le chemin clé sur un vrai appareil. Ajouter une dépense, la voir apparaître dans la liste, la supprimer, voir les statistiques changer en conséquence — tant que je n’ai pas parcouru cette chaîne de mes propres mains, je considère que ce n’est pas fini. Cette étape ne prend pas trois minutes, mais c’est le seul mur qui vous sépare du « découvert par les utilisateurs après le lancement ».

Pour la parcourir concrètement, j’ai aussi une méthode bête : avant de me lancer, j’écris d’abord sur une feuille les deux ou trois chemins les plus critiques de la chose. Pour le suivi des dépenses, j’avais écrit — « ① pouvoir ajouter une dépense et la voir ② pouvoir supprimer une dépense ③ le chiffre de l’accueil et le camembert changent en conséquence ». Juste ces trois-là. Une fois fini, je ne regarde pas ce que dit l’IA : je prends cette feuille et je clique sur le téléphone, un point après l’autre. Chaque chemin qui passe, je le barre ; ce que je n’arrive pas à barrer, c’est que ce n’est pas fini.

Ne sous-estimez pas cette feuille. Elle vous force, avant même de vous lancer, à clarifier « sur quelles quelques choses cette chose tient-elle au juste » — beaucoup se perdent à mi-chemin justement parce qu’ils n’ont jamais posé sur le papier ces deux ou trois chemins principaux ; ils avancent en se laissant emporter par mille détails, et se retrouvent au bout avec un tas de fonctionnalités mais le chemin le plus central qui, lui, ne passe pas. Clarifier d’abord quels chemins doivent absolument passer, puis laisser l’IA faire, et enfin vérifier ces chemins de ses propres mains — ces deux feuilles, au début et à la fin, comptent plus que tout le code qu’elle a pu écrire entre les deux.

Cinquième étape : le critère de recette, c’est « est-ce que ça se clique de bout en bout », pas « est-ce que ça a l’air correct »

Si l’on relie toutes ces étapes, c’est en réalité le même jugement qui revient sans cesse : avec quoi, au fond, est-ce que je décide si cette chose tient la route ?

La réponse que je me suis donnée : est-ce qu’on peut vraiment parcourir en cliquant un chemin complet, plutôt que de savoir si ça a l’air correct.

« Ça a l’air correct » est ce qui trompe le plus facilement. On envoie une capture d’écran dans le groupe, tout le monde trouve ça joli, alors que peut-être pas une seule personne n’y a réellement saisi une dépense. Tandis que « ça se clique » est solide — une vraie personne, de l’ouverture à la saisie d’une dépense jusqu’à la vue du résultat, sans jamais rester bloquée, sans un seul bouton mort : si ce chemin passe, alors seulement la chose tient vraiment debout.

C’est aussi ce qu’un product manager, à l’ère de l’IA, devrait selon moi défendre le plus. Quand le coût de fabriquer une chose est ramené à presque zéro, “produire un truc qui a l’air présentable” ne vaut plus rien, il y en a plein l’écran. Ce qui a de la valeur, c’est que vous soyez encore capable de juger : ce truc qui a l’air présentable, est-il vraiment utilisable, ou a-t-il juste l’air de l’être. Ce jugement, l’IA ne peut pas le faire à votre place, car c’est elle-même le genre à annoncer avec assurance « c’est terminé » en ayant oublié le bouton de suppression.

Alors, faut-il oui ou non apprendre à coder

Revenons à la question du début.

Ma réponse : vous n’avez pas besoin d’apprendre à écrire du code, mais vous devez apprendre à formuler une chose assez clairement pour que l’IA la fasse juste du premier coup — ce sont deux choses différentes. La première, c’est apprendre un métier en train de se déprécier ; la seconde, c’est exercer un discernement de plus en plus rare : forcer une idée floue à devenir claire, n’avancer que d’un pas à la fois, vérifier avec du réel, cliquer soi-même de bout en bout avant d’y croire.

Ces quelques principes, à vrai dire, aucun n’est « technique ». Ils ressemblent plutôt aux habitudes qu’une personne qui sait clairement ce qu’elle veut, et qui accepte de vérifier pas à pas, devrait de toute façon avoir. L’IA ne fait que démultiplier, plusieurs fois, la récompense de ces habitudes — plus vous pensez clairement, plus ce qu’elle vous rend est juste ; plus vous bâclez, plus elle bâcle avec vous.

Aujourd’hui encore, il me reste des choses que je n’ai pas élucidées, alors je vous les passe au passage : quand « transformer une idée en une chose cliquable » va assez vite pour faire plusieurs allers-retours en un après-midi, où trace-t-on encore la ligne entre le product manager et « une personne ordinaire qui sait clairement ce qu’elle veut » ? Moi aussi je cherche la réponse. Mais au moins je sais une chose : cette ligne ne passe pas par « savoir ou non écrire du code » — ce petit outil de suivi des dépenses de la semaine dernière, du début à la fin je n’ai pas touché une seule ligne de code.