Cursor Cloud-Agents : Coder, même lorsque le portable est éteint

Q: Puis-je vraiment fermer mon ordinateur portable ?

Oui. En mode Plan, "Build in Cloud" transfère l'exécution à un agent cloud qui continue de fonctionner côté serveur. Le résultat peut être récupéré ultérieurement en un clic dans l'environnement local.

18 juin 2026

5 min de lecture

Cursor permet désormais à ses agents de codage de poursuivre leur travail dans le cloud, même lorsque l’ordinateur portable est fermé. En passant en mode Plan sur « Build in Cloud », l’exécution est transférée à un agent cloud qui continue de fonctionner dans un environnement Ubuntu isolé, tandis que le développeur travaille en local ou éteint sa machine. L’agent prépare la pull request, fournit des démonstrations et des captures d’écran pour vérification, et peut être basculé d’un simple clic entre le cloud et l’environnement local. Cela semble pratique, mais cela soulève en réalité la question de savoir où le logiciel est développé – et donc où il doit être sécurisé.

Les points clés en bref

Les agents de codage migrent vers le serveur : Cursor exécute des agents en arrière-plan dans des machines virtuelles cloud isolées, indépendamment de l’éditeur local, et ceux-ci continuent de fonctionner même lorsque l’ordinateur portable est fermé.
Les avantages sont concrets : Les tâches parallèles, une pull request prête à l’emploi et la possibilité de basculer entre le cloud et le local soulagent les développeurs et accélèrent le processus.
L’addition arrive plus tard : Les agents côté serveur consomment des ressources cloud et opèrent, selon la configuration, sur des dépôts et des secrets. Les coûts et la sécurité des builds doivent être anticipés avant le déploiement, et non après.

En lien :Coolify à l’essai : l’autohébergement comme alternative à Vercel et Heroku / Quand la facture de l’IA explose le budget cloud

Ce que Cursor a concrètement modifié

Le cœur du changement réside dans un déplacement de l’exécution. L’agent standard de Cursor travaille en ligne dans l’éditeur sur les fichiers locaux, une tâche après l’autre. Les agents cloud, en revanche, fonctionnent de manière asynchrone dans des environnements Ubuntu isolés. Depuis une mise à niveau début 2026, chacun de ces agents dispose d’un environnement de développement complet avec bureau et navigateur, ce qui lui permet d’interagir avec des interfaces et de documenter visuellement les résultats.

Concrètement, cela signifie : en mode Plan, le développeur lance une tâche avec « Build in Cloud » et peut ensuite éteindre son ordinateur. L’agent continue d’itérer côté serveur, prépare la pull request pour la fusion et ne bloque aucune session locale. Pour récupérer le résultat, il suffit d’un clic pour le ramener dans l’environnement local et, si nécessaire, le renvoyer dans le cloud. Selon la documentation de Cursor, les agents cloud génèrent également des démonstrations et des captures d’écran, permettant de vérifier leur travail sans lecture approfondie.

Pourquoi cela compte pour les équipes DevOps

Le gain évident réside dans la parallélisation. Plusieurs agents peuvent travailler simultanément sur différentes tâches sans bloquer l’ordinateur du développeur. Cela déplace le rôle de l’humain de la saisie manuelle vers la supervision : définir les tâches, vérifier les résultats, valider les pull requests.

Pour les équipes DevOps en DACH, le point le plus intéressant est la proximité avec la pipeline. Un agent qui fonctionne jusqu’à la création d’un pull request prêt à l’emploi s’intègre profondément dans le flux de développement. Cela exige des garde-fous clairs : quels dépôts peut-il consulter, quelles actions peut-il déclencher, et qui valide en dernier ressort ? Sans ces règles, un outil de productivité peut rapidement se transformer en automatisme incontrôlé. La question du contrôle des agents autonomes ne concerne plus seulement Cursor, elle préoccupe désormais tous les responsables informatiques.

Le goulot d’étranglement se déplace également. Lorsque les agents livrent du code en quelques minutes, la revue devient le nouveau point critique. Une équipe qui examinait jusqu’ici une poignée de pull requests par jour se retrouve soudain face à un multiple, tous apparemment plausibles. C’est précisément là que se joue le véritable gain de productivité : celui qui ne fait pas évoluer sa capacité de vérification en parallèle ne fait qu’accumuler les risques plus rapidement. Il est judicieux d’établir des critères clairs pour déterminer quelles modifications un agent peut préparer de manière autonome et lesquelles nécessitent toujours une revue humaine, par exemple tout ce qui touche aux dépendances, aux migrations ou à la logique de sécurité.

Ce qui caractérise l’agent cloud

VM isolée environnement Ubuntu dédié par agent, indépendant de l’éditeur.
Ordinateur portable vers l’exécution se poursuit côté serveur, la pull request est préparée à distance.
Transfert passage entre le cloud et l’environnement local en un clic, avec des démonstrations et des captures d’écran pour le contrôle.

La question des coûts reste ouverte

Les agents côté serveur ont un coût. Selon le plan et le contingent, chaque VM cloud qui itère en arrière-plan est comptabilisée comme du temps de calcul consommé, et cela s’additionne lorsque plusieurs agents tournent en continu. Celui qui ne surveille pas les coûts d’inférence et de calcul vit la même mauvaise surprise que certains projets d’IA, lorsque la facture IA a explosé le budget cloud.

Le calcul honnête consiste à opposer les heures de développement économisées aux coûts cloud récurrents. Dans de nombreux cas, cela en vaut la peine, car un agent parallèle remplace un temps d’attente coûteux. Mais cette évaluation doit être faite avant de déployer l’outil à grande échelle, sinon la facture cloud n’apparaît que lorsque le budget est déjà dépassé.

L’environnement de build devient une surface d’attaque

Le deuxième angle mort concerne la sécurité. Un agent cloud qui prépare une pull request travaille sur le dépôt et peut, selon la configuration, accéder aux secrets de build ou même aux droits de déploiement. Ces accès se trouvent ainsi dans un environnement que le développeur ne contrôle plus directement. Une VM isolée aide, mais elle ne remplace pas une gestion rigoureuse des droits.

Il est judicieux de traiter l’agent comme un runner de build supplémentaire : permissions minimales, tokens éphémères, séparation claire entre les droits de lecture et de déploiement, et un journal des actions effectuées. Celui qui introduit des agents côté serveur sans ces fondations élargit sa surface d’attaque précisément là où le code est construit et livré.

S’ajoute à cela la perspective de la chaîne d’approvisionnement. Un agent qui ajoute ou met à jour des paquets prend des décisions sur les dépendances qui se retrouveront ensuite en production. Sans vérification de ces propositions, la responsabilité de la chaîne d’approvisionnement logicielle est transférée, sans qu’on s’en aperçoive, à un modèle. Les équipes qui misent déjà sur des dépendances signées et des builds reproductibles devraient appliquer explicitement ces contrôles à ce qu’apporte un agent cloud.

Foire aux questions

Que sont les agents cloud dans Cursor ?

Des agents asynchrones qui s’exécutent dans des environnements cloud Ubuntu isolés, indépendamment de l’éditeur local. Ils continuent de travailler sur les tâches même lorsque l’ordinateur est éteint et préparent des pull requests.

Puis-je vraiment fermer mon ordinateur portable ?

Oui. En mode Plan, « Build in Cloud » transfère l’exécution à un agent cloud qui continue de fonctionner côté serveur. Le résultat peut être récupéré ultérieurement en un clic dans l’environnement local.

Quel avantage en tirent les équipes DevOps ?

Parallélisme et pull request préparé. Plusieurs agents travaillent simultanément sans bloquer la session locale, et la tâche humaine se recentre sur la définition et la validation.

Quel est le coût d’exploitation ?

Selon le plan et le contingent, chaque machine virtuelle cloud en cours d’exécution consomme du temps de calcul. Les coûts doivent être comparés aux heures de développement économisées avant un déploiement à grande échelle.

Quelles questions de sécurité se posent ?

Selon la configuration, l’agent travaille sur le dépôt et peut accéder aux secrets de build ou aux droits de déploiement. Il doit être traité comme un runner de build : permissions minimales, tokens éphémères et un journal de ses actions.