Le 17 août 2026, GitHub — la plateforme où vit le code d'une bonne partie des logiciels du monde — est resté 7 heures et 47 minutes hors service. Ce n'était ni une attaque, ni un virus, ni quelqu'un qui a supprimé le mauvais fichier. C'était un manque de capacité : le trafic a atteint un nouveau pic et un composant critique n'a pas suivi.
Si votre entreprise n'écrit pas de logiciels, la nouvelle semble lointaine. Elle ne l'est pas. Ce qui s'est passé là arrive, à plus petite échelle, avec le logiciel de gestion que vous payez, avec le terminal de paiement, avec le serveur de messagerie et avec votre boutique en ligne. La question à laquelle ce texte répond est simple : que fait votre entreprise pendant les heures où le système dont elle dépend n'est pas là ?
Ce qui est arrivé à GitHub
La panne a commencé à 13h28 et s'est terminée à 21h15 (heure UTC), d'après le rapport publié par l'entreprise elle-même. Le site, l'authentification, GitHub Actions, les API, les pull requests, les issues et Copilot sont tombés. Au pic, environ 20 % des requêtes web et API échouaient, et les téléchargements d'archives et de contenu brut ont atteint 50 % d'erreurs.
Traduit pour qui n'est pas du métier : pendant près de huit heures, une grande partie des équipes techniques du monde n'a rien pu publier. Qui avait une livraison prévue ce jour-là n'a pas livré.
La cause n'était ni une attaque ni un bug — c'était la croissance
C'est la partie qui intéresse le plus les décideurs. Le rapport de GitHub pointe une saturation réseau sur les répartiteurs de charge du centre de données du centre des États-Unis, provoquée par un nouveau pic de trafic. Il n'y a eu ni changement de code ni erreur de configuration : la demande a dépassé ce que l'infrastructure supportait.
Les chiffres expliquent l'ampleur. Depuis avril, les commits mensuels sur la plateforme sont passés de 1,4 milliard à 2,9 milliards. Les pull requests fusionnées ont atteint environ 130 millions par mois et les nouveaux dépôts, 24 millions par mois. L'entreprise dit avoir ajouté plus de 3 millions de cœurs de calcul et 120 pétaoctets de stockage rapide, en plus de servir désormais environ 58 % de la charge via l'infrastructure Azure.
Autrement dit : le succès du produit a été la cause de la panne. C'est le type de risque que personne ne met dans le tableur, parce qu'il ne ressemble pas à un problème : il ressemble à une bonne nouvelle. Cela vaut pour une plateforme mondiale et cela vaut pour votre entreprise le jour où la campagne marche et où le site reçoit dix fois plus de monde que d'habitude.
Le détail le plus instructif : la relance automatique
Quand un système tombe, les programmes qui en dépendent réessaient souvent tout seuls. Cela paraît raisonnable — et, fait sans précaution, c'est ce qui transforme une panne en panne longue. Dans le cas de GitHub, le rapport est explicite : les erreurs ont déclenché une boucle de relances côté clients qui a augmenté le trafic pendant la reprise et retardé le retour de Copilot.
Notez l'ordre : la relance automatique n'a pas causé la panne, mais elle a gêné la sortie de panne. C'est un détail technique aux conséquences directes pour toute entreprise qui a des intégrations — facturation, encaissement, envoi de messages, synchronisation avec une place de marché. La question à poser à votre prestataire est : quand l'appel échoue, réessaie-t-il tout de suite, et combien de fois ? La bonne réponse est d'attendre un peu plus à chaque tentative et d'abandonner après quelques-unes — pas de marteler.
Avant le plan B, la question que presque personne ne pose
La conversation sur l'indisponibilité commence presque toujours du mauvais côté, par la technique. Elle devrait commencer par le calcul : combien coûte une heure d'arrêt, pour chaque partie de votre activité ?
Pour une boutique en ligne, c'est le chiffre d'affaires moyen de l'heure, plus les clients qui ne reviennent pas. Pour un cabinet, c'est l'agenda du jour. Pour une industrie, cela peut être presque rien pendant quelques heures — et catastrophique si cela tombe sur la clôture du mois. Sans ce chiffre, toute discussion sur la redondance devient une préférence personnelle, et la décision finit par être prise par la peur du dernier incident.
La conclusion dérange souvent : la plupart des systèmes d'une entreprise ne méritent pas de plan B. Deux ou trois le méritent, et c'est là que l'argent doit aller.
Les quatre niveaux de plan B
Du moins cher au plus cher. Choisissez le niveau selon le coût de l'heure d'arrêt que vous venez de calculer.
1. L'alerte. Savoir que c'est tombé avant que le client ne vous le dise. C'est le niveau le moins cher de tous et le plus ignoré : une vérification automatique toutes les quelques minutes qui envoie un message quand le service ne répond pas. Sans cela, votre temps d'arrêt commence à courir quand quelqu'un se plaint.
2. Le mode manuel. La consigne écrite de la façon dont l'équipe travaille sans le système : noter la commande sur papier, photographier le bon, saisir plus tard. Cela coûte une feuille et une conversation, et c'est ce qui sauve l'exploitation dans la plupart des pannes courtes.
3. La solution froide. Une seconde copie de ce qui compte, indépendante du prestataire principal : la liste clients exportée chaque semaine, les factures conservées hors du système, le fichier que vous pouvez ouvrir seul. Cela ne remplace pas le système — cela évite que la panne devienne une perte.
4. La redondance chaude. Un second chemin prêt à prendre le relais. C'est le seul niveau qui supprime vraiment l'arrêt, et il coûte cher : on paie une capacité inutilisée presque tout le temps. Il ne se justifie que lorsque l'heure d'arrêt coûte plus que l'abonnement du second chemin.
Ce que nous avons appris en faisant tomber notre propre système
Deux histoires de chez nous, parce que la théorie de la continuité est facile à écrire et difficile à pratiquer.
La première : le 2 août, notre plateforme de réalité augmentée est restée hors service environ quatre minutes. La cause était une commande mal écrite qui a vidé un fichier du serveur. Ce qui a raccourci la panne n'était aucune technologie sophistiquée — c'était d'avoir gardé une copie du fichier avant de le remplacer et d'avoir configuré le service pour redémarrer seul quand il meurt.
La seconde est pire, et c'est la plus instructive. Nous avons créé un script qui récupère les contacts envoyés par le formulaire du site et les envoie par e-mail — et nous avons oublié de le programmer. Rien n'est tombé. Aucun écran d'erreur, aucune alarme, le site répondant normalement. Les contacts restaient simplement en file d'attente, attendant un programme qui ne s'exécutait jamais.
La panne qui fait peur est celle qui met le site à terre. Celle qui coûte de l'argent est la panne silencieuse. C'est pourquoi le niveau 1 de la liste ci-dessus n'est pas « surveiller si le site est debout », mais « surveiller si ce qui rapporte se produit » : la commande arrive, l'e-mail part, la facture est émise.
Comment décider, en quatre questions
Emportez ceci à la prochaine conversation avec qui s'occupe de votre technique :
1. Quels sont les deux ou trois systèmes sans lesquels l'activité s'arrête aujourd'hui ? 2. Combien coûte une heure sans chacun d'eux ? 3. Comment suis-je averti que c'est tombé — et en combien de temps ? 4. Existe-t-il une consigne écrite pour travailler sans lui, que quelqu'un d'autre que le dirigeant a déjà lue ?
Si la quatrième question n'a pas de réponse, c'est par elle qu'on commence : c'est la moins chère des quatre et celle qui réduit le plus les dégâts.
Quand la réponse passe par un système fait sur mesure — parce que le standard ne suffit pas pour votre processus, ou parce que dépendre d'un seul prestataire est devenu un risque trop grand —, c'est notre métier : développement de logiciels sur mesure. Et si le doute porte encore sur le choix entre un logiciel standard et un développement, nous avons écrit sur comment choisir entre logiciel sur mesure et solution toute faite.
Sources
Rapport officiel de GitHub sur la panne du 17 août 2026 (« The August 17 outage, and the work ahead »), publié sur le blog de l'entreprise. Les chiffres de durée, services touchés, taux d'erreur, volume de commits et capacité ajoutée en proviennent.
Questions fréquentes
Combien de temps mon système peut-il rester hors service sans dommage ?
Il n'existe pas de chiffre universel — cela dépend de ce que coûte une heure d'arrêt dans votre activité. La méthode est de le calculer par système : chiffre d'affaires horaire moyen pour une boutique, agenda du jour pour un cabinet, risque de clôture mensuelle pour une usine. Ce chiffre détermine combien il vaut la peine de dépenser pour réduire l'arrêt.
Sauvegarde et plan B, est-ce la même chose ?
Non. La sauvegarde conserve les données et sert à ne pas perdre ce que vous aviez déjà. Le plan B, c'est la façon dont l'activité continue tant que le système n'est pas revenu. On peut avoir une sauvegarde parfaite et rester malgré tout huit heures sans servir personne.
Qu'est-ce qu'une page de statut et pourquoi est-elle importante ?
C'est la page où le prestataire publie si son service fonctionne. Elle compte parce qu'elle raccourcit le délai entre la panne et votre décision : au lieu de passer une demi-heure à croire que le problème vient de chez vous, vous confirmez en une minute qu'il vient du prestataire et vous activez le mode manuel.
Un logiciel standard est-il plus sûr qu'un développement sur mesure ?
Ni plus ni moins — le risque change de place. Avec le standard, vous dépendez de la capacité et des priorités du prestataire, et sa panne est votre panne. Avec le sur-mesure, vous maîtrisez l'infrastructure et l'ordre des réparations, mais il vous faut quelqu'un qui en soit responsable. Le choix dépend de celui des deux risques que votre entreprise gère le mieux.
Comment savoir si mes intégrations relancent les appels de la mauvaise façon ?
Posez trois questions à qui s'occupe du système : combien de fois un appel en échec est relancé, si le délai entre les tentatives augmente à chaque fois, et s'il existe une limite après laquelle il abandonne et enregistre l'erreur. Une relance immédiate et sans limite est le schéma qui transforme une panne courte en panne longue.
Faut-il payer pour de la redondance ?
Seulement quand l'heure d'arrêt coûte plus cher que le second chemin inutilisé. Pour la plupart des PME, les trois premiers niveaux — alerte, mode manuel et solution froide — règlent l'essentiel du problème pour une fraction du prix, et c'est par là qu'il est logique de commencer.