Qui possède l'établi

Une phrase trouvée sur Hacker News me reste en tête depuis hier soir, depuis que j’ai lu la nouvelle de l’acquisition d’Astral par OpenAI. La phrase dit : « OpenAI and Anthropic are making plays to own the means of production in software. » Les moyens de production. C’est de ces formules qui paraissent un peu excessives à la première lecture, et puis tu y repenses, tu y reviens, et à la fin tu réalises qu’elles ne le sont peut-être pas assez.

Astral est la startup derrière uv, Ruff et ty, trois outils qui en quelques années sont devenus l’infrastructure quotidienne de millions de développeurs Python. uv a résolu le problème de la gestion d’environnements et de dépendances avec une élégance et une vitesse que pip n’a jamais eues. Ruff a rendu le linting et le formatting si rapides qu’ils en deviennent invisibles, et ty fait la même chose pour le type checking. Des outils écrits en Rust, tous open source, tous sous licence permissive. Et depuis hier, tous propriété d’OpenAI, qui les intégrera à l’équipe Codex, son agent de coding qui a déjà dépassé les deux millions d’utilisateurs actifs hebdomadaires.

Il y a trois mois, en décembre, Anthropic avait fait un coup similaire en rachetant Bun, le runtime JavaScript créé par Jarred Sumner. Claude Code, leur outil de coding agentique qui a atteint un milliard de dollars de revenu annualisé en six mois, tourne comme exécutable Bun. Sumner l’a dit avec une clarté presque brutale dans son post d’annonce : « If Bun breaks, Claude Code breaks. » Anthropic a donc racheté l’infrastructure sur laquelle repose son produit à un milliard.

Deux acquisitions en trois mois, par les deux entreprises qui se disputent le marché des outils de coding assisté par IA. Prises isolément, chacune a sa logique. Prises ensemble, le pattern est inéquivoque.

Et le pattern est le suivant : les entreprises qui construisent des modèles de langage rachètent, pièce par pièce, la toolchain sur laquelle ces modèles opèrent. Pas le cloud, pas les puces, pas les datacenters. Les outils qui se trouvent entre le modèle et le code. Le package manager. Le linter. Le runtime. Le type checker. Tout ce dont un agent IA a besoin pour ne pas se contenter de générer du code, mais pour l’exécuter, le tester, le valider, et le remettre en production.

Ce n’est pas de la philanthropie envers l’open source. C’est de la stratégie infrastructurelle.

Quatre-vingt-quinze pour cent de contexte

Pour comprendre ce qui se passe, il faut partir d’un fait souvent sous-estimé : les modèles de langage, à eux seuls, génèrent du code. Mais générer du code, ce n’est pas faire du logiciel. Le sait quiconque a essayé de faire écrire un projet entier à un agent et s’est retrouvé avec quelque chose qui compile mais ne fonctionne pas, ou qui fonctionne mais ne respecte pas les conventions du repo, ou qui les respecte mais casse trois tests imprévus. La génération est cinq pour cent du travail. Les quatre-vingt-quinze restants sont du contexte : résoudre les dépendances, faire passer le linter, gérer les types, exécuter les tests, intégrer dans la CI/CD, maintenir le code dans le temps quand les libs s’updatent et les exigences changent.

Et c’est là le point. Un agent IA qui veut faire ces 95 % a besoin de posséder, ou au moins de contrôler, les outils qui les composent. Pas suffisant de savoir que uv existe. Il faut que uv réponde aux besoins de l’agent, qu’il soit optimisé pour ses workflows, qu’il évolue dans la direction qui rend l’agent plus efficace. Idem pour Ruff, ty, Bun. Quand OpenAI écrit dans son annonce que l’objectif est « move beyond AI that simply generates code and toward systems that can participate in the entire development workflow », ce n’est pas du marketing. C’est exactement pourquoi il a racheté Astral.

Je le vois tous les jours dans mon travail. J’utilise Claude Code sur des projets Laravel, je gère des pipelines CI/CD avec GitHub Actions, et la différence entre un agent qui génère un fichier et un agent qui comprend le contexte dans lequel ce fichier doit vivre, c’est la différence entre un outil utile et un jouet. Quand l’agent connaît les règles de mon linter, sait comment sont structurées mes dépendances, comprend mon flux de déploiement, alors il devient vraiment un collaborateur. Et pour être ce type de collaborateur, il doit parler la langue des outils que j’utilise. Si celui qui construit l’agent possède aussi ces outils, l’avantage concurrentiel est énorme.

Un lock-in d’un nouveau genre

Mais c’est précisément là que ça devient intéressant, et un peu inquiétant. Parce que ce qui émerge est un nouveau type de vendor lock-in, différent de tout ce qu’on a vu avant.

L’ancien lock-in était explicite : tu choisissais un cloud, tu choisissais une base de données propriétaire, et un jour migrer coûtait trop cher. Tu le savais, tu faisais tes comptes, tu décidais. Le nouveau lock-in est différent. Il est implicite. Tu ne te rends pas compte qu’il advient parce que chaque pièce paraît open source, libre, neutre. uv est encore sous MIT. Bun est encore sous MIT. Tu peux forker, tu peux les utiliser sans Codex ni Claude Code, tu peux faire ce que tu veux. Mais la question est ailleurs : dans deux ans, quand 80 % de l’évolution d’uv sera guidée par les besoins de Codex, quand les features prioritaires seront celles qui servent à l’agent d’OpenAI et pas à toi qui utilises uv en terminal, le fork sera-t-il vraiment une option praticable ? Simon Willison, l’un des esprits les plus lucides de l’écosystème, a écrit hier que le pire scénario a la forme de « fork and move on ». Mais il a ajouté, honnêtement, qu’OpenAI n’a pas encore de track record dans le maintien de projets open source acquis. Et qu’une acquisition produit + talent peut se transformer, avec le temps, en acquisition de seul talent.

C’est un point sur lequel je reviens. Le code reste ouvert, mais la direction devient fermée. C’est une forme de contrôle qui ne viole aucune licence, ne trahit aucune promesse explicite, et qui pourtant concentre du pouvoir de manière significative. Quelqu’un sur Hacker News a bien décrit la dynamique : « As they gobble up previously open software stacks, how viable is it that these stacks remain open ? » La viabilité technique reste, la viabilité pratique s’érode.

Je l’écris et j’entends déjà les objections, celles que je me suis faites moi-même. « Mais les incitations sont alignées », disent beaucoup. « Anthropic a besoin que Bun marche bien pour tous, pas seulement pour Claude Code, parce que l’adoption massive crée des effets de réseau. » Et c’est vrai, du moins aujourd’hui. « La licence MIT protège la communauté », disent d’autres. C’est vrai aussi, du moins en théorie. Mais j’ai vu assez d’acquisitions dans ma carrière pour savoir que les promesses du jour de l’annonce ont une date d’expiration non écrite. Le post de Jarred Sumner a été honnête : « No one can guarantee how motives, incentives, and decisions might change years down the line. » Et j’ajouterais que les incitations d’une startup à zéro revenu et quatre ans de runway devant elle sont très différentes de celles d’une division dans une boîte qui brûle deux dollars cinquante pour chaque dollar facturé et doit justifier chaque acquisition devant des investisseurs qui attendent une IPO.

La bataille pour le workflow

Il y a aussi un autre aspect qui me frappe, et qui concerne la façon dont ces acquisitions redéfinissent la concurrence. Jusqu’à hier, la bataille entre OpenAI et Anthropic se jouait sur la qualité des modèles. Qui raisonne mieux, qui génère du code plus propre, qui a le contexte le plus long. Aujourd’hui elle se déplace sur un autre plan : qui contrôle le plus de surface du workflow du développeur. Ce n’est plus seulement « mon modèle est meilleur ». C’est « mon modèle vit dans un écosystème que je possède et qui optimise chaque étape ». La génération de code devient une commodity, et la valeur se déplace vers l’orchestration de tout le cycle. Qui possède le linter, le package manager, le runtime et l’agent de coding a un avantage structurel qu’aucun benchmark ne capture.

La question que je me pose, et qui n’a pas encore de réponse claire, est ce que tout cela signifie pour qui travaille avec des stacks autres que Python et JavaScript. Beaucoup d’équipes — pensez à d’autres écosystèmes — n’ont pas (encore) subi cette concentration. Mais le pattern est clair, et il s’étendra. Aujourd’hui c’est Python et JavaScript parce que ce sont les langages de l’IA et du web. Demain ça pourra être tout écosystème dans lequel les agents de coding ont besoin d’outils fiables pour opérer en autonomie. La course à racheter les briques de l’infrastructure de développement vient de commencer.

Une analogie un peu forcée mais qui m’aide à penser. Pendant des décennies, le pétrole a été le carburant de l’économie industrielle, et qui contrôlait les raffineries et les pipelines avait plus de pouvoir que qui extrayait le brut. Dans le logiciel, les modèles de langage sont le brut. Ils génèrent de l’output. Mais la vraie valeur est dans la raffinerie : les outils qui prennent cet output et le transforment en logiciel fonctionnel, testé, conforme, déployé. Les AI companies l’ont compris et achètent les raffineries.

Un choix politique

Et nous sommes au centre de cette transition sans l’avoir choisie. On utilise uv parce que c’est le meilleur outil disponible. On utilise Bun parce qu’il est rapide et résout des problèmes réels. Nos choix sont rationnels et individuels. Mais l’effet agrégé de millions de choix rationnels et individuels, c’est la concentration du pouvoir infrastructurel dans les mains de quelques entreprises qui n’ont pas construit ces outils, elles les ont achetés.

Je ne sais pas où mène tout cela. Peut-être que les incitations resteront alignées assez longtemps pour ne pas poser problème. Peut-être que la licence MIT se révélera une protection suffisante. Peut-être que le marché restera assez concurrentiel pour empêcher les abus. Mais peut-être pas. Peut-être qu’on construit une dépendance qu’on reconnaîtra comme telle seulement quand il sera trop tard pour en sortir avec grâce.

Ce que je sais, c’est que le choix de ton package manager, de ton runtime, de ton linter n’a jamais été un choix uniquement technique. Aujourd’hui, que tu le veuilles ou non, c’est aussi un choix politique. Et comme tous les choix politiques, il mérite d’être fait les yeux ouverts.