Le Product Builder ne code plus seulement. Il orchestre des agents.
Le vibe coding était la porte d’entrée. La vraie compétence, maintenant, c’est de transformer une idée floue en workflow fiable.
Pendant deux ans, on a résumé l’IA au prompt. Puis au vibe coding. Puis aux agents.
Mais cette semaine, plusieurs signaux racontent autre chose : le sujet n’est plus seulement de “faire faire une tâche à l’IA”. Le sujet, c’est de savoir cadrer, piloter, vérifier et réutiliser le travail de plusieurs agents.
Au programme :
- 🧠 Pourquoi le Product Builder devient designer de workflows agents
- 🛠️ Un système simple pour passer d’une idée à un agent utile
- 📡 Visual AI as code, Codex Sites, agents locaux et interfaces agentiques
---
🧠 Le Product Builder devient designer de workflows agents
La compétence rare n’est plus d’utiliser un chatbot. C’est de construire le système qui permet à des agents de travailler proprement.
Le “vibe coding” a eu un mérite : il a montré qu’on pouvait passer d’une idée à un prototype sans maîtriser toute la chaîne technique. Tu décris ce que tu veux, l’IA écrit du code, tu corriges, tu relances. Pour beaucoup de builders, c’était déjà un énorme déblocage.
Mais on commence à voir la limite du modèle. Une IA qui code vite ne suffit pas si personne ne sait cadrer ce qu’elle doit produire, comment le vérifier, et quand s’arrêter.
C’est exactement ce que racontent les signaux de cette semaine autour de l’agentic engineering. Matt Van Horn parle de workflows où l’idée devient un `plan.md`, puis une séquence de tâches pilotées par agents. Anthropic vient de publier une approche similaire avec les dynamic workflows de Claude Code : au lieu d’utiliser un seul environnement générique, Claude peut créer son propre “harness”, c’est-à-dire le cadre de travail adapté à la tâche.
Le mot “harness” est technique, mais l’idée est simple : un agent travaille mieux quand on lui donne une méthode, des contraintes et une boucle de validation. Ce n’est pas très différent d’un bon brief humain. Tu ne demandes pas à un freelance “fais-moi un truc cool”. Tu lui donnes un contexte, un objectif, des critères de réussite, des exemples, puis tu relis.
La différence, c’est que cette logique devient maintenant industrialisable. Un Product Builder peut créer des plans, des checklists, des tests, des sous-agents spécialisés, des fichiers de suivi, des routines de QA. L’agent ne remplace pas seulement l’exécution. Il entre dans une chaîne de production.
Et c’est là que le métier devient intéressant.
Parce que si tout le monde peut générer du code, la valeur ne se situe plus seulement dans le code. La valeur se déplace vers la capacité à transformer un problème métier flou en système exécutable et facilement itérable. Comprendre le besoin, choisir les bons outils, découper la tâche, définir ce qui est acceptable, repérer les erreurs, capitaliser le workflow pour le réutiliser ailleurs.
C’est très proche de ce que Every appelle le compound engineering : l’humain garde l’idée, le jugement et le polish ; l’agent prend une partie croissante de l’exécution intermédiaire. Pas parce que l’humain disparaît, mais parce que son rôle change.
Pour les founders, freelances et équipes produit, le message est assez direct : apprendre à “prompter” ne suffit plus. Il faut apprendre à designer des workflows.
Le Product Builder de 2026 ne sera pas celui qui sait tout coder à la main. Ce ne sera pas non plus celui qui délègue tout à un chatbot. Ce sera celui qui sait orchestrer des agents assez bien pour livrer un résultat fiable, compréhensible et améliorable.
Ce que ça change pour toi :
- 🟢 Maintenant : arrête de demander directement “construis-moi X”. Commence par demander un plan, des hypothèses, des critères de validation et une checklist de QA avant toute exécution.
- 🟡 À surveiller : les workflows réutilisables par métier : audit SEO, analyse CRM, génération de landing pages, recherche marché, support client, reporting. Ce sont les prochains actifs que les bons builders vont capitaliser.
- ⚪ Pas encore : empiler 10 agents partout. Si ton workflow n’est pas clair avec un agent, il ne deviendra pas magique avec dix.
🛠️ Un workflow simple pour passer de l’idée à l’agent utile
Tu n’as pas besoin d’une usine multi-agents demain matin. Tu as besoin d’un meilleur cadrage.
La méthode la plus simple que tu peux tester cette semaine tient en quatre fichiers ou blocs.
D’abord, un `brief.md` : le contexte, l’objectif, les contraintes, les exemples de ce que tu veux et de ce que tu ne veux pas. Ensuite, un `plan.md` : les étapes proposées par l’agent avant exécution. Puis une `qa-checklist.md` : comment savoir si le résultat est bon. Enfin, un `notes.md` : ce qui a marché, ce qui a échoué, ce qu’il faudra réutiliser la prochaine fois.
Ce système paraît basique, mais il change tout. Tu ne discutes plus avec l’IA comme avec une boîte magique. Tu construis une mini-chaîne de production.
À tester : prends une tâche que tu fais souvent — préparer une page de vente, analyser une idée, structurer une proposition client — et force l’agent à produire `brief → plan → exécution → QA → notes`. Ne passe à l’exécution qu’après validation du plan. — [Claude Code dynamic workflows]
📡 Signaux à ne pas louper
→ Visual AI as code : a16z défend une idée importante : les meilleurs outils visuels IA ne génèrent plus seulement des pixels, ils génèrent le code ou la structure derrière le visuel. La prochaine génération d’outils visuels IA ne générera pas seulement des images finales, mais des fichiers structurés et modifiables: SVG, HTML/CSS, React, Lottie, Blender, scènes 3D. Pour les builders, c’est clé : un output éditable vaut plus qu’une jolie image impossible à modifier. — [a16z]
→ Codex Sites : OpenAI pousse Codex au-delà du code pur avec des sites et apps interactives partageables en équipe. Signal intéressant : les agents deviennent des outils de travail pour transformer plans, idées et analyses en interfaces utilisables, pas seulement en texte. — [OpenAI]
→ Hermes Agent : Nous Research pousse un agent open source avec mémoire, skills et capacité à apprendre de ses usages. Ce n’est pas forcément prêt pour tout le monde, mais le signal est clair : l’agent devient un environnement persistant, pas une session de chat jetable. — [GitHub]
→ Compound Engineering : Every formalise de plus en plus une méthode où l’humain garde l’intention et la qualité finale pendant que les agents absorbent une partie de l’exécution. C’est probablement l’un des meilleurs cadres actuels pour comprendre le travail “AI at work”. — [Every]
Si un sujet t’a parlé, si tu veux challenger une idée ou juste dire que tu étais là — réponds directement à cet email. Je lis tout et je réponds à tout.
Et si tu as un projet à développer — une app, un outil interne, une V1 à finaliser — c’est exactement pour ça que je suis là. Un message en réponse à cet email suffit pour qu’on en parle.
Si tu veux sponsoriser les prochaines éditions c’est possible. Je te laisse consulter le deck.
Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui en ferait quelque chose 👇
Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.
Bonne semaine,
— Milan