« Garbage in, treasures out » : Le chef designer d'Anthropic parle de la philosophie produit de Cowork et de la vérité derrière son lancement en 10 jours

Organiser & compiler : Profondeur TechFlow

Invité : Jenny Wen, responsable de la conception chez Cowork

Animateur : Peter Yang

Source du podcast : Peter Yang

Titre original : Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

Date de diffusion : 29 mars 2026

Points clés

Jenny est la responsable de la conception de Cowork. Elle m’a fait découvrir en profondeur le fonctionnement interne d’Anthropic, y compris la façon dont elle utilise la conception et le développement avec Cowork pour créer des produits, et l’histoire réelle derrière la naissance de Cowork. Anthropic sort presque tous les jours de nouvelles fonctionnalités, et voir leur façon de travailler m’a vraiment profondément marqué.

Résumé des idées remarquables

Sur la façon de travailler au quotidien

La plupart des choses que je passe mon temps à faire, c’est de lancer le produit. Mais je pense que ça ne ressemble peut-être plus vraiment à ce que ça semblait être il y a un ou deux ans. Une grande partie de tout ça, en fait, consiste à jam (collaboration improvisée) d’une manière assez informelle avec des ingénieurs, des gens produits, etc. En général, tout le monde regarde ensemble un prototype, puis en signale les points, et réfléchit à la manière dont il peut évoluer.

Sur la philosophie d’utilisation de “du rebut à la pépite”

Je trouve que le point le plus impressionnant pour moi avec Cowork, c’est sa capacité à organiser l’information. J’aime l’appeler “du rebut à la pépite”. Il peut collecter des informations depuis toutes sortes de sources différentes, puis retrouver rapidement les points clés, distiller du contenu à valeur ajoutée et le transformer en résultats concrets et directement productifs.

Sur la différence entre Cowork et Claude Code

En plus du travail de production de code (production code) très minutieux, aujourd’hui je fais presque tout avec Cowork. Si je dois me concentrer sur certains détails de code dans des scénarios spécifiques, j’utiliserai encore Claude Code. Mais pour la communication et la collaboration au quotidien, je m’appuie entièrement sur Cowork.

Sur l’histoire de la naissance de Cowork

L’expression “ils l’ont fait en 10 jours” vient en réalité d’un extrait tiré d’une interview ou d’un article médiatique. Mais en réalité, la démarche autour de Cowork a commencé bien avant : depuis que je me suis jointe à Anthropic il y a un an, nous avons déjà réfléchi à cette direction. Nous nous sommes demandé comment créer un “partenaire de réflexion” (thinking partner) capable d’aider tous les travailleurs du savoir généralistes.

Même si Claude Code sait déjà très bien gérer les tâches liées au code, notre objectif était de couvrir tous les scénarios de travail du savoir. Je pense que le vrai défi, c’était : comment exécuter cette idée ? Quel type d’architecture est le plus adapté ? Et quel type d’expérience utilisateur (UX) est la bonne ?

Sur l’évolution du processus de design

Je fais toujours Figma. Mais nous ne faisons pas aussi souvent de documents de spécifications, et en général ce n’est plus aussi détaillé. Nous continuons de faire un tri par priorités : c’est toujours un document, mais le plus souvent ce sont seulement quelques bullet points, pas de jolis tableaux trop conçus.

Sur la planification et la vision

Le domaine technologique dans lequel nous sommes évolue extrêmement vite, de nouveaux modèles apparaissent sans cesse, et la cadence de mise à jour ne cesse d’accélérer. Par conséquent, pour nous, définir une vision sur un an n’est pas vraiment réaliste, sans même parler d’une vision sur deux à cinq ans, car il y a trop d’inconnues.

Sur le futur des designers

Si tu as l’impression que le sol sous tes pieds bouge, c’est parce qu’il bouge vraiment. Nous devons l’admettre, apprendre à nous adapter, et aussi revoir notre façon de travailler avec un esprit ouvert.

À chaque fois que je sens que ma carrière est mise au défi, à ce moment-là, je pense à mes collègues ingénieurs. Leur travail a déjà traversé de profonds changements depuis longtemps, mais ils se sont non seulement adaptés à ces changements, ils ont aussi affronté les défis avec beaucoup de courage et d’humilité, et ont finalement obtenu des résultats de travail plus efficaces et plus remarquables. Ils sont ma source d’inspiration : je me dis que si ces collègues que j’admire énormément peuvent le faire, je peux aussi le faire. Ils sont un modèle d’adaptation au changement.

Introduction

Peter Yang : Bonjour à tous. Je suis très heureux d’accueillir aujourd’hui Jenny, responsable de la conception chez Anthropic. Jenny va nous montrer comment elle utilise Claude Cowork et Claude Code pour concevoir et publier des produits, et elle va aussi partager avec nous l’histoire interne de Cowork. Elle parlera peut-être aussi de la prochaine étape de développement de ses produits.

Jenny, à quoi ressemble une journée typique pour toi au travail ? Quelles tâches te prennent le plus de temps ?

Jenny :

Je ne sais pas si c’est une journée vraiment typique, mais la plupart du temps, je passe à lancer le produit. Cependant, je pense que ça pourrait ne pas ressembler autant à ce que ça avait l’air d’être il y a un ou deux ans. Une grande partie, en fait, c’est du jam (collaboration improvisée) — assez informel — avec des ingénieurs, des gens produit, etc. Souvent, tout le monde regarde ensemble un prototype, puis en pointe du doigt des éléments et réfléchit à la manière dont il pourrait évoluer. Parfois c’est juste discuter de la façon dont les fonctionnalités se comportent. Parfois c’est moi qui implémente certaines choses. Je pense que j’ai toujours une grosse part de temps où je conçois, je fais des prototypes, etc. Mais la manière de travailler côté design me paraît aujourd’hui beaucoup plus souple.

Peter Yang : En gros, tu génères une pile de prototypes avec Claude et ce genre de choses, puis tu fais du jam avec les ingénieurs, tu donnes du feedback, puis tu utilises des prompts pour que l’IA l’améliore, c’est bien ça ?

Jenny :

En fait, souvent ce ne sont même pas des prototypes. Ce sont plutôt des prototypes de travail qui sont déjà construits en interne et qui tournent dans des instances de Claude ou de Cowork. Je passe généralement du temps à utiliser cette fonctionnalité, à la faire avancer, à en tester les capacités, à me faire une opinion, et la prochaine itération consiste généralement à ce que je m’assoie et dise aux ingénieurs : Hé, voici comment je le vois. Ce sont, à mon avis, les endroits qui devraient changer. Je pense qu’il reste un temps très, très important pour moi à itérer, peaufiner et affiner dans l’outil de design. Donc cette partie n’a pas disparu. Simplement, parce que je gère plus de projets en même temps, je ressens que l’approche la plus efficace consiste à procéder de façon très aléatoire, très informelle.

Peter Yang : Je pense que c’est exactement la partie que j’aime le plus en tant que chef de produit ou designer : réunir les designers et les ingénieurs, et voir le produit évoluer en itération. Donc vous ne faites plus trop, maintenant, ce genre de documents de spécifications, de fichiers Figma, etc., pour la planification ? Ou est-ce que vous itérez directement dans le code autour des prototypes ?

Jenny :

Je fais encore Figma. Mais nous ne faisons pas aussi souvent de documents de spécifications maintenant, et généralement ils ne sont pas aussi détaillés. Oui. Nous faisons toujours un tri par priorités, et c’est encore un document. En fait, c’est utile pour les équipes de sécurité ou de legal. Comme ça, elles peuvent comprendre ce qui va être publié, mais en général ce sont juste quelques bullet points. Ce n’est pas ce type de tableaux joliment conçus avec trop de design. Je trouve que nos fichiers Figma sont aussi comme ça.

Démonstration pratique de Cowork

Peter Yang : Peux-tu nous montrer comment tu utilises ces produits, ou à quoi sert chaque produit séparément ?

Jenny :

Bien sûr. Je vais vous expliquer comment j’utilise Cowork. En fait, j’ai un petit secret : en dehors du travail de production de code (production code) très minutieux, je fais presque tout avec Cowork. Si le scénario nécessite de se concentrer sur certains détails de code, j’utiliserai encore Claude Code. Mais pour la communication et la collaboration au quotidien, je m’appuie entièrement sur Cowork.

Je pense que le point qui me surprend le plus avec Cowork, c’est sa capacité à organiser l’information. J’aime l’appeler “du rebut à la pépite”. Il peut collecter des informations depuis toutes sortes de sources différentes, puis retrouver rapidement les points clés, distiller du contenu à valeur ajoutée et le transformer en résultats concrets et directement productifs.

Prenons un exemple. En ce moment, je connecte un dossier qui contient des comptes rendus d’entretiens utilisateurs. L’équipe Cowork est très attentive à garder une relation étroite avec les utilisateurs : c’est l’une des clés de notre réussite. Nous faisons des recherches d’expérience utilisateur (UXR) classiques : on parle directement aux utilisateurs, et en parallèle, nous avons aussi des méthodes internes pour un usage pratique. Par exemple, nous avons un canal Slack dédié pour collecter du feedback. En plus de ça, nous faisons aussi attention aux discussions sur les réseaux sociaux et nous écoutons les avis des utilisateurs passionnés. C’est précisément parce que nous maintenons constamment un lien très étroit avec les utilisateurs, et que nous pouvons itérer rapidement le produit, que nous pouvons continuer à l’améliorer et à obtenir les résultats que nous avons aujourd’hui.

Donc, ce que je vais faire maintenant, c’est dire à Claude : Hé, j’ai ce dossier d’entretiens, mais fais aussi regarder à Claude les réseaux sociaux, Reddit et d’autres retours clients de Cowork, et dis-moi quelles sont les plus grandes insights. Ça peut demander un peu de temps, parce qu’il doit vraiment traiter autant de données et les transformer. Mais il peut faire des choses : parfois il déploie des sous-agents en parallèle pour traiter en même temps, et il passe aussi du temps à chercher sur le web.

Peter Yang : Dans ton travail réel, vous avez ce genre de rapports d’insights chaque semaine ? Une agrégation automatique de tout, puis un envoi vers toi et l’équipe ?

Jenny :

En fait, on peut déjà le faire directement avec Cowork. Je pense que nos chercheurs ont une réunion qui les sort, et nous avons aussi une version qui nous ping sur Slack. On écoute aussi directement des canaux Slack internes. Nous dépendons beaucoup des utilisateurs les plus solides pour nous fournir des retours très en avance. En interne, les gens sont vraiment prêts à être honnêtes avec toi : ils poussent souvent les fonctionnalités jusqu’au bout, et ils sont aussi les plus faciles à suivre.

Peter Yang : Je pense que c’est ce qui devrait se passer, et j’ai l’impression que dans la plupart des entreprises, les équipes sont trop cloisonnées. Mais chez Anthropic, ça ne ressemble pas du tout à ça.

Jenny :

Je pense que c’est aussi une partie importante de la réussite de Claude Code : écouter les utilisateurs de première ligne. Et c’est aussi quelque chose qu’on fait beaucoup quand on travaille avec Figma, grâce à du dogfooding interne en grande quantité. Parce que, en particulier quand il s’agit de design d’interactions et de peaufiner des détails, les gens en interne vont vraiment aller toucher à ces détails. Tandis qu’en général, les retours des utilisateurs externes portent davantage sur : est-ce que ça s’adapte à leurs workflows d’utilisateurs. Donc ça apporte un niveau de feedback complètement différent.

Frontières d’utilisation : Cowork vs Claude Code

Peter Yang : Je sais qu’en ce moment, dans le marketing d’Anthropic et chez les product managers, la plupart utilisent Claude Code, surtout depuis qu’il est devenu disponible en interne dans Cowork. Comment vois-tu les différents types de scénarios d’usage ? Ou comment les gens utilisent-ils Cowork et Claude Code ?

Jenny :

Nous avons constaté que le périmètre d’application global de Cowork s’élargit progressivement, et qu’il commence à être utilisé dans des scénarios un peu similaires à ceux que les utilisateurs avancés tentaient avec Claude Code auparavant. Vous vous souvenez de quand on a commencé à développer Cowork : l’équipe commerciale interne était notre principale source d’informations au début. Quelques-unes de ces personnes étaient des utilisateurs avancés de Claude Code ; elles l’utilisaient pour générer des listes de prospects, rédiger des scripts d’appel, etc. Quand j’ai vu ces cas d’usage pour la première fois, j’ai été assez surprise, car à ce moment-là, je n’avais même pas pensé que Claude Code pouvait être utilisé pour accomplir ce type de tâches. Et maintenant, ces utilisateurs ont presque tous basculé vers Cowork, et même leurs collègues commencent à utiliser Cowork très fréquemment.

Je pense que c’est parce qu’il y a une belle UI : c’est donc ce dont ça avait vraiment besoin. Et il y a aussi une autre raison : c’est très proche du reste de leur travail. Ils utilisent déjà les fonctionnalités de chat, et à partir de cette application de bureau, ils peuvent continuer à utiliser Claude Code. Je pense que c’est plus aligné avec leur workflow existant que d’ouvrir la ligne de commande.

De l’insight à l’Artifact exécutable : le processus complet

Jenny :

Ici, il y a sept thèmes différents, et chaque semaine c’est différent. Je peux pratiquement lui dire directement : aide-moi à créer ce document X, et il sera déjà automatiquement présent dans un dossier sur mon ordinateur. Je peux aussi démarrer deux tâches en parallèle en même temps. Par exemple, je peux dire : ces insights sont super, mais d’après ça, quelles fonctionnalités produit concrètes devrions-nous construire ? Ensuite, je peux faire une autre chose en parallèle : transformer le contenu de ce document d’insights que tu viens de me préparer en une présentation que je peux partager avec l’équipe lors de notre kickoff cette semaine.

Mais au final, à partir de là, je peux commencer à designer le workflow : ça va me proposer plein d’options de fonctionnalités. À partir de là, je peux même demander à Claude de créer des wireframes pour ces fonctionnalités. Il va peut-être me donner une tonne d’options différentes. Je peux ensuite les amener dans Figma pour les détailler vraiment, ou les amener dans Claude Code, puis les rendre réelles avec nos composants de design system, et à partir de là, continuer.

En plus, je peux aussi transformer ces deux éléments en tâches programmées. Par exemple, je vais lui faire planifier la tâche pour qu’elle s’exécute automatiquement chaque lundi matin à 10h. Comme ça, chaque lundi matin à 10h, je commence la semaine avec cette présentation, avec trois ou quatre idées produit différentes, afin de faire le kickoff. Il comprime fortement le cycle d’itération : passer du feedback à produire quelque chose de tangible, ou d’obtenir une idée que l’équipe peut voir. Cela nous aide à itérer rapidement sur le produit, et à l’améliorer rapidement pour qu’il devienne encore mieux.

Peter Yang : Tout est une question d’itération, c’est toujours une question d’itération. Je suis même devenu plus paresseux : je laisse l’IA faire la première version, puis je réagis.

Jenny :

Oui. Donc si tu veux vraiment que je parte de zéro et que j’organise ces insights en une sorte de priorisation de fonctionnalités, ça va prendre beaucoup plus de temps que ce n’était avant.

Je fais pareil. Par exemple, les notes de ce podcast que tu m’as envoyées : j’ai un dossier de notes personnelles, où il y a le contenu des réunions 1:1, des idées aléatoires, etc. Et je dis directement : lis mes notes personnelles, aide-moi à trouver les points clés de ce que je devrais dire dans ce podcast, et aide-moi à réfléchir à ce que je veux dire ici. Bien sûr, je ne vais pas le lire mot pour mot. Mais ça m’aide vraiment à ouvrir des perspectives, et à faire évoluer ma réflexion plutôt que de rester bloqué dessus.

Compétences et base de connaissances personnelle

Peter Yang : Quelles skills utilises-tu ? Ou as-tu des skills personnelles dédiées pour faire ces documents et ces slides ?

Jenny :

En interne, on a quelques skills dédiées pour faire des documents et des slides, parce que ça nous aide à maintenir une cohérence de marque. En fait, je n’ai pas une librairie de skills personnelle. La plupart du temps, j’emprunte les skills déjà existantes en interne, puis je les utilise pour différents usages.

Peter Yang : Par exemple, j’ai un writing skill : il dit à l’IA de ne pas utiliser ces mots “dégueulasses” d’IA (AI slop).

Jenny :

Mais en fait, j’ai remarqué qu’avec les dossiers de Cowork — où je mets toutes mes notes personnelles et ce genre de choses — il comprend ma façon de travailler via ces dossiers, et pour moi, c’est déjà très utile. J’ai plutôt l’impression d’avoir de moins en moins besoin de memory et de skills, parce qu’il existe déjà une base de connaissances sur moi. Bien sûr, je pense que les skills ont des cas d’usage, mais d’après mon utilisation actuelle, je trouve que le besoin est moins important pour moi personnellement.

Peter Yang : C’est parce qu’il met à jour la mémoire automatiquement chaque jour selon tes conversations ?

Jenny :

Oui. Fondamentalement, c’est une memory maintenue par moi-même, parce que j’y prends des notes tout le temps.

Points de collaboration en équipe

Peter Yang : Donc à quel moment, dans tout ce processus, tu fais entrer l’équipe ? Ou bien tu itères avec l’IA, puis tu reviens ensuite itérer avec l’équipe, en va-et-vient, ou c’est comment ?

Jenny :

Quand je parle de choses comme de vrais entretiens UXR, en fait je ne les fais pas moi-même : soit le chef de produit, soit un chercheur dans l’équipe, soit quelqu’un d’autre dans l’équipe s’en charge. Et ensuite, à partir de là, tu partages directement l’artifact : ça fait entrer l’équipe, et ça devient en pratique la base du fonctionnement de l’équipe.

Notre équipe est au moins assez bottom-up et démocratique. Notre façon de fonctionner, c’est qu’on donne aux gens des insights et des objectifs : chacun se met ensuite à faire des prototypes, à essayer des choses. Les idées viennent de tous les côtés. Ce n’est pas “c’est moi, designer, qui vais tout inventer”. C’est plutôt : “voici les insights, voici l’objectif qu’on doit essayer d’atteindre ce mois-ci ; comment on y arrive tous ensemble ?”

Avec ça, on ne délègue pas directement tout à Claude pour autant. On dépend toujours de nous-mêmes pour beaucoup de décisions, et de notre capacité à gérer et décider ce qu’il faut vraiment construire et faire.

Peter Yang : Quand les gens discutent en ligne du goût et du jugement, je pense que les méthodes pour développer ces capacités consistent en fait à obtenir en continu énormément de retours produit, depuis l’interne comme depuis l’extérieur. Dans ce processus, tu développes progressivement une intuition qui te permet de repérer ce qui ne va pas, ce qu’il faut réparer. Comme tu écoutes et traites des retours tous les jours, avec le temps, tu développes un jugement très affûté sur les problèmes.

Jenny :

Pour ce qui est du design, l’une des fonctionnalités de Claude, c’est qu’il peut générer des croquis de type wireframe, et proposer plusieurs options de design. En tant que designer, j’adore ce mode de fonctionnement. Même si le niveau de détail de ces croquis n’est pas très élevé, ils me permettent de voir visuellement les différentes possibilités, sans devoir entièrement dépendre de mon imagination. Cette méthode m’aide à décider plus vite de la direction du design suivante.

Donc, je pense que laisser Claude générer directement ces options initiales peut me faire gagner du temps et de l’énergie que je passerais autrement à fabriquer des croquis manuellement. Parmi ces options, je choisis une direction, et je commence à itérer à petite échelle. Ensuite, je peux utiliser du code pour transformer cette direction en un prototype initial, puis continuer à optimiser et à peaufiner le design par-dessus.

Histoire vraie de la naissance de Cowork

Peter Yang : Parlons de la façon dont Cowork est né. Dehors, il y a beaucoup d’histoires sur le fait que “ils l’ont fait en 10 jours”. Mais en réalité, avant ça, il y avait déjà eu beaucoup d’itérations, non ?

Jenny :

Cette phrase “ils l’ont fait en 10 jours” vient en réalité d’un extrait coupé depuis une interview ou une couverture médiatique. Les gens en ont débattu autour de ce point. Mais la réalité, c’est que pour la direction Cowork, on avait commencé à y réfléchir depuis que je suis arrivée chez Anthropic il y a un an. On se demandait comment créer un “partenaire de réflexion” (thinking partner) pour aider tous les travailleurs du savoir généralistes. Même si Claude Code sait déjà gérer très bien les tâches liées au code, notre objectif était de couvrir tous les scénarios de travail du savoir. Je pense que le vrai défi était : comment exécuter cette idée ? Quel type d’architecture est la plus appropriée ? Et quel type d’expérience utilisateur (UX) est la bonne ?

Au cours de la dernière année, on a essayé beaucoup de prototypes différents ; certaines idées étaient même plus ambitieuses que l’objectif actuel. On a aussi mené beaucoup d’expériences techniques, en testant différents frameworks d’agents IA, mais certaines tentatives n’ont pas fonctionné. Finalement, on a progressivement déterminé la direction qu’on suit aujourd’hui. On s’est inspiré non seulement de prototypes développés par l’équipe du laboratoire, mais aussi de prototypes que notre équipe produit avait construits elle-même. En fin de compte, c’est le moment et la capacité d’exécution qui ont été décisifs. Comme la foudre qui frappe exactement la cible.

Quand on a décidé de publier ce produit, tout le processus a été très rapide : de “on devrait le publier” à “le produit est déjà en ligne”, seulement 10 jours. C’est principalement parce qu’on a vu son potentiel pendant les vacances de Claude Code. Pendant les vacances, beaucoup de gens ont enfin eu le temps d’essayer Claude Code. Même des utilisateurs non techniques ont commencé à l’utiliser : par exemple pour analyser des transcriptions de podcasts, ou faire des analyses de données complexes, etc. On a constaté que le framework des agents de Claude Code a commencé à montrer un premier niveau d’adéquation produit-marché (product-market fit) même chez des utilisateurs non techniques. En fait, à ce moment-là, on avait déjà un prototype qui fonctionnait en interne, et la publication était prévue plus tard. Mais à cause de ces retours, on s’est rendu compte que “c’est maintenant le meilleur moment”. Alors on a décidé de saisir cette opportunité, et on a finalement eu ces 10 jours complètement fous.

Peter Yang : Si je comprends bien, au cours de la dernière année, vous avez partagé beaucoup de prototypes sur votre Slack interne, recueilli énormément de feedback, puis vous avez abouti à un prototype faisable. Ensuite, en voyant la demande du marché, vous avez fait un sprint rapide et vous l’avez mis en production.

Jenny :

Oui, globalement c’est ça. On prévoyait de lancer dans quelques semaines, mais à ce moment-là, on a senti que “c’est le meilleur moment”. Et cela nous a aussi amenés, dans un contexte de délais serrés, à réduire la portée du produit à un niveau plus réaliste et faisable, et à investir toute notre énergie et nos ressources. Finalement, on a réussi le lancement.

Itérations de design précoces : de l’outil workflow à un Chat minimaliste

Peter Yang : Tu peux partager des retours d’expérience sur l’itération précoce, ou montrer quelque chose qui est en cours de développement ?

Jenny :

Bien sûr. J’ai spécialement rassemblé quelques captures d’écran de la phase très précoce, que je peux montrer pour illustrer nos idées de design et notre processus d’itération.

Plus tôt dans l’année, nous avons eu un prototype précoce, réalisé avec un autre designer. À l’époque, on essayait de rendre cet outil davantage orienté tâches (task-oriented) ou orienté workflow (workflow-oriented). Parce que nous étions très inquiets : est-ce que les utilisateurs comprendraient comment utiliser un produit comme Cowork ? Est-ce qu’ils seraient capables d’accomplir des tâches spécifiques, ou d’obtenir des résultats clairs (outcome) ? Par exemple, créer un dashboard (tableau de bord), ou intégrer des données provenant de différentes sources. Donc à ce moment-là, nous avons conçu l’interface utilisateur de façon très structurée, presque comme un outil de workflow : par exemple “ajouter ce contenu”, ce sont les inputs (inputs), “ce sont les outputs” (outputs). Et la fonctionnalité de chat était reléguée au second plan.

Mais on avait l’impression qu’il fallait trop d’étapes pour accomplir les choses. En 2025, à l’époque actuelle, pourquoi faire tout ça de manière aussi compliquée ? N’y a-t-il pas juste à laisser Claude s’en occuper ?

C’était une direction de design au début, mais ensuite on a décidé de changer l’idée : le rendre plus simple, comme une boîte de chat (chat box). On a essayé de guider les utilisateurs à atteindre des objectifs plus spécifiques, comme l’analyse ou la génération de documents. On a aussi conçu un prototype fonctionnel : après avoir cliqué, on voyait toutes sortes d’options, avec des boutons pour ajuster chaque option, comme la longueur du document, ou le type de document, par exemple mémo ou présentation. Mais au final, ce design donnait aux utilisateurs une impression trop complexe et trop oppressante.

Donc, à travers plusieurs explorations et essais, on s’est efforcé de trouver un point d’équilibre : faut-il vraiment définir plus explicitement les scénarios d’usage, ou faut-il conserver une forme libre, comme dans une boîte de chat ?

Finalement, la version que nous avons publiée il y a quelques semaines ressemble à ça aujourd’hui. On avait essayé une expérience utilisateur presque “mode assistant” (wizard-like) : tu cliques, et tu vois des suggestions, comme “créer un document, longueur de trois à cinq pages”, etc.

À ce moment-là, on avait aussi ajouté beaucoup d’éléments dans l’interface, dans l’espoir de la faire paraître différente d’une boîte de chat classique. Mais on s’est rendu compte que ce design rendait l’interface trop complexe, et que la compétition entre les éléments visuels était trop forte. Alors on a décidé de simplifier : supprimer la plupart des éléments inutiles.

L’interface utilisateur que tu vois maintenant a été fortement simplifiée. On a retiré les sidebars lourds (barres latérales), ce qui la rapproche d’une boîte de chat traditionnelle. Mais on a modifié un peu la page d’accueil pour qu’elle ressemble davantage à une “liste de tâches” (to-do list) partagée par moi et Claude, plutôt qu’à un outil de chat rempli de suggestions et de guidage complexes.

Peter Yang : Peut-être que plus tard, elle pourra supporter plusieurs agents (agent), et qu’on pourra y glisser des tâches pour gérer le workflow.

Jenny :

Peut-être qu’il y aura une possibilité comme ça. Mais je veux insister sur le fait que le design de l’UI était complètement différent il y a environ quatre ou cinq semaines : on a continué à apprendre et à explorer quel type de design est le plus efficace, lequel ne marche pas aussi bien, et on a essayé de trouver la meilleure manière de présenter cette technologie aux utilisateurs.

Positionnement des différences entre Cowork et Claude Code

Peter Yang : Pendant l’utilisation de Claude Code, je partage souvent sur Twitter des retours. Il contient beaucoup de commandes slash (slash commands) intégrées, et les utilisateurs doivent apprendre progressivement. Cette expérience ressemble à une “chasse au trésor” (treasure hunt) quand tu vas faire des courses chez Costco : tu ne sais jamais ce que tu vas découvrir comme nouvelle fonctionnalité.

Mais pour les débutants, cette façon de faire n’est pas vraiment conviviale. C’est plus comme un jeu : plus tu l’utilises longtemps, plus tu te familiarises et tu finis par le maîtriser. Je me dis que Cowork est peut-être en train d’explorer la zone intermédiaire entre un outil de chat ordinaire et Claude Code. Il ne cache pas toutes les fonctionnalités, mais il guide les utilisateurs d’une manière ou d’une autre pour qu’ils apprennent à mieux l’utiliser.

Jenny :

Oui. Cowork supporte toujours l’utilisation des slash commands (slash commands), mais elles ne sont pas le mode d’interaction principal. À mon avis, Cowork est au moins un outil destiné aux professionnels. On a observé que beaucoup d’utilisateurs l’utilisent déjà comme des utilisateurs très avancés. Et il y a même des utilisateurs avancés qui émergent au sein de la communauté. Ces utilisateurs sont souvent prêts à passer du temps à apprendre des fonctionnalités plus complexes : créer soi-même des skills (skills), partager avec l’équipe, ou utiliser des commandes abrégées (shorthand commands).

Mais notre objectif est de faire de ces fonctionnalités un mode d’interaction secondaire, plutôt qu’un contenu d’apprentissage imposé. Autrement dit, même si l’utilisateur ne connaît pas toutes les commandes, il doit pouvoir utiliser Cowork facilement. Nous voulons que l’interaction entre l’utilisateur et Claude soit naturelle et intuitive, pas qu’il soit obligé de mémoriser une série de commandes pour faire des choses.

Processus de planification et vision

Peter Yang : Quel est le processus de planification chez Anthropic ? Vous faites de la planification annuelle et de la définition d’objectifs ? Ou bien vous vous basez davantage sur le développement de prototypes et sur des essais continus ?

Jenny :

Notre façon de planifier change à chaque fois. Dans l’équipe où je suis, nous faisons de la planification mensuelle. On a une feuille de calcul, et au moins dans la partie Cowork, on y liste jusqu’à environ 12 tâches, qui sont nos priorités absolues (P0). Chaque tâche a un responsable direct (DRI). Chaque semaine, on vérifie : est-ce qu’on est toujours sur la bonne trajectoire ? On fait aussi parfois de la planification trimestrielle ou semestrielle, généralement portée par une personne responsable qui indique : “Je pense qu’on devrait évoluer dans cette direction ; ce sont les sujets auxquels on doit prêter attention.” Mais ces plans ne sont pas stricts au point d’imposer d’exécuter des projets précis. L’objectif est plutôt de donner une direction globale à l’équipe : donc c’est relativement flexible.

Peter Yang : Plutôt flexible, oui ? Ce qui est intéressant, c’est que j’ai remarqué que les entreprises les plus innovantes font souvent moins de planification annuelle, et apprennent davantage en itérant continuellement et en tirant des leçons des utilisateurs. Est-ce que tu as fait quelque chose de similaire à un North Star deck pendant ta carrière ? Tu penses que c’est utile ?

Jenny :

J’ai effectivement fait ça : l’année dernière, j’ai préparé un North Star deck. Je pense que la vision a vraiment de la valeur : elle indique une direction à l’équipe, et nous aide à rester clairs sur ce que nous allons faire. Cependant, parce que le domaine technologique dans lequel nous sommes change extrêmement vite, avec des nouveaux modèles qui apparaissent sans cesse, et une vitesse de mise à jour de plus en plus rapide. Pour nous, définir une vision sur un an n’est pas très réaliste, sans même parler d’une vision sur deux à cinq ans, parce qu’il y a trop d’inconnues.

Cependant, la véritable utilité d’une vision, c’est de guider tout le monde pour avancer dans la même direction, surtout dans un environnement où chacun peut construire librement toutes sortes de projets. Donc aujourd’hui, je pense que la période d’une vision devrait être au maximum de trois à six mois, et elle peut être présentée sous forme de document. Je pense que quand la vision est visualisée, elle a un impact plus fort. Et c’est une grande valeur du design : pouvoir intégrer divers éléments et raconter une histoire cohérente dans une période donnée. Bien sûr, la vision peut aussi être un prototype, pas seulement un deck statique. Elle peut nous aider à coordonner le travail entre équipes, particulièrement quand nous avons cinq équipes qui traitent des projets très similaires, ou potentiellement conflictuels. Le design peut aider à faire converger ces idées grâce à la curation, et à nous montrer un chemin vers une expérience utilisateur idéale, plutôt que de disperser les expériences.

Peter Yang : Donc vous avez des revues avec des chefs de produit, ou des revues pour les personnes concernées ? Ces revues sont formelles, ou bien elles participent aussi à la conception des prototypes ?

Jenny :

On a effectivement des revues. Mais ce n’est pas comme dans certaines entreprises où chaque fonctionnalité doit passer par une revue. Nos revues portent surtout sur les projets plus importants et de priorité plus haute. Le but des revues n’est pas de passer beaucoup de temps à préparer, mais d’améliorer la visibilité des projets et d’obtenir du feedback. S’il y a un projet important qui impacte la compagnie et qui traverse les équipes, alors on organise ces revues.

Conseils pour les designers : comment trouver sa place à l’ère de l’IA

Peter Yang : Alors, pour ceux qui ressentent que leur environnement professionnel change rapidement, que conseillerais-tu aux designers ? Est-ce qu’ils devraient commencer à apprendre à soumettre du code (PR) ? Ou bien les designers devraient-ils s’adapter d’une autre manière ?

Jenny :

Si tu as l’impression que le sol sous tes pieds bouge, c’est parce qu’il bouge vraiment. Nous devons l’admettre, apprendre à nous adapter, et aussi revoir notre façon de travailler actuelle avec un esprit ouvert. Je pense que les changements actuels impactent particulièrement les designers, surtout parce que nous sommes dans la deuxième vague de cette tendance. D’autres rôles professionnels ont déjà traversé des transitions similaires, et aujourd’hui, c’est à notre tour. Pendant ce temps, nos outils de design continuent d’évoluer.

Chaque fois que je ressens que ma carrière est mise au défi, je ressens une petite inquiétude : par exemple “mon travail change énormément, et peut-être que les gens ne valoriseront plus mon travail comme avant”. Mais à ce moment-là, je pense à mes collègues ingénieurs. Leur travail a déjà traversé d’énormes transformations depuis longtemps. Et ils ne se sont pas seulement adaptés à ces changements : ils ont aussi accueilli les défis avec beaucoup de courage et d’humilité, pour finalement obtenir des résultats plus efficaces et plus remarquables. Ils sont ma source d’inspiration : je me dis que si ces collègues que j’admire énormément peuvent le faire, je peux aussi le faire. Ils sont un exemple d’adaptation au changement.

Peter Yang : D’une certaine manière, ces changements libèrent les designers d’une grande partie du travail répétitif et fastidieux, comme ajuster toutes sortes de cadres, non ? Et donc ça te permet de consacrer plus d’énergie à des réflexions à un niveau plus élevé et à un travail plus créatif.

Jenny :

Oui. Ou disons que ces changements nous permettent de faire plus de choses. Par exemple : quand je vois que mes collègues ingénieurs peuvent maintenant terminer une fonctionnalité complète en quelques jours seulement, alors qu’avant ça pouvait prendre quelques semaines, je suis vraiment impressionnée. Donc, oui : ces changements apportent aussi plus de possibilités.