Devenir PM à l'ère de l'IA 05 | Restez vague et l'IA comblera les trous à votre place

Vous dites à l’IA « fais-moi une fonctionnalité de connexion ».

Elle vous la sort. Mais entre cette phrase et ce bout de code, elle a pris à votre place une cascade de décisions que vous n’avez jamais évoquées : e-mail ou numéro de téléphone, code de vérification ou non, blocage du compte après combien de mauvais mots de passe, blocage pour combien de temps, message d’erreur « mot de passe incorrect » ou « identifiant ou mot de passe incorrect », case « se souvenir de moi » ou pas, durée de la session. Cette douzaine de décisions, aucune n’est de vous — elle les a toutes devinées.

Le problème n’est pas qu’elle devine juste ou faux, c’est qu’elle ne vous pose tout simplement pas la question. Confiez ce travail à un humain : il vous renverra « notre connexion, c’est par numéro ou par e-mail ? ». L’IA, non. C’est une yes-machine : elle fait ce que vous dites, pas ce que vous voulez. Partout où le besoin reste muet, elle remplit avec le défaut qu’elle a le plus vu à l’entraînement — règles de validation, logique d’expiration, gestion des erreurs, elle vous en colle un partout, et ce n’est presque jamais le vôtre.

Sean Grove, d’OpenAI, a eu cette phrase : le code que vous écrivez ne pèse que 10 à 20 % de votre valeur, les 80 à 90 % restants, c’est de formuler clairement ce qu’il faut faire. Quand l’IA prend en charge tout le « l’écrire », il ne vous reste que ces 80 % d’amont — dire le besoin jusqu’à ce qu’il n’ait plus aucune ambiguïté. Voici quatre gestes à reproduire.

1. Remplacez les adjectifs par des chiffres

« Plus rapide », « plus simple », « plus visible », « bonne expérience » — ces mots, l’IA ne peut pas les vérifier, elle ne peut que s’en inventer une définition. Quelqu’un a écrit à une IA « le système doit réagir vite à une surcharge » ; l’IA a aussitôt classé cette ligne comme « non vérifiable » : sans seuil mesurable, « vite », c’est vite comment ?

Remplacez l’adjectif par un chiffre et l’ambiguïté disparaît. « Le chargement doit être rapide » devient « le premier écran s’affiche en moins de 1,5 seconde » ; « la liste ne doit pas être trop longue » devient « 8 éléments maximum par écran, pagination au-delà » ; « bouton visible » devient « bouton en couleur principale, contraste suffisant avec le fond pour être bien lisible ». Tout ce qui peut s’écrire en chiffre ou en règle, ne le laissez pas en adjectif.

2. Écrivez tous les états

doaipm insiste depuis le début sur les quatre vrais états : en chargement, vide, en erreur, en succès. Vous dites seulement « fais-moi une liste de commandes » : l’IA vous la fait par défaut en état de succès — il y a des données, le réseau marche, tout va bien.

Liste de commandes : pendant le chargement, afficher un squelette ; quand il n’y a aucune commande, afficher « Pas encore de commande » avec un accès pour passer commande ; en cas d’échec de la requête, afficher « Échec du chargement, cliquez pour réessayer » ; en temps normal, afficher pour chaque ligne le numéro, le montant et le statut.

À quoi ressemble une liste vide, ce qu’on montre à l’utilisateur pendant le chargement, comment signaler un échec — ces trois cas, si vous ne les écrivez pas, l’IA soit ne les fait pas, soit vous en bricole un au hasard. Dans un vrai produit, la probabilité que l’utilisateur tombe sur le vide ou l’erreur est bien plus élevée que vous ne le pensez.

3. Listez les cas limites

Ce qu’on saute le plus facilement, et ce qui fait le plus de dégâts, ce sont les chemins d’exception. En étudiant les hypothèses que l’IA invente face à un besoin flou, on constate que c’est précisément là qu’elle en invente le plus : que faire quand les données ont expiré, quand une personne sans droits y accède, quand deux personnes manipulent la même entrée en même temps, quand ça part en timeout.

Vous faites un coupon de réduction ? Il faut alors clarifier tout ça : le coupon a expiré, l’utilisateur clique « utiliser », qu’affiche-t-on ; le même coupon est passé en commande simultanément sur deux appareils, à qui revient-il ; l’utilisateur a utilisé la moitié du coupon puis se fait rembourser, le coupon est-il rendu ou non. Si vous ne les listez pas, l’IA s’invente une hypothèse pour chacun, et vous ne découvrez comment elle a deviné qu’au moment où le problème éclate en production.

4. Une fois écrit, relisez-vous avec un test « contexte zéro »

Pour juger si un besoin est assez clair, il existe une règle toute prête : confiez-le à quelqu’un qui ne connaît absolument rien au projet — saura-t-il en faire exactement la même chose que celle que vous avez en tête ? Si deux personnes le lisent et le comprennent de deux façons, c’est qu’il n’est pas encore assez clair ; continuez à le décomposer, jusqu’à ce qu’il n’y ait plus d’ambiguïté.

Si ça vous semble fastidieux, il y a plus économique encore : demandez à l’IA de ne rien faire pour l’instant et de vous lister une à une les hypothèses qu’elle compte combler à votre place. Ce qu’elle énonce — « je pars du principe que le coupon est valable partout », « je suppose une validité de 7 jours » — ce sont exactement les points que vous n’avez pas dits clairement. Tant qu’elle n’a rien fait, bouchez ces trous.

Une chose à faire dès aujourd’hui : prenez un besoin que vous êtes sur le point de balancer à l’IA, ne l’envoyez pas tout de suite, passez-le au crible de « adjectifs en chiffres, tous les états écrits, cas limites listés », puis envoyez-le. Comparez ensuite : quel écart entre cette version-là et celle que vous auriez envoyée à la volée.

Pour aller plus loin

• Sean Grove (OpenAI), « The New Code » : la spec, c’est là que se trouvent 80 à 90 % de votre valeur — https://www.youtube.com/watch?v=8rABwKRsec4
• Improve & Repeat, « Why Requirements Matter So Much for AI Coding Agents » (la liste des hypothèses que l’IA invente face à un besoin flou) : https://improveandrepeat.com/2026/04/why-requirements-matter-so-much-for-ai-coding-agents/
• Le troisième article de cette série, « Traiter l’IA comme un collègue, pas comme un outil » : /fr/blog/ai-as-colleague/
• Le quatrième article de cette série, « Juger “faut-il le faire” coûte désormais plus cher que “peut-on le faire” » : /fr/blog/judgment-over-feasibility/