Product ou engineering : la valeur migre vers le jugement
Dans une vidéo de 47 secondes, Boris Cherny (Head of Claude Code) et Cat Wu (Head of Product) posent une question simple : le futur, c'est le produit ou l'ingénierie ? Leur réponse tient en un mot : les deux. Chez Anthropic, disent-ils, l'équipe produit code, l'équipe devrel code, l'équipe design code, et les ingénieurs livrent des produits de bout en bout : ils ont une idée, la construisent, travaillent avec le juridique, le marketing et la sécurité, et suivent tout le processus. Leur conclusion : « l'IA bénéficie aux gens curieux, dotés de goût produit, qui aiment cette responsabilité end-to-end ».
Les 55 commentaires que la vidéo a déclenchés valent plus que la vidéo elle-même. Les plus lucides ne se contentent pas d'applaudir la « fusion des rôles » : ils la recadrent.
Le faux débat : « tout le monde fera les deux »
L'idée que produit et ingénierie fusionnent est la partie la moins intéressante. Comme le note Chris Bounds dans les commentaires, porter plusieurs casquettes est le propre des équipes en mode startup : « ce n'est pas parce qu'une organisation peut concentrer ces responsabilités dans une seule personne que c'est une tendance sectorielle ». Il rappelle qu'on a déjà prédit, à tort, l'obsolescence des développeurs, dont la demande n'a fait que croître.
« Tout le monde fait tout » est donc un effet de taille et d'outillage, pas une loi. Le vrai sujet est ailleurs.
La rareté change de camp
Quand construire devient bon marché, la valeur se loge dans le « quoi », plus dans le « comment ». C'est le fil conducteur des commentaires les plus lucides.
Omer K., dont le commentaire est le plus liké, le résume : « si l'IA rend la construction facile, le différenciateur devient le jugement et le goût produit, pas le code. La vraie valeur, c'est choisir les bons problèmes, savoir quoi ne PAS construire, et définir le succès. »
Syed T. en tire la conséquence organisationnelle : quand Claude Code peut échafauder et itérer à partir d'un prompt bien cadré, « la compétence de valeur passe de "sais-tu le construire ?" à "sais-tu définir le problème assez précisément pour que la bonne chose soit construite ?". » Et il ajoute l'essentiel : « Les organisations qui développent ce muscle de la pensée précise à travers tous les rôles, pas seulement chez les ingénieurs seniors, auront un avantage cumulatif. »
Andrei van Noordt pointe le paradoxe côté recrutement : « la ligne qui disparaît est facile à célébrer et brutale à recruter. Quand produit et ingénierie s'effondrent dans un seul siège, tu ne cherches plus un excellent PM ou un excellent ingénieur, mais la personne, plus rare, qui a le goût de quoi construire et sait aussi le construire. »
La formule qui synthétise le mieux, signée Kristóf Nagy : « quand livrer coûte peu, la compétence rare devient décider quoi livrer. »
Ce que la valeur devient concrètement
Trois déplacements ressortent des commentaires.
La boucle de feedback raccourcit. Pour Noman A., le vrai changement n'est pas que les PM codent, « c'est qu'on teste des idées en heures plutôt qu'en semaines. Ça change comment les entreprises apprennent, pas seulement comment elles construisent. » Kevin Schoovaerts confirme depuis le terrain : Claude Code construit 80 % du produit, et « c'est la boucle de feedback avec l'utilisateur qui devient incroyablement courte. C'est là qu'est la puissance. »
Le contexte prend le pas sur le prompt. Sunny Vara capte un glissement subtil : « on passe de "qui écrit les meilleurs prompts ?" à "qui donne à l'IA le meilleur contexte ?". » L'IA, comme les humains, décide mieux avec le bon contexte.
Le rôle d'architecte s'impose. Pour Natasha Newbold, la mutation touche la définition même de la compétence technique : « de plus en plus, les gens opéreront comme des architectes, créant les plans et les spécifications que des équipes d'agents exécutent. »
Le revers que la vidéo passe sous silence
Plusieurs commentaires pointent le prix de cette vitesse.
Paul Breuler : « plus d'ownership signifie plus de responsabilité individuelle. Comment équilibre-t-on cette augmentation d'ownership avec la responsabilité ? Quand quelque chose tourne mal, qui est responsable ? »
Ron H. formule la question de gouvernance la plus tranchante : « quand tout le monde peut construire, quelqu'un doit encore pouvoir dire non. Avant que ça parte en production, qui peut approuver, arrêter, et assumer le résultat ? »
Et Mohammadjavad Sayadi ramène au réel : l'écart entre la performance en démo et la fiabilité en production reste important, « surtout dans les domaines régulés comme la santé, où les erreurs ont un coût opérationnel réel. »
Le jugement recouvre donc deux choses : le goût de quoi construire, et le discernement de quoi ne pas laisser passer.
Ce que ça change pour un dirigeant
Si l'on prend ces commentaires au sérieux, quelques conséquences pratiques se dessinent.
- Recruter et évaluer sur le jugement, pas sur la vélocité de production. La capacité à cadrer un problème, à dire non, à définir le succès devient le critère différenciant, bien plus difficile à mesurer qu'un test technique.
- Diffuser le « muscle de la précision » à tous les rôles, pas seulement aux seniors (Syed T.). C'est un enjeu de formation et de culture, pas d'outillage.
- Recréer des points de décision explicites. Si tout le monde peut livrer, il faut réintroduire délibérément le « qui dit non » (Ron H.) : revue, sécurité, conformité, pensées comme du jugement institutionnalisé plutôt que comme des goulots.
- Ne pas confondre démo et production. La vitesse d'itération est réelle ; la fiabilité en environnement contraint reste à prouver (Sayadi).
En une phrase
La vidéo dit : les rôles fusionnent. Le fil répond, plus justement : livrer devient bon marché, donc la valeur migre vers le jugement, le goût de quoi construire et le discernement de quoi arrêter. La question pour les organisations n'est plus « qui sait coder ? », mais « qui sait décider ? », et comment on recrute, forme et responsabilise pour cela.
Sources
Vidéo « Reflecting on a year of Claude Code » (Anthropic / Claude for Business, Boris Cherny et Cat Wu) et ses commentaires publics sur LinkedIn.
Articles similaires
Product Engineer : le nouveau rôle qui fusionne toutes les spécialités
La fin du développement en silos : un changement de paradigme Pendant des décennies, la production logicielle a reposé sur une logique de spécialisation poussée à l'extrême. D'un côté, les développeurs front-end. De l'autre, les développeurs back-end. Entre les deux, des designe...
Sandwich Team et Product Engineer : la nouvelle équipe 10x
La Pizza Team est morte. La Sandwich Team — 1 App Owner augmenté + contributeurs occasionnels — est le modèle d'équipe du développement 10x.
Claude Code : l'agent de développement qui change la donne
De l'assistant au agent : une rupture qui redéfinit le développement logiciel Pendant des années, l'IA dans le développement logiciel a joué un rôle bien délimité : celui du copilote. Un outil intelligent, certes, capable de compléter une ligne de code, de suggérer une fonction...
Loop Engineering pour les Product Managers : la compétence de demain n'est pas le prompt
La prochaine compétence des Product Managers n'est pas le prompt engineering mais la conception de boucles : signal produit hebdomadaire, evals comme tests unitaires, et un dépôt versionné comme mémoire du produit.