Le no-code n'a pas perdu. Il vient de muter.

Le no-code n’a pas perdu.

Il a ouvert une porte.

Pendant des années, cette porte disait : tu peux construire sans attendre une équipe technique, sans budget énorme, sans permission.

Aujourd’hui, la porte donne sur autre chose.

La nouvelle compétence rare n’est plus seulement de builder sans coder. C’est de maîtriser l’IA assez bien pour choisir quoi construire, tester plus vite, critiquer ses propres idées et transformer une intuition en produit réel.

Bref, de “builder” comme disent les américains.

Au programme :

• 🧠 Pourquoi le développeur de demain ressemble de plus en plus à un Product Builder.

• Comment utiliser l’IA pour critiquer tes idées, pas seulement les valider.

• Pourquoi les agents déplacent la valeur du prompt vers la boucle de travail.

• 🔮 Quelques découvertes à ne pas louper : agents de sécurité, Git pour agents, compression de contexte, apps agent-native.

Avant d’enchaîne sur le reste, je voulais te dire que j’ai pris une décision.

Je vais renommer cette newsletter Builders Station en référence à la fonction qui prend de plus en plus d’ampleur : le Product Builder.

Pas parce que le no-code aurait perdu.

Au contraire.

Le no-code a gagné quelque chose d’important : il a prouvé qu’une personne qui comprend un problème peut construire bien plus qu’avant, sans attendre que toute une organisation se mette en mouvement.

Mais la tournure technologique est clairement à un tournant.

À l’époque de l’explosion du no-code, le rôle du Product Builder était surtout associé à des outils capables de créer des apps, des automatisations, des sites, des workflows internes.

Aujourd’hui, la maîtrise de l’IA élargit ce rôle à des sujets qui n’étaient pas vraiment de son ressort à l’époque : écrire des specs plus solides, piloter des agents, structurer une base de connaissance, tester des hypothèses, générer du code, automatiser des boucles métier, auditer une stratégie, prototyper une interface, analyser des retours, documenter une décision.

Le Product Builder ne se définit plus seulement par les outils qu’il utilise. Il se définit par sa capacité à transformer l’IA en levier concret de création, de décision et d’exécution.

En renommant cette newsletter, je veux donner un nouvel élan à un métier que j’ai contribué à faire émerger il y a plusieurs années, à l’époque du no-code.

Le principe ne change pas.

Chaque semaine, l’objectif reste de t’éclairer sur les concepts, outils et signaux à connaître si tu construis des produits, des automatisations, des apps, des offres ou des systèmes avec l’IA.

Mais le terrain devient plus ambitieux.

Je veux aussi partager à la communauté, notamment française, les opportunités business, les jobs, les événements, les idées de services et les mouvements de marché qui vont compter pour ce métier.

Bref : si tu as aimé NO CODE STATION, tu devrais aimer cette nouvelle version consacrée à un métier qui va exploser en entreprise : Product Builder.

Bonne lecture !

P.S : pour me donner un peu de force, n’hésite pas à partager à tous les Product Builders (apprentis ou confirmés) cette newsletter. Merci !

Dans sa dernière vidéo, Benjamin Code va chez Google à San Francisco et pose une question simple : qu’est-ce qu’un développeur doit encore apprendre quand l’IA et les agents savent déjà produire de plus en plus de code ?

La réponse de Varun, telle que Benjamin la résume, est intéressante parce qu’elle ne dit pas : “la technique ne sert plus à rien”.

Elle dit plutôt : la technique bas niveau devient minoritaire pour la majorité des profils, pendant que le jugement produit devient central.

Pendant longtemps, le développeur “sérieux” était celui qui maîtrisait le plus de couches techniques possible. Langage, framework, base de données, infra, optimisation, edge cases, architecture.

Tout ça reste utile. Et dans certains moments, c’est même indispensable.

Quand tu tombes sur un bug dur, quand ton agent génère une solution bancale, quand ton produit casse en production, comprendre la stack reste une arme. Personne n’a envie d’être le passager d’un avion dont le pilote sait seulement demander gentiment au copilote automatique de “faire un bel atterrissage”.

Mais pour beaucoup de projets, la rareté se déplace.

Si l’IA réduit le coût d’exécution, le coût le plus dangereux devient le mauvais choix.

Construire vite un mauvais produit, c’est toujours construire un mauvais produit.

Construire vite une feature que personne n’attend, c’est juste brûler moins cher ton temps.

Construire vite une interface sans goût, sans exigence, sans retour utilisateur, c’est produire plus rapidement quelque chose que personne n’utilisera.

C’est là que le mot “goût” devient important.

Pas le goût au sens esthétique superficiel. Le goût au sens produit :

• sentir qu’un problème est réel ;

• écrire une spec claire ;

• distinguer une friction importante d’un détail cosmétique ;

• choisir ce qu’il ne faut pas construire ;

• mettre une version entre les mains de vrais utilisateurs ;

• exiger mieux que “ça marche à peu près”.

L’exemple du jeu vidéo dans la vidéo est parlant : les jeux qui marquent ne sont pas toujours ceux qui ont la plus grosse production. Ce sont souvent ceux qui ont une mécanique, une histoire, une boucle de plaisir, un univers cohérent.

Traduction pour nous : l’IA ne rend pas le goût optionnel. Elle le rend plus visible.

Avant, le manque de goût pouvait être masqué par la difficulté technique. “On n’a pas encore fini”, “il manque le dev”, “il faut plus de budget”.

Maintenant, tu peux sortir une V1 beaucoup plus vite. Donc l’excuse disparaît.

Si le produit est mauvais, ce n’est plus seulement parce que tu n’avais pas les moyens de le construire. C’est peut-être parce que tu n’avais pas assez bien choisi, cadré, testé ou simplifié.

Et c’est exactement pour ça que le profil Product Builder devient intéressant.

Il ne remplace pas le développeur expert.

Il ne remplace pas le designer.

Il ne remplace pas le PM.

Mais il combine assez de produit, assez de technique, assez de distribution et assez d’exigence pour faire avancer une idée sans attendre que cinq métiers différents se mettent en ordre de bataille.

Ce que ça change pour toi :

• 🟢 Maintenant : si tu apprends l’IA pour builder, ne passe pas tout ton temps sur les outils. Travaille aussi tes specs, tes critères de qualité, tes tests utilisateurs et ton sens du problème.

• 🟡 À surveiller : les profils hybrides vont devenir plus lisibles. Pas “no-codeur”, pas “dev junior assisté”, mais personnes capables de livrer des produits utiles avec agents.

• ⚪ Pas encore : la technique profonde ne disparaît pas. Elle devient un levier de différenciation dans les moments où l’IA bloque, hallucine ou simplifie trop.

L’autre signal de la semaine vient d’un short de Silicon Carne : Pourquoi Claude approuve toujours tes mauvaises idées ?

Le point est simple : si tu demandes à Claude si ta stratégie est bonne, il trouvera souvent des raisons de dire oui.

Pas parce que Claude complote pour ruiner ta boîte.

Parce qu’un assistant conversationnel est souvent entraîné à être utile, agréable, coopératif. Donc si tu lui apportes une idée avec enthousiasme, il peut très vite devenir ton meilleur stagiaire en validation émotionnelle.

Le remède proposé : le prémortem.

La méthode vient de Gary Klein, popularisée notamment dans la Harvard Business Review avec Performing a Project Premortem.

Le principe :

Imagine que ton projet a échoué dans 6 mois. Maintenant, explique pourquoi.

Ce petit changement de cadrage fait une différence énorme.

Tu ne demandes plus :

“Est-ce que mon idée est bonne ?”

Tu demandes :

“On sait déjà que ça a échoué. Qu’est-ce qui l’a tuée ?”

L’IA passe alors du rôle de miroir rassurant au rôle de simulateur d’échec.

Et c’est beaucoup plus utile.

Pour un Product Builder, c’est presque une routine de base. Avant de construire, avant de lancer, avant d’acheter un nom de domaine, avant de passer trois semaines dans Lovable ou Cursor, tu peux forcer ton projet à traverser une mini-crise fictive.

Quelques questions que tu peux poser :

• “Nous sommes dans 6 mois. Ce projet a échoué malgré un lancement correct. Liste les 12 causes les plus probables.”

• “Quelles hypothèses je suis en train de traiter comme vraies alors qu’elles ne sont pas prouvées ?”

• “Quels signaux faibles montreraient dans les 14 prochains jours que je me trompe ?”

• “Quelle partie du produit est séduisante en démo mais inutile en usage répété ?”

• “Quel type d’utilisateur va me dire que c’est intéressant, puis ne jamais l’utiliser ?”

Ce n’est pas magique. Claude peut encore se tromper.

Mais ça change ta posture.

Tu ne viens plus chercher une autorisation de continuer. Tu viens chercher des angles morts.

Et dans une période où tout le monde peut builder plus vite, la vitesse ne suffit pas : il faut aussi augmenter la qualité de tes objections.

Ce que ça change pour toi :

• 🟢 Maintenant : avant ton prochain build, fais un prémortem de 20 minutes. Si tu n’as pas envie de lire les réponses, c’est probablement que tu en as besoin.

• 🟡 À surveiller : les meilleurs builders vont créer des routines de critique, pas seulement des routines de génération.

• ⚪ Pas encore : ne transforme pas le prémortem en excuse pour ne jamais lancer. L’objectif est de réduire les angles morts, pas de fabriquer une thèse de doctorat sur ton anxiété.

Depuis deux ans, on a beaucoup parlé de prompts.

Puis on a parlé de copilotes.

Puis de chatbots.

Maintenant, le vrai sujet devient la boucle.

Une boucle, dans ce contexte, c’est un système qui ne se contente pas de répondre une fois. Il observe un état, agit, vérifie, corrige, recommence, et laisse une trace.

C’est ce qu’on commence à voir partout.

Lenny’s Newsletter parle d’agent loops : des agents qui travaillent sur un objectif avec étapes, critiques, outils et itérations.

OpenAI a lancé Patch the Planet, une initiative avec Trail of Bits pour aider les mainteneurs open source à trouver, valider et corriger des bugs de sécurité. Là encore, le signal n’est pas “un modèle écrit du code”. Le signal est : agents + experts humains + validation + patch.

Et dans tes Daily Briefs de cette semaine, le thème revient sous plusieurs formes : agents qui tournent en continu, skills comme méthodes installables, second brain qui devient actionnable, outils pensés pour le contexte et la version.

Le prompt est une interaction. La boucle est une capacité.

Et pour un Product Builder, ça change la manière de penser les projets.

Avant, tu pouvais dire :

“Je vais créer un outil qui génère X.”

Maintenant, la meilleure question devient souvent :

“Quelle boucle métier puis-je rendre plus fiable, plus rapide ou plus vérifiable ?”

Exemples :

• pas “un générateur de posts”, mais une boucle veille → angle → brouillon → critique → publication → mesure ;

• pas “un chatbot RH”, mais une boucle demande salarié → vérification documentaire → réponse sourcée → escalade humaine ;

• pas “un assistant commercial”, mais une boucle lead → qualification → enrichissement → relance → CRM → analyse des objections ;

• pas “un outil de code”, mais une boucle issue → patch → test → review → changelog.

Ce glissement est important parce qu’il remet le business au centre.

Une entreprise ne paie pas pour “avoir de l’IA”.

Elle paie pour qu’une boucle coûte moins cher, prenne moins de temps, casse moins souvent, ou produise un résultat plus fiable.

Le Product Builder qui comprend ça a une longueur d’avance.

Parce qu’il ne vend pas une démo.

Il vend une amélioration mesurable d’un système de travail.

Ce que ça change pour toi :

• 🟢 Maintenant : quand tu regardes une idée, reformule-la en boucle. Entrée, action, vérification, sortie, trace.

• 🟡 À surveiller : les produits agents seront jugés sur leur fiabilité répétée, pas sur leur première réponse spectaculaire.

• ⚪ Pas encore : toutes les boucles ne méritent pas un agent. Certaines ont juste besoin d’un formulaire, d’une automatisation ou d’une meilleure règle métier.

→ Oak, un Git pensé pour les agents : Oak attaque un problème très concret : Git a été pensé pour des humains qui commitent, pas pour des agents qui créent des branches, snapshots, checkpoints et gros volumes de changements en parallèle. Le signal : l’outillage dev va devoir s’adapter à des workflows où plusieurs agents explorent en même temps. — Oak

→ Headroom, compresser le contexte avant le modèle : Headroom promet de réduire les tokens envoyés aux LLM en compressant tool outputs, logs, RAG chunks, fichiers et historique. Ce n’est pas très sexy en surface, mais c’est exactement le genre de brique qui compte quand les agents deviennent coûteux et longs à opérer. — GitHub

→ Patch the Planet par OpenAI : OpenAI et Trail of Bits veulent aider des mainteneurs open source à identifier, valider et patcher des bugs de sécurité. Le signal : les agents sont plus crédibles quand ils entrent dans une boucle avec validation humaine, pas quand ils produisent juste un rapport automatique. — OpenAI

→ Agent-native architecture chez Builder.io : Builder.io formalise une idée utile : une app agent-native n’est pas juste une app avec un chatbot collé dessus. C’est une app où humain et agent peuvent agir sur les mêmes objets, avec permissions, contexte et actions structurées. Très bon cadre pour penser les prochains produits B2B. — Builder.io

→ Les skills comme produits de méthode : plus les agents deviennent capables, plus les méthodes réutilisables prennent de la valeur. Un skill, ce n’est pas juste un fichier d’instructions ; c’est une façon de transformer un savoir-faire en routine portable. Pour les formateurs, consultants, experts métier et Product Builders, c’est un format à surveiller de très près.

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 👇

Share

Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.

Bonne semaine,

— Milan