Agents IA auto-hébergés avec Cursor : garder les outils sur votre réseau

Le changement apporté par Cursor le 2 septembre 2026 déplace à la fois la frontière de sécurité et la facture d’infrastructure : votre équipe peut exécuter les outils de ses agents IA auto-hébergés sur des machines qu’elle contrôle, mais elle devient responsable de ces workers. Le modèle, la planification et la boucle agent continuent de fonctionner dans le cloud de Cursor.

Agents IA auto-hébergés : un runtime scindé en deux

Un Cursor Cloud Agent se compose de deux parties. La boucle agent décide de l’action suivante et sollicite le modèle. L’exécution des outils couvre la modification de fichiers, le lancement de commandes dans le terminal, l’ouverture d’un navigateur, les échanges avec un serveur MCP local et l’accès aux services internes.

Cursor Self-Hosted Machines sépare ces deux parties. Cursor conserve la boucle, l’inférence, la planification, l’interface et l’orchestration des sessions. Un worker que vous administrez exécute les outils.

Ce worker peut être un ordinateur portable, une VM, un Mac, un pod Kubernetes ou une sandbox fournie par un partenaire d’intégration. Il ouvre une connexion HTTPS sortante vers Cursor, reçoit les appels d’outils, les exécute localement, puis renvoie les résultats. Aucun port entrant ni aucune adresse IP publique ne sont nécessaires sur le worker.

Voici comment les responsabilités se répartissent.

Cursor propose deux types de workers. My Machines rattache une machine au compte d’une seule personne et convient à une devbox ou à un workflow personnel bien délimité. Les Team Pools sont des files d’attente nommées destinées aux équipes Enterprise. Une requête reste dans le pool jusqu’à ce qu’un worker disponible la prenne en charge, et chaque worker du pool ne traite qu’une session Cloud Agent à la fois.

Il ne s’agit pas d’un modèle Cursor on-premise. C’est un runtime scindé dont la partie exécution appartient au client. Cette nuance détermine si la fonctionnalité répond réellement à votre politique.

Ce qui reste dans votre réseau — et ce qui en sort encore

Le checkout complet, le cache de build et les identifiants stockés sur la machine restent sur votre worker. Les commandes, les opérations sur le dépôt, les builds et les appels aux services internes s’y exécutent également. Il devient donc possible d’éviter de copier tout un dépôt dans une VM d’exécution administrée par un fournisseur.

L’agent a toutefois besoin de contexte pour prendre ses décisions. Pendant une exécution, le worker envoie à Cursor le contenu des fichiers requis par l’agent, les sorties du terminal, les diffs, les captures d’écran, les résultats du MCP local et les métadonnées de routage. Des captures d’écran, des vidéos et des références de logs peuvent aussi être chargées dans un espace de stockage d’artefacts géré par Cursor afin d’apparaître dans les pull requests et le tableau de bord.

Il est possible de bloquer l’hôte des artefacts sans arrêter l’agent, mais ces éléments disparaissent alors de la pull request et du tableau de bord. Privacy Mode reste également applicable : le code envoyé depuis le worker n’est utilisé pour l’entraînement ni par Cursor ni par ses fournisseurs de modèles. La session n’en devient pas hors ligne pour autant.

Voilà la première conséquence métier. La revue de sécurité peut désormais valider séparément le lieu d’exécution et le traitement par le modèle, mais elle doit toujours approuver les deux.

À qui s’adresse cette architecture, et qu’est-ce qu’elle change ?

Une équipe backend d’entreprise qui dépend de services internes

Une équipe backend peut avoir besoin d’un registre de paquets privé, d’une base de données de staging et d’endpoints de services inaccessibles depuis une VM gérée. Un Team Pool peut être placé sur le même réseau contrôlé et lancer le build sans ouvrir de route entrante depuis Cursor.

Le bénéfice porte sur le contrôle des accès, pas sur une confidentialité automatique. L’équipe plateforme peut conserver sa politique réseau et son coffre de secrets existants, tandis que l’équipe sécurité examine précisément les résultats qui franchissent la connexion sortante.

Une équipe iOS dépendante de machines Mac

Les Cloud Agents gérés par Cursor fonctionnent sur des VM Ubuntu. Une équipe qui a besoin de matériel Mac pour travailler sur iOS peut enregistrer des Mac comme workers, leur accorder les autorisations nécessaires au contrôle de l’ordinateur, puis laisser un agent cliquer, saisir du texte, prendre des captures d’écran ou piloter le navigateur sur cette machine.

L’agent distant peut ainsi utiliser la même catégorie de matériel que le build. En contrepartie, les problèmes bien connus des équipes qui exploitent un parc de Mac pour les builds restent à votre charge : dérive des images, autorisations, disponibilité, nettoyage et remplacement.

Une équipe plateforme confrontée à des pics de demande

Une équipe plateforme peut placer des Cloudflare Containers derrière un Team Pool. Le template de référence démarre un conteneur isolé pour chaque session prise en charge, utilise un Durable Object pour gérer ce conteneur et peut mettre en cache des snapshots du dépôt dans R2.

Le pool reste disponible même lorsqu’aucun worker n’est connecté, ce qui permet de ramener la capacité à zéro. Lorsque les tâches reprennent, le contrôleur prend la requête en charge et lance un conteneur. L’avantage : la capacité de calcul suit l’usage au lieu d’imposer un parc constamment actif.

Un développeur indépendant avec une devbox persistante

My Machines convient à un développeur dont le projet dépend d’outils locaux ou d’un état difficile à recréer. Plusieurs agents peuvent partager cette machine : c’est pratique sur un poste personnel, mais c’est aussi un avertissement pour les tâches sensibles.

Le gain se situe dans la rapidité de configuration. Le risque vient des résidus entre deux exécutions, puisque Cursor n’efface ni ne reconstruit votre ordinateur portable entre les sessions. Le répertoire de travail, les identifiants, le nettoyage des processus et la santé de la machine relèvent de votre responsabilité.

Déployer une configuration Cloudflare fonctionnelle

La voie Cloudflare est intéressante parce qu’elle rend visible la nouvelle frontière de responsabilité. Elle nécessite Cursor Enterprise, une clé de compte de service d’équipe dotée du scope agent, un compte Cloudflare Workers Paid avec Containers et R2, Node.js 20 ou une version ultérieure, ainsi que Docker.

1. 1

   Enregistrer un Team Pool

   Installez la CLI Cursor, vérifiez qu’elle fonctionne, puis connectez temporairement un worker local afin de faire apparaître le pool dans Cursor.

   curl https://cursor.com/install -fsS | bash
   agent --version
   export CURSOR_API_KEY="<team service-account API key>"
   CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

   Une fois le pool visible, arrêtez ce worker avec Ctrl+C, puis exécutez unset CURSOR_API_KEY. Laissez le worker local à l’arrêt pendant le test de Cloudflare afin qu’il ne prenne pas la requête avant le conteneur.

2. 2

   Déployer le template de référence de Cursor

   Clonez le template, installez ses dépendances, connectez-vous à Cloudflare et créez le bucket facultatif destiné aux snapshots.

   git clone https://github.com/anysphere/cloudflare-workers.git
   cd cloudflare-workers
   npm install
   npx wrangler login
   npx wrangler r2 bucket create cursor-pool-worker-snapshots

3. 3

   Enregistrer les identifiants

   Placez la clé du compte de service Cursor dans les secrets du Worker. N’ajoutez les identifiants Git que si les conteneurs doivent accéder à des dépôts privés.

   npx wrangler secret put CURSOR_API_KEY
   npx wrangler secret put GIT_USERNAME
   npx wrangler secret put GIT_TOKEN

   Une clé API Cursor personnelle ne fonctionne pas avec un Team Pool. C’est l’erreur de configuration la plus susceptible de passer pour une panne d’infrastructure, car le contrôleur renvoie 401.

4. 4

   Configurer le pool et sa capacité

   Dans wrangler.jsonc, remplacez CURSOR_POOL par cloudflare-test. Réglez containers[].max_instances sur le nombre maximal de sessions simultanées que vous êtes prêt à exécuter, et non sur le nombre de développeurs de l’équipe.

   Par défaut, le fichier de référence fixe max_instances à 10 et utilise un conteneur standard-1 doté de 0.5 vCPU, 4 GiB de mémoire et 8 GB de disque. Les builds réels peuvent nécessiter une configuration plus puissante.

5. 5

   Déployer et observer la première exécution

   Lancez le déploiement, puis gardez les vues du contrôleur et du conteneur ouvertes pendant que vous démarrez un Cloud Agent et sélectionnez le pool auto-hébergé.

   npx wrangler deploy
   npx wrangler tail
   npx wrangler containers list

   La première exécution planifiée du contrôleur peut prendre jusqu’à cinq minutes avant de démarrer. Lorsqu’une session prise en charge ne démarre pas, le problème vient généralement de la capacité des conteneurs, du clonage du dépôt ou des identifiants Git.

Le coût se déplace, il ne disparaît pas

Les Cloud Agents gérés par Cursor incluent l’infrastructure d’exécution. Les Self-Hosted Machines restent facturées selon le modèle sélectionné dans Cursor, puis s’y ajoute la facture de vos workers. Les Team Pools nécessitent aussi un contrat Enterprise, dont le prix est établi sur mesure.

Cloudflare montre comment se comporte cette ligne supplémentaire. Son produit Containers repose sur l’offre Workers Paid à $5 par mois. Celle-ci inclut 25 GiB-heures de mémoire, 375 vCPU-minutes et 200 GB-heures de disque. Au-delà, la mémoire coûte $0.0000025 par GiB-seconde, le CPU actif $0.000020 par vCPU-seconde et le disque provisionné $0.00000007 par GB-seconde.

Prenons la configuration standard-1 du template de référence et modélisons 100 sessions d’une heure chacune, qui utilisent toute la puissance CPU disponible lorsqu’elles sont actives, puis restent ouvertes pendant la fenêtre d’inactivité de cinq minutes du template. Une fois les quotas inclus déduits, le calcul des conteneurs s’élève à environ $12 pour le mois :

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

Il s’agit d’une illustration du coût d’infrastructure, pas de la facture Cursor totale. Le calcul exclut l’utilisation de Worker et de Durable Object, les logs, l’egress, R2, le contrat Enterprise, l’utilisation du modèle et les personnes chargées de maintenir le parc. Il suppose également que la plus petite configuration du template suffit. Un dépôt dont la compilation est intensive peut imposer un conteneur plus puissant.

La décision la plus coûteuse ne tient souvent pas au tarif à la seconde, mais à la politique de maintien de la capacité active. Le worker de pool générique de Cursor utilise par défaut une fenêtre de reconnexion de 3,600 secondes, contre 300 secondes dans le template Cloudflare. Une fenêtre longue accélère les prompts suivants, tout en maintenant la facturation de la mémoire et du disque provisionnés. Une fenêtre courte réduit les dépenses à vide, au prix de démarrages à froid plus fréquents.

La capacité vous incombe également. Le template peut accueillir 10 conteneurs simultanés dès l’installation. La requête suivante attend ou ne démarre pas lorsque la capacité choisie, la limite du compte ou l’hôte sous-jacent est indisponible. Cursor peut acheminer une tâche vers un pool, mais ne peut pas créer une capacité que vous n’avez pas provisionnée.

Même logique pour l’isolation. Le template Cloudflare attribue son propre conteneur à chaque session. Une machine personnelle peut exécuter plusieurs agents sur un seul hôte. Si votre politique impose une VM neuve, un disque effacé, une séparation entre tenants ou une frontière de secrets propre après chaque exécution, c’est à vous de construire et de vérifier ce fonctionnement.

Les correctifs deviennent un calendrier d’exploitation. Votre équipe est responsable de l’image de base, de la CLI Cursor, des outils de build, des certificats, des dépendances et du déploiement progressif. Sur Cloudflare, déployer une nouvelle image de conteneur arrête les conteneurs en cours d’exécution : une mise à jour doit donc attendre la fin des sessions actives ou accepter de les interrompre.

Que faut-il faire maintenant ?

Passez à l’action cette semaine si un Cloud Agent a besoin de matériel spécifique, d’une image personnalisée ou d’un accès à des outils que le réseau géré ne peut pas fournir. Commencez avec un pool limité et un dépôt à faible risque. Maintenez le traitement par le modèle et les données renvoyées par les outils dans le périmètre de la revue de sécurité, car déplacer l’exécution ne les en retire pas.

Attendez si votre seul besoin consiste à accéder à un dépôt de code source privé ou à un service interne. Cursor recommande de tester les environnements gérés, les contrôles réseau, Tailscale, AWS PrivateLink ou Cloudflare Tunnel avant d’endosser la gestion d’un parc de workers. Ces options laissent à Cursor la responsabilité du cycle de vie et de l’isolation des hôtes.

Rien ne change pour vous si les Cloud Agents gérés respectent déjà votre politique et reproduisent correctement votre build. L’auto-hébergement n’ajoute aucune nouvelle capacité au modèle. Il change le lieu d’exécution et la responsabilité opérationnelle.

L’action concrète à lancer lundi : choisissez un dépôt représentatif, consignez le code, les secrets, les résultats d’outils et les artefacts autorisés à franchir la frontière, puis exécutez le même build sur un agent géré et sur un pool auto-hébergé strictement plafonné. Mesurez le temps d’attente dans la file, les heures-conteneur, les modifications acceptées, les échecs de nettoyage et le temps consacré à maintenir l’image. N’approuvez le parc que si l’exigence de contrôle justifie cette seconde facture.

Recevez dans la newsletter la prochaine analyse opérationnelle d’un workflow IA.