Entretien avec le responsable de Claude Code : la programmation est désormais « résolue », les ingénieurs logiciels seront finalement remplacés par des « Builders ».
TechFlow SélectionTechFlow Sélection
Entretien avec le responsable de Claude Code : la programmation est désormais « résolue », les ingénieurs logiciels seront finalement remplacés par des « Builders ».
Ne demandez pas à l’IA ce qu’elle peut faire pour vous ; donnez-lui des outils et laissez-la agir par elle-même.
Dédié à des analyses Web3 approfondiesRédaction & traduction : TechFlow
Invité : Boris Cherny, chef de projet Claude Code
Animateur : Lenny Rachitsky
Source du podcast : Lenny's Podcast
Titre original : Head of Claude Code : What happens after coding is solved | Boris Cherny
Date de diffusion : 19 février 2026
Résumé des points clés
Boris Cherny est le fondateur et chef de projet de Claude Code chez Anthropic. En seulement un an, il a transformé un prototype simple basé sur le terminal en un outil qui redéfinit progressivement le rôle de l’ingénieur logiciel et influence désormais tous les domaines professionnels.
Dans cet entretien, les sujets suivants sont abordés :
- Comment Claude Code est passé d’un prototype développé rapidement à un outil représentant 4 % des contributions publiques sur GitHub, avec un doublement du nombre d’utilisateurs actifs quotidiens le mois dernier.
- Les principes produit contre-intuitifs à la base du succès de Claude Code.
- Pourquoi Boris considère que le problème de la programmation est désormais « résolu ».
- Les besoins latents ayant façonné le développement de Claude Code et de Cowork.
- Des conseils pratiques pour tirer le meilleur parti de Claude Code et de Cowork.
- Pourquoi réduire la taille des équipes tout en leur accordant un accès illimité aux tokens améliore la qualité des produits IA.
- Pourquoi Boris a brièvement quitté Anthropic pour rejoindre Cursor, avant d’y revenir deux semaines plus tard.
- Les trois principes fondamentaux partagés par Boris avec chaque nouveau membre de son équipe.
Résumé des idées marquantes
La vérité sur son départ puis son retour chez Anthropic
- « Ce qui m’a attiré chez Anthropic, c’est sa mission, sa priorité donnée à la sécurité. Si vous arrêtez n’importe quel employé d’Anthropic dans les couloirs pour lui demander pourquoi il travaille ici, sa réponse sera toujours ‘la sécurité’. Ce sentiment de mission partagée résonne profondément en moi. Je sais que c’est une nécessité personnelle : sans cela, je ne pourrais pas être heureux. »
Pourquoi Claude Code connaît une croissance aussi rapide ?
- « Chez Anthropic, penser de façon exponentielle est inscrit dans notre ADN — regardez nos cofondateurs, qui figurent parmi les trois premiers auteurs de l’article fondateur sur les lois d’échelle (scaling laws). Nous pensons réellement en termes exponentiels. Si vous aviez tracé la courbe exponentielle de la part de code généré par Claude Code, puis prolongé cette courbe, il était clair que nous dépasserions les 100 % d’ici la fin de l’année. »
- « L’innovation n’a pas de feuille de route : on ne peut pas la forcer à se produire. Il faut offrir de l’espace — ou plutôt un sentiment de ‘sécurité psychologique’ — où l’échec est permis, où 80 % des idées peuvent être mauvaises sans conséquence. »
Quel est le prochain horizon ? La programmation est résolue
- « La programmation est essentiellement résolue — du moins pour le type de programmation que j’effectue. C’est un problème résolu, car Claude le fait. Depuis novembre, je n’ai plus modifié manuellement une seule ligne de code. Chaque jour, je soumets dix, vingt ou trente PR, toutes écrites intégralement par Claude Code. »
Le dividende inattendu de l’apprentissage par transfert
- « Le phénomène d’apprentissage par transfert (transfer learning) est fascinant : lorsqu’on entraîne un modèle à accomplir une tâche X, ses performances s’améliorent également sur une autre tâche Y. Par exemple, depuis le lancement de notre technologie Quad Code, l’équipe d’ingénierie a grossi d’environ quatre fois, mais ce qui est encore plus remarquable, c’est que la productivité de chaque ingénieur a augmenté de 200 %. »
Principe d’équipe n°1 : volontairement sous-doter en ressources (underfund)
- « Lorsqu’un projet est volontairement ‘sous-doté’, les personnes sont contraintes d’utiliser Claude. Si vous affectez un ingénieur seul sur un projet, sa motivation interne à livrer rapidement provient de son désir de bien faire. Et si vous avez Claude, vous pouvez l’utiliser pour automatiser une grande partie du travail. »
Principe d’équipe n°2 : accorder aux ingénieurs un accès illimité aux tokens
- « Ne cherchez pas à optimiser dès le départ, ne réduisez pas les coûts trop tôt : donnez d’abord autant de tokens que possible aux ingénieurs. Accorder un accès illimité aux tokens dès l’intégration est une pratique que je soutiens pleinement, car elle permet aux gens d’expérimenter librement des idées folles. Les innovations les plus intéressantes émergent précisément de ces expérimentations sans entraves. »
L’analogie avec l’imprimerie : la partie amusante change
- « L’analogie la plus juste est celle de l’imprimerie. Je n’ai plus besoin de faire ces tâches fastidieuses — jongler avec Git, utiliser divers outils — ce n’était jamais la partie amusante. Ce qui est amusant, c’est réfléchir à ce qu’on veut construire, parler aux utilisateurs, concevoir de grands systèmes, penser à l’avenir, collaborer avec l’équipe. Aujourd’hui, je peux consacrer bien plus de temps à ces activités. »
Quelles professions changeront ensuite ? Les agents arrivent sur les ordinateurs
- « Je pense que ce seront beaucoup de postes adjacents à l’ingénierie — chef de produit, designer, data scientist — puis, progressivement, presque tous les métiers pouvant être effectués sur ordinateur. Le sens véritable d’un ‘agent’ : un LLM capable d’utiliser des outils — il ne se contente pas de parler, il agit réellement, interagit avec votre système. »
Une réorganisation de l’échelle professionnelle : les ‘Builders’ remplacent les ingénieurs
- « D’ici la fin de l’année, ces frontières deviendront de plus en plus floues. Dans certains endroits, le titre de ‘software engineer’ commencera à disparaître, remplacé par celui de ‘Builder’, ou alors tout le monde deviendra chef de produit tout en écrivant du code. Ceux qui seront les mieux récompensés seront les curieux, les polyvalents, ceux qui traversent plusieurs disciplines. »
Un cadre moderne des ‘besoins latents’
- « Le cadre traditionnel des besoins latents consiste à observer ce que font les utilisateurs. Le cadre moderne que j’observe est légèrement différent : observez ce que le modèle essaie de faire, puis rendez cette activité plus facile. Le produit, c’est le modèle lui-même. Nous voulons le rendre pleinement accessible, avec le moins de ‘scaffolding’ possible, afin qu’il décide lui-même quels outils utiliser et dans quel ordre. »
Construire Cowork en 10 jours grâce à l’IA
- « Cowork est né d’un ‘besoin latent’ — nous avons vu des gens utiliser Claude Code pour des tâches non techniques. La solution finale a été de le construire entièrement avec Claude Code, en 10 jours. Cowork intègre un système de sécurité extrêmement sophistiqué, dont tout le code a été généré par Claude Code. »
La triple couche de sécurité d’Anthropic
- « La première couche concerne l’alignement et l’interprétabilité mécanique ; la deuxième couche est constituée des évaluations (Eval), menées dans des scénarios de laboratoire ; la troisième couche consiste à observer le comportement du modèle dans le monde réel. Nous devons publier plus tôt que ce que nous estimons prêt, afin d’obtenir des retours rapides. Même après publication, nous continuons à apprendre beaucoup sur l’alignement et la sécurité. »
L’anxiété liée au blocage des agents
- « Je me lève chaque matin et la première chose que je fais est d’ouvrir l’application iOS Claude sur mon iPhone pour voir les progrès de mes agents pendant la nuit. Cela génère effectivement une certaine anxiété — une sorte de sentiment selon lequel ‘un agent est bloqué, et j’ai perdu beaucoup de productivité’. Je n’aurais jamais imaginé utiliser iOS pour ‘écrire du code’. »
Les principes fondamentaux de la conception de produits IA
- « Ne demandez pas ce que le modèle peut faire pour vous, mais réfléchissez à comment lui fournir des outils pour qu’il agisse lui-même. N’exercez pas un contrôle excessif, ne l’enfermez pas dans une boîte. Concevez toujours pour le modèle de dans six mois, pas pour celui d’aujourd’hui. Quand ce modèle arrivera, votre produit décollera immédiatement. »
Une astuce pour les utilisateurs experts : le mode Plan
- « Je commence environ 80 % de mes tâches en mode Plan. C’est très simple : il suffit d’ajouter dans l’invite la phrase ‘Veuillez ne pas écrire de code pour le moment’. Une fois que le plan semble bon, je demande ensuite à l’agent de l’exécuter. Utiliser le modèle le plus puissant (Opus 4.6) est souvent même moins coûteux. »
Pourquoi Boris a brièvement quitté Anthropic pour Cursor (et pourquoi il y est revenu)
Lenny (animateur) : Il y a environ six mois, vous avez quitté Anthropic pour rejoindre Cursor, mais vous êtes revenu deux semaines plus tard. Que s’est-il passé ?
Boris Cherny :
C’est la transition professionnelle la plus rapide que j’aie jamais vécue. J’ai rejoint Cursor parce que j’étais un grand fan de ce produit, et j’ai été impressionné par l’équipe — c’est une excellente équipe, travaillant sur des projets passionnants. Je pensais qu’ils avaient vu plus tôt que la plupart des gens l’orientation future de la programmation assistée par IA, donc l’idée de construire un excellent produit là-bas m’attirait fortement. Mais dès mon arrivée, j’ai réalisé que ce que je regrettais le plus, c’était la mission d’Anthropic. C’était d’ailleurs ce qui m’avait initialement motivé à y rejoindre — avant cela, je travaillais dans une grande entreprise technologique, mais je voulais participer, au sein d’un laboratoire, à façonner l’avenir de cette chose folle.
Ce qui m’a attiré chez Anthropic, c’est sa mission, sa priorité donnée à la sécurité. Si vous arrêtez n’importe quel employé d’Anthropic dans les couloirs pour lui demander pourquoi il travaille ici, sa réponse sera toujours ‘la sécurité’. Ce sentiment de mission partagée résonne profondément en moi. Je sais que c’est une nécessité personnelle : sans cela, je ne pourrais pas être heureux. Peu importe à quel point le travail lui-même est passionnant, même sur un produit incroyable, rien ne peut remplacer ce sentiment de mission. Cette prise de conscience est venue rapidement et clairement.
Le premier anniversaire de Claude Code
Lenny (animateur) : Revenons sur Anthropic et sur le travail que vous y avez accompli. Ce podcast sortira à peu près un an après le lancement de Claude Code. Vous avez probablement vu le rapport de SemiAnalysis — il indique que 4 % des contributions publiques sur GitHub sont créées par Claude Code, et prédit que ce chiffre atteindra un cinquième d’ici la fin de l’année. Le jour même de l’enregistrement de ce podcast, Spotify a publié une actualité selon laquelle leurs meilleurs ingénieurs n’ont pas écrit une seule ligne de code depuis décembre, se fiant entièrement à l’IA. Que retirez-vous de cet impact sur une année ?
Boris Cherny :
Ces chiffres sont tout simplement fous — bien supérieurs à ce que j’imaginais, et ce ne sont encore que les contributions publiques. Si l’on incluait les dépôts privés, ils seraient encore bien plus élevés. Mais ce qui me semble le plus fou, ce n’est pas tant le chiffre actuel que la vitesse de notre croissance — car sur n’importe quelle dimension, la croissance de Claude Code s’accélère continuellement : elle ne monte pas seulement, elle monte de plus en plus vite. Au lancement de Claude Code, il s’agissait d’un petit hack. Anthropic avait globalement une idée claire de vouloir développer un produit de programmation, et la trajectoire historique de construction de modèles chez la société suit une logique bien définie : d’abord rendre le modèle très performant en programmation, puis en utilisation d’outils, puis en utilisation d’ordinateurs — cela découle aussi d’une préoccupation de sécurité, car à mesure que les capacités de l’IA augmentent, elles doivent être développées de manière responsable.
L’origine de Claude Code
Boris Cherny :
Après avoir rejoint Anthropic, j’ai d’abord passé un mois à créer divers prototypes insolites, la plupart restés inédits ; puis un autre mois à effectuer des entraînements complémentaires afin de bien comprendre la recherche sous-jacente. Pour bien faire mon travail, je devais vraiment saisir la couche située en dessous de celle sur laquelle je travaillais. Dans le domaine de l’IA, il est indispensable, dans une certaine mesure, de comprendre le modèle pour concevoir un bon produit.
La première version de Claude Code s’appelait ClaudeCLI. Elle démontrait comment le modèle pouvait utiliser plusieurs outils. Le moment le plus marquant fut lorsque je lui ai fourni un outil bash, et qu’il a spontanément utilisé cet outil pour répondre à ma question « Quelle musique suis-je en train d’écouter ? ». C’était magique, car je ne lui avais absolument pas dit « utilise cet outil pour cette tâche » — il l’a déduit tout seul. Après l’avoir partagé en interne, la réaction fut limitée à deux likes — rien de plus. Car dès qu’on parlait d’outils de programmation, tout le monde pensait IDE ; personne ne voyait l’intérêt d’un outil fonctionnant dans un terminal. Ce choix semblait bizarre, effectivement atypique. Mais j’avais choisi le terminal uniquement parce que, durant les premiers mois, j’étais seul, et que c’était la méthode la plus simple à mettre en œuvre.
C’est là une leçon importante en matière de conception produit — au stade initial, il faut volontairement limiter les ressources allouées. Nous avons ensuite envisagé de changer de format, mais avons finalement décidé de rester sur le terminal, principalement parce que les modèles évoluaient trop vite pour qu’un autre format puisse les suivre. C’était une question que je me posais régulièrement, tard le soir : le modèle continue d’évoluer — que faire ? Le terminal était la seule réponse qui me venait à l’esprit, et effectivement, après sa sortie, il a rapidement connu un grand succès, devenant un véritable phénomène interne chez Anthropic, avec une croissance quasi verticale des utilisateurs actifs quotidiens.
Lors de sa sortie publique en février, il n’a pas rencontré immédiatement le succès. Ce n’est que plusieurs mois plus tard que la majorité des gens ont véritablement compris ce qu’il était. Il était tellement différent ! Une partie du succès de Claude Code repose sur le concept de « besoin latent » — nous avons amené l’outil là où les gens étaient déjà, rendant leurs flux de travail existants un peu plus faciles. Certes, étant donné qu’il fonctionne dans un terminal, il est un peu étrange, et demande une ouverture d’esprit pour l’adopter. Aujourd’hui, Claude Code est disponible sur iOS et Android, en application de bureau, en version web, sous forme de plug-in pour les IDE, intégré à Slack et à GitHub — il est partout où sont les ingénieurs, et est désormais bien plus familier et intuitif. Le fait qu’il soit utile dès le départ était déjà une surprise. À mesure que l’équipe grandissait, que le produit évoluait, des startups aux plus grandes entreprises technologiques, des utilisateurs du monde entier se sont mis à l’utiliser et à nous envoyer des retours. En regardant cette année en arrière, nous avons constamment appris des utilisateurs. Personne ne savait vraiment ce qu’il faisait : nous explorions tous ensemble.
A quelle vitesse l’IA transforme-t-elle le développement logiciel ?
Lenny (animateur) : Vous avez lancé ce produit il y a un an — ce n’était pas le premier outil permettant de programmer avec l’IA, mais en un an, toute l’industrie du génie logiciel a subi une transformation radicale. Au début, tout le monde disait : ‘L’IA peut-elle écrire 100 % du code ? Impossible !’ Aujourd’hui, tout le monde dit : ‘Bien sûr, c’est exactement ce qui se passe.’ Tout va trop vite.
Boris Cherny :
Lors de la conférence Code with Claude en mai 2025, j’ai prononcé une brève allocution. Pendant la séance de questions-réponses, on m’a demandé quelle était ma prédiction pour la fin de l’année. J’ai répondu : « D’ici la fin de l’année, vous n’aurez peut-être plus besoin d’un IDE pour écrire du code », et nous commençons déjà à voir des ingénieurs qui n’en utilisent plus. À peine avais-je fini ma phrase qu’un soupir collectif parcourut la salle. Cette prédiction semblait folle à l’époque, mais chez Anthropic, penser de façon exponentielle est inscrit dans notre ADN — regardez nos cofondateurs, qui figurent parmi les trois premiers auteurs de l’article fondateur sur les lois d’échelle. Nous pensons réellement en termes exponentiels. Si vous aviez tracé la courbe exponentielle de la part de code généré par Claude Code, puis prolongé cette courbe, il était clair que nous dépasserions les 100 % d’ici la fin de l’année. C’est exactement ce que j’ai fait, et pour moi personnellement, cela s’est produit en novembre, et cela continue depuis. Nous observons aujourd’hui la même chose chez de nombreux clients.
L’importance de l’esprit expérimental dans l’innovation IA
Lenny (animateur) : Votre récit de ce parcours est fascinant — cette sensation de jouer librement, pour voir ce qui se produit. Cela semble être un élément central de nombreuses grandes innovations dans le domaine de l’IA : quelqu’un pousse le modèle plus loin que la plupart des autres.
Boris Cherny :
Sur l’innovation, une chose est certaine : elle n’a pas de feuille de route : on ne peut pas la forcer à se produire. Il faut offrir de l’espace — ou plutôt un sentiment de ‘sécurité psychologique’ — où l’échec est permis, où 80 % des idées peuvent être mauvaises sans conséquence. Il faut aussi instaurer un certain niveau de responsabilité : si une idée ne fonctionne pas, on reconnaît la perte et on passe à la suivante, sans s’enliser davantage. Au tout début de Claude Code, je ne savais absolument pas si cet outil serait utile. Même lors de sa sortie publique en février, il ne rédigeait que 20 % de mon propre code. En mai, ce chiffre était passé à 30 %, et je continuais à utiliser Cursor pour la majeure partie de mon code, jusqu’à ce que je franchisse le cap des 100 % en novembre. Pourtant, dès le tout premier jour, j’avais eu le sentiment d’avoir trouvé quelque chose. Je passais chaque soir et chaque week-end à étudier cet outil. Parfois, on trouve une piste, et il faut la suivre jusqu’au bout.
Le flux de travail actuel de Boris pour la programmation (100 % géré par l’IA)
Lenny (animateur) : Donc aujourd’hui, 100 % de votre code est rédigé par Claude Code. C’est bien là votre situation actuelle ?
Boris Cherny :
Oui, 100 % du code est rédigé par Claude Code. Je suis un ingénieur particulièrement productif : même à l’époque d’Instagram, j’étais l’un des ingénieurs les plus productifs de l’entreprise, et cela reste vrai chez Anthropic. Chaque jour, je soumets dix, vingt ou trente PR, toutes rédigées intégralement par Claude Code. Depuis novembre, je n’ai plus modifié manuellement une seule ligne de code.
Je continue à lire le code — je ne pense pas que nous soyons arrivés à un stade où on pourrait s’en passer totalement, surtout quand beaucoup de personnes utilisent votre programme : il faut s’assurer qu’il est correct et sécurisé. Chez Anthropic, nous disposons également d’un système de revue automatique complète du code par Claude : 100 % des PR sont examinées par Claude, puis soumises à une revue humaine supplémentaire. Ces points de contrôle sont pertinents, sauf dans le cas de codes purement expérimentaux, qui ne seront jamais exécutés en production.
Quel est le prochain horizon ?
Lenny (animateur) : Le fait que 100 % du code soit généré par l’IA semble un jalon fou, et pourtant cela paraît désormais naturel — ‘bien sûr, c’est ainsi que le monde fonctionne’. Alors, quel sera le prochain changement majeur dans la façon d’écrire du logiciel ?
Boris Cherny :
Je pense qu’une chose qui se produit actuellement, c’est que Claude commence à proposer des idées lui-même. Il analyse les retours utilisateurs, les rapports de bugs, les données de télémétrie, et commence à suggérer des corrections et des fonctionnalités à implémenter, devenant presque un collègue. Deuxièmement, nous commençons à dépasser le cadre strict de la programmation. À ce stade, on peut dire que la programmation est essentiellement résolue — du moins pour le type de programmation que j’effectue, c’est un problème résolu, car Claude le fait.
Nous nous posons donc maintenant la question : qu’est-ce qui vient ensuite ? Que faire au-delà de la programmation ? Il existe de nombreuses activités adjacentes, et je pense que ce sont celles-là qui viendront ensuite. Il y a aussi des tâches plus générales — j’utilise aujourd’hui Cowork pour des activités totalement déconnectées de la programmation : il y a quelques jours, j’ai utilisé Cowork pour régler une amende de stationnement, et toute la gestion de projet de mon équipe est désormais assurée par Cowork — synchronisation d’informations entre feuilles de calcul et Slack, envoi d’e-mails, etc. Je pense donc que c’est là que se situe le prochain horizon. La programmation est essentiellement résolue, dans les prochains mois, nous verrons l’ensemble des bases de code et des piles technologiques de l’industrie être progressivement résolues.
Lenny (animateur) : Le fait que Claude vous aide à déterminer ‘quoi faire ensuite’ est fascinant. Beaucoup d’auditeurs sont chefs de produit, et ils transpirent probablement en ce moment. Comment utilisez-vous Claude pour cela ?
Boris Cherny :
La méthode la plus simple est la suivante : ouvrez Claude Code ou Cowork, et pointez vers un canal Slack. Nous disposons d’un canal Slack dédié aux retours internes sur Claude Code, créé dès les premières versions internes, et alimenté en continu. Au début, chaque fois qu’un utilisateur envoyait un retour, j’intervenais immédiatement pour corriger aussi vite que possible — en une minute, parfois en cinq minutes, avec une boucle de rétroaction extrêmement rapide. Cela crée un sentiment d’écoute, car habituellement, lorsqu’on utilise un produit et qu’on donne un retour, celui-ci disparaît dans un trou noir, et on ne souhaite plus jamais en donner un autre. Mais si les utilisateurs se sentent écoutés, ils continuent à contribuer et à aider à l’amélioration. Aujourd’hui, je fais la même chose, mais Claude prend en charge la majeure partie du travail.
Lenny (animateur) : Les performances d’Opus 4.6 se sont-elles nettement améliorées ? Globalement, quel est l’état d’avancement de ce modèle ?
Boris Cherny :
Oui, les performances se sont nettement améliorées. Je pense que cela tient en partie à un entraînement spécifique à la programmation. Codex est actuellement l’un des modèles de programmation les plus performants au monde, et ses performances ne cessent de s’améliorer. Par exemple, la version 4.6 se distingue particulièrement, mais ce n’est pas seulement l’entraînement spécifique à la programmation qui explique cette progression. En effet, les entraînements que nous menons dans d’autres domaines se transfèrent également efficacement aux tâches de programmation. Ce phénomène d’apprentissage par transfert (transfer learning) est fascinant — lorsqu’on entraîne un modèle à accomplir une tâche X, ses performances s’améliorent également sur une autre tâche Y. Par exemple, depuis le lancement de notre technologie Quad Code, la taille de notre équipe d’ingénierie a augmenté d’environ quatre fois, mais ce qui est encore plus remarquable, c’est que la productivité de chaque ingénieur a augmenté de 200 %, notamment en termes de nombre de pull requests soumises — une augmentation tout simplement incroyable pour quiconque étudie la productivité des développeurs.
J’ai travaillé chez Meta, où je gérais la qualité du code pour l’ensemble des bases de code de Facebook, Instagram et WhatsApp. Nous mettions alors l’accent sur l’amélioration de la productivité des ingénieurs, car une meilleure qualité de code augmente directement l’efficacité du développement. Pourtant, même avec une centaine d’ingénieurs travaillant ensemble pendant un an, les gains de productivité ne dépassaient généralement que quelques points de pourcentage.
Le coût de l’innovation rapide
Lenny (animateur) : Ce qui est encore plus frappant, c’est que ces changements sont devenus tellement ordinaires. Lorsqu’on entend ces chiffres, on peut les considérer comme acquis, car l’IA transforme notre façon de travailler. Mais une telle transformation radicale du développement logiciel, de la conception de produits et de l’ensemble du secteur technologique est sans précédent.
Boris Cherny :
Bien sûr, cette rapidité de changement pose aussi certains défis. À titre personnel, la vitesse de mise à jour des modèles est telle que j’ai parfois du mal à sortir de mes schémas mentaux anciens pour m’adapter aux nouvelles évolutions. Je remarque même que les nouveaux membres de l’équipe, notamment les jeunes diplômés, adoptent souvent une approche plus prospective, plus alignée sur l’AGI, tandis que je me retrouve parfois en retard.
Par exemple, il y a quelques mois, nous avons eu un problème de fuite mémoire — la consommation mémoire de Claude Code augmentait progressivement jusqu’à provoquer un plantage, un problème d’ingénierie classique. La méthode traditionnelle consiste à obtenir un instantané de la pile (heap snapshot), à le charger dans un débogueur, puis à l’analyser avec des outils spécialisés. C’est ce que j’ai fait. Mais un ingénieur plus récemment recruté a simplement demandé à Claude Code : « Hé Claude, il semble y avoir une fuite — tu peux la trouver ? » Claude Code a fait exactement la même chose que moi — obtenu un instantané de la pile, écrit un petit outil personnalisé pour l’analyser (un programme généré à la volée), identifié le problème, et soumis une pull request — et plus vite que moi. Ainsi, pour ceux d’entre nous qui utilisons les modèles depuis longtemps, il est essentiel de se recentrer constamment sur le présent, sans rester prisonnier des cadres mentaux associés aux anciens modèles — ce n’est plus Sonnet 3.5, les nouveaux modèles sont radicalement différents, et cette évolution de la pensée est profonde.
Les principes de travail de l’équipe Claude Code
Lenny (animateur) : J’ai entendu dire que vous appliquez certains principes spécifiques au sein de votre équipe, dont l’un serait : ‘Y a-t-il quelque chose de mieux que de faire soi-même une tâche ? Faites-la faire par Claude.’ L’histoire de la fuite mémoire que vous venez de raconter illustre parfaitement ce principe — vous aviez presque oublié votre propre règle, et oublié de demander d’abord à Claude d’essayer.
Boris Cherny :
Il y a aussi une autre chose intéressante : le principe de « sous-dotement volontaire » (underfund). Lorsqu’on sous-dote volontairement, les gens sont contraints d’utiliser Claude — c’est un phénomène que nous observons régulièrement. Parfois, nous plaçons un ingénieur seul sur un projet : sa motivation interne à livrer rapidement provient de son désir de bien faire, de concrétiser rapidement de bonnes idées. Si vous avez Claude, vous pouvez l’utiliser pour automatiser une grande partie du travail, donc le sous-dotement est un principe.
Un autre principe est d’encourager les gens à agir plus vite — si une tâche peut être faite aujourd’hui, faites-la aujourd’hui. C’est une valeur très forte au sein de l’équipe. C’était particulièrement important au début, car j’étais seul, et notre seul avantage était la vitesse — notre seule façon de survivre sur ce marché concurrentiel de la programmation. Mais même aujourd’hui, c’est encore l’un de nos principes. Pour aller plus vite, une bonne méthode consiste à faire faire plus de choses par Claude — ces deux principes se renforcent mutuellement.
Pourquoi accorder aux ingénieurs un accès illimité aux tokens
Lenny (animateur) : Le concept de ‘sous-dotement’ est fascinant, car l’idée courante est que l’IA vous permet de faire plus avec moins d’employés. Or vous dites : non seulement l’IA vous permet d’aller plus vite, mais si vous utilisez moins de personnes, vous tirez en réalité davantage profit des outils IA.
Boris Cherny :
Oui. Si vous embauchez des ingénieurs excellents, ils trouveront le moyen d’y parvenir. C’est aussi un sujet que j’aborde fréquemment avec les CTO et diverses entreprises. Mon conseil est généralement le suivant : ne cherchez pas à optimiser dès le départ, ne réduisez pas les coûts trop tôt : donnez d’abord autant de tokens que possible aux ingénieurs. Vous commencez aujourd’hui à voir certaines entreprises adopter cela comme un avantage — accorder un accès illimité aux tokens dès l’intégration est une pratique que je soutiens pleinement, car elle permet aux gens d’expérimenter librement des idées folles. Une fois qu’une idée fonctionne, c’est le moment de réfléchir à l’extension, à l’optimisation, à l’utilisation de Haiku ou de Sonnet à la place d’Opus, ou à la réduction de l’échelle. Mais au départ, utilisez massivement les tokens, testez les idées, et laissez les ingénieurs libres de le faire.
Lenny (animateur) : Les auditeurs pourraient penser : ‘Bien sûr, il travaille chez Anthropic, il veut forcément que nous utilisions plus de tokens.’ Mais vous affirmez que les idées innovantes les plus intéressantes émergent précisément de ces expérimentations sans entraves.
Boris Cherny :
Oui. Et la réalité est qu’à petite échelle — par exemple, lorsqu’un ingénieur expérimente individuellement — le coût des tokens est relativement faible comparé à son salaire ou à d’autres coûts opérationnels. Ce qui fait vraiment exploser les coûts, c’est lorsque quelque chose fonctionne réellement et que l’échelle augmente — c’est alors qu’il faut optimiser, mais pas avant.
Lenny (animateur) : Avez-vous déjà vu une entreprise dont les coûts en tokens dépassaient les salaires ?
Boris Cherny :
Chez Anthropic, nous commençons à voir certains ingénieurs dépenser plusieurs dizaines de milliers de dollars en tokens chaque mois, et nous observons des cas similaires dans certaines entreprises.
La programmation restera-t-elle une compétence importante à l’avenir ?
Lenny (animateur) : Vous allez vous ennuyer de coder ? Ce n’est plus votre rôle d’ingénieur logiciel, cela vous rend-il triste ?
Boris Cherny :
Cela me semble intéressant, car j’ai appris à programmer pour des raisons pratiques. Je suis un ingénieur autodidacte : j’ai étudié l’économie à l’université, pas l’informatique, mais j’ai commencé à écrire des programmes dès le lycée, et toujours de façon très pratique. J’ai appris à programmer pour tricher — nous avions des calculatrices graphiques, et j’y ai programmé les réponses. L’année suivante, les exercices étaient trop difficiles, je ne connaissais même pas les questions, alors j’ai écrit un petit solveur algébrique pour les résoudre. Puis j’ai découvert que je pouvais transmettre ce programme à toute la classe via un petit câble, et tout le monde a eu la note maximale — mais cela a été découvert, et le professeur nous a demandé d’arrêter. Dès le départ, la programmation était pour moi un moyen de construire des choses, pas une fin en soi.
Plus tard, je suis tombé amoureux de la programmation elle-même — j’ai écrit un livre sur TypeScript, j’ai fondé la plus grande communauté TypeScript hors ligne au monde, car j’adorais ce langage, la programmation fonctionnelle et les systèmes de types. Mais pour moi, la programmation est fondamentalement un outil, un moyen d’accomplir des tâches. Bien sûr, ce n’est pas le cas pour tout le monde : certains apprécient profondément le processus même de programmation. Chacun est différent, et même si le domaine évolue, il restera toujours de la place pour apprécier cet art, pour écrire du code à la main.
Lenny (animateur) : Craignez-vous que vos compétences d’ingénieur ne se dégradent ?
Boris Cherny :
Pour ma part, je ne m’en fais pas trop. La programmation a toujours évolué — des cartes perforées, aux interrupteurs, au matériel, au papier et au crayon, puis aux logiciels exécutés sur des machines virtuelles : voilà environ soixante ans que nous écrivons des programmes ainsi. À chaque étape, certains ont déclaré : « Ce n’est pas de la vraie programmation. » Mais je pense que vous voudrez toujours comprendre la couche inférieure, car cela vous rendra un meilleur ingénieur. Toutefois, cela ne durera probablement qu’un an environ, puis cela deviendra peut-être vraiment secondaire, comme l’assembleur l’est aujourd’hui pour les programmeurs.
Sur le plan émotionnel, j’ai toujours besoin d’apprendre de nouvelles choses — en tant que programmeur, ce n’est pas une nouveauté, car il y a toujours de nouveaux frameworks, de nouveaux langages. C’est une réalité familière dans ce domaine. Mais cela ne sera pas nécessairement le cas pour tout le monde : certaines personnes éprouveront peut-être un sentiment de perte, de nostalgie, ou une crainte de dégradation de leurs compétences.
L’analogie avec l’imprimerie : l’impact de l’IA
Lenny (animateur) : Une question revient sans cesse : avons-nous encore besoin d’apprendre à programmer ? Les étudiants doivent-ils encore apprendre à programmer à l’école ? Selon vous, cela ne sera peut-être plus une compétence obligatoire dans un ou deux ans.
Boris Cherny :
Mon avis est que pour ceux qui programment aujourd’hui avec Quad Code ou des agents intelligents, il est encore nécessaire de comprendre la logique fondamentale de la programmation. Mais dans un ou deux ans, cette compréhension risque de devenir moins importante.
Récemment, je me suis demandé quel événement historique pourrait servir d’analogie, car nous devons replacer ce phénomène dans un contexte historique plus large, pour essayer de déterminer si nous avons déjà connu une transformation technologique similaire. L’analogie la plus juste qui me vient à l’esprit est celle de l’imprimerie. Au milieu du XVe siècle, en Europe, le taux d’alphabétisation était extrêmement faible — moins de 1 % de la population, principalement des scribes employés par la noblesse et les rois ; de nombreux dirigeants étaient eux-mêmes analphabètes. Puis Gutenberg et l’imprimerie sont apparus. Une statistique incroyable : dans les cinquante ans suivant son invention, plus de textes ont été imprimés que durant les mille années précédentes. La quantité de documents imprimés a explosé, et leur coût a chuté d’environ cent fois dans les cinquante ans suivants. Quant au taux d’alphabétisation, il a mis environ deux cents ans à passer de moins de 1 % à 70 % dans le monde, car apprendre à lire et à écrire est difficile : cela nécessite un système éducatif, du temps libre, impossible lorsqu’on passe ses journées aux champs.
Je pense que nous pourrions vivre une transformation similaire. Et il existe un témoignage historique intéressant — un visiteur a interrogé un scribe du XVe siècle sur ses impressions concernant l’imprimerie, et celui-ci a répondu avec enthousiasme : « Ce que je n’aimais pas faire, c’était copier d’un livre à un autre. Ce que j’aimais, c’était la décoration des livres, les illustrations et la reliure. Je suis ravi que mon temps soit désormais libéré.» En tant qu’ingénieur, je ressens fortement cette résonance. Je n’ai plus besoin de faire ces tâches fastidieuses — jongler avec Git, utiliser divers outils — ce n’était jamais la partie amusante. La partie amusante, c’est réfléchir à ce qu’on veut construire, parler aux utilisateurs, penser à ces grands systèmes, réfléchir à l’avenir, collaborer avec l’équipe. Aujourd’hui, je peux consacrer bien plus de temps à ces activités.
Lenny (animateur) : Et ce qui est remarquable, c’est que l’outil que vous avez construit permet à n’importe qui de faire cela, même sans formation technique. J’ai moi-même réalisé plusieurs petits projets, et chaque fois que je butais sur un obstacle, Claude m’aidait à le résoudre — les douleurs passées liées aux bibliothèques et aux dépendances ont aujourd’hui disparu.
Boris Cherny :
Exactement. Ce matin, j’ai discuté avec un ingénieur qui avait écrit un service en Go, qu’il faisait tourner depuis un mois et qui fonctionnait très bien. Je lui ai demandé comment il se sentait, et il m’a répondu : « En fait, je ne maîtrise pas vraiment Go… » Je pense que nous verrons de plus en plus souvent ce genre de situation — du moment que vous savez que le système fonctionne correctement et efficacement, vous n’avez pas besoin de connaître tous les détails.
Quelles professions l’IA va-t-elle transformer ensuite ?
Lenny (animateur) : Selon vous, quelles professions seront les plus rapidement touchées par l’IA ? Que ce soit dans le domaine technologique — chef de produit, designer — ou en dehors ?
Boris Cherny :
Je pense que ce seront beaucoup de postes adjacents à l’ingénierie — chef de produit, designer, data scientist — puis, progressivement, presque tous les métiers pouvant être effectués sur ordinateur, car les modèles deviendront de plus en plus performants dans ce domaine. Cowork est la première façon d’atteindre ces métiers, mais ce n’est que le début. Je pense qu’il introduit l’IA agentic auprès de personnes qui ne l’avaient jamais utilisée auparavant, leur donnant pour la première fois un avant-goût de ce qu’elle peut faire. En regardant le domaine de l’ingénierie il y a un an, personne ne savait vraiment ce qu’était un agent, personne ne l’avait réellement utilisé — or aujourd’hui, c’est devenu notre façon de travailler.
Et en regardant les métiers non techniques, ou semi-techniques, comme le produit ou la science des données, les gens utilisent encore principalement une IA conversationnelle — un simple chatbot. Le terme « agent » est aujourd’hui galvaudé, ayant perdu beaucoup de son sens, mais il a une signification technique très précise : un LLM capable d’utiliser des outils — il ne se contente pas de parler, il agit réellement, interagit avec votre système, utilise vos Google Docs, envoie des e-mails, exécute des commandes sur votre ordinateur. Je pense donc que tout métier utilisant des outils informatiques est le prochain sur la liste. C’est aussi pourquoi, chez Anthropic, je ressens une urgence particulière à travailler sur ce sujet — nous le prenons très au sérieux, avec des économistes, des chercheurs en politiques publiques, des spécialistes des impacts sociétaux. Nous voulons en discuter largement, afin que la société dans son ensemble puisse réfléchir collectivement à la manière d’y faire face, car cela ne doit pas être une décision prise uniquement par nous.
Lenny (animateur) : Il existe un concept appelé ‘paradoxe de Jevons’ — lorsque nous pouvons faire plus, nous embauchons davantage de personnes, ce qui rend la situation finalement moins effrayante. Dans le processus d’intégration de l’IA au travail des ingénieurs, qu’avez-vous vécu ? Avez-vous embauché plus de personnes ?
Boris Cherny :
L’équipe Claude Code recrute actuellement. Pour ma part, tout cela me rend mon travail plus agréable que jamais. Je n’ai jamais autant apprécié la programmation, car je n’ai plus à m’occuper des détails fastidieux. Nous recevons également ce type de retour de nombreux clients — ils adorent Claude Code, car il rend à nouveau la programmation amusante. Mais où cela va-t-il nous mener, c’est difficile à prédire. Je dois encore chercher des analogies historiques, et l’imprimerie est vraiment la plus juste — cette capacité, autrefois réservée à une poignée de personnes sachant lire et écrire, devient accessible à tous. C’est fondamentalement une démocratisation. Tout le monde commence à pouvoir le faire, et sans cela, la Renaissance n’aurait tout simplement pas pu se produire, car celle-ci reposait largement sur la diffusion des connaissances, la mise par écrit — à l’époque, pas de téléphone, pas d’internet, l’écrit était le moyen de coordination à grande échelle. J’imagine un monde où, dans quelques années, tout le monde pourra programmer, où n’importe qui pourra construire un logiciel à tout moment. Que cela débloquera-t-il ? Je n’en ai aucune idée, tout comme les gens du XVe siècle ne pouvaient pas imaginer ce qui allait suivre. Mais je pense que cette période de transition sera très destructrice, très douloureuse pour beaucoup, et que c’est une question à laquelle la société dans son ensemble doit réfléchir et répondre collectivement.
Des conseils pour réussir à l’ère de l’IA
Lenny (animateur) : Que conseillez-vous à ceux qui veulent s’ancrer solidement dans cette ère mouvante ? Explorer activement les outils IA, maîtriser les dernières innovations ? Y a-t-il autre chose ?
Boris Cherny :
C’est probablement le premier conseil — utilisez ces outils, familiarisez-vous avec eux, n’ayez pas peur, explorez sans retenue, restez à la pointe. Le deuxième conseil est : devenez plus que jamais un généraliste. Par exemple, à l’université, beaucoup d’étudiants en informatique apprennent à coder, mais peu étudient d’autres domaines, au mieux un peu d’architecture système. Or, parmi les ingénieurs les plus efficaces avec qui je travaille quotidiennement, beaucoup sont polyvalents — dans l’équipe Claude Code, tout le monde écrit du code : nos chefs de produit écrivent du code, nos managers d’ingénierie écrivent du code, nos designers écrivent du code, nos services financiers écrivent du code, nos data scientists écrivent du code. Et de nombreux ingénieurs traversent plusieurs domaines : les plus performants sont ceux qui sont à la fois ingénieurs-produit et ingénieurs-infrastructure, ou ingénieurs-produit dotés d’un fort sens du design, ou ingénieurs dotés d’une forte intuition commerciale, ou encore ceux qui aiment parler aux utilisateurs et comprennent bien leurs besoins. Je pense donc que ceux qui seront les mieux récompensés dans les années à venir ne seront pas seulement des natifs de l’IA, capables d’utiliser ces outils, mais aussi des esprits curieux, cultivés, capables de traverser plusieurs disciplines, de penser de façon macroscopique à la problématique qu’ils cherchent à résoudre — et non pas seulement de se concentrer sur l’ingénierie.
Lenny (animateur) : Selon vous, les trois disciplines distinctes que sont l’ingénierie, le design et la gestion de produit ont-elles encore une valeur durable, même si elles se chevauchent de plus en plus et s’empiètent mutuellement ?
Boris Cherny :
À court terme, elles continueront d’exister, mais nous commençons à observer environ 50 % de chevauchement entre ces rôles : beaucoup font en réalité la même chose, avec des spécialisations différentes. Par exemple, j’écris peut-être plus de code que notre chef de produit, qui se concentre davantage sur la coordination, la planification, les prévisions et la gestion des parties prenantes. Je pense effectivement que d’ici la fin de l’année, ces frontières deviendront de plus en plus floues, et que dans certains endroits, le titre de ‘software engineer’ commencera à disparaître, remplacé par celui de ‘Builder’, ou alors tout le monde deviendra chef de produit tout en écrivant du code.
Enquête : quels métiers apprécient davantage leur travail grâce à l’IA ?
Lenny (animateur) : J’ai mené une enquête informelle sur Twitter, demandant à des ingénieurs, des chefs de produit et des designers : depuis qu’ils utilisent des outils IA, leur travail leur procure-t-il plus ou moins de plaisir ? Chez les ingénieurs et les chefs de produit, 70 % disent en tirer plus de plaisir, environ 10 % disent en tirer moins. Chez les designers, c’est intéressant : seuls 55 % disent en tirer plus de plaisir, et 20 % disent en tirer moins.
Boris Cherny :
J’aimerais beaucoup discuter avec les deux groupes pour en savoir plus. Chez Anthropic, la plupart de nos designers écrivent du code — c’est un critère que nous évaluons lors des recrutements, et nous pratiquons également de nombreux entretiens techniques même pour les postes non techniques. La plupart de nos designers apprécient fortement les changements apportés par l’IA, car ils n’ont plus besoin de solliciter les ingénieurs pour effectuer des modifications eux-mêmes. Certains designers qui ne programmaient pas auparavant ont même commencé à le faire, ce qui est excellent pour eux, car ils peuvent lever eux-mêmes les blocages. Mais j’aimerais beaucoup entendre davantage d’expériences variées, car je suis convaincu que la situation n’est pas uniforme.
Lenny (animateur) : Donc, si vous écoutez ce podcast et que vous ne trouvez pas votre travail plus agréable, n’hésitez pas à commenter pour nous dire ce qui vous rend moins heureux — car la majorité, 70 % des chefs de produit et des ingénieurs, disent qu’ils apprécient davantage leur travail.
Boris Cherny :
Nous observons également l’utilisation d’outils différents — nos designers utilisent davantage l’application de bureau Claude pour écrire du code : ils téléchargent l’application, qui contient un onglet dédié au code, placé juste à côté de l’onglet Cowork. Il s’agit en fait du même agent Claude Code, et il est possible d’exécuter simultanément autant de sessions Claude que souhaité — nous appelons cela le « Claude multi-parallèle ». Pour les non-ingénieurs, je trouve cela plus naturel. Cela rejoint aussi le principe de porter le produit là où les gens sont déjà — ne pas demander aux gens de modifier leur flux de travail, ni d’apprendre délibérément une nouvelle chose, mais, quel que soit ce qu’ils font, rendre cette activité un peu plus facile, afin que le produit soit meilleur et plus apprécié.
Le principe des « besoins latents » dans le développement produit
Lenny (animateur) : Pouvez-vous nous expliquer ce principe des « besoins latents » ? Vous en avez parlé lors du lancement de Cowork. Pouvez-vous définir ce concept et expliquer ce qui se produit lorsqu’on débloque un besoin latent ?
Boris Cherny :
Le besoin latent est une idée selon laquelle : si votre produit est utilisé par les gens d’une manière qui n’était pas prévue, pour accomplir une tâche qu’ils souhaitent réaliser, cela vous aide, en tant que concepteur de produit, à comprendre où votre produit devrait aller ensuite. Un exemple est Facebook Marketplace. Fiona, la chef de projet, raconte souvent cette histoire — l’origine de Facebook Marketplace vient de l’observation que, dans les groupes Facebook, environ 40 % des publications concernaient des achats et des ventes. Les gens « abusaient » des groupes Facebook pour acheter et vendre, sans qu’aucun produit n’ait été conçu à cet effet, mais ils avaient trouvé cette utilisation parce qu’elle était réellement utile. Il était donc évident que, si on construisait un produit dédié à l’achat et à la vente, les utilisateurs l’adopteraient. Facebook Marketplace est né de cette observation, tout comme Facebook Dating — si vous examinez les données de consultation des profils personnels, 60 % des consultations proviennent de personnes de sexe opposé qui ne se connaissent pas, une « conduite de rencontre latente », d’où le produit Dating.
Ce concept de ‘besoin latent’ a également joué un rôle dans la naissance de Cowork. Nous avons remarqué que, au cours des six derniers mois, de nombreuses personnes utilisaient Claude Code non pas pour écrire du code. Certaines l’utilisaient pour cultiver des tomates, d’autres pour analyser leur génome, d’autres encore pour récupérer des photos de mariage sur un disque dur endommagé — des usages totalement non techniques, clairement des efforts pour accomplir ces tâches dans un terminal, ce qui suggère fortement qu’il faudrait leur construire un produit dédié.
Je me souviens d’un jour où je suis entré au bureau et où j’ai vu notre data scientist Brendan exécuter Claude Code dans un terminal. J’ai été stupéfait — comment avait-il ouvert un terminal ? C’est un produit très orienté ingénierie, que beaucoup d’ingénieurs eux-mêmes ne veulent pas utiliser. Il avait téléchargé Node.js, installé Claude Code, et effectuait des analyses SQL dans le terminal. La semaine suivante, tous les data scientists faisaient de même. Lorsque vous voyez des gens utiliser votre produit d’une manière non prévue pour accomplir une tâche qui leur est utile, c’est un signal fort indiquant que vous devriez construire un produit dédié à cette activité.
Je pense qu’il existe aujourd’hui une deuxième dimension intéressante. Le cadre traditionnel des besoins latents consiste à observer ce que font les utilisateurs, puis à rendre cette activité plus facile, en leur donnant les moyens de la réaliser. Or, le cadre moderne que j’observe depuis six mois est légèrement différent : observez ce que le modèle essaie de faire, puis rendez cette activité plus facile. Lorsque nous avons initialement construit Claude Code, beaucoup de gens construisaient des applications avec des LLM en enfermant le modèle dans une boîte : « Voici l’application que je veux construire, tu dois accomplir ce composant, interagir avec cette API de cette façon. » Mais Claude Code inverse cette approche — le produit, c’est le modèle lui-même, nous voulons le rendre pleinement accessible, avec le moins de ‘scaffolding’ possible, en lui fournissant un jeu d’outils de base, afin qu’il décide lui-même quels outils utiliser et dans quel ordre. Cela repose largement sur le « besoin latent » du modèle lui-même — qu’est-ce qu’il essaie de faire ? En recherche, nous parlons de « distribution », c’est-à-dire observer ce que le modèle tente de faire. Du point de vue produit, le besoin latent est précisément cette notion appliquée au modèle.
Comment Cowork a été construit en 10 jours
Lenny (animateur) : Parlons de Cowork. Lors de son lancement, vous avez mentionné que votre équipe l’avait construit en 10 jours. Comment cela a-t-il été possible ?
Boris Cherny :
À sa sortie, Claude Code n’a pas connu un succès immédiat. Il est devenu un véritable phénomène progressivement, avec plusieurs points d’inflexion clés — lors du lancement d’Opus 4, puis en novembre, la croissance s’accélérant de plus en plus. Mais durant les premiers mois, beaucoup de gens ne savaient pas comment l’utiliser ni même ce qu’il était. En revanche, Cowork a connu un succès immédiat à sa sortie, bien plus important que les débuts de Claude Code.
Cowork est né du « besoin latent » que nous venons d’évoquer — nous avons vu des gens utiliser Claude Code pour des tâches non techniques, et nous devions réfléchir à la manière d’y répondre. L’équipe a exploré diverses pistes pendant plusieurs mois, jusqu’à ce que quelqu’un propose : « Et si nous intégrions simplement Claude Code dans une application de bureau ? » C’est cette solution qui a fonctionné. Ensuite, nous l’avons construit en 10 jours, entièrement avec Claude Code. Cowork intègre un système de sécurité très sophistiqué, avec des garde-fous empêchant le modèle de perdre le contrôle — nous avons publié avec le produit une machine virtuelle complète, dont tout le code a été rédigé par Claude Code. Nous devions simplement réfléchir à la manière de le rendre un peu plus sûr et autonome pour les utilisateurs non ingénieurs. Tout a été réalisé par Claude Code, en environ 10 jours.
Nous l’avons publié très tôt, alors qu’il était encore très brut, mais c’est ainsi que nous apprenons — que ce soit au niveau produit ou sécurité, nous devons publier plus tôt que ce que nous jugeons prêt, afin d’obtenir des retours, de parler aux utilisateurs, de comprendre leurs besoins, et de laisser ces retours façonner l’évolution du produit.
La triple couche de sécurité IA d’Anthropic
Lenny (animateur) : Le principe de ‘publier tôt, apprendre des utilisateurs, itérer’ existe depuis longtemps, mais vous en donnez une justification unique : vous ne savez même pas ce que l’IA peut faire ni comment les gens vont l’utiliser, ce qui constitue justement une raison unique de publier tôt — pour découvrir où se situent réellement les ‘besoins latents’.
Boris Cherny :
Oui, et en tant que laboratoire prioritairement axé sur la sécurité, la publication comporte une autre dimension : la sécurité. Car il existe plusieurs approches de la sécurité des modèles. La recherche la plus fondamentale concerne l’alignement et l’interprétabilité mécanique — lors de l’entraînement du modèle, nous voulons nous assurer qu’il est sécurisé. Des techniques assez matures existent aujourd’hui pour comprendre ce qui se passe dans les neurones, par exemple, si un neurone lié à la tromperie s’active, nous commençons à pouvoir le surveiller et le comprendre. C’est l’alignement, c’est l’interprétabilité mécanique — c’est la couche la plus fondamentale.
La deuxième couche est constituée des évaluations (Eval) — un environnement de laboratoire, où le modèle est dans une ‘boîte de Pétri’, et où on l’étudie dans des scénarios synthétiques : ‘Modèle, que ferais-tu ? Est-ce que tu es aligné ? Es-tu sécurisé ?’
La troisième couche consiste à observer le comportement du modèle dans le monde réel. À mesure que les modèles deviennent plus complexes, cette couche devient de plus en plus cruciale, car le modèle peut se comporter parfaitement dans les deux premières couches, mais pas nécessairement dans la troisième. Nous avons publié Claude Code très tôt, car nous voulions étudier sa sécurité — nous l’avons utilisé en interne chez Anthropic pendant environ quatre ou cinq mois avant sa sortie publique, car c’était le premier agent à grande échelle, et nous n’étions pas certains de sa sécurité, donc nous avions besoin de l’étudier en prof
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
