Cursor 3 : une nouvelle ère du codage avec IA et des agents parallèles

Quoi de neuf dans Cursor 3 ?

La version 3.0 met davantage l'accent sur l'infrastructure que sur le polissage de l'UI. Voici ce qui change vraiment.

Espace de travail unifié pour les agents

Toute l'activité des agents vit désormais dans une même interface. La barre latérale affiche chaque agent en cours d'exécution sur votre machine ou dans le cloud, y compris ceux lancés depuis Slack, GitHub, Linear, mobile et le web. Une vue unique.

L'espace de travail est conçu multi-repo. Un agent peut mettre à jour des composants frontend pendant qu'un autre corrige une bibliothèque backend. Avant Cursor 3, cela exigeait des fenêtres d'IDE séparées et un changement de contexte permanent.

Deux ajouts à noter : les onglets d'agents permettent d'afficher plusieurs conversations d'agents côte à côte ou en grille. Les chats d'agents sont aussi des onglets d'éditeur standards ; les volets partagés et raccourcis clavier fonctionnent comme attendu. Pas de réapprentissage. Le mode Design a sa section dédiée ci-dessous.

Exécuter plusieurs agents en parallèle

La commande /best-of-n s'exécute dans le chat d'agent au sein de l'IDE, pas dans la fenêtre Agents. Pour l'utiliser, ouvrez un dépôt Git, ouvrez Agent Chat dans la disposition classique de l'éditeur, puis lancez /best-of-n suivi d'une liste de modèles séparés par des virgules et de votre tâche. Par exemple : /best-of-n sonnet, gpt, composer fix the flaky logout test.

Cursor crée un worktree Git séparé pour chaque modèle afin d'éviter toute interférence entre les exécutions. Une fois la tâche terminée, vous pouvez passer en revue les sorties, valider et pousser depuis le worktree sélectionné, ou exécuter /apply-worktree pour rapatrier les changements dans votre copie de travail principale. Vous pouvez aussi personnaliser la configuration des worktrees par projet via .cursor/worktrees.json.

Cursor oriente désormais les exécutions parallèles multi-modèles via /best-of-n dans le chat d'agent de l'IDE, tandis que l'ancien flux de sélection n'est plus recommandé.

La commande /worktree suit la même logique : chat d'agent de l'IDE, dépôt Git requis, worktree isolé par agent.

Le choix du « meilleur » reflète les heuristiques d'évaluation de Cursor, pas nécessairement les vôtres. Lisez vous-même les sorties.

Un point pratique : chaque exécution de modèle est facturée indépendamment à son tarif de jetons habituel, sans remise groupée. Trois modèles signifient trois facturations séparées. Je reviens plus loin sur le système de crédits.

Relais entre agents locaux et cloud

Les agents cloud tournent sur des machines virtuelles Ubuntu isolées. Le transfert fonctionne dans les deux sens.

Passer du cloud au local vous donne accès à votre système de fichiers, à votre serveur de dév local et à vos outils de test desktop. Envoyer une session dans le cloud permet aux tâches longues de continuer après la fermeture de votre ordinateur. Quand l'agent termine, les résultats vous attendent dans la fenêtre Agents. Les agents cloud produisent aussi des démos et des captures de leurs travaux, que vous pouvez consulter avant de rapatrier quoi que ce soit en local.

Les sessions d'agents circulent dans les deux sens entre le local et le cloud. Image de l'auteur.

Pour les équipes entreprises, des agents cloud auto-hébergés sont disponibles depuis le 25 mars 2026. Le code, l'exécution d'outils et les artefacts de build restent dans votre propre infrastructure. Un processus worker se connecte en sortie au cloud de Cursor via HTTPS, sans ports entrants ni VPN requis. Les agents auto-hébergés sont réservés à l'offre Enterprise ; les agents cloud standards sont disponibles avec Pro et au-delà.

Vous pouvez définir l'environnement cloud avec un fichier .cursor/environment.json à la racine du dépôt. Stockez les secrets dans l'onglet Secrets des réglages Cursor plutôt que dans ce fichier.

Du commit à la pull request en un seul flux

La nouvelle interface de diff permet de voir les changements au mot près, de préparer les commits et d'ouvrir une pull request sans quitter la fenêtre Agents. Le rendu des diff de gros fichiers est plus rapide et moins gourmand en mémoire en 3.0.

Quand vous utilisez /worktree dans l'éditeur classique, chaque agent travaille sur son worktree isolé, donc les diff sont déjà propres au moment de la revue. Pas de chevauchements à démêler.

Cursor a également annoncé le 18 décembre 2025 un accord d'acquisition de Graphite, un outil de gestion de pull requests. Je l'aurais presque omis faute de détails d'intégration confirmés, mais cette acquisition pourrait remodeler ce flux une fois finalisée.

Mode Design et navigateur intégré

Décrire un changement d'UI par écrit est plus lent que de le montrer. Le mode Design corrige cela.

Appuyez sur Cmd+Shift+D pour activer l'outil de sélection sur le navigateur intégré. Utilisez Shift+drag pour sélectionner une zone, Cmd+L pour injecter un élément sélectionné dans le chat d'agent, ou Option+click pour l'ajouter au champ de saisie. L'agent reçoit le HTML, le CSS appliqué et la boîte englobante visuelle. Au lieu d'écrire un paragraphe pour décrire le problème de mise en page, vous sélectionnez l'élément et dites : « resserrez ceci ».

Le navigateur inclut également Chrome DevTools. Les agents peuvent lancer un serveur de dév local, cliquer sur des boutons, lire les logs console et vérifier que leurs changements fonctionnent vraiment.

Composer 2 : le modèle de codage intégré de Cursor

Composer 2 a été lancé le 19 mars 2026, deux semaines avant Cursor 3. C'est le modèle qui propulse les agents dans le nouvel espace de travail.

Il est construit sur une base Kimi K2.5 de Moonshot AI, avec un pré-entraînement continu et un apprentissage par renforcement 4 fois plus étendu par-dessus. Cursor n'avait pas dévoilé le modèle de base au lancement. Un utilisateur l'a trouvé dans les en-têtes API le lendemain. Le cofondateur Aman Sanger a reconnu l'oubli : « Ne pas mentionner Kimi comme base dans notre billet dès le départ était une erreur. Nous corrigerons cela pour le prochain modèle. »

Si les benchmarks ne sont pas votre truc, la version courte : Composer 2 est plus rapide et moins cher que les alternatives tierces. Passez directement au tableau de tarifs ci-dessous.

Sur le CursorBench de Cursor, Composer 2 obtient 61,3 contre 44,2 pour Composer 1.5, soit environ +39 %. Il débite plus de 200 jetons/seconde, en partie grâce à des kernels GPU maison plutôt que de s'appuyer uniquement sur des stacks d'inférence tierces. CursorBench n'est pas auditable indépendamment, à garder en tête. GPT-5.4 le dépasse sur des tâches plus dures, mais sur CursorBench (352 lignes en moyenne sur huit fichiers), Composer 2 surpasse Claude Opus 4.6 pour un coût par jeton environ 90 % plus bas. Cet écart de coût est le chiffre le plus parlant.

Voici le détail des tarifs :

Sur les plans individuels payants, Composer 2 dispose de son propre réservoir d'usage, distinct des crédits pour les modèles de pointe sélectionnés manuellement. La facturation est basée sur la dépense, pas sur le nombre de requêtes. La répartition complète des crédits est dans la section tarifs ci-dessous. Le modèle offre une fenêtre de contexte de 200 000 jetons avec auto-résumé : quand le contexte est plein, il compresse à environ 1 000 jetons et continue.

Composer 2 est conçu spécifiquement pour le codage agentique. Il ne vous aidera pas pour autre chose.

Cursor 3 comme environnement de développement à dominante agents

Le CEO de Cursor, Michael Truell, décrit trois ères du développement logiciel avec l'IA. D'abord l'autocomplétion par Tab, pour le code répétitif. Puis les agents synchrones, guidant le modèle étape par étape. Désormais des agents cloud opèrent en autonomie sur des durées plus longues, les développeurs jouant le rôle de chef d'orchestre plus que de rédacteur.

Les données d'usage confirment ce glissement. Comme noté plus haut, le ratio agents/Tab s'est inversé entre début 2025 et début 2026.

Selon Truell : « Cursor n'est plus principalement un outil pour écrire du code. Il aide les développeurs à construire l'usine qui fabrique leur logiciel. » C'est une vision, pas une fiche produit. La plupart des développeurs sous Cursor 3 passent encore leur temps à relire et corriger la sortie des agents. Je n'ai pas vu de codebase où l'usine tourne seule. Mais l'interface est conçue en partant du principe que ce futur est plus proche qu'il n'y paraît.

Fonctionnalités clé qui subsistent et s'améliorent

Les fonctions cœur des versions précédentes sont toujours là et globalement inchangées.

Compréhension des fichiers et du code

Le support complet du Language Server Protocol (LSP) demeure. Aller à la définition, recherche de symboles, documentation au survol et navigation dans les fichiers fonctionnent comme dans VS Code. Les références de contexte comme @Files, @Folders et @Docs sont prises en charge. La fenêtre Agents n'enlève pas l'accès au niveau fichier ; elle ajoute une couche au-dessus.

Cursor Marketplace et plugins

Le Cursor Marketplace ajoute des capacités aux agents par installation de plugins en un clic. Un plugin regroupe un mix de Skills (prompts que les agents peuvent appeler à la demande), Subagents, serveurs MCP, Hooks et Rules. Détail complet dans la documentation Cursor.

Les plugins disponibles couvrent un large éventail : AWS, Figma, Linear, Stripe, Vercel, Datadog, Snowflake, et plus encore. Les offres Teams et Enterprise peuvent configurer des marketplaces privées d'équipe. En Enterprise, l'import de plugins tiers est désactivé par défaut sauf action d'un administrateur.

Une lacune qui ne devrait pas exister : il n'y a pas d'UI intégrée pour définir des variables d'environnement pour les serveurs MCP des plugins Marketplace. Le contournement consiste à ajouter manuellement le serveur à ~/.cursor/mcp.json avec un champ env et à désactiver l'entrée dupliquée dans les réglages de Cursor. Cela fonctionne, mais c'est typiquement le genre de chose qui ne devrait pas nécessiter un contournement dans un produit payant.

Automations

Automations, lancé le 5 mars 2026, sont des agents toujours actifs déclenchés par des événements externes : planifications, messages Slack, tickets Linear, événements GitHub et incidents PagerDuty. L'agent lance un bac à sable cloud et suit les instructions en utilisant les MCP et modèles configurés. Quand la mémoire est activée, l'agent accède à un bloc-notes persistant (petits fichiers texte comme MEMORIES.md qui survivent entre exécutions). L'agent choisit quoi y écrire : avancement, motifs repérés, contexte des exécutions précédentes. L'exécution suivante lit ces notes et reprend là où elle s'était arrêtée. Vous pouvez voir et éditer ces fichiers dans la section Automations du tableau de bord.

Tarifs de Cursor 3 et exigences d'offre

Toutes les fonctions ne sont pas disponibles sur chaque offre. Voici la répartition actuelle :

Les agents cloud et Composer 2 exigent Pro ou plus. Les marketplaces d'équipe nécessitent Teams ou Enterprise, et les agents cloud auto-hébergés sont réservés à Enterprise.

Cursor fonctionne avec deux réservoirs de crédits distincts sur les plans individuels payants : l'un pour le mode Auto et l'usage de Composer, décrit par Cursor comme « généreux » sans plafond publié, et l'autre pour les modèles de pointe sélectionnés manuellement comme Claude ou GPT. Quand vous choisissez un modèle manuellement, il puise dans le réservoir de crédits. Le mode Auto, non.

Note pour gros utilisateurs : des développeurs sur l'offre Pro qui lancent souvent des sessions d'agents rapportent une dépense réelle plutôt autour de $40 à $50 par mois une fois les dépassements enclenchés. Les $20 sont un plancher.

Comment Cursor 3 change les workflows des développeurs

Voici une comparaison concrète pour une tâche backend API standard :

Le changement n'est pas de pénible à facile, mais d'écriture à direction. Vous passez moins de temps à implémenter et plus à définir le besoin et à relire la sortie. La valeur de cet échange dépend de la tâche, et honnêtement du niveau de confiance que vous accordez à l'agent ce jour-là.

Les tâches longues en profitent le plus. Un refactor qui prendrait des heures au terminal peut partir à un agent cloud ; vous fermez votre ordinateur, l'agent continue, et les diff vous attendent à votre retour.

Cursor 3 vs versions précédentes de Cursor

Aux débuts de Cursor (2022 à 2024), l'outil était d'abord un IDE. Édition de fichiers assistée par IA dans un environnement VS Code.

Cursor 1.0 (juin 2025) a été la première version stable. Cursor 2.0 (octobre 2025) a apporté le premier modèle Composer et le navigateur in-app. Cursor 2.5 (février 2026) a ajouté des sous-agents asynchrones et le marketplace de plugins. Cursor 2.6 (mars 2026) a ajouté les marketplaces d'équipe.

Cursor 3.0 acte le virage. Les agents cloud sont sortis de l'éditeur et résident désormais exclusivement dans la fenêtre Agents. Le support des worktrees a aussi évolué : l'ancien menu déroulant est déprécié et remplacé par les commandes /worktree et /best-of-n qui s'exécutent dans le chat de l'éditeur classique. Si vous avez une documentation interne expliquant comment utiliser le menu worktree ou lancer des agents cloud depuis l'éditeur, elle est obsolète.

Cursor a profité de la refonte 3.0 pour résorber la dette de performance des 2.x : correctifs de fuites mémoire/CPU, React Compiler. Robinson parle d'un résultat plus rapide et moins sujet aux hoquets UI. Windows est pleinement supporté, et l'interface gère plusieurs workspaces dans une seule fenêtre.

Le saut de 2.x à 3.0 est plus structurel qu'il n'y paraît. Les versions précédentes ajoutaient des fonctions d'agents à un IDE. Cursor 3 ajoute un IDE à une plateforme d'agents. L'ordre a son importance.

Cursor 3 vs IDE traditionnels

Les IDE traditionnels sont centrés sur les fichiers. Vous ouvrez un fichier, vous éditez du texte, et l'IDE vous aide à taper plus vite. Même avec GitHub Copilot, l'abstraction reste le document.

Cursor 3 relègue le fichier au second plan. L'interface principale est la file de tâches. L'IDE devient le filet de sécurité pour les éditions trop spécifiques pour être promptées.

La comparaison devient toutefois plus floue. GitHub Copilot propose désormais des agents cloud et de la revue de code sur ses offres individuelles. JetBrains inclut Junie, son agent de codage autonome, avec ses abonnements AI. Et, comme mentionné plus haut, Cursor tourne maintenant dans les IDE JetBrains via ACP. Tout le monde a des agents. La vraie différence avec Cursor 3, c'est que l'espace de travail a été conçu autour d'eux, au lieu d'être ajouté à un éditeur existant.

Limitations et questions ouvertes

L'expérience au quotidien est plus heurtée que ne le laissent entendre les supports de lancement.

Supervision par les développeurs

Les agents se trompent. Sur des tâches complexes multi-fichiers, ils se trompent souvent. Relire la sortie d'un agent exige une familiarité suffisante avec la base de code pour détecter les hypothèses fausses, les fonctions hallucinées et les logiques à deux doigts de marcher. Le temps gagné à l'écriture se déplace vers la lecture et la validation. Des développeurs incapables de lire et vérifier le code généré ne pourront pas garder la base de code en état. Ce n'est pas un reproche spécifique à Cursor ; cela vaut pour tous les outils de codage à base d'agents.

Fiabilité des agents cloud

Les échecs de configuration d'environnement sont un problème connu et suivi. Les secrets ne peuvent pas être injectés pendant le script d'initialisation, seulement après. Des sessions parallèles prolongées consomment beaucoup de ressources ; des utilisateurs ont signalé une forte consommation de RAM sur des machines pourtant à la hauteur. Gardez les sessions sous deux heures si possible et ajoutez des points de réindexation pour plus long.

Autre lacune précise : Plan Mode n'est pas encore disponible dans l'interface web de Cursor. Vous pouvez lancer et exécuter des agents cloud, y compris la planification, depuis l'app desktop Cursor 3, mais pas directement depuis cursor.com/agents.

Il existe aussi un bug connu où les agents se figent quand la fenêtre Agents n'est pas au premier plan. Signalé peu après le lancement, il n'était pas résolu début avril 2026. Pour un outil fondé sur des sessions longues, c'est un vrai souci.

Sur les agents parallèles en général : des recherches de Google DeepMind sur les systèmes multi-agents ont relevé une amplification d'erreur jusqu'à 17,2 fois dans des réseaux non structurés. Même à 99 % de fiabilité par agent, dix agents chaînés tombent à environ 90 % au global. La commande /best-of-n utilise des worktrees isolés, ce qui limite une partie de cela. Sans l'éliminer.

Considérations de sécurité

Deux CVE ont été découvertes et corrigées en 2025. CVE-2025-54136 (MCPoison) permettait à des outils MCP approuvés de voir leurs commandes modifiées silencieusement ; corrigé en version 1.3. CVE-2025-64106 était une vulnérabilité RCE via deep-link avec une gravité de 8,8, corrigée en deux jours. Workspace Trust est également désactivé par défaut. Si vous connectez des outils MCP en environnement sensible, cela compte.

Les agents cloud auto-hébergés, comme vu plus haut, gardent le travail des agents dans votre réseau, mais la plateforme Cursor elle-même n'est pas déployable entièrement on-premises. Cursor n'a pas de certification FedRAMP ni HIPAA. La disponibilité d'un BAA n'est pas documentée publiquement ; confirmez directement avec Cursor avant d'engager des décisions de conformité. Si votre environnement exige FedRAMP ou un déploiement totalement on-prem, Cursor 3 ne convient pas.

Deux autres limites pratiques à signaler : le mode Design ne fonctionne actuellement que dans Chrome ; Firefox et Safari ne sont pas supportés. Et, dans les jours suivant le lancement de Cursor 3, la communauté a signalé une consommation de jetons de Composer 2 environ 10 fois supérieure à la normale pour certains utilisateurs, liée à des problèmes de lecture de cache.

Le modèle de crédits

Comme mentionné dans la section agents parallèles, chaque modèle /best-of-n est facturé séparément. Une comparaison de trois modèles sur une tâche complexe peut épuiser une grande partie de votre réservoir mensuel en une seule session.

Pour qui Cursor 3 est-il fait ?

Si vous utilisez déjà des workflows assistés par agents et voulez tout centraliser, c'est fait pour vous. Cela prend tout son sens pour des équipes multi-repo, des tâches longues à confier au cloud, et pour des équipes Enterprise qui doivent garder le code dans leur propre infrastructure.

Je ne le recommanderais pas aux débutants. Non pas parce qu'il est difficile à utiliser, mais parce que les agents produisent du code qu'il faut lire avec esprit critique. Si vous ne voyez pas quand la sortie est fausse, vous ne pouvez pas la corriger, et dans six mois la base de code s'en ressentira. Pour des scripts simples ou des tâches ponctuelles, l'overhead d'installation ne vaut pas le coup non plus. Et si votre environnement est régi par HIPAA ou cloisonné, lisez la section Sécurité avant d'aller plus loin.

Les gros monorepos hérités posent aussi un vrai problème. Les fenêtres de contexte s'y cassent encore.

L'avenir du codage avec IA et Cursor

En février 2026, Cursor a publié « Towards Self-Driving Codebases », décrivant des expériences avec des milliers d'agents orchestrés sur de grandes bases de code. Objectif affiché : « jusqu'à ce que les codebases deviennent autonomes ».

Les fenêtres de contexte cassent toujours sur les grands monorepos. Les agents hallucinent régulièrement. La vision est suffisamment lointaine pour éviter d'en faire un axe de planification.

Ce que fait Cursor 3, c'est mettre en place les pièces principales : un modèle avec Composer 2, une interface avec la fenêtre Agents, des VM cloud comme runtime, et des options auto-hébergées pour l'entreprise. La base de code « autonome » dépend d'améliorations de modèles que Cursor ne maîtrise pas totalement.

Le cadrage « usine » de Truell est encore loin. Pour l'instant, c'est toujours vous qui inspectez la chaîne de production.

Conclusion

Le principal changement de Cursor 3 n'est pas une fonction. C'est une interface repensée autour d'une autre hypothèse : l'agent, pas le fichier, est l'unité de travail. Il y a deux ans, c'était un pari. Les données d'usage montrent qu'il porte ses fruits.

La pertinence pour votre workflow dépend de facteurs que je ne peux pas déterminer d'ici : taille de la base de code, exigences de sécurité, et votre tolérance pour un produit tout juste lancé et encore perfectible. En cas d'hésitation, relisez la section Limitations avant de trancher.

Pour aller plus loin avec Cursor en pratique, notre cours Software Development with Cursor couvre le prompting, le refactoring, les tests et les workflows d'agents.