« Mauvaises entrées, trésors en sortie » : le concept produit de Cowork et la vérité sur son lancement en 10 jours, selon le chef designer d’Anthropic
TechFlow SélectionTechFlow Sélection
« Mauvaises entrées, trésors en sortie » : le concept produit de Cowork et la vérité sur son lancement en 10 jours, selon le chef designer d’Anthropic
Bien que Claude Code soit déjà capable de traiter efficacement les tâches liées au code, notre objectif est de couvrir tous les scénarios de travail intellectuel.
Dédié à des analyses Web3 approfondiesRédaction & traduction : TechFlow
Invitée : Jenny Wen, responsable conception chez Cowork
Animé par : Peter Yang
Source du podcast : Peter Yang
Titre original : Tutoriel Claude Cowork par la responsable conception de Cowork (40 min) | Jenny Wen
Date de diffusion : 29 mars 2026
Résumé des points clés
Jenny est la responsable conception de Cowork. Elle m’a fait découvrir en profondeur le fonctionnement interne d’Anthropic, notamment la manière dont elle utilise Cowork pour concevoir et lancer des produits, ainsi que l’histoire authentique derrière la création de Cowork. Anthropic déploie presque quotidiennement de nouvelles fonctionnalités, et observer leur façon de travailler m’a profondément impressionné.
Résumé des idées marquantes
Concernant les modalités de travail au quotidien
- La majeure partie de mon temps est consacrée à faire sortir les produits. Cela dit, cela ne ressemble probablement pas tout à fait à ce qu’il y a eu il y a un ou deux ans : une grande partie de ce travail consiste désormais en des collaborations informelles — ce que nous appelons des « jam sessions » — avec les ingénieurs, les chefs de produit, etc. En général, nous examinons ensemble un prototype, puis nous identifions ses points faibles et réfléchissons collectivement à la manière dont il pourrait évoluer.
Concernant la philosophie d’usage « entrée désordonnée, sortie précieuse »
- Ce qui me fascine le plus chez Cowork, c’est sa capacité à organiser l’information. J’aime l’appeler « entrée désordonnée, sortie précieuse ». Il est capable de rassembler des données provenant de sources très diverses, d’en extraire rapidement les points essentiels, de synthétiser des contenus utiles et de les transformer en résultats concrets et productifs.
Concernant les différences entre Cowork et Claude Code
- À l’exception des tâches très précises liées au développement de code de production, j’utilise aujourd’hui Cowork pour pratiquement toutes mes activités. Si je dois me concentrer sur certains détails techniques précis, je recours encore à Claude Code. Mais pour la communication et la collaboration quotidiennes, je dépend désormais entièrement de Cowork.
Concernant l’histoire de la création de Cowork
- L’expression « ils l’ont réalisé en dix jours » provient d’une interview ou d’un article médiatique, où elle a été extraite hors contexte. En réalité, dès mon arrivée chez Anthropic il y a un an, nous avions déjà commencé à réfléchir à cette direction. Nous cherchions alors à concevoir un « partenaire cognitif » (thinking partner) capable d’accompagner tous les travailleurs de la connaissance, quel que soit leur domaine.
- Bien que Claude Code gère déjà très bien les tâches liées au code, notre objectif était d’étendre cette capacité à l’ensemble des activités intellectuelles. Le véritable défi, selon moi, résidait dans la mise en œuvre concrète de cette idée : quelle architecture adopter ? Quelle expérience utilisateur (UX) serait la plus adaptée ?
Concernant l’évolution du processus de conception
- Je continue d’utiliser Figma. Toutefois, nous rédigeons rarement des documents de spécifications, et lorsqu’ils existent, ils sont généralement peu détaillés. Nous continuons néanmoins à établir des priorités ; celles-ci prennent la forme d’un document, mais se réduisent souvent à quelques puces, sans être présentées sous forme de tableaux élaborés et surchargés.
Concernant la planification et la vision stratégique
- Le domaine technologique dans lequel nous évoluons change extrêmement vite : de nouveaux modèles apparaissent constamment, et leurs mises à jour s’accélèrent. Pour nous, établir une vision à un an semble déjà peu réaliste, encore moins une vision à deux ou cinq ans, compte tenu de l’incertitude considérable qui règne.
Concernant l’avenir des designers
- Si vous avez l’impression que le sol tremble sous vos pieds, c’est parce qu’il bouge effectivement. Nous devons l’admettre, apprendre à nous adapter, et reconsidérer ouvertement nos méthodes de travail actuelles.
- Chaque fois que je ressens une remise en question de ma profession, je pense à mes collègues ingénieurs. Leur travail a connu des transformations radicales bien avant le nôtre, mais ils ont non seulement su s’y adapter, mais aussi accueillir ces défis avec courage et humilité, aboutissant à 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 profondément, y sont parvenus, alors moi aussi j’y arriverai. Ils constituent pour moi un modèle d’adaptation au changement.
Ouverture
Peter Yang : Bonjour à tous ! Aujourd’hui, je suis particulièrement ravi d’accueillir Jenny, responsable conception chez Anthropic. Jenny va nous montrer comment elle utilise Claude Cowork et Claude Code pour concevoir et lancer des produits, nous raconter l’histoire interne de Cowork, et peut-être même nous parler des prochaines étapes de son développement.
Jenny, à quoi ressemble typiquement une journée de travail pour vous ? Quelles tâches occupent la majeure partie de votre temps ?
Jenny :
Je ne sais pas s’il existe vraiment une « journée type », mais la majeure partie de mon temps est consacrée à faire sortir les produits. Cela dit, cela ne ressemble probablement pas tout à fait à ce qu’il y a eu il y a un ou deux ans : une grande partie de ce travail consiste désormais en des collaborations informelles — ce que nous appelons des « jam sessions » — avec les ingénieurs, les chefs de produit, etc. En général, nous examinons ensemble un prototype, puis nous identifions ses points faibles et réfléchissons collectivement à la manière dont il pourrait évoluer. Parfois, nous discutons simplement de la façon dont une fonctionnalité devrait se comporter ; parfois, je développe moi-même certains éléments. Une bonne part de mon temps est toujours consacrée à la conception et à la création de prototypes, mais la manière dont je pratique la conception aujourd’hui me semble beaucoup plus souple.
Peter Yang : En gros, vous générez une série de prototypes à l’aide d’outils comme Claude, puis vous faites des « jam sessions » avec les ingénieurs, leur donnez des retours, et utilisez des prompts pour demander à l’IA d’améliorer les prototypes, c’est bien ça ?
Jenny :
En réalité, il ne s’agit souvent même pas de prototypes, mais de versions fonctionnelles déjà construites en interne et exécutées dans des instances Claude ou Cowork. Je passe généralement du temps à utiliser cette fonctionnalité, à la pousser à ses limites, à évaluer ses capacités et à former une opinion. La prochaine itération consiste alors souvent à m’asseoir avec les ingénieurs et à leur dire : « Voilà ce que j’en pense. Ce sont les points que je jugerais bon de modifier. » Je pense qu’il reste encore beaucoup de temps à consacrer à l’itération, au perfectionnement et à l’affinement directement dans les outils de conception — ce qui demeure extrêmement important. Cette phase n’a donc pas disparu. Simplement, comme je traite simultanément davantage de projets, il me semble plus efficace de procéder de façon très libre et très informelle.
Peter Yang : Je pense que c’est justement la partie que j’apprécie le plus, en tant que chef de produit ou designer : rassembler designers et ingénieurs autour du produit pour itérer ensemble. Vous ne rédigez donc plus guère de documents de spécifications, de fichiers Figma ou autres documents de planification ? Ou bien itérez-vous directement dans le code ?
Jenny :
Je continue d’utiliser Figma. Toutefois, nous rédigeons rarement des documents de spécifications, et lorsqu’ils existent, ils sont généralement peu détaillés. Oui. Nous continuons néanmoins à établir des priorités ; celles-ci prennent la forme d’un document, mais se réduisent souvent à quelques puces, sans être présentées sous forme de tableaux élaborés et surchargés. Je dirais que nos fichiers Figma suivent le même principe.
Démonstration pratique de Cowork
Peter Yang : Pourriez-vous nous montrer comment vous utilisez ces produits, ou encore préciser à quoi chacun d’eux vous sert spécifiquement ?
Jenny :
Bien sûr. Je vais vous expliquer comment j’utilise Cowork. J’ai un petit secret : à l’exception des tâches très précises liées au développement de code de production, j’utilise aujourd’hui Cowork pour pratiquement toutes mes activités. Si je dois me concentrer sur certains détails techniques précis, je recours encore à Claude Code. Mais pour la communication et la collaboration quotidiennes, je dépend désormais entièrement de Cowork.
Ce qui me fascine le plus chez Cowork, c’est sa capacité à organiser l’information. J’aime l’appeler « entrée désordonnée, sortie précieuse ». Il est capable de rassembler des données provenant de sources très diverses, d’en extraire rapidement les points essentiels, de synthétiser des contenus utiles et de les transformer en résultats concrets et productifs.
Prenons un exemple : j’ai connecté un dossier contenant des comptes rendus d’entretiens utilisateurs. Chez l’équipe Cowork, nous accordons une grande importance à notre proximité avec les utilisateurs, ce qui constitue l’un des facteurs clés de notre succès. Nous menons des études traditionnelles d’expérience utilisateur (UXR), dialoguons directement avec les utilisateurs, et utilisons également des canaux internes : par exemple, nous disposons d’un canal Slack dédié à la collecte de retours. Nous suivons aussi les discussions sur les réseaux sociaux et écoutons attentivement les utilisateurs les plus engagés. C’est grâce à cette proximité constante avec les utilisateurs, associée à une capacité d’itération rapide, que nous parvenons à améliorer continuellement notre produit et à obtenir les résultats actuels.
Ainsi, ce que je fais maintenant, c’est dire à Claude : « Hé, j’ai ce dossier d’entretiens, mais je veux aussi que tu ailles consulter les réseaux sociaux, Reddit et les avis clients sur Cowork pour me dire quels sont les principaux enseignements. » Cela prend parfois un peu de temps, car il doit réellement traiter une masse considérable de données. Il peut alors déclencher des agents secondaires pour traiter certaines tâches en parallèle, ou passer du temps à effectuer des recherches en ligne.
Peter Yang : Dans votre travail quotidien, produisez-vous des rapports hebdomadaires d’enseignements — c’est-à-dire des synthèses automatiques envoyées à vous et à votre équipe ?
Jenny :
Nous pouvons effectivement le faire directement via Cowork aujourd’hui. Je crois que nos chercheurs en produisent un, et qu’un autre est envoyé directement dans Slack. Nous écoutons aussi activement notre canal Slack interne, car nous dépendons fortement de nos collaborateurs internes et de nos utilisateurs les plus avancés pour obtenir des retours pointus : les personnes internes sont particulièrement honnêtes, poussent les fonctionnalités à leurs limites et sont les plus faciles à suivre.
Peter Yang : C’est exactement ce qui devrait se produire, et j’ai l’impression que, dans la plupart des entreprises, les équipes sont trop cloisonnées, alors qu’Anthropic semble totalement différente.
Jenny :
Je pense que cela fait aussi partie intégrante du succès de Claude Code — écouter les utilisateurs en première ligne. C’est également ce que nous faisions beaucoup avec Figma, en pratiquant intensément le « dogfooding » interne. En effet, surtout lorsqu’il s’agit de design interactif et d’affinage, les collaborateurs internes explorent vraiment les détails, tandis que les utilisateurs externes donnent souvent des retours plus orientés sur la compatibilité avec leurs propres flux de travail — ce qui fournit un niveau de feedback totalement différent.
Frontières d’utilisation entre Cowork et Claude Code
Peter Yang : Je sais que les équipes marketing et les chefs de produit d’Anthropic utilisent aujourd’hui largement Claude Code, surtout depuis que Cowork est disponible en interne. Comment percevez-vous les différents scénarios d’utilisation ? Ou encore, comment les gens utilisent-ils Cowork et Claude Code ?
Jenny :
Nous avons observé que le champ d’application global de Cowork s’élargit progressivement, et qu’il commence à être utilisé dans des cas d’usage similaires à ceux explorés auparavant par les utilisateurs avancés de Claude Code. Lorsque nous avons commencé à développer Cowork, l’équipe commerciale interne constituait notre principale source d’informations. Certains de ses membres étaient des utilisateurs avancés de Claude Code, qu’ils employaient pour générer des listes de prospects ou rédiger des scripts téléphoniques. Lorsque j’ai vu ces cas d’usage pour la première fois, j’ai été profondément surprise, car je n’avais même pas imaginé que Claude Code puisse être utilisé à ces fins. Aujourd’hui, ces utilisateurs ont presque tous migré vers Cowork, et leurs collègues commencent eux aussi à l’utiliser fréquemment.
C’est précisément parce qu’il dispose désormais d’une interface graphique attrayante que je pense qu’il a trouvé sa véritable vocation. Une autre raison tient au fait qu’il s’intègre parfaitement aux autres activités qu’ils mènent déjà — ils utilisent déjà des interfaces conversationnelles, et peuvent continuer à utiliser Claude Code depuis cette application de bureau, ce qui le rend bien plus adapté à leur flux de travail que l’ouverture d’un terminal.
Processus complet, de l’enseignement à l’artefact exécutable
Jenny :
Ici, on voit sept thèmes différents, et chaque semaine, ils changent. Je peux directement lui demander : « Crée-moi ce document X », qui sera automatiquement sauvegardé dans un dossier spécifique sur mon ordinateur. Je peux également lancer deux tâches en parallèle. Par exemple, je peux dire : « Ces enseignements sont excellents, mais concrètement, quels fonctionnalités devrais-je développer à partir d’eux ? » Et en parallèle, je peux lui demander : « À partir du document d’enseignements que tu viens de me préparer, transforme-le en une présentation que je pourrai partager avec mon équipe lors de notre réunion hebdomadaire d’ouverture. »
Mais à partir de là, je peux directement entamer le processus de conception — il me propose diverses options fonctionnelles. À partir de celles-ci, je peux même demander à Claude de créer des maquettes (wireframes) pour ces fonctionnalités. Il peut me proposer une multitude d’options différentes, que je pourrai ensuite affiner dans Figma, ou importer dans Claude Code pour les concrétiser à l’aide de nos véritables composants de système de conception, puis poursuivre à partir de là.
Je peux également automatiser ces deux tâches. Ainsi, je pourrais demander à ce qu’elles soient programmées pour s’exécuter automatiquement chaque lundi à 10 heures. Chaque lundi matin à 10 heures, je commence donc ma semaine avec cette présentation et trois ou quatre idées de fonctionnalités, prêtes à lancer la semaine. Ce processus raccourcit considérablement le cycle d’itération allant des retours à la production d’un artefact tangible ou d’une idée partageable avec l’équipe, ce qui nous permet d’itérer rapidement sur le produit et de l’améliorer sans cesse.
Peter Yang : Tout tourne autour de l’itération, tout tourne autour de l’itération. Moi aussi, je deviens paresseux : je demande toujours à l’IA de produire une première version, puis j’interviens pour apporter mes retours.
Jenny :
Oui. Donc, si vous me demandiez vraiment de structurer ces enseignements en une liste de priorités fonctionnelles à partir de zéro, cela me prendrait aujourd’hui bien plus de temps qu’auparavant.
C’est aussi ainsi que je procède. Par exemple, pour ces notes de podcast que vous m’avez envoyées, j’ai un dossier personnel de notes contenant les comptes rendus de mes réunions individuelles, des idées éparses, etc. Je lui dis alors simplement : « Lis mes notes personnelles, aide-moi à identifier les points clés de ce podcast, et aide-moi à réfléchir à ce que je souhaite dire ici. » Bien entendu, je ne lis pas mot pour mot ce qu’il propose, mais cela m’ouvre réellement l’esprit et enrichit ma réflexion, plutôt que de la bloquer.
Compétences (Skills) et base de connaissances personnelle
Peter Yang : Quelles compétences (skills) utilisez-vous ? Avez-vous des compétences personnalisées pour produire ces documents et présentations ?
Jenny :
Nous disposons en interne de plusieurs compétences spécifiques à la rédaction de documents et de présentations, car elles nous aident à maintenir une cohérence de marque. Je n’ai pas de bibliothèque personnelle de compétences : la plupart du temps, j’emprunte celles existant déjà en interne et les adapte à différents usages.
Peter Yang : Par exemple, j’ai une compétence « écriture », qui indique à l’IA d’éviter les termes creux typiques des IA.
Jenny :
Mais je constate que l’utilisation des dossiers Cowork — dans lesquels j’archive toutes mes notes personnelles — permet déjà à l’outil de me connaître suffisamment pour être extrêmement utile. Je ressens de moins en moins le besoin de recourir à la mémoire ou aux compétences, car il dispose déjà d’une base de connaissances sur moi. Bien entendu, je pense que les compétences restent pertinentes dans certains cas d’usage, mais pour mes besoins actuels, leur utilité me paraît nettement moindre.
Peter Yang : Est-ce parce qu’il met à jour automatiquement sa mémoire chaque jour, en se basant sur vos échanges ?
Jenny :
Oui, c’est essentiellement une mémoire que je maintiens moi-même, puisque j’y note constamment des observations.
Points de collaboration en équipe
Peter Yang : À quel moment du processus intégrez-vous votre équipe ? Alternance-t-on entre itérations avec l’IA et itérations avec l’équipe, ou procède-t-on autrement ?
Jenny :
Je veux dire que, par exemple, les vrais entretiens UXR, je ne les réalise pas moi-même — ils sont menés soit par le chef de produit, soit par un chercheur de l’équipe, soit par un autre membre de l’équipe. Ensuite, via ces entretiens, nous partageons directement les artefacts correspondants, intégrant ainsi les participants, et ces artefacts deviennent effectivement la base de notre travail collectif.
Notre équipe fonctionne de façon assez ascendante (bottom-up) et démocratique : nous partageons donc les enseignements et les objectifs avec tous, puis chacun crée des prototypes, expérimente, et les idées viennent de partout. Ce n’est pas moi, en tant que designer, qui dois imaginer toutes les solutions, mais plutôt : « Hé, voici les enseignements. Voici l’objectif que nous devons atteindre ce mois-ci. Comment pouvons-nous y parvenir ensemble ? »
Nous ne confions pas non plus systématiquement l’intégralité du travail à Claude. Nous continuons à nous fier à notre propre jugement, ainsi qu’à notre capacité à piloter et décider concrètement ce qui doit être construit et mis en œuvre.
Peter Yang : Lorsque les gens parlent en ligne de « goût » et de « jugement », je pense que la meilleure façon de les cultiver consiste à recevoir continuellement, en interne comme en externe, une grande quantité de retours sur le produit. Au fil du temps, cela développe une intuition qui vous permet de détecter immédiatement les problèmes et les zones nécessitant une correction. Car en écoutant et en traitant quotidiennement ces retours, vous finissez par acquérir une sensibilité aiguë face aux dysfonctionnements.
Jenny :
Concernant la conception, une fonctionnalité de Claude consiste à générer des esquisses de maquettes (wireframes) et à proposer plusieurs options de design. En tant que designer, j’apprécie particulièrement cette approche. Même si la finesse de ces esquisses n’est pas élevée, elles me permettent de visualiser concrètement les différentes possibilités, sans devoir uniquement compter sur mon imagination. Cela m’aide à prendre plus rapidement une décision sur la direction à suivre.
Ainsi, je pense que demander à Claude de générer directement ces premières options me fait gagner du temps et de l’énergie, comparé à la création manuelle d’esquisses. À partir de ces options, je sélectionne une direction et commence à l’itérer à petite échelle. Ensuite, je pourrais utiliser du code pour créer un prototype préliminaire de cette direction, puis continuer à l’optimiser et à l’affiner.
L’histoire authentique de la naissance de Cowork
Peter Yang : Parlons-en un peu plus : comment Cowork est-il né ? Il circule beaucoup d’histoires à propos de sa réalisation en dix jours, mais il y a forcément eu de nombreuses itérations préalables, non ?
Jenny :
L’expression « ils l’ont réalisé en dix jours » provient d’une interview ou d’un article médiatique, où elle a été extraite hors contexte, suscitant depuis des discussions récurrentes. En réalité, dès mon arrivée chez Anthropic il y a un an, nous avions déjà commencé à réfléchir à cette direction. Nous cherchions alors à concevoir un « partenaire cognitif » (thinking partner) capable d’accompagner tous les travailleurs de la connaissance, quel que soit leur domaine. Bien que Claude Code gère déjà très bien les tâches liées au code, notre objectif était d’étendre cette capacité à l’ensemble des activités intellectuelles. Le véritable défi, selon moi, résidait dans la mise en œuvre concrète de cette idée : quelle architecture adopter ? Quelle expérience utilisateur (UX) serait la plus adaptée ?
Au cours de l’année écoulée, nous avons testé de nombreux prototypes, certains étant même plus ambitieux que notre objectif actuel. Nous avons également mené de nombreuses expérimentations techniques, testant divers cadres d’agents IA, dont certaines se sont révélées infructueuses. Ce n’est qu’au fil du temps que nous avons progressivement défini la direction actuelle. Nous nous sommes inspirés à la fois des prototypes développés par l’équipe de recherche, et de ceux créés par notre propre équipe produit. En fin de compte, le moment opportun et l’exécution ont été déterminants — comme si la foudre avait frappé juste au bon endroit.
Lorsque nous avons décidé de lancer ce produit, le processus s’est déroulé très rapidement — de « Nous devrions le lancer » à « Le produit est en ligne », en seulement dix jours. Cela s’explique principalement par le potentiel que nous avions observé pendant les vacances de Claude Code. Pendant cette période, beaucoup de personnes ont enfin eu le temps d’essayer Claude Code, y compris des utilisateurs non techniques, qui l’ont utilisé, par exemple, pour analyser des transcriptions de podcasts ou effectuer des analyses de données complexes. Nous avons constaté que le cadre d’agents IA de Claude Code commençait à montrer une adéquation précoce avec le marché, même auprès des utilisateurs non techniques. En interne, nous disposions déjà d’un prototype fonctionnel, initialement prévu pour une sortie ultérieure, mais ces retours nous ont convaincus que « le moment était venu ». Nous avons donc saisi cette opportunité, aboutissant à ces dix jours intenses.
Peter Yang : Si j’ai bien compris, au cours de l’année passée, vous avez partagé de nombreux prototypes dans votre Slack interne, recueilli d’abondants retours, et finalement identifié un prototype viable. Puis, voyant la demande du marché, vous avez lancé une course contre la montre pour le finaliser et le lancer.
Jenny :
Exactement. C’est à peu près cela. Nous avions initialement prévu de le lancer dans quelques semaines, mais nous avons senti que « le moment était venu ». Cela nous a incités, dans un contexte de contrainte temporelle, à réduire la portée du produit à un périmètre plus réaliste et réalisable, et à mobiliser toutes nos ressources et toute notre énergie pour réussir ce lancement.
Itérations initiales de conception : passage d’un outil de workflow à un chat minimaliste
Peter Yang : Pouvez-vous nous partager quelques expériences tirées des premières itérations, ou montrer certains contenus encore en cours de développement ?
Jenny :
Bien sûr. J’ai spécifiquement rassemblé des captures d’écran des premières versions, afin de vous montrer notre démarche de conception et notre processus d’itération.
Début 2025, nous avions un prototype préliminaire, conçu conjointement avec un autre designer. À ce stade, nous essayions de rendre cet outil plus orienté « tâche » ou « workflow ». Nous craignions en effet que les utilisateurs ne comprennent pas bien comment utiliser Cowork pour accomplir des tâches concrètes ou obtenir des résultats tangibles — comme créer un tableau de bord (dashboard) ou agréger des données provenant de sources variées. Aussi, nous avions conçu une interface très structurée, presque comme un outil de workflow — par exemple : « Ajoutez ces éléments, voici les entrées (inputs), voici les sorties (outputs) ». La fonctionnalité de chat était reléguée à un rôle secondaire.
Mais pourquoi rendre les choses si compliquées, alors qu’en 2025, nous pourrions tout simplement demander à Claude de s’en charger ?
C’était l’une de nos orientations initiales en matière de conception, mais nous avons ensuite choisi de simplifier, en revenant à une interface semblable à une simple boîte de discussion (chat box). Nous avons tenté d’orienter les utilisateurs vers des objectifs plus précis, comme l’analyse ou la génération de documents. Nous avions aussi conçu un prototype fonctionnel : en cliquant, l’utilisateur voyait diverses options, chacune accompagnée de boutons réglables — par exemple, pour ajuster la longueur du document ou choisir son type (note ou présentation). Toutefois, cette conception s’est révélée trop complexe et oppressante pour l’utilisateur.
Ainsi, au fil de multiples explorations et essais, nous avons constamment cherché un équilibre entre deux approches : définir explicitement les scénarios d’usage, ou bien maintenir une liberté formelle similaire à celle d’une boîte de discussion.
Finalement, la version que nous avons publiée il y a quelques semaines est celle que vous connaissez aujourd’hui. Nous avions auparavant testé une expérience utilisateur quasi « guidée » (wizard-like), où l’utilisateur cliquait pour voir des suggestions telles que « Créez un document de trois à cinq pages », etc.
Nous avions alors intégré de nombreux éléments dans l’interface, afin de la distinguer d’une simple boîte de discussion. Or, nous avons constaté que cette conception rendait l’interface trop complexe, avec une concurrence trop forte entre les éléments visuels. Nous avons donc décidé de simplifier le design, en supprimant la plupart des éléments superflus.
L’interface utilisateur que vous voyez aujourd’hui a été considérablement simplifiée. Nous avons retiré les barres latérales (sidebars) envahissantes, la rapprochant ainsi d’une boîte de discussion classique, mais avec des modifications sur la page d’accueil : celle-ci ressemble désormais davantage à une « liste de tâches » (to-do list) partagée entre moi et Claude, plutôt qu’à un outil de discussion surchargé de suggestions et d’instructions complexes.
Peter Yang : Peut-être que, dans le futur, il pourra supporter plusieurs agents, permettant de gérer les workflows en glissant-déposant les tâches.
Jenny :
Peut-être que cela deviendra possible à l’avenir. Mais je tiens à souligner que l’interface utilisateur était totalement différente il y a environ quatre ou cinq semaines. Nous apprenons continuellement, explorons ce qui fonctionne le mieux, ce qui fonctionne moins bien, et cherchons activement la meilleure façon de présenter cette technologie à l’utilisateur.
Positionnement différencié entre Cowork et Claude Code
Peter Yang : Lors de mon utilisation de Claude Code, je partage souvent des retours sur Twitter. Il intègre de nombreuses commandes avec barre oblique (slash commands), qu’il faut apprendre progressivement. Cette expérience ressemble un peu à une « chasse au trésor » (treasure hunt) dans un magasin Costco : on ne sait jamais ce qu’on va découvrir.
Mais pour les débutants, cette approche n’est pas très accueillante. C’est davantage un jeu : plus on l’utilise, plus on s’y familiarise. J’ai l’impression que Cowork cherche à explorer un terrain intermédiaire entre un outil de discussion classique et Claude Code. Il ne cache pas toutes ses fonctionnalités, tout en guidant subtilement l’utilisateur pour une meilleure appropriation.
Jenny :
Oui. Cowork supporte toujours les commandes avec barre oblique (slash commands), mais elles ne constituent pas le mode principal d’interaction. Personnellement, je considère que Cowork est au moins un outil destiné à des professionnels. Nous observons que de nombreux utilisateurs l’emploient déjà de façon très avancée, et qu’une communauté d’utilisateurs expérimentés s’est déjà formée. Ces derniers sont généralement prêts à consacrer du temps à l’apprentissage de fonctionnalités plus complexes, comme la création de compétences (skills), leur partage avec l’équipe, ou l’utilisation de commandes abrégées (shorthand commands).
Toutefois, notre objectif est de faire de ces fonctionnalités des modes d’interaction secondaires, non obligatoires. Autrement dit, même un utilisateur ignorant de toutes les commandes peut facilement utiliser Cowork. Nous voulons que l’interaction avec Claude soit naturelle et intuitive, sans qu’il soit nécessaire de mémoriser une série de commandes pour accomplir une tâche.
Processus de planification et vision stratégique
Peter Yang : Comment fonctionne le processus de planification chez Anthropic ? Procédez-vous à une planification annuelle et à la fixation d’objectifs ? Ou privilégiez-vous davantage le développement de prototypes et les essais itératifs ?
Jenny :
Notre méthode de planification varie à chaque fois. Dans mon équipe, nous opérons une planification mensuelle. Nous disposons d’un tableau de bord, qui, pour la partie Cowork, comporte au maximum environ douze tâches, toutes classées en priorité maximale (P0). Chaque tâche est attribuée à une personne directement responsable (DRI), et nous vérifions chaque semaine : « Sommes-nous toujours sur la bonne voie ? » Nous menons également des planifications trimestrielles ou semestrielles, généralement pilotées par un responsable qui indique : « Je pense que nous devrions nous orienter dans cette direction, et voici les points sur lesquels nous devons nous concentrer. » Toutefois, ces planifications ne sont pas rigoureuses au point d’imposer la réalisation de projets spécifiques. Elles visent plutôt à donner une orientation globale à l’équipe, ce qui implique une grande flexibilité.
Peter Yang : Plutôt flexible, donc ? Ce qui est intéressant, c’est que je constate que les entreprises les plus innovantes effectuent rarement des planifications annuelles, mais préfèrent plutôt itérer continuellement et apprendre directement des utilisateurs. Avez-vous, au cours de votre carrière, déjà rédigé un « North Star » — une vision stratégique illustrée sous forme de présentation ? Est-ce utile, selon vous ?
Jenny :
J’ai effectivement rédigé un tel document l’an dernier. Je pense que les visions stratégiques ont une réelle valeur : elles donnent une direction à l’équipe et aident à garder une clarté sur les travaux à venir. Toutefois, comme le domaine technologique dans lequel nous évoluons change extrêmement vite, avec l’apparition constante de nouveaux modèles et des mises à jour de plus en plus rapides, établir une vision à un an nous semble déjà peu réaliste, encore moins une vision à deux ou cinq ans, compte tenu de l’incertitude considérable qui règne.
Cependant, la véritable valeur d’une vision réside dans sa capacité à orienter collectivement vers un même objectif, surtout dans un environnement où chacun est libre de construire des projets variés. Ainsi, je considère aujourd’hui qu’une vision ne devrait couvrir qu’un horizon de trois à six mois, et qu’elle peut prendre la forme d’un document. Je pense que lorsqu’elle est visualisée, elle est plus percutante. C’est là tout l’intérêt du design : pouvoir intégrer divers éléments et raconter, sur une période donnée, une histoire cohérente. Bien entendu, une vision peut aussi prendre la forme d’un prototype, et non pas uniquement d’une présentation statique. Elle peut ainsi aider à coordonner le travail entre les équipes, notamment lorsque cinq équipes travaillent sur des projets très similaires ou potentiellement contradictoires. Le design peut, par une démarche de « curation », contribuer à aligner ces idées et à tracer un chemin vers une expérience utilisateur idéale, plutôt que vers une expérience fragmentée.
Peter Yang : Organisez-vous des revues avec les chefs de produit, ou des revues ciblées pour les parties prenantes concernées ? Ces revues sont-elles formelles, ou les parties prenantes participent-elles directement à la conception des prototypes ?
Jenny :
Nous organisons effectivement des revues, mais contrairement à certaines entreprises où chaque fonctionnalité requiert une revue, les nôtres portent principalement sur les projets importants et à haute priorité. Leur objectif n’est pas de consommer beaucoup de temps en préparation, mais d’accroître la visibilité des projets et de recueillir des retours. Nous organisons ces revues pour les projets transversaux ayant un impact significatif sur l’entreprise.
Conseils aux designers : comment trouver sa place à l’ère de l’IA
Peter Yang : Que conseilleriez-vous aux designers qui sentent leur environnement professionnel changer rapidement ? Doivent-ils commencer à apprendre à soumettre des pull requests (PR) ? Ou doivent-ils adopter d’autres approches pour s’adapter ?
Jenny :
Si vous avez l’impression que le sol tremble sous vos pieds, c’est parce qu’il bouge effectivement. Nous devons l’admettre, apprendre à nous adapter, et reconsidérer ouvertement nos méthodes de travail actuelles. Je pense que les changements actuels affectent particulièrement les designers, car nous sommes aujourd’hui dans la deuxième vague de cette transformation. D’autres professions ont déjà traversé des mutations similaires, et c’est maintenant notre tour. Parallèlement, nos outils de conception évoluent également en continu.
Chaque fois que je ressens une remise en question de ma profession, je ressens une certaine inquiétude, comme : « Mon Dieu, mon travail change radicalement, et les gens pourraient ne plus valoriser autant mon expertise qu’auparavant. » Mais à ces moments-là, je pense à mes collègues ingénieurs. Leur travail a connu des transformations radicales bien avant le nôtre, mais ils ont non seulement su s’y adapter, mais aussi accueillir ces défis avec courage et humilité, aboutissant à 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 profondément, y sont parvenus, alors moi aussi j’y arriverai. Ils constituent pour moi un modèle d’adaptation au changement.
Peter Yang : Dans une certaine mesure, ces changements libèrent les designers de nombreuses tâches répétitives fastidieuses, comme le réglage minutieux de cadres, n’est-ce pas ? Cela vous permet de consacrer davantage d’énergie à des réflexions plus élevées et à des travaux créatifs.
Jenny :
Exactement, ou plutôt, ces changements nous permettent de faire davantage. Par exemple, quand je vois mes collègues ingénieurs réaliser aujourd’hui une fonctionnalité complète en quelques jours, alors qu’il fallait auparavant plusieurs semaines, cela me laisse vraiment bouche bée. Oui, ces changements ouvrent donc aussi de nouvelles possibilités.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
