Panne GitHub d'août 2026 : 2,9 milliards de contributions de code par mois

GitHub est resté indisponible presque huit heures le 17 août 2026 et a publié, trois jours plus tard, le chiffre qui explique la panne : le volume de code déposé chaque mois a doublé depuis avril. Ce que cette vague change pour qui fait construire un logiciel.

La panne GitHub d'août 2026 a duré 7 heures et 47 minutes, le 17 août. Dans son explication du 20 août 2026, GitHub écarte tout changement de code et décrit une saturation de capacité, chiffre à l'appui : les contributions de code mensuelles sont passées de 1,4 milliard en avril à 2,9 milliards.

Ce qui s'est arrêté ce jour là

L'interruption n'a pas touché qu'une page web. Elle a emporté la connexion aux comptes, les chaînes d'automatisation qui construisent et testent les logiciels, les interfaces machine, les demandes de fusion et les tickets, ainsi que l'assistant de code de la maison. Pour une équipe dont la journée de travail passe par cette plateforme, la journée s'est arrêtée. C'était le deuxième incident notable du mois, après une défaillance des chaînes d'automatisation le 6 août, et aucun des deux ne venait d'une modification apportée par GitHub.

Le doublement, et ce qu'il raconte

Un volume de dépôts de code qui double depuis avril ne s'explique pas par une vague d'embauches. GitHub ne nomme pas la cause de cette croissance ; la période coïncide avec la mise en circulation par l'IA d'un code écrit vite, en quantité, par des gens qui n'en écrivaient pas il y a deux ans. La plateforme qui reçoit tout cela a plié sous le poids avant que quiconque ne s'en inquiète. Le chiffre est aussi un avertissement de qualité : produire plus de code n'a jamais voulu dire produire plus de logiciel utile, et personne n'a doublé le temps de relecture dans le même mouvement.

Ce que perd un dirigeant quand la plateforme tombe

Si le seul exemplaire de votre produit vit sur un service distant, votre produit s'arrête quand ce service s'arrête. La panne emporte le travail en cours, mais aussi l'historique de vos versions, la possibilité de revenir à celle d'avant-hier, et le déploiement de la correction urgente que vous vouliez publier ce matin. Deux pannes à un jour d'écart en août 2026, l'une chez GitHub le 17 et l'autre chez un fournisseur d'IA le 16, ont rappelé à tout le monde combien de maillons distants tient une journée de travail ordinaire.

La copie locale, et ce qu'elle ne remplace pas

Chez Maestro, le code et les documents de votre produit vivent sur votre Mac, et l'historique des versions se lit et se restaure depuis votre machine. La sauvegarde en ligne, elle, est facultative et va chez vous, sur votre compte. Le 17 août, elle aurait été bloquée : impossible d'envoyer la copie de sécurité de la journée. Le travail, lui, aurait continué. Nous ne prétendons pas pour autant qu'une copie locale suffit à tout : elle ne protège pas d'un vol d'ordinateur, elle ne remplace pas le travail à plusieurs, et une plateforme distante reste le meilleur endroit pour partager un projet avec un prestataire. Le choix de l'endroit se pose dès le premier jour.

Ce que la vague fait à la relecture

La contrepartie du doublement se lit dans votre propre projet. Plus de code écrit vite signifie plus de code que personne n'a lu, et un dirigeant qui ne lit pas de code se retrouve devant un tas dont il ne peut rien dire. La seule prise reste le document : ce que le produit doit faire, écrit en français, validé par vous avant que la construction commence, et une vérification qui échoue quand le résultat s'en écarte.

Vérifier où vit votre produit, ce soir

Trois vérifications tiennent en un quart d'heure. Ouvrez le dossier de votre produit sur votre machine et regardez s'il contient les fichiers eux-mêmes ou un simple raccourci vers un service. Cherchez la dernière copie de sauvegarde et notez sa date. Enfin, demandez à votre prestataire ou à votre outil ce qui se passe pendant huit heures d'indisponibilité de la plateforme qu'il utilise. Si la réponse est « on attend », vous connaissez le prix de la prochaine panne.