Prototyper avec l’IA avant d’écrire le cahier des charges

Dans mon métier, déplacer un bouton de droite à gauche coûte trois semaines. L’utilisateur le demande, la maîtrise d’ouvrage reformule, la demande devient une ligne dans une file de tickets ou un avenant au contrat, la maîtrise d’œuvre la requalifie, un développeur la reprend, et si l’on est sérieux, on la revérifie en recette¹, à condition que quelqu’un l’ait priorisée entre-temps. Puis la boucle repart souvent une seconde fois, parce qu’au bout du compte le bouton était mieux à droite.

Je suis chef de projet côté maîtrise d’ouvrage, pas développeur, sur des projets qui consistent à rendre lisibles par des non-experts des données hétérogènes venues de domaines très pointus. Discrétion oblige, je n’en dirai pas plus, mais je peux vous raconter ce que j’y fais depuis que l’intelligence artificielle sait écrire un écran. Le bouton se déplace désormais en 30 secondes, parce que les deux personnes qui décident sont dans la même pièce et que l’écran bouge devant elles. Le temps gagné compte pourtant moins que le reste. Une remarque à trois semaines, le métier, c’est-à-dire les gens qui se serviront de l’outil, la garde pour lui. La même remarque à 30 secondes, il la fait.

Le faux oui du cahier des charges

Rappelez-vous la dernière fois que vous avez acheté une voiture. Vous avez lu la fiche technique, puis vous avez demandé un essai, parce que personne ne signe pour une voiture qu’il n’a pas conduite. Dans mon métier, la fiche technique s’appelle un cahier des charges, ou PRD² chez ceux qui font du produit plutôt que du projet, elle fait cent pages relues avec soin, du moins par ceux qui les ont lues, et l’essai sur route n’existe pas. On demande au métier de signer quand même, parce qu’à l’époque où cette façon de faire s’est installée, l’essai coûtait trop cher pour lui être proposé. C’est cette époque-là qui se termine.

Le cahier des charges échoue de deux manières, et aucune des deux n’est une faute de rédaction. Prenez la ligne la plus ordinaire qui soit, « un bouton de validation », et donnez-la à quatre personnes. Aucune n’a tort, chacune l’a lue honnêtement, et le document reste ambigu, parce que « valider », chez chacune, désigne son propre processus. L’écart se découvre quand quelqu’un construit, c’est-à-dire trop tard. La seconde manière est plus vicieuse. Mettez un utilisateur devant une image fixe, avec une pile de dossiers qui l’attend, et il dira « ouais, ça me va » pour y retourner. J’appelle ça le faux oui. Il ressemble à un accord et il se paie en recette, ou pire, en production.

Le prix du faux oui a été mesuré. Pendo, un éditeur qui observe l’usage réel des logiciels, a passé au crible 615 produits en 2019 et conclu que 80 % de leurs fonctionnalités ne servaient jamais ou presque³. Ce ne sont pas des fonctions ratées, ce sont des fonctions que personne n’a osé refuser.

Une maquette se regarde, un démonstrateur se manipule

En réunion, on appelle tout « la maquette », et c’est pour ça qu’on se comprend mal. Trois objets se cachent derrière ce mot, séparés par l’usage qu’on en fait. La maquette se regarde. L’application s’exploite, avec de vraies données et de vraies contraintes, et c’est le travail de la maîtrise d’œuvre. Entre les deux, le démonstrateur, un prototype cliquable, se manipule. C’est le seul des trois où le métier a le clavier avant qu’on ait construit quoi que ce soit.

Un démonstrateur, chez moi, c’est un dossier de fichiers qui s’ouvre dans un navigateur, sans rien à installer au-delà de l’éditeur de texte, sans base de données et hors du réseau interne, ce qui interdit de fait d’y faire entrer la moindre donnée réelle. Les données sont fausses mais plausibles, « restaurant le 12 mars à Bordeaux, 47 euros » plutôt que « note 1, X euros », le parcours va de bout en bout et tout fonctionne pour de vrai. Il ne partira jamais en production et personne ne reprendra son code tel quel. Il accompagne en revanche le cahier des charges jusqu’à la maîtrise d’œuvre, qui s’en sert pour voir sans ambiguïté ce que le document décrit. On ne fabrique pas un produit, on fabrique une conversation.

L’intelligence artificielle n’intervient qu’ici, de la façon la plus terre à terre qui soit. La presse appelle ça le vibe coding⁴ et le raconte comme une affaire de développeurs ou de fondateurs solitaires. Mon cas est plus banal, et personne n’en fera un documentaire. Un agent⁵, le même modèle que votre assistant en ligne mais installé dans un dossier de mon ordinateur, écrit l’écran que je lui décris, me demande l’autorisation avant d’agir, et un mot suffit à l’arrêter. Je décris ce que je veux, je regarde ce qui s’affiche et je juge sur ce que je vois. Mon métier n’est pas de coder et je ne relis le code que rarement. En clair, je fais mon métier de chef de projet, avec un outil qui fabrique enfin ce que je ne savais que décrire.

L’atelier, quatre personnes et une souris

L’atelier décide de tout, et c’est la partie qu’on prépare le moins. Un démonstrateur qu’on présente est une visite guidée, où le métier admire, félicite, et laisse le chef de projet repartir avec un bel écran et zéro arbitrage. Un démonstrateur qu’on fait manipuler se prépare.

Quatre personnes côté métier, pas davantage, parce qu’au-delà les plus discrets se taisent, et ce sont souvent eux qui connaissent le cas particulier. Trois à cinq questions à faire trancher, préparées d’avance, les participants ajoutant les leurs. Une capture d’écran de secours dans un coin, parce que l’effet démo ne pardonne pas et que je suis chat noir. Puis la mise en situation, « tu dois traiter cette demande, vas-y », à partir de laquelle c’est le métier qui manipule et moi qui observe. C’est le plus dur des gestes, parce que le réflexe du chef de projet est de reprendre la souris dès que quelqu’un hésite. Il ne faut pas. L’hésitation, c’est l’information. Et la question « et si je clique là » est l’exact contraire du faux oui, parce que devant un écran qui réagit, le métier essaie, et c’est son propre travail qu’il rejoue.

Pendant qu’ils parlent, un journal d’arbitrages reste ouvert et visible sur l’écran voisin, avec chaque décision et son motif, et c’est étonnant ce que les gens corrigent quand ils voient ce qu’on écrit d’eux. Ce journal est le seul livrable de la journée. Les exclusions y valent autant que les ajouts, et elles ne remontent qu’en atelier, comme cette fonction d’export que tout le monde aurait trouvée pratique sur le papier et dont plus personne ne veut dès qu’elle s’affiche, parce qu’on comprend soudain à qui elle partirait. Il faut voir l’écran pour comprendre qu’on ne veut pas l’envoyer.

Ce que le métier y gagne, je le vois à chaque séance. Les gens sont contents de prendre le clavier et d’essayer des choses au lieu de subir une réunion de recueil des besoins, et ça leur donne envie de s’engager. Les réunions interminables où l’on remue des idées sans rien produire ont disparu de mon agenda, et je ne les regrette pas. Dans le circuit habituel, je recevais un besoin d’un côté, je le reformulais, je le transmettais de l’autre et je recommençais en sens inverse avec la réponse. Je faisais le passe-plat, et je ne suis pas certain d’avoir choisi ce métier pour ça. Là, je vois le besoin se former devant moi et je tranche sur place. C’est probablement ce qui a le plus changé dans ma façon de travailler.

Ce que le développeur reçoit

Le cahier des charges reste dû, entier, et il est même plus riche. Ses exigences fonctionnelles, ce que l’outil doit faire, ne s’inventent plus, elles se constatent, écran par écran, et l’on y écrit les exclusions avec leur motif, seule chose qui empêche une fonctionnalité de revenir six mois plus tard par la porte de derrière, portée par quelqu’un qui n’était pas à l’atelier. L’agent en rédige le brouillon en quelques minutes à partir du journal, et il laisse toute la section non fonctionnelle, tout ce qui ne se voit pas à l’écran, la sécurité, les sauvegardes, la tenue à la charge, en « à compléter par la maîtrise d’ouvrage », et c’est exactement ce qu’on veut. Aucun métier ne demande spontanément un plan de reprise après panne, et l’outil sait ce qu’il ne sait pas.

Côté maîtrise d’œuvre, l’adhésion a été la bonne surprise. Aujourd’hui, un développeur reçoit cent pages qu’il interprète seul, plus ce qui s’est dit en réunion et que personne n’a noté. Avec un démonstrateur, il reçoit les mêmes cent pages et un écran qu’il ouvre et qu’il clique. Quand il doute, il n’organise pas une réunion, il clique. Les développeurs y voient un projet déjà validé par le métier, donc bien moins d’allers-retours coûteux pour des arbitrages, et bien moins de risque de construire quelque chose dont le métier dira à la fin que ce n’est pas adapté. Les livraisons s’en ressentent, et les retours négatifs des utilisateurs finaux sont devenus rares.

L’objection la plus solide vient de ce côté-là, et elle est juste. Un écran fabriqué en HTML en un après-midi induit des choix d’interaction qui ne coûtent rien là et qui peuvent coûter cher dans les langages et les logiciels sur lesquels le produit final sera vraiment bâti. C’est pour ça que le démonstrateur donne une cible à viser, jamais un contrat de réalisation, et que j’associe un regard de la maîtrise d’œuvre dès l’atelier, pas seulement à la livraison.

Une demi-journée avec l’IA, à condition de savoir se retenir

Mon dernier démonstrateur, un petit outil qui mesure le temps de parole de chacun en réunion, a tenu en cinq prompts et une demi-journée, atelier et journal compris, et ces deux-là ont pris plus de temps que la génération. Si je m’arrêtais là, quiconque voudrait essayer raterait ses trois premiers démonstrateurs exactement comme j’ai raté les miens, parce qu’entre le démonstrateur qui fait parler une salle et le joli brouillon qu’on jette au bout d’une heure, la différence tient à quelques tours de main qui ne s’inventent pas.

Le premier s’écrit une fois pour toutes, dans le fichier que l’agent relit à chaque session⁶. Le socle technique, ce que ce projet est et ne sera jamais, et des garde-fous formulés en refus. « N’utilise pas de framework », ces grosses boîtes à outils de développeurs dont un démonstrateur n’a pas besoin, est un vœu. « Si je demande React, l’une d’elles, refuse et rappelle-moi la contrainte » est une consigne qui agit, et qui tient encore à 19 heures la veille d’un atelier, quand c’est moi qui ai oublié ma propre contrainte. Même chose pour le prénom d’un collègue glissé par habitude, remplacé d’office par un prénom fictif, et pour la sauvegarde qu’il ajouterait de lui-même, avec un joli message de confirmation, alors qu’on ne voulait surtout rien enregistrer. Ce que je ne dis pas, il l’invente, et il l’invente bien.

Le deuxième, c’est de demander les états. Une fonctionnalité fait quatre écrans, la liste vide, le chargement, l’erreur et le cas heureux, celui où tout se passe bien, et une maquette ne montre jamais que le dernier. Le métier ne parle pas devant le cas heureux, il approuve. Il parle devant la liste vide, en se demandant qui la remplit avant lui, et devant le message d’erreur, en se souvenant du cas particulier de son service.

Le troisième, c’est un changement à la fois. On demande un bouton, on reçoit le bouton, et l’agent a renommé, réorganisé et embelli pendant qu’il y était, comme un stagiaire trop zélé qui range votre bureau pendant que vous êtes en réunion. Rien ne se voit sur le moment, tout se voit en atelier, quand le parcours qui marchait la veille ne marche plus devant six personnes. Lui interdire d’améliorer ne suffit pas, il faut lui donner un endroit où le dire, une ligne à la fin, sinon il le fait quand même.

Le dernier, c’est l’ordre des passes, et je l’ai appris de travers. Le comportement d’abord, puis les états, l’habillage en troisième et en une seule passe, parce que c’est la seule des quatre qu’on ne sait pas arrêter, et l’accessibilité en dernier, parce qu’un écran projeté ne pardonne pas un mauvais contraste. Sur ce chronomètre, dont j’ai déjà parlé ici, j’ai passé deux étapes entières à peaufiner l’apparence pendant que le métier attendait des arbitrages. Et sur le même, l’audit que je fais lancer à l’agent avant chaque atelier a trouvé un bouton qui aurait planté au vidéoprojecteur, devant tout le monde, après que trois personnes en séance l’avaient laissé passer. Quand l’outil vous dit « c’est vérifié », demandez-lui ce qu’il a lancé et ce que ça a donné.

Rien de tout cela n’est de l’informatique. Anthropic publie un cadre de compétences en quatre volets, déléguer, décrire, discerner, assumer⁷, et le prompt, la consigne qu’on écrit à la machine, n’y occupe qu’une case sur douze. Les onze autres, choisir le bon travail à confier, juger ce qui sort, l’assumer, un chef de projet sait déjà les faire, parce que c’est son métier appliqué à un nouvel outil. Et pour les projets où aucune donnée ne peut sortir, il reste trois paliers, dans cet ordre, flouter, parce que la forme d’un écran n’est presque jamais sensible quand la donnée l’est, localiser avec un modèle qui tourne chez soi, et renoncer, qui se décide et s’assume comme le reste.

« Ça marche, livre-le »

Un jour, quelqu’un regarde mon démonstrateur et prononce ces mots. Ma réponse doit sortir avant qu’il ait fini sa phrase, parce qu’une seconde d’hésitation vaut un oui. Rien de ce qui manque n’a été oublié, ni les vraies données, ni les droits, ni la sauvegarde, ni la reprise après panne, c’est le principe même de l’objet. Son jumeau est plus insidieux, l’attachement. Le métier tombe amoureux de ce qu’il a manipulé et trouvera la vraie version moins bien. Je le dis au premier atelier, avant le premier clic, cet écran ne sera jamais le produit, et c’est pour ça qu’on peut tout lui demander. Préparer le deuil dès la naissance manque de romantisme, mais ça marche.

La méthode n’est pas faite pour tout le monde. Elle demande de vrais arbitrages, à prendre sur place et à assumer ensuite devant la maîtrise d’œuvre comme devant le métier, et tous les chefs de projet n’ont pas envie de ce rôle-là. Elle vaut en revanche autant pour un product owner que pour un chef de projet, PRD à la place du cahier des charges, puisque le travail est presque le même et que le prototype fait déjà partie de sa culture. Je viens du métier, ce qui m’aide à deviner ce qui lui sera profitable, et j’ai gardé assez de sensibilité aux contraintes des ingénieurs et des techniciens pour trouver une solution de repli quand la leur ne passe pas. C’est ce mélange qui fait que ça marche chez moi, et je ne garantis rien pour les autres.

Il n’empêche que des directeurs et des chefs de projet me sollicitent maintenant pour que je leur montre comment je fais, et je leur montre bien volontiers. Je crois profondément que l’intelligence artificielle n’est pas faite pour tout, et qu’elle a changé de fond en comble cette partie-là de mon métier, celle qui exigeait un temps interminable de rédaction d’un cahier des charges que personne n’avait envie de lire. Un démonstrateur, c’est tout de suite plus digeste. Si vous voulez essayer, ne commencez pas par le projet stratégique de votre entreprise, parce que si le premier essai est trop gros, il n’y aura pas de deuxième. Commencez par ce qui vous agace.

Notes

1. Dans le jargon des projets informatiques, la maîtrise d’ouvrage (MOA) représente ceux qui commandent l’outil et s’en serviront, le « métier », et la maîtrise d’œuvre (MOE) désigne ceux qui le construisent. La recette est la phase où le métier teste ce qui a été livré avant la mise en service, et c’est là que les malentendus se découvrent. ↩

2. Le product requirements document, le document d’exigences produit, joue dans les équipes produit le rôle du cahier des charges dans les projets, et souffre des mêmes faux oui. ↩

3. Pendo, « The 2019 Feature Adoption Report » (en anglais), 5 février 2019, sur 615 produits observés pendant plus d’un an. Un chiffre plus ancien de 64 % circule partout, attribué au Standish Group en 2002, mais il reposait sur quatre applications internes, comme l’a rappelé Mike Cohn (en anglais). ↩

4. Le terme vient d’Andrej Karpathy, ancien directeur de l’IA chez Tesla, qui décrivait le 2 février 2025 une façon de coder où l’on « s’abandonne aux vibrations » et où l’on « oublie que le code existe ». Un démonstrateur, c’est exactement ça, à ceci près qu’on n’oublie jamais que l’écran ne sera pas le produit. ↩

5. Un agent est un modèle de langage installé sur votre machine, capable de lire et d’écrire des fichiers et de lancer des commandes, là où l’assistant en ligne ne fait que répondre dans une fenêtre, sans voir le fichier, et le réécrit donc en entier à chaque remarque. J’utilise Claude Code parce que c’est mon outil au quotidien, et Codex, chez OpenAI, fait le même travail. ↩

6. Chaque agent relit au début de chaque conversation un fichier de projet, CLAUDE.md chez Claude Code, AGENTS.md chez Codex. L’image qui m’a aidé est celle d’un chef de projet brillant mais amnésique, que l’on changerait à chaque réunion, et à qui l’on glisserait ce document avant d’entrer dans la salle. ↩

7. Anthropic, « AI Fluency: Framework & Foundations » (en anglais), conçu avec Rick Dakan (Ringling College of Art and Design) et Joseph Feller (University College Cork). Les quatre compétences s’y nomment delegation, description, discernment et diligence, chacune en trois volets, soit douze cases dont une seule, dans la description, concerne la formulation de la demande. ↩