Cette question paraît absurde. Elle est pourtant devenue le fil rouge de mon exploration des assistants de code en tant que Product Owner.
Le point de départ
Avec l'évolution des outils IA et la possibilité de "vibe coder", on a désormais au Produit une gamme d'outils beaucoup plus variée que ce qu'on avait il y a quelques années. Mais on n'a pas de notice. Pas d'instructions sur quelle direction prendre. Et personnellement, je ne m’y étais encore jamais frotté.
J'ai décidé d'explorer ça ces dernières semaines, à travers quelques questions fondamentales :
- Comment expliquer et faire réaliser des tâches complexes à une IA ?
- Comment livrer du code quand on n'est pas technique ?
- Comment valider la qualité de ce code sans le vérifier soi-même ?
- Comment communiquer avec une IA, versus avec un humain ?
Ce dernier point est devenu central. Parce que s'il y a bien un département qui doit cerner le besoin, anticiper les enjeux, formuler clairement ce qu'on attend, c'est le Produit. Et formuler clairement, c'est exactement ce que demande une IA.
Expérimentation 1 : Vibe coder une appli simple
Le setup est simple : une licence Claude Code, Visual Studio Code, et une application "bac à sable" pour expérimenter. L'application en elle-même n'a rien de révolutionnaire : un suivi de finances personnelles avec un Dashboard, une page de détail, une liste de comptes. Côté infra, j'ai demandé quelque chose de propre : secrets dans un Vault, Docker, base de données locale.
La règle du jeu que je me suis fixée : ne rien faire de technique moi-même. Même les commandes shell, c'est Claude qui les exécute. Le but était vraiment de me dire : même si j'en suis capable, je veux voir ce qui se passe quand je ne touche à rien.
Le principe à ce stade est direct : je rédige un besoin en langage naturel, Claude le code, je valide chaque édition, chaque commande bash. Si le résultat est bon, on avance. S'il ne l'est pas, je corrige par prompting.
Et pour les features simples, ça marche. On arrive en tant que PO à proposer une fonctionnalité, à la voir se matérialiser, à la valider. C'est déjà quelque chose. Cependant…
Couac 1 : Le problème de la négociation
Là où ça déraille, c'est que Claude se base sur le contexte des prompts précédents et des fichiers claude.md qu’on peut créer au fil de l'eau. Et assez rapidement, il commence à halluciner. À prendre des libertés. On se retrouve à avoir des échanges qui ressemblent étrangement à ce qu'on vivrait avec un développeur un peu insubordonné :
- "Tu as fait ça alors que tu devais faire ça."
- "Attention, tu n'as pas bien lu le contexte."
- "Pourquoi as-tu changé l'interface graphique ? Rien dans le ticket ne le mentionne."
On négocie avec l'outil. Ce qui est à la fois fascinant et profondément contre-productif : je perds du temps à convaincre un robot qu’il a tort au lieu d’avancer.
Couac 2 : La sur-spécification, piège classique
La réaction naturelle face aux hallucinations, c'est de verrouiller le contexte. D'ajouter des prérequis de plus en plus stricts dans le fichier claude.md : “Tu dois exactement suivre ce pattern. Tu dois exactement réaliser ça. Tu ne dois pas toucher à l'interface si le ticket porte sur le back”.
Sauf que ça devient vite paradoxal : plus on lui donne d'informations, plus il a tendance à en occulter certaines. On ne précise jamais à un développeur de ne pas refaire le design complet d'une page si le ticket porte sur un endpoint back-end. C'est implicite et l'IA, elle, n'a pas ces implicites.
Et il y a un autre problème : le code "quick and dirty". Les guidelines de Clean Code existent pour les humains ; bien que difficiles à faire respecter, ça reste un consensus. Pour les IA, je n’ai pas l’impression qu’il y en ait encore, la qualité livrée variant par moments, on ne peut jamais lui faire confiance. On peut tenter de forcer des règles dans le contexte, mais ce contexte peut sauter à tout moment. Mon ressenti est que de cette manière, on ne peut pas être garant du “vibe code” livré sans un tech surveillant le sujet.
Expérimentation 1.2 : le Kanban intégré et la question de l'outillage
Le rêve du Product (le mien en tout cas) : écrire “à l’appli” ce qui ne va pas et elle le change en live. Ainsi, piloter le développement et l'itération de features depuis l'application elle-même, et non plus uniquement par prompting. J’ai donc fait développer un tableau Kanban intégré à l'app. Quatre colonnes : À faire, En cours, À valider, Done. Avec une fonctionnalité permettant de rédiger un ticket directement depuis l'interface.
Quand le ticket est créé, il part en base de données. Quand je le déplace en "En cours", Claude va chercher ce qui est en cours, pose ses questions via VS Code, le réalise, et le pousse en "À valider”. La contrainte : il n'avait pas le droit de développer en dehors des tickets et en dehors des prérequis du ticket. Il a beaucoup de mal à comprendre cette limite fictive. Mais l'idée elle-même m'a ouvert une réflexion plus large que j’explorerai peut-être plus tard : “Les tickets rédigés aujourd’hui sont pertinents à l’échelle humaine, pas à celle d’une IA, et si nous devions monter d’un cran toute notre logique agile ? Une story deviendrait une epic et une epic deviendrait un 'axe de développement'.”
Ce qui m'a frappé dans mon petit exercice, c’est que d’avoir la rédaction du besoin au même endroit que l'application fait gagner un temps fou. Plus de navigation entre Jira, Figma, VS Code. Le même langage pour tout le monde. En tant que PO, c'est un confort immense. J'ai eu un instant la tentation de penser que c'était la fin des Jira et consorts. (Spoiler : non).
Dès qu'on parle sécurité, partage entre équipes, traçabilité à l’échelle, ces outils font le travail et le font bien. En revanche, ce qui est prometteur, ce sont les MCP (Model Context Protocol) : ces connecteurs permettent à l'IA de dialoguer directement avec Jira, GitHub, Slack, sans quitter VS Code. Le PO rédige dans l'interface qu'il connaît ; l'assistant consomme, questionne, travaille. Le meilleur des deux mondes. C’est encore émergent, mais je pense que le premier à faire un “IDE” qui fit autant à des devs qu’à des non-devs explose le marché.
Expérimentation 2 : Fini le dev, focus Produit
Changement d'approche fondamental : je ne vais désormais plus m’amuser à piloter le code, on met le poids sur mon vrai besoin : la rédaction de features. On utilise des "skills" qui prennent en entrée un besoin peu précis et qui produisent en sortie un ticket structuré, propre, exploitable.
J'ai fait l'exercice “Entretien utilisateur exploration”. Un besoin synthétique dans un fichier doc/Miro avec comme besoin de :
- Prendre une page Wikipédia au hasard
- Occulter tous les mots
- Leur donner une “température sémantique”
- Faire jouer l’utilisateur à trouver le titre de la page Wikipédia
- Avoir un système de points par rapport au nombre de mots cherchés / temps d'exécution.
Niche, mais certains auront peut-être reconnu le très bon :https://pedantix.certitudes.org/
Simple en apparence, mais ça touche à tout : API externes, traitement back, affichage front, système de points. J'ai demandé à l'agent de transformer ça en epic et features. Le résultat m'a bluffé. Le pipeline découpe en phases : “rédaction”, “vérification”, “validation” et “monitoring”. Un besoin minimal est devenu quelque chose de structuré et pertinent.
Je me retrouve désormais avec 3 epics logiques (avec un MVP dès l’epic 1 “Pouvoir faire une partie”) et des tickets logiques qui ne se chevauchent pas. Le hic reste sur le temps de développement : il m’estime plusieurs jours de dev et ensuite le réalise en 5 minutes lorsqu’il doit le faire.
J’ai utilisé le manifeste d’un collègue, Ayoub, qui a creusé presque le même sujet en parallèle de mon approche : un manifeste complet du vibe coding, très cadré, avec des workflows de statuts, des phases de revue, des artefacts canoniques. L'avantage : une maîtrise totale. L'inconvénient : un volume d'interactions de pilotage important — /validate, /review, /record-build...
C'est un compromis intéressant à observer : est-ce qu'on veut un assistant qu'on supervise comme un junior avec un process strict, ou est-ce qu'on veut un outil plus autonome qu'on recadre quand il dévie ? La réponse dépend probablement des gens, de l’entreprise... Moi, je veux surtout ne pas avoir un agent dans les pattes à gérer toutes les 25 secondes.
Ce que j'y vois de plus prometteur
Selon moi, l’application des IA et assistants de code la plus pertinente pour un PO ce n'est pas le vibe coding en tant que tel. C'est la transformation d'un besoin brut en spécification exploitable.
Imaginez un entretien utilisateur. Quelqu'un a un pain point. On lui propose de parler, dessiner, gribouiller pendant 10 minutes sur Figma, Miro, un bout de papier. On passe tout ça dans le pipeline : l'agent va croiser avec l'existant, structurer, et remonter quelque chose de palpable. Quelque chose qu'on peut discuter avec les équipes techniques, challenger en tant que Produit.
En 10 minutes d'échange, j'obtiens une base de travail qui aurait pris bien plus longtemps. Pas parce que le PO est lent, mais parce qu'en 10 minutes il n'a pas le temps de croiser le besoin avec l'existant technique de vérifier la cohérence. L'IA, elle, le fait.
Et ensuite ?
Et bien de mon côté, je vais finir cette application pour voir l’évolution de la pertinence de mes features (et aussi parce que j’ai bien envie d’avoir mon Pédantix maison). Je pense qu’il faut également creuser sur une application avec du legacy, de la dette technique et compagnie, ce qui est totalement différent d’un petit projet from scratch, et déjà un peu renseigné sur internet.
Mais concluons ! Si je remonte aux questions que je posais au début, celle qui reste la plus intéressante, c'est : comment parler à un humain via un robot pour mieux communiquer avec un robot ?
Je n’ai pas trouvé la réponse mais je sens bien que le PO augmenté de demain ne sera pas celui qui push des anomalies trouvées sur l’appli ou des petits changements en direct, mais bien quelqu’un avec une myriade d’agents capable à tout moment de challenger des gribouillis d’utilisateurs pour en faire l’appli de leurs rêves.
