GitHub tombe pendant 3 h et paralyse la planète dev : ton business a-t-il un point unique de défaillance ?

Le 17 août, GitHub — la plateforme sur laquelle 225 millions de développeurs hébergent leur code — est resté cassé plus de trois heures. Pull requests, Actions, Copilot, téléchargements : tout par terre, et des chaînes de production logicielle gelées dans le monde entier. Le rival Cursor en a même profité pour lancer sa plateforme concurrente en plein incident. Tu ne fais pas de code ? Peu importe : la leçon de cette panne vise tout solopreneur.

Ce qui s’est passé

La panne a démarré à 9h40 (heure de l’Est) et s’est propagée en 90 minutes à quasiment tous les services de GitHub, avec jusqu’à 50 % d’erreurs sur certains téléchargements. La récupération n’est intervenue qu’en fin d’après-midi. Détail qui pique : selon une analyse citée, GitHub aurait connu 257 incidents en un an, dont 48 majeurs — soit environ une perturbation sérieuse par semaine.

Le sous-texte, souligné par le lancement opportuniste de Cursor : même l’infrastructure la plus incontournable a un point unique de défaillance. Quand tout un secteur suppose qu’un service « est toujours là », sa panne devient un blocage mondial.

Ce que ça veut dire

Oublie le code et transpose. Chaque business a son maillon dont la panne l’arrête net. Pour un solo, ce n’est pas GitHub — c’est peut-être : un seul outil qui héberge tout ton travail, un seul compte qui encaisse tous tes paiements, une seule plateforme d’où viennent tous tes clients, ou un seul ordinateur sans sauvegarde. Tant que ça marche, on n’y pense pas. Le jour où ça lâche, on découvre qu’on avait tout mis au même endroit.

C’est le pendant concret de ce qu’on répète sur la dépendance à un fournisseur : tu ne contrôles pas les pannes des géants, mais tu contrôles à quel point tu en dépends.

Ce que tu fais lundi matin

Trois réflexes.

Trouve ton point unique de défaillance. Pose-toi la question franchement : « si ça tombe demain, qu’est-ce qui s’arrête chez moi ? » Fais la liste des services, comptes et appareils critiques. Celui dont la panne te met à l’arrêt total, c’est ta priorité.

Mets un filet là où c’est vital. Sauvegarde ton travail à un deuxième endroit (règle simple : ce qui n’existe qu’à un seul exemplaire n’existe pas). Aie un moyen de contacter tes clients hors de la plateforme qui te les amène. Garde une alternative identifiée pour tes outils clés — c’est aussi pour ça qu’il faut rester libre de changer d’outil.

Répartis ce qui est trop concentré. Tous tes revenus via un seul canal ? Toute ton audience sur un seul réseau ? Toute ta compta sur un seul service ? Tu n’as pas à tout dupliquer, mais réduire une concentration dangereuse est un investissement de tranquillité — le fond de tenir en solo dans la durée.

Le piège à éviter

Le piège : croire que « ça n’arrive qu’aux autres ». GitHub, c’est Microsoft derrière — et ça tombe quand même, souvent. Tes outils à toi ne sont pas plus increvables. Compter sur la chance plutôt que sur une sauvegarde, c’est jouer ton activité à pile ou face.

L’autre piège, inverse : la parano qui te fait tout dupliquer. La résilience n’est pas de bâtir un système de secours pour chaque détail — c’est d’identifier les quelques maillons vitaux et de les protéger. Un solo n’a pas besoin d’une infrastructure de multinationale ; il a besoin d’une sauvegarde de son travail, d’un lien direct avec ses clients, et d’un plan B pour ses outils clés. Le bon niveau : pas de point unique dont la panne t’efface — le reste peut attendre.