La crise GitHub d’avril 2026 : ce que révèle l’échelle 30x

La crise GitHub d’avril 2026 : ce que révèle l’échelle 30x

J'ai actualisé la liste des pull request pour la troisième fois. Vide. Le dépôt contenait 14 PR ouverts ce matin-là – j'en avais examiné deux avant le déjeuner – et maintenant la page me montrait le genre de table rase que l'on ne voit que sur un tout nouveau dépôt. Ma première pensée n'a pas été "GitHub est en panne". Ma première pensée a été : « Est-ce que quelqu'un de l'équipe a tout fermé en masse pendant que j'étais en communication ?

Ensuite, j'ai ouvert le terminal. gh pr list. Les 14 PR. Juste là. Numéros, titres, auteurs, états de projet. Intact.

Cet écart – les données existent, mais l'interface utilisateur ne peut pas les voir – est la forme entière de la crise de disponibilité GitHub d'avril 2026 qui a frappé la communauté des développeurs. Ce n’est pas le genre de panne où la plateforme tombe et où une page d’état devient rouge. C'est pire. C'est le genre où tout semble cassé d'une manière qui vous fait douter de votre propre travail, tandis que les systèmes sous-jacents insistent tranquillement sur le fait qu'ils vont bien.

À la fin de la semaine, j'avais observé deux modes de défaillance distincts frapper la même plate-forme en sept jours, lu trois fois la mise à jour de GitHub CTO et commencé à repenser la façon dont j'architecte tout ce qui touche API de GitHub. Parce que l’histoire en dessous ne concerne pas vraiment deux bugs. Il s'agit de ce qui se produit lorsque le point d'étranglement du développement mondial de logiciels est frappé par une courbe de charge pour laquelle aucune infrastructure n'a été conçue - et les outils agentic AI que vous et moi utilisons quotidiennement en font partie.

La semaine où l'interface utilisateur de GitHub a commencé à mentir aux développeurs

Permettez-moi de bien planter le décor, car l’ordre des événements compte.

Le premier signe que quelque chose était structurellement défectueux est apparu le 31 mars 2026, lorsque GitHub a connu ce que j'appellerais sa « véritable » panne : environ six heures de disponibilité dégradée liée à un événement de perte de données sur les systèmes internes. Douloureux, très médiatisé et le genre de chose que chaque équipe d’ingénierie gère plusieurs fois par décennie. Je l'ai traité comme une pièce unique.

Puis le 23 avril est arrivé. Corruption de la file d’attente de fusion. Les demandes d'extraction entrant dans la file d'attente ne sortaient pas toujours proprement de l'autre côté. Certaines équipes ont réussi, d'autres non. Si vous n'avez jamais dépendu des files d'attente de fusion dans un monorepo à grande vitesse, c'est le genre de bug qui érode discrètement la confiance dans l'ensemble de la couche d'automatisation - votre CI dit vert, la fusion dit fusionné, puis quelqu'un remarque que le commit réel n'a pas atterri comme il aurait dû.

Le 27 avril est le moment où les choses sont devenues bruyantes. Les vues de liste de demandes d’extraction ont commencé à renvoyer des résultats vides ou partiels. La recherche du problème a échoué. Les filtres du tableau de projet ont cessé de se résoudre. Les premiers rapports que j'ai vus sur les réseaux sociaux concernaient des personnes accusant leurs collègues de supprimer du travail, ce qui est exactement une conclusion erronée mais très humaine. Il a fallu quelques heures au canal d'incident de GitHub pour confirmer la cause réelle : le cluster ElasticSearch alimentant les vues basées sur la recherche avait été submergé, apparemment sous le trafic généré par un botnet, et avait cessé de renvoyer des résultats utiles pendant qu'il tentait de récupérer.

Aucune perte de données. Les opérations Core Git ont fonctionné tout le temps. Le API renvoyait constamment des résultats corrects à toute personne sachant contourner l'interface utilisateur Web et demander directement. Mais pour les millions de développeurs qui expérimentent GitHub principalement via github.com/org/repo/pulls, la plateforme aurait tout aussi bien pu être en panne.

C'est la partie à laquelle je revenais sans cesse. Les données étaient toujours là. L'infrastructure qui trouve les données est ce qui a échoué. Et c’est précisément dans cette distinction que les choses deviennent intéressantes.

Pourquoi "GitHub est en panne" est le mauvais modèle mental

Si vous traitez GitHub comme un grand service monolithique, les incidents d’avril 2026 semblent aléatoires. Six heures ici, un problème de file d'attente de fusion là-bas, une panne de recherche quatre jours plus tard. De l'intérieur, il n'y a rien de tel : il s'agit d'une classe spécifique de modes de défaillance apparaissant à un endroit spécifique de l'architecture, de manière répétée.

Voici le modèle mental qui m'a aidé à comprendre cela.

Le GitHub moderne comprend au moins trois services empilés les uns sur les autres :

1. La couche Git — stockage réel du référentiel, push/pull, branchement, fusion. C’est la pièce que personne ne peut se permettre de casser et celle qui a le mieux résisté.
2. La couche de métadonnées et de flux de travail — pull requests, problèmes, projets, actions, webhooks, autorisations. Il s'agit principalement d'un territoire monolithique Ruby, avec MySQL et PostgreSQL en dessous.
3. La couche de recherche et de découverte — ElasticSearch, les pipelines d'indexation, les vues de liste et les filtres sur lesquels vous cliquez réellement.

Lorsque l'incident du 27 avril a eu lieu, il n'a pas supprimé la couche 1. Il n'a même pas supprimé la majeure partie de la couche 2. Il a supprimé la couche 3 - et comme la couche 3 est ce qui rend l'interface utilisateur que la plupart des développeurs utilisent pour trouver leur travail, le rayon d'explosion perçu était énorme alors que le rayon d'explosion fonctionnel réel était contenu.

Le bug de la file d'attente de fusion du 23 avril se trouvait dans la couche 2. L'événement de perte de données du 31 mars était plus profond, plus proche de la limite entre la couche 1 et la couche 2. Trois échecs différents, trois couches différentes, le tout en quatre semaines. Ce n'est pas de la malchance. Il s'agit d'une courbe de charge qui dépasse l'architecture à plusieurs endroits à la fois.

Et c'est sur la deuxième partie – la courbe de charge – que je souhaite consacrer le reste de cet article. Parce que l'autopsie CTO de GitHub admet essentiellement l'évidence : on demande à la plate-forme de faire quelque chose pour laquelle elle n'a pas été conçue, et la chose qui demande, c'est en partie nous.

Le nombre 30x qui devrait arrêter tous les ingénieurs à froid

Voici la phrase du leadership de GitHub que je ne cesse de relire. En octobre 2025, l'équipe a lancé un plan d'expansion de capacité visant une croissance 10x — un chiffre que vous considéreriez comme conservateur-agressif pour n'importe quelle équipe d'infrastructure. En février 2026, quatre mois plus tard, la modélisation interne indiquait que l'objectif réel était de 30x.

Relisez-le. Pas 10x révisé légèrement à la hausse. Pas 12x ou 15x. Tripler l'objectif initial, après seulement quelques mois de nouvelles données.

La mise à jour publique de GitHub cite des pics de 90 millions de pull requests fusionnés, 1,4 milliard de commits et 20 millions de nouveaux référentiels par mois. Même un de ces chiffres pris isolément serait une erreur. Tous trois décrivent ensemble une plateforme dont le profil de charge est réécrit en temps réel.

Qu'est-ce qui a changé entre octobre et février ? Deux choses, et elles sont liées.

La première est la plus évidente : les workflows de développement d'agents sont passés de la nouveauté à la production. J'ai observé cette courbe de l'intérieur de mon propre travail. Au troisième trimestre 2025, les agents étaient expérimentaux : Claude Code était nouveau, le SDK Anthropic Agent venait d'arriver et la plupart des équipes exécutaient un ou deux flux de travail automatisés en production avec de nombreux contrôles humains. Au premier trimestre 2026, les mêmes équipes géraient des flottes d’agents. Agents créateurs PR. Agents fixateurs de tests. Agents anti-dépendances. Agents de documentation qui surveillaient les fusions et mettaient à jour les documents automatiquement.

Chacun de ces agents est un utilisateur infatigable et infatigable de GitHub. Il ouvre PR. Il pousse les commits. Il lit les problèmes. Il atteint le API. Il déclenche des exécutions d'actions. Là où un développeur humain peut ouvrir trois ou quatre PR au cours d'une journée chargée, un agent peut en ouvrir trente et une flotte d'agents peut en ouvrir des milliers dans une organisation.

Le deuxième changement est structurel. Les référentiels eux-mêmes s'agrandissent. Les monorepos sont plus courants. Les refactors assistés par AI génèrent des différences plus importantes. Le code généré (des applications échafaudées entières produites par des outils tels que Claude Code en une seule invite) produit des validations qui touchent des centaines de fichiers à la fois. L'unité de "changement" sur GitHub s'est agrandie.

Multipliez ces deux tendances ensemble et vous n’obtiendrez pas une croissance 10x. Vous obtenez quelque chose de plus proche d’une croissance exponentielle composée qui double tous les six à huit mois et ne montre aucun signe de ralentissement. C'est exactement ce que l'équipe de capacité de GitHub a décrit.

Si vous vous demandez pourquoi votre CI semble plus lent cette année, pourquoi les retards de vos webhooks s'accentuent, pourquoi votre CLI gh se bloque parfois pendant dix secondes avant de renvoyer un résultat qui devrait être instantané - voici votre réponse. Vous ne l'imaginez pas. Vous ressentez la courbe de charge.

Ce que nous dit réellement la panne ElasticSearch

Je souhaite revenir spécifiquement au 27 avril, car l'échec ElasticSearch est l'incident le plus utile des trois sur le plan diagnostique. Cela nous apprend quelque chose de spécifique sur la manière dont un point d’étranglement de cette ampleur échoue.

ElasticSearch à la taille de GitHub n'est pas un cluster sur lequel vous pouvez lancer plus de nœuds. Il s'agit d'un système distribué parfaitement optimisé qui alimente tout, depuis les filtres de liste PR jusqu'aux requêtes de recherche, en passant par les requêtes de projet et la découverte de référentiels. Lorsqu’un botnet décide de le marteler – et « marteler » à l’échelle GitHub signifie des dizaines de milliers de requêtes spécialement conçues par seconde provenant d’une infrastructure compromise – vous ne voyez pas seulement des réponses plus lentes. Vous voyez les pipelines d’indexation prendre du retard. Vous voyez une bulle de files d’attente d’écriture. Vous voyez que le cluster passe plus de temps à gérer sa propre contre-pression qu'à répondre à de vraies requêtes.

L'atténuation consiste à reconstruire les index, à limiter le trafic abusif et à remettre lentement le cluster en service. Rien de tout cela n’est rapide. Rien de tout cela n’est glamour. Et pendant tout ce temps, le reste de la plateforme semble en bon état tandis qu’une couche critique de l’expérience utilisateur est dégradée.

Ce que cela révèle – et ce que GitHub a maintenant publiquement reconnu – c'est que le sous-système de recherche était un point de défaillance unique qui n'avait pas encore été isolé du reste de la plate-forme. Le travail de fiabilité a été prioritaire ailleurs, dans des endroits considérés comme à plus haut risque, et la recherche a tiré la courte paille. Rétrospectivement, le 27 avril a donné l’impression que cette priorisation était erronée, ce qui est l’arithmétique cruelle de la réponse aux incidents – chaque autopsie est également une critique des incendies que vous avez décidé de ne pas combattre en premier.

Il y a une leçon de développement enfouie là-dedans, et c'est le genre de chose à laquelle il est facile de faire signe mais difficile à faire : le rayon d'explosion de votre application n'est pas le même que l'empreinte de votre application. Les données de GitHub n'ont jamais été menacées le 27 avril. Leur couche principale Git a continué à bourdonner. Mais comme la plupart de leurs utilisateurs expérimentent GitHub via une interface utilisateur basée sur la recherche, un échec de la couche de recherche est devenu un événement au niveau de la plate-forme dans l'expérience vécue de chacun. Ce qui s'est cassé n'était pas la chose la plus importante dans leur architecture. C'était la chose la plus visible.

J'ai commencé à auditer mes propres systèmes dans cet objectif la semaine dernière. Quels sous-systèmes, en cas de défaillance, donneraient l'impression que le reste de mon application est défectueux même si ce n'est pas le cas ? La réponse est inconfortable. Il y en a plus que je ne le souhaiterais.

La feuille de route CTO, décodée

La réponse de GitHub à tout cela a pris la forme d'une mise à jour publique de CTO, et je souhaite la parcourir attentivement car le langage fait un vrai travail. Il ne s’agit pas simplement de « nous sommes désolés, nous allons ajouter de la capacité ». Il s'agit d'un aveu structuré de ce à quoi ressembleront les 12 à 24 prochains mois d'ingénierie GitHub - et sa forme vous indique quelque chose sur la direction que prend l'ensemble de l'industrie.

La feuille de route, telle que je la lis, se divise en cinq priorités.

1. Disponibilité avant capacité, capacité avant fonctionnalités. Il s'agit de la réorganisation principale. Pendant la majeure partie de l'histoire de GitHub, la rapidité des fonctionnalités était la priorité absolue : Copilot, Codespaces, Actions, Projects v2, flux de travail agents, tous livrés selon des délais agressifs. Le nouvel ordre est explicite : gardez d'abord les lumières allumées, puis assurez-vous qu'elles peuvent rester allumées à une charge 30x, puis expédiez les nouveaux éléments. Quiconque dirige une équipe d'infrastructure a déjà été témoin de cette réorganisation, généralement après un mauvais trimestre. C'est le bon choix. C'est également le signe que le travail de certaines fonctionnalités va visiblement ralentir.

2. Réduisez le travail inutile et améliorez la mise en cache. Cela semble ennuyeux jusqu'à ce que vous vous souveniez de l'exemple PostgreSQL donné par GitHub : la limitation du débit via des tables non enregistrées fonctionne bien à moins de 1 000 requêtes par seconde, mais à 10 000 RPS, vous avez besoin d'une mise en cache Redis devant, sinon vous ferez fondre la base de données. Chaque couche de la stack a des seuils comme celui-ci. La mise à l'échelle ne consiste pas à ajouter du matériel : elle consiste à remarquer chaque endroit où un modèle bon marché ne fonctionnait que parce que la charge était faible et à le reconstruire.

3. Isolez les services critiques et limitez le rayon d’explosion. C’est ce que le 27 avril aurait dû empêcher. Le travail ici est architectural : s'assurer que la recherche peut échouer sans interrompre les pages PR, s'assurer que la livraison des webhooks peut se dégrader sans supprimer les actions, s'assurer que les limites de débit appliquées à un locataire ne se répercutent pas sur un autre. Chaque élément « isoler X » de cette liste est également un aveu que X n’était pas isolé auparavant.

4. Migrez les chemins sensibles aux performances du monolithe Ruby vers Go. Il s'agit de l'élément le plus tactique et le plus chargé. Le monolithe Ruby on Rails est l'identité de GitHub depuis le début — il y a une célèbre blague interne selon laquelle GitHub est le monolithe Rails avec quelques services supplémentaires intégrés. Déplacer les chemins chauds vers Go (et déplacer la livraison des webhooks de MySQL vers des backends alternatifs, ce qu'ils ont également appelé) est le genre de travail qui prend des années et remodèle la façon dont les ingénieurs perçoivent la base de code.

5. Migration Azure et préparation multi-cloud. Microsoft possède GitHub, la migration Azure était donc toujours à venir. Mais le cadre multi-cloud est nouveau et important : il suggère que la direction de GitHub ne souhaite pas qu'un incident régional impliquant un seul fournisseur de cloud devienne l'incident de GitHub.

Si vous lisez cette feuille de route et louchez, c'est le même manuel de jeu que toutes les plateformes à croissance rapide des quinze dernières années ont utilisé. Twitter l'a diffusé après l'ère des baleines ratées. Stripe l'exécute en continu. AWS l'exécute au ralenti sur plusieurs décennies. La partie intéressante n'est pas que GitHub fasse cela. La partie intéressante est le timing et le déclencheur.

Pourquoi les workflows agentiques AI remodèlent l'infrastructure de développement

Voici la partie qui se connecte le plus directement à ce que j’écris chaque semaine. La raison pour laquelle GitHub a dû réviser son objectif de croissance de 10x à 30x en quatre mois n'est pas que les développeurs humains deviennent soudainement trois fois plus productifs. C'est que l'unité de "utilisateur GitHub" change.

Au cours de la dernière décennie, un utilisateur de GitHub était une personne. Cette personne a ouvert quelques PR par jour, en a examiné quelques autres, a poussé les commits en rafales concentrées pendant les heures de travail et est rentrée chez elle. Leur profil de charge était intense, ancré par fuseau horaire et finalement limité par le nombre de frappes qu'un humain peut produire.

Le nouvel utilisateur GitHub est partiellement ou entièrement un agent. Il ne dort pas. Il n'y a pas d'heures de travail. Il génère un PR chaque fois que CI signale un test irrégulier, qu'une dépendance devient obsolète, qu'une dérive de la documentation est détectée ou qu'un indicateur de fonctionnalité doit être nettoyé. Il n'effectue pas de petits commits - il effectue des commits structurés et générés par des outils qui touchent souvent plusieurs fichiers à la fois.

Lorsque vous remplacez une charge humaine limitée en rafales par une charge d'agent continue et illimitée, trois choses se produisent simultanément sur votre infrastructure :

• Les ratios crête/moyenne se compressent. GitHub avait l'habitude d'avoir des nuits et des week-ends. Ce n'est plus le cas. La frontière entre « charge de pointe » et « charge de fond » disparaît et vous devez concevoir que le pic soit la nouvelle moyenne.
• La taille moyenne des objets augmente. Les agents produisent des différences plus importantes et des descriptions PR plus riches. Les sous-systèmes touchant PR - rendu différentiel, contrôles de fusion, révision des threads - paient pour cela avec plus de CPU, plus de mémoire, plus de travail d'indexation.
• Pics de probabilité en cascade. Un webhook instable signifiait autrefois une notification légèrement retardée. Avec des agents dans la boucle, un webhook instable peut signifier un pipeline d'automatisation bloqué, ce qui signifie que l'agent réessaye, ce qui signifie plus d'appels API, ce qui signifie plus de charge sur le système qui était déjà en difficulté.

J'ai ressenti chacun de ces éléments dans mon propre travail. Le trimestre dernier, j'exécutais environ quatre agents Claude Code en parallèle sur un projet client : un écrivant des tests, un les corrigeant, un mettant à jour la documentation, un révisant les PR. Chaque agent se sentait bon marché individuellement. Ensemble, ils ont généré plus de trafic GitHub API en un après-midi que j'en aurais généré en une semaine en travaillant manuellement. Et j'étais un développeur. Multipliez cela par la population mondiale de développeurs agents, qui est passée de « premiers utilisateurs » à « grand public » à peu près dans la même fenêtre où la charge de GitHub a doublé.

C'est la véritable histoire de la crise de disponibilité du GitHub produite en avril 2026. Pas "GitHub a passé une mauvaise semaine". C'est "le modèle de charge pour lequel la plate-forme a été conçue a été remplacé par un modèle de charge différent, et la dette architecturale de cette inadéquation est devenue publique".

Si vous souhaitez mieux comprendre comment les flux de travail agentiques sont devenus la force dominante sur les plates-formes de développement cette année, j'en ai couvert les signaux précédents dans le guide Anthropic Agent SDK et le cadre de système d'exploitation agentique Claude Code - le fil conducteur de tout cela est que les outils que nous célébrons comme des gains de productivité sont également des tests de stress d'infrastructure, et GitHub est la première plateforme majeure où le projet de loi est arrivé assez fort pour faire la une des journaux.

Ce que cela signifie pour construire sur GitHub

Laissez-moi devenir tactique. Si vous construisez quelque chose qui dépend de GitHub – et si vous êtes un développeur actif en 2026, vous l'êtes – il y a cinq ajustements concrets qui méritent d'être apportés au cours des 30 prochains jours.

Tout d'abord, séparez « GitHub is up » de « GitHub UI is up » dans votre surveillance. L'incident du 27 avril a prouvé qu'il s'agit d'états différents. Si vos outils attendent que la page d’état GitHub passe au rouge avant de contourner les problèmes, vous serez en retard. Ajoutez directement des sondes d'intégrité API aux points de terminaison spécifiques dont dépend votre flux de travail (gh pr list à un référentiel connu, une requête de recherche dont vous savez qu'elle doit renvoyer des résultats) et traitez la dégradation partielle comme un signal d'action, pas seulement un signal d'information.

Deuxièmement, appuyez-vous sur le API et la CLI, et non sur l'interface utilisateur Web, pour tout flux de travail que vous ne pouvez pas vous permettre de perdre. Le pull requests a existé jusqu'au 27 avril. La CLI les a vus tout le temps. Si le manuel d'incidents de votre équipe dépend des clics humains sur les vues de liste PR, votre manuel d'incidents s'interrompt lorsque la couche de recherche s'interrompt. Si le playbook passe par gh et API, ce n’est pas le cas.

Troisièmement, auditez le comportement de vos agents en matière de nouvelles tentatives. Chaque flux de travail agent que j'ai jamais expédié a, à un moment donné, présenté une tempête de nouvelles tentatives lors d'un incident en aval, ce qui a aggravé l'incident pour tout le monde, y compris lui-même. L'intervalle exponentiel, la gigue et les disjoncteurs ne sont pas facultatifs pour les agents qui touchent GitHub. Si votre agent ne dispose pas des trois, la prochaine panne sera plus difficile pour vous et pour GitHub.

Quatrièmement, considérez les vues basées sur la recherche comme fondamentalement moins fiables que les recherches directes. Il s'agit d'une leçon d'architecture à long terme, et non spécifique à GitHub. Chaque fois qu'une interface utilisateur dépend d'un index de recherche, vous dépendez d'un système dont les temps de reconstruction sont mesurés en heures. Là où votre flux de travail peut utiliser des recherches directes (PR par numéro, validation par SHA, problème par ID), préférez celles-ci. Enregistrez les requêtes basées sur la recherche pour des cas d’utilisation véritablement exploratoires.

Cinquième – et c'est celui que la plupart des équipes ignorent – ​​ajoutez un mode « Dégradation gracieuse GitHub » à tout ce que vous construisez. Que fait votre outil lorsque GitHub est opérationnel mais lent ? Quand renvoie-t-il des résultats partiels ? Quand les webhooks sont retardés de cinq minutes au lieu de cinq secondes ? La plupart des outils que j'ai vus sont soit "GitHub fonctionne" soit "tout explose". Il existe un énorme terrain d’entente qui mérite d’être conçu.

Ce que je me suis trompé et ce que je regarde ensuite

Je vais être honnête sur une chose que je pensais à propos de tout cela. Lorsque l’incident du 31 mars s’est produit, je l’ai interprété comme un événement isolé et je suis passé à autre chose. Je ne l'ai pas connecté à la courbe de charge. Je ne m'attendais pas à ce que d'ici quatre semaines, nous assistions à deux autres incidents à différents niveaux de la même plate-forme. La corruption de la file d'attente de fusion du 23 avril a à peine été enregistrée pour moi car aucun de mes projets n'utilisait de files d'attente de fusion ce jour-là. Le 27 avril, la tendance était indéniable.

La leçon que j’en tire est que les incidents d’infrastructure de cette ampleur ne se traduisent généralement pas par une simple défaillance dramatique. Ils se présentent sous la forme d’un groupe d’échecs plus petits liés qui semblent chacun explicables isolément et n’ont de sens que lorsque vous les lisez comme une seule histoire. Si vous attendez qu’une grosse panne agisse, vous manquerez les coups de semonce.

Ce que je regarde pour le reste de 2026 :

• Si l'expansion de la capacité de GitHub reste en avance sur la courbe de charge. L'objectif 30x est en gras mais la courbe bouge également. Si les workflows agents s’accélèrent à nouveau au second semestre, la cible évolue avec eux. - Que les concurrents deviennent sérieux. Les instances GitLab, Codeberg, Forgejo et Gitea auto-hébergées bénéficient toutes de tout écart de fiabilité soutenu chez GitHub. Je ne m'attends pas à une migration massive, mais je m'attends au message "GitHub est-il toujours la valeur par défaut ?" Cette question sera abordée dans plus de réunions d'architecture qu'il y a six mois. - Les flux de travail agents eux-mêmes deviennent-ils plus polis. Il existe un argument selon lequel les agents produisant cette charge pourraient être plus intelligents à ce sujet : traitement par lots, mise en cache, respect des délais d'attente, évitement des interrogations inutiles. La première vague d'outils agents optimisés pour la fonctionnalité.

La deuxième vague devra être optimisée pour être un bon citoyen sur les infrastructures partagées. - La migration du monolithe à emporter sera-t-elle expédiée à temps. Il s'agit de l'élément ayant le plus grand effet de levier sur la feuille de route de GitHub, et également le plus lent. Des années de travail. S'ils l'exécutent bien, GitHub à une charge 30x semble correct. S’ils ne le font pas, nous aurons la même conversation en 2027 à propos d’un incident différent.

Ce sur quoi je reviens sans cesse, c'est que GitHub à cette échelle n'est plus seulement un produit. C'est une infrastructure. C'est le point d'étranglement par lequel un pourcentage significatif des logiciels mondiaux passent de l'idée à la production. Lorsque votre point d'étranglement connaît un mauvais mois, les conséquences se répercutent d'une manière difficile à mesurer mais facile à ressentir.

Questions fréquemment posées

Qu'est-ce qui a causé le bug de la demande d'extraction GitHub en avril 2026 ?

Le bug de visibilité des demandes d'extraction du 27 avril a été provoqué par la surcharge du cluster ElasticSearch alimentant les vues basées sur la recherche, apparemment sous le trafic généré par un botnet. Les PR semblaient absents des vues de liste car ces vues dépendent des index de recherche, mais les données sous-jacentes n'ont jamais été perdues et sont restées accessibles via GitHub API et CLI. Pour la répartition architecturale, voir « Pourquoi GitHub est en panne, c'est le mauvais modèle mental » ci-dessus.

GitHub a-t-il perdu des données lors des incidents d'avril 2026 ?

Non. Aucun des incidents d'avril 2026 (corruption de la file d'attente de fusion le 23 avril, surcharge ElasticSearch le 27 avril) n'impliquait une perte de données. Les opérations principales de Git, les référentiels et API ont continué à fonctionner. L'incident du 31 mars 2026 impliquait effectivement un événement de perte de données avec environ six heures de disponibilité dégradée.

Qu'est-ce que le plan de mise à l'échelle 30x de GitHub ?

GitHub a commencé une expansion de capacité de 10 fois en octobre 2025, puis a révisé l'objectif à 30 fois d'ici février 2026 après que l'agent AI workflows ait fait doubler la charge de la plate-forme en 6 à 8 mois. Le plan comprend l'isolation des services critiques, la migration des hot paths de Ruby vers Go, le déplacement des webhooks hors MySQL et la poursuite de la migration vers Azure. Voir « Le nombre 30x qui devrait arrêter chaque ingénieur à froid » ci-dessus pour la répartition complète.

Comment l'agent AI workflows affecte-t-il l'infrastructure de GitHub ?

Les flux de travail agents remplacent la charge humaine intense et ancrée dans un fuseau horaire par une charge d'agent continue et illimitée. Les agents ouvrent les PR, envoient des validations et appellent les API sans cycles de veille, ce qui compresse les ratios crête/moyenne, augmente la taille moyenne des objets et augmente la probabilité de cascade lors d'incidents. La mise à jour CTO de GitHub cite directement l'accélération des flux de travail agentiques depuis fin 2025 comme principal moteur de l'objectif de mise à l'échelle révisé.

Dois-je migrer hors de GitHub après avril 2026 ?

Pour la plupart des équipes, non. La couche Git principale de GitHub est restée stable tout au long des incidents d'avril 2026, et aucune feuille de route publique de GitLab, Codeberg ou Forgejo ne correspond actuellement à la surface des fonctionnalités de GitHub. La bonne solution consiste à renforcer vos outils contre la dégradation partielle de GitHub : préférez le API et la CLI à l'interface utilisateur Web pour les flux de travail critiques, ajoutez des modes de dégradation gracieux et auditez vos agents pour les tempêtes de nouvelles tentatives. Voir « Ce que cela signifie pour la façon dont vous construisez sur GitHub » ci-dessus.

Travaillons ensemble

Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.

• Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
• Portefeuille : mejba.me
• Ramlit Limited (solutions d'entreprise) : ramlit.com
• ColorPark (conception et image de marque) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io