7 jugements importants du fondateur de Claude Code lors de la conférence Sequoia
TechFlow SélectionTechFlow Sélection
7 jugements importants du fondateur de Claude Code lors de la conférence Sequoia
Les startups véritablement révolutionnaires pour les secteurs d’activité au cours des 10 prochaines années pourraient être 10 fois plus nombreuses que durant les 10 dernières années.
Dédié à des analyses Web3 approfondiesRédaction : A Ying
L’intervention de Boris Cherny, fondateur de Claude Code, lors de la conférence Sequoia était extrêmement riche en informations ; beaucoup d’idées m’ont été présentées pour la première fois dans leur intégralité. Ce type possède effectivement une compréhension particulièrement fine de l’IA.
Voici ma synthèse personnelle.
01 Le code n’est plus rare
Dans de nombreux scénarios de développement courants, écrire du code manuellement commence à devenir une activité inefficace.
Autrefois, pour livrer une fonctionnalité, un ingénieur s’asseyait, réfléchissait soigneusement à sa mise en œuvre, puis tapait ligne par ligne le code correspondant. Dans ce processus, la principale valeur ajoutée de l’ingénieur résidait dans sa capacité à écrire du code — ou non —, à bien l’écrire, et à le produire rapidement.
Aujourd’hui, la manière de travailler a changé.
Pour une même fonctionnalité, l’ingénieur agit davantage comme suit : il clarifie d’abord les besoins, décompose la tâche en plusieurs sous-tâches qu’il confie à des agents, définit des critères d’acceptation, puis vérifie si les résultats produits par les agents sont corrects ; sinon, il ajuste les instructions (prompts) et relance les agents.
L’IA est désormais capable de gérer la majorité des tâches de programmation. Bien entendu, ce n’est pas encore le cas à 100 % : pour les très grands et complexes dépôts de code, les langages peu répandus ou les environnements spécialisés, les modèles actuels restent insuffisants.
Globalement, la valeur ajoutée de l’ingénieur ne réside plus dans sa capacité à écrire du code, mais dans sa capacité à décomposer les tâches, à formuler clairement les objectifs, à valider les résultats obtenus et à piloter les agents.
Ce changement rappelle fortement la Révolution industrielle.
Avant celle-ci, un forgeron réalisait seul l’intégralité du processus : forgeage, façonnage, polissage et assemblage. Un forgeron particulièrement habile avait donc naturellement une grande valeur marchande.
Puis sont apparues les chaînes de montage. Chaque ouvrier ne s’occupait alors que d’une seule étape, tandis que la production globale augmentait de plusieurs dizaines, voire centaines de fois par rapport à l’ère artisanale.
À cette époque, la figure la plus précieuse au sein de l’usine n’était plus l’artisan le plus qualifié pour une étape donnée, mais celui capable de concevoir, de piloter et d’optimiser efficacement toute la chaîne de montage.
Les ouvriers n’ont pas disparu, mais leur rôle a profondément évolué.
L’ingénierie logicielle traverse aujourd’hui une inflexion similaire. Le code lui-même n’est plus une ressource rare. La capacité à écrire du code devient une compétence fondamentale, aussi banale que celle de créer une présentation PowerPoint.
Ce qui devient véritablement rare, c’est la capacité à décomposer une demande floue en tâches claires, à sélectionner la meilleure solution parmi plusieurs propositions d’un agent, ou encore à coordonner un ensemble d’IA afin qu’elles accomplissent collectivement une tâche donnée.
Beaucoup d’ingénieurs expérimentés ont du mal à accepter ce changement au départ. Écrire personnellement chaque ligne de code constituait, pendant des décennies, une des raisons fondamentales de leur passion pour ce métier.
Confier cette tâche aux machines ne signifie pas seulement un changement de méthode de travail, mais aussi une refonte profonde de leur identité professionnelle.
Mais une tendance reste une tendance.
02 Une révolution à l’image de l’imprimerie de Gutenberg
La programmation évolue d’une compétence spécialisée vers une compétence fondamentale — une évolution comparable à l’invention de l’imprimerie en Europe au XVe siècle.
Avant l’imprimerie, seuls environ 10 % des Européens savaient lire et écrire. Ces personnes étaient généralement employées par des nobles illettrés pour leur lire ou rédiger des textes à leur place.
Puis l’imprimerie a fait son apparition. En cinquante ans, le nombre de livres publiés en Europe a dépassé la somme totale des ouvrages imprimés au cours du millénaire précédent, tandis que le prix des livres chutait d’environ un facteur cent.
Il faudra ensuite plusieurs siècles de développement progressif (systèmes éducatifs, structures économiques adaptées, etc.) pour que le taux d’alphabétisation mondial atteigne aujourd’hui environ 70 %.
Selon Boris, l’impact de l’IA sur le logiciel constitue une version accélérée de cette révolution de l’imprimerie. En quelques décennies, le logiciel sera entièrement démocratisé, devenant un outil accessible à tous.
À terme, créer un logiciel sera aussi naturel que rédiger un SMS.
03 Quelles compétences sont vraiment essentielles ?
Lorsque le seuil d’accès à la programmation est abaissé au maximum par l’IA, ce qui distingue réellement les individus, ce sont leur sens produit et leur compréhension approfondie d’un domaine spécifique.
Prenons un exemple. Deux personnes doivent développer un produit destiné aux médecins : l’une est un ingénieur très rapide dans l’écriture de code, l’autre a travaillé plusieurs années au sein d’un service informatique hospitalier.
Autrefois, l’ingénieur avait plus de chances de réussir, car il pouvait concrétiser l’idée initiale.
Aujourd’hui, la situation s’inverse. Tout le monde peut désormais concrétiser une idée. À ce stade, la personne qui connaît réellement les flux de travail quotidiens à l’hôpital devient plus précieuse : elle sait quels fonctionnalités seront effectivement utilisées par les médecins, et lesquelles ne sont que séduisantes en apparence.
Autrement dit, une fois que l’IA a nivelé le terrain en matière d’exécution, les écarts de jugement sont exacerbés.
Cela redéfinit directement la signification du mot « généraliste ».
Autrefois, on désignait par « généraliste » un ingénieur capable de développer à la fois pour iOS, le web et le backend. Ce type de généraliste restait fondamentalement un « full-stack » limité au domaine de l’ingénierie.
À l’avenir, le généraliste sera un « full-stack interdisciplinaire ».
Certains maîtriseront à la fois le produit, le design et l’ingénierie ; d’autres combineront produit, science des données et ingénierie. De telles combinaisons étaient presque impossibles auparavant, car chacune nécessitait des années de formation spécialisée.
Or l’IA abaisse aujourd’hui le seuil d’exécution de chacune de ces disciplines, permettant à une seule personne de couvrir plusieurs domaines tout en conservant une solide expertise technique.
C’est précisément ainsi que fonctionne l’équipe de Claude Code : chef de projet technique, chef de produit (PM), designer, data scientist, expert financier et chargé d’études utilisateurs — chacun écrit du code.
Le designer peut désormais exécuter lui-même un prototype interactif pour le présenter à l’équipe, sans se limiter à fournir des maquettes en attente de leur implémentation par les ingénieurs.
L’expert financier peut construire lui-même un outil d’analyse permettant d’exécuter les modèles financiers complexes de l’entreprise, sans avoir à attendre son tour auprès de l’équipe BI.
Le chargé d’études utilisateurs commence à exploiter lui-même les données, prenant en charge les tâches qui, auparavant, nécessitaient systématiquement la collaboration de l’équipe dédiée aux données.
Chacun conserve son expertise pointue dans son domaine respectif. Mais, grâce à l’assistance de l’IA, l’écriture de code devient un langage commun partagé par tous.
04 La « moat » des entreprises SaaS s’effrite
Au cours des dernières décennies, le secteur SaaS s’est bâti sur plusieurs principes quasi-axiomatiques.
Le premier est le coût de basculement. Une fois qu’une entreprise adopte votre système, y sont progressivement accumulés des années, voire des décennies, de données, de configurations, de champs personnalisés et de relations de permissions.
Migrer vers un autre système implique déjà, rien que pour transférer fidèlement ces éléments d’un côté à l’autre, une telle complexité qu’elle dissuade souvent toute tentative de changement.
Le second principe est le verrouillage des flux de travail. Les opérations quotidiennes des employés, les collaborations interdépartementales et les étapes d’approbation sont toutes structurées autour de ce SaaS spécifique.
Changer de système ne revient pas seulement à migrer des données, mais à reconstruire entièrement les « mémoires musculaires » accumulées par l’entreprise au fil des années.
Ces deux facteurs combinés constituaient jusqu’à présent la « moat » la plus profonde du secteur SaaS. Or, avec des modèles suffisamment puissants, cette logique commence à changer.
Examinons d’abord le coût de basculement. Autrefois, aligner les champs et recréer la structure des données lors d’une migration d’un SaaS à un autre pouvait occuper une équipe d’ingénieurs pendant plusieurs mois.
Aujourd’hui, il suffit de soumettre les interfaces et les structures de données des deux systèmes à un modèle, qui en déduira automatiquement les relations de correspondance, progressant itérativement vers la solution optimale. Ce qui prenait des mois peut désormais aboutir à une version fonctionnelle en quelques jours seulement.
Quant au verrouillage des flux de travail, la situation est encore plus intéressante. Ce verrouillage reposait jusqu’ici sur la complexité, l’aspect implicite et la forte dépendance humaine de ces processus.
Les savoir-faire tacites des employés — savoir qui doit approuver quoi, à quel moment une procédure bloque — ne pouvaient pas être transférés directement.
Or des modèles comme Opus 4.7 excellent précisément dans la compréhension, la décomposition et la reconstruction d’un processus complexe dans un nouvel environnement — voire dans une version améliorée par rapport à l’originale.
Ainsi, la « moat » traditionnellement fondée sur l’accumulation de données et de processus s’effrite progressivement.
Pour les entreprises SaaS existantes, cela pourrait constituer une mauvaise nouvelle. Mais pour leurs clients et pour les équipes préparant la prochaine génération de solutions SaaS, c’est une opportunité véritable et inédite.
05 L’ère dorée des entrepreneurs
Au cours des dix prochaines années, le nombre de startups capables de bouleverser radicalement leur industrie pourrait être dix fois supérieur à celui des dix dernières années.
La raison en est assez simple.
De petites équipes peuvent désormais utiliser l’IA pour développer des produits équivalents, voire supérieurs, à ceux des grandes entreprises. Inversement, pour les grandes entreprises, l’adoption réelle de l’IA devient un « passif ».
Comment cela ?
Une entreprise ayant plusieurs décennies d’existence a développé une organisation complète : processus métiers, répartition des rôles, habitudes de collaboration, systèmes de formation et indicateurs de performance (KPI). Ces éléments constituaient hier des atouts, voire des barrières à l’entrée.
Mais intégrer véritablement l’IA implique de remettre tout cela en question : restructurer les processus métiers, requalifier l’ensemble des employés, faire face à d’importantes résistances internes à chaque étape, et coordonner des dizaines de départements et niveaux hiérarchiques pour chaque décision.
En revanche, une startup de trois personnes intègre l’IA dès le premier jour comme socle par défaut. Elle n’a aucun bagage historique à déconstruire, aucune habitude à modifier, personne à convaincre. Une discussion claire aujourd’hui permet de produire un prototype demain, et de le mettre en production pour les utilisateurs dès le jour suivant.
Cette différence de vitesse existait déjà avant l’IA : les startups bénéficient naturellement d’un avantage de rapidité sur les grandes entreprises. Mais l’IA amplifie cet écart de façon considérable.
Pourquoi ?
Parce que plus l’IA est puissante, plus un individu peut mobiliser de leviers en un temps donné. Une petite équipe exploitant pleinement l’IA peut aujourd’hui produire autant que dix personnes auparavant, et demain autant que trente.
Or le « poids organisationnel » des grandes entreprises n’a pas diminué — bien au contraire, il augmente, car leur capacité à absorber l’IA ajoute une couche supplémentaire de complexité. Plus l’IA progresse, plus l’écart entre l’accélération des petites équipes et la résistance des grandes entreprises s’élargit.
C’est ce que Boris désigne comme un « passif ». Il ne s’agit pas d’un manque de moyens financiers, humains ou de volonté, mais du fait que les « muscles » qui leur ont permis de réussir par le passé bloquent aujourd’hui précisément la voie à la pleine réalisation de la valeur de l’IA.
06 Le protocole MCP ne disparaîtra pas
Le protocole MCP ne disparaîtra pas.
Depuis l’essor des « skills », beaucoup pensent que le MCP n’est plus nécessaire. Le fondateur d’OpenClaw partage également ce point de vue.
Boris ne partage pas cette analyse. Selon lui, le MCP deviendra la couche de connectivité logicielle de l’ère de l’IA.
Historiquement, la connectivité logicielle sur Internet reposait sur les API.
Or le problème fondamental des API est qu’elles sont conçues pour les ingénieurs. Pour les utiliser, il faut consulter la documentation, demander un jeton (token), écrire du code, aligner les champs et gérer les exceptions. En clair, les API sont destinées aux développeurs humains.
Le MCP est différent : il permet aux modèles d’y accéder directement, sans intermédiaire humain. Le modèle comprend lui-même l’interface et peut l’appeler sans traduction préalable par un programmeur.
C’est pourquoi Boris qualifie les API d’« Interface pour développeurs humains » (Human Developer Interface), et le MCP de « Protocole d’interface pour modèles » (Model Interface Protocol) — l’un est destiné aux humains, l’autre aux modèles.
Cela rappelle fortement l’ère du mobile : à l’époque, il était acquis que tout service devait proposer une API. Aujourd’hui, dans l’ère de l’IA, il devient tout aussi naturel que tout service propose un protocole MCP.
07 L’usage de l’ordinateur reste essentiel
Beaucoup considèrent aujourd’hui le « Computer Use » comme une piste peu prometteuse.
Leur argument est légitime : cela consomme trop de tokens, c’est lent et instable. Cela ressemble davantage à une démonstration spectaculaire qu’à une solution prête à l’emploi.
Mais Boris perçoit cette problématique sous un angle totalement différent.
Ce qu’il valorise véritablement, c’est que le « Computer Use » résout le principal obstacle à la mise en œuvre concrète de l’IA : dans le monde réel, une multitude de systèmes ne disposent ni d’API, ni de protocole MCP.
C’est particulièrement vrai dans le monde de l’entreprise.
Qui a déjà travaillé au sein d’une entreprise sait que bon nombre de ses systèmes centraux sont extrêmement anciens : ERP, systèmes de gestion administrative (OA), systèmes financiers, plateformes internes d’approbation, backends logistiques, ou encore applications sur mesure. Beaucoup n’offrent aucune interface ouverte, aucune documentation, aucune capacité d’automatisation. Ils sont là, silencieux, manipulés quotidiennement par des milliers d’employés à la main.
Alors pourquoi ne pas simplement leur ajouter une API ?
Parce que c’est impossible. Les éditeurs qui les ont développés ont souvent disparu. Les services informatiques manquent de motivation et de budget pour les refondre.
Les départements métiers, quant à eux, ne peuvent pas suspendre leurs activités pendant six mois ou un an. Ces systèmes n’attendront jamais une API parfaite pour se sauver.
À court terme, les principaux modèles devraient continuer à renforcer leurs capacités en « Computer Use ».
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
