Pourquoi les product managers d’OpenAI ont arrêté les maquettes, Katia Gil Guzman

Personnotypes de Codex, ambition de Chatgpt Work et notion de harnais

Écouter à 04:05

Katia explique que Codex a d’abord été adopté par les développeurs, au sens large, mais aussi de plus en plus par des product managers et des personnes qui travaillent en growth. Elle précise que l’ambition de ChatGPT Work est de pouvoir être utilisé par tout le monde, y compris des personnes non techniques, dans des domaines comme le droit, le marketing ou d’autres formes de knowledge work.

Terry: Par rapport à ces deux produits, à l'heure actuelle, On enrogeait cet épisode en septembre 2026, Je le précise, parce que s'il est écouté plus tard, Les choses avancent très vite. Mais à date, c'est quoi un petit peu les personnotypes, tu vois, entre ces deux. Deux produits que tu vois, toi, aujourd'hui

Katia: Alors, c'est assez varié, pour être honnête. Donc, Codex, bien sûr, C'est les développeurs qui l'ont adopté en premier. Quand je dis développeurs, c'est très large. Ça peut être les indie développeurs, ça peut être des développeurs dans des entreprises grandes ou petites. Mais de plus en plus, en fait, On voyait qu'il y avait, Par exemple, des product managers, des personnes qui travaillent en growth, qui commençaient à utiliser Codex. Et donc, c'est pour ça aussi, C'est ça qui a alimenté l'idée de faire Chatgpt Work. Maintenant, on veut, en tout cas, Notre ambition, c'est que vraiment tout le monde puisse utiliser Chatgpt Work, que ce soit. Quelqu'un qui n'a rien à voir avec la tech, tout comme quelqu'un qui travaille dans un cabinet d'avocats, qui travaille dans le marketing, qui travaille dans tout type de ce qu'on appelle Knowledge work. On pense que le meilleur environnement pour le faire, c'est de chercher B2Work. Et après, ceux qui sont intéressés pour savoir ce qui se passe derrière, un peu ceux qui veulent ouvrir sous le capot, Et ce n'est pas forcément que les développeurs, Comme je disais, ça peut être aussi. Les product builders, peuvent utiliser Codex et avoir un peu plus de détails techniques. Mais en fait, d'ailleurs, notre équipe, ça s'appelle Developer Experience, actuellement, Mais on se demande si on ne pourrait pas changer de nom, parce que finalement, notre audience, maintenant, Ce n'est plus du tout que les développeurs. C'est vraiment... Tout le monde qui peut construire quelque chose, sans forcément avoir de connaissances techniques derrière.

Terry: Ok, très clair. Donc, avant d'aller dans les cas d'usage, de voir ce que ça permet de faire ces deux produits, Tu as parlé de harnais. C'est un concept en fonction du niveau d'implication dans les sujets IA, qui peut être plus ou moins clair. Donc est-ce que tu peux expliquer avec tes mots, toi, ce que tu mets derrière cette notion de harnais, de harness. Et pour des profils plus ou moins techniques, ce que ça veut dire

Katia: Le harnais, c'est l'environnement d'exécution d'un modèle. C'est à la fois les outils auxquels il a accès, c'est les guardrails, les limites qui lui sont imposées, c'est aussi tout ce qui va gérer son contexte. Par exemple, Les modèles ont une fenêtre de contexte limitée. La façon dont on va gérer le fait de réduire cette fenêtre lorsqu'on arrive à la limite, ça fait partie aussi du harnais. Donc, en fait, tout ce qui va dire au modèle, Voilà tout ce que tu peux faire, Voilà comment tu dois te comporter. C'est aussi les instructions, c'est tout ça, c'est le Harnais en fait. Il n'y a pas une définition hyper précise, c'est vraiment Codex, c'est le Harnais Codex. Et en fait, Quand on utilise nos modèles dans Codex ou quand on utilise le modèle d'autres personnes, parce qu'on peut utiliser aussi d'autres modèles. Qui ne sont pas les modèles? Openai dans Codex, on dit qu'on utilise le Harnais Codex. Et après, on peut aussi utiliser nos modèles dans Cursor, dans OpenRouter, dans d'autres harnais. Et l'exécution va être différente, puisque les Harnais seront différents. Après, nous, nos modèles, Ce qu'on dit, c'est que c'est mieux, forcément, de les utiliser avec Codex ou ChatGPT Work, Parce qu'ils ont été entraînés pour ça. Ils ont été entraînés avec la connaissance. Des outils qui sont disponibles dans le Harnais Codex, de la façon dont la compaction du contexte fonctionne, etc. Donc, forcément, ça marche mieux en général, quand on utilise nos modèles dans le Harnais Codex, Même s'il y a des gens qui préfèrent l'utiliser autrement.

Terry: Yes. Donc, assez clair, On pourra potentiellement revenir à plusieurs moments sur des éléments si ça s'y prête.

Automatiser les demandes Slack et les PR avec Codex

Écouter à 07:57

Terry demande un cas d’usage concret pour montrer les capacités de Codex et la manière dont il peut servir à construire un produit. Katia explique que sa façon d’utiliser Codex a beaucoup changé, au point de pouvoir déléguer à l’outil des tâches qui l’aident à se concentrer sur la création de nouvelles choses. Elle décrit ensuite un flux très concret où Codex lit les demandes sur Slack et dans ses DM, prépare une PR prête à l’emploi, partage une Preview, puis itère en fonction des retours.

Terry: Maintenant, Ce que j'aimerais bien qu'on fasse, c'est que tu prennes un cas d'usage que toi, tu mets en avant sur... On va commencer par Codex. Pour montrer les capacités de Codex. Est-ce que tu as un exemple vraiment frappant, qui pourrait parler de comment tu vas utiliser Codex pour construire un produit

Katia: Oui. Franchement, On a un nouveau modèle qui est sorti la semaine dernière. On pourra en parler plus en détail. Ce modèle, Ça fait plusieurs semaines que je l'utilise. Et la façon dont j'utilise Codex a complètement changé depuis quelques semaines. Donc, Astra. Oui, Astra, exactement. Et déjà, ça avait changé avec les modèles précédents, mais là, c'est vraiment... En fait, c'est génial, puisque je n'ai plus rien à faire, plus rien à dire. Limite, Je ne sais pas que je n'ai plus mon travail à faire, mais je peux me concentrer sur uniquement créer des nouvelles choses. Et toutes les tâches annexes, en fait, Ce ne sont pas des tâches annexes, Ça fait partie de mon travail, Mais ce ne sont pas forcément les choses sur lesquelles j'ai besoin de réfléchir et de me concentrer. En fait, tout ça, je peux le déléguer à Codex. Donc, exemple très concret. Donc, je gère le site de developers, developers.openai.com, learn.chatgpt.com, avec d'autres gens, Mais il y a pas mal de choses où c'est moi, principalement qu'on vient voir pour ajouter des choses dessus. Notamment, On a une page avec des USE cases, on a des blog posts, on a plein de guides différents. Et donc, je reçois pas mal de demandes de gens qui veulent ajouter. Des choses dans ces surfaces-là. Et donc, avant, je devais un peu le faire moi-même, prompter Codex de dire, OK, ajoute cette chose-là. Et là, aujourd'hui, en général, Ces personnes me le demandent sur Slack. Et donc, Tout ce que je fais, c'est que je demande à Codex de scanner Slack, scanner mes DM. et de faire les choses que les gens me demandent. Et en fait, le repo dans lequel vit ce code, dans lequel vivent ces sites, parce que c'est le même repo, On l'a préparé avec plein de skills, Donc on peut parler plus en détail de ce que c'est les skills, mais en fait, On l'a préparé de sorte qu'on n'ait plus besoin de rien dire. Et que Codex fasse tout en utilisant le contexte qui est dans le repo et en utilisant le contexte qui est dans Slack. Donc ça veut dire que si aujourd'hui, il y a quelqu'un qui vient me voir en me disant « Ouais, j'ai fait ce blog post, est-ce qu'on peut l'ajouter ? » Ou « Est-ce qu'on peut ajouter ce guide dans les docs ? » etc. Je n'ai rien besoin de dire, Je dis juste à Codex, fais ce qui est dit dans mes DM, et je peux préciser avec cette personne-là. Et automatiquement, Codex va prendre le document qui a été envoyé par cette personne, va prendre les skills qui sont en rapport avec, par exemple, le blog, les use, cases, les docs, etc. Et va me faire une PR qui est déjà prête. Et ensuite, va partager le lien de la Preview à cette personne. Cette personne aura peut-être du feedback à faire. Et s'il y a du feedback, Codex va itérer dessus. Et en fait, moi, je n'ai même plus besoin d'être dans la boucle. Au final. Je crée juste un nouveau work tree sur Codex. Donc, pour que ça ne soit pas sur mon... Quand je travaille en local sur le même repo, en fait, c'est sur une autre branche en local. Et ça se passe sans que j'ai besoin de regarder, sans que j'ai besoin de rien faire. Et ensuite, c'est juste prêt. Et je n'ai pas eu besoin de me déconcentrer de la tâche que j'étais en train de faire. Donc... Ça change vraiment ma façon de travailler.

Gérer le coût des tokens et choisir entre Astra et Luna

Écouter à 11:24

Terry interroge Katia sur le coût des tokens, en particulier avec Astra, et sur la manière d’évaluer ce coût par rapport à l’efficacité du modèle pour une même tâche. Katia explique qu’Astra peut utiliser moins de tokens pour arriver au même résultat, tout en laissant la possibilité d’ajuster le niveau de raisonnement demandé. Elle compare aussi Astra et Luna, en recommandant plutôt Luna pour des automatisations simples et moins coûteuses, tandis qu’Astra reste réservé aux tâches plus compliquées.

Terry: Sur ça, hyper intéressant. Après, j'ai pas mal de questions par rapport à ça. La première, c'est ces messages qui t'arrivent dans ton contexte. Slack. Est-ce que tu as mis en place un mécanisme où quand Codex passe dessus, c'est quand toi, Tu as répondu à la personne en disant oui, ok. Parce que potentiellement, si je sais qu'il y a cette machine derrière toi, je peux t'envoyer des messages. Après, c'est la même équipe, Tu es chez OpenAI, Mais envoyer un message? Et il y a des actions qui sont prises. Alors que toi, tu ne voulais pas que l'action soit prise. Comment tu le gères, ça

Katia: Il y a deux choses. En fait, automatiquement, Codext va scanner deux fois par jour, le matin et le soir, tous mes DM, les channels qui m'intéressent, mes mails, etc. Et mettre à jour une sorte de dashboard qui est un peu mon dashboard où je suis, toutes les choses que j'ai à faire. Et il va créer des drafts de choses qui ont été demandées. Mais je me suis fait une petite interface où il me met le lien vers les drafts. Et après, moi, je vérifie quand même, mais j'en vois. Sur l'exemple que je donnais juste avant, en fait, souvent, c'est moi qui vais dire à Codex, OK, scan, Il y a telle personne qui m'a parlé de telle chose. À ajouter, ça peut être plusieurs personnes, regarde les D.M avec un tel, regarde le Channel avec telle autre personne et fais la tâche demandée. Donc, c'est quand même moi qui initie dans ce contexte-là, Mais j'ai juste à dire, regarde ce qu'il m'a dit et fais.

Terry: Yes, OK. Du coup, par rapport à ça, évidemment, C'est hyper inspirant ce que tu partages en termes de gains, de productivité. Derrière, on parle d'Astra, dernier modèle, qui consomme, Si je ne dis pas de bêtises, c'est quand même 2,5 fois plus que chez GPT, que le 6 juste avant, en termes d'usage.

Katia: En fait, Tu parles du prix

Terry: Oui, du coût des tokens.

Katia: Sauf qu'en fait, le coût des tokens, On ne peut pas regarder juste le coût des tokens parce que...

Terry: À niveau de raisonnement équivalent.

Katia: Justement, en fait, Astra peut faire des tâches de manière beaucoup plus token efficient que le modèle précédent. C'est-à-dire qu'en fait, pour une même tâche, il va y arriver avec moins de tokens. Donc, certes, c'est plus cher, mais dans l'absolu, ce n'est pas tellement plus cher puisqu'il va réussir à faire la même tâche avec moins de tokens.

Terry: Donc, il va ajuster son effort de reasoning en fonction de la tâche qu'il a comprise, qu'il devait réaliser.

Katia: En fait, c'est surtout pour une même tâche, Il y aura besoin de moins raisonner, Il y aura besoin de moins de tokens avec Astra. Pour arriver au même résultat.

Terry: Ok, mais tu gères toujours quand même le niveau d'effort, de raisonnement que tu lui demandes d'appliquer ?

Katia: Tu peux. Après, naturellement, Astra va consommer, va utiliser moins de tokens pour arriver au même résultat. Mais aussi, Il y a le fait que tu as ce curseur et typiquement une tâche où tu aurais besoin d'un SOL, Qui était notre modèle précédent, State of the Art. Donc, si sol arrivait à le faire en extra, high, peut-être qu'Astra arriverait à le faire en médium. Donc ça veut dire qu'en fait... Tu peux utiliser un niveau de raisonnement plus faible avec Astra pour arriver à la même tâche, mais aussi... Alors, je n'ai pas les chiffres exacts, mais en tout cas, On a trouvé notamment sur certains Benchmarks qu'Astra arrivait à des meilleurs résultats que sol, avec moins de tokens utilisés.

Terry: Yes, ok. Du coup, plus efficient, comme tu me le dis, au final, Même si le coût par Token est plus élevé, étant donné qu'il en consomme moins que ce qui est le plus efficient, ça te revient potentiellement moins cher pour la même tâche.

Katia: Exactement.

Terry: Maintenant, par rapport à cette logique de token, Parce qu'en soi, quand on entend des use cases comme celui que tu viens de partager, Merci. On peut se dire, go. Mais après, il y a un moment aussi, où, en fait, Il y a l'aspect non déterminisme des LLM qui permet de réaliser ce type de tâches, qui fait que quand tout se passe bien, ça va bien. Mais s'il part un peu en vrille, il peut potentiellement surconsommer, ne pas réaliser la bonne tâche. Ça, en soi, tu peux mettre les garde-fous, comme tu l'as dit, avec une logique de draft où, en fait, Tu revalides quand même, à chaque fois. Mais le sujet, par exemple, de la surconsommation, ou comment est-ce que... Quels sont potentiellement aussi, toi, quand tu échanges au quotidien avec les personnes qui... Qui construisent, qui essayent d'utiliser ces modèles-là. Quelles sont les réponses que tu peux apporter autour de « Ok, c'est génial, mais demain, ça peut me coûter très très, cher en token pour faire une tâche qui, en fait, si je l'avais faite en tant qu'humain ou avec un peu d'automation purement déterministe et le mix des deux, m'aurait coûté moins cher. »

Katia: Ce qui est bien, c'est que les tâches que je décris là, ça dépend desquelles, mais typiquement, celles où il faut répondre à des messages sur Slack, C'est des choses qui peuvent être très bien gérées par des modèles type Luna, qui est notre modèle. Le plus petit, GPT 5.6 Luna, qui est très token, efficient également. Il arrive à... Et qui est aussi très peu cher. On a d'ailleurs divisé les coûts par deux après l'avoir sorti. C'est-à-dire qu'entre le moment où Luna est sortie. Et quelques semaines après, on avait divisé les coûts par deux parce qu'on a réussi à faire des optimisations supplémentaires. Et donc, des modèles comme ça, finalement, ça coûte très peu cher, même pour analyser beaucoup de contextes et... À partir du moment où la tâche n'est pas trop compliquée, Si c'est juste répondre à un message sur Slack, je dirais vraiment, Faites attention au modèle que vous utilisez dans vos automatisations. Et si vous utilisez, Si vous savez que vous allez avoir besoin d'analyser beaucoup de documents, de regarder tous vos mails, d'analyser tous les messages. Slack, Essayez d'utiliser plutôt un Luna qui est beaucoup moins cher et beaucoup moins consommateur. Et après, réservez plutôt le... Les gros modèles comme Astra pour les tâches est vraiment compliqué. Typiquement, Si je sais que je dois ouvrir une PR, après, je vais être honnête, nous, On a moins ce raisonnement en interne, parce qu'on est...

Terry: C'est pour ça que je te challenge là-dessus, parce que je sais que vous n'avez pas de limite, vous, sur l'usage des tokens.

Katia: C'est vrai que je ne suis pas une très bonne élève là-dessus et que j'utilise souvent Astra parce qu'on teste Astra. On ne change pas pour aller mettre Luna, mais je change quand même le niveau d'effort, de raisonnement. En fonction des tâches, surtout si je n'ai pas envie d'attendre, par exemple. Mais en pratique, Je sais que Luna est très bon sur tous ces sujets-là et ça va être vraiment quand il y a une tâche compliquée, par exemple, notamment qu'il faut implémenter une nouvelle fonctionnalité dans du code ou faire un document, Une présentation vraiment poussée, où là, on peut dire, OK, On va utiliser Astra. Mais du coup, pour les automatisations du quotidien, On peut très bien faire ça de manière optimisée en utilisant des modèles plus petits. Et ce qui est bien, en fait, C'est que dans l'exemple que je donnais, où j'ai mon dashboard qui se met à jour tous les jours, en fait, On garde tout le contexte qui a déjà été analysé dans le dashboard, dans le site, en fait. Donc ça, Je l'ai créé avec un site qui est déployé automatiquement et qui, avec notre plugin, qui permet de faire des sites, qui a aussi une base de données, inclue. Et donc, du coup, Le modèle, en fait, va faire cette première analyse. Et ensuite stocker. Tout dans une base de données. Et donc, lorsque l'automatisation devra tourner à nouveau, Il n'y aura pas besoin de refaire toute cette analyse puisqu'il y aura déjà le contexte existant. Donc, ce sera surtout prendre le contexte existant, voir s'il y a des nouveautés par rapport à ce contexte existant.

Terry: Yes, très clair.

Context engineering dans un travail solo ou en équipe

Écouter à 18:27

Terry introduit la question du « context engineering » en demandant quelles bonnes pratiques permettent de donner au modèle le plus de contexte pertinent, au-delà du simple fait de brancher Slack sur un LLM. Katia commence par distinguer le travail seul du travail en équipe, en expliquant qu’en solo le modèle peut s’appuyer sur des logs, l’historique de session et d’autres éléments pour reconstituer le contexte. Quand il s’agit d’équipes, elle insiste sur le fait d’encoder au maximum le jugement et les règles directement dans le dépôt ou dans des fichiers partagés pour que les autres puissent retrouver ce contexte.

Terry: Donc, tu as parlé pas mal de fois de la notion de contexte. Tu as parlé du Harnais aussi, dans lequel le contexte vient aussi s'imbriquer avec les outils et les éléments dessus. Là, en sortant purement du produit Codex, mais au sens large, Cette notion de context engineering, de comment est-ce qu'on fait pour réussir à donner au modèle, au LLM, le plus de contexte pertinent à son business, à son entreprise. Quelles sont un peu les bonnes pratiques, toi, que tu commences à voir, que vous avez pu expérimenter aussi en interne chez OpenAi Vous aviez publié un article en début d'année sur justement la construction d'un produit full Vibe codé en interne, qui était intéressant autour du sujet du harness, mais du coup, Il y a le contexte qui vient là-dedans aussi. Donc, là, si tu peux donner un peu, partager des clés de lecture, justement, pour des boîtes qui se posent. Des questions autour de comment je donne du contexte, au-delà de juste dire Je plug mon slack sur mon LLM. Oui,

Katia: alors je pense que ça dépend de si on travaille seul ou en équipe. Si on travaille, seul, en fait, finalement, On a de moins en moins besoin de réfléchir à comment donner le contexte, Notamment parce qu'avec Astra, on a sorti une nouvelle fonctionnalité qui... Aujourd'hui est expérimental, Mais d'ici quelques semaines sera activé par défaut, Qui est qu'Astra va naturellement créer des fichiers pour lui-même, pour noter tout ce qu'il a fait, puisque quand on fait une compaction de contexte, parfois il peut y avoir des informations qui sont perdues. C'est-à-dire que le modèle va arriver à la limite de sa fenêtre de contexte, Et ensuite, on va la compacter automatiquement, C'est fait de manière optimisée, mais c'est possible qu'on perde un peu de l'information. Et donc... Une bonne pratique que commençaient à faire les gens, c'était demander au modèle, dans Codex, de créer des logs pour lui-même. Je parlerai ensuite de comment ça se passe en équipe, mais même quand on travaille. seul, de créer des fichiers de Logs pour un peu enregistrer toutes les décisions qui avaient été faites, s'il y avait eu un bug en particulier qui avait été réglé, Comment est-ce que ça avait été fait, etc. Et donc ça, en fait, par défaut, maintenant, ça va être dans Codex, Donc le modèle va le faire naturellement. Et il y a aussi beaucoup de choses qui sont pour le coup des fonctionnalités de Codex et de Chatgpt Work. Typiquement, l'historique d'utilisation sur son ordinateur, tous les plugins, donc Slack, Email, Drive, etc. Qui font que maintenant, honnêtement, On n'a plus vraiment besoin de données, de contexte quand on travaille seul. Parce que le modèle va pouvoir aller chercher aussi dans les historiques de session, par exemple. Dans l'historique de ce qu'on a fait sur son ordinateur, dans tous les éléments qui sont à sa disposition, vont lui permettre de reconstituer ce que nous, On aurait voulu faire. Et donc, Il n'y a plus besoin de dire ce qu'on veut quand on est seul. Par contre, Quand on travaille en équipe, là, Le modèle dans le Codex de quelqu'un d'autre ne va pas forcément avoir du contexte sur ce que nous, on a fait. Et donc, C'est là où je pense que... La bonne pratique, c'est vraiment d'encoder le plus possible le jugement dans le repo de code. Donc, après, c'est différent si on travaille sur des présentations. Ça ne va pas être un repo de code, mais ça peut être, par exemple, je ne sais pas, Une cheat sheet cachée à la fin d'une présentation qui explique le thème qu'on a le droit d'utiliser, Les différentes polices, les icônes, etc. Que ensuite, le Codex ou le chat GPT Work de quelqu'un d'autre va pouvoir utiliser. Quand c'est dans du code, en fait, c'est...

Terry: Là, juste avant de basculer sur quand c'est dans du code, c'est un peu l'équivalent de... Au début, on avait les fichiers agents.MD qui permettaient de poser un peu le point d'entrée pour l'ALM, Plus potentiellement, une arborescence d'autres fichiers Markdown, qui vont ajouter du contexte au-delà de ce Master agents.md. Là, Ce que tu dis, c'est sur ton repo GitHub, où tu as ton code, tu vas ajouter un fichier équivalent qui va être le... Le contexte partagé entre les différentes personnes qui travaillent dessus

AGENTS.md et skills dans un repo de code

Écouter à 22:24

Katia explique que, dans un repo de code, le fichier AGENTS.md reste pertinent pour guider le modèle vers les bons endroits, tandis que d’autres éléments peuvent compléter ces instructions quand on n’est pas dans du code. Elle donne des exemples de skills pour différents types de tâches sur le site, les docs et les assets médias, avec des règles, des fichiers et des scripts qui permettent de traiter les demandes sans contexte supplémentaire. Terry demande ensuite comment définir précisément un skill, ce qui lance la discussion sur sa portée et sur ce qu’il peut regrouper.

Katia: Justement, quand c'est dans du code, en fait, le AGENTS.md est encore très pertinent. Et après, on peut ajouter d'autres choses quand ce n'est pas dans du code. Parce que maintenant, ChatGPT Work, on peut faire beaucoup plus que juste du code. En fait, on ne va pas demander aux utilisateurs non techniques de créer un AGENTS.md. Donc, c'est plus le fait que maintenant, en particulier. Astra est très bon pour utiliser des templates existants, un design system existant. Donc, c'est plus dire si on veut créer des présentations en équipe, plutôt qu'une seule personne qui donne le contexte de comment doit être la présentation, C'est bien aussi d'inclure une slide cachée qui décrit le design system qui est utilisable. Pareil pour les documents, Pareil pour les spreadsheets. Si jamais il y a des choses qui sont non évidentes, notamment des règles de calcul pour le cadre d'un fichier Excel, Il faut que ce soit dans le fichier que le chat GPT Work de quelqu'un d'autre. va... modifié, puisque la personne qui l'a créé ne sera pas là pour dire « non, ce n'est pas comme ça qu'il faut faire » . Dans le cadre du code, c'est beaucoup plus simple, parce qu'effectivement, tout peut vivre dans le repo. Donc, le agents.md, C'est un peu le fichier d'entrée qui donne les instructions, mais qui dit surtout « si tu dois faire tel stage, va regarder tel endroit » . Et donc, là, l'exemple que je donnais avec notre repo pour notre site, Developers.openiray.com et learn.gpt.com, en fait, On a plein de skills différents. Pour chaque type de tâche, comme je disais, ajouter un guide dans les docs, ajouter un Use case, ajouter une démo dans le showcase. Et en fait, dans le Agents.md, on dit, Si jamais tu dois ajouter ça, va voir le skills correspondant à telle chose.

Terry: Les skills, est-ce que tu peux en donner ta définition, ta compréhension de comment vous voyez les skills Parce qu'il y a plusieurs niveaux de compréhension de la notion de skills. Je trouve que cette notion de skills, elle n'est pas si triviale que ça, parce que, d'un côté... Il y a eu aussi une évolution en termes de produits, c'est-à-dire que vous aviez commencé, avant qu'il y ait des skills, Si je ne dis pas de bêtises, c'était les custom GPTS qui sont arrivés, avec la capacité de faire des systèmes promptes réutilisables pour avoir des bouts de systèmes promptes qu'on va devoir utiliser. Typiquement, résumer une réunion, On a une façon de résumer la réunion, On veut à chaque fois réutiliser le même système prompt, On peut faire un custom GPT. Ça, c'est quelque chose qu'on peut empacter dans un skill, parce que c'est un système prompt. seul, Mais les skills permettent aussi d'avoir des bouts de code, faire appel à des scripts. Donc, ça va en... Comment, toi, tu définis le Skill

Katia: Alors, un skill, Pour moi, c'est très simple. C'est un set d'instructions avec potentiellement des ressources à utiliser. Donc, par exemple, ça peut être aussi simple que de dire, lorsque tu dois... Ajouter une démo dans notre showcase, assure-toi que tous ces éléments sont bien renseignés, formate l'information de telle manière, etc. Mais tu peux aussi avoir des ressources qui sont, soit des scripts, soit des fichiers que le modèle va pouvoir utiliser. Notamment, par exemple, On a un skill pour gérer les assets médias dans notre repo, puisqu'en fait, Il y a beaucoup de gens qui mettent. C'est ça qui est bien dans le fait d'encoder le jugement dans le repo, C'est que tu peux avoir beaucoup de contributeurs qui n'ont pas forcément besoin d'avoir du contexte sur le Repo. Et ça va juste marcher. Là, par exemple, J'ai fait un peu une rétro parce que ça fait un peu plus d'un an que le site existe. Et en fait, Dans ces un an, il y a presque 200 personnes qui ont contribué au DOC et autre chose sur ces sites. Et ça, avant, notre site pour les docs, Il y avait peut-être 10 personnes qui contribuaient parce que c'était tellement compliqué de contribuer. Bon, il n'y avait pas Codex à l'époque, mais aussi, c'était dans le mono-repo. Les gens ne savaient pas trop où est-ce qu'il fallait mettre les choses. Là, en fait, C'est un repo à part, avec plein de skills qui fait que même les gens qui ne sont pas du tout techniques, on a des gens, c'est des... On a beaucoup de product managers qui ajoutent des choses. On a des personnes qui travaillent en growth, en marketing, en... enfin, qui sont... Qui veulent aussi partager du contenu, mais non technique pour les utilisateurs de chat GPT Work. Toutes ces personnes-là, en fait, Elles ont zéro contexte sur comment ça fonctionne. Mais on a des skills qui permettent de traiter ce qu'ils leur demandent de la meilleure manière, de la même manière que ce que nous, qui avons du contexte sur le repo, Aurions fait. Et donc là, typiquement, sur les médias, assets, en fait, Il y a beaucoup de gens qui ajoutaient du contenu avec des grosses images, avec des vidéos, etc. Et donc là, typiquement, on a... Un skill qui dit, Il faut mettre, convertir toutes les images en WebP, il faut les compresser. Si jamais c'est des images ou des vidéos trop grosses, il faut les mettre dans le CDN. Et donc, en fait, Tout ça, c'est des scripts. Notre CDN, il est dans Azure. Donc, on a un script, en fait, qui permet d'uploader les assets directement dans le CDN. Sans que les gens aient aucune idée de ce qui se passe derrière. Donc, en fait, c'est pour ça, les skills, c'est vraiment, On package des instructions et éventuellement des scripts, des ressources qui vont permettre au modèle de... De faire tout ce que la personne qui gère ce repo aurait voulu faire. C'est pour ça que je dis que quand on travaille en équipe dans un repo partagé, c'est différent. Parce que toute cette connaissance qui, normalement, Si on était tout seul, Codex pourrait le retrouver par rapport à notre propre contexte, à notre propre historique, etc. Là, ça ne va plus être valide si c'est quelqu'un d'autre qui l'utilise. Et donc, ça reste une bonne pratique de le mettre dans le repo.

Terry: Et donc d'avoir un ensemble de skills qui permettent ensuite d'être appelés de manière automatique par le LLM, qui ira chercher sur la base de skills.

Appeler des skills automatiquement et transformer un screenshot en composant HTML

Écouter à 27:59

Terry revient sur l’appel automatique des skills, en rappelant qu’au début le système se trompait parfois en appelant des skills qu’il ne fallait pas, ou l’inverse, alors qu’aujourd’hui la gestion autonome est bien meilleure. Katia explique comment des agents dans Slack et sur leur repo automatisent déjà plusieurs tâches, comme l’ouverture de PR quand un problème remonte sur les docs ou la mise à jour automatique de la documentation. Le chapitre présente aussi le skill « screenshot to component », qui prend un screenshot, s’appuie sur le code source de l’app et le transforme en composant HTML adaptable à partir de cette référence.

Terry: Et ça aujourd'hui, cet appel automatique, Il y avait aussi ça, le sujet de l'appel automatique des skills, qui est en fonction de l'évolution des modèles. Au début, c'était un peu moyen. Des fois, il y a des skills qui étaient appelés automatiquement. On ne voulait pas qu'ils le soient. Et inversement. Là, tu trouves que le niveau de gestion des skills en autonome, il est...

Katia: Ah, oui, c'est génial. Et c'est pour ça aussi que maintenant... On a aussi des agents dans notre Slack, par exemple, qui vont automatiquement ouvrir des PR lorsque un problème est remonté sur les docs. En fait, ces agents, ils tournent en général sur la DEV box, donc dans le cloud de quelqu'un de notre équipe. Et donc, Il y a aussi accès à ces différents skills pour justement faire les choses de la même manière. C'est nous qui l'avions fait directement. Donc ça permet d'automatiser plein de choses. Il y a plein de choses qu'on fait dans notre repo, qui dépendent de ses skills ou d'autres trucs tout simples. Typiquement, là, On a remplacé sur Land.jgpt.com toutes nos images par des composants HTML. C'est-à-dire qu'on n'a plus de screenshot du produit parce qu'en fait, le produit change. Tellement qu'on n'avait pas envie de reprendre des screenshots tous les quatre matins. Donc... On a ajouté un skill où tu prends un screenshot, tu lui dis « fais une illustration de ce truc-là » et dans le skill, tu donnes l'emplacement du monorepo qui contient le code de la Codex App et on donne le screenshot. Ensuite, Le modèle va pouvoir reconstituer à partir de ces deux choses-là une image de ce que tu as mis dans ton screenshot, mais c'est un composant HTML.

Terry: Donc, là, pour bien comprendre ce qu'il y fait, ce skill, Il ne va pas lancer un browser headless et en faire un screenshot. Il va inférer ce qu'on aurait vu sur notre browser. Pas sur notre browser, parce qu'on est sur l'app Descope, excuse-moi. Mais il va inférer ce que l'App devrait représenter.

Katia: Oui, c'est ça. Et on l'a aussi pour ChatGPT, l'app web. Donc, en fait, la personne qui veut ajouter un screenshot dans un guide, au lieu de prendre un screenshot qui, en plus, ne serait pas forcément aux bonnes dimensions, qui ne serait pas adaptable, Dark mode, Light, mode, qui ne serait pas responsif, etc. En fait, on dit aux gens, mettez juste un screenshot. Et ce skill, screenshot to component, va aller regarder le code source de l'app, Web ou desktop, va comprendre ce qui doit être dans l'image grâce au Screenshot et va créer le composant HTML en utilisant le code source comme référence.

Terry: Mais du coup, c'est dans le sens que le point d'entrée, le besoin que j'avais compris, c'est l'app, Elle évolue tellement vite, Tu veux du coup mettre sur... Ta feature page des nouvelles évolutions de ton app, Mais du coup, tu veux pas à chaque fois devoir aller reprendre les screenshots à la main, donc tu dis tel endroit, va me...

Katia: Du coup, après, imaginons qu'il y ait quelque chose qui change, on dit juste, voilà, Ce truc là a changé, mets à jour l'image et en fait, c'est un composant HTML. Et aussi, ça permet de faire des trucs du style, Si moi, par exemple, je prends un screenshot de la page plugins, moi sur ma page Plugins, il y a marqué OpenAI, Enfin, il y a les plugins de OpenAI, mais je veux pas que ce soit sur le screenshot des docs, je dis juste, enlève ça. Du screenshot. Et en fait, comme c'est un composant HTML, il enlève. Je peux réorganiser les plugins qui sont montrés. Donc, en fait, ça permet de modifier les images automatiquement. Et on a aussi un autre truc qui tourne sur notre repo toutes les semaines, qui va mettre à jour automatiquement les docs en fonction du code source de Codex pour voir s'il y a des choses qui ont été changées. Et il peut aussi mettre à jour les images. Typiquement, là, il y a Astra, qui est sortie. En fait, on veut que nos screenshots montrent Astra et pas qu'ils montrent 5.6 seul. Et donc ça, c'est un truc qui peut être fait automatiquement et on n'a pas besoin de reprendre de Screenshot.

Pourquoi les product managers codent directement dans le produit

Écouter à 32:01

Terry relance la discussion sur l’idée que, dans la tech, la vérité finit dans le code et demande à Katia quel intérêt il reste aux étapes intermédiaires comme les maquettes ou les PRD. Katia explique alors que, chez eux, les product managers codent avec Codex et vont directement implémenter dans le produit plutôt que de passer par des Figma mock-up. Elle décrit comment cette manière de travailler accélère les prototypes, les proofs of concept et les PR, au point qu’un product manager sans profil software engineer peut désormais contribuer directement. Katia oppose aussi cette approche à l’époque où il fallait encore valider longuement des Figma avant de toucher au code, alors qu’aujourd’hui on peut tester le vrai produit en quelques heures.

Terry: Yes, voilà, c'était ça, moi, le Use case que je voyais vraiment intéressant, c'est celui-ci donc ça m'emmène à tirer un peu le fil sur la notion, Après, on parlera un petit peu aussi de Chatgptwork sur des USe Case moins techniques. Mais sur cette notion, au final, dans la Tech, on dit souvent Code is law. Ou le fait du coup, que la vérité, au final, est effectivement toutes les fonctions intermédiaires. euh... Pour spécifier, le but, c'est qu'à la fin, ça arrive dans le code. Quand maintenant, on a une capacité à parler au code en langage naturel, Quel est l'intérêt d'avoir des étapes intermédiaires où on va avoir des maquettes, des PRD, etc. Quelle est un peu ta vision, toi, par rapport à ça, sur justement l'évolution de la construction de produits Tu as parlé des product Managers que vous avez aussi en interne, qui vont travailler avec ChatGPT Work Mais donc, le fait que maintenant, c'est ultra simple, en fait, de pouvoir aller faire des modifications ou avoir des infos sur ce qu'il y a dans le code. Les produits intermédiaires ou les étapes intermédiaires qui permettaient de faire le pont entre les deux, C'est quoi ton regard par rapport à ça ?

Katia: Nous, pour le coup, maintenant, tous les product managers codent avec Codex. Et au lieu de faire des prototypes et des Figma mock-up, ils vont directement l'implémenter dans le produit. S'ils ont besoin de faire un Proof of concept, ils vont faire une nouvelle branche. Ils vont dire, voilà, Je voulais faire ça. Donc, en fait, c'est vrai qu'on skippe un peu tout le côté maquette et intégrer sur une maquette, etc. On peut directement l'implémenter et ça ne coûte pas grand chose. En fait, ça ne coûte rien. En tout cas, ça coûte des tokens pour nous, pour le coup, en interne, ça ne coûte rien. Mais ça permet de voir beaucoup plus rapidement à quoi ça pourrait ressembler. Donc, là, typiquement, on a refait notre showcase avec toutes les démos. Et en fait, Je travaillais dessus avec un product manager qui n'a jamais été software. engineer, Mais au lieu de me donner un figma avec des exemples de à quoi ça pourrait ressembler, il a directement implémenté la nouvelle UI dans le code. Et d'ailleurs, ça a pas mal changé. On voit vraiment les progrès par rapport à il y a quelques mois, puisque je me souviens qu'il y avait un designer avec qui j'allais travailler. Il y a peut-être huit mois. Avant qu'il y ait tout, ça, avant qu'on fasse toutes les bonnes pratiques dont je te parlais, qui étaient de mettre le jugement dans le repo, etc. Tout ça, c'était vraiment les tout débuts. Et du coup, je me rappelle, Il y avait un designer qui m'avait envoyé une PR qui changeait plein de trucs. Et ce n'était pas du tout comme ça qu'il fallait le faire. Parce qu'il y avait pas mal. De data model impliqués. Il avait changé tous les data model, donc ça n'allait pas du tout. Et en fait, maintenant, ça ne se passe plus du tout. Maintenant, je reçois une PR d'un designer, d'un product manager qui n'a jamais été software engineer de sa vie. C'est parfait, en fait. Parfois, il y a quelques commentaires, mais sinon, Je n'ai rien besoin de faire. Donc ça, ça a vraiment changé beaucoup de choses dans la façon dont le produit est construit. C'est aussi pour ça qu'on va très vite dans le développement de produits. Là, l'équipe Codex, Je n'ai jamais vu une équipe aussi... Rapide de ma vie, c'est incroyable. On a sorti déjà les Codex Thursday, où en fait tous les jeudis, Il y a des nouvelles choses qui sont lancées sur l'app. Mais en fait, finalement, Il y a des nouvelles choses encore plus rapidement que ça. Parce que non seulement l'équipe Codex, C'est des ingénieurs qui sont tous très forts, mais en plus, ils ont Codex et donc en fait, Un ingénieur, Il peut faire tout un produit de A à Z en très peu de temps. Même un product manager peut faire un produit. Enfin, donc, ça permet d'itérer beaucoup, beaucoup plus vite qu'avant et de ne pas forcément passer par la case. Pierre dit, etc. Parce qu'en fait, pourquoi est-ce Qu'on faisait tout ça ? Parce que ça coûtait cher de construire. Donc, en fait, On voulait être sûr de ne pas se tromper. Moi, je me rappelle Quand je faisais ma startup, on faisait des Figma, On faisait valider les FIGMA en faisant plein d'interactions sur les FIGMA et qu'on faisait tester à des utilisateurs. Pour être sûr que c'était ça, le bon truc à construire avant de toucher du code. Parce qu'en fait écrire le truc en code, c'était le truc qui prenait le plus de temps. Aujourd'hui, ça, c'est plus possible. On ne peut plus se permettre d'itérer pendant des semaines sur un figma parce qu'en fait, on peut, Mais c'est bête entre Guillemets parce qu'on pourrait juste le faire en code et avoir le vrai truc et tester le vrai truc. Et ça ne coûterait rien. Et ça pourrait être fait en quelques heures.

Le rôle des product managers quand les ingénieurs peuvent tout prototyper

Écouter à 36:35

Katia explique que, chez OpenAI, les product managers sont peu nombreux par rapport aux ingénieurs et qu’ils servent surtout à canaliser ce qui se passe pour garder un ensemble cohérent. Elle détaille aussi leur rôle d’alignement et de priorisation, alors même que des prototypes peuvent être créés directement dans le produit avant d’être revus par un ingénieur. La discussion aborde enfin la place des PRD, des vision docs et la volonté de conserver une touche humaine dans les documents produits.

Terry: Et ce que tu partages, c'est effectivement un point hyper intéressant. Après, évidemment, vous êtes vraiment au devant, du devant, de la scène. Vous n'avez aucune limite sur les tokens. Il y a aussi des enablers derrière, Des choses qui vous permettent de le faire sans trop avoir d'enjeu à ce niveau-là. Mais du coup, c'est intéressant, parce que ça permet un peu de se projeter sur qu'est-ce que va être le futur. Du développement produit dans les années à venir, plus ou moins rapidement, en fonction aussi de l'adoption après des entreprises et de l'évolution derrière des différents profils, des jobs impactés. Je suis curieux de savoir, Du coup, vous, vos profils? product, product, manager, plus que product, engineer, donc les profils qui n'ont pas spécialement des backgrounds de software. engineer, au-delà de Prototyper en live, En faisant des branches sur la base de code pour montrer ce qu'ils veulent construire, Quelles sont un peu les choses sur lesquelles ils travaillent, Comment est-ce qu'ils bossent au quotidien Et peut-être que ça va nous permettre d'aller sur Chatgpt Work aussi, d'ailleurs, Je ne sais pas, mais en tout cas, de comprendre comment vous, Vos profils produits bossent.

Katia: En fait, le rôle des product managers chez OpenAI, déjà, Il y en a très peu par rapport au nombre d'ingénieurs. Ça va être, je pense, de canaliser un peu tout ce qui se passe et d'être sûr que l'ensemble est cohérent. Parce qu'en fait, quand tu as plein d'ingénieurs qui peuvent chacun construire leur propre feature, leur propre produit, de leur côté, sans communiquer avec les autres, etc. En fait, ça peut vite être le chaos. Donc, le rôle du product manager, c'est quand même hyper important. Ça va être d'aligner tout le monde, de prioriser les choses qu'on veut sortir en premier. Il y a pas mal de features qui sont un peu liées entre elles. où, en fait, Il y a besoin d'abord de construire telle chose pour, finalement, Cette feature-là, la construire de telle manière, au lieu de le faire avec... Avec ce qu'il y avait avant. Il y a pas mal de dépendance. Ça va être le rôle du product manager d'organiser tout ça. Il y a quand même un vrai travail là-dessus. Mais là où ça va être différent d'avant, c'est que s'ils veulent faire passer une idée, s'ils veulent faire un prototype, ils peuvent le faire directement dans le produit. Après, ça ne veut pas dire que ça va être lancé comme ça, sans être revu par un ingénieur. En général, il y a quand même beaucoup de dépendance technique. Qui ne sont pas forcément évidentes pour des gens non techniques, qui vont ensuite être peaufinés, etc. Mais là où il va y avoir besoin de faire des PRD, etc., C'est vraiment sur le côté. vision, produit, général, high level, où en fait, Ce n'est pas une seule feature, C'est quel est l'ensemble cohérent qui va permettre de faire en sorte que toutes ces features-là Que tout le monde est en train de développer, fonctionnent bien ensemble. Donc, c'est là où ils vont encore faire des documents, des PRD, des vision, docs, etc. Et d'ailleurs, Ce qui est marrant, c'est qu'on a un peu un truc où on veut quand même garder le contrôle sur ce qu'on écrit. C'est-à-dire que... On ne va pas forcément utiliser ChatGPT work pour écrire tous les documents pour nous, parce qu'on sent, Quand ça a été fait par un product manager humain, justement, il y a plus de... Enfin, je ne sais pas, Il y a une petite touche humaine qu'on veut garder. Et donc, on a ce truc de, On n'envoie pas des documents à des collègues si on n'est pas repassé derrière en tant qu'humain.

Terry: Yes. Du coup, pour rebondir là-dessus, les LLMs, ils sont très bons pour compacter de l'information. Pour compresser de l'information et, du coup, faire des one-pagers sur tout ce qui s'est passé sur la semaine. Et me dire un peu les points sur lesquels il faut que je me concentre, etc. Ils sont très bons pour, évidemment, Il n'y a pas de question sur l'écriture de code. Parce qu'ils ont pu s'entraîner sur les bases de code open source du monde entier. Et donc cette capacité de valider ce qu'ils font. Mais sur la génération de textes créatives, c'est là où la création du coup de contenu textuel, On sent, Comme tu viens de le dire, Quand ça a été écrit par l'IA, c'est quelque chose que l'on... Que l'on détecte assez rapidement en tant qu'humain. Et donc, après, on arrive vite à trouver que c'est moyen. Et à vouloir revenir à des cas où l'humain écrit, ou en tout cas, reprend ce qui a été écrit par l'IA. C'est quoi, du coup, sur cette partie vraiment de production de texte Comment... Tu as en partie répondu, mais je suis curieux de savoir comment est-ce que tu vois. L'évolution de LLMs par rapport à ce cas d'usage-là ? Parce qu'il y a aussi pas mal de produits qui se construisent autour de ça. Et je trouve qu'on... Enfin, pour moi, ça rend... Assez régulièrement dans ce qu'on peut mettre ai Slop, où c'est des produits qui vont faire des trucs moyens. Ça peut paraître au début. Le premier effet wow, Mais dès que tu commences à passer l'effet wow, tu te dis en fait, C'est pas top. C'est quoi un peu votre regard sur ça ? Sur l'utilisation de l'LM pour écrire du texte

Écrire sans AI slop avec des skills de style personnels

Écouter à 41:14

Katia explique que, pour éviter l’« AI slop », il faut d’abord repérer ce qui ne va pas dans un texte généré par l’IA et tenir compte du contexte. Elle décrit ensuite comment elle a codifié ses propres préférences d’écriture dans des skills afin que les modèles produisent des brouillons plus proches de sa voix. Elle raconte avoir demandé à Codex d’analyser ses discussions récentes pour résumer ses objections sur la manière d’écrire, puis d’intégrer ces remarques dans un skill comme « Write Practical, Copy ». Terry l’amène aussi à préciser comment elle obtient des posts LinkedIn ou des messages Slack qui sonnent comme elle, et Katia répond que le modèle regarde ses anciens messages ou ses précédents posts pour écrire dans sa voix. La discussion se termine sur l’idée que les modèles peuvent bien écrire si on leur donne le bon contexte, alors que par défaut ils produisent ce qui est le plus classique et le plus répandu. Terry et Katia évoquent enfin l’usage d’Astra dans le browser pour chercher et faire défiler des contenus sur X ou LinkedIn, sans que Katia puisse donner un nombre précis de posts nécessaires.

Katia: Pour moi, encore une fois, c'est une question de contexte et du coup, Ce que je dirais aux gens, c'est vraiment de noter tout ce qui va pas quand ils lisent. Un texte écrit par l'IA. Parce que c'est vrai, je suis d'accord que aujourd'hui... Si on demande à un modèle d'écrire un document sans contexte, ça va être du AI Slop. Enfin, tout le monde, après, n'a pas forcément la même sensibilité au AI Slop. Et je pense qu'il y a beaucoup de gens qui seraient totalement OK. Avec ce que moi, j'appelle du AI Slop. C'est compréhensible. Voilà, les idées sont claires. C'est juste qu'il y a quelques petits éléments, quelques petits tics de langage qui, moi, me font tiquer et dire « Ah, ça, ça, a été écrit par Delia et je n'aime pas » . Et il y a plein de gens, je pense. Même en interne, il y a plein de gens qui... C'est difficilement explicable, mais on arrive à reconnaître parce qu'on le voit tellement. Et du coup, on n'aime pas quand on s'est envoyé sans être relu avec un peu une petite touche humaine. Et du coup, moi, ce que j'ai trouvé pour un peu gagner du temps. Et justement pouvoir quand même écrire des documents avec de l'IA, Mais que ce soit quand même, ma voix, c'est d'avoir en fait, de créer mes skills personnels sur comment j'écris. Notamment, J'ai un skill... Qui s'appelle Write Practical, Copy, qui dit au modèle comment écrire du texte pratique. Et donc, J'ai pris tous les patterns que je n'aimais pas, mais ce n'est pas moi qui les ai écrits à la main. J'ai demandé à Codex d'analyser toutes les discussions que j'avais eues sur les deux dernières semaines, de regarder les fois... C'était les... Les discussions où soit? J'ai tiré sur un document, soit j'ai tiré sur un site web qui avait beaucoup de textes. Et donc, Je lui ai demandé de résumer toutes les objections que j'avais eues, tous les commentaires que j'avais sur sa façon d'écrire. Et avec le skill CreateSkill, en fait, On a un skill spécifiquement pour créer des skills.

Terry: Tu réponds à la question que je vais te poser après, qui était? Du coup, est-ce que tu as des conseils pour créer des skills

Katia: On a un skill extrait pour ça. Donc, je lui ai dit... J'ai utilisé ce skill-là et j'ai dit Regarde toutes mes sessions des deux dernières semaines où je fais des commentaires sur la façon, sur la copie. Et en fait, fais-moi Un résumé de tout ce qui va pas. Et donc, après, j'ai aussi ajusté quelques petits trucs à la main parce que je me disais Ah oui, c'est vrai que j'aime pas quand il fait ça. Mais il y a aussi cet autre truc-là que j'aime pas, donc tout ça. En fait, je l'ai codifié, je l'ai mis dans un skill et maintenant, quand je sais que je vais écrire de la copie. Enfin, quand il ne le fait pas automatiquement, en fait, je lui demande d'utiliser ça. Et souvent, c'est beaucoup mieux. Et après, si c'est pour un format particulier, par exemple, Si c'est, je demande d'écrire un post. LinkedIn, un message slack ou quelque chose comme ça. En fait, je lui demande de... Et maintenant, Il le fait automatiquement parce que je lui demande à chaque fois de regarder mes autres messages pour le faire dans ma voix. Et donc maintenant, C'est marrant parce que les Drafts qu'il crée pour que j'envoie, que je réponde à des gens sur Slack. En fait, parfois, Il dit des trucs. C'est vraiment ce que j'aurais écrit. C'est trop marrant parce que c'est Je ne sais pas, il met des émojis ou il parle comme moi. Parfois, il fait des petites blagues, un peu comme moi. Donc, en fait, C'est possible que les modèles écrivent bien et dans notre voix, et comme on veut. C'est juste que par défaut, ils ne vont pas le faire. Par défaut, ils vont faire ce qui est le truc le plus classique, le truc que tout le monde fait. Et c'est ça, en fait, qui fait que c'est du aislop. C'est qu'on le voit partout. Et donc, si on lui donne le bon contexte et qu'on codifie un peu tout ce qui nous dérange dans sa manière de parler naturelle. Et tout ce que nous, en fait, on aime mettre lorsqu'on écrit des choses, les fois d'après, ça va être beaucoup mieux.

Terry: Et c'est quoi un peu le volume, du coup, que tu lui as donné Typiquement, pour réussir à avoir la qualité de post LinkedIn. Que toi, t'aurais fait, toi-même, Tu lui as donné quoi ? C'est quoi ? C'est 50 100 100 post précédents ? 10 20 ? C'est quoi l'ordre de grandeur

Katia: Je ne sais pas, en fait. Je lui ai juste dit, regarde dans mes précédents post. Et donc, c'est lui qui regarde. Je ne sais même pas ce qu'il regarde, en fait. Parce que aussi, maintenant...

Terry: Mais tu laisses-toi coûter parce que pour le coup, il ne peut pas se connecter sur LinkedIn.

Katia: Maintenant, justement, c'est un autre truc dont on n'a pas parlé, mais Astra, Un des avantages principaux d'Astra, c'est qu'il est très bon. En Computer use, donc en utilisation des interfaces d'ordinateur. Et donc, quand je lui demande de chercher des choses sur X ou sur LinkedIn, en fait, Il va juste utiliser le browser et scroller, trouver des choses, cliquer, et le voir comme ça, en fait.

Terry: Ok. Ça ne te fait pas peur par rapport, justement, en fonction des plateformes Elles ont des termes sans condition, où ça peut être un peu touchy, parfois quand tu utilises justement des robots pour botter dessus. Après, là,

Katia: c'est toi qui es connecté. C'est toi qui es connecté et ils scrollent pour toi.

Terry: Donc, tu n'as jamais de souci où LinkedIn te dit attention, là, c'est Bot Detected ou ce genre de choses.

Katia: Il ne peut pas détecter que c'est un Bot vu que c'est dans mon browser.

Terry: Oui, à part si tu vas trop vite. Oui. Il y a quand même la vitesse avec... J'ai pas eu de problème pour l'instant,

Katia: j'espère que ça va se passer.

Terry: Yes. Non, mais parce que moi, sans même utiliser... Des outils comme ça. Avant, même l'ia générative, à un moment, Je me souviens, j'avais Unfollow plein de personnes rapidement. Et en fait, C'était juste moi. C'est que j'avais pris le pattern avec la souris, donc je cliquais super vite. Et à un moment, ça m'a bloqué. Ça m'a dit, pendant 72 heures, Je crois que je n'avais plus accès. Ça me disait, on pense avoir détecté un bot, alors que c'était juste moi qui cliquais trop vite. Mais c'est intéressant. C'est intéressant. Ce que tu dis, c'est qu'en fait, tu ne peux pas me dire. Le nombre de postes. Nécessaire parce qu'en gros, il est juste allé chercher, lui-même.

Katia: Après, par contre, pour le skill, qui était basé sur mes conversations, Je crois que je l'avais dit, regarde toutes mes conversations des dernières deux semaines. Il faisait beaucoup, mais je ne sais pas combien.

Chatgpt Work pour les présentations, les documents et les tâches personnelles

Écouter à 46:57

Terry propose de passer à un petit cas d’usage complémentaire, plus proche de Chatgpt Work, pour voir la nuance entre les deux. Katia explique ensuite que Codex peut faire tout ce que Chatgpt Work peut faire, avec surtout une différence d’interface et de manière de l’utiliser selon le contexte. Elle détaille enfin les tâches qu’elle fait avec cet outil, notamment des présentations, de l’écriture de contenu et plusieurs démarches personnelles liées à l’achat d’une maison à l’étranger.

Terry: Peut-être aller maintenant sur un petit cas, pas déroulé aussi longtemps que sur Codex, mais un petit cas d'usage complémentaire, ou, en tout cas, qui serait plus type Chat GPT Work pour voir un peu la nuance entre les deux.

Katia: Après, moi, du coup, j'utilise tout le temps. Codex. Pour être claire, en fait, Codex peut faire tout ce que Chatgpt Work peut faire. C'est la même chose, c'est le même harnais. C'est juste que l'interface va être différente quand on l'utilise en local. Après, la différence aussi, c'est que Chatgpt Work, On peut l'utiliser sur la version web de Chatgpt, où on a un petit toggle, on peut cliquer sur chat ou sur Chatgpt Work, On ne peut pas cliquer sur Codex. Mais les deux peuvent fonctionner dans le cloud, C'est juste que Codex, Moi, je l'utilise via l'app desktop. Mais donc, en fait, tout ce que je ferais dans Chatgpt Work, je le fais sur Codex et inversement. C'est juste une question, de préférence en termes de ce qu'on voit dans l'interface. Et, du coup, les tâches que je fais, qui sont plus work que code, C'est beaucoup créer des présentations parce que je fais pas mal de talk, ou de présentation où je dois aller faire des démos, etc. Ou écrire du contenu aussi, Je le fais beaucoup plus. Là, par exemple, Je suis en train d'écrire un blog post où je lui ai juste parlé, parce que maintenant, je ne fais que ça. D'ailleurs, je ne tape presque plus rien, je ne fais que la voix. Je lui ai juste brain-dub, Donc j'ai juste dit tout ce qui me passait par la tête pendant 10 minutes. Et il m'a aidé à structurer, à écrire, etc. Mais les présentations, en fait, avec Astra, pour le coup, C'est vraiment beaucoup, beaucoup mieux qu'avant. Parce qu'il a été entraîné spécifiquement sur ces tâches-là et notamment pour pouvoir respecter le design system d'un deck existant. Donc, c'est mieux quand on commence à partir d'une présentation existante, avec quelques slides déjà en place ou un template de présentation. Puisque là, en fait, Astra va être très bon pour réutiliser ce contexte-là et augmenter la présentation. Avec des visuels qui sont vraiment qualis, qui sont vraiment très bien. Là où, en fait, les modèles précédents pouvaient faire des présentations très bien, Mais ça arrivait que je dois repasser dessus manuellement, puisqu'en fait, il avait changé certaines choses, certaines polices. Donc, là, maintenant, J'ai beaucoup moins ce problème avec les présentations et je peux avoir des présentations très bien que j'ai à peine besoin de toucher. Sinon, après, pour des cas d'usage plus perso, J'ai pas mal d'admins à faire en ce moment. Notamment, Je suis en train d'acheter une maison à l'étranger. Et donc, du coup, en fait, Il y a énormément de choses que je ne connais pas là-dessus. Et du coup, là, J'utilise vachement Chatgpt Work en version web pour le coup. Où je lui demande de me créer. Des spreadsheets avec tous les coûts, toutes les taxes qu'il y aurait à l'étranger, faire tout plein de calculs en prenant en contexte les lois étrangères, dont je n'ai aucune connaissance, et notamment aussi revoir des documents. Je reçois pas mal de mails, de pas mal de personnes qui m'aident sur ce projet, architectes, etc. C'est Codex, c'est Chatgpt Work, en l'occurrence, puisque je le fais sur la version web. Qui gère tout ça pour moi, qui fait des drafts d'emails, qui envoie les documents, qui va chercher des documents qui étaient dans un autre mail envoyé par une autre personne, qui va les mettre dans mon drive au bon endroit, qui va partager le drive avec les autres personnes. Tout ça, ça permet de faire gagner énormément de temps. Et là, je ne l'ai pas encore utilisé trop pour remplir des formulaires, des grands formulaires, Mais je sais que c'est un USe case que beaucoup de gens ne savent pas adore. Parce que maintenant, sur Computer Use, Astra va presque deux fois plus vite. Et donc, là où? Avant, c'était un peu frustrant, Computer Use, Parce qu'on regardait le modèle, on le voyait cliquer à deux à l'heure sur les boutons, On se disait Bon, OK, je préfère le faire moi-même. Là, en fait, il va être vraiment beaucoup plus efficace et remplir sans faute plein de choses, tout en allant chercher du contexte ailleurs. Donc ça peut être vraiment très pratique lorsqu'il s'agit de remplir des formules en ligne. Là, pour l'instant, je n'ai pas encore à le faire, mais je pense que ça va... Ça va venir bientôt.

Ce que les équipes produit et tech sous-estiment encore

Écouter à 51:28

Terry ouvre la discussion sur les mécompréhensions autour de Codex et des produits similaires pour les équipes Product & Tech. Katia répond que le principal frein est une méconnaissance de tout ce qu’il est déjà possible de faire, et que des usages comme la recherche de contexte ou la création de livrables restent sous-utilisés. Elle explique aussi que beaucoup sous-estiment encore le temps gagné et la vitesse à laquelle on peut livrer de nouvelles fonctionnalités aujourd’hui.

Terry: Très clair. Ça montre vraiment les possibilités assez dingues. Ça pose quand même pas mal de questions sur le futur des jobs dans le product et la tech. Qu'est-ce que ça veut dire que de construire demain du software au-delà des personnes comme Toi qui sont au cœur de Builder. Des machines qui sont en train de réinventer complètement comment on construit des produits tech. Mais avant de te poser ces Katia, La première question que j'aurais pour toi, c'est en France et en Europe peut-être, Qu'est-ce que tu vois comme mécompréhension principale autour des produits comme Codex ou Usage, qui n'est pas bien compris ou sous-optimisé d'un produit comme Codex par des équipes Product & Tech ?

Katia: Je pense qu'en fait, c'est vraiment juste une méconnaissance de tout ce qui est possible de faire. Parce que, et ce que je comprends parfaitement, parce que ça a bougé tellement vite quand on regarde Codex. En janvier, Versus Codex, maintenant, depuis le début de l'année, c'est le jour à la nuit. Et même encore aujourd'hui, Il y a plein de nouvelles fonctionnalités. C'est dur de suivre. Même pour nous, qui travaillons, c'est le métier de savoir, C'est dur de suivre. Parfois, d'une semaine à l'autre, Il y a des nouvelles choses. On pensait que ça sortirait dans trois semaines. Finalement, c'est maintenant. Donc, c'est difficile de savoir ce qu'il est possible de faire ou non. Je pense qu'une méconception que j'ai vue en parlant notamment à des gens qui n'était pas du tout dans la tech, pour le coup, C'est ce côté que, en fait, Chatgpt Work peut faire vraiment beaucoup de choses pour nous, notamment aller chercher du contexte avec tous les plugins, donc aller chercher du contexte dans Drive, dans les emails, dans les canaux de communication, et créer, en fait, Des livrables qui sont de très haute qualité. Ça, Je pense que c'est quelque chose qui est sous-utilisé. Et après, sur le côté... tech. Je pense qu'il y a encore une méconception sur le fait que il y a encore beaucoup besoin de repasser derrière. En gros, il y a quelques mois, je me rappelle, J'avais beaucoup cette discussion et c'était vrai, pour le coup, il y a six mois, Je dirais. Il y avait beaucoup de gens qui me disaient que ça créait plus de travail que ce qu'on croit, parce que finalement, On passe beaucoup plus de temps à revoir. Ce que des gens qui ne sont pas forcément hyper techniques ou qui n'ont pas forcément de contexte sur le produit ont Vibe codé. Et donc, ça nous prend plus d'énergie qu'autre chose. Mais en fait, maintenant, Si on met en place les bonnes pratiques dont je parlais tout à l'heure, ça fait gagner un temps fou. Et je pense que les gens sous-estiment encore à quel point ça fait gagner un temps fou. Moi, je suis... Outré, par à quel point? C'est rapide de développer des nouvelles choses. Des choses qui sont très ambitieuses. Là, typiquement, la semaine dernière, ou il y a deux semaines, Je ne sais plus, On a sorti ChatGPT Training sur notre site, learn.chatgpt.com. Et ça, en gros, Il y avait une autre personne avec qui je travaillais, qui avait fait un prototype sur un autre site, qui était très cool, son prototype. Et après, moi, j'ai utilisé une librairie qu'on a, qui est une sorte de mini version de Codex, qui est basée sur le code source de Codex, mais qu'on met dans nos docs pour pouvoir interagir avec. J'ai juste dit, prends ce truc-là, prends le prototype, et prends du contenu qui m'avait été envoyé par d'autres personnes, et fais cette nouvelle feature qui est quand même un truc qui, normalement, aurait pris des semaines à faire. C'est un truc qui est assez interactif. Il faut le voir pour comprendre, mais en gros, c'est un training pour les débutants. C'est un scénario où on nous dit qu'il faut cliquer là, ça entoure les choses où cliquer sur l'écran, etc. Et ça, C'est des choses qui auraient pris beaucoup de temps à faire. Et là, j'ai pu le faire en juste quelques jours, en prenant en compte la review, etc. Donc, c'est maintenant, on peut shipper des choses en quelques jours, alors qu'avant, c'était des semaines et des semaines. Et je pense que les gens ne se rendent pas compte encore que ça, c'est possible aujourd'hui.

Terry: Yes.

UI générative, agents et nouveaux critères de réussite produit

Écouter à 55:28

Katia explique que la tech n’est plus un frein et que les équipes peuvent désormais imaginer des expériences nouvelles, avec des interfaces de plus en plus personnalisées. Elle décrit aussi l’UI générative, où des composants HTML sont créés à la demande, et le besoin d’adapter l’interface aux utilisateurs comme aux agents, notamment via des connecteurs comme WebMCP. Enfin, Katia et Terry insistent sur de nouveaux critères de réussite produit, où l’ambition, le taste et la capacité à guider les modèles comptent davantage, tout en posant la question des parcours pour les profils plus juniors.

Terry: Du coup, ça m'amène à la question de... C'est quoi? Pour Toi, l'évolution future de la construction, les jobs qu'on va voir pour fabriquer des produits tech Comment l'intelligence va se déplacer ? Qu'est-ce que toi, tu peux anticiper Je trouve que c'est quand même compliqué, comme tu le disais, c'était il y a longtemps, Tu parles de semaines, Ça montre le rapport au temps qu'on a en ce moment. Et en même temps, il y a à chaque fois des breaking change qui font qu'un truc que tu pensais impossible. Boum, ça y est, ça fonctionne et ça fonctionne bien, donc c'est quand même difficile. Malgré tout, personne n'a de boule de cristal. Bon, je le répète. On enregistre cet épisode du coup en septembre 2026. Mais à date toi, quelles sont? Un petit peu peut-être les tendances que tu vois sur l'évolution des rôles Product and Tech. Justement, dans cet univers post-IA génératif peut-être aussi avec tes connexions que tu as à côté. San Francisco est-ce que tu peux voir là-bas qui commence à un peu peut-être se de... Se settle, même si c'est difficile de voir les choses se calmer en ce moment.

Katia: Je pense que maintenant, en fait, La tech n'est plus un frein. C'est-à-dire qu'avant, il y avait beaucoup de décisions qui étaient prises en fonction de ce qui était réalisable, ce qui était faisable. Maintenant, pour moi, ceux qui vont avoir un edge en tant que personnes, produits ou personnes tech, C'est ceux qui vont pouvoir se projeter et sortir des choses établies et imaginer des expériences nouvelles sans avoir cette contrainte de « c'est pas possible parce que c'est trop compliqué techniquement » . Notamment, Je pense que les interfaces vont être de plus en plus personnalisées aux utilisateurs. On le voit déjà avec... Nous, d'ailleurs, On a sorti un plugin qui s'appelle Visualize, qui, en fait, est de l'ui générative, c'est-à-dire que quand on demande quelque chose, il y a des composants HTML qui vont être générés sur le moment. Pour s'adapter à ce que l'utilisateur veut voir. Je pense que ça, c'est quelque chose qui va être de plus en plus vrai. Et d'ailleurs, C'est marrant parce que j'ai l'impression que ça fait deux ans que j'en parle, de l'UiGénératif, en disant, Pour moi, c'est le futur, etc. Et pour l'instant, Je ne l'ai pas trop vu. C'est-à-dire qu'il y a encore des apps qu'on utilise. La plupart des apps, en fait, C'est une UI pour tout le monde. Alors qu'en fait, quand on y pense maintenant, pourquoi est-ce qu'on aurait la même UI pour tout le monde ? Il faudrait que l'UI s'adapte aux utilisateurs. Il faudrait qu'aussi l'UI s'adapte aux agents. C'est-à-dire que maintenant, Il y a beaucoup plus de gens qui ne vont pas aller directement sur les apps, que ce soit Web ou mobile, Ils vont passer par leur agent pour faire des tâches. Et donc ça, ça veut dire avoir des connecteurs en place, notamment avec WebMCP, qui font que les agents puissent utiliser ton service de manière fluide, parce que peut-être que les gens n'ont pas envie de s'adapter à ton app. Après, je pense qu'il y a aussi beaucoup de... De USE Case où, en fait, c'est l'interface qui compte, l'app, L'expérience utilisateur est hyper importante parce que, justement, l'utilisateur ne cherche pas à parler à un agent. Mais il cherche à avoir un truc très visuel qui correspond exactement à ce qu'il veut. Donc, je pense qu'il y a encore beaucoup de cas d'usage où, en fait, il y a quelque chose à construire. Il y a une app à faire, Il y a une expérience utilisateur intéressante à aller chercher, mais pour moi, c'est hier. Des choses qui doivent être un peu nouvelles. Maintenant, les listes ou les cards qui, juste stockent de la data, est-ce que c'est assez pour faire une app versus penser vraiment, c'est quoi l'expérience idéale pour l'utilisateur et la construire, parce qu'en fait, maintenant, c'est juste possible. Avant, on se freinait. Maintenant, il faut être ambitieux. Et pour moi, ceux qui vont vraiment réussir dans les carrières productives, c'est ceux qui arrivent à être ambitieux, qui ont aussi ce qu'on appelle du taste, On parle beaucoup de taste en ce moment, mais en fait, pour moi, c'est ça qui reste fondamentalement humain. C'est de savoir dire OK, ça, c'est bien, ça c'est pas bien. Et donc avoir ce taste là et savoir guider les modèles pour qu'ils créent quelque chose qui soit vraiment novateur et vraiment cool. En fait, pour les humains, c'est ça qui va compter le plus.

Terry: Très clair, je te rejoins là-dessus, on parle aussi dans le produit Product Sense, Taste comme tu dis et c'est une compétence qui a Merci. Ce qu'il y a de compliqué, c'est plus pour des profils plus juniors, c'est comment ils vont réussir à construire ce test-là, là où avant, il y avait des tâches peut-être à plus faible gel à rajouter qui leur permettaient de se créer l'expérience. Là, C'est vrai que c'est l'enjeu aussi, qu'il y a derrière, C'est comment tu fais pour emmener tout le monde autour de ça. Je pense qu'une des réponses, en tout cas, c'est de se dire de commencer à construire le plus tôt possible des choses. Pour aussi prendre en main ces nouveaux outils et, au fur et à mesure, construire son expérience de manière un peu différente.

Alignement des modèles et limites à ne pas franchir

Écouter à 1:00:20

Terry ouvre cette fin d’échange en demandant à Katia s’il reste un sujet à mettre en avant, et Katia revient sur l’alignement des modèles comme un point appelé à devenir de plus en plus important. Elle explique qu’Astra est à la fois le modèle le plus puissant et le plus aligné, conçu pour éviter de dépasser les limites même face à des tâches difficiles ou impossibles. Katia évoque aussi l’incident Hugging Face, les outils développés en interne et des benchmarks où Astra reste dans les limites, contrairement à Sol dans une partie des cas.

Terry: Avant d'aller vers mes questions de fin d'échange, est-ce qu'il y a un sujet dont on n'a pas parlé, un point que tu veux mettre en avant, un message à faire passer

Katia: Il y a beaucoup de choses. En fait, c'est juste qu'il y a tellement de choses nouvelles tous les mois. que, bien sûr, On n'a pas le temps de tout couvrir. Je pense qu'un truc qui est intéressant à dire, c'est que peut-être Astra, C'est notre modèle qui est le plus puissant actuellement, mais aussi qui est le plus aligné. Et ça, C'est un sujet qui va devenir de plus en plus important, je pense. Mais au fur et à mesure que les modèles deviennent de plus en plus capables, Il faut aussi s'assurer qu'ils soient alignés avec les valeurs humaines. Et donc, on l'a vu là, par exemple, avec l'incident Hugging Face, où des modèles ont voulu réussir à tout prix leurs tâches et donc sont un peu sortis des limites, enfin un peu beaucoup sortis des limites qui étaient imposées parce que ça leur permettait de réussir la tâche qui leur a été donnée. Et donc, en fait, Astra, C'est notre modèle le plus aligné qui va justement éviter ce genre de choses. Et donc, On voit, par exemple, par rapport à Sol, notre modèle d'avant, que devant des tâches qui sont difficiles, impossibles, Plutôt que d'essayer de passer à travers les mailles du filet et de trouver des solutions un peu créatives qui permettent d'atteindre le résultat final, en fait, Astra va préférer s'arrêter. clarifier, Être sûr que la personne qui donne les instructions est OK, avec ce que le modèle fait, plutôt que de continuer. Donc ça, Je pense que c'est hyper important. Et c'est quelque chose dont on ne s'en rendait pas forcément compte avant, parce qu'on pensait que nos modèles étaient... On ne se rendait pas compte à quel point ça pouvait être un problème, parce que les modèles étaient moins capables. Mais à partir du moment où on a des modèles capables, et s'ils font des choses non alignées, ça peut avoir... Sur le monde réel. Là, on a fait un gros focus et on a développé plein d'outils, plein de choses en interne qui nous permettent de s'assurer que nos modèles, Non seulement ils sont très puissants, mais aussi, Ils ne vont jamais essayer de faire quelque chose qui n'est pas OK, d'un point de vue humain. C'est-à-dire qu'en fait, c'est une sorte de jugement interne où en fait, si on nous demande de faire une tâche et qu'on sait que pour accomplir cette tâche, on aurait besoin de faire des choses qui ne sont pas très... très, j'allais dire pas très catholiques, qui ne sont pas ok, en fait, On ne va pas le faire.

Terry: Qui ne sont pas alignés avec nos valeurs, la manière dont on veut travailler.

Katia: Et donc, en fait, Le fait d'apprendre ça au modèle, c'est très compliqué, mais on a fait un vrai travail là-dessus. Et Astra, On a vu que sur des benchmarks, justement, qui avaient été inspirés de l'incident. Avec Hugging Face, d'ailleurs, On a écrit un super article sur le sujet, qui est passionnant. Je recommande à tout le monde de le lire. Sur ce qui s'est passé avec l'incident de Green Face. Et en fait, ça, Ça a inspiré un Benchmark où on a vu que dans presque 50% des cas, 48% Il me semble, sol, aller au-delà des limites qui étaient imposées, Alors qu'Astra, dans 0% des cas, il a pris des chemins qu'il n'aurait pas dû prendre. Donc ça, Je pense que c'est hyper important et ça veut dire qu'on va dans la bonne direction.

Terry: Top, très clair.

Faire découvrir les fonctionnalités et les faire adopter

Écouter à 1:03:46

Terry introduit l’affirmation selon laquelle la capacité à faire découvrir et adopter les produits et les fonctionnalités est le nouveau point de blocage des équipes Product et Tech. Katia répond en expliquant que c’est justement son travail en Developer Experience, avec pour enjeu de faire connaître ces fonctionnalités à un public plus large et de partager des usages, notamment via l’équipe, des ingénieurs et du training.

Terry: Maintenant, pour aller vers mes dernières questions de fin d'échange, Donc tu es la première à ouvrir le bal sur... Trois questions. Jusqu'à présent, Je vais en poser deux. Donc, La troisième, c'est parce qu'en fait, il y a une personne, la personne que j'ai reçue avant, Du coup, qui a laissé une affirmation sur laquelle il va falloir que tu dises oui, non et que tu justifies par rapport à cette affirmation. Donc, je vais commencer avec ça et ensuite, je te poserai mes deux questions classiques. Donc, l'affirmation, c'est la capacité à faire découvrir et adapter les produits et fonctionnalités. C'est le nouveau limitant des équipes. Product & Tech. Pardon, la capacité à faire... Découvrir et adopter les produits features des produits, c'est le nouveau limitant des équipes ProduitTech. Faut-il plus de product? Marketing Manager

Katia: Justement, c'est typiquement mon job. Pour le coup, dans l'équipe. Developer Experience, Comme je disais, on s'appelle developer Experience, mais au final, Notre audience est beaucoup plus large que ça. C'est vraiment notre but, C'est comment est-ce qu'on fait découvrir ces fonctionnalités, et comment est-ce qu'on s'assure que tous ces use cases qui sont... Un peu à la frontière de ce qui est possible, le plus de gens possible en bénéficient. Et donc, après, On travaille avec des product Marketing managers, mais ce n'est pas forcément Product Marketing Manager. Qui est la réponse à ça. C'est nous, on le fait beaucoup dans notre équipe. Il y a aussi beaucoup qui est fait grâce à des ingénieurs, notamment Thibaut, qui est le lead, surtout, Codex ChatGPT Work, qui est... Il lead Toutes les équipes qui travaillent sur ces produits-là. Il est aussi très visible sur Twitter et il fait découvrir pas mal de choses grâce à sa présence sur Twitter. Il a aussi le product manager de la Codex App, Enfin Codex H-A-G-P-T Work App, donc l'app desktop. Andrew est aussi très présent et communique vachement, ce qui permet de donner beaucoup de visibilité à des choses qui seraient sinon passées inaperçues. Après, le problème de ça, c'est que c'est sur Twitter et que malheureusement, en dehors de San Francisco, Il n'y a pas tant de gens que ça qui sont au courant. Et donc, C'est là où, en fait, Il y a d'autres efforts qui sont mis en place. Là, typiquement, le training dont je te parlais, C'est quelque chose qu'on a créé pour justement partager aux plus de personnes possibles, y compris les débutants qui n'ont jamais utilisé l'app. Comment est-ce qu'on peut faire certaines choses qui sont des fonctionnalités assez avancées ? Et donc, c'est vraiment le challenge du moment. Parce que, comme on disait, ça évolue tellement vite que c'est impossible pour une personne normale de suivre tout ce qui se passe. Surtout que déjà, pour nous, c'est dur de suivre sur ce qu'on fait, nous, Mais il y a beaucoup de gens qui veulent aussi suivre tout ce que font tout le monde. C'est-à-dire pas juste OpenAI, mais toutes les entreprises qui sont dans ce domaine-là. Et donc là, ça devient vite très dur. De suivre tout ça. Il y a des gens qui arrivent, mais je pense que c'est des gens qui passent leur journée sur Twitter et je recommande à personne de faire ça. Et du coup, Le challenge, c'est où est-ce qu'on trouve l'information En fait, Ce que je dirais, c'est que ce n'est pas forcément nécessaire de savoir tout ce qui se passe. Et d'être au courant des dernières fonctionnalités qui viennent de sortir la semaine dernière. C'est bien, Si ça intéresse les gens de savoir, ils peuvent trouver l'information, mais en fait, Ce qui compte, c'est plus est-ce qu'on comprend de manière générale comment ça fonctionne ? Est-ce qu'on l'utilise au quotidien pour ses propres tâches ? Ce qui nous intéresse, nous, en fait. Ouais, ça répond à moitié à la question. La question, c'était est-ce qu'il faut plus de product. Marketing, manager ? Enfin,

Terry: à la base, Le point, c'est de faire une affirmation. Donc, là, ça a été tourné en affirmation, mix, question. En fait, c'était de dire qu'en gros, la capacité à faire découvrir et adopter des produits, c'est le nouvel irritant des équipes Product tech. Donc ça, tu partages, ça. Et après, ce qu'il y avait, c'était du coup, est-ce que la solution, mais l'affirmation, c'était ça. Et avec une solution que toi, t'élargis au sens, pas juste product, marketing, manager, Mais tous ceux qui peuvent mettre en avance tout ce que permet de faire le produit.

Katia: Mais c'est vrai que le contenu... Devient beaucoup plus important. Et c'est marrant. Parce que parce que oui, en fait, avant, c'était un peu les ingénieurs qui étaient le truc le plus important dans une boîte. Ça reste très important. Mais en fait, avant le vrai sujet, c'était est-ce Qu'on peut construire des features, construire des produits. Et pour ça, on avait besoin de plus d'ingénieurs, Maintenant, ça, c'est facilité. Donc on arrive beaucoup plus à construire des produits et des features beaucoup plus facilement et beaucoup plus rapidement. Et du coup, le vrai sujet, c'est maintenant Est-ce que le marketing et le fait de faire connaître ces choses-là, ça devient le truc le plus important et le vrai souci ? Et d'ailleurs, c'est marrant parce qu'il y a eu pas mal de bruit sur Twitter, récemment, sur le marketing. Je ne sais pas si tu as vu, ça. Non, vas-y. Si les gens qui écoutent ont vu. Non, mais bon, Il y a eu pas mal de sujets. Notamment, il y a une boîte d'assurance qui s'appelle Corgi, qui a créé... Enfin, il y a eu tout un... Un truc autour des personnes qu'ils avaient employées, qui étaient majoritairement des femmes, pour faire du marketing. Et il y a plein de gens qui disent, « Bah ouais, en fait, finalement, maintenant, le vrai truc, le vrai différentiel, c'est à quel point on est visible. » Et donc, ça vaut le coup d'investir sur plein de personnes qui vont faire du marketing. Après, bon, moi, Je pense qu'il y a d'autres manières de faire du marketing, mais c'est vrai que c'est un sujet qui revient beaucoup, en fait, en ce moment, qui est beaucoup sur le devant de la scène, est très présent dans... Dans les très présents, chez les personnes, tech, en fait, qui se demandent quel est le prochain vrai sujet, quoi. Quel est le prochain rôle le plus important

Terry: Yes.

Pourquoi les juniors ne sont pas les perdants de cette transformation

Écouter à 1:09:31

Katia explique qu'elle ne pense pas que les juniors vont avoir plus de mal à entrer dans la tech. Selon elle, des outils comme Codex automatisent aussi des tâches de seniors, et ce qui compte vraiment, c'est le taste, la créativité et la capacité à penser hors des sentiers battus. Terry nuance en disant que cela vaut à condition que les juniors utilisent ce temps pour construire cette nouvelle expertise plutôt que de simplement se déléguer le travail.

Terry: Pour aller, du coup, vers les deux dernières questions. maintenant, donc la suivante, C'est est-ce que tu as une conviction forte avec laquelle tu es en général en désaccord avec Tes Pairs

Katia: Ouais, alors, c'est marrant parce que tu parlais des juniors tout à l'heure et moi, Je pense que c'est pas vrai que les juniors sur vont avoir plus de mal à rentrer dans la tech. J'ai beaucoup de personnes qui me posent ces Katia, qui disent, mais du coup, avec tout ça, qu'est-ce que ça veut dire pour les juniors ? Parce qu'avant, les juniors, ils faisaient les tâches plus simples qui sont aujourd'hui automatisées. Je trouve que ce n'est pas forcément le cas parce que déjà, aujourd'hui, Codex peut automatiser des tâches qui sont aussi des tâches de seniors, qui sont des choses que des personnes qui, auparavant avaient 20 ans d'expérience, pouvaient écrire et il le fait mieux. Donc, en fait, ce n'est pas... Le sujet de est-ce qu'on a de l'expérience ou pas. Pour moi, le vrai sujet, c'est justement, on en parlait, le taste, la créativité et le fait de savoir penser en dehors des sentiers battus, en fait. Et ça, pour moi, c'est complètement décorrélé du fait d'être junior ou pas. Parce que, justement, les seniors, tous, Ils ont de l'expérience, Mais s'ils continuent à se baser uniquement sur l'expérience existante, donc sur des choses qui ont déjà été faites, en fait, finalement, Ça devient moins intéressant que quelqu'un qui viendrait avec une vision toute nouvelle et qui penserait à des choses que la personne senior n'aurait pas considérées. Parce qu'en fait, il ne l'a jamais vue. Donc, pour moi, c'est vraiment le fait d'être ambitieux dans ses idées, créatif et d'aller plus loin que l'existant, qui fait vraiment la différence. Et donc, Je pense qu'au contraire, des outils comme Codex, Ça équipe ces juniors avec des... De l'expérience en fait packagée, Ils n'ont pas besoin de savoir comment tout fonctionne, ils n'ont pas besoin d'avoir déjà réglé. X. Bug. 20 fois. Parce que, en fait, Codex va s'en servir. Codex va le faire pour eux. Et donc, en fait, il y a. Pour moi, c'est limite mieux d'être junior aujourd'hui que d'être junior il y a 20 ans.

Terry: Intéressant, comme point de vue sur certains points, je rejoins ce que tu dis sur le fait de pouvoir penser hors des sentiers battus. Après, c'est sous réserve. Moi, ce que je compléterais par rapport à ce que tu viens de dire, C'est sous réserve que les juniors décident de mettre leur temps sur justement penser en dehors du cadre et pas juste se déléguer, se dire C'est bon, Le TAF est fait. Du coup, c'est passer son temps sur une nouvelle expertise qu'ils vont construire, qui n'est pas la même expertise qui était nécessaire il y a encore quelques années. Pour aller vers ma dernière question, quelles sont les choses qui te nourrissent intellectuellement ? Comment est-ce que tu progresses ?

Katia: C'est une question très large. En fait, Je m'ennuie très vite, donc j'ai besoin de tester plein de choses tout le temps. Et donc, je dirais, Ce qui me nourrit intellectuellement, c'est de faire des expériences, tester des choses et donc apprendre des nouvelles choses de cette manière. VOIR AUSSI Ce que d'autres personnes créent et font pour que ça me donne des idées. Notamment dans mon équipe, c'est trop cool, parce que tout le monde est hyper créatif et justement pensant d'avoir des scientifiques là-dessus parfois je vois des choses qu'ils font et je me dis ah ouais c'est vraiment trop bien et donc le fait de voir des gens créer des nouvelles choses et moi de tester des nouvelles choses, expérimenter c'est ça qui va me nourrir intellectuellement

Terry: Yes, le biais de l'action, le fait de construire et de t'exposer du coup, ça va je pense qu'en termes de de changement, c'est pas mal chez OpenAI en termes de rapidité. Oui, c'est cool. Je m'ennuie pas,

Katia: pour une fois.

Terry: Super. Merci encore pour ton partage, Katia, et à bientôt.

Katia: Merci à toi.