Une responsable produit chez OpenAI nous explique comment l’IA transforme la gestion de produit aux plus hauts niveaux

Kathy Korevec est une créatrice qui a travaillé en tant que directrice produit chez Google Labs AI, vice-présidente Produit & Design chez Vercel et directrice principale de la gestion produit chez GitHub, entre autres. Elle travaille actuellement sur Codex chez OpenAI. Le fil conducteur de son parcours est la création d'outils pour développeurs, avec une attention constante portée aux utilisateurs et aux détails.

Nous nous sommes entretenus avec Kathy pour comprendre comment l’IA transforme la gestion produit dans les plus grandes entreprises technologiques au monde. Voici ce qu’elle avait à nous dire.

Être un « chef qui cuisine pour des chefs »

J’ai toujours été une créatrice avant d’être une cheffe de produit.

J’ai commencé dans les outils pour développeurs, chez Heroku, GitHub et Vercel notamment, ce qui correspond à une approche très particulière de la gestion produit. Il ne s’agit pas seulement de livrer des fonctionnalités ; il faut créer des produits pour des personnes qui savent immédiatement lorsque vous avez bâclé quelque chose. C’est comme être un chef qui cuisine pour des chefs. Le niveau d’exigence est élevé, et ils remarqueront absolument si votre sauce n’est pas réussie.

Certains de mes meilleurs souvenirs en tant que PM n’avaient rien à voir avec le « travail traditionnel d’un PM ». Chez GitHub, j’ai réécrit des parties de la documentation et j’ai même repensé le site pour refléter mon approche fondée sur mes principes de DX. J’ai consacré des week-ends à refactoriser mon propre site web pour gagner quelques centaines de millisecondes, parce que ses performances me dérangeaient. J’ai contribué à un projet appelé Papercuts, dans le cadre duquel nous avons corrigé des centaines de petites irritations, car ce sont ces détails qui déterminent si les utilisateurs adorent votre produit ou le tolèrent.

C’est en quelque sorte le fil conducteur de mon parcours. Je ne considère pas que le rôle des PM consiste simplement à repérer les lacunes et à les combler, ou à être le « PDG de son produit ». Je le vois plutôt comme le fait de se rapprocher des détails jusqu’à en devenir presque mal à l’aise. Suffisamment pour commencer à se soucier de choses qui n’apparaissent pas sur une feuille de route.

Et nous voici maintenant dans cette ère de l’IA, qui ressemble honnêtement un peu au fait de donner un jetpack à tout le monde en espérant que personne ne foncera dans un arbre.

Je passe beaucoup de temps à coder au feeling le soir et le week-end, en créant de petits outils rudimentaires avec des agents d’IA. On peut passer d’une idée à un produit fonctionnel en un après-midi, ce qui est incroyable. En même temps, les fondamentaux sont plus importants que jamais. Comprendre les systèmes, les compromis et le fonctionnement réel des choses en coulisses est ce qui distingue un projet qui est livré d’un projet qui dure.

Sinon, on finit avec un cimetière de projets inachevés et de bugs mystérieux.

Mon parcours jusqu’à ce moment n’a donc pas vraiment consisté à changer ma façon de travailler. Il s’agit plutôt de la renforcer. Rester proche du métier. Et construire moi-même les choses.

Réduire la distance entre l’idée et la validation

Jusqu’à très récemment, je dirigeais le produit pour une équipe de Google Labs appelée AIDA, ce qui signifiait « Assistance aux développeurs par l’IA ».

Nous travaillions à un niveau assez profond de la pile. Des premiers modèles de codage aux données d’entraînement pour le code qui alimentait Gemini, puis en remontant dans la couche d’abstraction vers des produits comme Colab Composer et Jules. Nous sommes passés de « Pouvons-nous générer du code ? » à « Pouvons-nous réellement aider les gens à créer des logiciels complets, de bout en bout ? »

L’organisation que je dirigeais était donc véritablement hybride. Une partie recherche, une partie produit, et une partie « Nous allons livrer quelque chose de rudimentaire cette semaine et voir si quelqu’un l’utilise ». Nos utilisateurs allaient des développeurs professionnels aux personnes n’ayant jamais écrit une ligne de code, ce qui constitue un public exigeant, car il faut répondre simultanément à des besoins de profondeur et d’accessibilité.

Le modèle de livraison reflétait cela. Beaucoup d’itérations rapides, des boucles étroites entre les capacités du modèle et l’expérience produit, ainsi que la volonté d’abandonner certaines choses si elles ne trouvaient pas leur public. Il s’agit moins de suivre une feuille de route que d’explorer avec intention.

Je travaille maintenant chez OpenAI, sur Codex, ce qui représente une sorte de retour aux sources. Codex a commencé comme un modèle et évolue désormais vers un agent et une couche applicative au sein de ChatGPT, qui aide concrètement les utilisateurs à accomplir leur travail. Écrire du code, automatiser des flux de travail, relier des systèmes entre eux.

Dans les deux cas, le fil conducteur est donc le même : créer des outils qui réduisent la distance entre une idée et quelque chose qui fonctionne dans le monde réel.

Pourquoi les PM devraient se concentrer sur un développement produit guidé par les prototypes

J’ai cessé de considérer les spécifications comme le principal livrable du travail produit. C’est un changement que j’avais déjà commencé à opérer, mais l’IA l’a accéléré.

Au début de ma carrière, notamment chez GitHub et Heroku, j’ai compris à quel point l’élan était important. L’utilisation réelle est importante. On apprend davantage d’une chose en production qu’on ne le fera jamais d’un document parfaitement rédigé.

Ce que l’IA a fait, c’est pousser cette philosophie encore plus loin en la condensant.

Désormais, au lieu de rédiger une longue spécification et d’en débattre pendant une semaine, je construis moi-même une version approximative du produit. Ou je code intuitivement un prototype en un jour ou deux. Quelque chose sur lequel on peut cliquer, qu’on peut casser et auquel on peut réagir. Cela change tout.

On passe de « Que pensons-nous qu’il va se passer ? » à « Que se passe-t-il réellement lorsqu’on utilise cette fonctionnalité ? » Cela transforme beaucoup de débats abstraits en quelque chose de concret.

Cela change également le rôle du responsable produit. Il ne s’agit plus seulement de façonner des idées ; il faut les mettre directement à l’épreuve. On est plus proche de la mise en œuvre, ce qui permet de repérer plus tôt les mauvaises hypothèses.

Le résultat, c’est bien sûr la rapidité. Nous livrons plus vite, nous abandonnons plus vite les idées et nous améliorons plus vite les bonnes.

Le changement le plus important, toutefois, est que nos décisions sont plus honnêtes.

Pourquoi les inconvénients de l’IA sont subtils, mais importants

Mais il y a certainement des inconvénients.

L’un d’eux est ce que j’appellerais une « fausse vitesse ». On a l’impression d’avancer incroyablement vite parce qu’on produit beaucoup de choses. Du code, des prototypes, des documents. Mais tout cela n’est pas forcément bon ou utilisable. On peut générer une grande surface fonctionnelle sans réelle profondeur.

Un autre problème concerne la qualité et la confiance. Le code généré par l’IA peut être étonnamment bon tout en étant, avec assurance, erroné. Si l’on ne comprend pas ce qui se passe sous le capot, on peut finir par livrer des éléments fragiles, non sécurisés ou difficiles à maintenir.

Et puis il y en a un plus subtil. Il n’a jamais été aussi facile de commencer des choses. Il n’est pas forcément plus facile de les terminer correctement. Nous allons voir beaucoup plus de produits à moitié construits, de prototypes abandonnés et de systèmes qui fonctionnent à peu près jusqu’au jour où ils cessent de fonctionner. J’en ai moi-même construit quelques-uns.

Le résultat global est donc quelque peu paradoxal. Nous n’avons jamais été aussi rapides pour parvenir à quelque chose. Mais nous ne sommes pas automatiquement meilleurs pour transformer cette chose en un produit qui dure.

Les réflexions de Kathy

Il n’a jamais été aussi facile de commencer des choses. Il n’est pas forcément plus facile de les terminer correctement. Nous allons voir beaucoup plus de produits à moitié construits, de prototypes abandonnés et de systèmes qui fonctionnent à peu près jusqu’au jour où ils cessent de fonctionner. J’en ai moi-même construit quelques-uns.

Pourquoi quatre principes font passer les produits de l’effet spectaculaire à la confiance

Je voudrais parler un peu plus de la confiance, car je pense que les responsables produit sous-estiment le risque que représente un logiciel invisible et de mauvaise qualité.

L’IA facilite incroyablement la création de choses. On peut mettre en place des outils, des fonctionnalités et même des applications entières en une fraction du temps nécessaire auparavant. Cela semble être un avantage absolu, mais le résultat est une quantité bien plus importante de logiciels qui fonctionnent à peu près.

Des fonctionnalités inachevées, des systèmes fragiles, des éléments construits rapidement puis jamais renforcés. Ils n’échouent pas de manière spectaculaire. Ils se dégradent simplement avec le temps. Ils tombent en panne de façon subtile, créent de la confusion ou érodent silencieusement la confiance.

Le risque ne se limite pas à la dette technique au sens traditionnel du terme. Il s’agit aussi d’une dette de confiance.

Voici quatre principes que j’ai trouvés utiles :

1. Rendre le système compréhensible. Les utilisateurs doivent pouvoir comprendre ce que fait l’IA et pourquoi, au moins à un niveau général. Il ne s’agit pas d’une transparence technique totale, mais d’un niveau suffisant pour que le système ne donne pas l’impression d’être une boîte noire prenant des décisions arbitraires. Cela peut être aussi simple que d’afficher les étapes, de présenter les hypothèses ou de permettre aux utilisateurs d’examiner ce qui a changé.
2. Concevoir en prévoyant la correction. Le système se trompera parfois. C’est inévitable. Ce qui compte, c’est la facilité avec laquelle l’utilisateur peut intervenir, corriger le problème et poursuivre son travail. Si la correction du système est pénible, la confiance diminue rapidement. Si elle est facile, les utilisateurs continueront à s’en servir même s’il n’est pas parfait.
3. Privilégier la cohérence plutôt que l’effet spectaculaire. Beaucoup de produits d’IA optimisent le moment « waouh ». Une interaction vraiment impressionnante. La confiance vient de l’inverse : un système qui fait la chose attendue, encore et encore, sans surprise. Dans les outils pour développeurs en particulier, la prévisibilité compte davantage que la magie.
4. Faire preuve de retenue. Ce n’est pas parce que le système peut faire quelque chose qu’il doit le faire. Si l’on automatise à outrance ou si l’on retire trop de contrôle aux utilisateurs, ils le ressentent. Ils perdent leur sentiment de maîtrise. Les meilleurs produits offrent un effet de levier sans vous exclure du processus.

Pourquoi l’IA ne peut pas prendre en charge la différenciation produit ni l’automatisation de bout en bout

Voici quelques autres domaines dans lesquels l’IA montre ses limites.

On parle beaucoup d’agents capables de prendre une tâche en charge et de l’exécuter de bout en bout. En pratique, la plupart des systèmes que j’ai vus nécessitent encore beaucoup de supervision. Il faut les guider, les corriger et relancer les instructions. C’est davantage comme gérer un stagiaire enthousiaste que déléguer à un coéquipier totalement autonome.

C’est tout de même utile, mais c’est différent de ce que l’on attend.

Et puis il y a la différenciation des produits.

De nombreuses fonctionnalités d’IA actuelles se ressemblent. On peut ajouter une interface de conversation, générer du code et résumer quelque chose. C’est désormais le minimum attendu.

Le plus difficile a été de transformer ces capacités en quelque chose qui semble avoir une valeur unique et être profondément intégré à un flux de travail. Quelque chose dont les utilisateurs ressentiraient réellement l’absence si on le leur retirait.

Je pense que c’est là que de nombreux produits montrent leurs limites.

Pourquoi le jugement humain reste essentiel dans les décisions produit liées à l’IA

Les responsables produit doivent se demander : « Dans quels domaines l’IA a-t-elle réellement du discernement ? Et dans quels domaines n’en a-t-elle pas ? »

Il y a désormais des aspects du travail produit pour lesquels l’IA m’est incroyablement utile — tout ce qui bénéficie de l’ampleur, de la rapidité ou de l’itération, je m’appuie fortement sur elle. Les premières phases d’exploration, l’étude des espaces de solutions, la rédaction de différentes approches, et même la génération de premières orientations ou de premiers parcours UX. Elle aide beaucoup à sortir d’une impasse ou à envisager davantage d’options qu’on ne le ferait seul.

Je l’utilise aussi beaucoup pour le prototypage, comme je l’ai mentionné. Pouvoir passer rapidement d’une idée à quelque chose d’interactif a complètement changé ma façon de travailler.

Et puis il y a tout le travail « intermédiaire ». Résumer les retours des utilisateurs, dégager des tendances à partir des données, rédiger des documents. Des tâches qui prenaient auparavant beaucoup de temps et imposaient de fréquents changements de contexte.

Là où je ne m’appuie pas sur l’IA, c’est lorsque le jugement compte vraiment. La priorisation en est un bon exemple. L’IA peut aider à dresser une liste d’options, mais elle ne comprend pas réellement les compromis liés à votre entreprise, à votre équipe ou à vos contraintes. Elle ne ressent pas le coût d’une erreur.

Il en va de même pour les décisions concernant la feuille de route. Elles reposent sur la conviction, le calendrier et, parfois, sur le fait de faire un pari qui ne semble pas rationnel dans un tableur.

L’UX est un autre domaine intéressant. L’IA peut générer rapidement beaucoup d’interfaces utilisateur, mais elle n’a pas de goût. Elle ne ressent pas ce qui est frustrant ou plaisant au fil des utilisations. Lorsqu’on conçoit des produits pour les développeurs en particulier, la différence entre quelque chose qui fonctionne et quelque chose qui procure une bonne expérience est essentielle.

Et puis il y a les compromis techniques. L’IA peut suggérer des architectures, mais elle n’assume pas les conséquences à long terme de ces décisions. C’est votre équipe qui les assume.

Comment l’IA bouleverse les présupposés traditionnels sur les produits

Je pense que le principal présupposé auquel j’ai dû renoncer est que le terrain sur lequel on se tient est stable.

Pendant longtemps, dans le domaine des produits, on pouvait supposer que certaines choses étaient relativement immuables. L’interface, le flux de travail, et même ce qu’est le produit. On itérait dans ce cadre. L’IA bouleverse cela.

Le modèle s’améliore et, soudain, la surface de votre produit ne convient plus. Un nouveau paradigme d’interaction apparaît et ce qui semblait être une feuille de route solide devient obsolète. Des éléments que vous pensiez être des contraintes disparaissent, tandis que de nouvelles contraintes apparaissent sans que vous les ayez prévues.

Vous ne construisez donc pas seulement sur un terrain mouvant. Vous vous demandez constamment si ce terrain devrait même exister. Cela a profondément changé ma façon de penser.

Le deuxième présupposé auquel j’ai renoncé est que les meilleurs produits sont les mieux définis. Autrefois, on accordait beaucoup d’importance à la clarté dès le départ. Définir le problème, définir la solution, exécuter proprement.

Désormais, une grande partie de la valeur vient du fait de rester plus longtemps dans l’exploration qu’on ne le jugerait confortable. Laisser le produit rester quelque peu indéfini tandis que les capacités sous-jacentes continuent d’évoluer.

Et le dernier concerne l’endroit où se trouve la valeur. Je pensais autrefois qu’une grande partie de la valeur d’un produit résidait dans l’interface. L’interface utilisateur, le parcours, les pixels. Aujourd’hui, une grande partie de la valeur réside dans le comportement. La manière dont le système réagit, s’adapte et collabore. L’interface reste importante, en particulier pour les développeurs, mais elle n’est plus le centre de gravité.

Comment l’IA fait disparaître les frontières entre les rôles

Les rôles se confondent. Les frontières entre le chef de produit, l’ingénieur et le designer deviennent beaucoup plus ténues.

Avec l’IA, vous pouvez prototyper, écrire du code, explorer l’UX et mettre les idées à l’épreuve beaucoup plus directement. Cela signifie que davantage de personnes peuvent intervenir dans ce qui était autrefois des rôles très distincts. Et cela modifie la structure de l’équipe.

Vous avez besoin de moins de transmissions. De davantage de personnes capables de prendre une idée et de la faire avancer par elles-mêmes, au moins jusqu’à un niveau de fidélité significatif.

Je l’ai ressenti très personnellement. Je suis récemment redevenue cheffe de produit individuelle, et cela a été incroyablement gratifiant. Je suis de nouveau beaucoup plus proche du travail. Construire des choses, tester des idées, entrer dans les détails. Cela me rappelle qu’une grande partie du jugement produit vient du fait de réellement créer des choses, et pas seulement de les orchestrer.

Cela ne signifie pas que les managers ou la spécialisation vont disparaître. Vous avez toujours besoin d’une expertise approfondie, notamment dans des domaines comme la conception des systèmes ou une UX de haute qualité. Mais vous avez aussi besoin de davantage de « penseurs produit polyvalents » capables d’évoluer avec fluidité dans toute la chaîne et d’utiliser l’IA comme levier.

Pourquoi l’IA a changé les attentes des utilisateurs

L’IA n’améliore pas seulement votre produit. Elle redéfinit ce que les utilisateurs attendent de tous les produits. Vous n’êtes donc plus seulement en concurrence avec vos concurrents directs. Vous êtes en concurrence avec la meilleure expérience d’IA qu’une personne a vécue n’importe où cette semaine-là.

Je pense avoir sous-estimé la rapidité avec laquelle ce changement d’attentes allait se produire.

En pratique, cela signifie que les périodes où quelque chose est « suffisamment bon » sont beaucoup plus courtes. Quelque chose peut sembler magique le lundi et dépassé le vendredi. Si je l’avais su, j’aurais davantage optimisé pour l’adaptabilité et moins pour le degré de finition.

Les réflexions de Kathy

Je pense avoir sous-estimé la rapidité avec laquelle ce changement d’attentes allait se produire…En pratique, cela signifie que les périodes où quelque chose est « suffisamment bon » sont beaucoup plus courtes.

Pourquoi les responsables produit doivent considérer l’IA comme un changement de discipline

Mon conseil est de considérer ce moment moins comme une évolution des outils que comme un changement de discipline.

La compétence la plus importante actuellement est la capacité à voir les choses clairement. L’IA génère beaucoup de résultats. Des idées, du code, des orientations. Le risque est de commencer à confondre ces résultats avec la vérité. En tant que responsable produit, votre rôle est donc de rester ancré dans ce qui se passe réellement : ce que font les utilisateurs, les endroits où les choses échouent et ce qui tient dans la durée.

La deuxième chose consiste à construire ce dont vous dépendez. Si vous travaillez sur des produits d’IA, vous devriez les utiliser de manière approfondie. Pas seulement lors de démonstrations ou de revues, mais dans vos propres flux de travail. Vous ressentirez immédiatement les lacunes : les endroits où les choses sont lentes, déroutantes, où elles fonctionnent presque, mais pas tout à fait. Ce type d’expérience directe est difficile à remplacer et change la qualité de vos décisions.

La troisième consiste à vous habituer à la tension. Il existe actuellement une véritable tension entre la vitesse et la qualité, l’exploration et la discipline, ce qui est possible et ce qui est réellement utile. Cette tension n’est pas quelque chose qu’il faut résoudre. C’est le travail lui-même. Les meilleures équipes que j’ai vues n’essaient pas de l’éliminer. Elles la gèrent intentionnellement. Elles avancent rapidement lorsqu’elles apprennent et ralentissent lorsqu’une chose doit être parfaite.

Enfin, ne laissez pas l’IA faire de vous un gestionnaire de résultats. Il est très facile de prendre du recul et d’orchestrer, de formuler des invites, de vérifier, puis de passer à autre chose. Mais les meilleurs responsables produit restent aujourd’hui très proches de leur métier. Ils construisent, ils testent, ils corrigent les choses qui les dérangent.

Car au fond, le travail n’a pas changé. Vous êtes toujours responsable de créer quelque chose qui fonctionne, auquel les gens font confiance et qui s’intègre dans leur vie. L’IA change simplement la manière d’y parvenir.

Suivez son actualité

Vous pouvez en apprendre davantage auprès de Kathy sur son blog consacré au métier de chef de produit ou sur son site personnel. Vous pouvez également la suivre sur X.

D’autres entretiens avec des experts arrivent bientôt sur Le CPO Club !