GitButler lève 17 Mns $ : le cofondateur de GitHub veut construire l'infrastructure de l'ère des agents IA
GitButler lève 17 millions pour réinventer le contrôle de versions : le cofondateur de GitHub veut construire l'infrastructure de l'ère des agents IA,
la communauté open source répond par la méfiance
Un cofondateur de GitHub revient avec une nouvelle vision du contrôle de versions à l'ère de l'IA. Entre ambition légitime et scepticisme nourri, le débat autour de GitButler illustre une tension plus profonde : peut-on vraiment remplacer Git, et surtout, devrait-on le vouloir ?
Scott Chacon n'est pas un inconnu dans l'écosystème du développement logiciel. Cofondateur de GitHub, la plateforme rachetée par Microsoft pour 7,5 milliards de dollars en 2018, il est aussi l'auteur de Pro Git, la référence bibliographique de millions de développeurs. C'est lui qui, il y a trois ans, a lancé GitButler avec une prémisse simple : Git a résolu le problème de la collaboration distribuée pour une époque révolue, celle des patches envoyés par courriel. Il est temps de repenser l'infrastructure.
GitButler a annoncé avoir levé 17 millions de dollars en série A, menée par Andreessen Horowitz (a16z), avec la participation de Fly Ventures et A Capital. Peter Levine, nouveau membre du conseil d'administration, avait déjà croisé Chacon à l'époque de GitHub. Le message de l'annonce est ambitieux : « Nous ne construisons pas un "meilleur Git". Nous construisons l'infrastructure de la façon dont le logiciel sera produit demain. »
Scott Chacon et Andreessen Horowitz
Le problème posé : Git à l'ère des agents
Le cœur de l'argumentaire de Chacon repose sur un constat qui résonne dans de nombreuses équipes de développement : le modèle traditionnel supposait une seule personne, une seule branche, un seul terminal, un flux linéaire gitbutler et ce modèle est aujourd'hui mis à l'épreuve par la montée en puissance du développement assisté par agents IA. Quand des outils comme Claude Code, Cursor ou Codex génèrent et modifient du code de manière autonome, parfois en parallèle, les primitives de Git commencent à montrer leurs coutures.
GitButler vient de publier la préversion technique de son interface en ligne de commande (CLI), baptisée but. Conçu pour les workflows de type GitHub Flow (branches courtes, développement orienté trunk), l'outil se veut utilisable aussi bien par des humains que par des agents, avec des fonctionnalités de branches empilées, de multitâche, d'annulation et d'organisation des changements.
La vision à plus long terme est celle d'une collaboration véritablement sociale du code : des outils capables d'informer les développeurs des conflits potentiels avant qu'ils ne surviennent, d'intégrer les conversations et les décisions dans l'historique du dépôt, et de donner aux agents une visibilité complète sur ce que font leurs homologues (humains ou non) en temps réel.
Et Scott Chacon d'expliquer :
« Pour moi, c'est une longue histoire.
« J'ai cofondé GitHub et, ces 15 dernières années, j'ai vu Git passer d'un outil de développement assez confidentiel, conçu pour un style de collaboration très ésotérique, à l'infrastructure fondamentale de tout le développement logiciel à l'échelle mondiale. J'y ai peut-être même contribué, même modestement. Ce que j'ai appris en observant cette évolution, c'est que les plateformes de développement réussissent lorsqu'elles fluidifient la collaboration et allègent la charge de travail des développeurs.
« GitButler a vu le jour il y a trois ans, car nous avions le sentiment que nos pratiques de développement étaient depuis trop longtemps cantonnées aux possibilités de Git. Il nous semblait formidable de voir ce que nous pourrions accomplir avec des outils réellement conçus pour ces pratiques.
« C'est fondamentalement la raison d'être de cette levée de fonds.
« Nous pensons que le développement logiciel entre rapidement dans une nouvelle ère et que le problème que Git a résolu ces 20 dernières années a besoin d'être repensé. Aujourd'hui, avec Git, nous apprenons à des cohortes d'agents à utiliser un outil conçu pour envoyer des correctifs par listes de diffusion. C'est loin d'être ce dont nous avons besoin aujourd'hui.
« Chez GitHub, une chose est devenue criante : les développeurs ne rencontrent pas de difficultés parce qu'ils ne savent pas coder. Leurs difficultés proviennent d'un manque de cohérence entre les outils, entre les personnes, et maintenant entre les personnes et les agents. La véritable difficulté n'est pas de générer des changements, mais de les organiser, de les examiner et de les intégrer sans créer de chaos.
« L'ancien modèle supposait une personne, une branche, un terminal et un flux linéaire. Non seulement ce problème n'a pas été correctement résolu pour ce modèle, mais il est aujourd'hui exacerbé par nos nouveaux outils d'IA.
« La semaine dernière, nous avons publié notre première réponse à ce problème : la préversion technique de l'interface de ligne de commande GitButler. »
Une levée facile à expliquer, un produit difficile à justifier
Sur les forums spécialisés, la réaction est mitigée, pour le dire poliment. Un utilisateur résume l'ambivalence dominante : « Git n'est pas SVN, et ces problèmes sont déjà résolus. Je conviens que l'interface n'est pas toujours intuitive, mais Git dispose d'une infrastructure très axée sur le support des alternatives au flux linéaire. »
La levée elle-même, en revanche, est aisément explicable. Comme le note un commentateur : le pitch tient en trois points ; un cofondateur de GitHub, une sortie à 7,5 milliards, et l'argument que l'IA transforme déjà le développement logiciel, avec la preuve dans les revenus de Claude Code, Cursor ou Codex. Autrement dit : ce n'est pas le produit qui a convaincu a16z, c'est l'équipe et le contexte.
Cette distinction est fondamentale. Plusieurs voix font remarquer que la vraie cible de GitButler n'est pas Git, mais GitHub. Ils ne veulent pas construire le prochain Git, ils veulent construire le prochain GitHub, écrit un utilisateur, avec la logique que le premier est un bien commun indétrônable tandis que le second reste une plateforme commerciale susceptible d'être concurrencée.
Le spectre du vendor lock-in
La méfiance exprimée va bien au-delà du scepticisme technique. Plusieurs développeurs soulèvent la question du modèle économique : comment un investissement en capital-risque portant sur un outil d'infrastructure critique peut-il générer un retour suffisant sans, à terme, capturer l'utilisateur ? Leur objectif final est de vous piéger. Même si c'est gratuit et que ça fait ce que vous aimez, ne l'utilisez pas. La formulation est brutale, mais elle illustre une anxiété réelle dans la communauté open source.
Cette anxiété s'est cristallisée autour d'une pratique concrète : à l'installation, GitButler pose des hooks Git, notamment un hook pre-commit qui bloque les commits directs via git commit et redirige l'utilisateur vers but commit. GitButler installe ce hook silencieusement dans le cadre de la « configuration » d'un dépôt, sans opt-in. Le seul moyen d'y échapper sans leur CLI est de le supprimer manuellement.
Scott Chacon lui-même est intervenu dans le fil pour clarifier : le hook est une nécessité architecturale liée à la gestion des branches parallèles via un commit de fusion interne (megamerge), incompatible avec un git commit classique. Mais le mal est partiellement faite. Pour beaucoup, cette pratique évoque la formule attribuée à Microsoft : la stratégie dite « embrace, extend, extinguish » (intégrer, dériver, puis étouffer).
Jujutsu, le rival inattendu
Ironiquement, la discussion autour de GitButler a surtout profité à… Jujutsu (alias jj), un système de contrôle de versions open source développé initialement par un ingénieur de Google, Martin von Zweigbergk, et aujourd'hui soutenu par une communauté plus large ainsi qu'une startup (East River Source Control) qui ne cherche pas à monétiser l'outil lui-même.
Jujutsu est compatible avec Git (il utilise Git comme backend) et son modèle par snapshots automatiques s'avère particulièrement adapté au développement assisté par IA : vous pouvez itérer librement sans penser aux commits, et remettre de l'ordre après coup. Plusieurs développeurs décrivent l'usage combiné de jj et Claude Code, en configurant des hooks pour déclencher un snapshot à chaque modification de fichier par l'agent.
La comparaison est instructive : là où GitButler mise sur une interface propriétaire avec financement VC pour proposer une expérience polie, Jujutsu mise sur une philosophie de remplacement progressif de la porcelaine Git, sans rupture brutale et sans actionnaires à satisfaire. Le fait qu'il ne soit pas financé par du capital-risque est un point positif majeur, note un utilisateur, même si cette affirmation est nuancée par d'autres qui rappellent l'existence d'une entreprise adossée au projet.
Un problème réel, une solution contestée
Il serait injuste de réduire GitButler à un exercice de marketing. Chez GitHub, une chose est apparue clairement à maintes reprises : les développeurs ne peinent pas parce qu'ils ne savent pas écrire du code. Ils peinent parce que le contexte se fragmente entre les outils, entre les personnes, et maintenant entre les personnes et les agents. C'est un diagnostic que peu contestent.
Les pull requests de 10 000 lignes produites par les agents, la difficulté à tracer la paternité d'un changement généré par IA, la gestion des conflits entre branches parallèles travaillées simultanément par plusieurs agents : ces problèmes sont réels et s'aggravent à mesure que l'IA prend une place plus centrale dans les workflows de développement. Git n'a pas été conçu pour les agents IA... et GitHub non plus. Les deux ont été pensés pour des humains travaillant de façon séquentielle.
La question n'est donc pas tant de savoir si le problème existe, mais si GitButler (avec son modèle VC, ses hooks controversés et son positionnement ambigu entre client Git amélioré et système de versioning de nouvelle génération) est la bonne réponse. Et si une réponse financée par a16z peut, structurellement, l'être.
Git a mis vingt ans à devenir l'infrastructure invisible sur laquelle repose l'intégralité du développement logiciel mondial. Son successeur, quel qu'il soit, devra non seulement résoudre des problèmes techniques inédits, mais aussi convaincre une communauté de développeurs aussi méfiante des monopoles que dépendante des standards ouverts. GitButler a peut-être le bon fondateur. Il lui reste à trouver le bon produit et le bon modèle.
Source : annonce Gitbutler
Voir aussi :
Git a été créé par Linus Torvalds en 2005 pour gérer le développement du noyau Linux. Un outil conçu par une startup financée par a16z peut-il prétendre au même statut d'infrastructure neutre et universelle ?
Répondre avec citation
Partager