Claude Code le 7 jugements importants du fondateur lors de la conférence Sequoia

Organisation : Aying

La partage de Boris Cherny, fondateur de Claude Code, lors de la conférence Sequoia, était extrêmement riche en informations, beaucoup de points de vue que je n'avais jamais entendus dans leur intégralité auparavant. Ce gars a vraiment une compréhension assez précise de l'IA.

Je vais partager mon propre résumé.

01 Le code n’est plus rare

Pour de nombreux scénarios de développement grand public, écrire du code à la main commence à devenir une activité peu efficace.

Autrefois, pour livrer une fonctionnalité, l’ingénieur s’asseyait, réfléchissait à la façon de la réaliser, puis tapait le code ligne par ligne. Dans ce processus, la plus grande valeur de l’ingénieur était : savoir écrire, la qualité de son écriture, sa rapidité.

La façon de travailler a changé maintenant.

Pour une même fonctionnalité, le travail de l’ingénieur ressemble davantage à : d’abord clarifier les besoins, décomposer la tâche en plusieurs parties confiées à un Agent, définir une norme d’acceptation, puis vérifier si le résultat généré par l’Agent est correct, sinon ajuster l’invite et faire rerun.

L’IA peut déjà gérer la majorité des tâches de codage. Bien sûr, ce n’est pas encore parfait à 100 %, il existe encore de nombreux grands et complexes dépôts de code, des langages peu courants ou des environnements spéciaux, où les modèles actuels ne sont pas encore suffisants.

Globalement, la valeur de l’ingénieur ne réside plus dans sa capacité à écrire du code, mais dans sa capacité à décomposer des tâches, à formuler clairement des objectifs, à valider les résultats, à gérer l’Agent.

Ce changement est en fait très semblable à la révolution industrielle.

Avant la révolution industrielle, un forgeron faisait tout lui-même : ferrer, forger, polir, assembler. Son savoir-faire faisait sa valeur.

Puis sont apparues les chaînes de montage. Chaque ouvrier ne faisait qu’une étape, mais la production globale a explosé, multipliée par dizaines ou centaines.

À cette époque, le rôle précieux dans l’usine n’était plus le maître d’atelier qui maîtrisait la meilleure technique pour une étape, mais celui qui pouvait concevoir, gérer et faire fonctionner la chaîne.

Les ouvriers n’ont pas disparu, mais leur rôle a changé.

Le génie logiciel vit une transition similaire. Le code lui-même n’est plus une ressource rare. Savoir coder devient une compétence de base, comme savoir faire une présentation PowerPoint.

Ce qui est vraiment rare, c’est la capacité à décomposer des besoins flous en tâches claires, à choisir la meilleure solution parmi plusieurs proposées par l’Agent, à faire collaborer plusieurs IA pour réaliser une tâche.

Beaucoup de vieux ingénieurs ont du mal à accepter cela au début. Écrire du code à la main était la raison pour laquelle beaucoup ont aimé leur métier ces dernières décennies.

Confier cela à une machine, ce n’est pas seulement changer la façon de travailler, c’est une redéfinition de l’identité professionnelle.

Mais la tendance est là.

02 Comme la presse de Gutenberg

Le codage devient une compétence de base, pas seulement une compétence spécialisée. C’est comparable à l’invention de l’imprimerie en Europe au XVe siècle.

Avant l’invention de l’imprimerie, seulement environ 10 % des Européens savaient lire. Ces personnes étaient souvent employées par des nobles analphabètes, pour lire et écrire à leur place.

Puis l’imprimerie est née. En 50 ans, le nombre de livres publiés en Europe a dépassé celui de toute la période précédente d’un millénaire, et le prix des livres a chuté d’environ 100 fois. Avec plusieurs siècles d’adaptation (système éducatif, économie), le taux d’alphabétisation mondial a atteint aujourd’hui 70 %.

Boris pense que l’impact de l’IA sur le logiciel est une révolution accélérée de l’imprimerie. Le logiciel sera démocratisé en quelques décennies, accessible à tous.

Finalement, faire du logiciel deviendra aussi naturel que d’envoyer un SMS.

03 Quelles compétences sont les plus importantes ?

Lorsque la barrière pour écrire du code est abaissée au maximum par l’IA, la véritable différenciation d’un individu réside dans son sens du produit, sa compréhension profonde d’un domaine spécifique.

Par exemple, deux personnes doivent créer un produit destiné aux médecins. Un ingénieur qui code rapidement, et une personne ayant travaillé plusieurs années dans un service d’information hospitalière.

Avant, c’était l’ingénieur qui avait plus de chances de réussir, car il pouvait réaliser l’idée.

Mais maintenant, tout le monde peut réaliser une idée. La personne qui connaît vraiment le fonctionnement quotidien d’un hôpital a une valeur accrue, car elle sait quelles fonctionnalités seront réellement utilisées par les médecins, et lesquelles ne sont que des idées séduisantes.

Autrement dit, une fois que l’IA a nivelé la barrière à l’exécution, la différence de jugement devient plus marquée.

Cela modifie directement la signification du mot « généraliste ».

Autrefois, un généraliste était un ingénieur capable de faire du iOS, du Web, et du backend. En réalité, c’était un ingénieur full-stack interne.

Le futur « généraliste » sera un professionnel pluridisciplinaire.

Certains maîtrisent à la fois le produit, le design et l’ingénierie. D’autres combinent produit, science des données et ingénierie. Ces combinaisons étaient presque impossibles auparavant, car chaque domaine nécessitait une formation longue.

Mais maintenant, l’IA abaisse la barrière pour chaque domaine, permettant à une personne de couvrir plusieurs champs tout en conservant une expertise approfondie.

L’équipe Claude Code fonctionne ainsi. Managers, PM, designers, data scientists, financiers, chercheurs utilisateurs, tout le monde code.

Les designers peuvent créer eux-mêmes des prototypes interactifs pour l’équipe, sans attendre que les ingénieurs réalisent les maquettes.

Les financiers peuvent développer leurs propres outils d’analyse, pour modéliser la complexité financière de l’entreprise, sans attendre le service BI. Les chercheurs en user research analysent eux-mêmes les données, sans dépendre de l’équipe data.

Chacun conserve sa spécialité. Mais grâce à l’IA, coder devient une langue commune à tous.

04 La brèche de la SaaS s’effrite

Depuis une dizaine d’années, plusieurs idées dans le secteur SaaS étaient considérées comme des vérités absolues.

La première : le coût de changement. Lorsqu’une entreprise adopte votre système, elle accumule des années, voire des dizaines d’années, de données, configurations, champs, relations d’accès.

Migrer vers un autre système, c’est d’abord transférer ces éléments tels quels, ce qui est une tâche ardue et dissuasive.

La deuxième : le verrouillage par workflow. Les opérations quotidiennes, la collaboration inter-départements, les processus d’approbation, tout tourne autour de ce SaaS.

Changer de système, ce n’est pas seulement transférer des données, c’est tout réapprendre, tout reconstruire.

Ces deux idées formaient la principale barrière protectrice du secteur SaaS. Mais avec des modèles puissants, la logique commence à changer.

Concernant le coût de changement : auparavant, il fallait plusieurs mois pour faire correspondre manuellement les champs et structures de deux SaaS. Maintenant, on peut simplement fournir les API et les structures à un modèle, qui s’occupe de faire la correspondance lui-même, en cherchant la meilleure solution. Ce qui prenait des mois peut se faire en quelques jours.

Concernant le verrouillage par workflow, c’est encore plus intéressant. La raison pour laquelle ces processus verrouillaient les clients, c’était leur complexité, leur nature implicite, leur dépendance humaine.

Les employés ont en tête des processus tacites, des approbations, des étapes à ne pas manquer. Impossible de tout transférer tel quel.

Mais des modèles comme Opus 4.7 sont capables de comprendre, décomposer, et reconstruire ces processus dans un nouvel environnement. Parfois, la nouvelle version est même meilleure que l’originale.

Ainsi, la barrière construite par la donnée et les processus est en train de s’effondrer.

Pour ceux qui font du SaaS, c’est peut-être une mauvaise nouvelle. Mais pour les clients, et pour les équipes qui veulent créer la prochaine génération de SaaS, c’est une opportunité réelle.

05 La meilleure époque pour les entrepreneurs

Dans 10 ans, les startups qui bouleverseront leur secteur seront probablement 10 fois plus nombreuses qu’aujourd’hui.

Ce n’est pas compliqué à comprendre.

Une petite équipe peut créer des produits aussi performants, voire plus, que ceux des grandes entreprises grâce à l’IA. À l’inverse, pour les grandes entreprises, exploiter pleinement l’IA devient une charge supplémentaire.

Comment ça ?

Une entreprise vieille de dix ans a déjà ses processus, ses rôles, ses habitudes, ses formations, ses KPI. Tout cela constitue un actif, une barrière.

Mais intégrer l’IA dans tout cela implique de tout repenser : restructurer les processus, former à nouveau tous les employés, faire face à une résistance interne énorme, coordonner plusieurs départements et niveaux d’approbation.

Une startup de trois personnes, dès le départ, considère l’IA comme une base par défaut. Elle n’a pas de bagages historiques à défaire, pas d’habitudes à changer, pas besoin de convaincre qui que ce soit. En un jour, elle peut faire un prototype, et en deux, le déployer pour les utilisateurs.

Ce décalage de vitesse, l’IA l’a toujours permis. Les startups ont toujours eu un avantage de rapidité sur les grands groupes. Mais l’IA amplifie cette différence.

Pourquoi ?

Parce que plus l’IA est puissante, plus le levier qu’un individu peut actionner en une unité de temps est grand. Une petite équipe qui maîtrise bien l’IA peut produire aujourd’hui l’équivalent de dix personnes d’hier, et demain, celui de trente.

Mais la lourdeur organisationnelle des grands groupes ne diminue pas, elle s’alourdit même, car ils doivent digérer l’IA. La puissance de l’IA augmente, la vitesse des petites équipes s’accroît, tandis que la résistance des grands s’accroît aussi, creusant un écart de plus en plus grand.

C’est ce que Boris appelle la « dette négative ». Ce n’est pas un manque d’argent, de personnel ou de volonté dans les grandes entreprises, c’est que leurs muscles qui leur ont permis de gagner de l’argent jusqu’ici, deviennent un obstacle à la véritable valeur de l’IA.

06 MCP ne mourra pas

Le MCP ne mourra pas.

Après la montée en puissance des compétences, beaucoup pensent que le MCP n’est plus nécessaire. Le fondateur d’OpenClaw partageait une idée similaire.

Mais Boris n’est pas d’accord. Il pense que le MCP deviendra la couche de connexion des logiciels à l’ère de l’IA.

Autrefois, la connexion des logiciels sur Internet se faisait via des API.

Mais le problème principal des API, c’est qu’elles sont conçues pour les développeurs. Pour utiliser une API, il faut lire la documentation, demander un token, écrire du code, faire correspondre les champs, gérer les erreurs. En clair, une API est faite pour les développeurs humains.

Le MCP, lui, est différent. Il permet à un modèle d’être directement connecté, de comprendre et d’interagir sans qu’un programmeur ait besoin de faire la traduction.

Boris appelle cela l’Interface Humaine de Développement (Human Developer Interface), et le MCP, le Protocole d’Interface Modèle (Model Interface Protocol). L’un pour l’humain, l’autre pour le modèle.

C’est très similaire à ce qui s’est passé à l’époque de l’Internet mobile. Tous les services devaient être API-ifiés. À l’ère de l’IA, tous les services devront être MCP-ifiés.

07 L’utilisation de l’ordinateur reste essentielle

Beaucoup pensent que l’utilisation de l’ordinateur n’a plus d’avenir.

Les raisons sont valides : cela consomme trop de tokens, c’est lent, ce n’est pas stable. Cela ressemble à un simple démonstration technique, encore loin d’une utilisation pratique.

Mais Boris voit une autre dimension.

Ce qu’il valorise, c’est que l’utilisation de l’ordinateur résout un problème majeur de l’IA : dans le monde réel, beaucoup de systèmes n’ont ni API ni MCP.

Surtout dans le monde de l’entreprise.

On sait tous que beaucoup de systèmes centraux sont très anciens. ERP, OA, systèmes financiers, approbations internes, gestion de la chaîne d’approvisionnement, systèmes sur-mesure. Beaucoup n’ont pas d’interface ouverte, pas de documentation, pas d’automatisation. Ils sont là, chaque jour manipulés manuellement par des employés.

Pourquoi ne pas simplement leur faire une API ?

Parce que c’est impossible. Les fournisseurs de ces systèmes ont souvent disparu. Les départements IT n’ont ni la motivation ni le budget pour tout reconstruire.

Les départements métier ne peuvent pas attendre six mois ou un an. Ces systèmes ne se réinitialiseront jamais pour attendre une API parfaite.

Dans l’immédiat, les grands modèles continueront à améliorer leur capacité à utiliser ces systèmes.