Journal de bord · 17 juillet 2026

Vous n’avez pas besoin d’écrire vos specs

Je profite des derniers jours de Fable (jusqu’à ce qu’Anthropic nous annonce qu’ils prolongent à nouveau l’accès) pour regarder jusqu’où je suis allée avec l’IA dans un domaine qui n’est pas le mien : le product management.

Quand j’ai demandé à l’IA ce qu’elle en retenait, elle m’a sorti les poncifs habituels : tu cadres et tu exécutes, ta valeur est dans le cadrage et le jugement…

Bon.

Que diable retenir de ces centaines d’heures passées à emprunter aux product managers leur expertise — garantir qu’un produit reste utile et cohérent — sans reprendre leurs process, hérités d’un monde déjà ancien : cadrage, spécification, validation, puis exécution ?

Prélever juste assez d’expertise

La moi d’avant aurait passé ses soirées à lire pour se faire un vernis d’expertise.

Maintenant, je chasse le bon mot. LE bon concept métier : celui qui oriente l’IA sans tout lui réexpliquer.

Je lui ai demandé le glossaire de l’apprentie product manager : user story, product requirements, wireframe, customer journey, jobs to be done.

Puis je fais appel à des experts sous forme de skills. GitHub regorge de repos d’experts et d’aficionados qui ont transformé leur savoir en fichiers réutilisables.

Le vrai Service-as-a-Software.

Passer de la finalité au rendu sans tout spécifier entre les deux

Je donne mon idée brute et je cadre la finalité : qu’est-ce que je cherche à construire ? Pas quelles fonctionnalités je veux y mettre.

Par exemple : « Un playbook pour rendre les gens autonomes. »

Parfois, je dis ce que je ne veux pas : « Une énième application de gestion de tâches ou de calendrier corporate, froide et sans âme. »

Je donne l’intention.

Puis j’emprunte à Mark Pincus sa méthode Proven, Better, New : demander à l’IA d’aller chercher des concepts éprouvés pour en faire quelque chose de nouveau.

Les skills produisent des problem statements, des personas ou des user stories. Je ne les lis pas. Ces documents servent de mémoire à l’IA pendant le build.

Je demande plusieurs rendus. Je choisis. Je critique. Je chipote. Je transmets tout dans des notes vocales. Avant, j’aurais séparé les registres et les niveaux de décision. Maintenant, j’y vais pêle-mêle.

Dans la même note, je peux dire :

« Il faudra déplacer le bouton en bas à droite pour qu’il soit plus visible. »

Puis remonter à l’intention :

« Ce n’est pas assez limpide pour être utilisé par un C-level qui n’a pas le temps d’ouvrir tous ces onglets. »

À la fin de chaque session, je demande à l’IA d’extraire ce qu’il faut pour mettre le repo GitHub à jour : composants, règles, décisions, recadrages. Elle réécrit les spécifications après coup.

Une aberration dans le monde d’avant, où la réalisation attendait la fin de la sacro-sainte phase de cadrage, relue et tamponnée.

Je laisse la documentation se corriger au contact du rendu.

Flaubert écrivait : « Il n’y a pas de belles pensées sans belles formes, et réciproquement. »

Cent soixante-dix ans plus tard, je crois que nous parlons de la même chose, en version IA.

Étrangement, c’est le rendu qui me révèle ce que je voulais.

Cette pratique est imparfaite

L’exécution prend encore du temps : je peux passer trois heures à comparer des options et à vérifier le résultat. Mais je peux obtenir en un prompt une première maquette qui aurait exigé plusieurs jours de travail.

Le rendu devient un outil de pensée.

Je risque de moins comprendre, d’oublier l’historique, voire de perdre la maîtrise des décisions. Cette méthode se transpose mal au travail en équipe.

Cette pratique imparfaite me convient, pour le moment. Je cherche la vitesse sans abandonner l’intention.

Et atteindre l’exécution avant la perfection.

Le repo, les skills et les outils