Personal OS : ce qu’un product manager senior délègue à l’IA et ce qu’il refuse de lâcher, Lucas Cerdan

La claque ChatGPT et Cursor comme outil central dans la stack

Écouter à 03:46

Lucas raconte qu’avant ChatGPT, il ne suivait pas vraiment ce monde, même en travaillant déjà avec du machine learning et d’autres sujets technologiques. La première version de ChatGPT lui a donné une véritable claque et l’a rapidement amené à l’intégrer dans sa stack pour l’aider surtout à mieux communiquer en anglais. Puis Terry l’amène sur ses outils actuels, notamment Cursor et le modèle Opus 4.6, avant d’aborder les tâches qu’il a aujourd’hui augmentées ou optimisées grâce à ces nouvelles technos.

Lucas: Avant que Chatgpt sorte, j'avoue que je n'étais pas du tout dans ce monde. Même si j'étais dans le monde de la technologie, ce n'est pas quelque chose sur lequel je payais plus attention. Évidemment, je travaillais avec du ML ou des choses comme ça, mais le GNI, ce n'est pas quelque chose sur lequel je travaillais. Par contre, Quand j'ai vu la première version de ChatGPT, pour moi, c'était tout de suite, un peu la claque. incroyable. Ça fait partie des claques que j'ai prises en termes de tech, où je me suis dit qu'il y a un potentiel de fou. Je me suis trompé sur des choses comme la réalité virtuelle, mais bon, ça, c'est un autre sujet. Donc, c'est un outil, Tout de suite, je l'ai mis dans ma stack, Tout de suite, j'ai commencé à vouloir jouer avec et à comprendre un peu ce qui pouvait être fait. On va dire que depuis que c'est sorti, c'était principalement pour m'aider à mieux communiquer. Parce que mine de rien, quand on travaille 100% en anglais, qu'on a besoin de faire passer parfois des messages qui sont clairs, succincts et bien tournés, C'était un peu la force de LLM quand c'est sorti. Je travaillais un petit peu avec la partie custom GPT, mais que je ne trouvais pas incroyable. Mais par contre, là, en fin d'année 2025, quand on a commencé à voir du clôt de sortir, des nouveaux modèles, sortir, moi, J'étais en congé paternité, où je suis revenu ensuite en février. Du coup, 2026. Et là, je me suis dit non, ça, ça change tout parce que je voyais que tous les problèmes que j'avais pour faire passer ça à l'échelle, je voyais comment ça pouvait servir. Et c'est tout de suite un outil où je me suis dit Il faut que je m'y mette tout de suite maintenant. Et on peut rentrer plus dans les détails après.

Terry: Yes, donc allons-y. Donc, déjà, là, On a ces deux produits, donc Chatgpt et Cloud. Donc, déjà, toi, est-ce que tu as une préférence entre ces deux produits aujourd'hui, dans ton usage

Lucas: Je n'utilise que Cursor.

Terry: Ok, donc cursor qui est... Encore un autre produit, un environnement de développement intégré, un IDE. Donc, à la base, c'est plutôt destiné à un public de développeurs, Mais c'est en train d'atteindre plein d'autres fonctions, dont les fonctions produits, et qui est du coup agnostique du modèle sous-jacent. Donc tu vas pouvoir aussi bien utiliser les modèles fournis par OpenAI, donc la boîte de CGPT, que par Anthropic, la boîte de Cloud, ou que Mistral, que tes propres modèles.

Lucas: Et pour le coup, j'utilise principalement Opus 4.6, qui est le modèle d'Anthropic.

Terry: Ok, donc, si on rembobine un petit peu, donc cursor comme outil central dans ta stack, Quelles sont les tâches que tu as aujourd'hui? augmentées, optimisées ? Et si tu peux partir à chaque fois, peut-être avant d'aller sur comment ça marche, de USE, case, Tu parles du problème, et aussi dans un podcast product, Tu parles du problème et de comment tu as réussi à le résoudre tout ou partie grâce à ces nouvelles technos.

Lucas: Tout à fait.

Premier cas d’usage avec MCP, Granola et extraction automatique de tâches

Écouter à 06:21

Lucas explique qu’au départ il ne savait pas par où commencer et qu’il a construit des choses très basiques pour comprendre comment créer du contexte, travailler avec des fichiers et aborder la partie agent. Il décrit ensuite un premier cas d’usage avec le MCP et Granola, en récupérant automatiquement des transcriptions de réunions pour en extraire des to-do visibles dans Obsidian, dans un Kanban.

Lucas: Quand j'ai voulu approcher l'outil, je pense, comme beaucoup de gens, et même si je pense un peu moins vrai aujourd'hui, je ne savais pas par où commencer. Je ne comprenais pas forcément les possibilités. C'est vrai que ça peut être assez impressionnant. Quand on ouvre un cloud code, la première fois, on est devant un terminal. Quand on ouvre curseur, la première fois, on est devant un IDE qui est complètement vide. Par contre, Je suis arrivé avec des modèles mentaux qui m'ont vachement aidé. Et ce que je cherchais à faire, c'est un, Si j'avais un temps infini et que j'étais sur une tâche et que j'avais un temps infini. Qu'est-ce que je pourrais faire Aujourd'hui, ça n'a aucun sens. On est toujours en train de prioriser notre temps. Et je me suis dit, Par contre, un agent avec le bon contexte et un peu d'intelligence, est-ce Qu'il peut aller faire quelque chose pour moi, qui n'a aucun sens ? Il passait un temps infini, mais l'agent pourrait. Ça, c'est la première chose. La deuxième, c'était, Sur quoi est-ce que je suis très mauvais en tant que PM Et en quoi est-ce que ça peut m'aider à m'aider, à me coacher ou à faire les choses mieux que moi ou à combler les gaps. Quand moi, je n'y pense pas ? Et je suis vraiment arrivé avec ces deux angles-là, et je me suis dit, ok, commençons, voyons ce que ça peut faire. Et j'ai construit des choses très, très, très basiques au début, Mais c'était vraiment pour comprendre comment ça fonctionne, qu'est-ce que ça veut dire, créer du contexte, qu'est-ce que ça veut dire. Travailler avec des fichiers, et ensuite la partie agent. Et j'ai exploré, j'ai commencé, ça a fait boule de neige, Parce que c'est une grande nombre des choses qui, quand tout commence à s'emboîter ensemble, C'est là que la puissance, l'outil arrive.

Terry: Tu peux donner des exemples de petites choses que tu as créées, justement, au début, pour t'approprier un peu

Lucas: La première chose que je voulais créer, c'est cette notion de MCP, Commencer à connecter des outils. Parce que je travaillais déjà dans le chat GPT, il y avait des Custom GPT, Mais la manière dont je travaillais, c'est qu'on prenait des fichiers, on les droppait, on les mettait dans des projets. Ensuite, il fallait les mettre à jour. Et je me suis dit, tiens, Ce côté MCP, qui est capable d'aller le récupérer automatiquement, c'est intéressant. La première chose que j'ai fait, c'était, J'utilise toujours Granola, qui est un super outil pour les transcriptions de meetings. Et je me suis dit, tiens, est-ce que je peux... Je peux commencer à les récupérer automatiquement et avoir ensuite un petit agent qui va m'extraire. Mes to-do. Hyper basique, pas super intéressant, Mais ça m'a mis en place de, OK, j'ai un MCP, je récupère des fichiers, Mon contexte est capable de le comprendre, Ensuite, je vais développer un skill qui va ensuite me créer des to-do que je peux voir dans Obsidian, dans un Kanban.

Terry: OK, donc hyper intéressant. On va faire une première pause, parce que là, t'as... Partagé pas mal de concepts et en fonction du niveau d'adoption et de maturité sur la prise en main de ces nouveaux outils, Ça peut être plus ou moins clair. Au début, Ce que tu disais là, c'est que tu avais commencé déjà à explorer. Le potentiel des projets, donc des custom GPT, qui sont un peu des assistants où tu mets un système prompt. Et puis tu peux poser des questions et pas à chaque fois... Avoir à réécrire ton système prompt. Et donc tu généralises un peu un boutage typiquement, tu veux qu'il te résume une réunion, tu veux qu'à chaque fois, la manière dont la réunion est résumée soit toujours la même. Et que, peu importe le compte-rendu de réunion que tu lui envoies, il te sorte derrière un résumé qui est une même structure, Tu vas écrire un système prompt qui te permet d'avoir ça et tu vas le packager dans un custom GPT. Et ça va te permettre de sortir à chaque fois. Un même format de compte-rendu, peu importe le transcript que tu lui donnes. Ça, c'est l'imitation, notamment en termes d'intégration. Bout en bout pour Alors... Parce que tu es obligé de faire des actions. manuelles, de drop de tes fichiers. Tu as les projets dont tu as parlé, qui est encore une extension où tu vas pouvoir mettre du coup aussi du contexte, enfin un système prompt au niveau de ton projet pour lui donner une manière de se comporter. Mais surtout, Tu vas pouvoir attacher des fichiers à ton projet, qui va faire en sorte qu'à chaque fois que tu poses des questions dans ton projet, il va aller utiliser ces fichiers comme élément de contexte. Et donc pouvoir te répondre de manière plus pertinente par rapport à un contexte qui lui est donné. Mais toujours pareil, là, Il faut que les fichiers, tu les mettes à la main. Et du coup, tu as cette logique de flow de bout en bout, c'est plus compliqué de faire des automations de bout en bout, et ça, c'est très 2025 maintenant. Oui, après les projets, Moi, je trouve que les projets ont quand même beaucoup de valeur, notamment quand tu veux travailler sur des contextes spécifiques, tu vois. C'est une manière de créer indirectement si tu veux faire un petit ux repository pour travailler du coup sur des bases d'interviews utilisateurs, je trouve que ça peut être intéressant en fonction du niveau aussi de maturité technique des utilisateurs, mais, mais... Donc, si je continue le fil, du coup, par rapport à ce que tu as décrit et aux terminologies que tu as employées. Ensuite, tu as parlé du MCP. Le MCP, c'est une manière d'interagir entre des systèmes agentiques. Donc, pour caricaturer la chose, C'est la version 2026 des API qui va permettre aux agents de communiquer entre eux. Et donc là, pour le coup, Quand tu as un système de génération de transcripts, donc tu as parlé de Granola, qui va automatiquement transcrire tes réunions. Qui va offrir un MCP avec un autre système qui lui va prendre ton transcript et en faire un compte-rendu, Tu vas pouvoir connecter ton granola avec ton autre système qui va faire ton résumé de réunion au travers du MCP. Donc, là, ça te permet de connecter les choses ensemble sans avoir à faire des actions manuelles.

Lucas: Tout à fait.

Terry: Donc, là, c'était pour revenir un peu sur cette terminologie technique. Et ensuite... T'es parti, t'as parlé d'Obsidian, Il me semble. Donc, si tu veux juste continuer. Le film...

Skills, Obsidian et mise en place d’une to-do list Kanban depuis les transcripts

Écouter à 11:28

Lucas explique qu’il a créé son premier skill pour extraire des tâches depuis un transcript et générer un fichier Markdown dans Obsidian avec une vue Kanban. Terry précise ensuite que les Skills sont une évolution du système prompt, pouvant aller jusqu’à intégrer des fonctions ou du code, tout en résumant ce premier cas d’usage autour des réunions et des tâches à suivre.

Lucas: J'ai créé mon premier skill, qui était un premier Skill to-do, parce que je voulais chercher à comprendre comment ça fonctionnait. Le skill, c'est vraiment quelque chose de réutilisable, presque un simstem prompt, Mais c'est vraiment une tâche que je vais vouloir répéter. Et dans ce cas-là, c'était sur un transcript, qu'est-ce que l'agent peut m'extraire comme tâche, des choses que moi, j'ai à faire, et ça me crée. Un autre fichier, Markdown, Obsidian, et ensuite un éditeur. Qui permet aussi de voir les fichiers. Markdown, mais qui? A une vue Kanban qui m'intéressait. Et donc, en fait, C'est comme ça que j'ai commencé à créer. Ma to-do List Kanban, visualisable directement depuis des transcripts.

Terry: Yes. Donc, effectivement, Le dernier point, c'était les Skills qui ont été introduits par Claude, entre autres, et qui sont effectivement l'évolution du système. prompt, du custom GPT, augmentée. Parce que c'est pas juste un fichier Markdown. Tu peux avoir aussi derrière des fonctions qui peuvent être appelées. Tu peux avoir des bouts de script python dans ton skill. Tu peux avoir... Ça permet d'augmenter un pur système prompt, Mais tu peux avoir juste des six skills qui sont quasiment l'équivalent d'un simple système prompt, Ça dépend de la complexité, de ton skill. Et donc, derrière, tu as créé tes propres skills pour générer tes comptes transuits de réunion, Et tu utilises un outil qui te permet de visualiser ça sur une vue qu'en banc, qui est Obsidian. Donc, premier use case, au final, Il y a beaucoup de termes techniques, etc. Pour résumer, des réunions de manière automatique.

Lucas: Et avoir une tâche qui je peux visualiser.

Terry: Et avoir une tâche derrière qui t'est préenregistrée.

Lucas: Encore une fois, pas très intéressant, mais pour moi, c'était le but, C'est de mettre la main à la pâte et voir un peu le workflow, connecter des outils, les récupérer, travailler ensuite en local, ensuite en extraire une intelligence. Ensuite, Il y a une partie dont je n'ai pas parlé, mais c'est comment est-ce que ça, Je l'automatise ou en tout cas, Je le mets sur des... Tiens, ce qui est du lent français, s'il te plaît.

Terry: Sur des ordonnanceurs.

Lucas: Ouais, voilà. Il tournait tous les jours, tout le début du matin. Pour être sûr que mes tâches soient à jour et que les choses que j'ai discutées la veille, j'en garde une trace.

Terry: Yes, ok. Et donc déjà, par rapport à ce premier use case, tu le dis, Il peut paraître simple, mais en fait, en soi, Ça peut faire vraiment gagner beaucoup de temps parce que quand on est dans des boîtes... Les profils des C-Level, on va dire, Ils ont l'habitude d'avoir dans les grandes organisations des personal assistants qui font ce travail pour eux, justement, prendre les notes, hop, d'en extraire des trucs importants à faire, aider à Booker, sur l'agenda, etc. Là, en fait, On n'est pas arrivé au booking sur l'agenda, mais la création tout doux, extraite par rapport à un meeting, Ça fait quand même gagner un temps fou. Au final.

Pourquoi le contexte change tout pour un assistant de type personal assistant

Écouter à 13:55

Lucas explique qu’un personal assistant devient beaucoup plus utile quand il dispose du contexte de la personne, de son rôle, des réunions et des personnes impliquées, alors qu’en isolation la même fonction paraît peu impressionnante. Il détaille aussi comment il a construit ce contexte en précisant qui il était, sur quoi il travaillait et en identifiant ses stakeholders, ce qui améliore nettement la compréhension du LLM. Terry rebondit ensuite sur les résultats, notamment l’extraction des to-do et la manière dont ce contexte est injecté dans la chaîne, avant de demander à Lucas comment il le donne concrètement au système.

Lucas: Mais tu vois, Ce qui est intéressant, c'est que tu parles d'un personal assistant et ce personal assistant, aujourd'hui, Ça va leur ajouter ce qu'il a à ton contexte. Il sait à qui tu parles, Il sait quel était le type de réunion. Et en fait, C'est l'autre côté sur lequel j'arrive. En isolation, Ce que je viens de décrire, ce n'est pas très impressionnant. Mais une fois qu'on commence à regarder ce qui va être construit à côté, j'ai commencé à construire mon contexte. J'expliquais qui j'étais, j'expliquais sur quoi je travaillais. J'ai créé un autre skill, on peut en revenir dessus, qui me permettait d'identifier mes stakeholders. Dans une boîte de 6000 personnes, moi, C'était une de mes plus grosses difficultés. Et en fait, à partir du moment où je reçois un transcript. Et il y a Andri et Lucas qui parlent, un LLM tout seul en isolation, Il n'y a pas 30 000 choses ou 30 000... Ce n'est pas miraculeux. Par contre, s'il sait qu'Henry, c'est mon IM et qu'on est en train de parler d'un projet, qu'il a le contexte de mon projet, il sait que je suis product Manager, Il sait qu'il est Engineering Manager et qu'on discute de certaines choses, en fait, Ma tout doux ou la compréhension du LLM va être bien meilleure. Et c'est ce qu'est capable de faire un personal assistant humain aujourd'hui, des six Levels dont tu parlais, C'est cette gestion du contexte.

Terry: Yes, hyper intéressant. Et d'ailleurs, petit teaser, J'ai des épisodes à venir sur la notion pure de context engineering, qui est aussi, du coup, un sujet hyper intéressant par rapport à ça. Pour revenir déjà sur ce premier USE, case, tes résultats, toi, qu'est-ce que tu as eu du coup, comme résultat, notamment sur la partie extraction de todo Parce que ça, je trouve que c'est quelque chose qui peut être un peu touchy, où tu te dis, Si il loupe des todo sur lesquels je me suis vraiment engagé, ça peut la foutre mal derrière. Tu m'inventes des trucs. Après moi, j'ai une charge de... Au final mental, à devoir prier sur les choses qu'il m'a dit, qui sont fausses, Donc. En fait, tu passes plus de temps à vérifier que d'avoir l'automatisation. Donc, quelles ont été un peu les performances que tu as eues

Lucas: Il y a certaines tâches, mais c'est très minoritaire. Ou peut-être que c'était pas à moi de le faire. Ou en fait, plus tard, dans la Réunion, on s'est mis d'accord que j'allais pas le faire ou que c'est quelqu'un d'autre qui s'en occupait, C'est très minoritaire, la grosse majorité. Et on parlait des choses où j'étais pas forcément bonne, Il y a plein de petites tâches EUH, sur lesquels j'oubliais de follow-up. Parce que, tiens, je t'enverrai un document, tiens, Il faut que j'envoie ce message à cela, qu'à telle personne. Au contraire, c'était plus, ah, ok, hyper intéressant, J'avais oublié de le faire, et puis, hop, je peux dérouler la to-do. Et c'est un peu ce côté, Lucas fait ce qu'il a dit. C'est quelque chose qui est assez important, au final, dans le ministère du Produit, qui permettait d'être beaucoup plus complet dans...

Terry: Yes, hyper intéressant. Et donc, sur cette... Premier use case, Donc on a déroulé un petit peu. Les outils que tu as utilisés, tu parlais donc de l'importance du contexte, à quel moment? Dans cette chaîne, tu lui donnes justement le contexte de ton entreprise, des gens avec lesquels tu travailles et comment tu le fais ?

Lucas: Tout à fait.

Créer des fichiers de contexte avec agent.md et la mémoire des stakeholders

Écouter à 16:39

Lucas explique comment il a commencé à créer du contexte avec un agent.md, puis avec d’autres fichiers Markdown sur l’entreprise, sur ce que l’outil sait de lui, et sur sa façon de travailler et de communiquer. Il raconte aussi qu’il est allé voir ChatGPT pour lui demander ce qu’il savait de lui, afin de trier les réponses et commencer à construire son contexte. Ensuite, Lucas décrit la création de fichiers de stakeholders et l’ajout de retours clients, pendant que Terry résume qu’il s’agit d’écrire du texte pour faire vivre ce contexte au fil de l’usage.

Lucas: Peut-être quelque chose que je vais mentionner, c'est tout ce dont on parle là, c'est littéralement la première semaine où je prends l'outil en main. C'est vraiment quelque chose que vous pouvez faire rapidement, mettre en place. Et j'ai fait cette partie outillage. Mais l'autre partie que j'ai fait en parallèle, c'était comment je vais créer du contexte Et il y avait déjà pas mal d'aides en ligne qui faisaient, Il y a un fameux cloud MD quand on vous travaille dans Cloud. Dans le cas de Cursor, c'est un agent.md. Donc, dans mon agent.md, j'expliquais qui j'étais. Et ensuite, Je vais aller créer d'autres fichiers. Markdown. Un, sur quelle est l'entreprise ? Deux, qu'est-ce qu'elle sait sur moi Trois, comment j'aime travailler Comment j'aime communiquer Et peut-être Ce qui est intéressant, c'est que je travaillais beaucoup sur Chatgpt avant. Je ne l'ai pas écrit manuellement. Je suis allé voir ChatGPT, je lui ai fait « qu'est-ce que tu sais de moi ? Quel est mon style ? Sur quoi? D'habitude, je te reprends ? » J'ai déjà travaillé plusieurs mois, années dans un outil. Qu'est-ce que la mémoire de cet outil est capable de me dire Et ensuite, J'ai regardé, j'ai fait le tri, et c'est comme ça que j'ai commencé à créer mon contexte. Et au final, c'est plus en cours d'utilisation, quand je vois un résultat ou quand je parle avec cet agent dans Cursor, « Ah tiens, là, il s'est planté. Pourquoi ? » Ou alors, ce n'était pas très pertinent. Pourquoi Qu'est-ce que j'ai besoin de rajouter Donc, ce n'est pas quelque chose où vous vous dites, tiens, Je vais me bloquer une semaine et je ne vais faire que ça. Non, commencez par un use case, une chose, Apportez votre contexte assez basique. Et ensuite, quand vous travaillez, comme si vous étiez avec un humain, Pourquoi est-ce qu'il s'est planté quand il m'a répondu Il faut que je t'explique quelque chose. Le « je t'explique » , c'est juste, je vais l'ajouter au contexte.

Terry: C'est ça. Et donc, hyper intéressant. Et on parle bien, comme tu le ferais à un humain d'expliquer, donc là, d'écrire, on peut... Tu as parlé du fichier Agent.md ou Cloud.md. C'est ni plus, ni moins que des fichiers où on écrit du texte. En format Tmarkdown, qui est un format assez simple à prendre en main une fois qu'on prend les deux, trois structures importantes. Enfin, des choses qui permettent de structurer la page et donc l'expliquer, comme on le ferait effectivement en humain. Donc, il n'y a rien pour le coup de très technique Lucas Cerdan si ce n'est de connaître le contexte dans lequel on évolue et de voir justement comment l'IA répond par rapport à des questions qu'on lui pose et ensuite adapter se dire elle n'a pas assez de contexte sur ça ou voilà et donc faire vivre au final ce contexte-là. Hyper intéressant. Donc, là, c'était le premier Use. case, donc en l'espace d'une semaine, que tu as réussi à déployer en prod pour toi et avoir des premiers résultats intéressants. Ensuite, Quel a été du coup ? J'imagine déjà après ça, tu t'es dit... Un peu Waouh, quoi. Ouais,

Lucas: non, c'est tout de suite, J'ai vu la puissance de l'outil parce que si je refais la comparaison avec ce que j'utilisais avant, il y avait la partie projet, Mais si j'avais besoin de Skill, qui était l'équivalent des Custom GPT, en fait, le Custom GPT ne peut pas être lancé dans le projet, Si je me souviens bien. Et donc, J'avais vraiment une perte de contexte, je n'avais pas un contexte global qui était bien structuré. Et donc, je me suis dit tiens, je vais commencer à structurer mon contexte, la façon dont j'aime parler, et notamment, Je disais sur quoi est-ce que je suis très nul ? Je suis assez transparent. Très mauvais pour me souvenir des gens. Et quand on travaille dans une boîte de 6000 personnes sur des projets, il va y avoir des sales, des CSM, des SI, d'autres ingénieurs qui vont venir, qui vont poser des questions. Et puis, trois mois après, on s'est dit, tiens, Il y avait un client qui voulait quelque chose, mais je ne me souviens plus qui travaillait dessus. Et en fait, J'ai délégué toute cette partie de charge mentale. Je sais que je ne vais pas être très bon. Je sais que ça va me prendre de la recherche. Et en fait, J'ai commencé à créer des skills qui me permettaient de me dire Tiens, il y a quelque chose d'intéressant qui m'a été dit. Je vais prendre un screenshot ou je vais faire un copier-coller et je vais le mettre dans un skill. Et je vais dire à l'agent, tu t'en souviens. Donc, ça m'a commencé à me créer des fichiers. stakeholder, donc pour MD. Ça a commencé à me créer des fichiers. Quels sont les clients qui ont été intéressés par tes projets ? Pourquoi J'ai commencé à regarder du Feedback client que je commençais à lui Feed pour qu'il s'en souvienne. Et en fait, Tout ça, ça fait vraiment un effet. Boule de neige.

Terry: Donc, là, je te laisse continuer juste après. Ce que tu dis, c'est que tu as créé des skills qui te permettaient d'accélérer ton extraction de contexte. Pour pouvoir ensuite aller mettre ce contexte au bon endroit pertinent.

Lucas: Juste commencer à construire du contexte, Toutes les choses dont je ne voulais pas me souvenir ou que je voulais que lui s'en souvienne et pas moi. Le principal intérêt, peut-être que j'ai oublié de le dire, c'est que quand je vais commencer une nouvelle discussion avec un agent, je n'ai pas besoin de leur expliquer. Et l'idée entière, c'est J'ai quelque chose à faire, j'ai quelque chose dans la tête, je vais le taper, Il va comprendre tout mon contexte. Ou alors, s'il n'a pas l'info, il saura où aller la chercher. C'est ça pour moi, l'énorme force du personnel os dont on parle. C'est mon espace de travail, il connaît mon contexte, qui je suis, Dans quelle boîte je suis. Et s'il a besoin d'informations, il sait où aller.

Terry: Yes. Donc, ce que tu dis, c'est l'extraction de contexte. Tu fais de l'extraction de contexte comme ça. Donc, après, tu es allé vers, au fur et à mesure, Tu alimentes ton contexte de manière la plus fournie, possible. Tu es allé ensuite chercher... Quelle autre automatisation ou quelle autre augmentation ?

Lever les barrières d’accès aux outils internes et connecter Confluence, CLI et données feedback

Écouter à 21:27

Lucas explique qu’à la fin février, son entreprise a supprimé beaucoup de barrières d’accès, avec des équipes BizApps prêtes à mettre en place les accès nécessaires quand un agent n’avait pas l’information requise. Il décrit ensuite comment Confluence, des outils en CLI et d’autres outils internes ont été connectés à son environnement, ce qui lui a évité des recherches manuelles et lui a permis d’aller chercher le contexte plus vite. Terry revient aussi sur la question du contrôle et des autorisations, alors que Lucas précise que l’accès reste cadré par les droits déjà en place et par les pipelines internes de données feedback et client.

Lucas: Je pense que là, Il faut faire un petit check-in sur la situation. On arrive à fin février et à ce moment-là, dans mon entreprise, vraiment, tout le leadership se rend compte que, ok, Le monde a changé et il faut qu'on change la façon dont on travaille. On ne sait pas encore à quoi ça va ressembler, Mais on sait qu'il faut que tout le monde commence à travailler de cette nouvelle façon où il est capable de le faire. Et ce qui était intéressant à ce moment-là, et que je n'ai pas vu dans beaucoup d'entreprises, c'est qu'ils nous ont vraiment enlevé toutes les barrières qu'on pouvait avoir. Ça veut dire qu'à ce moment-là, Ils ont mis des équipes BizApps, et à chaque fois qu'ils nous ont dit en tant que PM, Si vous travaillez sur quelque chose et votre agent n'a pas accès à l'information, vous nous le dites et on le met en place. Et en fait, ça, ça a été vraiment un timing parfait pour moi, parce que, du coup... Je pouvais avoir accès à mon confluence automatiquement. L'accès avait été fait, Je n'ai pas besoin de chercher, à comprendre comment je vais demander. Des accès à certaines personnes dans la sécurité, qui doivent ensuite revoir une autre intégration, ce genre de choses. Tout mon contexte et les outils sur lesquels on travaille au quotidien d'un coup ont été connectés à mon personnel. OS. Et on en parlait un tout petit peu au début, L'idée, ce n'est pas que de parler aux IC aujourd'hui, mais d'un point de vue, leadership. Ce qui était intéressant, c'est qu'ils n'ont pas été prescripteurs. En voilà comment vous devez utiliser les choses. Par contre, Ils nous ont enlevé toutes les barrières. Et à partir du moment où toutes les barrières sont tombées, j'avais accès à différents MCP. On peut parler aussi de CLI, qui sont des outils de terminal. Oui,

Terry: des command lines. Des command lines, Je ne sais pas comment dire en français,

Lucas: désolé.

Terry: Des outils dans le terminal.

Lucas: Dans le terminal. Tout ça, ça a commencé à me dire, tiens, c'est intéressant, Maintenant que j'ai besoin de faire quelque chose, soit j'ai le contexte en local, soit mon agent sait où aller le chercher. Parce que des fois, généralement, ce qu'un local, c'est ce qui me concerne. Mais si j'ai une question sur comment fonctionnent certaines choses dans la boîte, il est capable d'aller le chercher par lui-même bien plus rapidement que moi. Et ça m'évite d'avoir à faire des recherches, Je ne fais plus de recherches dans un outil individuel.

Terry: Et là, du coup, l'interconnexion entre tous les outils, Donc tu as parlé de Confluence, Il y a plein d'autres outils. Après que vous avez, j'imagine, en place dans la boîte. Ça passait principalement du coup, par des MCP, Donc ces outils-là exposaient leur MCP. Ou il y avait aussi d'autres connecteurs que tu as pu utiliser

Lucas: On a un peu de tout. On a des outils qui sont du MCP, on a des outils qui sont en CLI. Je pourrais parler de Google Workspace Cli, que j'utilise pas mal. Et on a aussi des... On a mis pas mal de choses en commun pour tout ce qui est un peu feedback, client, point de vue, PM, qui sont ensuite des outils en Python, augmentés par des skills, où on a tout le pipeline qui a été fait et écrit par des gens qui s'y connaissent bien.

Terry: Ok, donc des choses un peu custom, aussi. Oui,

Lucas: on a pas mal de choses. Custom aujourd'hui. On est capable d'avoir un MCP interne. Qui est. Quel est le Feedback client sur tel sujet. En fait, on a déjà toutes les choses en place, qu'il va aller chercher dans... Différentes bases, qui a déjà analysé pas mal de choses et qui permet d'aller beaucoup plus vite.

Terry: Donc, avant de continuer et d'aller voir du coup, ce que ça a permis de débloquer, comme Use case, Premier point que je trouvais hyper intéressant, la position du leadership par rapport à ça, de vous dire en fait, allez-y, Vous nous dites ce dont vous avez besoin. Et, en fait, on est là pour faciliter le truc et vous aider à avoir accès à ce dont vous avez besoin et faites pour apprendre. Et vous êtes les meilleurs placés pour savoir quoi faire. Ça, je trouve ça génial, par contre, du coup, si je me mets aussi dans la... Position des leaders à ce niveau-là, qui doivent quand même se dire d'un point de vue. Données qui font aussi la force de l'entreprise, qui sont un peu le... Enfin, Moi, je le répète sur beaucoup d'épisodes et au XXIe siècle, l'or numérique, c'est la donnée. Et on voit aujourd'hui, même les fournisseurs de frontières modèles, type, du coup, Anthropic, OpenAI, Ils se battent maintenant pour réussir à entraîner aussi de manière très spécifique, des... Ou, en tout cas, avoir accès à des experts sur des domaines métiers très spécifiques, puisque maintenant qu'ils ont aspiré tout Internet, il va falloir spécialiser des choses. Et donc, la donnée propriétaire d'une entreprise qui est structurée reste une mine d'or dans cette ère de l'IA. Et donc quand tu commences à ouvrir toutes les portes et notamment à te connecter sur des API tierces type Anthropic, type OpenAI, ta donnée potentiellement, tu l'envoies chez eux.

Lucas: Sauf qu'aujourd'hui, C'est quoi le Shadow ai C'est qu'au final, Les gens faisaient des exports CSV parce qu'ils ont besoin de travailler sur cette donnée. Cette donnée est utile dans le quotidien et elle va finir par se retrouver de toute manière dans ces outils. Donc, autant avoir le contrôle sur le pipeline, sur ce qui est autorisé. Et si la donnée sert, que les gens ont besoin de s'en servir? Et pour créer de la valeur, créons de la valeur. Yes.

Terry: Là-dessus, Je te rejoins sur le fait qu'effectivement, de toute façon, mettre juste des... Des murs, ça n'empêche pas le Shadow E.T., Le Shadow ia maintenant. Pour autant, entre ça et complètement ouvrir les portes et dire allez-y, en fait, Il y a un entre deux, Je me dis, et je me pose, en fait, La question vient sur quelle a été la réflexion, Tu vois, au niveau du leadership sur ça. C'est-à-dire, j'entends du coup ce côté, se dire de toute façon si nos collaborateurs veulent utiliser ces outils, ils le feront, mais entre le moment où ils disent vas-y, on ouvre un peu tout, et derrière... Comment est-ce qu'on contrôle, ce qu'on envoie ou pas ? Est-ce qu'il y a eu une réflexion là-dessus ? Ou est-ce qu'au final, Ils se sont dit, en fait, L'enjeu est tellement énorme qu'on se posera la question après

Lucas: Je ne veux pas donner l'impression que c'est open bar dans le sens où j'ai accès à tout dans l'entreprise, Mais au sein des propres outils, il y avait déjà pas mal de sécurité, de rôle. Et en fait, L'agent qui va chercher de la donnée ne fait rien d'autre qu'utiliser, en gros, Mon identité pour aller la chercher. Donc, ce n'est pas comme si j'allais soudainement avoir accès... À des données RH auxquelles je ne suis pas censé avoir ou des données financières que je ne suis pas censé avoir. C'est purement mon utilisation. Et ils ont automatisé cette connexion entre mon agent et la donnée auxquelles j'ai déjà le droit d'avoir d'accès.

Terry: Donc, Il y a déjà la couche d'autorisation qui était gérée par tous les collaborateurs. Et c'est sur cette couche-là sur laquelle ils s'appuient.

Lucas: Je ne suis pas en train de dire que c'est open bar, Tout le monde a accès à toutes les données. Mais au contraire, c'est les données qui étaient déjà bien structurées, sécurisées. On est dans une entreprise où on a pas mal de certifications, on a une entreprise en bourse, On a des clients qui sont dans des domaines sensibles, donc on a déjà pas mal de contraintes, Ces contraintes étaient déjà en place. La seule chose dont je parle qu'on a automatisé, c'était si votre agent dans lequel vous travaillez, qui est un cloud code, qui est un curseur, a besoin d'accès à cette donnée de manière automatisée pour que vous n'ayez pas à faire des choses manuellement, Tout ça, c'était cette complexité interlevée pour moi.

Terry: Très clair, parce que ça, pour le coup, c'est la complicité après plus interne, effectivement. Et du coup, vous avez réussi à...

Lucas: C'est ça. Aujourd'hui, comment ça se passait ? Et pour moi, c'était vraiment... Je n'imaginais pas que notre leadership allait faire ça. Mais sinon, c'était, tiens, je suis telle personne, j'ai essayé ce case. Voilà pourquoi je vais avoir une clé d'API pour me connecter à cette donnée, qui doit être vue par une équipe sécurité. Ça prenait trop long. C'est trop long, c'est trop long pour tout le monde. Et là, au contraire, On sait que vous y avez accès, on sait que ça marche comme ça. Il y a du contrôle.

Terry: Très clair. Donc, une fois qu'il y a eu un peu, ce déblocage complet sur la connexion à ces outils de manière automatique, Quels sont les autres cas d'usage que tu as pu mettre en place, avec quelle rapidité aussi et quel résultat

Le code rouge interne et la détection des synergies entre projets

Écouter à 28:59

Lucas explique qu’après un code rouge interne, l’équipe a centralisé ses plans, visions et roadmaps dans un repository Github commun. Il raconte ensuite qu’un skill capable de parcourir les fichiers ajoutés chaque semaine lui a remonté dès le premier jour deux projets dont il n’avait jamais entendu parler, tandis que Terry souligne l’intérêt de ce type de détection dans une très grande entreprise.

Lucas: Tout s'est passé ultra rapidement. Après cette mise en place, on a eu un code rouge, ce qu'on appelle un code rouge dans les entreprises américaines. C'est notamment connu quand Chatgpt est sorti, Google a lancé un code rouge et globalement, On arrête tout ce qu'on fait, c'est un risque existentiel et on reparle de ce qu'on veut faire. Nous, on avait un code rouge de manière plus interne, de comment est-ce qu'on travaille. Et notamment une des choses qu'on est sorti, c'est qu'aujourd'hui, on a un peu cette idée de compagnie. OS, où toutes les équipes produisent, travaille dans un repository Github commun où on va aller. Ajouter les plans des choses sur lesquelles on travaille, les choses à laquelle on pense, les visions, nos roadmaps, dans un endroit un peu centralisé. Et un des USE cases qui a été assez cool pour moi, donc j'expliquais que j'étais sur la partie. plateforme, Donc parfois, mes clients sont des gens en interne, J'ai commencé à faire tourner un skill qui fait, donc je ne sais même plus combien on est dans l'équipe. produit, Et je me suis dit tiens, va voir tous les fichiers qui sont ajoutés chaque semaine, Tu connais tout mon contexte, tu sais les choses sur lesquelles je bosse, T'as accès à des fichiers où je dump mes idées potentielles. Et va voir ce qui peut être une synergie, un conflit, une utilisation. Et ça, le Day One. Le premier jour où je l'ai fait tourner, ça m'a sorti deux projets dont j'avais jamais entendu parler, dont j'aurais jamais entendu parler. Sauf peut-être 3-4 Mois plus tard, il m'a dit tiens, il y a cette personne qui bosse sur quelque chose, ça a l'air assez similaire à ce que tu fais. Ou alors, Ils sont en train de reconstruire quelque chose et ils ne savent pas que toi, Tu as déjà construit un outil qu'il va falloir faire gagner trois semaines. Et ça, ça a été un effet waouh. Ça, je n'aurais jamais pu le faire avant.

Terry: Oui, parce que là, pour le coup, C'est vrai que dans des situations d'entreprise comme ça. Très grande, où en fait, Tu ne peux pas avoir le contexte de tout le monde et sinon, Tu passes ton temps à regarder ce que font les autres. Donc, tu ne peux pas. Donc ça, c'est quand même hyper intéressant. Moi, ça me permet du coup de rebondir là et de sortir un peu de ce contexte là. Grande entreprise, vu que t'as un parcours où t'as commencé aussi à des équipes de 30 personnes. Enfin, des boîtes de 30 personnes. Comment est-ce que tu portes ça? Parce que là, je pourrais me dire OK, génial, mais moi, je suis dans une boîte où il y a 30 personnes au produit, on est 5 en...

Lucas: Tu connais tout le monde, tu connais tous les projets. Dans ce cas là, c'est pas un skill. Ce Use Case n'a aucun sens pour toi. Par contre, là, aujourd'hui où je me sers de mon personnel OS, c'est la capacité d'exécution. Donc il y a ma capacité d'exécution personnelle et un exemple que j'aime bien donner, que j'ai fait à peu près. Il y a 3 semaines. Donc, on a parlé de ce fameux pipeline où je suis dans un meeting, Je vais avoir un agent qui va regarder un transcript, qui va regarder les tâches qu'il mettait à signer, qui va les ajouter dans Ma to-do. Depuis, j'ai aussi des agents qui tournent, qui vont regarder les to-do et qui vont essayer de les faire pour moi. Et notamment, Un viscage que j'avais, j'étais dans un call avec un sales, et ça, qu'importe la taille, Il peut y avoir des sales dans du B2B SAAS, en tout cas. Il est venu, Il me fait que j'ai un call avec un client dans une heure et demie. Je viens de voir ton nouveau produit. J'ai vu une page, je ne sais plus. Bref, est-ce que tu peux me faire un slide deck pour que je lui présente Moi, je ne pouvais pas venir en call. Donc, ce n'est pas comme si j'allais pouvoir multiplier. Et j'étais dans un autre meeting pendant une heure après. Donc, la réponse dans un monde, il y a 3-4 mois, C'était non, déso. On ne peut rien faire. Dans ce nouveau monde, j'ai juste dit dans le meeting, oui, je t'envoie un deck. Qu'est-ce qui s'est passé ensuite derrière J'ai un transcript qui a détecté que Lucas a dit « je t'envoie un deck » . Il a compris le contexte du projet sur lequel je travaillais. Je n'ai pas eu besoin d'expliquer le projet parce qu'il avait déjà tout le contexte du projet où il savait aller le trouver. Même si c'était un projet vraiment très Early stage, même pas en bêta ou quoi que ce soit, Il savait sur quoi je travaillais, Il avait accès au dernier statut du projet, il comprenait les limitations. Ensuite, J'avais créé un skill qui me permettait de générer des decks automatiquement. Donc j'ai ma to-do, pardon, je reprends. J'ai le transcript, il identifie, il comprend le projet, il me crée une to-do, la to-do arrive. J'ai un autre agent qui est venu, qui a regardé la tâche, qui a fait, Lucas a engagé à envoyer un deck sur ce projet. Très bien, tiens, j'ai un skill qui me dit, Si tu as besoin de faire un deck, tu peux utiliser ce Lucas. Donc il a pris le contexte, il a pris le sales, il est capable de récupérer, pardon, le contexte de qui est le sales qui me parlait. Il est capable d'aller récupérer, en utilisant, on va dire... On va dire notre CRM, Il est capable d'aller dans le CRM pour voir qui est le client ou le prospect auquel on parlait, quel était son contexte, dans quel milieu il évoluait, le projet sur lequel je bossais et le skill pour créer le deck. Ça arrivait littéralement dans ma, pas ma tout doux, mais on va dire Mon inbox de tiens, Un agent a essayé de te faire un deck là-dessus. Littéralement, j'ai eu à aller dedans, j'ai changé un screenshot parce qu'ils sont pas très bons en screenshot. Et j'ai envoyé au site en disant Tiens, tu peux aller faire ta démo. Et ça, ça paraît, Pour moi, c'est un peu magique parce que c'est juste une tâche comme ça, Oui, c'est sympa, mais en fait, quand on multiplie ça au quotidien, c'est ça qui permet d'accélérer. Je pense que dans le métier de PM, on a quand même des tâches qui sont chronophages, mais vraiment, Des fois, je sais pas, mais je sortais de journée, j'ai l'impression d'avoir rien fait. Peut-être que j'ai mal priorisé, peut-être que j'ai fait d'autres choses, Je me suis fait distraire, Mais on a des millions de petites tâches. Et c'est toutes ces choses-là que j'essaie de m'enlever.

Terry: Hyper intéressant. Et effectivement, là, On rentre vraiment, dans le cas de déléguer des parties de son travail de manière automatique à un agent. Donc, des parties de travail aussi, pour lesquelles ce n'est pas un workflow totalement déterminé. C'est-à-dire que, globalement... L'agent a compris le problème de ton sales et a des capacités pour pouvoir répondre à ce problème en créant le deck, Mais en avance, Tu n'avais pas codé ou tu n'avais pas expliqué exactement comment faire ce deck de manière spécifique. Tu as expliqué comment faire un deck, mais ça, C'est vraiment l'agentique, c'est vraiment la puissance vers laquelle l'agentique peut nous permettre d'aller. Mais du coup, ça me permet de tirer un petit peu le fil par rapport à ce que tu as dit sur le rôle du produit. Et le fait qu'effectivement, en tant que Product people, en fonction des contextes, On va avoir des journées parfois ou des semaines où il va y avoir. Beaucoup de tâches qui vont être un peu des tâches de glue,

Lucas: un peu des tâches. Chef d'orchestre,

Terry: Mais du coup, des tâches assez ingrates, parfois, Où? À la fin de la journée, effectivement, on se dit, mais qu'est-ce que j'ai fait en fait, mis à part coller des trous, mettre des racines ici pour que le truc, il soit propre. Et donc dans un monde dans lequel ces tâches là, on arrive au fur et à mesure, à les déléguer à des agents, Quelle est la place au final du produit Lucas Cerdan. Est-ce qu'on ne pourrait pas se dire. On a beaucoup moins besoin de glue et là, je tire volontairement le trait parce que je peux faire le parallèle. Avec des boîtes qui, aujourd'hui, considèrent que le rôle du produit, c'est purement de la glue, justement. Et que donc une organisation bien pensée n'a pas besoin de cette Lucas Parce que, justement, c'est fait de manière directe. Entre, par exemple, l'Engineering et les sales. Toi, qui as vraiment une carrière très, très fournie sur le produit et en particulier en tant que contributeur individuel, quelques heures plus tard, Quels sont tes regards à la prospectiviste sur là où va le métier dans les prochaines années, en fonction de la vitesse, d'adoption et de mise en place de tous ces outils ? Qu'est-ce que tu prévois, toi, si on projette à 5 ans ?

Pourquoi le rôle de Product Manager change moins que sa manière de travailler

Écouter à 36:36

Lucas explique que le rôle du Product Manager a peu changé sur le fond, même si sa manière de travailler évolue beaucoup plus vite, parce qu’il s’agit toujours de créer de la valeur pour des clients. Il détaille aussi où il voit aujourd’hui sa valeur ajoutée, notamment dans la distribution, l’enablement et l’explication de sujets complexes à des équipes qui doivent vendre rapidement. Terry relance ensuite la discussion sur la notion de Product Builder, en distinguant les profils venus de la tech de ceux venus du business et en questionnant la barrière d’entrée de ces nouveaux outils.

Lucas: Avec 15 ans de recul, Je pense que le rôle du PM n'a pas changé tant que ça. En fait, on est toujours dans une problématique de, On a des clients pour qui on doit créer de la valeur, Et comment est-ce qu'on y arrive ? C'est très mal. résumé, mais c'est juste la manière d'opérer, La manière dont on travaille, la manière dont on y arrive, qui va beaucoup plus vite qu'à changer. Mais la réflexion, elle est toujours là, qui est? Comment est-ce que je résous? Des problèmes sur lesquels ça va apporter de la valeur, sur lesquels les gens sont prêts à payer Comment est-ce qu'ils vont le comprendre ? Et d'ailleurs, c'est un learning assez intéressant. Quand je suis sorti d'école, je pensais que la tech, c'était la chose la plus intéressante. Après, j'ai pensé que le produit, c'était la chose la plus intéressante. Et ce qui fait le succès d'une boîte, c'est la distribution. Et je pense que c'est encore beaucoup plus vrai aujourd'hui. Aujourd'hui, ma distribution dans une boîte B2B de 6 000 personnes, c'est m'assurer que des sales et des solution engineers comprennent le produit, sont capables de le conseiller en fonction de la problématique complexe que peuvent avoir des clients. Et donc, ce côté glue, pour moi, Il est encore plus présent. On peut passer dessus juste après, mais aujourd'hui, Je ne contribue pas à la code base parce que je considère que ce n'est pas là, au moins en tant que PM. Je sais qu'on parle beaucoup de Product builder et c'est peut-être... Différent dans des scale-up. Ma contribution, là où je peux apporter de la valeur, où j'ai plus de leverage, d'effet de levier, Ce n'est pas contribuer à la code base. Par contre, ça va être construire des bonnes démos, construire des outils d'enablement, Construire des choses intéressantes pour expliquer des concepts compliqués à des gens qui ont besoin de le vendre rapidement ou en tout cas, Ils ont besoin de vendre 50 choses et ils ont besoin de comprendre comment tout ça fonctionne. Là-dessus, Je vais aller passer du temps. Donc, pour finir sur le sujet, est-ce que dans 5 ans, Je suis persuadé qu'il y aura encore des PM Je suis persuadé qu'on a besoin encore de moutons à cinq pattes qui sont capables de parler à des clients, de parler à des sales, de parler à la finance, de parler à l'Ugly Gold, de parler à des ingénieurs, de savoir faire toutes ces choses-là. Ça ne changera pas. Nos métiers vont changer, la manière dont on travaille, ça change déjà. Dans cinq ans, je suis persuadé qu'il y aura encore ce genre de profit.

Terry: Hyper intéressant donc, pour continuer à tirer un peu le fil sur ça, sur ce que t'as touché du doigt. Du coup, la notion de Product Builder. Moi, c'est quelque chose que je pratique. Déjà, cette notion de Builder à titre perso. Et pour pour des clients. Et c'est quelque chose aussi où je vois qu'il y a, il y a, il y a deux mondes. Il y a ceux qui ont des profils un peu typiquement, comme le mien, c'est à dire. Et comme le tien qui viennent du background tech à la base et qui sont allés vers le produit? Et donc qui ont la compréhension quand même de comment ça marche sous le capot et qui peuvent, du coup, Grâce à ces outils-là, s'augmenter et construire en sachant plus ou moins ce qu'ils font. Et il y a les profils qui deviennent builder, mais qui n'ont pas du tout la compréhension de tech. Et là, pour le coup, Je pense que la barrière à l'entrée est beaucoup plus importante que ce qu'on peut l'imaginer ou ce qu'on peut le dire sur LinkedIn. Et donc, cette notion de tout le monde dans Cloud Code, où là, tu parlais de Cursor, c'est des choses qui, pour toi, ne te paraissent pas. complexe, mais pour des profils qui ont plus un angle business, en fait, Rien que la logique de pensée d'un DEV n'est pas la même qu'un profil business. Donc, par rapport, si tu veux un peu étayer sur ta conviction ou ton avis sur le sujet du builder, du Builder AI.

Product builders sans background technique et exemple de spoofing GPS

Écouter à 39:51

Lucas explique qu’avec un agent LLM, on peut poser des questions en langage naturel et construire des choses sans forcément comprendre ce qu’il y a « sous le capot ». Il illustre ce point avec un exemple concret : créer, via Cursor, une petite application de spoofing GPS pour aider les commerciaux à faire des démonstrations de son produit de géolocalisation. Terry revient ensuite sur l’idée que ce type de travail de builder sert surtout la distribution et aide les équipes commerciales à vendre.

Lucas: Justement, je ne sais pas si c'est au contraire de ce que tu dis, mais je pense que vous avez une chance et une opportunité énorme aujourd'hui. Si vous ne venez pas d'un background engineering, vous avez un monde qui s'est libéré. Et si vous aviez un syndrome de l'imposteur là-dessus, au contraire, l'avantage d'avoir un bas-grand technique, Pour moi, est en train de s'effacer quelque part. Je force un peu le trait, mais vos plus grandes forces, c'est plus d'être forcément un bas-grand technique. Vous n'avez même plus besoin de savoir comment ça fonctionne. Je force un peu le trait. Mais je m'explique. Déjà, il y a plusieurs choses. Un, Il y avait quand même la compréhension de comment ça marche sous le capot. Et aujourd'hui, pour bien comprendre comment fonctionne quelque chose. Sous le capot, il fallait aller embêter des devs. explique-moi Pourquoi ça, Pourquoi cette décision. Aujourd'hui, vous êtes capable de Plugger un agent au-dessus de votre code base et vous pouvez poser des questions dans un langage naturel. Et vous pouvez poser les questions les plus stupides au monde, il vous répondra, Il prendra le temps qu'il faudra, c'est juste des tokens. Vous n'êtes pas en train de prendre le temps de votre Lead DEV qui va s'énerver parce que lui n'a pas pu faire ses tâches. Donc, au contraire, Si vous êtes curieux, vous allez pouvoir poser des questions et généralement vous avez une raison pour laquelle vous posez une question, un agent LLM va vous répondre. Même sur le côté builder, je trouve qu'on est dans un monde assez fantastique. Où maintenant, vous allez pouvoir construire des choses et vous n'avez pas besoin forcément, de comprendre ce qu'il y a sous le capot. J'ai un exemple de l'Etherlance que j'ai fait la semaine dernière. Un de nos produits, donc j'ai dit on fournit des solutions télématiques, par exemple, qu'on va équiper des camions, qu'on va mettre des petits boîtiers qui vont nous permettre de les géolocaliser partout dans le monde. Pour certains véhicules, on ne peut pas les équiper. Et notamment, On a des clients qui font nos chauffeurs. Ils ont un téléphone, ils ont une application samsara qui permet de faire leur mission au cours de la journée. Est-ce qu'on peut au moins savoir où est leur téléphone et utiliser ça pour les visualiser sur une carte Assez simple comme pitch. Par contre, je suis responsable de ce produit. Il fonctionne. La question que je me posais, c'est comment est-ce que les sales vont être capables d'aller faire de la... La démo de cette chose-là. Je suis devant un ordinateur, Comment est-ce que je montre qu'avec mon téléphone qui change de position, ça apparaît bien dans votre application, ça me sert. Et là, vous pourrez dire en fait, Ce que j'ai fait, c'est que je me suis dit tiens, est-ce que je peux modifier la géolocalisation de mon téléphone de manière automatique, même si je suis littéralement devant mon ordi. Même moi qui ai un background technique, qui a su coder, Jamais je n'aurais pris le temps de le faire et je n'aurais pas eu les connaissances pour... Pour le faire. Je suis juste allé dans cursor et je lui ai dit, voilà, mon but, c'est voilà ce projet, Ce que je cherche à faire, c'est que quelqu'un qui cherche à démo, comment est-ce que je peux m'y prendre Ma première idée, c'était On a une application macOS, et je me suis dit, est-ce que je peux changer la géolocalisation de mon Mac Il m'a dit, non, c'est pas possible, voilà, la limitation, Tu ne pourras pas. Par contre, voilà une idée, est-ce que tu as ton téléphone avec toi Ouais, Si tu le connectes et que tu le mets en mode développeur, je peux te développer. Une petite application qui va faire du spoofing GPS. Et il me l'a développé. J'ai écrit zéro ligne de code, j'ai revu zéro code. Je n'ai pas besoin de voir le code, j'ai juste testé que ça marchait. Et ça, aujourd'hui, c'est mis en place. Et il y a des sales, du coup, maintenant, Quand ils vont dans des démos, ils pranchent leur téléphone et ils font, Ben, voilà, Je suis en train de me balader dans ce quartier. Et comme vous pouvez voir, voilà à quoi ça ressemblera sur votre application. Et en fait, C'est ça le message que je veux faire passer. Et je n'ai pas eu besoin de mon background technique, Je n'ai pas eu besoin de comprendre comment ça fonctionnait. C'est, j'ai un besoin, j'ai une créativité, je suis capable de m'expliquer. Je fournis le contexte et je suis capable de m'expliquer, je suis capable de justifier mes choix, J'ai un agent qui va pouvoir me faire le travail compliqué.

Terry: Hyper intéressant. Donc, Ce que j'aime bien dans cet exemple et sur lequel je voudrais revenir, c'est que là, tu as parlé de builder, mais dans un contexte où tu n'as pas buildé pour pouvoir vendre le produit, tu as buildé. Pour pouvoir aider à la distribution de ce produit, pour aider les commerciaux derrière à le vendre. Et donc, c'est ce que tu disais avant, c'est qu'aujourd'hui, Le gros sujet n'est pas sur la phase de pure construction, c'est la distribution. Et donc, réussir à augmenter. Donc, là, c'est un rôle de... Toi, en tant que product, au sein de ton organisation, Tu es venu là pour donner encore plus d'outils aux commerciaux pour aller signer, Closer, le client. Quelle place tu vois, toi, peut-être dans des organisations plus petites, puisque tu as. Cette double expérience aussi, sur les PM, des profils produits, du coup, de Builder, plus, qui vont peut-être Permettre à des organisations plus petites de démarrer et d'avoir leur premier client sans staffer tout de suite une équipe d'ingénieurs.

Lucas: Oui, tout à fait. Il y a beaucoup de prototypage qui est possible, mais l'exemple reste le même. C'est vous exprimer un besoin, c'est basé potentiellement, vous partez de rien, potentiellement, vous parlez d'une code base. Vous n'avez pas forcément besoin de la comprendre, mais vous avez besoin de bien vous exprimer. Je pense qu'on n'a pas besoin de faire forcément du prompt engineering, même si ça aide. Mais savoir bien s'exprimer et au contraire, venir avec un point de vue business et bien vraiment penser son produit. Plus la stratégie, Comment ça va être utilisé, à qui je vais le distribuer, bien comprendre le client. Tout ça, c'est des questions où l'engineering n'a pas son importance, mais que vous pouvez aller explorer. Je sais qu'il y a beaucoup de product builders. Et même des PM qui contribuent sur résoudre un bug devenu beaucoup plus simple et explorer les idées beaucoup plus simple. Tout ça ne demande pas un background technique. Aujourd'hui, je vais juste venir, peut-être là-dessus. Même si vous avez une question technique, par exemple, J'ai demandé, il m'a changé du code, maintenant, qu'est-ce que j'en fais J'ai du code sur mon laptop, j'en fais quoi ? En fait, ça, Vous pouvez poser comme question. Je fais quoi ? Tu m'as généré du code, et maintenant ? Et un élève va être capable de vous dire, peut-être qu'il faut que tu le passes sur GitHub. Ensuite, tiens, il y a un truc, c'est de la CI. C'est quoi la ci J'ai un message d'erreur, faites-lui un screenshot, vous lui envoyez, il vous expliquera ce que c'est. Il ne faut pas hésiter à être l'idiot du village en disant, je ne sais pas, explique-moi. Au contraire, Je pense que c'est une énorme qualité en tant que PM. Vous n'êtes jamais forcément l'expert de votre produit, de votre domaine. Et en fait, Vous vous posez plein de questions. Je pense qu'on se focus beaucoup sur la partie engineering. Pour moi, c'est vrai. Sur le côté illégal, c'est vrai. Sur le côté sales. Et je vais poser des questions sur la différence entre un mid-market et un enterprise force, le stress ou entre un SDR et un IDR. Je ne comprends pas forcément ces différences. Il faut être curieux, poser la question et en fait, Vous trouverez la réponse.

Terry: Yes.

Conseils aux Product Managers en France et création de la LPC

Écouter à 46:18

Terry revient sur le fait que Lucas a co-créé la LPC et lui demande quels conseils donner à des product people en devenir sur le marché français. Lucas raconte alors ses débuts en Product management en France, son passage à San Francisco et la création de la LPC pour partager les problèmes et les pratiques entre pairs. Il insiste sur l’idée que le playbook du PM change selon le contexte et qu’il faut éviter de suivre des guidelines trop théoriques ou importées telles quelles. Pour lui, il faut surtout faire preuve d’initiative, de curiosité, d’agency et chercher à créer de la valeur en résolvant les problèmes qu’on rencontre.

Terry: Pour clôturer, du coup, cette partie un peu future du métier du produit, Tu ne l'as pas dit en intro, mais tu es aussi le co-créateur de la LPC. Tu fais partie des personnes qui ont créé. Cette conférence, qui a permis aussi à l'émergence, donc la Prodeconf, du produit en France. Et donc, avec, du coup, ce regard aussi là, peut-être très franco-français, mais vu que toi, tu as... Aussi, ce regard sur ce qui se passe aux Etats-Unis. Quels sont pour Toi? Un peu les tips que tu pourrais donner à des product people en devenir sur le marché français ? Vers quoi aller ? Comment un peu penser leur rôle de demain ? Parce que voilà, on a parlé de Product builder, on a parlé d'aider à la distribution, mais aussi de s'augmenter pour bien comprendre. Des sujets qu'on maîtrise peut-être moins sur des angles si sa boîte fait du legal sur des angles legal sur des sujets, Domaines, métiers spécifiques dans la boîte dans laquelle on est, donc il y a un peu. Un panel qui est toujours aussi large, donc, qu'est-ce que tu peux donner un peu comme comme tips à des producteurs en devenir.

Lucas: Merci de me rappeler et je pense que je vais utiliser ce parallèle par rapport à la Product conférence. Et je vais expliquer comment est-ce qu'on a été amené à la créer et pourquoi je pense que c'est intéressant, donc, quand j'ai commencé le métier de Product management, donc en 2012 en France, ça n'existait pas. C'est juste que j'ai rejoint une boîte franco-française. Ils m'ont dit, tiens, Il y a ce rôle de Product manager qui a l'air de faire des responsabilités. Il y a Marty Kagan, qui a écrit un livre. Ça a l'air intéressant, sera ça ton rôle Et j'étais premier PM, je n'avais pas de manager, personne n'avait jamais fait. Et j'avais un gros syndrome de l'imposteur par rapport aux États-Unis. Grâce à cette boîte qui est Prestashop d'ailleurs, belle boîte française. J'ai pu partir un an à San Francisco. Et à San Francisco, Ce que j'ai adoré, c'est que j'allais à trois. meet-ups, conférences par semaine. Et je me rendais compte, en toute humilité, Je les définis littéralement comme ça, Je ne suis pas plus con que les autres. Mais ce qui est intéressant, c'est qu'on a tous les mêmes problèmes. Et en fait, En échangeant avec ces pairs, On se rend compte qu'on a les mêmes problèmes. Ils nous expliquent ce qu'ils ont pu tester, faire différemment. Et j'ai adoré cet enrichissement. Du coup, Quand je suis revenu en France, en 2016, je suis allé voir mes copains et je me suis fait, tiens, les conférences aux Etats-Unis, Ça pourrait quand même faire pas mal de choses. Tiens, on veut lancer une LPC, on va le faire. Pourquoi est-ce que je raconte tout ça C'est que le playbook, le rôle de PM, il change et il changera. Si vous essayez de suivre des guidelines qui sont écrites par des gens qui ne sont potentiellement absolument pas dans votre contexte, qui sont généralement embellis, Je pense que... Il y a quelques années, on se souvient beaucoup des Spotify Squad qui a fait parler, reparler. Et au final, Même l'auteur a dit, mais en fait, non, ça, c'est une vision. Même nous, en interne, on ne travaille pas comme ça. Et je pense que c'est un peu ce qu'il faut retenir du métier de PM, c'est Stay hungry, Stay foolish. Faites les choses, essayez de créer de la valeur, N'essayez pas de passer trop de temps sur la manière dont ça doit être fait. Et si vous voyez un problème, essayez de le résoudre. Soyez Scrappy et ayez ce qu'on dit en français de l'agency. Donc, vraiment, c'est... Pour moi, c'est de l'initiative et de la curiosité. Votre métier changera. Soyez pas amoureux de la manière dont vous faites les choses. Soyez pas amoureux de la manière dont ça fonctionne ou des rôles. Si vous partez du principe que vous avez un client, vous cherchez à créer de la valeur, généralement, C'est un bon signal.

Terry: Hyper intéressant. Et donc, globalement, Ce que tu dis au travers de ça, c'est que tu arrives dans une équipe, peu importe la taille de l'organisation dans laquelle tu commences à venir. On fait appel à toi parce qu'il y a des trous à boucher. Tu viens voir où tu peux les boucher pour apporter toujours plus de valeur.

Lucas: Créer de la valeur. Je disais un peu, On aime bien définir le PM, comme le CEO du produit, comme le chef d'orchestre. Quand j'étais premier PM, je disais que j'étais l'homme de ménage. Pourquoi Il y a un gap. Il y a quelque chose qui doit être fait. Vous êtes ce mouton à cinq pattes. Allez le faire. Il y a de la valeur. Allez le faire.

Terry: Ça, Je pense que c'est un message hyper fort et hyper intéressant, parce que derrière ce message-là, il y a... Évidemment, les nouveaux outils. On a vu plein de cas d'usage. Toi, comment tu t'augmentes dans ton contexte? Mais il y a plein d'autres à inventer de cas d'usage pour votre contexte. Et il y a beaucoup moins. Enfin, il n'y a pas d'excuses de dire Je ne peux pas le faire parce qu'aujourd'hui, à partir du moment où on a le bon état d'esprit, la curiosité, le fait de vouloir faire les choses, d'avoir cette capacité, cette agency. Justement, c'est vrai qu'il y a plein de mots français qui traduisent bien. Je trouve la notion d'Agency. Attendez pas un expert, c'est ce que j'ai surtout dans l'AI, je pense qu'il y a beaucoup de gens qui sont en mode. J'ai besoin d'être formé, j'ai besoin d'un expert, il

Lucas: faut... À un moment, c'est des outils sur... Littéralement, il y a six mois, ça n'existait pas. Les experts que vous voyez sur LinkedIn qui font de nos émerveilles, c'est sympa, mais prenez-en inspiration, Ça peut débloquer des idées et c'est hyper intéressant, mais faites. Just do it. On était notamment tous les deux à l'AI Product Day, qui était une conférence, Et il y avait juste avant moi un talk de Julie, Je ne sais plus. Qui est quelqu'un qui n'est pas technique, qui est CPO d'une petite entreprise et qui, pareil, est arrivé devant un terminal de Cloud Code. Et qui dit, au début, J'avais super peur, parce que pareil, GitHub, une poulerie, Je n'ai jamais entendu parler de ma vie. Et pourtant, trois semaines après, C'est le meilleur outil que j'utilise. Et c'est vraiment ce côté. Les Playbooks n'existaient pas. Les choses ont changé. La manière dont on fonctionne en tropique, dont tous les gens parlent, en plus, ce n'est pas vrai, Ils ont beaucoup de PM, ils ont ce côté. Product builder, Tout le monde pousse en prod. Peut-être que ça marche pour eux parce qu'ils sont un outil à destination de personnes plutôt techniques. aujourd'hui, Mais ça ne marchera pas pour votre boîte qui n'a rien à voir parce que vous travaillez chez GDF. Je force le trait, mais par contre, Vous connaissez les problèmes, vous savez vous passer du temps. Allez-y, Essayez de trouver comment vous augmenter, de trouver comment augmenter votre équipe, de prouver, d'ajouter de la valeur à vos clients. Généralement, vous ne pouvez pas vous tromper quand vous faites ça.

Terry: Super. Top, merci pour ce partage. Donc, 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 message à faire passer, Un point à mettre en avant

Peur du changement, syndrome de l’imposteur et apprentissage par l’expérimentation

Écouter à 52:23

Lucas évoque la peur du changement et le syndrome de l’imposteur, en disant que c’est normal et qu’il préfère le dire clairement. Il s’appuie ensuite sur un petit livre avec des souris dans un labyrinthe pour expliquer qu’on peut réagir de plusieurs façons face à une décision qui fait peur. Pour lui, l’idée est d’être la petite souris qui va expérimenter, et Terry souligne que ce livre est très court, rapide à lire et utile pour ancrer cet état d’esprit.

Lucas: Je pense que ça fait peur. Je pense que je préfère le dire. Même moi, avec 15 ans d'expérience, Je me suis dit Quand je suis revenu de congé paternité, j'étais en mode. « waouh, est-ce que je vais devenir absolument inutile dans un an ? » Et puis, c'est des juniors qui vont être bien plus forts que moi, qui vont prendre ma place. Je préfère le dire. Si vous avez un syndrome de l'imposteur, si vous avez peur, c'est normal. Je préfère le dire, c'est normal. Au lieu d'être bloqué, Il y a un petit bouquin que j'aime bien. Je ne sais pas comment il se traduit en français. C'est un bouquin qui fait 80 pages.

Terry: Je l'ai déjà conseillé dans un épisode il y a longtemps. Il est génial avec des petites souris dans un labyrinthe.

Lucas: C'est ça.

Terry: Je crois que c'est Who Stole My Cheese. C'est qui a volé mon Fromage, il me semble, en français.

Lucas: En anglais, Je suis sûr que c'est Who Moved. C'est Moved. Et l'idée, c'est qu'il y a des petites souris dans un labyrinthe. D'habitude, il y a toujours le fromage au même endroit. Et du jour au lendemain, le fromage, Il n'est plus là. Et en fait, Les petites souris représentent l'état d'esprit dans lequel vous pouvez réagir. Et on n'est jamais une seule souris. On est toujours plusieurs souris. Donc, il y a une souris qui part tout de suite explorer. Il y a une souris qui attend un peu et qui regarde un peu à droite, à gauche. Et il y a une souris qui va se plaindre. Et c'était... Je sais que moi, en tant que Français. râleur, quand j'ai des changements que je trouve, qui me font peur, sur lesquels je ne suis pas d'accord, J'avais tendance à d'abord râler. Et à chaque fois que je reviens à ce genre de décision, il y a pour moi été un bon exemple de « je ne sais pas par où commencer, ça a l'air impressionnant, est-ce que je vais devenir inutile ? » Je me suis dit « non, je suis la petite souris, je vais aller expérimenter » . Donc, si vous avez peur, c'est normal, Soyez la petite souris qui va expérimenter et je vous garantis qu'au contraire, Les barrières à l'entrée sont en train de tomber. Et si vous êtes curieux, que veut Vous allez expérimenter, vous allez trouver de la valeur et vous allez trouver ça super intéressant.

Terry: Super, merci. 100%, ce bouquin, pour le coup, contrairement souvent au bouquin américain, Il est très petit. Donc, il se lit très vite. Et l'état d'esprit, enfin derrière, C'est vraiment même pour les profils plus entrepreneuriaux, etc. C'est un bouquin que je trouve hyper intéressant pour ancrer justement cet état d'esprit à avoir. Et ça y matche, super bien. Enfin, la métaphore avec l'adjointe, Elle est, Je trouve, très bien faite. Je le mettrai dans les liens de la description.

Trop de poids accordé aux titres et apprendre en faisant

Écouter à 54:32

Terry ouvre cette fin d’échange en demandant à Lucas quelle conviction forte il a, en général, en désaccord avec ses pairs. Lucas répond qu’on accorde trop d’importance à la voix des gens qui ont un certain titre, et Terry prolonge en disant qu’il faut plutôt juger sur les outcomes que sur les titres. La discussion glisse ensuite vers la manière dont Lucas progresse et ce qui le nourrit intellectuellement. Il explique qu’il apprend en faisant, en s’inspirant de ses pairs, et en allant voir des gens qui ont déjà résolu des problèmes pour comprendre comment ils s’y sont pris.

Terry: Pour aller vers mes 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

Lucas: Ce qui est intéressant, c'est que ça fait 15 ans que je fais du contributeur individuel et ça redevient un peu sexy. Ce n'était même pas le cas. Il y a encore 2-3 ans. Une conviction qui est assez forte, Et je le vois aussi à travers la preuve de conférence, c'est qu'on porte... Trop d'importance à la voix des gens qui ont un certain titre. Les gens que vous allez voir dans des conférences, dans des podcasts, dans des articles, ils vont vous dire, c'est un C-level, c'est un Head of product. C'est pas forcément les gens qui font craft, c'est pas forcément les gens qui ont eu les bonnes idées, C'est pas forcément les gens qui ont vraiment débloqué les situations. De manière générale, Prenez avec une pincée de sel. Je connais d'énormes gens que vous verrez jamais sur scène, qui n'ont pas envie de... De parler, mais qui font un métier et un travail formidable. Donc, voilà, Moi, c'est ma conviction. forte, C'est que c'est pas parce que vous êtes C-Level que vous êtes forcément très bon dans le produit.

Terry: Hyper intéressant pour ces gens que tu connais, dont on entend moins parler, j'espère que tu m'en recommanderas certains et qu'ils viendront partager leur expérience sur le podcast. Et je trouve ça intéressant aussi par rapport à ce que tu dis là, et ça, C'est aussi un aspect très français. On aime bien mettre les gens dans des boîtes. Et, du coup, effectivement, ça permet derrière, En fonction des boîtes dans lesquelles les gens sont, on va plus ou moins leur accorder notre attention et une certaine légitimité. Et je pense qu'il faut réussir à sortir de ça. Parce qu'effectivement, à l'heure actuelle, où on peut tous tout faire. À partir du moment où on a la volonté d'apprendre, c'est plutôt jugé sur les outcomes plutôt que purement sur des titres. Ou effectivement, des rôles dans certaines orgues. Hyper intéressant. Donc, pour aller vers ma dernière question maintenant, c'est quelles sont les choses qui te nourrissent intellectuellement ? Comment est-ce que tu progresses ?

Lucas: En faisant, généralement, et en m'inspirant de mes pairs. Là, je parlais justement, donc en interne, On a tous été un peu... Il n'y a pas eu de prescription, c'était on vous donne les outils créés, allez créer de la valeur. Je trouve ça hyper intéressant. Ensuite, de se regrouper, d'aller voir les gens qui ont fait des choses. cool, qui partagent, leur demander comment est-ce qu'ils ont résolu tel ou tel problème. Et je trouve ça hyper intéressant de voir, Ah, j'avais même pas pensé à ça, ou tiens, c'est vrai que c'est des choses que je fais pas aujourd'hui, que j'avais pas pensé à les automatiser. Et je pense qu'on a tout ça à apprendre les uns des autres et être constamment dans le partage. Ça a toujours été ma feuille de route et ça continuera à l'être.

Terry: Super, totalement en ligne avec ça, C'est aussi le but et l'existence de ce podcast. Merci en tout cas pour ton partage Lucas. Et à bientôt.

Lucas: Merci pour l'invitation.