GitHub cite un dysfonctionnement de l'autoscaling et une tempête de tentatives de reconnexion dans VS Code comme responsables de sa récente panne de 8 h,

Qui s'explique par sa structure de SaaS centralisé

Le 17 août 2026, GitHub a subi une [nouvelle] panne mondiale pendant près de 8 heures. L’incident a débuté à approximativement 15 h 40 en France métropolitaine avant d’être déclaré résolu à 23 h 15. Ce n’était pas une simple indisponibilité de l’interface web. La panne à touché les API, les Pull Requests, les webhooks, l'outil [GitHub Actions] et l'authentification. En tant que plateforme SaaS centralisée et interconnectée, ses caractéristiques structurelles et opérationnelles ont amplifié l'impact de la situation.

The RCA for the outage we had at GitHub yesterday is live.

We're sorry it happened and hope this answers your questions about it. The team is already working on the actions listed here to fix it.https://t.co/1BZfMYncoU

— Cassidy (@cassidoo) August 18, 2026

La panne GitHub du 17 août 2026 illustre les inconvénients pour les équipes de développement informatique de s’appuyer uniquement sur un SaaS centralisé.

Bien que Git soit décentralisé, GitHub impose un serveur maître officiel. Ainsi, les validations de code et autres historiques d’équipe convergent vers un même centre. C’est cette architecture qui explique en grosse partie la dernière panne.

En effet, lorsqu’un développeur dispose déjà du dépôt d’un projet informatique sur sa machine, il peut continuer à consulter l’historique, créer une branche et produire des commits sans joindre GitHub. C’est là qu’apparaît l’aspect décentralisé (via Git). Pour le reste, il faut s’appuyer sur l’architecture SaaS centralisée.

Une équipe ne livre pas un produit avec des commits locaux seulement. Son fonctionnement dépend aussi d’autres services dépendant de l’architecture SaaS de GitHub :

• la synchronisation avec le dépôt distant ;
• la revue et la fusion des changements ;
• l’exécution des tests automatisés ;
• la production et le stockage des artéfacts ;
• les webhooks vers d’autres services ;
• l’authentification des collaborateurs ;
• le déclenchement des déploiements.

Au plus fort de l'incident, GitHub a signalé un taux d'erreur d'environ 20 % pour le trafic Web et API, et un taux d'erreur stupéfiant de 50 % pour les téléchargements bruts de dépôts et d'archives. Parmi les services touchés, on trouve justement ceux qui apparaissent dans la liste ci-dessus. En gros, la panne du 17 août illustre la différence entre « posséder une copie du code » et « maitriser la chaîne qui permet de le livrer. »

Time to invest in self hosted runners.

— Snazzie (@ItsSnazzie) August 18, 2026

Tout est parti d’une forte hausse du trafic externe qui a mené à une surcharge des couches d’authentification, isolant ainsi de nombreuses entreprises.

La dépendance à l’authentification centralisée est l’un des nœuds de la dernière panne sur GitHub. Les pannes sur les couches SAML, OIDC et SCIM ont bloqué l'accès des équipes d'entreprise, rendant les services inaccessibles même lorsque le code de base restait potentiellement joignable.

En effet, les systèmes SaaS modernes gèrent des appels automatisés fréquents. Face aux premiers ralentissements, les clients VS Code, les scripts CI/CD et les agents ont multiplié les nouvelles tentatives automatiques et ont saturé les serveurs.

La croissance exponentielle des requêtes générées par les assistants d’intelligence artificielle et les flux de travail automatisés pèse lourdement sur l'infrastructure de la plateforme, rendant la gestion de la concurrence plus fragile lors d'incidents de mise à l'échelle.

En gros, la panne du 17 août 2026 illustre les inconvénients de la centralisation de la chaîne de valeur DevOps. En effet, GitHub opère selon une espèce de modèle « Tout-en-un ». La plateforme ne sert pas juste à héberger du code, mais orchestre toute la chaîne de livraison logicielle et c’est en cela que se situe le piège pour les équipes de développement informatique. Quand les couches web et les API ralentissent, c’est tout l’écosystème de développement qui se fige.

We had a big outage on GitHub Monday, and the root cause is here for transparency's sake. I know this has been posted all over by other Hubbers, but I want to make sure my audience sees it too. https://t.co/j6bZs3W6cH

— Pj Metz (@MetzinAround) August 19, 2026

De tels incidents expliquent l’apparition d’alternatives avec une concentration sur l’affranchissement à la dépendance de la centralisation

La plupart des projets open-source sont généralement hébergés sur GitHub ou d’autres alternatives comme GitLab. Bien que ces plateformes offrent de nombreux avantages et fonctionnalités (sans parler de la visibilité potentielle), elles présentent également des inconvénients comme ceux qui font surface avec cette récente panne sur GitHub. Par exemple, le projet youtube-dl a été retiré par Microsoft suite à une demande de retrait DMCA. Avec une approche centralisée, les équipes de développement n’ont pas de contrôle total sur leur projet.

C’est là qu’entrent en jeu des projets open source comme Radicle. C’est une alternative pair-à-pair (P2P) à GitHub construite sur Git. Radicle utilise un réseau décentralisé où les données sont stockées et répliquées directement sur les machines des utilisateurs.

Bien que Git soit conçu d’une manière ou d’une autre pour les interactions peer-to-peer, aucun déploiement ne fonctionne de cette façon. Tous les déploiements utilisent le modèle client-serveur car Git ne dispose pas de fonctionnalités permettant d'être déployé tel quel dans un réseau peer-to-peer. De plus, difficile de vérifier que le référentiel que vous avez téléchargé après un « clone git » est celui que vous avez demandé, ce qui signifie que vous devez cloner à partir d'une source fiable (c'est-à-dire un serveur connu). Une situation difficilement compatible avec P2P.

Radicle résout ce problème en attribuant des identités stables aux référentiels qui peuvent être vérifiés localement, permettant ainsi aux référentiels d'être servis par des parties non fiables.


En gros, Radicle favorise la collaboration sans intermédiaires entre les équipes de développement informatique tandis que GitHub nécessite une plateforme centralisée pour la collaboration. En l'utilisant, les développeurs n'auraient pas subi la panne de GitHub (qui a bloqué les Pull Requests et les API pendant des heures), grâce à une architecture sans point de défaillance unique.

Même sans connexion Internet active ou en cas de panne mondiale d'un hébergeur, vous pouvez continuer à créer des branches, valider du code et rédiger des correctifs localement. Dès que la connexion au réseau P2P est rétablie, vos modifications se propagent naturellement auprès des autres développeurs.

Et vous ?

Comment avez-vous vécu la panne mondiale sur GitHub en tant que développeur informatique ? Quelles sont les dispositions que votre entreprise a prises ? Partagez vos anecdotes
Pensez-vous que les projets open-source devraient explorer davantage les alternatives peer-to-peer comme Radicle ? Pourquoi ou pourquoi pas ?
Avez-vous déjà utilisé Radicle ou envisagez-vous de l’essayer pour vos projets ?