Agent IA dans le cloud : deux écarts entre Cursor et Cloudflare Workers

Le 13 mai, Cursor a lancé des environnements cloud multi-repos conçus pour qu’un agent IA travaille sur plusieurs dépôts. D’après sa propre page produit, plus de 30% des pull requests que l’entreprise fusionne sont désormais créées par des agents autonomes opérant dans des sandboxes cloud.

Agent IA dans le cloud : ce que Cursor a réellement lancé le 13 mai

La nouveauté phare, ce sont les environnements cloud multi-repos dédiés aux agents. Un même environnement configuré peut désormais couvrir plusieurs dépôts, dans le prolongement des workspaces multi-root livrés par Cursor le 24 avril. Comme cet environnement reste réutilisable d’une session à l’autre, inutile de reconfigurer la même machine de développement à chaque démarrage d’un agent.

La configuration passe par un Dockerfile. Les secrets de build restent cantonnés à cette étape et ne sont pas transmis à l’agent en cours d’exécution. Cursor neutralise ainsi le piège le plus courant des infrastructures d’agents : une clé API intégrée par erreur au build qui finit dans la mémoire de travail de l’agent. Cursor peut également préparer le Dockerfile après avoir analysé les outils et dépendances des repos. Ce parcours reste en bêta privée pour les équipes Enterprise.

C’est le cache des layers qui bénéficie du gain de performances le plus net. Lorsqu’un cache est disponible, les builds sont désormais 70% plus rapides, car seules les layers modifiées du Dockerfile sont reconstruites. Pour une équipe qui relance régulièrement des agents, la différence se mesure directement entre temps d’attente et temps de travail.

La dimension opérationnelle est précisément celle que les concurrents continuent de minimiser. Chaque environnement dispose d’un historique des versions avec rollback, réservé aux administrateurs. Un journal d’audit consigne toutes les actions réalisées par les membres de l’équipe sur les environnements. Les listes d’autorisation de trafic sortant et les périmètres des secrets se règlent environnement par environnement : un secret accessible depuis l’environnement A ne l’est pas depuis l’environnement B. C’est cette infrastructure peu spectaculaire qu’il faut avant d’autoriser un agent à ouvrir des PR sur du code de production.

Pour étayer son annonce, Cursor cite Amplitude. Ses Cursor Automations surveillent les canaux Slack publics, enquêtent sur les problèmes signalés, identifient les repos concernés et ouvrent les PR dans les bons repos. Voilà un agent multi-repos qui assure un premier niveau de triage à l’échelle réelle d’une entreprise. Ce n’est pas une démo.

Le vrai signal, c’est le taux de PR fusionnées chez Cursor

Cursor affirme que plus de 30% des pull requests qu’il fusionne sont désormais créées par des agents autonomes dans des sandboxes cloud. Le dénominateur est essentiel : il s’agit de pull requests fusionnées, pas de tentatives lancées par des agents. Ce chiffre montre que la boucle peut aller jusqu’à la revue, aux corrections et à la livraison sans qu’un humain pousse chaque commit.

Depuis le 2 septembre 2026, Self-Hosted Machines permet aux équipes de transférer les modifications de fichiers, les commandes de terminal, les outils de computer use et l’exécution MCP locale vers des workers qu’elles gèrent, tandis que Cursor conserve dans son cloud la boucle de l’agent, l’inférence et la planification. L’écart sur le lieu d’exécution privée est ainsi comblé, mais Cursor ne devient pas pour autant un runtime programmable et durable.

Le choix ne se résume plus à opposer un état limité à la session à un état durable. Cursor conserve l’état des conversations dans son backend afin de pouvoir reprendre et consulter les runs, et Self-Hosted Team Pools sait restaurer un workspace en hibernation. La distinction décisive est désormais celle entre un état d’agent géré par le fournisseur et un état applicatif programmable. Cloudflare donne accès à un état SQLite propre à chaque Agent ainsi qu’à des étapes de workflow durables, pilotables dans le code.

Ce que fait déjà ma stack Cloudflare Workers et Agents SDK

J’exploite six agents de production sur Cloudflare. Le runtime repose sur Workers ; l’état est stocké dans des Durable Objects avec une base SQLite par instance ; l’orchestration de longue durée s’exécute dans Cloudflare Workflows. Projet solo, compte unique : j’en détaille ici toute l’architecture. L’ensemble de la stack Cloudflare a coûté $19.14 en avril 2026. Il s’agit d’une facture de production datée, pas d’un tarif catalogue. Chez Cursor, l’offre Enterprise est affichée sur devis ; Team Pools exige Enterprise, et Self-Hosted Machines ajoute toujours le coût du modèle choisi à celui de vos workers.

Cette stack se distingue du produit actuel de Cursor de trois façons.

Le multi-repo, par le code. Un Worker peut récupérer des ressources via HTTP pendant l’exécution. Browser Run, anciennement Browser Rendering, peut piloter un navigateur headless lorsque le contexte se trouve derrière un site web. Cursor encapsule l’accès multi-repos dans une configuration d’environnement réutilisable ; Cloudflare vous laisse gérer la récupération, l’authentification et la logique des dépôts. Ce n’est ni mieux ni moins bien : la surface de contrôle est différente.

Un état durable programmable. Un Cloudflare Agent enregistre automatiquement l’état applicatif dans sa propre base SQLite, puis le recharge après un redémarrage ou une hibernation. Cursor conserve lui aussi l’état des conversations et permet de reprendre les runs. La différence tient au contrôle : Cursor possède le stockage des conversations et le runtime de l’agent, tandis que Cloudflare expose à votre code l’état applicatif et son schéma.

Des étapes durables bien délimitées, sans garantie automatique d’exécution unique. Dans Workflows, chaque étape peut être retentée séparément et produire un état afin que l’exécution survive à une panne réseau ou d’infrastructure, puis reprenne. step.do accepte une configuration de retry propre à chaque étape, NonRetryableError interrompt les nouvelles tentatives en cas d’échec définitif, et chaque ID d’instance est unique dans un Workflow. Mais une étape peut s’exécuter plusieurs fois, et Cloudflare demande explicitement de rendre idempotents les appels qui produisent des effets de bord. L’avantage réside dans la durabilité définie par le développeur et dans le contrôle des retries, pas dans une protection automatique contre les pull requests, e-mails ou débits en double.

Les deux écarts que Cursor n’a toujours pas comblés

Écart 1 : un état d’agent programmable sous le contrôle du client. Cursor a résolu la reprise élémentaire : par défaut, l’état des conversations est conservé indéfiniment, tandis que les snapshots des VM managées suivent une fenêtre glissante de 90 jours d’inactivité. Self-Hosted Machines déplace l’exécution des outils, mais Cursor continue d’opérer la boucle de l’agent et de stocker la conversation. À l’inverse, Cloudflare Agent expose dans le runtime applicatif un état adossé à SQLite. Cette différence compte lorsqu’un agent surveille des incidents, coordonne une migration ou conserve un état métier tout au long d’un onboarding de plusieurs jours.

Cet écart est plus précis que celui décrit en mai. Cursor sait reprendre les runs d’agent de son propre produit. En revanche, il n’expose pas de machine à états appartenant au client, que son application pourrait interroger, enrichir et coordonner indépendamment d’un chat Cursor.

Écart 2 : une surface d’étapes durables définie par le développeur. La documentation actuelle de Cloud Agent et Self-Hosted Machine chez Cursor ne présente aucune primitive applicative équivalente à une étape de Workflow dotée d’un état persistant et d’une configuration de retry propre. Cloudflare, si. La différence devient déterminante dès qu’un agent de codage IA intervient sur la facturation, l’e-mail, le déploiement ou tout autre effet externe.

Déplacer les appels d’outils sur votre propre machine ne comble pas cet écart : cela modifie le lieu d’exécution, pas le contrat d’orchestration. Cloudflare ne garantit pas non plus que les effets de bord ne se produisent qu’une fois ; une étape susceptible d’être retentée doit toujours être idempotente.

Il ne s’agit pas de dénigrer Cursor, mais de distinguer deux catégories. Cursor est un produit dédié au développement logiciel qui propose une exécution des outils aussi bien managée que pilotée par le client. Cloudflare est un runtime applicatif programmable. La sortie de septembre réduit l’écart d’infrastructure, mais la frontière de l’état et de l’orchestration continue de les séparer.

Ce que les fondateurs et CTO devraient faire cette semaine

Trois profils appellent trois décisions différentes.

Pour une petite équipe produit qui livre des fonctionnalités, les Cloud Agents managés par Cursor conviennent dès lors que leurs environnements et leurs contrôles réseau reproduisent votre build. La sortie du 13 mai prend en charge la configuration multi-repos, les secrets de build, le cache et l’auditabilité ; le chiffre public de Cursor, selon lequel plus de 30% de ses PR fusionnées proviennent d’agents, sert de preuve. N’exploitez pas une flotte de workers sans raison liée à vos règles internes.

Si Cloudflare ou Vercel héberge déjà vos processus d’arrière-plan de longue durée, conservez-y l’état applicatif durable et l’orchestration. Cursor Self-Hosted Machines peut désormais utiliser une infrastructure Cloudflare ou Vercel pour exécuter les outils, mais Cursor reste propriétaire de la boucle de l’agent. Un parallèle côté utilisateurs mérite aussi le détour : il montre comment Anthropic regroupe des primitives comparables pour les PME. Cette convergence des plateformes vers les agents apparaît partout.

Pour préparer un déploiement en entreprise, commencez par les Cloud Agents managés si les listes d’autorisation, Tailscale, AWS PrivateLink ou Cloudflare Tunnel répondent aux exigences d’accès. Passez à Team Pools lorsque le checkout, l’exécution des outils, le matériel personnalisé ou l’image du worker doivent rester sous votre contrôle. Team Pools nécessite Enterprise, dont le prix est sur devis, et les Dockerfiles configurés par Cursor restent en bêta privée.

Ce qui a changé depuis mai

Deux signaux se dégagent.

Premièrement, Cursor documente désormais l’état des conversations séparément du workspace d’exécution. Cet état est conservé indéfiniment par défaut afin de permettre la consultation et la reprise des runs ; les snapshots des VM managées expirent après 90 jours d’inactivité, sauf si un démarrage ou une reprise prolonge la fenêtre. La reprise élémentaire n’est donc plus un écart. Restent en revanche les questions de propriété et de programmabilité.

Deuxièmement, l’exécution dans un environnement privé n’est plus un écart non plus. Self-Hosted Machines y répond tout en laissant dans le cloud de Cursor la boucle de l’agent, l’inférence et la planification. L’état d’agent sous contrôle du client et une surface d’étapes durables définie par le développeur restent les deux différences de fond.

La sortie de Cursor du 13 mai rend-elle inutile une infrastructure d’agents auto-hébergée ?

Non. Cursor propose désormais sa propre voie auto-hébergée : My Machines pour les workflows individuels et Team Pools pour les flottes Enterprise. L’exécution des outils passe dans votre réseau, mais Cursor continue d’opérer la boucle de l’agent et de stocker l’état des conversations. Les équipes qui ont besoin d’un runtime applicatif programmable ou d’étapes de workflow durables doivent toujours disposer d’une infrastructure pour ces couches.

À quelle vitesse s’exécutent désormais les builds en cache des agents cloud Cursor ?

Après l’amélioration du cache des layers du 13 mai, les builds avec cache hit s’exécutent 70% plus vite. Seules les layers modifiées du Dockerfile sont reconstruites.

Que signifie le chiffre interne de Cursor sur les PR fusionnées ?

La page officielle actuelle de Cursor indique que plus de 30% des pull requests qu’il fusionne sont créées par des agents autonomes opérant dans des sandboxes cloud. Ce chiffre fournit un indicateur utile de l’adoption en production, car il mesure les pull requests fusionnées et non les tâches tentées.

Les agents cloud Cursor sont-ils sûrs pour du code qui accède aux secrets de production ?

La sortie du 13 mai définit des listes d’autorisation de trafic sortant et des périmètres de secrets propres à chaque environnement, isole les secrets de build de l’agent en cours d’exécution et fournit un historique des versions, un rollback ainsi que des journaux d’audit. Self-Hosted Machines peut conserver l’intégralité du checkout et les identifiants locaux à la machine sur votre worker, mais les contenus de fichiers nécessaires, les sorties des outils, les diffs, les captures d’écran et les résultats MCP locaux peuvent toujours parvenir à Cursor. La sécurité suppose de valider ces deux frontières.

Puis-je utiliser Cloudflare Workers et les agents cloud Cursor côte à côte ?

Oui. Cursor référence Cloudflare parmi les intégrations de Self-Hosted Machines, et son template de référence utilise un Cloudflare Worker comme contrôleur afin de démarrer un Cloudflare Container pour chaque requête prise en charge. Cursor peut gérer la boucle de l’agent de codage, tandis que Workers, Durable Objects et Workflows prennent en charge l’état applicatif durable et l’orchestration. Les produits se chevauchent désormais au niveau de l’exécution des outils, mais pas à la frontière de la boucle de l’agent.