GitHub n’a pas déployé tous ses services sur Azure au 30 septembre

Ce rapport mensuel n’est pas isolé. Depuis le printemps, GitHub publie chaque mois la liste de ses incidents et l’avancement de sa migration, chiffres à l’appui. Mis bout à bout, ces cinq rapports racontent une bascule rapide entre février et août, puis un plateau en septembre, sur fond de pannes parmi les plus longues de l’année.

Un déménagement décidé faute de place

Le projet a été rendu public en octobre 2025 : selon The Verge, cité par Tekedia le 8 octobre 2025, GitHub préparait alors une migration complète vers les serveurs d’Azure, étalée sur les deux années suivantes. Son directeur technique, Vlad Fedorov, en a donné la raison sur le blog de GitHub le 11 mars 2026 : passer sur Azure doit permettre d’« absorber une croissance rapide », en grandissant au sein d’une même région comme d’une région à l’autre. Le 20 août, il précisait que GitHub avait installé dans ses centres de données existants « autant de matériel que l’électricité disponible le permettait », tout en accélérant son passage à Azure.

Les rapports de 2026 ont resserré cette échéance. Celui de juillet fixait l’objectif de sortir le trafic de production de github.com des centres de données de GitHub « d’ici la fin de l’année civile 2026 », avec une étape pour la fin du trimestre, le 30 septembre : 70 % du trafic de lecture et 30 % du trafic d’écriture en Central US, et chaque service de production en ligne dans cette région. La règle répétée dans les rapports depuis mai résume les priorités : « la disponibilité, puis la capacité, puis les fonctionnalités ».

De 8 % à 65 %, puis presque plus rien

Les chiffres publiés permettent de suivre la progression. GitHub servait depuis Azure 8 % du trafic de son « monolithe » (le gros programme d’un seul bloc qui fait tourner l’essentiel de github.com) en février, et 40 % en mai, selon le rapport de mai. Puis la montée s’est arrêtée une première fois : après un incident de stabilité le 21 mai, la montée en charge a été suspendue environ un mois et n’a repris que le 17 juin, avec de nouveaux garde-fous. « Aller plus lentement avec plus d’assurance est le bon compromis », écrivait GitHub dans le rapport de juin, qui reconnaissait déjà un objectif manqué : 43 % du trafic Git (les envois et récupérations de code) en Azure au lieu des 50 % visés.

L’été a ensuite été rapide. Les lectures du monolithe ont culminé à 52,75 % le 28 juillet, puis à 64,3 % en août, d’après le rapport d’août. Le 11 août, GitHub a fait tourner pour la première fois depuis Azure une base de données MySQL « primaire », c’est-à-dire la copie qui reçoit les écritures (les autres copies, ou répliques, ne servent qu’à lire). Deux autres ont suivi le 27 août.

Au 7 octobre, le compteur affichait 65,4 % pour les lectures de l’application principale, 48,3 % pour les lectures Git et 80,2 % pour le traitement de flux (les chaînes qui traitent en continu les événements de la plateforme), trois mesures qui « portent sur des charges différentes et ne doivent pas être additionnées », précise GitHub. Entre le pic d’août et la mesure d’octobre, la part des lectures n’a donc gagné qu’un peu plus d’un point. Les deux chiffres ne sont pas strictement comparables (un pic d’un côté, un relevé à date de l’autre), mais le plateau colle avec ce que décrit le rapport : GitHub a gelé les déploiements et les hausses de trafic vers Central US le 11 septembre, « parce que la capacité était inégale entre les zones de disponibilité », ces groupes de centres de données d’une même région, alimentés et raccordés séparément pour qu’une défaillance de l’un n’emporte pas les autres. La montée a repris le 18 septembre « après un soulagement temporaire » ; l’objectif est désormais de débloquer toute la capacité disponible d’ici fin octobre.

Face aux objectifs de juillet, le bilan est net. Les lectures restent sous les 70 % visés. Pour les écritures, le rapport ne donne aucune part de trafic, seulement le nombre de bases primaires déplacées : 13 sur 51. Et 40 des 160 services de production n’étaient toujours pas déployés en Central US.

Les chiffres de part d’Azure qui circulent, et celui que nous retenons

Le 20 août, Vlad Fedorov écrivait qu’Azure assurait « environ 58 % de la charge de la plateforme » de GitHub, contre 12 % en mai. Ce chiffre mesure la charge globale, pas les seules lectures du monolithe : il ne contredit pas les 64,3 % du rapport d’août, il compte autre chose. Nous retenons la série des rapports mensuels (lectures de l’application principale), seule mesure suivie de mois en mois. En mai et en juin, le rapport parle de « trafic du monolithe » sans préciser « lectures ». Pour Git, les chiffres de juin (43 %) et de juillet (47 %, valeur atteinte et non pic) portent sur tout le trafic Git, ceux d’août (54 %, valeur atteinte) et du 7 octobre (48,3 %, relevé à date) sur les seules lectures : ils ne se comparent pas entre eux, et deux relevés ponctuels ne suffisent pas à conclure à un recul.

Août, le mois des pannes de capacité

La migration se déroule pendant que la plateforme encaisse une croissance brutale. Dans un billet du 20 août, Vlad Fedorov indiquait que le nombre de commits (les enregistrements de modifications du code) par mois était passé de 1,4 à 2,9 milliards depuis avril. « Cette croissance explique la pression sur nos systèmes, mais elle n’excuse pas ces pannes », ajoutait-il.

Les pannes en question sont celles du 6 et du 17 août. Le 6 août, à partir de 15 h 22 UTC, GitHub Actions, le service qui exécute automatiquement tests et déploiements, a été perturbé pendant 10 h 42 selon la chronologie de l’incident (environ 9 heures d’impact pour les clients) : au moins 74 organisations ont vu leurs tâches ne pas démarrer, échouer en cours de route ou rester en file d’attente. Le 17 août, à partir de 13 h 40 UTC, c’est github.com lui-même qui a flanché pendant 7 h 35 (7 h 47 dans le billet du directeur technique) : au plus fort, 56,07 % des requêtes adressées aux services touchés échouaient ou traînaient. BleepingComputer relevait le jour même que l’authentification d’entreprise (SAML, OIDC) et la synchronisation des comptes faisaient partie des services atteints.

Pour le directeur technique, aucune de ces deux pannes ne vient d’un changement de code ou de configuration : ce sont « des défaillances de capacité ». Le 17 août, un pic de trafic a poussé les répartiteurs de charge d’un centre de données au-delà de leurs limites, et un défaut dans les nouvelles tentatives automatiques d’un client a amplifié le trafic vers un service d’authentification. Le billet du directeur technique situe la défaillance initiale dans « notre centre de données Central US », le nom même de la région Azure vers laquelle GitHub migre ; le texte ne détaille pas davantage.

Septembre a été plus calme sur le papier : deux incidents, contre cinq en août, huit en juillet, six en juin et neuf en mai. Le 13 septembre, une tâche de nettoyage de données a saturé une base partagée pendant environ deux heures : environ 96 % des créations de tickets par l’interface web ont été touchées, ainsi que 90 % des inscriptions. Le 28 septembre, les revues de code de Copilot, l’assistant de programmation de GitHub, ont rendu des résultats incomplets pendant près de trois heures, sans que le défaut soit détecté, faute de surveillance. Le rapport mentionne aussi qu’une bascule de base de données planifiée a déclenché un processus d’urgence automatique qui a coupé les copies de Central US et perturbé les clients de la région ; il n’en donne pas la date.

Ce que les équipes peuvent en attendre

Pour les développeurs et les entreprises qui confient leur code et leurs chaînes de déploiement à GitHub, trois points se dégagent des documents publiés.

La migration elle-même produit des incidents. La bascule de base de septembre en est l’exemple le plus direct, et il reste 38 bases primaires à déplacer. Or une base qui flanche se voit tout de suite côté utilisateurs : le 13 septembre, la saturation d’une seule base partagée a suffi à perturber presque toutes les créations de tickets par le web.

Les entreprises ne sont pas à l’abri sur leurs offres dédiées. L’incident du 28 septembre a touché github.com mais aussi les régions de GitHub Enterprise Cloud avec résidence des données, une offre séparée, hébergée sur un sous-domaine de GHE.com, qui permet de choisir où sont stockées ses données (Europe, soit l’UE, la Norvège et la Suisse, États-Unis, Australie, Japon).

Enfin, les nouveautés passent après : GitHub le répète dans ses rapports, la disponibilité et la capacité d’abord, les fonctionnalités ensuite.

Reste le calendrier. Le rapport du 14 octobre ne mentionne plus l’échéance de fin 2026 annoncée en juillet : il ne la confirme pas et ne la retire pas, et ne fixe aucune nouvelle date pour les 40 services et les 38 bases encore à déplacer. Le seul jalon chiffré est la capacité promise pour fin octobre. Le prochain rapport, si GitHub garde son rythme mensuel, dira si la montée vers les 70 % a repris, et quel chemin il restera à parcourir, en quelques semaines, pour tenir la promesse de juillet.

Les citations de GitHub sont traduites de l’anglais par la rédaction.