Le 2 septembre, Cursor a lancé Self-Hosted Machines, qui permet aux équipes de déplacer l’exécution des outils de ses agents de programmation vers des ordinateurs, machines virtuelles, clusters ou environnements isolés qu’elles administrent elles-mêmes. Le changement est important pour les organisations dont le dépôt de code, la chaîne de compilation, les services internes ou le matériel spécialisé ne peuvent pas être exposés à un environnement d’exécution géré par un fournisseur.
La portée est toutefois plus étroite que le terme « autohébergé » pourrait le laisser penser. La documentation de Cursor précise que l’orchestration de l’agent, l’inférence et la planification restent dans le cloud de Cursor. La machine du client modifie les fichiers, exécute les commandes, pilote le navigateur et accède aux serveurs MCP locaux. Pour les équipes de sécurité et de gouvernance, la vraie question n’est donc pas seulement où l’agent s’exécute, mais où se trouve chaque composant du système.
L’exécution passe chez le client, l’orchestration reste chez Cursor
Une machine d’exécution autohébergée ouvre une connexion HTTPS sortante vers Cursor et attend les appels d’outils. Cursor effectue l’inférence et la planification, envoie l’action demandée à la machine d’exécution, puis récupère le résultat avant l’étape de raisonnement suivante. L’entreprise indique qu’aucune connexion entrante vers le réseau du client n’est nécessaire.
Cette séparation donne à l’organisation un contrôle direct sur la machine d’exécution. Elle peut choisir son système d’exploitation, installer ses outils de compilation internes, utiliser des GPU ou des Mac et placer la machine d’exécution à proximité de services qui ne sont pas accessibles depuis un environnement cloud public. Cursor prend en charge aussi bien une machine personnelle que des groupes de machines partagés pour les équipes.
Cette architecture n’est donc pas celle d’un agent de programmation entièrement autohébergé. Le calcul qui manipule le dépôt et lance les commandes appartient au client, tandis que l’orchestration et le traitement par le modèle restent fournis par Cursor.
L’exécution autohébergée ne signifie pas que toutes les données restent sur place
La documentation de Cursor décrit précisément la frontière réseau. Le dépôt complet, le cache de compilation et les identifiants conservés sur la machine restent dans l’environnement du client. En revanche, la machine d’exécution transmet à Cursor les éléments nécessaires à la session de l’agent, notamment du contenu de fichiers, des sorties de terminal, des différences de code, des captures d’écran, des résultats de serveurs MCP locaux et des métadonnées de routage.
Des artefacts de l’agent peuvent également être envoyés vers un stockage géré par Cursor afin d’apparaître dans les demandes de fusion et les tableaux de bord. Cursor indique que son mode de confidentialité empêche l’utilisation du code transmis pour l’entraînement par Cursor ou ses fournisseurs de modèles. Cela ne signifie pas pour autant que ces données ne quittent jamais le réseau de l’entreprise.
La nuance compte dans une revue d’architecture. Une organisation peut conserver son dépôt complet et ses secrets sur ses propres machines tout en transmettant certains extraits de code et résultats d’outils à un service externe. Une exécution autohébergée n’équivaut donc pas automatiquement à un traitement intégralement local ni à une garantie complète de résidence des données.
Le principal avantage est l’accès aux infrastructures privées
La fonction est surtout utile lorsque l’agent doit agir au plus près d’une infrastructure existante. La machine d’exécution peut accéder à un gestionnaire de sources privé, à des dépôts de paquets internes, à une chaîne de compilation, à des services locaux ou à du matériel spécialisé sans déplacer ces ressources dans l’environnement géré par Cursor.
Cursor propose également des groupes de machines dont la capacité peut évoluer avec la file d’attente et servir plusieurs dépôts. La documentation décrit des intégrations avec plusieurs fournisseurs d’environnements isolés ainsi que le contrôle d’ordinateur sous Linux et macOS. La fonction peut ainsi s’intégrer à une plateforme de développement d’entreprise plutôt que de se limiter à une machine distante individuelle.
Pour une équipe plateforme, l’option est claire : conserver la couche d’exécution sous les contrôles d’infrastructure existants tout en utilisant Cursor pour l’orchestration de l’agent.
Une revue de sécurité doit distinguer deux frontières
La conséquence opérationnelle est que les équipes de sécurité doivent examiner séparément deux frontières.
La première est la frontière d’exécution : où les commandes tournent, où réside la copie de travail, quels services internes sont accessibles, quels identifiants se trouvent sur la machine et comment les machines d’exécution sont isolées et maintenues.
La seconde est la frontière de traitement des informations : quels extraits de fichiers, sorties de commandes, captures d’écran, résultats MCP, transcriptions et artefacts sont envoyés à Cursor ou stockés hors de la machine d’exécution. Ce sont ces flux qui déterminent si l’architecture satisfait une exigence particulière de confidentialité, de conservation ou de conformité.
Réunir ces deux questions sous la seule étiquette « autohébergé » peut donner une impression de contrôle excessive. La fonction peut réduire l’exposition directe de l’infrastructure et des identifiants tout en conservant un flux sortant qui doit être encadré explicitement.
Avant d’autoriser des dépôts sensibles, une bonne règle de mise en production consiste à documenter les deux frontières dans le modèle de menace et le schéma des flux de données. L’équipe peut alors décider quels dépôts sont éligibles, quelles destinations sortantes sont autorisées, ce que les sorties d’outils peuvent contenir, si l’envoi d’artefacts doit être désactivé et quelles règles contractuelles ou de conservation s’appliquent aux données traitées par Cursor.
Davantage de contrôle implique aussi davantage de responsabilité
Cursor recommande ses Cloud Agents gérés pour la plupart des équipes. La documentation précise qu’avec Self-Hosted Machines, le client devient responsable de l’image de la machine d’exécution, de l’infrastructure, des secrets, de la politique de mise à l’échelle et de la validation en production. Il supporte également le coût et l’exploitation de ses propres machines en plus de l’utilisation du modèle.
Ce compromis est cohérent pour une organisation qui a besoin d’accéder à un réseau privé, d’utiliser du matériel particulier ou de mieux maîtriser l’environnement d’exécution. Il est moins intéressant lorsque l’isolation gérée et les options de connectivité privée répondent déjà au besoin.
La conclusion architecturale est précise : Cursor a déplacé les actions de l’agent dans l’infrastructure contrôlée par le client, mais pas son raisonnement ni son traitement par le modèle. Cette séparation doit apparaître explicitement dans les modèles de menace, les schémas de flux de données, les revues d’achat et les critères de mise en production.