Cursor a commencé à déployer Origin, sa propre plateforme d'hébergement de code, auprès des offres payantes le lundi 17 août 2026. On y retrouve ce pour quoi vous utilisez GitHub : dépôts, demandes de fusion, navigation et relecture de code, avec les agents Cursor intégrés et une synchronisation GitHub qui évite d'avoir à déménager quoi que ce soit. Environ trois heures et demie après le début du déploiement, GitHub est entré dans une dégradation mondiale de six heures quarante deux, son septième incident en quinze jours. Le calendrier relève du hasard. La question de fond, non, et elle mérite réflexion avant de synchroniser un dépôt où que ce soit.
The short answer
Cursor a commencé à déployer Origin sur les offres payantes le lundi 17 août 2026. La plateforme arrive avec dépôts, demandes de fusion, navigation de code, synchronisation GitHub bidirectionnelle et agents Cursor, et les workflows GitHub Actions existants tournent sans modification. Les intégrations Vercel, Depot et Buildkite sont disponibles. Environ trois heures et demie après le début du déploiement, GitHub est entré dans une dégradation mondiale de six heures quarante deux, son septième incident en quinze jours. Une coïncidence, mais c'est ce qui a fait remarquer le lancement.
Construire un hébergeur de code en 2026 est une drôle d'idée. La catégorie est réglée depuis dix ans, l'acteur dominant revendique environ cent quatre vingts millions d'utilisateurs, et personne ne se lève le matin avec l'envie de migrer ses dépôts. Cursor l'a fait quand même, et son argument est plus intéressant que le lancement.
Ce qui est livré
Origin a commencé son déploiement le lundi 17 août 2026, en bêta précoce, sur toutes les offres payantes de Cursor. Les organisations d'entreprise sont incluses, sauf désinscription de leurs administrateurs. Cursor avait présenté Origin en juin et évoqué une sortie plus large plus tard dans l'année : la bêta arrive donc avant ce calendrier.
Le périmètre fonctionnel est le coeur attendu d'un hébergeur de code. Dépôts, demandes de fusion, navigation et relecture, et accès aux agents Cursor sur un projet entier plutôt que sur un seul fichier ouvert. Le tout vit dans un nouvel onglet Codebase de l'éditeur, et les dépôts hébergés obtiennent des adresses sous cursor.com/codebase/nom.
Deux décisions de compatibilité comptent plus que n'importe quelle fonctionnalité de cette liste.
La première est la synchronisation GitHub. Vous connectez un compte GitHub et recopiez des dépôts vers Origin, GitHub restant la source de vérité, et les conversations de demandes de fusion se synchronisent dans les deux sens. Cursor le formule ainsi : vos dépôts GitHub peuvent cohabiter avec ceux qu'il héberge. Essayer Origin devient donc presque gratuit, puisque vous ajoutez un miroir au lieu de mener une migration, et vous arrêtez en vous déconnectant.
La seconde, c'est que les workflows GitHub Actions existants tournent sans modification, avec les intégrations Vercel, Depot et Buildkite disponibles dès le premier jour. C'est la décision qui sépare une tentative sérieuse d'une démonstration. L'intégration continue est l'endroit où meurent normalement les migrations d'hébergeur, car les chaînes accumulent des années de dépendances discrètes à la plateforme sur laquelle elles ont grandi, et les réécrire est un chantier que personne ne budgète. Accepter Actions tel quel évite de commencer l'essai par ce travail.
L'argument, qui porte sur les agents
Cursor décrit Origin comme de l'hébergement Git à l'échelle des agents, et la formule fait un vrai travail. C'est une affirmation sur un changement de trafic, pas une liste de fonctions.
Git et les workflows empilés par dessus ont été pensés pour des humains. Une personne ouvre une branche, pousse quelques commits sur un jour ou deux, ouvre une demande de fusion, et attend qu'une autre personne la lise. La capacité de relecture est la ressource rare, et toutes les conventions du workflow moderne le supposent.
Les agents de code cassent ces hypothèses de façon facilement observable si vous en faites déjà tourner. Les branches se multiplient, puisqu'en créer une ne coûte rien. Les demandes de fusion deviennent plus petites et bien plus nombreuses. Les fusions arrivent par rafales plutôt qu'étalées sur une journée de travail. La file qui était limitée par la vitesse d'écriture du code est désormais limitée par la vitesse de lecture, ce qui est un autre goulot d'étranglement, avec d'autres remèdes.
Savoir si un hébergeur conçu pour ce schéma se comporte nettement mieux qu'un hébergeur adapté après coup est exactement la question à laquelle Origin doit répondre, et une bêta aux détails rares n'y répond pas. Cursor annonce des fonctions pensées pour les agents sans dire lesquelles. Traitez ce cadrage comme une hypothèse à surveiller, pas comme un avantage livré.
La question de la fiabilité, traitée honnêtement
Le lancement est entré en collision avec une panne GitHub, et il faut séparer la collision du fond.
Cursor a lancé le déploiement le lundi matin. Environ trois heures et demie plus tard, GitHub est entré dans une dégradation de six heures quarante deux, avec un taux d'erreur d'environ vingt pour cent, son septième incident en quinze jours. Un employé de Cursor en a tiré la meilleure phrase du jour, expliquant qu'ils auraient livré plus tôt mais que GitHub était tombé. C'était de la chance, pas de la préparation.
La tentation est d'y lire un argument de fiabilité en faveur du changement, et ce n'en est pas un. Une plateforme en bêta précoce n'a aucun historique de disponibilité, ce qui est une position plus faible qu'une plateforme traversant une mauvaise quinzaine. Une comparaison honnête demande des mois de données, un historique d'état publié et un vrai processus de gestion d'incident des deux côtés. Le risque de dépendance unique est une vraie préoccupation d'ingénierie, mais la réponse n'est pas d'échanger une dépendance unique contre une plus récente.
Il existe une réponse moins chère, et c'est l'un des rares avantages que Git vous donne encore gratuitement. Un dépôt Git est distribué par conception, donc recopier vers un second hébergeur relève du réglage et non de la migration. Poussez vers deux dépôts distants, gardez votre définition d'intégration continue portable quand c'est raisonnable, et la question de la panne devient une gêne plutôt qu'un arrêt. Cela vaut que le second dépôt distant soit Origin, un serveur auto hébergé ou un tout autre fournisseur.
Ce que nous ferions
Synchroniser un dépôt à faible enjeu et l'utiliser une semaine, parce que le coût de l'essai est réellement faible et que relire vos propres diffs dans une autre interface vous apprend plus que n'importe quelle annonce.
Garder GitHub comme source de vérité pendant ce temps, ce qui est le comportement par défaut et le bon. Avant d'activer quoi que ce soit sur du sensible, vérifiez ce que la synchronisation bidirectionnelle réécrit dans vos conversations de demandes de fusion GitHub, qui peut l'activer dans votre organisation, et si vos administrateurs se sont déjà désinscrits. Tout ce qui appelle directement l'API GitHub, ou dépend de permissions ou de réglages de dépôt spécifiques, se vérifie à part, puisque faire tourner Actions sans modification ne couvre pas ces cas.
Ensuite, attendre. L'hébergement de code est une infrastructure, et une infrastructure gagne la confiance par des mois ennuyeux plutôt que par une belle journée de lancement.
Sources et pour aller plus loin
- Cursor capitalizes on GitHub frustration, launches rival hosting platform, TechCrunch, 18 août 2026
- Cursor launches Origin code hosting platform as GitHub outage exposes opening in AI coding race, VentureBeat, août 2026
- Cursor begins Origin code hosting rollout for paid plans, TestingCatalog, 17 août 2026
- Cursor launches Origin, a code hosting platform built for AI coding agents with GitHub sync, Tech Startups, 17 août 2026
Questions fréquentes
Qu'est ce que Cursor Origin et qui peut l'utiliser ?
Origin est une plateforme d'hébergement de code construite par Cursor, déployée en bêta précoce depuis le lundi 17 août 2026 sur toutes les offres payantes de Cursor, sauf dans les organisations d'entreprise dont les administrateurs se désinscrivent. Elle couvre le coeur du métier : dépôts, demandes de fusion, navigation et relecture de code, plus un accès direct aux agents Cursor sur l'ensemble d'un projet. Elle vit dans un onglet Codebase de l'éditeur, et les dépôts obtiennent des adresses de la forme cursor.com/codebase/nom. Cursor l'avait présentée en juin 2026 en annonçant une sortie plus large dans l'année : cette bêta arrive donc en avance.
Faut il quitter GitHub pour l'essayer ?
Non, et c'est un choix de conception délibéré. Vous pouvez synchroniser des dépôts GitHub existants vers Origin, GitHub restant la source de vérité, et les conversations de demandes de fusion se synchronisent dans les deux sens. La formulation de Cursor est que vos dépôts GitHub peuvent cohabiter avec ceux qu'il héberge. En pratique, le coût de l'essai est faible, car un dépôt synchronisé est un miroir et non une migration. Cela signifie aussi que les questions habituelles s'appliquent avant d'activer la chose sur quoi que ce soit de sensible : ce que la synchronisation réécrit, qui peut l'activer chez vous, et si vos administrateurs se sont désinscrits.
Est ce que mon intégration continue fonctionne toujours ?
Les workflows GitHub Actions existants tournent sans modification, et c'est l'affirmation de compatibilité la plus importante de ce lancement. Les intégrations Vercel, Depot et Buildkite sont livrées dès le premier jour, d'autres sont promises. L'intégration continue est d'ordinaire la raison pour laquelle une migration d'hébergeur de code s'enlise, car les chaînes accumulent des années de dépendances implicites à la plateforme pour laquelle elles ont été écrites. Garder Actions fonctionnel supprime ce blocage pour un essai. Cela ne le supprime pas pour une migration complète, puisque tout ce qui touche à l'API GitHub, aux permissions spécifiques ou aux réglages de dépôt reste à vérifier.
Que veut dire concrètement l'échelle des agents ?
C'est le cadrage de Cursor pour un changement de charge, pas une liste de fonctionnalités. Quand des agents de code committent, créent des branches, ouvrent des demandes de fusion et fusionnent à la vitesse machine, le volume et la forme du trafic Git cessent de ressembler à du trafic humain. Vous obtenez beaucoup plus de branches, beaucoup plus de petites demandes de fusion, et des files de relecture qui ne correspondent plus à un rythme humain. Cursor soutient qu'un hébergeur conçu pour ce schéma se comporte autrement qu'un hébergeur conçu pour des humains qui cliquent sur fusionner. L'argument se tient sur le principe. Les détails restent minces, et une bêta ne prouve rien dans un sens ou dans l'autre.
La panne de GitHub avait elle un lien avec le lancement ?
Non. Le déploiement a commencé le lundi matin et la dégradation de GitHub a démarré environ trois heures et demie plus tard : l'enchaînement relève de la coïncidence, pas de la cause. C'est le contexte qui rend la chose notable. Cet incident a duré six heures quarante deux et constituait le septième de GitHub en quinze jours, d'où le débat sur la disponibilité. Une quinzaine difficile ne fait pas une tendance, et une plateforme en bêta précoce n'a aucun historique de disponibilité auquel se comparer. Jugez un nouvel hébergeur sur des mois de fonctionnement, pas sur la semaine de son lancement.