Quand des milliers d'agents logiciels créent des branches, poussent du code et lisent des dépôts en parallèle, la limite d'une infrastructure Git ne se joue plus seulement sur le stockage. Elle se joue aussi sur ce qui force les opérations à attendre les unes les autres.
GitHub dit s'attaquer à ce point en déplaçant ses dépôts vers Azure et en changeant la façon dont les écritures sont validées. D'après l'entreprise, 99,99999 % de ses dépôts sont déjà hébergés dans le cloud, tandis qu'une petite portion des dépôts les plus sollicités reste ralentie par la latence entre régions. La direction envisagée passe notamment par des quorums appliqués référence par référence, plutôt qu'au dépôt entier.
Et ce n'est pas qu'un cas GitHub. Ça touche une question plus générale : dans un système distribué, ajouter des machines ne suffit pas si chaque écriture reste bloquée par une coordination trop large. Voici comment le modèle fonctionne, ce que GitHub en attend, et les limites à garder en tête avant de s'en inspirer ailleurs.
Pourquoi GitHub déplace ses dépôts vers Azure
La migration répond à un problème très concret : le trafic Git augmente, mais les contraintes physiques restent les mêmes (énergie, régions, capacité des centres de données). Et l'extension « en dur » prend du temps, surtout quand l'approvisionnement en matériel ralentit.
Pour un service central comme Git, on ne parle pas juste de déplacer des fichiers. Les dépôts sont nécessaires à beaucoup d'autres fonctions de GitHub. Il faut donc déplacer les données, les services qui les servent et les dépendances associées, sans couper le trafic des utilisateurs. GitHub décrit une approche progressive : d'abord déplacer les données, puis faire évoluer l'architecture une fois qu'elles tournent dans le nouvel environnement.
Migrer avant de refondre
Sur le papier, on pourrait imaginer un double mouvement : migration vers le cloud et refonte du stockage en même temps. Le problème, c'est qu'on cumule alors deux sources de risque : une nouvelle plateforme d'hébergement et un nouveau protocole de stockage, tous deux modifiés en parallèle. Pour un système critique, si quelque chose casse à cause de l'interaction entre ces changements, l'erreur sera plus difficile à isoler.
GitHub a donc séquencé. La première copie d'un dépôt est arrivée en Azure Central US en août 2025. Selon l'entreprise, la plupart des dépôts ont aujourd'hui deux répliques sur cinq dans Azure, et le cloud sert environ la moitié du trafic Git. Pendant une bonne partie de la migration, Azure absorbe la croissance tandis que les centres de données historiques restent à charge relativement stable.
L'objectif ici n'est pas de « supprimer » le risque. Il est de le rendre plus local et plus facile à mesurer : on peut observer le comportement des dépôts déjà migrés sans changer simultanément leur mécanisme de validation. C'est souvent la meilleure stratégie quand on ne peut pas arrêter le service pour tester une nouvelle architecture.
La migration suit les répliques et le trafic
Les dépôts sont répartis sur cinq répliques, pour combiner disponibilité, durabilité et capacité de lecture. Le routage privilégie une réplique proche géographiquement (même région et même zone de disponibilité que la requête). À mesure que les répliques passent dans Azure, une part grandissante du trafic y est servie. Quand la dernière réplique quitte l'ancienne région, cette région cesse de recevoir les requêtes pour ce dépôt.
Ce point est important : migration des données et migration du trafic vont ensemble. Copier un dépôt ne suffit pas. Il faut aussi diriger les lectures et les écritures vers les répliques pertinentes, tout en gardant assez de copies en ligne pour ne pas perdre en disponibilité. Résultat : la migration devient un processus « observé » dépôt par dépôt, plutôt qu'un basculement massif.
Le verrouillage par dépôt limite les écritures
Le vrai goulot reste sur une petite fraction des dépôts - mais ce sont les plus actifs. Dans l'architecture actuelle, GitHub valide les écritures avec un quorum. En bref, un quorum permet de confirmer une opération après la réponse d'un nombre suffisant de répliques. Mais le système attend aussi les répliques restantes jugées saines, jusqu'à un délai d'expiration.
Cette nuance compte. Entre « obtenir une majorité » et « continuer tant que les répliques attendues n'ont pas répondu », la différence peut être énorme. Si une réplique est loin ou lente, elle peut retarder les écritures même quand le quorum est déjà atteint. GitHub cite des répliques Azure séparées des centres historiques par environ 1 600 kilomètres. Un aller-retour réseau représente autour de 25 millisecondes, et une écriture peut en demander plusieurs. À ce rythme, la latence finit par peser très vite sur le débit.
Une file d'attente unique
Le système garde un verrou à l'échelle du dépôt pendant toute la validation d'une mise à jour. Donc, tant qu'une écriture n'est pas terminée, la suivante attend. Et le temps global dépend de la réplique saine la plus lente : le débit maximal du dépôt devient aussi limité par cette durée.
On peut le voir comme une file d'attente. Si les écritures arrivent plus vite qu'elles ne sont traitées, elles s'empilent. Les requêtes suivantes attendent derrière les précédentes, et l'attente grimpe avec la charge. Ajouter des répliques éloignées aide sur la résilience, mais ne supprime pas la sérialisation. Dans certains cas, cela ajoute même un aller-retour réseau par écriture, sans augmenter le nombre d'opérations en parallèle.
Et quand plusieurs acteurs travaillent sur le même dépôt, ça se ressent. Un agent pousse une branche, un développeur met à jour une autre branche, et une automatisation publie un résultat sur une troisième. Si tout ça est verrouillé au niveau du dépôt, les opérations finissent par s'attendre les unes les autres alors qu'elles ne modifient pas forcément le même état.
La cohérence Git ne demande pas toujours un ordre global
Git impose des garanties de cohérence, mais elles portent surtout sur les références : branches et étiquettes. Après l'acceptation d'une mise à jour de référence, un client ne devrait pas « retomber » sur une ancienne valeur. Il voit soit la valeur acceptée, soit une valeur plus récente. Ça vaut pour une mise à jour normale, un force push ou une suppression.
En revanche, deux mises à jour de références distinctes n'ont pas besoin, dans tous les cas, d'être ordonnées par rapport l'une à l'autre. C'est là que se joue la marge : on peut conserver l'ordre seulement là où il faut, sans forcer un ordre global pour toutes les opérations d'un dépôt. Cette séparation entre cohérence locale et coordination globale est le cœur du changement proposé.
Le quorum par référence réduit la coordination
GitHub change la portée du quorum. Au lieu de sérialiser toutes les écritures d'un dépôt, le système sérialise celles qui touchent une même référence. Deux opérations concurrentes sur la même branche doivent toujours être ordonnées. Deux opérations sur des branches différentes peuvent, dans les cas où elles ne dépendent pas l'une de l'autre, avancer en parallèle.
Concrètement, ça aide quand plusieurs développeurs ou agents poussent sur un même dépôt. Si chacun travaille sur sa branche, leurs opérations ne sont plus obligées de s'attendre derrière une file unique. La latence inter-régions reste là pour chaque écriture, mais plusieurs écritures indépendantes peuvent être « en vol » en même temps.
Comparaison des deux approches
| Critère | Quorum à l'échelle du dépôt | Quorum par référence |
|---|---|---|
| Portée de la sérialisation | Toutes les écritures du dépôt | Écritures portant sur la même référence |
| Écritures sur des branches différentes | Elles peuvent se bloquer mutuellement | Elles peuvent progresser en parallèle |
| Latence réseau | Affecte chaque opération sérialisée | Toujours présente, mais mieux amortie par la concurrence |
| Principal avantage | Modèle simple à raisonner | Débit supérieur quand les écritures sont indépendantes |
| Limite principale | File globale et plafond de débit | Conflits toujours possibles sur une même référence |
Dans des tests internes rapportés par GitHub, des écritures sur des références différentes atteignent un débit trois à quatre fois supérieur, avec une latence plus faible. Le chiffre dépend des charges testées, donc ce n'est pas une promesse « universelle » dépôt par dépôt : le gain vient surtout du nombre d'écritures réellement indépendantes qu'on peut traiter en parallèle.
Ce que cette approche ne résout pas
Le quorum par référence ne supprime pas la latence d'un aller-retour réseau. Il réduit surtout ce qui empêche les autres opérations de progresser. Un dépôt dont toutes les écritures visent la même branche restera largement séquentiel. Et les opérations qui touchent plusieurs références à la fois, ou qui dépendent d'un état partagé, demandent un traitement particulier : on ne peut pas les déclarer « indépendantes » juste pour gagner des performances.
En pratique, il faut raisonner à partir de la sémantique réelle des données. Plus de parallélisme n'est pas toujours synonyme de meilleur système. Dans un système distribué, alléger la coordination aide, mais seulement si les garanties attendues par les clients restent intactes.
Le stockage objet sépare lecture et écriture
Le deuxième axe consiste à séparer le stockage durable des données et la capacité de calcul qui les sert. GitHub explique qu'actuellement lectures et écritures sollicitent les mêmes répliques. Or la plupart des dépôts sont très orientés lecture : l'entreprise indique observer entre 100 et 1 000 lectures pour une écriture.
Quand lectures et écritures utilisent les mêmes machines, elles se disputent mémoire et ressources de calcul. Les lectures pourraient bénéficier de caches mémoire plus gros, mais cette mémoire sert aussi à la compaction, c'est-à -dire à la réorganisation des données stockées. Tant que tout reste mélangé, chaque capacité doit être partagée entre plusieurs besoins.
Une réplique virtuelle pour rendre les écritures durables
Première étape : intégrer le stockage objet Azure Blob Storage au quorum via une « réplique virtuelle ». Cette réplique est un processus éphémère : elle ne stocke pas son propre état durable, mais relaie les écritures vers le stockage objet. Une écriture n'est confirmée qu'une fois qu'elle est durable dans Azure Blob Storage.
Le mécanisme ajoute de la latence à chaque écriture. Mais il ne crée pas forcément un nouveau plafond de débit, tant que les écritures sur des références différentes peuvent rester concurrentes. La réplique virtuelle peut aussi regrouper plusieurs transactions indépendantes dans un seul ensemble d'opérations réseau. Sur un dépôt très sollicité, on peut ainsi amortir un aller-retour de stockage sur plusieurs écritures simultanées, au lieu de le payer séparément pour chacune.
Pour l'instant, cette réplique virtuelle prend aussi en charge la compaction, et les répliques de lecture récupèrent l'état compacté. C'est un choix transitoire : la séparation progresse, mais tout n'est pas encore découplé à 100 %.
Des répliques de lecture à la demande
Quand les données durables sont dans le stockage objet, GitHub peut ajouter des répliques virtuelles dédiées à la lecture, sans les intégrer au quorum d'écriture. Elles réchauffent leur cache depuis Azure Blob Storage, prennent en charge le trafic de lecture et réconcilient leur état local avec la source de vérité en arrière-plan.
L'intérêt, côté architecture, est clair : on peut faire varier séparément les ressources pour les écritures et celles pour les lectures. Si un dépôt subit une hausse de lectures, l'infrastructure peut ajouter des capacités de lecture sans devoir multiplier, dans la même proportion, les membres du quorum qui valident les écritures.
GitHub indique aussi que ses tests internes de charge ont atteint les limites de leur outil avant celles des répliques virtuelles de lecture. C'est encourageant, mais ça reste une mesure « dans leurs conditions » : contenu des dépôts, profils de requêtes, cache et concurrence peuvent changer la donne. L'article mentionne en plus que cette étape laisse encore des sujets à traiter pour la suite.
Conclusion : faire évoluer le système sans attendre sa refonte complète
Le chantier de GitHub repose sur deux leviers. Le premier consiste à réduire la coordination à ce qui doit vraiment l'être, au lieu de tout sérialiser au niveau du dépôt. Le second consiste à séparer le stockage durable, le traitement des écritures et la capacité dédiée à la lecture. Ensemble, ces changements visent à augmenter le débit sans attendre la refonte complète du protocole de stockage.
Rien n'est magique : une branche très disputée reste un point de friction, la latence ne disparaît pas, et l'ajout de durabilité via le stockage objet impose aussi ses propres contraintes. Mais une évolution progressive qui donne déjà de la marge peut valoir plus qu'une architecture cible « parfaite » qui arrive trop tard.
Pour creuser les choix et les étapes de migration, consultez l'article technique de GitHub sur cette architecture. Et si vous concevez une plateforme distribuée, commencez par cartographier les opérations qui dépendent réellement les unes des autres : c'est souvent là que se trouve le prochain levier d'augmentation de capacité.