Cursor Origin : La Forge Git Conçue pour les Agents IA, Expliquée

Cursor Origin est la propre forge git de Cursor — un endroit pour héberger des dépôts, examiner des pull requests et parcourir du code, avec les agents de codage de Cursor intégrés comme acteurs de premier plan. Elle a été lancée en bêta anticipée le 17 août 2026, sur les plans payants uniquement. Ce guide couvre ce qui a réellement été lancé, comment fonctionne le miroir GitHub, ce que les agents peuvent faire, et — tout aussi important — ce qui manque encore. Tout ici est fondé sur la propre documentation de Cursor.

Qu'est-ce que Cursor Origin ?

Cursor décrit Origin en une ligne : une forge git pour l'ère agentique. En termes simples, c'est un véritable hébergeur git — pas une interface graphique superposée à GitHub. Les dépôts vivent sur les propres serveurs distants de Cursor, et vous poussez et tirez avec git standard.

La raison pour laquelle une entreprise connue pour son éditeur héberge soudainement du code : le dépôt est l'endroit où le travail des agents devient réel, vérifiable et fusionnable. Avec Origin, Cursor s'installe dans la couche où les dépôts, les pull requests, la navigation dans le code et les agents coexistent — et le pari plus grand n'est pas simplement de construire un autre GitHub, mais de faire de la forge elle-même une partie du flux de travail des agents plutôt qu'un système externe avec lequel l'éditeur s'intègre.

Origin a été construit par l'équipe derrière Graphite, la société de révision de code par diff empilé que Cursor a acquise, et il est arrivé la même semaine qu'une panne majeure de GitHub — ce qui a amplifié le lancement mais n'en était pas le but.

Ce qui a été livré en bêta anticipée

La bêta est délibérément modeste. Voici ce qui est inclus — et ce qui ne l'est pas.

Dans la bêta :

• Hébergement de dépôts via git standard (HTTPS), avec visibilité Interne et Privée
• Pull requests avec révision en ligne, vérifications et protections de fusion
• Navigation dans le code, recherche et historique des commits sur cursor.com/codebase
• Mise en miroir GitHub avec synchronisation bidirectionnelle des PR
• Une CLI Origin, une API et des webhooks
• Trois intégrations : Vercel (déploiements de prévisualisation), Depot et Buildkite (CI)

Pas dans la bêta :

• GitHub Issues, projets, discussions ou wiki
• Dépôts publics (pas encore d'espace pour l'open source)
• Un runner CI natif, un registre de paquets ou des releases
• Analyse de sécurité ou équivalents aux alertes de dépendances
• Limites de stockage, SLA ou tarification post-bêta publiés

Trois intégrations ont été livrées dès le premier jour : Vercel crée un déploiement de prévisualisation pour chaque pull request et déploie en production lors de la fusion, tandis que Depot et Buildkite exécutent l'intégration continue — et, point crucial, les deux exécutent les workflows GitHub Actions existants sans modification. Cette couche de compatibilité est la stratégie en miniature : essayez Origin sans réécrire votre système de build.

Qui peut l'utiliser

Le stockage de code Origin est disponible sur les plans Pro, Teams et Enterprise — pas sur les plans gratuits. L'accès se déploie par étapes, donc les abonnés payants peuvent ne pas le voir immédiatement. Activez-le en revendiquant un nom de codebase (base de code), l'espace de noms sous lequel vivent tous vos dépôts. Choisissez-le soigneusement : pendant la bêta, il ne peut pas être renommé, et il apparaît dans chaque URL de dépôt.

Origin remplace-t-il GitHub ? Comment fonctionne le miroir

Pas encore — et Cursor ne vous le demande pas. Le chemin conçu est la mise en miroir, et elle est conservatrice dans le bon sens. Cursor ne vous demande pas de quitter GitHub : connectez une organisation GitHub, sélectionnez des dépôts, et ils apparaissent aux côtés des dépôts natifs Origin.

La mise en miroir copie l'historique complet, les branches et les tags dans Origin et les maintient synchronisés, avec les commentaires et révisions de pull requests circulant dans les deux sens. Le détail crucial : un développeur peut cloner depuis Origin et pousser vers le remote Origin, mais ces poussées transitent par GitHub — et Cursor indique explicitement que GitHub reste la source de vérité pour les dépôts qui y ont commencé.

Le pont a des limites. Les GitHub Issues ne sont pas migrées. Ni les secrets Actions ni la configuration d'exécution — les dépôts mis en miroir conservent leur CI sur GitHub. Quand une équipe décide qu'Origin doit faire autorité, elle détache le miroir : la synchronisation s'arrête, la copie Origin devient indépendante, et le dépôt GitHub original est laissé intact. Ce détachement est le vrai moment de migration ; tout ce qui précède est un essai gratuit du flux de travail.

Les agents comme acteurs de premier plan

La liste de fonctionnalités ci-dessus pourrait décrire n'importe quelle jeune forge. La stratégie se révèle dans le câblage des agents. Les agents cloud de Cursor peuvent créer un dépôt Origin de bout en bout, puis cloner, créer une branche, commiter, pousser et ouvrir des pull requests contre lui.

Les automatisations attachent des agents aux événements du dépôt — un push sur main, une PR ouverte ou mise à jour, ou un calendrier. Et depuis le changelog du 19 août 2026, les agents cloud s'abonnent automatiquement aux PR qu'ils créent : un agent abonné surveille le CI, corrige les vérifications échouées, répond aux retours de révision et se réveille quand la PR change, poursuivant l'objectif jusqu'à ce que le travail soit réellement terminé.

Cela ferme une boucle qu'aucune forge tierce ne peut offrir à Cursor : événement de dépôt → agent s'exécute dans une VM isolée → changement de code → mise à jour de PR → résultat CI → agent se réveille à nouveau. Posséder la forge signifie posséder chaque étape. Il convient d'être précis, cependant : le modèle de révision de PR lui-même reste une révision humaine conventionnelle. Le pari porte sur l'endroit où la boucle se resserre à partir d'ici.

Les limites honnêtes

Les propres docs de Cursor sont candides, et les lacunes comptent si vous évaluez un déménagement :

• Pas d'Issues ni de suivi de travail. Elles ne sont même pas mises en miroir — votre outil de suivi reste où il est.
• Pas de dépôts publics. Les projets open source n'ont nulle part où atterrir encore.
• Pas de CI natif, de paquets ou d'outils de sécurité. Le CI vient de partenaires ; il n'y a pas d'équivalent documenté à l'analyse des secrets ou aux alertes de dépendances.
• Pas de limites publiées, de SLA ou de prix post-bêta. Les engagements de stockage, de bande passante et de disponibilité ne sont pas écrits à la date de la bêta.
• Le déploiement est progressif et contrôlé par l'administrateur. Le mode de confidentialité hérité le bloque entièrement, et les administrateurs d'équipe peuvent le désactiver.

Rien de tout cela n'est une critique d'une bêta vieille de quelques jours — c'est juste la carte honnête de l'emplacement des bords. Pour une image plus complète des préoccupations d'entreprise, l'analyse de lancement de VentureBeat passe en revue les questions de révision de sécurité qu'une équipe plateforme devrait poser.

Devriez-vous déplacer vos dépôts maintenant ?

Le chemin à faible risque est celui qui a été conçu : mettre en miroir quelques dépôts pendant que GitHub reste autoritaire, utiliser Origin pour la navigation, la révision et les flux de travail des agents, et n'envisager le détachement qu'après avoir validé le CI, les contrôles d'accès et les fonctionnalités de collaboration que vous perdriez. La bêta ne coûte rien au-delà de votre plan Cursor existant, c'est donc un aperçu peu coûteux de ce que ressent l'infrastructure de l'ère agentique.

Si vous êtes curieux de savoir comment Cursor en est arrivé là, notre histoire des origines de Cursor retrace l'entreprise depuis une idée de CAO jusqu'à l'un des outils de codage IA les plus utilisés — un contexte utile pour comprendre pourquoi elle construit maintenant sa propre forge.

Construisez votre propre flux de travail d'agents — selon vos conditions

La vraie thèse d'Origin est que l'unité de travail intéressante est un agent permanent qui possède une tâche de l'événement à la PR fusionnée, pas une fenêtre de chat. C'est le même pari qu'Eigent fait — sauf qu'Eigent fait tourner toute une équipe d'agents multi-agents localement, sur du code et des flux de travail que vous contrôlez, sans dépendance fournisseur. Si la révision des pull requests rédigées par des agents est votre goulot d'étranglement, notre flux de travail de révision des PR GitHub met un agent directement sur ce travail. Téléchargez Eigent et confiez une vraie tâche multi-étapes à votre propre équipe IA.