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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
