Mise à jour, 30 avril, 8h10 : ajout des éléments de réponse apportés par GitHub sur l’explosion des volumes de requêtes associée notamment à l’IA.

C’est la mort dans l’âme que Mitchell Hashimoto, développeur de Ghostty, a pris ses cliques et ses claques : son émulateur de terminal va déménager sur une autre plateforme. Sur GitHub, où le logiciel est développé depuis 18 ans, il ne restera plus que le code source en lecture seule. « Je suis l’utilisateur GitHub 1299, inscrit en février 2008. Depuis, j’ouvre GitHub tous les jours, chaque jour, plusieurs fois par jour, depuis plus de 18 ans », écrit-il sur son blog. Mais alors, pourquoi cette décision ?

Les pannes s’enchaînent

C’est que GitHub n’est plus fiable à ses yeux. Mitchell Hashimoto a marqué d’un « X » les jours du mois où la plateforme a eu « un impact négatif sur ma capacité de travailler ». Résultat : un « X » « presque tous les jours ». GitHub n’est plus un environnement adapté à un travail sérieux « s’il vous bloque pendant des heures chaque jour ». Il partagera un peu plus tard les détails sur le déménagement de Ghostty ; cela prendra du temps de retirer les dépendances sur GitHub. La popularité de l’utilitaire est telle que plusieurs fournisseurs se montrent intéressés. 

Kyle Daigle, le directeur des opérations de GitHub, a répondu au développeur en se disant désolé de le voir partir : « L’équipe va continuer à travailler pour faire de GitHub un service vers lequel vous aurez envie de revenir, preuves concrètes à l’appui, pas seulement des promesses ». Il ajoute qu’il continuera de soutenir Ghostty en tant qu’utilisateur.

Mitchell Hashimoto n’est pas le seul à en avoir sa claque de GitHub. En novembre dernier, Andrew Kelley annonçait le déménagement de son langage Zig créé en 2015, vers Codeberg. « Il est clair que l’excellence technique qui a fait le succès de la plateforme ne la guide plus. Les priorités et la culture d’ingénierie se sont dégradées, laissant les utilisateurs aux prises avec une sorte de framework JavaScript lourd et truffé de bugs, au nom du progrès », regrette-t-il, avant d’asséner que « ce qui était autrefois rapide est désormais lent, et souvent complètement cassé ».

Andrew Kelley fait remonter les problèmes de GitHub à son acquisition par Microsoft en 2018, pour 7,5 milliards de dollars. À l’époque, la plateforme prédisait « un futur brillant ». Un des problèmes soulevés par les deux développeurs concerne le système d’automatisation GitHub Actions, qui déclenche automatiquement des tâches dès qu’un événement se produit sur un dépôt (un commit, une pull request, un déploiement…). Le jour de la publication de sa note, Mitchell Hashimoto expliquait ne pas avoir pu relire et valider les pull requests pendant deux heures à cause d’une panne de GitHub Actions. Pour Andrew Kelley, ce service a été « complètement négligé ».

Un ou deux développeurs qui quittent GitHub, ce n’est pas encore une hémorragie ou une fuite des cerveaux. Il s’agit toutefois de profils bien connus, qui sont présents et actifs sur la plateforme depuis des années et qui pourraient en inspirer d’autres à regarder ailleurs.

Aux bugs s’ajoutent les failles de sécurité. Ce lundi 28 avril, GitHub donnait des précisions sur un correctif mis en ligne deux heures après la réception du rapport de vulnérabilité sur le Bug Bounty de la plateforme. Il s’agissait d’une faille critique permettant d’exécuter du code à distance. Il n’y a eu aucune exploitation, et GitHub tient à faire savoir au monde sa rapidité de réponse. Néanmoins, cela participe aussi à une certaine défiance.

GitHub incrimine l’explosion du volume de requêtes

GitHub a indirectement répondu à ces critiques par l’intermédiaire d’un billet de blog, lui aussi daté du 28 avril, signé par Vlad Fedorov, directeur technique. Ce dernier y explique que GitHub a engagé un plan de multiplication par dix des capacités de sa plateforme, précisément pour en améliorer la fiabilité, mais l’effort se serait finalement révélé insuffisant : en février, il aurait ainsi mesuré que ces capacités auraient dû progresser d’un facteur 30, principalement à cause de l’essor des agents IA : « Le principal facteur est l’évolution rapide des méthodes de développement logiciel. Depuis la seconde moitié de décembre 2025, les flux de travail de développement automatisés se sont considérablement accélérés. »

Fedorov promet à cette occasion que les équipes sont entièrement mobilisées sur le sujet :

« Nos priorités sont claires : la disponibilité d’abord, puis la capacité, et enfin les nouvelles fonctionnalités. Nous réduisons les tâches inutiles, améliorons la mise en cache, isolons les services critiques, éliminons les points de défaillance uniques et déportons les processus critiques vers des systèmes conçus pour ces charges de travail. »

L’IA pointée du doigt

Cette remarque peut être perçue comme paradoxale du point de vue des développeurs qui observent l’insistance avec laquelle Microsoft cherche à fourrer de l’IA générative partout dans GitHub. Le développeur de Zig rappelle les propos tenus en août 2025 par Thomas Dohmke, le directeur général de la plateforme : « Soit vous adoptez l’IA, soit vous quittez votre carrière. »

• Logiciel

  Sur GitHub, la promotion de l’IA fait fuir certains utilisateurs

  Logiciel

  Lundi 08 décembre 2025 à 14h30 08/12/2025 14h30

  28

Reste à voir comment cette IA s’intègre dans GitHub. Mais pour Andrew Kelley, le compte n’y est pas : GitHub Actions a commencé à choisir les tâches à exécuter de manière « apparemment aléatoire ».

Ce trop plein d’IA et la grogne qui en découle ont manifestement atteint les oreilles des dirigeants de Microsoft. L’éditeur va prioriser la stabilité et la fiabilité de Windows 11, en réduisant la voilure sur les fonctions d’IA qui n’apportent aucun bénéfice. Et même chez Xbox, la nouvelle direction incarnée par Asha Sharma ne veut pas inonder sa plateforme de « bouillie IA ». Alors à quand la prise de conscience chez GitHub ?