Cursor a lancé Origin, sa propre plateforme d’hébergement de code. Quelques heures plus tard, GitHub subissait une panne majeure affectant dépôts, pull requests, API, Actions, authentification et Copilot.
Une coïncidence presque trop parfaite pour Cursor, qui veut précisément convaincre les développeurs qu’à l’ère des agents IA, le forge logiciel doit lui aussi être repensé.
Cursor lance Origin, puis GitHub tombe en panne
Le timing aurait difficilement pu être meilleur. Dans la matinée du 17 août, Cursor a commencé à déployer Origin, sa nouvelle plateforme capable d’héberger directement des dépôts Git. Quelques heures plus tard, GitHub rencontrait l’un de ses incidents les plus importants de ces dernières semaines. La chronologie mérite d’être précisée, car elle a rapidement été inversée sur les réseaux sociaux : Cursor n’a pas lancé Origin en réaction à la panne.
Le produit était déjà disponible.
Matt Palmer, qui travaille chez Cursor, s’est d’ailleurs amusé de la situation en expliquant que l’entreprise aurait voulu lancer plus tôt, mais que GitHub était en panne. Une plaisanterie, pas l’explication du calendrier.
Les grands lancements logiciels sont préparés bien avant leur publication. Rien ne suggère que Cursor ait pu prévoir ou exploiter volontairement l’incident. Mais, en matière de communication, la coïncidence est exceptionnelle.
La panne GitHub a été particulièrement étendue
L’incident GitHub a commencé officiellement à 13 h 40 le 17 août. À son pic, GitHub annonçait environ 20 % d’erreurs sur ses interfaces Web et son trafic API, tandis que les téléchargements d’archives et de fichiers bruts atteignaient approximativement 50 % d’échecs. Les Pull Requests, Issues, Actions, Webhooks, Git Operations et Pages ont tous été affectés à différents moments.
Les services d’identité destinés aux entreprises ont également rencontré des difficultés, notamment SAML, OIDC, SCIM et Team Sync.
Même GitHub Copilot a subi une dégradation.
La majorité des services principaux avait retrouvé un fonctionnement normal autour de 16 h 59 UTC, mais des problèmes résiduels d’authentification, notamment autour de Copilot, ont continué plusieurs heures.
GitHub n’a déclaré l’incident entièrement résolu qu’à 21 h 15 UTC, soit environ sept heures et demie après son début. Pour des milliers d’équipes, l’impact dépassait donc largement une simple page Web inaccessible.
Origin arrive précisément là où GitHub paraît vulnérable
Cursor Origin propose pour l’instant les briques fondamentales d’une forge logicielle. Création et hébergement de dépôts, navigation dans le code, recherche, pull requests, commentaires, branches, clonage, push et pull via Git. Mais, la décision la plus importante de Cursor est probablement de ne pas exiger une migration complète depuis GitHub.
Origin peut fonctionner comme un hébergeur indépendant, mais il peut également créer un miroir d’un dépôt GitHub existant. Cette distinction change complètement le risque d’adoption.
Cursor ne demande pas encore de quitter GitHub
Lorsqu’un dépôt GitHub est synchronisé avec Origin, GitHub reste la source de vérité. Le dépôt est copié dans Origin afin que Cursor puisse proposer sa navigation, sa recherche, ses agents et ses outils de revue. Cependant, les modifications continuent à être synchronisées avec GitHub. Les pushes effectués sur un dépôt miroir repartent vers GitHub, les pull requests se synchronisent également dans les deux sens, un commentaire publié dans Cursor peut apparaître sur GitHub quelques secondes plus tard, et inversement. Pour une équipe informatique, c’est un choix architectural particulièrement habile.
Migrer des centaines de dépôts, leurs permissions et toute la chaîne CI/CD vers une nouvelle plateforme est un projet risqué. Tester une couche supplémentaire au-dessus de GitHub l’est beaucoup moins.
C’est probablement la véritable stratégie d’Origin
Cursor n’a pas besoin de convaincre immédiatement un CTO de remplacer GitHub. Il lui suffit de convaincre les développeurs de passer davantage de temps dans Cursor. Au départ, GitHub peut rester derrière, es dépôts sont toujours là, les workflows restent là et les droits restent largement liés à l’organisation existante. Mais progressivement, les développeurs peuvent effectuer leurs recherches, leurs reviews, leurs commentaires et leurs interactions avec les agents depuis Origin.
C’est ainsi que l’interface devient potentiellement plus stratégique que le stockage lui-même.
Si Cursor contrôle l’endroit où les développeurs passent leur journée, GitHub peut rester la base technique tout en devenant moins visible. Et lorsqu’une plateforme devient invisible, la remplacer devient beaucoup plus facile.
Depot, Buildkite et Vercel évitent de reconstruire toute la chaîne
Cursor a également anticipé l’une des objections les plus importantes : l’intégration avec les outils existants. Origin prend déjà en charge des applications comme Depot, Buildkite et Vercel. Depot et Buildkite peuvent exécuter des workflows GitHub Actions existants, tandis que Buildkite conserve également ses propres pipelines natifs, tandis que Vercel peut générer des environnements de prévisualisation pour les pull requests.
L’objectif est clair : Origin ne veut pas forcer une équipe à reconstruire toute son infrastructure DevOps dès le premier jour. Le produit se glisse dans une chaîne existante. C’est probablement indispensable pour qu’une bêta aussi jeune puisse être testée sérieusement en entreprise.
Origin n’est pourtant pas simplement un clone de GitHub
Cursor parle depuis plusieurs mois d’un « git forge for the agentic era ». La formule pourrait sembler marketing, mais elle traduit une vraie évolution du développement logiciel. Un forge traditionnel a été conçu autour d’un principe simple : les humains écrivent du code, ouvrent des pull requests, expliquent leurs intentions et attendent que d’autres humains les relisent.
Les agents IA commencent à casser ce modèle. Ils peuvent travailler en parallèle, créer plusieurs branches, corriger des bugs, faire tourner des tests, ouvrir leurs propres PR, répondre aux commentaires, et recommencer continuellement.
À mesure que leur volume augmente, l’interface conçue pour quelques contributions humaines quotidiennes commence à devenir moins naturelle.
GitHub travaille évidemment sur exactement le même sujet
Cursor n’est pas seul à avoir compris cette évolution. GitHub développe lui aussi Copilot Coding Agent, Copilot Code Review et différentes fonctions permettant aux agents de travailler directement depuis sa plateforme. Microsoft possède donc un avantage gigantesque : GitHub est déjà l’infrastructure centrale d’une immense partie du développement logiciel mondial.
Cursor doit convaincre les équipes de déplacer une partie de leur workflow. GitHub doit simplement moderniser celui qu’elles utilisent déjà. En revanche, cette position dominante devient problématique lorsque la fiabilité se dégrade.
Et c’est ici que la panne du 17 août prend une importance stratégique.
GitHub traverse une véritable période de fragilité
L’incident de lundi n’est pas isolé. GitHub a lui-même reconnu en mars 2026 ne pas avoir atteint ses propres standards de disponibilité. L’entreprise explique faire face à une croissance particulièrement rapide de l’utilisation de sa plateforme, révélant des limites d’échelle et des dépendances architecturales capables de transformer des problèmes localisés en incidents plus larges.
Les chiffres publiés par GitHub sont éloquents.
En avril, la plateforme a recensé dix incidents ayant entraîné une dégradation. En mai : neuf. En juin : six. En juillet : huit. Début août, GitHub Actions a encore subi une panne particulièrement longue, avec jusqu’à 71 % des workflows affectés par des défaillances d’infrastructure au pic de l’incident. GitHub ne cache donc plus le problème.
Sa priorité affichée est désormais claire : disponibilité, puis capacité, puis nouvelles fonctionnalités.
Cursor n’a pas besoin que GitHub disparaisse
C’est là toute l’élégance de la stratégie Origin. Cursor n’a pas besoin de démontrer que GitHub est condamné. Il lui suffit de rendre crédible l’idée qu’un développeur puisse vouloir une deuxième couche. Si GitHub fonctionne, Origin reste synchronisé. Si GitHub connaît des problèmes, la copie hébergée dans Origin peut continuer à offrir une partie des fonctions de navigation et de contexte.
Si les agents deviennent plus importants, Cursor contrôle directement l’environnement dans lequel ils travaillent. L’entreprise peut donc progresser sans provoquer immédiatement une confrontation frontale. Au moins dans un premier temps.
Mais héberger le code change complètement la responsabilité de Cursor
C’est également là que commencent les questions les plus importantes. Un éditeur IA peut être expérimental. Un hébergeur de code beaucoup moins. Dès qu’une entreprise décide de stocker la propriété intellectuelle de ses clients, elle doit répondre à des questions beaucoup plus lourdes : résidence des données, sauvegardes, conservation, contrôle d’accès, chiffrement, reprise après incident et sortie du service.
Cursor possède déjà une documentation importante sur son Privacy Mode et sa gouvernance des données pour les fonctions IA.
Pour Origin spécifiquement, la documentation reste cependant encore relativement légère — ce qui est compréhensible pour une bêta très récente, mais insuffisant pour certaines organisations fortement réglementées.
Le rachat par SpaceX ajoute une dimension supplémentaire
Le calendrier devient encore plus intéressant lorsqu’on regarde la situation capitalistique de Cursor. Le 14 août 2026, soit seulement trois jours avant le lancement d’Origin, Cursor a officiellement finalisé son acquisition par SpaceX. La transaction, évaluée à environ 60 milliards de dollars, rapproche davantage Cursor de l’infrastructure IA développée autour de SpaceX et de xAI.
Cursor explique notamment que cette intégration lui donnera accès à une capacité GPU beaucoup plus importante pour entraîner et exécuter ses modèles.
Pour Origin, cette nouvelle propriété ajoute néanmoins une question stratégique.
Une même organisation peut désormais se rapprocher du contrôle de plusieurs couches essentielles : modèles IA, infrastructure de calcul, environnement de développement et désormais hébergement du code.
Pour certaines entreprises, cette intégration représentera un avantage.
Pour d’autres, elle justifiera une analyse plus stricte de dépendance fournisseur.
La sécurité reste également un sujet à surveiller
Cursor a aussi connu récemment une controverse autour d’une vulnérabilité Windows liée à la manière dont l’éditeur résolvait l’exécutable Git.
Des chercheurs de Mindgard avaient montré qu’un fichier malveillant nommé git.exe, placé à la racine d’un dépôt, pouvait être exécuté automatiquement lorsque le projet était ouvert sous certaines conditions.
Cursor avait initialement estimé que le problème se situait hors du périmètre de son programme de bug bounty, invoquant un modèle de responsabilité partagée et recommandant notamment Workspace Trust pour les projets non fiables.
Le comportement a ensuite été corrigé fin juillet selon les informations publiées autour du correctif.
L’épisode reste pertinent pour Origin, mais il ne faut plus le présenter comme une faille toujours laissée volontairement ouverte.
Le message est plutôt différent : lorsqu’un outil touche simultanément au code, aux identifiants, aux agents et désormais aux dépôts, ses décisions de sécurité deviennent encore plus critiques.
Origin est encore une bêta, mais l’ambition ne l’est pas
Pour l’instant, GitHub reste infiniment plus complet.
Issues, Actions, Packages, gestion d’entreprise, marketplace, écosystème open source et outils de conformité représentent des années d’investissement qu’Origin ne reproduit pas encore.
Cursor ne prétend d’ailleurs pas le contraire.
La plateforme commence volontairement avec les fondamentaux.
Mais c’est précisément ce qui rend son lancement intéressant.
L’objectif n’est pas de reconstruire GitHub fonctionnalité par fonctionnalité.
L’objectif est de construire un environnement où le dépôt, la pull request et l’agent deviennent trois facettes du même objet.
Si le développement logiciel devient effectivement agentique, cette différence architecturale pourrait devenir beaucoup plus importante qu’elle ne paraît aujourd’hui.
GitHub lui a offert involontairement la meilleure démonstration possible
Cursor aurait pu consacrer des mois à expliquer pourquoi une alternative ou un complément à GitHub pouvait être utile.
GitHub l’a involontairement démontré en quelques heures.
Cela ne signifie pas que les entreprises vont migrer leurs dépôts demain matin.
Cela signifie qu’Origin vient de devenir beaucoup plus facile à tester.
Et c’est exactement ce dont une nouvelle infrastructure a besoin.
Cursor a réduit le coût psychologique de l’adoption en permettant à GitHub de rester la source principale.
La panne, elle, a augmenté le coût psychologique de ne dépendre que d’un seul service.
Entre les deux se trouve une ouverture commerciale particulièrement intéressante.
Origin est encore trop jeune pour être décrit comme le remplaçant de GitHub.
Mais pour Cursor, ce n’est probablement pas nécessaire.
Le véritable objectif est peut-être simplement de devenir l’endroit où les développeurs et leurs agents travaillent avant même de se demander où leur code est réellement hébergé.
Et si cette habitude s’installe, la bataille avec GitHub aura déjà commencé.
