Qu'est-ce que Cursor Origin ? La plateforme Git pour agents IA décryptée.

Cursor veut désormais héberger votre code, et pas seulement l'écrire. Le 17 août 2026, l'entreprise a commencé à déployer Origin, son propre service d'hébergement Git, en version bêta précoce sur tous les forfaits payants. Les dépôts (repos), les requêtes de tirage (pull requests), la navigation de code et la synchronisation bidirectionnelle avec GitHub ont été livrés dès le premier jour, le tout résidant dans un nouvel onglet Codebase à l'intérieur de l'éditeur.

Le message est direct : les forges Git ont été conçues pour des humains poussant des commits quelques fois par jour, et Cursor parie que la prochaine décennie de contrôle de version sera façonnée par des agents ouvrant des branches, mettant à jour des PRs et fusionnant du travail 24h/24. Origin est la première plateforme d'hébergement conçue dès le départ autour de cette hypothèse.

Si votre équipe construit des API, cela vous concerne plus tôt que vous ne le pensez : vos spécifications OpenAPI, vos tests de contrat pilotés par CI et votre flux de travail de révision résident tous là où votre dépôt Git distant pointe. Voici ce que fait Origin aujourd'hui, ce qu'il lui manque, et comment maintenir un flux de travail API (y compris l'automatisation des tests Apidog) intact si vous l'essayez.

Qu'est-ce qu'Origin

Origin est une forge Git cloud gérée par Cursor. La version bêta initiale comprend :

• Dépôts hébergés que vous créez depuis l'onglet Codebase, depuis le web à l'adresse cursor.com/codebase, ou depuis un agent Cursor en pleine tâche. Les dépôts distants suivent le modèle https://cursor.com/codebase/{owner}/{repo}, et les commandes standard git clone, push, et pull fonctionnent avec eux.
• Requêtes de tirage (Pull requests) avec les éléments attendus : une chronologie, des commits, des vérifications, des diffs, des commentaires et la fusion, révisables dans l'éditeur ou dans le navigateur.
• Navigation et recherche de code sur le web, avec des paramètres au niveau du dépôt et du codebase.
• Une CLI dédiée pour les flux de travail en terminal, séparée de l'éditeur.
• Intégration d'agents, ce qui est le point essentiel : les agents peuvent lire le codebase, répondre à des questions le concernant, apporter des modifications, mettre à jour des PRs et pousser des branches depuis la même interface où vous révisez leur travail. Selon le journal des modifications, davantage de « fonctionnalités natives pour agents seront bientôt disponibles. »

Disponibilité : Forfaits Pro, Teams et Enterprise uniquement. Les utilisateurs des forfaits gratuits ne peuvent pas créer de dépôts Origin, et les organisations d'entreprise peuvent se désinscrire entièrement. Des détails comme les quotas de stockage, une API publique et les webhooks ne sont pas encore documentés, ce qu'il est bon de garder à l'esprit avant de déplacer quoi que ce soit d'important. Consultez la documentation Origin de Cursor pour l'état actuel.

Origin clôt un mois chargé pour l'entreprise ; la couverture médiatique, y compris le rapport de SiliconANGLE, note également que le lancement a eu lieu quelques jours après que SpaceX a finalisé son acquisition de Cursor. Pour un rappel sur la partie éditeur du produit, notre guide Cursor tout-ce-que-vous-devez-savoir couvre les fondamentaux.

La synchronisation GitHub est la partie intelligente

Personne ne migre une entreprise de GitHub en un week-end, et Cursor le sait. La version bêta d'Origin s'appuie donc sur une synchronisation bidirectionnelle plutôt que sur une migration :

• Miroitez un dépôt GitHub dans Origin et les dépôts synchronisés se mettent à jour en temps réel.
• Les commentaires et réactions des PRs se synchronisent dans les deux sens en quelques secondes : un commentaire laissé dans Cursor est publié sur GitHub, et une réponse GitHub apparaît dans Cursor.
• GitHub reste la source de vérité pour tout dépôt qui y a été créé. Les pushes continuent d'affluer vers GitHub ; Origin est un miroir vivant avec une meilleure histoire d'agent, pas un remplacement distant.
• Les permissions d'accès reflètent vos paramètres de lecture/écriture GitHub, de sorte que la synchronisation n'élargit pas discrètement le cercle des personnes pouvant accéder à un dépôt.

C'est le même modèle d'adoption à faible engagement qui a fonctionné pour Cursor face à VS Code : ne demandez à personne de partir, placez-vous aux côtés de l'opérateur historique, et laissez le nouveau flux de travail l'emporter par sa commodité. Vous pouvez essayer l'interface utilisateur de revue de PR d'Origin dès lundi sans en informer votre équipe plateforme, car rien ne change dans votre configuration GitHub.

Le sous-texte stratégique est plus difficile à ignorer. GitHub est le foyer par défaut du code depuis quinze ans, et sa propre histoire d'IA passe par Copilot, qui est en concurrence directe avec Cursor ; nous avons comparé les deux dans Cursor vs GitHub Copilot. La construction par Cursor de sa propre forge est une déclaration qu'il ne veut plus que sa feuille de route d'agents soit bloquée par la plateforme d'un concurrent.

Ce qui manque (et c'est beaucoup, pour l'instant)

La version bêta est une forge, pas une plateforme DevOps complète. Au moment du lancement, Origin dispose de :

• Pas de CI/CD natif. Au lieu de cela, Depot et Buildkite se connectent via l'onglet Applications d'un dépôt et peuvent exécuter vos fichiers de workflow GitHub Actions existants sur les dépôts Origin. C'est un pont pragmatique, mais c'est une dépendance tierce là où GitHub a un produit intégré.
• Pas de problèmes (issues), pas de discussions, pas de wiki. La revue de code est le seul primitif de collaboration.
• Pas d'auto-hébergement, pas d'API publique documentée, pas de webhooks, pas de limites de stockage déclarées.
• Un partenaire de lancement notable : connectez Vercel depuis l'onglet Applications et chaque PR obtient un déploiement de prévisualisation qui est mis en production lors de la fusion, le même flux que Vercel exécute pour les dépôts GitHub. (Vercel a livré rapidement ces derniers temps ; c'est la même passerelle qui exécute actuellement la réduction GPT-5.6 Sol.)

Aucune de ces lacunes n'a beaucoup d'importance tant que GitHub reste la source de vérité derrière la synchronisation. Elles deviennent énormément importantes le jour où une équipe envisage de faire d'Origin le primaire. Traitez la version bêta comme une couche de revue et d'agents, et non comme une infrastructure.

Ce que cela signifie spécifiquement pour les équipes API

Votre flux de travail API touche probablement la forge à trois endroits : la spécification réside dans le dépôt, les tests de contrat s'exécutent en CI sur chaque PR, et les relecteurs approuvent les modifications des deux. Voici comment chacun d'eux se rapporte à Origin aujourd'hui.

Spécifications et revue de conception. Si vous suivez un flux de travail axé sur la conception, votre fichier OpenAPI est l'artefact le plus révisé du dépôt. Les diffs de PR d'Origin gèrent le YAML comme n'importe quel autre texte, et la synchronisation bidirectionnelle des commentaires signifie qu'un relecteur d'API sur GitHub et un opérateur d'agent sur Cursor voient le même fil de discussion. Rien ne se casse, rien ne s'améliore non plus pour l'instant ; la partie intéressante arrive lorsque les agents commencent à proposer des modifications de spécification sous forme de PRs, ce qui est exactement la boucle pour laquelle Origin est conçu. Notre guide sur l'exécution de l'interface CLI Apidog dans Cursor couvre déjà la validation d'une spécification par l'agent de l'éditeur avant qu'elle ne soit commise.

Tests de contrat CI. Apidog CLI s'exécute comme une étape dans n'importe quel système CI, et la réponse d'Origin à la CI est « apportez vos workflows GitHub Actions via Depot ou Buildkite. » En pratique, cela signifie qu'une étape de workflow existante comme apidog run --scenario smoke-tests devrait être reportée sans modification, car le format du fichier de workflow est le même. L'avertissement honnête : nous n'avons pas vérifié la couche de compatibilité Actions de Depot par rapport à toutes les actions existantes, et personne d'autre ne l'a fait cette semaine. Exécutez votre pipeline sur un dépôt jetable miroir avant de lui faire confiance avec une branche de publication.

Les changements pilotés par agent nécessitent des barrières à l'épreuve des agents. Toute la prémisse d'Origin est que plus de code arrive des agents, plus rapidement. Cela augmente la valeur des vérifications automatisées et déterministes sur chaque PR, car les relecteurs humains deviennent le goulot d'étranglement. Une suite de tests de contrat qui fait échouer la construction lorsqu'un schéma de réponse dérive est précisément le type de barrière qui s'adapte au débit des agents, et c'est une configuration de cinq minutes dans Apidog : définissez les assertions par rapport à votre spécification une fois, exécutez-les depuis l'interface CLI dans n'importe quelle CI qui exécute vos PRs Origin. Téléchargez Apidog si vous voulez cette barrière en place avant que vos agents n'aient l'accès en écriture, et consultez notre tutoriel de tests QA avec Cursor pour la boucle de test plus large.

Devriez-vous l'essayer ?

Un raccourci de décision :

• Développeurs solos et petites équipes sur les forfaits payants Cursor : oui, faible risque. Miroitez un dépôt, utilisez la vue des PRs, gardez GitHub comme source de vérité. Vous ne perdez rien si Origin ne prend pas.
• Équipes avec un investissement important dans GitHub Actions : essayez-le d'abord sur un projet secondaire. Vos workflows se portent théoriquement via Depot ou Buildkite, mais « se porter théoriquement » n'est pas un plan de migration.
• Toute personne dont l'historique de conformité mentionne GitHub : attendez. Pas d'auto-hébergement, pas d'API documentée et un statut de bêta précoce font d'Origin un non-départ pour le code réglementé aujourd'hui.
• Équipes exécutant déjà des agents Cursor avec enthousiasme : c'est à elles que s'adresse Origin. Si vous utilisez quotidiennement les fonctionnalités d'agent de Cursor, le fait que les agents ouvrent et mettent à jour des PRs sur une forge qui les traite comme des utilisateurs de première classe constitue un réel gain en termes de flux de travail dès maintenant.

La forge devient une interface pour les agents

La vraie histoire n'est pas que GitHub a un nouveau concurrent. C'est que Cursor pense que le dépôt lui-même est sur le point de devenir principalement une interface pour les agents, les humains révisant plutôt qu'écrivant la plupart des changements. Qu'Origin gagne ou non, chaque forge sera tirée dans cette direction, et les équipes API le ressentiront en premier, car les spécifications et les tests de contrat sont les portes de révision les plus automatisables dans les logiciels.

La préparation est la même dans tous les cas : rendez vos vérifications API scriptables et agnostiques à la forge. Apidog conserve vos spécifications, mocks et scénarios de test au même endroit et les exécute à partir d'une interface CLI qui ne se soucie pas de savoir si la PR provient d'un humain sur GitHub ou d'un agent sur Origin. Essayez-le gratuitement, et vos barrières de révision vous suivront, quelle que soit l'issue de la guerre des forges.

FAQ

• Cursor Origin est-il gratuit ? Non. Le stockage de code Origin nécessite un forfait Cursor payant (Pro, Teams ou Enterprise). Les utilisateurs des forfaits gratuits ne peuvent pas créer de dépôts Origin, et les organisations d'entreprise peuvent se désinscrire entièrement d'Origin.
• Dois-je quitter GitHub pour l'utiliser ? Non. La conception du lancement suppose que vous ne le ferez pas : miroir un dépôt GitHub dans Origin et GitHub reste la source de vérité, avec les pushes, les commentaires de PR et les réactions se synchronisant dans les deux sens en quasi temps réel.
• Origin dispose-t-il de CI/CD ? Pas nativement. Depot et Buildkite se connectent via l'onglet Applications et exécutent vos fichiers de workflow GitHub Actions existants. Vercel est également intégré pour les déploiements de prévisualisation de PR.
• Les agents peuvent-ils utiliser Origin directement ? Oui, c'est la fonctionnalité essentielle : les agents Cursor peuvent créer des dépôts, répondre à des questions sur le codebase, mettre à jour des requêtes de tirage et pousser des branches. Cursor indique que d'autres fonctionnalités natives pour les agents sont à venir ; notre guide du mode agent Cursor couvre ce que les agents peuvent déjà faire dans l'éditeur.
• Comment exécuter des tests API sur les requêtes de tirage Origin ? De la même manière que sur GitHub : exécutez Apidog CLI comme une étape CI. Sur Origin, cela signifie connecter Depot ou Buildkite au dépôt et réutiliser votre workflow Actions existant, avec vos commandes apidog run inchangées.