GitHub a subi une panne mondiale de 6 heures le 18 août 2026. Le même jour, Cursor — désormais propriété de SpaceX — a lancé Origin, sa propre plateforme d’hébergement de code. Ce n’est probablement pas un hasard de calendrier. Ce qui est sûr, c’est que la question que beaucoup de builders évitaient de se poser devient soudainement urgente : GitHub est-il encore l’endroit où tu dois mettre tout ton code ?
Ce qui s’est passé le 18 août
Mardi 18 août, GitHub est tombé pendant plus de 6 heures. Les repos inaccessibles, les actions GitHub bloquées, les déploiements en attente. Pour des milliers de développeurs — y compris des solos qui ont automatisé leurs workflows sur GitHub Actions — c’est plusieurs heures de travail perdues ou gelées.
Quelques heures plus tard, Cursor annonçait Origin, une plateforme d’hébergement de code positionnée directement contre GitHub. Coincidence ou timing délibéré pour capitaliser sur la frustration du moment ? Cursor n’a pas commenté. Mais le résultat est là : le sujet est dans toutes les conversations de devs.
Ce qu’est Origin, concrètement
Origin propose les fonctionnalités de base qu’on attend d’une forge de code : hébergement de repos, gestion de branches, pull requests, collaboration. Rien de révolutionnaire sur le papier.
Ce qui change, c’est l’interopérabilité. Cursor a conçu Origin pour fonctionner à côté de GitHub, pas contre lui. Tes repos GitHub peuvent coexister avec ceux qu’Origin héberge, avec synchronisation bidirectionnelle possible. Traduction : tu peux adopter Origin sans migration forcée, sans couper le fil avec tes projets existants.
La promesse à venir : des fonctionnalités « agent native », pensées pour les workflows où un agent IA écrit, commit et ouvre des PRs de façon autonome. C’est exactement ce que Cursor fait dans son éditeur depuis des mois — l’étendre à la couche hébergement est une extension logique.
257 pannes en un an : le vrai problème de GitHub
La panne du 18 août n’est pas un accident isolé. Selon les données citées dans le contexte du lancement d’Origin, GitHub a enregistré 257 incidents sur les douze derniers mois. C’est plus de 5 pannes par semaine en moyenne — des interruptions qui vont de quelques minutes à plusieurs heures.
Pour une équipe avec un SLA à respecter ou un pipeline CI/CD critique, ces chiffres ont des conséquences réelles. Pour un builder solo qui a tout automatisé sur GitHub Actions — déploiements, génération de contenu, synchro de données — chaque panne est une interruption directe.
GitHub a 180 millions d’utilisateurs et 257 incidents en un an. C’est la définition d’un service trop grand pour migrer, mais trop fragile pour tout lui confier.
Ce que ça change pour toi, builder solo
Soyons honnêtes : tu ne vas probablement pas quitter GitHub demain. 180 millions de développeurs, l’intégration native avec à peu près tout, les GitHub Actions, le social autour des repos publics — c’est impossible à remplacer du jour au lendemain, et Origin ne te demande pas de le faire.
Le vrai changement, c’est que tu as maintenant une raison valable de répartir ta dépendance. Quelques stratégies concrètes :
- Héberger les projets critiques en double : tes repos les plus sensibles (celui qui pilote ton déploiement prod, par exemple) en miroir sur Origin dès qu’il ouvre au public.
- Tester les workflows agent-native : si tu utilises déjà Cursor comme éditeur et que tu as des agents qui committent du code, Origin est l’extension naturelle du même écosystème.
- Ne pas migrer pour migrer : Origin n’a pas encore de track record. La fiabilité se mesure sur des mois. Surveille, ne saute pas.
Ce qui est inédit dans le cas Cursor, c’est que l’outil d’édition et la plateforme d’hébergement parlent le même langage dès le départ. GitHub a été conçu avant l’ère des agents IA. Origin est conçu pour. La question n’est pas « GitHub ou Origin ? » — c’est « dans 18 mois, comment est-ce que tu veux que ton workflow agent-to-code-to-deploy soit câblé ? »
Ma lecture
Cursor a fait quelque chose de rare : lancer un produit concurrent à GitHub sans se positionner en ennemi de GitHub. C’est de la stratégie propre. L’interopérabilité immédiate réduit le coût d’adoption à zéro — et ça, combiné à la frustration réelle autour des pannes GitHub, peut générer une adoption organique que même un lancement fracassant n’aurait pas produit.
Le timing du 18 août ne trompait personne. Mais la question de fond reste valide bien au-delà de cette panne : à mesure que les agents IA deviennent des collaborateurs actifs dans ton code (ils écrivent, ils committent, ils testent), l’infrastructure d’hébergement doit suivre. GitHub est en train de s’adapter. Origin part de zéro avec cette contrainte en tête. Dans un an, on saura lequel des deux a mieux joué.
Pour faire tourner ce type d’agent sur tes propres process, avec surveillance et alertes quand ça casse, voir mes prestations d’automatisation IA.