# AI Native PM : construire plus vite mais construire mieux, Benoit Terpereau Source : - Auteur : Terry Michel - Publié le : 2026-04-27T21:36:31+02:00 - Mis à jour le : 2026-09-16T09:22:35+02:00 - Langue : fr-FR - Invité : Benoit Terpereau - Épisode : 134 [Écouter l’épisode](https://sphinx.acast.com/p/open/s/67a716499c6f7f7f280da15b/e/69efcb5442ac2dba68312e90/media.mp3) ## Présentation Et si le futur du Product Management ne consistait plus seulement à cadrer, mais aussi à construire ? Dans cet épisode, **Benoît Terpereau** partage sa vision du Product Management augmenté par l'IA générative, où les profils produit deviennent des product builders capables de concevoir, tester et livrer plus vite tout en restant centrés sur la valeur utilisateur et business. Benoît est ingénieur de formation, passé par des rôles de développeur, CTO, Product Manager, directeur produit, VP produit et CPTO, notamment chez My Little Paris, Deezer, Lunii et aujourd'hui [Believe](https://www.believe.com/), où il pilote une équipe produit d'une cinquantaine de personnes. Il explique : ▪️ Pourquoi aujourd'hui seul un tiers du code livré apporte réellement de la valeur et pourquoi accélérer sans discernement ne ferait qu'amplifier ce gaspillage. ▪️ Comment il déploie cette transformation chez Believe avec une no-code factory et un programme beta "AI Native PM". ▪️ Pourquoi les PM doivent devenir plus business et mesurer leur impact sur les revenus car c’est là que se joue leur légitimité quand tout le monde peut builder. ▪️ Pourquoi l'empathie reste la compétence numéro un et pourquoi un PM ne devrait pas passer une journée sans interagir avec un utilisateur. ▪️ Sa méthode en 3 phases : interviews dé-biaisées par l'IA, prototypes fonctionnels testés par les utilisateurs, synthèse des retours assistée par la GenAI. Vous pouvez contacter [Benoit sur LinkedIn par ici](https://www.linkedin.com/in/benoitterpereau/). — 💼 Vous souhaitez travailler avec moi ? Découvrez [mes services ici.](https://justaclick.fr/product-sprint/) — ## Transcription ## Transcription de l’épisode - [Présentation de Benoit et mission produit chez Believe](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#pr%C3%A9sentation-de-benoit-et-mission-produit-chez-believe) - [Les outils quotidiens pour automatiser, transcrire et prototyper](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#les-outils-quotidiens-pour-automatiser-transcrire-et-prototyper) - [En 2026, des product managers beaucoup plus business pour apporter de la valeur](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#empathie-business-et-valeur-du-product-management-en-2026) - [Interviews utilisateurs, transcription et prototypes testés avec la GenAI](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#interviews-utilisateurs-transcription-et-prototypes-test%C3%A9s-avec-la-GenAI) - [Granola, Gemini et Claude Code pour analyser les retours de prototype](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#granola-gemini-et-claude-code-pour-analyser-les-retours-de-prototype) - [Rendre Claude Code accessible aux product managers non techniques](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#rendre-cloud-code-accessible-aux-product-managers-non-techniques) - [Les développeurs comme premiers utilisateurs des outils de GenAI et de no-code](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#les-d%C3%A9veloppeurs-comme-premiers-utilisateurs-des-outils-de-genai-et-de-no-code) - [Créer une no-code factory et former les équipes au mode ai native](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#cr%C3%A9er-une-no-code-factory-et-former-les-%C3%A9quipes-au-mode-ai-native) - [Les objections des product managers face à l’automatisation](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#les-objections-des-product-managers-face-%C3%A0-l-automatisation) - [Commencer par de petites automatisations avec Gemini et n8n](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#commencer-par-de-petites-automatisations-avec-gemini-et-n8n) - [Context switching, fatigue et évolution du métier de product manager](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#context-switching-fatigue-et-%C3%A9volution-du-m%C3%A9tier-de-product-manager) - [Les leaders produit doivent garder un pied dans l’opérationnel](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#les-leaders-produit-doivent-garder-un-pied-dans-l-op%C3%A9rationnel) - [Commencer à builder aujourd’hui et nourrir sa veille produit](https://justaclick.fr/podcast/ai-native-pm-construire-plus-vite-mais-construire-mieux-benoit-terpereau/#commencer-%C3%A0-builder-aujourd-hui-et-nourrir-sa-veille-produit) ### Présentation de Benoit et mission produit chez Believe 00:00 Terry ouvre l’échange en demandant à Benoit de se présenter, avant de revenir sur le futur des métiers du produit, le Product management augmenté à la GenAI et l’idée que tout le monde devra devenir Product Builder d’ici 2030. Benoit retrace alors son parcours, de ses premières années dans la tech comme développeur et CTO jusqu’à ses postes chez Deezer, Luni puis Believe. Il présente aussi la mission produit chez Believe: accompagner le développement international, aider les artistes et labels avec des outils numériques et des services, et faire monter la culture produit dans un univers de plus en plus technologique. **Terry:** Salut. Benoit. **Benoit:** Hello, Terry. **Terry:** Merci de prendre du temps aujourd'hui pour parler du futur des métiers du produit, pour parler du Product management augmenté à la GenAI. Et pourquoi, d'ici 2030, Ce qui n'est pas si long, in fine, à la vitesse à laquelle tout ça évolue, Tout le monde devra devenir Product Builder. En tout cas, C'est une conviction que tu as qui est assez forte. C'est ça. Et avant de rentrer dans le vif du sujet, je te propose tout d'abord de te présenter. **Benoit:** Déjà, Merci de m'avoir invité. Je suis très content d'être là et c'est vraiment un sujet super. Écoute, donc, moi, je suis Benoit, je suis ingénieur de formation. J'ai passé mes dix premières années de ma carrière plutôt dans la tech, donc j'ai été startupeur, développeur. J'ai fini, entre guillemets, ma carrière de tech dans une startup qui s'appelle My Little Paris, où j'étais CTO et j'ai découvert en 2011 les métiers du produit, dans une startup qui s'appelle Enablone, Et je me suis engouffré dans ce métier que j'adore. Et j'ai grandi, donc Product, manager, directeur, produit. Ensuite, J'ai rejoint Deezer en tant que VP produit. Et j'ai évolué après. Dans d'autres postes de CTO et CPTO, notamment chez Luni, les petites fabriquées à histoire pour les enfants. Et depuis presque un an, j'ai rejoint Believe pour retravailler dans la musique. **Terry:** Et du coup, Believe, **Benoit:** qu'est-ce que vous faites Alors, Believe, C'est une boîte d'à peu près 2200 personnes. On aide les artistes et les labels. À accélérer leur carrière avec des outils numériques et des services. Donc, on a une couverture mondiale. On a des artistes un peu partout dans le monde. Et en France, par exemple, On a des artistes comme Jul, comme Mickey, que j'adore. Et l'équipe produit fait entre 50 et 60 personnes à peu près. **Terry:** Et donc, toi, ta mission, t'as rejoint, du coup, cette nouvelle boîte. Avec quoi, comme Mission principale et tes enjeux aujourd'hui du quotidien **Benoit:** Alors, il y en a plusieurs. Il y a d'abord accompagner l'entreprise dans son développement international. La musique, C'est un marché qui est en perpétuel renouvellement et en perpétuel disruption. Donc, il faut réussir à accompagner ça en proposant les bonnes solutions. Produits et digitales. Continuer à apporter la culture produit chez Believe. La musique est un métier initialement très humain, mais qui se... Technologistes de plus en plus, donc il faut de plus en plus de culture, produit. Et enfin, je pense, et on en parlera aujourd'hui, amener cette culture de product building et comment on gère l'arrivée de la GenAI, En tout cas dans nos métiers, produits et tech, Et comment on accompagne tout ça, Et donc c'est ce que j'essaye de faire. **Terry:** Yes, trop bien. Donc on va rentrer maintenant dans le vif du sujet, donc product building, toi, à titre déjà perso, Donc qu'est-ce que quels sont les outils avec lesquels tu as le plus passé de temps récemment ? On a enregistré cet épisode, ### Les outils quotidiens pour automatiser, transcrire et prototyper 02:59 Terry précise qu’à fin mars 2026, il veut savoir quels outils sont devenus des outils du quotidien pour Benoit. Benoit cite surtout des outils de no-code et de code augmenté, comme n8n, Bubble, Claude, Claude Code, Gemini et Notebook LM. Il ajoute Whisperflow pour dicter plus vite, ainsi que quelques outils de design et de prototypage comme Polymet ou Claude Code, ce que Terry résume comme un panel d’automatisation, de transcription automatique et de prototypage. **Terry:** Je précise aussi, fin mars 2026, Parce que les choses évoluent très vite à l'ère de la gen AI. À cette date, quels sont un petit peu les outils qui sont devenus pour toi maintenant des outils du quotidien et avec lesquels tu joues beaucoup ? **Benoit:** Je vais forcément en oublier. Je pense qu'on en parlera. Les premiers outils que j'ai vraiment utilisés sont plutôt des outils de no-code. Donc, là, en ce moment, Je joue beaucoup avec n8n, avec Bubble aussi, qui est un outil que j'aime beaucoup, que je trouve très bien pour faire de la production. Beaucoup, Claude et Claude. Code pour des projets perso et pro. Énormément Gemini, puisque c'est notre LLM chez Believe. Notebook LM, qui est juste un outil fantastique. Et un des outils que j'utilise le plus, c'est Whisperflow. Parce que de plus en plus, plutôt que d'écrire, plutôt que de taper sur le clavier, Je préfère dicter et on va beaucoup plus vite. **Terry:** Yes, donc outils d'automatisation, outils de code augmenté, outils de transcription automatique et de prototypage, donc panel et aussi d'exploration derrière, d'interviews, qualis, de transcripts avec notre boucle L. Tout à fait. **Benoit:** J'ai aussi utilisé quelques outils comme Polymet pour faire du design, mais je trouve que de plus en plus, Par exemple, avec un cloud, on peut avoir le même résultat. Et finalement, aller plus vite, parce qu'à moins d'être très piqui, de faire des choses très liées à du design émotionnel, par exemple, On arrive à avoir des interfaces qui sont quand même très correctes. **Terry:** Ça marche. **Benoit:** Avec du Claude Code. **Terry:** Donc, je te posais la question des outils juste pour poser un petit décor. Le but, ce n'est pas de faire du tout. Le spécifique, c'est parler aussi. méthodo, Parler aussi l'évolution du métier du produit. Pour toi, aujourd'hui, Quelle est la place des profils produits Au sein des organisations, quelles sont les compétences et la valeur qu'ils doivent venir apporter aux organisations? À NR, justement, où beaucoup de choses sont en train de bouger avec la Générique. **Benoit:** Moi, je dirais qu'il y a une compétence, ou plutôt un soft skill qui n'a pas changé, c'est l'empathie. C'est de réussir à comprendre le problème de ses utilisateurs. Ça, c'est quelque chose qui n'a pas changé et qui ne changera jamais. À mon avis, Il faut réussir à comprendre les problèmes des gens, de ses clients, de ses utilisateurs pour pouvoir proposer les meilleures solutions produits. Donc ça, c'est le point numéro un. Mais par contre, Je dirais que ce qui est en train de changer, c'est très théorisé, par notamment Airbnb, B, Mais c'est qu'en fait, je trouve que les métiers... ### En 2026, des product managers beaucoup plus business pour apporter de la valeur 05:27 Benoit explique qu’en 2026, les product managers doivent être beaucoup plus business, comprendre leur impact sur les revenus et les coûts, et mesurer à quoi ils contribuent. Il relie cela à l’accélération de la delivery et à la commoditisation d’une partie du code, qui vont faire surgir beaucoup plus d’applications et ne laisser survivre que celles qui apportent de la valeur, bien conçues et alignées sur le business et les besoins utilisateurs. Terry ouvre alors la discussion sur la façon de transformer plus vite des idées en valeur, en parlant de construction autonome, d’apprentissage du marché, d’hypothèses, de méthode et d’outils pour prototyper rapidement. **Benoit:** À la fois, il se rapproche et à la fois, il s'étire. C'est un peu pareil que ça, ce que je dis, Mais les product managers doivent être en 2026, beaucoup plus business qu'on l'a été, par exemple, il y a dix ans. Il y a dix ans, Ce n'était pas tellement la question de venir intervenir dans le P&L des entreprises. Aujourd'hui, Il faut qu'on comprenne pourquoi on intervient et quel est notre impact sur les revenus de la boîte ou sur ses coûts, tout simplement parce que, justement, comme les métiers se rapprochent, puisqu'on peut devenir product builder. Quand on est product, on peut faire de la conception quand on est développeur, on peut faire du code quand on est designer. Comment on arrive à nous, à justifier notre place Et je pense que notre place, c'est vraiment comprendre aussi cet aspect. Très business, très business, très marketing. Et donc ça, c'est quelque chose qu'il faut qu'on apprenne à faire, vraiment. Mesurer notre impact et être capable de comprendre à quoi on contribue. **Terry:** Yes, très clair. Du coup, par rapport à ça, J'ai commencé le Talk en disant qu'on allait parler de product building. Quel est pour Toi le lien entre tout ça? Avec le fait que les Product Managers de demain, les Product designers de demain vont devenir des Product Builders En fait, **Benoit:** Il y a devant nous une accélération de la delivery, comme on appelle dans nos métiers. On va beaucoup plus vite. Le code, En tout cas, une partie du code, est en train de se commoditiser. Et donc, finalement, On va pouvoir amener de la valeur beaucoup plus vite. Et donc on va avoir une explosion demain? d'apps, de micro-apps, de SaaS, de micro-SaaS. Peut-être même qu'on va avoir des SAAS, qu'on pensait absolument immuables, disparaître parce que les gens vont fabriquer leurs propres SaaS. Mais donc, devant cette explosion de... d'applications, Celles qui vont survivre sont celles qui vont apporter de la valeur. Et donc celles qui vont apporter de la valeur, c'est celles qui vont être bien conçues, mieux conçues, donc, avec une compréhension des attentes du business, Une compréhension de business model, une attraction et une compréhension de besoins utilisateurs qui est forte. Donc, si on ne passe pas notre temps à faire, ça, on va shipper du fonctionnel qui ne servira à personne. Il y a quand même un truc qu'il faut se rappeler, il y a des études qui le montrent, c'est que aujourd'hui, là maintenant, chaque ligne de code qu'on sort, Il y en a à peu près uniquement un tiers qui sert à quelque chose. Donc, en fait, Si on amplifie ce phénomène, on ne va pas se rendre service à nous-mêmes. La question, c'est comment, En amplifiant, en allant beaucoup plus vite, on peut réduire ces 70% qui ne servent à rien. Et les gens qui vont réussir demain sont les gens qui vont réussir à transformer ces 30% d'utiles en 70% d'utiles. **Terry:** J'aimerais bien, du coup, qu'on creuse un peu ce sujet-là, donc transformer ces 30% d'utiles en 60 ou 70% d'utiles, avec l'accélération. Parce qu'en fait, c'est là, Je pense aussi, où il y a une connexion entre la capacité à construire soi-même Sans avoir à dépendre potentiellement d'une équipe tech. Et pouvoir apprendre beaucoup plus de son marché, de ses hypothèses, et pouvoir d'ailleurs, in fine, Tendre à délivrer des choses qui vont apporter beaucoup plus de valeur que ce n'est le cas aujourd'hui. Donc, si tu peux partager un peu, peut-être, si on rentre dans ce sujet-là. Aujourd'hui, je sais que toi, tu as beaucoup... Bosser à titre, perso sur construire un peu une sorte d'operating system ou pour toi, en tout cas des suites d'outils pour essayer justement de prototyper vite, de faire des choses. Quelles sont un petit peu à la fois la partie méthode? Et puis, en ligne de fond, les outils qui se grèvent dans cette méthode. Mais pour permettre du coup à des profils produits d'aller encore plus rapidement. Comprendre très finement des problèmes et surtout réussir à voir s'ils peuvent aller apporter de la valeur qui va générer derrière du business. ### Interviews utilisateurs, transcription et prototypes testés avec la GenAI 09:06 Benoit explique qu'il y a au moins trois phases : des interviews utilisateurs en phase exploratoire, la transcription et la synthèse avec la GenAI, puis le prototypage. Terry lui demande ensuite quels outils et quels mécanismes de prompt utiliser pour suivre ce flux, du transcript des interviews jusqu’à la collecte des retours sur le prototype. **Benoit:** Écoute, c'est une très bonne question. Moi, je dirais qu'il y a au moins trois phases. Il y a la phase exploratoire où on fait des interviews avec les utilisateurs. En fait, je vois énormément de Product Managers qui ont des biais de confirmation très forts. Donc, en fait, Ils avèlent les clients et disent Je vais faire cette fonctionnalité. Est-ce que tu l'aimes bien ? Les clients vont répondre oui, parce que les clients, un, Ils n'ont pas envie de te faire de la peine en tant que personne. C'est généralement des gens gentils. Et deux, Si tu leur demandes d'une certaine façon, ils vont te dire oui. Moi, si tu me dis est-ce que tu aimes bien cette fonctionnalité, je vais probablement te dire oui. Par contre, si tu me dis, c'est quoi vraiment? Ton problème, c'est peut-être Le problème que la fonctionnalité résout, c'est peut-être pas là où je vais t'emmener. Et donc, On se rend compte que quand on utilise la GenAI, elle est généralement moins biaisée que nous. C'est comme ça, on est... On est des humains, nous, on n'est pas des machines, donc on est plein de biais. Et on a envie de confirmer ces hypothèses, ces humains. Donc, déjà, un premier conseil, c'est de faire des guides d'interview avec de la GenAI en lui demandant d'avoir un positionnement très ux. research, c'est-à-dire avec le moins de biais possible, toujours transcrire ces interviews utilisateurs, et demander à la GenAI d'en faire des synthèses. Alors, ce n'est pas pour autant qu'il ne faut pas vérifier, il faut toujours vérifier ce que nous disent... Les lèmes, mais pour autant, généralement, C'est moins biaisé que nous. Donc ça, C'est une première approche. Donc vraiment transcrire et essayer d'extraire ce que nous disent les interviews utilisateurs. Ensuite, on peut prototyper, ce qui n'était pas forcément le cas il y a très longtemps, ou alors, je me souviens, il y a une dizaine d'années, moi, j'utilisais... Je crois que c'était Sketch à l'époque, ça n'existe plus maintenant. Comme quoi, les logiciels, il faut faire attention parce que, bine de rien, ça change. Mais j'utilisais Sketch et Invision à l'époque pour faire des prototypes pour mettre sur les téléphones. Mais c'était des images qu'on pouvait cliquer, en fait, comme on fait sur les FIGMA aujourd'hui. Mais maintenant, on peut aller beaucoup plus loin. C'est-à-dire qu'on peut mettre entre les mains de ses utilisateurs un fonctionnel quasiment prêt, même avec une base, pour vraiment montrer ce qu'on veut faire. Et ça, c'est une chance. unique, c'est-à-dire qu'en tant que product manager ou product designer, on peut mettre entre les mains d'un utilisateur ou d'une utilisatrice un fonctionnel pour lui dire est-ce que ça marche ? Et ça, c'est quelque chose qu'on n'avait pas avant ou alors il fallait le développer. Et quelle meilleure façon de voir si on résout un problème avec un fonctionnel que le donner entre les mains de ses utilisateurs sans avoir à le coder vraiment. Et donc ça, c'est fantastique. Donc, là, Le deuxième élément, c'est les prototypes et le troisième élément, c'est reutiliser, Merci. Ce mécanisme de transcription et de synthèse avec de la GenAI pour vérifier que ce que nous disent les utilisateurs de notre fonctionnel qu'on a livré en prototype, c'est bien ce qu'on a entendu nous-mêmes et qu'on ne fait pas de biais de confirmation. Trop fort. Et donc, là, déjà, en fait, On a fait un vrai travail de product, mais à l'heure de la GenAI, qui nous permet de, après, Quand on donne ça à des développeurs ou qu'on le vibe, code, de faire moins de bêtises derrière. **Terry:** Yes, là-dessus, du coup, très clair. Si tu devais partager un petit peu, tu vois, deux, trois outils pour faire ça, pour faire ce... Enfin, tu les as partagés en intro, mais pour faire ce flow-là, Je run mes interviews contextuelles et j'enregistre le transcript que je vais ensuite donner à un LLM, Donc partager potentiellement ce que tu utilises avec... Un système prompt, ou en tout cas, un mécanisme de prompt engineering où tu vas lui demander de télé-analyser, ensuite la partie outils pour prototyper, et enfin la troisième partie pour recollecter ses feedbacks du prototype et voir où aller par la suite. ### Granola, Gemini et Claude Code pour analyser les retours de prototype 12:51 Benoit explique qu’il utilise des outils de transcription comme Granola ou Gemini, puis qu’il peut stocker les transcripts dans un projet et demander à Claude Code d’en faire l’analyse. Terry relance ensuite sur le niveau de technicité attendu chez les PM, en demandant où s’arrête leur जिम्मabilité et comment se fait le handover vers les développeurs, jusqu’aux pull requests. **Benoit:** Bien sûr. Alors, moi, l'outil que je préfère pour tout ce qui me transcribe, c'est Granola. Je ne l'utilise pas au travail. Au travail, quand on utilise la suite Google, J'ai Gemini qui transcribe les meetings pour moi et ça marche très bien. Mais j'avoue que... De perso, Si j'étais tout seul, j'utiliserais Granola parce que j'adore le concept de pouvoir finalement chatter sur un meeting ou une interview. Mais peu importe, en fait, il faut un outil de transcript, donc Granola, Gemini ou, peu importe. En fait, il faut les stocker quelque part. Donc, moi, j'ai des Gems après qui me permettent de faire ça, Mais on peut le faire très bien aussi avec du Claude Code. On met dans son projet Prototype X, on met dans son projet tous les transcripts. Et on lui demande de faire une analyse de ça, ça marche très bien. Comme outil de prototyping, il y en a plein, Figma, Mac, Il y a des outils comme Polymet, un peu plus design, Mais moi, j'avoue qu'aujourd'hui, je fais du Claude Code, parce que c'est l'outil que je préfère. Alors j'ai un passé tech, donc ça ne me fait pas peur, mais finalement, Je pense que même en tant que non tech, on peut s'y mettre. Et finalement, Ce que je trouve intéressant, c'est que... Dans les fichiers de setup, donc cloud.md, On peut donner la stack de son entreprise qu'il va appliquer et ça permet de donner un fonctionnel presque prêt aux développeurs. Une fois qu'on a validé son prototype. Et la question de demain, ça va être, c'est quoi? l'interface, le handover entre les développeurs et les product managers ? Est-ce qu'on va rester sur des tickets comme on a aujourd'hui Ou est-ce que demain, le handover final, Ça sera le prototype expliqué avec les interviews utilisateurs et qu'on donnera ça à des développeurs qui n'ont plus qu'à l'adapter ? Sur la code base finale. Donc ça, c'est la question. Mais en tout cas, voilà ça, c'est les outils qui permettent de faire ça sans problème. Il y a des os de plus en plus des product os, mais aujourd'hui, j'en vois pas vraiment l'intérêt. Yes très **Terry:** clair, donc j'aimerais bien revenir un petit peu sur ce sujet. Justement, du niveau de technicité, notamment quand on voit de plus en plus de PM qui viennent pas nécessairement du monde de la tech. Utiliser par exemple du Claude Code, à quel niveau? En fait, il y a un moment, il faut s'arrêter et dire OK, bah, là, c'est plus de ma responsabilité, C'est plutôt aux développeurs d'intégrer ça de manière plus robuste dans la stack existante, etc. On parle beaucoup des organisations, notamment les plus matures, côté gen. AI, de dire maintenant les product managers, Ils font des pull requests, donc ils font des demandes d'intégration de leurs features dans la base de code existante. Toi, est-ce que tu as un regard par rapport à ça et peut-être Des conseils pour des PM qui ne viendraient pas spécialement du monde de la tech au départ et qui voudraient malgré tout... leverage, tous ces nouveaux outils, quoi. ### Rendre Claude Code accessible aux product managers non techniques 15:33 Benoit explique que des outils comme n8n ou Claude Code sont parmi les plus documentés, et qu’on peut s’y mettre même en tant que product sans être très technique. Terry prolonge ensuite la discussion en interrogeant la place des développeurs dans ce contexte et l’évolution de leur rôle. **Benoit:** Déjà, il faut se redire qu'on vit dans un monde, je vais dire encore une fois, un monde fantastique. Non, On vit dans une époque qui est assez intéressante pour nous, product et nous, tech. Pourquoi C'est que les outils qu'on a entre les mains, donc les outils que j'ai cités tout à l'heure, par exemple n8n ou CloudCode, Ça fait partie des outils les plus documentés du monde. Donc, en fait, moi, mon conseil, déjà, c'est Prenez deux écrans, Prenez une vidéo YouTube et faites quelque chose. Et ça, c'est facile à faire. Enfin, je veux dire, Il y a des tutos qui expliquent tout sur NBTN, sur Cloud. Et même en tant que product, on peut le faire. Alors, ça fait un peu peur quand on fait du Claude Code parce qu'on ouvre un terminal et qu'on ne l'a jamais fait avant. Mais la réalité, c'est que ce n'est pas si technique que ça. Et je vais donner une petite anecdote. Quand j'ai voulu essayer de Claude Code cette année, quand ça s'est mis vraiment à buzzer, Je me suis dit qu'est-ce que je vais faire et j'ai voulu me faire un site perso. C'est tout con, Je n'avais jamais fait un site perso. Et puis, comme je fais des interviews comme là, je me suis dit, pourquoi pas mettre les interviews dans lesquelles j'ai participé, ma base d'articles préférées et les outils ai que j'utilise. Et donc, Je l'ai vibe codé et j'ai trouvé ça facile. Et là où ça m'a le plus bluffé, c'est que quand j'étais développeur, j'avais l'habitude de prendre des serveurs, genre sur OVH. Et je me souviens, config un serveur, Mettre le nom de domaine, faire les sécurisations, C'était compliqué. Et moi, je ne suis pas DevOps, donc j'avais toujours du mal à le faire. Et donc, Je lui ai demandé à Claude Code de m'accompagner. Je lui ai dit, mais est-ce que pas à pas, tu peux m'aider ? Il m'a dit, mais je ne vais pas faire pas à pas. Donne-moi juste les credentials de ton serveur et je vais tout faire. Et il a tout fait. Donc, Je me suis retrouvé avec mon site, bien configuré sur mon serveur OVH, sur lequel j'avais mis déjà mon n8n. Et j'ai trouvé ça assez incroyable parce qu'en fait... Moi, j'ai choisi OVH, Mais il y a des solutions de hosting aussi très simples, comme Vercel, qui sont très naturellement plugées avec Cloud. Et en fait, de la conception. même, donc faire des PRD, Une explication, jusqu'à la livraison sur des serveurs et jusqu'à la base de données avec des services comme Supabase, en fait, On n'a pas besoin de faire une seule ligne de code et un seul truc compliqué. Il assiste complètement. Et donc là, on arrive, à mon avis, à un moment... Pivot pour nous, Product, c'est qu'on n'a plus d'excuses. Il y a encore quelques temps, je trouve qu'on avait des services pour faire du webcoding, mais qui touchaient parfois certaines limites. On n'en touche plus avec le code, en fait. Là, il n'y en a plus. Et c'est pour ça qu'il y a une accélération, maintenant, et c'est pour ça qu'il faut y aller. Moi, je parle souvent du concept de product manager ai native, ou ai native PM. Et là, c'est le moment où il faut y aller. On n'est pas en retard pour ceux qui nous écoutent et qui n'ont pas commencé. Mais maintenant, il faut y aller. **Terry:** Très clair. Là-dessus, J'aimerais bien maintenant avoir ton regard aussi, puisque tu as un background de tech. À la base, sur la place des DEVS là-dedans. Parce que moi, je traite des deux sujets sur le podcast, Autant produits que tech. Et je suis évidemment, à titre personnel, Je suis convaincu que les DEVS ne vont pas disparaître. Évidemment qu'il y a une contraction du marché parce qu'il y a besoin de moins de DEVS pour créer la même solution. Mais leur rôle évolue. Donc, toi, quel est ton... Ton regard par rapport à ça, par rapport au rôle, justement, des développeurs ? ### Les développeurs comme premiers utilisateurs des outils de GenAI et de no-code 18:57 Benoit explique que les développeurs ne vont pas disparaître, mais que les outils de nocode et de GenAI devraient avant tout être utilisés par eux, car ils les augmentent et accélèrent des tâches comme la connexion de systèmes. Il illustre son propos avec n8n, en disant que ce type d’outil permet de passer de plusieurs jours de travail à seulement quelques heures pour des intégrations techniques. Terry reprend cette idée en soulignant que les développeurs sont les meilleurs utilisateurs de ces outils, puis ouvre la discussion sur le contexte d’équipe, les enjeux d’organisation et l’accompagnement au changement. **Benoit:** Bien évidemment que les devs ne vont pas disparaître pour moi. En revanche, Je pense que ce que certains développeurs ne réalisent pas, c'est que, Que ce soit les outils de Nocode ou que ce soit les outils de GenAI, Ça devrait être les premiers utilisateurs. Et ce n'est pas le cas aujourd'hui. Beaucoup voient ça comme des choses qui peuvent les remplacer. Moi, je pense que c'est des outils qui les augmentent. Par exemple... Moi, je travaille beaucoup sur n8n. Chez Believe, on travaille sur une nocodefactory dans laquelle on a mis n8n et on essaye d'automatiser des process avec du n8n. Et parfois, pas spécialement chez Believe, d'ailleurs, mais ça fait la troisième entreprise dans laquelle je crée cette instance-là, on a des devs qui sont plutôt perplexes ou qui ne veulent pas que ces outils-là soient utilisés par d'autres personnes. Alors... Les DEVS devraient être les premiers utilisateurs de ces outils. Pourquoi C'est qu'en fait, quand on veut connecter plusieurs systèmes, et aujourd'hui, On est sur des systèmes d'information qui sont multi-connectés. Mais par exemple, quand on est au support client et qu'on veut connecter un Zendesk avec un stripe pour faire du paiement, par exemple, demander à un développeur de le faire, alors que ce n'est pas le cœur de notre métier, c'est une ineptie. Parce que je suis développeur, je dois sortir de l'information de Zendesk, je dois aller dans la doc de Zendesk, Comprendre le truc, le coder. Mettre ça sur un serveur, et je dois faire la même chose avec la doc de Stripe. On est des humains, c'est assez long à faire finalement. Quand on prend un n8n, les connecteurs sont déjà faits. Et donc, du coup, On va passer de plusieurs jours de travail à plusieurs... J'allais dire minutes, pour faire ça. Peut-être heures, mais pas plus. Et l'enjeu de 2026, c'est la vitesse. Il faut aller vite. Et donc, quand on est développeur, ce qui était mon cas, même si ça fait longtemps que je ne développe plus, en fait, On comprend les concepts. Et donc, on peut appliquer ce qu'on connaît, les concepts qu'on connaît, au service de cette vitesse avec des outils. On n'est pas moins un développeur quand on utilise du n8n pour connecter des systèmes. Et on n'est pas moins un développeur quand on a la machine de coder. Mais quand on voit la qualité, par exemple, de cloud pour faire des interfaces, pourquoi on la ferait? nous-mêmes ? En revanche, commencer à coder des interactions complexes, Commencer à coder un back-end très compliqué, avec des process très complexes, là, ça vient de la tête des gens. Et poser des contextes très clairs, Ça reste l'apanage des développeurs sur des process techniques très compliqués. **Terry:** Et donc... Les développeurs sont les meilleurs quand ils utilisent ces outils-là. Par contre, Il faut qu'ils y aillent. Yes, assez aligné là-dessus. J'aimerais bien maintenant revenir sur le contexte. Donc, là, on a fait un petit panel de l'état actuel, de comment le monde du produit est en train d'évoluer. Et cette logique de product building, donc d'être capable de construire, d'aller assez loin dans la construction de Proto pour faire de la collecte. De Feedback les plus qualitatifs possibles, avec des interfaces qui sont finalement presque les produits finis. Avec des gros guillemets modulo non intégrés en Prod, mais qui permettent d'aller très loin sur la compréhension business. Donc tout ça assez clair d'un point de vue individuel, contributeur individuel, Je suis dans une petite structure, je peux comprendre comment connecter tout ça et aller shipper des choses. Tu disais qu'aujourd'hui, tu as une équipe entre 50 et 60, enfin, vous êtes entre 50 et 60 au product, Donc il y a quand même pas mal de monde à embarquer aussi. Ce n'est pas, j'imagine, aussi simple d'utiliser tous les outils qu'on veut. Il y a aussi les sujets d'orgas, etc. À ce niveau-là, donc, Quels sont un petit peu, toi, peut-être les challenges que tu as, ce que tu essayes de mettre en place, ce que tu as vu. Qui a marché, les choses aussi dans tes expériences passées que tu as pu voir fonctionner dans cette logique d'accompagnement au changement. Donc, même si la genia Ic récent, Tu as vécu d'autres transformations, notamment celle du mobile. Qui était quand même aussi quelque chose d'assez important. Donc, voilà, tes retours d'expérience, plus d'un point de vue, leadership, que tu peux partager. ### Créer une no-code factory et former les équipes au mode ai native 22:59 Benoit explique d’abord qu’il met rapidement en place une no-code factory, avec une petite équipe de Product Builders chargée d’automatiser des processus et de faire des projets en no-code. Il décrit aussi comment cette approche sert à former les personnes intéressées, avec des pratiques, des formations et des usages de n8n pour aller vers des Product Managers « ai native ». Terry enchaîne ensuite en demandant quels sont les principaux freins, résistances au changement et objections qui reviennent quand il faut commencer à automatiser des choses. **Benoit:** Alors, déjà, Le premier truc que j'ai fait dans mes trois précédentes, enfin, deux précédentes expériences, et Believe, c'est que je monte très vite. Une no-code factory. C'est-à-dire qu'en gros, Je crée une petite équipe de Product Builders qui seront là pour automatiser des process et faire des projets en no-code. Par exemple, chez Luni, On avait tout un projet en low-code qui a énormément marché, qui était un mix entre du bubble et du mec.com, qui permettait de faire des interactions avec nos clients sans déstructurer notre roadmap. Donc, en fait, on peut, avec quelques personnes, Mettre une addition à la roadmap et avoir des impressions d'accélération pour tout ce qui n'est pas le cœur. De notre proposition de valeur. Chez BDiv, Notre métier, c'est de distribuer de la musique, de donner des outils aux artistes et aux labels pour accélérer leur carrière et de gérer toute la problématique de rémunération des artistes, être avec les plateformes de streaming pour poser des offres cohérentes. Tout ce qui n'est pas finalement dans ce cœur-là, Souvent, on le donne aux développeurs et c'est là où on perd de la vélocité. Moi, je pense qu'il faut utiliser le no-code pour ça. Donc ça, c'est déjà le premier truc, c'est d'utiliser ça pour aller plus vite. Et surtout ne plus disrupter. Ni les product managers, ni les développeurs. Donc, là, déjà, On crée une petite équipe de Product Builders qui utilisent des outils comme n8n pour faire de l'augmentation de process. Dans les boîtes précédentes, on utilisait aussi Bubble. J'avoue qu'en ce moment, la limite entre du no-code très front et du cloud, par exemple, Elle devient vraiment très poreuse. Et j'aurais tendance plutôt maintenant à utiliser de... Du cloud no offense bubble, je vous adore. Mais c'est vrai que la question se pose maintenant. Donc ça, déjà, C'est la première réponse. Et ce qui est intéressant, c'est que quand on crée une code Factory, le but, Ce n'est pas tellement d'avoir des product builders qui font uniquement ça, mais c'est de former les gens que ça intéresse, notamment à des process comme n8n. Donc, en fait, on forme énormément de gens, on fait... Chez Believe, on utilise le vendredi après-midi pour faire de l'amélioration continue, à la fois personnelle, à la fois en équipe. Et donc, on fait des formations, on se voit entre nous, on montre ce qu'on a fait, ce qu'on a appris. Par exemple, J'ai fait récemment une formation où j'ai appris à une dizaine de Product Managers à utiliser Nuitn pour faire des playlists. Quand je vais voir des concerts. C'est un truc tout bête. J'ai un concert qui tombe dans mon agenda, je fais beaucoup de concerts. Je vais chercher sur Spotify, la dernière setlist sur setlist.fm. Et je me la mets dans Spotify pour pouvoir écouter exactement la setlist du concert. Pour ne pas avoir de chansons que je ne connais pas. Dans les concerts. Alors, ça ne sert pas tellement à Believe, mais ce qui sert, c'est que n8n, Ça peut servir à la fois à la productivité interne et à la fois à sa productivité personnelle. Donc, on l'oublie beaucoup quand on est Product manager. Là où on perd le plus de temps, c'est en meeting, à faire des slack et à faire des emails. n8n permet très facilement de venir. Créer des mini Chief of staff qui vont venir regarder ton agenda. Est-ce que tout va bien ? Comment tu gères ton temps Est-ce qu'il y a des choses à changer ? Est-ce qu'il y a des meetings que tu peux déléguer Est-ce que tu as bien préparé certains meetings Trier tes emails, faire des sum-ups de newsletters, faire des brouillons pour toi, Ce sont des choses que tu peux faire très facilement avec un LLM et n8n. Donc moi, par exemple, sur toute ma stack perso, qui utilisent n8n et Mistral pour faire ça. Et je gagne énormément de temps. Je ne sais pas combien de temps par jour, mais comme je suis très FOMO, par exemple, je suis inscrit à toutes les newsletters du monde. Donc, J'ai besoin qu'on me les résume et que je pique qu'il y a une chose que les articles qui m'intéressent. Et donc, ça, c'est intéressant. Donc, déjà, Créer une instance qui peut être une instance collective. Il n'est pas obligé d'avoir aussi des temps à temps plein dedans, qui permettent de lancer les practices no code. De product building. Et ensuite, Le deuxième truc qu'on fait la plus particulièrement, c'est qu'on crée un programme bêta de Dai Native PM pour définir ce que ça veut dire. Parce qu'en fait, si on donne à 50 personnes des licences cloud, chacun va l'utiliser comme il veut, mais surtout, Je pense que beaucoup ne vont pas l'utiliser en réalité. Donc, là, Ce qu'on est en train de faire, c'est qu'en petit groupe, avec une dizaine de personnes, on crée nos pratiques, nos skills, nos projets. Pour se dire, ce serait quoi être réel. Natif chez Believe, demain. Donc, on a des skills qui vont transformer des prototypes en tickets, en Epic et en tickets pour suivre le process. On va avoir des skills d'interview. utilisateur, on va avoir des skills de rédaction de PRD. Voilà, c'est tout le travail qu'on fait pour que demain, finalement, Les products ne soient pas livrés avec un fonctionnel qu'ils ne connaissent pas et pas formés. Donc, c'est ce qu'on est en train de préparer. Pour un déploiement dans le quarter, pour que tout le monde devienne un peu ai native. Et après, ça va être aux individus de prendre cette responsabilité, de faire ce virage ou pas faire ce virage. **Terry:** Et là-dessus, quels sont? Un petit peu peut-être les plus gros freins que tu vois côté product, là, pour le coup Les plus grosses résistances aux changements ou les plus grosses... Les questions qui reviennent fréquemment ou les... Les objections qui reviennent fréquemment lorsque tu vas leur dire maintenant, il faut que vous commenciez à réfléchir, à automatiser des choses. ### Les objections des product managers face à l’automatisation 28:37 Dans cette partie, Benoit répond à la première objection, « j’ai pas le temps », en expliquant qu’on peut commencer avec de la GenAI sans perdre de temps et qu’il n’y a plus d’excuses pour se former et s’y mettre. Terry prolonge l’idée en parlant de profils product non techniques qui ne savent pas par où commencer, et des outils comme Lovable qui permettent d’avancer pas à pas vers l’automatisation, jusqu’à des outils comme n8n. **Benoit:** Alors la première objection, c'est J'ai pas le temps. Ce qui, à mon avis, n'est pas recevable. Pourquoi C'est que en fait, une des premières bases d'être réaïnatif. Quand on lit un peu la littérature, même s'il n'y a pas tant d'articles que ça sur ce concept là, c'est de toujours commencer avec de la GenAI. C'est tout bête, mais moi, j'ai beaucoup d'angoisse de la page blanche. Je n'en ai plus. Je dois faire un email. Je commence avec Gemini, par exemple. Je dois faire un slack à mon boss. Peut-être que je commence avec Gemini. Je dois faire une analyse concurrentielle. Je commence avec Gemini. Donc, en fait, c'est le premier truc. C'est déjà de se former à se dire, en fait, Je vais commencer avec juste un LM. Et ça, ça ne prend pas plus de temps. Mais juste, on va s'apercevoir, qu'on fait les choses quand même, beaucoup, beaucoup, beaucoup plus vite. Donc ça, c'est le premier truc, c'est commencer presque tout avec de la générique. Pour autant, je le redis, c'est pas magique, la générique, donc il faut toujours vérifier ce que ça sort. Mais le fait de commencer, savoir ce qu'on veut, faire, savoir ce qu'on veut sortir, ça permet de domestiquer les outils. Ça, c'est le premier truc. Le deuxième truc, Ce que je conseille toujours, c'est à mon avis, en 2026. Quand on est product, il faut avoir un Side project et ça peut être juste, Je vais faire une application pour faire une liste de courses. N'importe quoi, mais il faut faire un Side project. Il faut avoir quelque chose qu'on build, soi-même. Si en 2026, on est product, si on n'a pas buildé quelque chose, Je pense qu'on passe à côté de... À côté d'une opportunité. Et surtout, Ce qui me fait peur, c'est que... Donc, moi, je suis responsable, je me sens responsable d'une cinquantaine de personnes et de leur carrière. Donc moi, je veux faire en sorte que les gens, quand ils travaillent avec moi, Ils soient au top de ce qu'on fait en termes de product. Donc, c'est ce que je me suis forcé à faire dans toutes les entreprises dans lesquelles j'ai du leadership. Et la GenAI ne va pas nous remplacer. Par contre, les gens qui ne sont pas équipés vont commencer à avoir du mal à trouver du travail. Et donc on a une responsabilité, c'est comment on accompagne tout ça. Et donc, Je pense qu'on a une responsabilité, nous, en tant que leader. Donc, c'est ce que j'essaie de faire avec mon programme ai Native. Mais il y a aussi une responsabilité individuelle, qui est qu'en 2026, bien évidemment, On a une responsabilité sociétale en tant qu'entreprise, donc on forme les gens. Mais on a une responsabilité individuelle et on peut se former. Il n'y a pas d'excuses. C'est-à-dire, faire un prototype avec un Claude Code ou même mettre un service en production, aujourd'hui, on n'a pas d'excuses. Il y a 100 vidéos qui permettent de le faire. Je dis 100, Il y en a peut-être 1000. En français, en anglais, en toutes les langues que vous voulez, apprendre à faire du n8n pour automatiser ses emails, Il y a 100 vidéos qui permettent de le faire. Et on prend un écran et ça accompagne pas à pas. Et il y a zéro bug. Ça se fait facilement. Et donc, à la fois, on accompagne, mais à la fois, Ce que j'essaie aussi, c'est de faire prendre conscience que c'est le moment de le faire. Et ce que je trouve intéressant, c'est que je trouve que la montée en compétences est finalement pas si importante que ça, pas si grande. honnêtement, même quelqu'un de pas technique peut mettre en deux jours, en trois jours, un service en production. Un week-end, On s'y met et on a un service en production à la fin du week-end, même sans être technique. C'est quand même assez fantastique. Là où, avant, certains logiciels, parce que finalement, les logiciels qui permettent aux gens qui sont pas techniques de coder, Il y en avait avant, des logiciels comme Windows à 20 ans. C'est quand même assez difficile de s'y mettre. Même un logiciel comme Bubble, Il y a quand même une montée en compétences qui est quand même assez forte. Ce n'est plus le cas avec les outils comme le Lovable, comme CloudCode, comme Cloud. Et donc, il n'y a plus d'excuses. C'est vraiment, il faut s'y mettre. Et ce n'est pas trop tard. Et c'est ça qui est intéressant. Alors que la GenAI, on en parle quand même d'une manière assez intensive dans nos métiers. Depuis 3-4 ans. Ce n'est pas trop tard. Donc, il faut vraiment s'y mettre maintenant. **Terry:** Yes, très clair. Donc, j'allais te poser la question, mais tu as cité les outils. Effectivement, la page blanche, dont tu parlais, toi, pour, par exemple, écrire des mails, etc. Mais c'est aussi un retour que j'ai eu. De profils qui ne viennent vraiment pas du monde de la tech, mais qui sont product, et qui disent, OK, Je veux m'y mettre, je veux m'y mettre à faire de l'automation, Je veux m'y mettre à construire des choses, mais je ne sais vraiment pas par où commencer. Et je pense que des outils, tu vois, comme tu as cité, Lovable, sont des outils qui sont très simples, justement, pour rentrer dedans, avec une fenêtre de chat à la chat GPT, Et qui vont vous permettre ensuite, petit à petit, de commencer à faire des choses, de pouvoir aller, regarder le code, de commencer, à comprendre certaines mécaniques de déploiement, de stockage, etc. Et ça va vous permettre ensuite, en vous assistant avec un Claude à côté, en lui parlant, en lui posant des questions, d'avancer, de comprendre un peu comment tout ça fonctionne, les logiques. client-serveur, des petites choses, sans vous transformer en développeur, Mais qui vont vous donner ensuite ces clés-là qui vous permettront encore plus facilement d'aborder un outil d'automatisation comme n8n, d'aborder des choses qui peuvent être un petit peu... Dont la barrière à l'entrée est... En réalité, pas si élevé que ça. C'est juste que l'UI et l'onboarding n'est peut-être Pas aussi travaillé que sur un Mac, par exemple. Sur n8n, je prends deux outils similaires d'automatisation, mais derrière, une fois qu'on a pris les concepts, globalement, ça roule. ### Commencer par de petites automatisations avec Gemini et n8n 33:45 Benoit explique qu'il vaut mieux commencer petit plutôt que de partir compliqué quand on se demande quoi automatiser avec Gemini ou n8n. Il donne des exemples très simples, comme envoyer un titre et une date à un gem pour les mettre dans Google Tasks, labelliser ses emails avec n8n ou résumer des newsletters. Terry prend ensuite le relais pour élargir la discussion aux effets de cette automatisation sur l'organisation du travail et à la fatigue qu'elle peut provoquer. **Benoit:** Je vais te donner un petit conseil, c'est qu'en fait, souvent, On est un peu bloqué en se disant, mais qu'est-ce que je peux automatiser ? Tout le monde me parle n8n, je ne sais pas comment faire. Ou même, qu'est-ce que je peux faire avec un GPT ou un GM Et souvent, On a... Tendance à vouloir... **Terry:** Donc, la custom GPT ou l'équivalent sur Google. **Benoit:** On a tendance à vouloir partir compliqué, alors on peut faire des trucs tout simples. Je vais te donner un exemple que j'ai fait moi juste avec Gemini, donc vraiment un outil très simple, et Gems C'est vraiment très simple à utiliser. Je suis toujours en galère quand je veux me donner une tâche dans ma to-do alors que je suis en réunion. On me dit Tiens, il va falloir faire ça. Et si je prends par exemple, Apple, Rappel, Il faut mettre le titre, il faut mettre une date, il faut mettre une heure, Et finalement, c'est tout de suite, une ou deux minutes et tu perds le focus de ta réunion. Je me suis créé un gemme tout simple où je lui ai dit écoute, Ce que je vais faire, c'est que je vais te dropper. Un titre, une date et tu vas me mettre ça dans Google Tasks. Tout simplement. Je gagne quelques minutes chaque fois en réunion. Et après, on le complexifie. Je lui ai dit par exemple, si je ne te mets pas de date, tu le mets à demain matin à 8h. Si jamais je te mets une date dans le futur, tu le mets à telle heure. Si je te mets la semaine prochaine, tu le mets à lundi 8h. Et en fait, on s'aperçoit que juste un tout petit truc, avec juste des promptes, Ça permet de gagner du temps. Et des exemples comme ça, il y en a plein. Avec du n8n, par exemple, juste se connecter à son Gmail, c'est vraiment très simple. Et se dire, est-ce que tu peux labelliser mes emails ? Et bien ça, c'est très simple à faire, et ça évite de les trier, ça les labellise, Et c'est une toute petite automatisation qui marche bien, qui est documentée plein de fois, Et puis, après ce qu'on va se dire, c'est, Je reçois quand même entre 5 et 6 newsletters par jour, et j'ai du mal à Keep up, est-ce que tu peux me les résumer ? Ce qui est intéressant dans les newsletters, c'est que souvent, quand on est à plusieurs, par exemple sur la GenAI, il y a souvent des news qui sont similaires. Hier, Claude Code a sorti. channels, toutes mes newsletters générales, Elles parlent de ça. Donc, je n'ai pas à passer sur les cinq. Par contre, naturellement, moi, en l'occurrence, Mistral va me les résumer. Et ça, C'est facile à faire aussi. Des Prontes qui résument les newsletters, Il y en a plein et ça permet de se mettre les pieds à l'étrier et de ne pas avoir à tout réimaginer. Et ce que je trouve fantastique aussi sur un outil comme NBTN, Mais même sur des Gems ou des GPT, c'est qu'en fait, il y a déjà tellement de contenu qui existe. Il y a... Énormément d'automatisations n8n qui s'exportent et qui s'importent dans votre n8n. Ça marche très bien, donc vous les prenez directement, Ça ne sert à rien de réinventer un truc qui existe déjà. Il y a des librairies de promptes qui vous permettent de faire déjà des choses. Et les promptes sont interchangeables entre Google, entre Claude ou entre ChatGPT. Donc, en fait, Il existe plein de choses. Et donc, vraiment, mon conseil, c'est Commencez petit et itérez. Yes. **Terry:** Là-dessus, très clair. Donc, maintenant, ce que j'aimerais bien, j'aimerais bien aller vers un autre sujet qui est indirect par rapport à ça, c'est que là, on parle de s'augmenter. Donc, une partie craft, on met les mains dedans, on construit des choses pour soi, pour s'augmenter. En tant que PM, ce qui va nous dégager du temps pour d'autres tâches, pour aller justement plus vite, Comprendre les besoins, apporter de la valeur au business, Vraiment réussir à nous concentrer encore plus sur les tâches à haute valeur ajoutée. Mais ça, ça veut dire qu'à partir du moment, on a commencé à déployer. Du coup, un système où toutes les tâches à faible valeur ajoutée de notre journée. Elles sont déléguées de manière automatique à des systèmes. Pour pas qu'on ait à se charger de ça. En fait, notre journée est concentrée uniquement sur des tâches à haute valeur ajoutée. Et donc, ça veut dire qu'en fait là où avant, on avait un peu des temps morts, pour des fois un peu, déconnecter, faire des tâches un peu. Voilà où il n'y a pas trop besoin où on débranche le cerveau. Mais au moins, ça nous permet juste de nous de faire un peu des Merci. Des moments dans la journée où on n'est pas tout le temps à 200%, là, on se retrouve potentiellement à des journées où on est tout le temps à 200%. Et du coup, mine de rien, en fait, C'est beaucoup plus fatigant. Les personnes qui n'ont pas cette habitude-là de pouvoir gérer une intensité aussi forte, notamment plus les contributeurs individuels, qui avaient l'habitude d'avoir le manager qui les cadre. Un petit peu aussi sur ce qu'il faut faire sur une durée de temps plus ou moins définie. On commence à avoir justement, En premier lieu chez les développeurs, des développeurs qui commencent à parler de burn-out lié à la productivité qu'ils gagnent. Mais du coup, c'est quelque chose qui va gagner aussi. Le monde du produit. C'est une petite musique qu'on commence à entendre en termes de fatigue. Donc, toi, c'est quoi un peu ton ressenti par rapport à ce que je viens de dire ? Et puis tes tips ou en tout cas, les choses que tu vois autour de ça ? ### Context switching, fatigue et évolution du métier de product manager 38:19 Benoit explique que les product managers vivent déjà beaucoup de context switching, entre clients, stakeholders, développeurs, discovery et delivery. Il estime aussi que le métier demandera demain encore plus de temps pour comprendre le business, les utilisateurs et les analyses, tout en continuant à construire des choses. Terry ajoute que cette montée de la force de production peut aussi submerger les product people et les conduire à une logique d’épuisement. **Benoit:** Je vais sonner comme une machine, mais je le sens pas parce que j'ai l'impression d'être déjà dedans. Et donc, Je pense que d'une certaine manière, Les product managers sont déjà dedans. On est un métier qui est rempli de contexte. switching. On passe notre temps avec des clients, avec des stakeholders, avec des développeurs. Si on est en discovery, en delivery, Et souvent, on a des produits. Qui sont les deux, en fait, On fait du contexte switching tout le temps. Et donc, j'ai l'impression qu'on est déjà dans ce vortex-là, nous, en tant que métier. C'est vrai que je le vois plus chez les développeurs où on a cette impression qu'on change d'un produit. Un produit, là où on mettait trois mois à le développer, peut-être qu'on met une semaine maintenant. Donc, effectivement, Le contexte switching est important. En fait, Ce que je dirais déjà, c'est qu'il faut se rappeler que faire être Product manager aujourd'hui, mais ce sera encore plus vrai demain, Il faut avoir la passion et l'empathie pour le faire. C'est-à-dire que c'est un métier qu'il faut vraiment choisir avec précaution. Parce que ma conviction, c'est que demain, On va passer beaucoup plus de temps à comprendre son business. Comprendre ses utilisateurs, Donc on va passer beaucoup plus de temps à faire. Des analyses concurrentielles, à faire des analyses de marché, à parler à ses utilisateurs et utilisatrices, à parler aux supports clients, à parler à ses stakeholders business. Donc on va passer beaucoup plus de temps, Pas forcément en réunion, mais en interview d'utilisateurs, Donc il faut aimer ça. Si on n'aime pas, ça, à mon avis, en 2026, on parlait de 2030, Il ne faut pas faire ce métier, parce que ça va être un métier de contact très fort. Donc ça, c'est le premier point. Ensuite, il faut aimer, à mon avis, construire des choses. Et moi, j'adore ça. C'est presque une respiration intellectuelle pour moi quand je vibe code. C'est que je vois les trucs, se construire. J'ai pas l'impression de solliciter. J'ai dit à mon cerveau que je le sollicite forcément, mais en tout cas, c'est quelque chose d'assez reposant. Je suis un fan de l'ego, donc je pense que c'est aussi ça. Ça me repose aussi l'esprit, parce que je sais ce que je veux faire, je le vois se construire devant moi. Donc ça, C'est une forme de respiration. Et je crois que la question, Ça va être la vitesse dans laquelle on fait ce cycle. Est-ce qu'on fait des cycles de conception en une semaine, disant C'est que là, oui, Il va falloir se trouver des formes de respiration Est-ce qu'on fait ces cycles-là ? Dans des temps comme on fait aujourd'hui, entre quelques semaines et quelques mois. Donc, forcément, Je n'ai pas toutes les réponses, mais je dirais que si on aime ce qu'on fait, on va rester un métier avec beaucoup de context switching et beaucoup de travail. Mais je n'ai pas l'impression que ça va changer fondamentalement par rapport à aujourd'hui. C'est juste que les activités vont être un peu différentes. Par exemple, Je pense qu'on va passer moins de temps avec les développeurs, moins de temps peut-être à faire des tests aussi, parce qu'il y a des outils qui arrivent... Qui permet de faire du test de manière très, très, très, très efficace, que ce soit en front ou en back, d'ailleurs. Donc, je pense juste que notre métier va changer. Et si on l'aime, Je pense que ça va rester sous table. **Terry:** Intéressant. Après, peut-être pour un petit peu rebondir là-dessus, c'est vrai que toi, tu as eu des positions de leadership depuis plusieurs années. Donc, tu as aussi cette capacité. Tu es déjà habitué à piloter des personnes. Qui vont produire aussi pour toi et donc à avoir un petit peu cette force de frappe de plusieurs personnes qui peuvent produire pour toi. Et donc à avoir un niveau d'abtraction qui te permet de réfléchir. Justement. Non pas parfois d'avoir cette capacité à la fois de descendre dans le détail, mais aussi de prendre le recul et de gérer ça. Mon point, en fait, c'était vraiment de se dire qu'aujourd'hui pour reprendre l'exemple avec les développeurs, mais c'est en train de se déporter chez les product Managers. Un développeur hier Euh Enfin, Un développeur aujourd'hui peut produire, sans exagérer, avoir une productivité qui va faire x5. Ça veut dire que hier, si c'était un CTO qui manage. Les 5 développeurs, aujourd'hui, le développeur seul a l'équivalent de la force de frappe de son CTO d'hier. Pour autant, il n'a pas nécessairement les compétences que son CTO avait d'un point de vue, management. Et de savoir un petit peu. Justement, comment piloter? Cette force de frappe-là pour ne pas se cramer à vouloir tout comprendre ce que chacun de ces 5 devs faisait. Et donc, le développeur qui va piloter une suite d'agents qui vont lui donner cette force de frappe-là, peut se retrouver un petit peu submergé par cette capacité de production. Et mon point, c'est de dire que du coup, Cette force de frappe, en tant que contributeur individuel, est en train d'arriver au sein des product people. Et ceux qui n'ont pas justement ce recul-là peuvent commencer à tomber dans le travers de « Oh là là je produis tellement que j'ai du mal à tout contrôler, j'ai du mal... » Et tomber un petit peu après, dans une logique d'épuisement. Je le lis aussi, **Benoit:** je ne l'observe pas encore, mais je le lis aussi effectivement. ### Les leaders produit doivent garder un pied dans l’opérationnel 43:09 Benoit explique que les leaders produit ne doivent pas rester seulement des leaders, mais aussi être des contributeurs qui participent à la Roadmap et restent proches de l’opérationnel. Il insiste aussi sur le fait de ne pas « shipper » pour shipper, mais de se concentrer sur la valeur, le business et les interactions avec les utilisateurs et utilisatrices. Terry lui demande ensuite un dernier message à faire passer, et Benoit conclut en invitant à commencer à builder dès aujourd’hui. **Benoit:** J'ai une première réponse, c'est très vrai ce que tu dis sur ma position, mais ce qui me semble important, c'est que de 2026 vers 2030, Les leaders produits ne doivent pas rester que leaders, ils doivent être aussi individuels, contributeurs. C'est-à-dire qu'en fait, On a une forme de rôle modèle qu'on doit appliquer et tout le monde devrait... Participer à la Roadmap quelque part. Ça, c'est quelque chose de lequel je crois beaucoup, que j'ai fait beaucoup chez Luni, ma boîte précédente, et que j'ai essayé de faire là chez Believe, Même si je suis encore dans une phase de ramp-up, Ça fait que dix mois que je suis là. Mais c'est quelque chose de lequel je crois, parce que finalement, Comment on peut s'apercevoir de ce problème-là si on n'est pas dedans ? Donc ça, C'est la première réponse. Moi, je serais assez vigilant là-dessus. Mais je reviens à notre métier de product. C'est-à-dire que si on a une accélération telle que, finalement, on fait n'importe quoi, on va se planter. Donc, Shipper pour s'y shipper, si je reviens à ce qu'on a dit tout à l'heure, Et si on revient aux 30% uniquement de codes qui sont utilisés ou de features qui sont utilisés, Si on ne fait que shipper, on va augmenter ce que là, On va se retrouver pas plus avec 30%, mais avec 20%. Et ça, c'est dramatique. Parce que, malgré tout, on est dans un monde où... Chaque ligne de code qu'on fait coûte de l'argent, va coûter des tokens demain et va coûter du hosting aussi, parce qu'on n'est plus sur des serveurs unitaires, On est sur le cloud et donc tout ça va nous coûter très cher. Donc quelque part, Il va falloir remettre finalement ce qui fait la base du produit. C'est pour ça que je parle beaucoup de business, c'est-à-dire qu'est-ce qui va apporter de la valeur demain et de ne pas se lancer dans la construction de fonctionnels. À tout va, qui vont ne servir à rien et à personne. Donc peut-être que quelque part, une des réponses, parce que je ne l'ai pas. La réponse, bien évidemment, mais une des réponses, C'est d'avoir un produit très fort qui va nous permettre demain, de ne pas shipper n'importe quoi et de modérer l'accélération. En fournissant plus de trucs à valeur ajoutée, en remplaçant ces 70% qui ne servent à rien, à part des trucs qui servent à quelque chose, Mais pas accélérer pour accélérer, parce que ça n'a pas de sens. On risque juste de fournir des choses qui n'intéressent rien et personne. C'est ça aussi, notre problème. Donc, je n'ai pas forcément la réponse aujourd'hui, mais moi, Je pense qu'une des réponses possibles, c'est d'avoir un produit très fort, qui s'assure, qu'on chip des choses à forte valeur ajoutée. **Terry:** Donc, profiter de ce temps qu'on dégage pour aller encore plus réfléchir sur la valeur de ce qu'on produit et pas juste. Produire plus pour produire plus. **Benoit:** Le contrat que j'ai avec mes product managers qui entrent dans le programme ai native, c'est de se dire, Une ou un product manager ne devrait pas passer une journée sans avoir une interaction avec un utilisateur ou une utilisatrice. Et finalement, C'est un mantra assez simple que beaucoup de product dans la sphère product ne respectent pas parce qu'ils n'ont pas le temps. Quand on est dans des sphères de délivrerie, parce qu'il faut Shipper, absolument, parce qu'on avait dit qu'on shippait, Puis il faut faire des tests, etc. Parce qu'on n'a pas le temps. Là, justement, On a le temps parce qu'il y a plein de choses qu'on faisait, qui nous prenaient du temps, qui ne nous prennent plus de temps. Donc, passons du temps sur la partie très business, très utilisateur. Faisons jouer notre empathie naturelle et notre compréhension business pour faire en sorte qu'on shippe ce qui apporte de la valeur et qu'on aide nos entreprises à avoir plus d'impact, plus de chiffre d'affaires, moins de coûts. Et c'est ça où on nous attend demain. **Terry:** Yes, très clair. Avant d'aller vers mes questions de fin d'échange, est-ce qu'il y a un sujet en particulier, dont on n'a pas parlé ? Un point que tu voudrais aborder Un message à faire passer **Benoit:** Pour moi, je dirais que... Je vais redire ce que je dis tout à l'heure. Builder, quelque chose. Commencer quelque chose, mais pas la semaine prochaine. Faites-le aujourd'hui. Vous avez écouté ce podcast, ce soir, vous prenez un abonnement à Claude, ça coûte 20 euros, un abonnement à Lovable et buildez. Quelque chose, même quelque chose perso, juste une app web pour votre prochain voyage, une app pour faire ses courses, une app pour planifier les tâches ménagères dans le foyer, quelque chose de tout simple, Mais commencez ce process maintenant. Il n'est pas trop tard pour le faire, mais peut-être que bientôt, il sera trop tard. Donc voilà, les outils sont mûrs et je pense qu'il faut y aller maintenant. Donc mettez finalement votre savoir-faire product au service de vous-même et commencez à builder quelque chose. Et si vous avez du mal, allez sur LinkedIn et commencez à contacter des gens qui sont dans le produit qui parlent de ça. On vous répondra toujours Moi, je suis facile à trouver sur LinkedIn, m'envoyez un petit message, je vous répondrai, je vous aiderai. On est sur une communauté qui est quand même aujourd'hui extrêmement bienveillante. Et donc, vous n'avez plus d'excuses. Et moi, ce qui me fait peur aujourd'hui, et je le dis parce que j'ai l'impression d'être déjà dans ma. Troisième vie dans le produit en 15 ans, J'ai peur pour l'emploi des gens. J'ai peur que les gens qui ne se mettent pas à ces technologies-là, d'ici quelques années, n'arrivent plus à trouver du travail. Et ça, moi, ça me fait peur. Je suis père de famille. Et je pense que on a de la chance aussi en France, On a un écosystème tech qui est quand même assez développé. Donc, on est loin derrière les États-Unis, mais on est un des plus développés d'Europe. On a plein de choses à... On a plein d'atouts. Et donc il faut s'y mettre, il n'y a pas de fatalité. Et donc on a besoin d'aider cet écosystème tech, donc il faut s'y mettre vraiment maintenant. Et si vous avez le sentiment que c'est trop difficile, contactez-nous. Des gens dans le produit, des leaders produits, des gens qui parlent de généré. On vous répondra toujours, donc voilà complètement aligné avec ça. N'hésitez pas, du coup, à ### Commencer à builder aujourd’hui et nourrir sa veille produit 49:08 Terry introduit ses deux dernières questions de fin d’échange et demande à Benoit quelle conviction forte le met généralement en désaccord avec ses pairs. Benoit explique que les Chiefs Product officers doivent garder une part opérationnelle dans leur travail afin de comprendre ce à quoi sont confrontés les products et les développeurs. La discussion se termine sur ce qui nourrit Benoit intellectuellement au quotidien, notamment la lecture d’articles et de newsletters ainsi que les meet-ups. **Terry:** pinguer Benoit Pinguer. Aussi, Je fais partie de la communauté aussi des product Builders et complètement aligné avec ce que tu dis sur le fait d'aller construire des choses. Même des petits produits, justement, on a tous plein d'idées. Je pense que les gens n'en manquent pas. Donc allez-y si ce n'est pas déjà fait. Et donc pour aller maintenant vers mes deux dernières questions de fin d'échange, La première, c'est est-ce que tu as une conviction forte avec laquelle tu es en général en désaccord avec Tes Pairs **Benoit:** Il y en a une, mais elle est en train de tomber pour moi. Mais j'ai quand même à dire, c'est que pour moi, les leaders, en tout cas pour moi, Les Chiefs Product officers, doivent avoir une part de leur travail, qui est une part opérationnelle, donc être un peu individuel, contributeur aussi. Donc, c'est en train de tomber, parce que de plus en plus, on se pose la question de savoir être quoi? Un leader produit demain. Et il y a des gens même qui disent que j'y en aurai plus. C'est possible, puisque finalement, on sera toutes et tous, On pilotera des agents, peut-être demain. Mais en tout cas, pour moi, Il faut garder un pied dans l'opérationnel. C'est hyper important. Donc moi, par exemple, quand je fais le travail d'individu.el contributeur, ça me permet de regarder. L'état de nos API, l'état de nos documentations, l'état de certains process, comment je peux avoir des credentials, etc. Et ça, C'est fondamental parce que ça permet de vraiment voir à quoi sont confrontés nos products et nos développeurs. Donc ça, J'ai beaucoup de gens qui me disaient encore quelques mois, quelques années, que non, On n'a pas le temps et que notre rôle, ce n'est pas ça, et qu'on est payé relativement cher. Et ce n'est pas pour venir faire du code ou venir faire des fonctionnalités. Mais moi, Je pense que c'est un élément important pour savoir à quoi on expose nos équipes. Donc, je dirais ça. Très clair. Pour aller vers ma dernière question, du coup, quelles sont les choses qui te nourrissent intellectuellement ? Comment est-ce que tu progresses ? Alors, moi, je lis tous les jours des articles. Je suis abonné à toutes les newsletters de France et de Navarre sur le produit. Et je lis énormément de newsletters, quelques bouquins, parfois, mais surtout des newsletters. Pourquoi Encore une fois, c'est probablement ma troisième vie. Dans le produit, entre les product managers 1.0, qui étaient plutôt des experts métiers, les producteurs 2.0 qui se sont mis à faire vraiment de la conception, centrée, utilisateur. La Discovery est là, 3.0, On devient un peu product builder. Notre métier, il change. Et souvent, Ce que je dis aux gens, c'est que c'est un peu comme Builder quelque chose. Il faut lire et se documenter. Les articles, souvent, Ils prennent cinq minutes à lire. Et si jamais on ne lit pas, on ne se rend pas compte des changements qu'on a devant nous. Et moi, j'apprends encore énormément de choses. Donc ça, c'est le premier truc. Et le deuxième truc, c'est Il faut aller dans les meet-ups. On apprend énormément de choses dans les meet-ups. Moi, j'en fais encore plusieurs par mois. J'apprends énormément de choses. Ça fait 15 ans que je fais du produit. Donc, il faut vraiment faire ça. La lecture des articles et des meet-ups. **Terry:** Top. Merci en tout cas pour ton partage, Benoit. Et puis, Je mettrai le lien de ton LinkedIn pour que les gens n'hésitent pas à te contacter. Avec plaisir. **Benoit:** Merci, beaucoup.