AIREITERPendant ses deux premiers mois, Cursor Origin se résumait à une promesse et un champ pour saisir son e-mail. Depuis le 17 août 2026, le service est devenu la bêta anticipée de l’hébergement de code de Cursor. Deux réserves sont toutefois essentielles : les dépôts synchronisés depuis GitHub continuent de considérer GitHub comme source de vérité, et le déploiement ne semble pas encore identique pour tous les abonnés payants.
Cursor Origin est-il déjà disponible ?
Oui, Cursor Origin est accessible en bêta anticipée depuis le 17 août 2026 pour les utilisateurs de toutes les formules Cursor payantes. Les organisations Enterprise font exception : d’après le même changelog, leurs administrateurs peuvent désactiver le service. La page produit renvoie elle aussi vers la bêta via son encart « Early beta ».
Dans les faits, l’accès varie encore d’un compte à l’autre. Dans le fil de lancement r/cursor des 17 et 18 août, des clients payants ont signalé un décalage entre l’annonce et ce qu’ils voyaient dans leur compte :
« Je ne vois toujours qu’une inscription sur liste d’attente. » — u/NerdyGuy117, r/cursor
« Je n’y ai pas encore accès avec mon forfait Teams. » — u/Darkoplax, r/cursor
Ces retours pointent vers un déploiement progressif plutôt qu’une ouverture immédiate sur tous les comptes éligibles. Une fois activés, les dépôts Origin apparaissent dans l’onglet Codebase. Si votre formule est compatible mais que rien ne s’affiche, votre compte n’a donc pas encore reçu l’accès à la bêta.
| Date | Événement |
|---|---|
| 16 juin 2026 | Cursor annonce Origin lors de sa conférence Compile : uniquement une page d’attente et une liste d’inscription |
| 17 août 2026 | Lancement de la bêta anticipée : dépôts, PR, navigation dans le code, synchronisation GitHub et agents |
Au moment de l’annonce, un commentateur de r/cursor décrivait la page produit comme « aucune information. Une page d’attente avec un champ e-mail. » (u/One-Poet7900)
Ce que propose concrètement la bêta d’Origin
La bêta met en place quatre grandes capacités, détaillées dans le tableau ci-dessous. Selon le changelog, les dépôts sont regroupés dans le nouvel onglet Codebase de Cursor. Leur nom entre dans leur URL — cursor.com/codebase/acme-corp dans l’exemple de Cursor. Pour en créer un, il faut sélectionner +New, le nommer, installer la CLI, puis le cloner ou y pousser un projet local existant.
Les pull requests affichent la chronologie, les commits, les vérifications et les fichiers modifiés. Il est possible de relire les différences, commenter et fusionner sans quitter l’éditeur. Des icônes distinguent les dépôts hébergés par Cursor de ceux synchronisés depuis GitHub.
| Fonctionnalité | État dans la bêta du 17 août |
|---|---|
| Dépôts hébergés par Cursor | Disponible (onglet Codebase) |
| Pull requests : consulter, commenter, fusionner | Disponible |
| Navigation et recherche dans le code | Disponible |
| Import GitHub avec synchronisation en temps réel | Disponible |
| Agents agissant dans les dépôts | Disponible (premier ensemble de fonctions) |
| Applications Vercel, Depot et Buildkite | Disponible |
| Fonctions natives pour agents au-delà des bases | « Coming », sans date annoncée |
| Pull requests empilées | Non documenté |
| Tarification, limites, SLA | Non publié |
Synchronisation GitHub : ce que fait vraiment Origin
La synchronisation GitHub d’Origin crée un miroir en direct destiné à la consultation, pas une seconde source de vérité. Après avoir connecté GitHub, choisi une organisation et sélectionné les dépôts, Cursor en conserve une copie synchronisée en temps réel. Toute personne disposant d’un accès en lecture ou en écriture au dépôt synchronisé peut le consulter dans Cursor. Il est ensuite possible de déconnecter chaque dépôt depuis ses réglages, selon le changelog.
La communauté Cursor posait déjà cette question avant même la bêta :
« Origin remplace-t-il github ou git ? » — u/sn2006gy, r/cursor
L’architecture de la bêta y répond clairement. Pour les dépôts provenant de GitHub, les push continuent d’arriver sur GitHub ; la copie Origin sert à parcourir, rechercher et récupérer le code. Le changelog de Cursor l’indique explicitement : GitHub reste la source de vérité.
| Action | Où elle a lieu |
|---|---|
| Push vers un dépôt synchronisé | GitHub ; Origin le reflète |
| Commentaire sur une PR dans Cursor | Publié sur GitHub |
| Réaction ou réponse sur GitHub | Apparaît dans Cursor « en quelques secondes », selon le changelog |
| Review attribuée dans GitHub | Peut être effectuée et fusionnée dans Cursor |
| Déconnexion d’un dépôt synchronisé | Prise en charge, dépôt par dépôt |
La responsabilité de l’hébergement ne bascule donc que pour les dépôts créés nativement dans Origin.
Agents et CI dans les dépôts Origin
D’après le changelog, les agents ayant accès à un dépôt Origin peuvent répondre à des questions sur le code, effectuer des modifications, mettre à jour des pull requests et pousser des branches. Des mois avant le lancement, un utilisateur de r/cursor résumait le goulot d’étranglement ainsi : « Les revues de code sont devenues un mauvais goulot d’étranglement. » (u/calloutyourstupidity)
Trois applications étaient disponibles au lancement : Vercel, Depot et Buildkite. En connectant Vercel depuis l’onglet Apps d’un dépôt, chaque PR obtient un déploiement de prévisualisation pour les tests et les commentaires ; la fusion déclenche ensuite le déploiement en production. Depot et Buildkite exécutent les workflows GitHub Actions existants, tandis que Buildkite peut aussi lancer ses pipelines natifs. La distinction compte : les dépôts synchronisés depuis GitHub conservent la CI déjà présente sur GitHub, alors que les dépôts hébergés nativement dans Origin ne peuvent à ce stade se connecter qu’à ces trois applications.
Le changelog ne dit rien de la couche opérationnelle qui encadre ces agents : aucun contrôle d’autorisation ou journal d’audit pour les push initiés par des agents, aucune limite par dépôt, aucun détail sur les coûts. Si vous utilisez vos propres agents de programmation en dehors de Cursor, les mêmes critères de choix d’un LLM pour agents de programmation s’appliquent à tout outil qui pousse du code dans vos dépôts.
Les zones d’ombre qui subsistent dans la bêta
- Aucune limite publiée concernant la taille des dépôts, le stockage ou la concurrence, ni SLA ou objectif de disponibilité.
- Aucune tarification propre à Origin. « Included in paid plans » est à ce jour le seul détail commercial communiqué, sans précision sur d’éventuels suppléments, quotas ou futur palier gratuit.
- Aucune condition spécifique à Origin sur le traitement des données. La page sécurité de Cursor mentionne une certification SOC 2, mais les questions sur les données d’entraînement et la rétention, soulevées lors de l’annonce, n’ont pas reçu de réponse publiée pour les dépôts hébergés.
- Les chiffres présentés dans la démo de Compile — 22.6 commits par seconde dans un dépôt et « hundreds of thousands of clones per hour » — restent des affirmations de démonstration : un guide indépendant sur Cursor les qualifie de non vérifiées, tandis que cette couverture du lancement note que le chiffre souvent repris de « 296,000+ clones » a perdu son unité de temps d’origine.
Tant que Cursor ne publie pas de conditions propres à Origin, cette réaction de juin reste un frein réel à l’adoption :
« Aucune chance que je confie l’historique Git complet à Cursor. » — u/fintechbass, r/cursor
Qui devrait tester Origin maintenant, et qui devrait attendre
| Votre situation | Recommandation |
|---|---|
| Formule Cursor payante, agents responsables d’une grande partie du code, dépôts non critiques disponibles | Testez-le : la bêta est déjà incluse dans votre formule |
| Les dépôts doivent rester sur GitHub avec leur CI existante | Pas de problème : la synchronisation apporte la revue et la recherche dans Cursor, tandis que la CI continue de tourner sur GitHub |
| Vous voulez héberger nativement sur Origin avec une CI au-delà de Vercel, Depot et Buildkite | Attendez : seules ces trois applications existent aujourd’hui |
| Vous envisagez de migrer des dépôts qui font autorité | Attendez : synchronisez-les plutôt, puisque GitHub reste de toute façon la référence |
Le compromis qui survivra à la bêta est simple : changer d’hébergeur pour un dépôt, c’est aussi déplacer sa responsabilité. La même comparaison des PR empilées rappelle que les artefacts de revue hors Git, comme les fils de discussion de PR, « ne passent pas par git push ». Origin est donc l’option actuelle la moins réversible. Cette comparaison indique aussi que Cursor a annoncé un accord définitif pour acquérir Graphite, l’entreprise spécialisée dans les PR empilées, le 19 décembre 2025 ; que l’équipe Graphite construit Origin au sein de Cursor ; et que Graphite continue d’opérer indépendamment sur graphite.com, avec des offres d’empilement affichées entre $20 et $40 par utilisateur et par mois avec facturation annuelle.
Cursor Origin remplace-t-il GitHub ?
Non. Les dépôts synchronisés depuis GitHub conservent GitHub comme source de vérité, et les push arrivent toujours sur GitHub. Origin ajoute une option d’hébergement native ainsi qu’une interface de revue par-dessus.
Cursor Origin est-il inclus dans les formules Cursor ?
La bêta anticipée est ouverte à toutes les formules Cursor payantes. Aucune tarification Origin distincte, aucun quota ni parcours vers une offre gratuite n’ont été annoncés.
Cursor Origin prend-il en charge les pull requests empilées ?
Ce point n’est pas documenté dans la bêta. Selon la comparaison indépendante, les workflows empilés dans Origin relèvent d’une attente liée à l’acquisition de Graphite, et non d’une fonctionnalité annoncée.
Peut-on auto-héberger Cursor Origin ?
Ni le changelog du 17 août ni la page produit d’Origin ne mentionnent d’option d’auto-hébergement. Les dépôts Origin sont hébergés par Cursor, et les administrateurs Enterprise peuvent seulement désactiver entièrement le service.
Faut-il Origin pour exécuter des agents de programmation à grande échelle ?
Non. Un guide indépendant sur Cursor recommande d’utiliser des worktrees distincts par agent, de maintenir de petits diffs et de recourir à des bots de première passe pour traiter le même goulot d’étranglement de revue sur GitHub ou GitLab dès aujourd’hui.
À lire aussi : Cursor Router expliqué