Cursor v2 : L'IA qui a dévoré VS Code

L'IA en matière de codage vient de déclencher une nouvelle course aux armements. Cursor v2, un fork de VS Code qui n'est apparu il y a que six mois, propose désormais son propre modèle de classe frontière, un essaim multi-agents, et un navigateur directement intégré dans l'éditeur. Dans une industrie qui considère encore Copilot comme un simple compléteur sophistiqué, Cursor vise ouvertement l'ensemble de la pile IDE.

Le timing de Cursor fait que le lancement semble moins être une mise à jour de fonctionnalités et plus une véritable avancée, comme un coup de maître. Les estimations d'une valorisation d'environ 10 milliards de dollars se trouvent maintenant à côté d'un lancement en version 2 qui a eu lieu le 29 octobre, à peine six mois après le fork de VS Code. Ce rythme indique une entreprise qui ne veut pas être un simple plugin dans l'écosystème de Microsoft ; elle veut être l'écosystème.

Au centre se trouve Composer, le modèle de codage interne de Cursor, évalué comme étant environ 4 fois plus rapide que les systèmes concurrents pour des tâches similaires. Dans une situation donnée, Composer termine un travail de codage complexe en environ 28 secondes, alors que Claude peut y mettre plus de 2 minutes. Cursor ne considère pas cela comme une simple économie de latence, mais comme la couche permettant de faire fonctionner des dizaines d'agents par développeur sans exploser le budget.

La vitesse n'est qu'une partie de la provocation. Cursor v2 transforme le paradigme de l'assistant unique en une escouade de huit agents, chacun travaillant dans des arbres de travail isolés afin qu'ils ne se chevauchent jamais lors des engagements. Vous ne poussez plus un seul chatbot ; vous déléguez à une petite équipe d'IA capable de refactoriser, d'écrire des tests et de prototyper des fonctionnalités en parallèle.

La question qui plane sur chaque démo est directe : cela rend-il les flux de travail de codage traditionnels obsolètes ? Si un système multi-agents peut explorer plusieurs implementations, exécuter des tests dans une fenêtre Chrome intégrée, et révéler des différences à proprement parler plus rapidement qu'un humain ne peut préparer l'environnement, le rôle de l'IDE évolue d'éditeur à centre de commande. VS Code commence à ressembler à un cockpit très raffiné pour un pilote unique dans un monde en transition vers des escadrons autonomes.

Ce que Cursor v2 remet vraiment en question, c'est la définition d'un "développeur". Lorsque votre travail principal consiste à assigner des tâches, à examiner des différences et à orchestrer des agents, l'IA cesse d'être un outil d'aide et commence à ressembler à un membre d'équipe indispensable. C'est la limite que Cursor ose défier pour le reste du monde des outils.

Composer est le coup de maître de Cursor : un modèle de codage mélange d'experts de marque déposée conçu en interne plutôt que loué à OpenAI ou Anthropic. Ce changement peut sembler cosmétique, mais il transforme discrètement le modèle commercial de « paiement à la demande » en « possession du moteur », ce qui est important lorsque votre IDE fonctionne soudainement avec une équipe d'assistance IA au lieu d'un simple assistant.

Cursor qualifie Composer de modèle de classe frontière, mais le titre est la vitesse. Dans la démonstration de Better Stack, Composer termine une tâche de codage non triviale en environ 28 secondes, alors qu'une exécution comparable sur Claude dépasse les 2 minutes sur le même prompt. Ce gain de vitesse d'environ 4× n'est pas une micro-optimisation ; c'est la différence entre « attendre le bot » et « maintenir votre état de flux pendant que les agents travaillent ».

La latence drive tout ici. Cursor affirme que Composer traite environ 250 tokens par seconde, suffisamment pour diffuser des explications et des différences presque aussi vite que vous pouvez faire défiler. Lorsque chaque cycle d'agent se termine en moins d'une demi-minute, vous cessez de regrouper d'énormes tâches et commencez à envoyer en continu des plus petites.

Posséder Composer en propre permet également à Cursor de réduire le coût par tâche à un niveau qui rend le développement multi-agents financièrement viable. La vidéo s'appuie sur une métrique simple mais brutale : le coût par tâche est désormais suffisamment bas pour que les équipes “utilisent des dizaines d'agents par développeur” sans exploser leur budget. Cela n’est possible que lorsque vous ne payez pas des tarifs d'API de modèle à la pointe pour chaque boucle d'agent.

Les systèmes multi-agents ont toujours bien rendu sur les diagrammes, mais se sont effondrés dans la pratique, chaque appel d'agent ressemblant à une petite facture cloud et à une pause café. La combinaison de latence faible et de coût marginal réduit de Composer renverse cette équation. Lancement de 8 agents parallèles dans Cursor v2 devient un flux de travail par défaut, et non un plaisir coupable.

C'est ici que Composer cesse d'être une diapositive de référence et devient une infrastructure. Des appels rapides et à faible coût signifient que vous pouvez avoir un agent rédigant une fonctionnalité, un autre écrivant des tests, un autre en train de refactoriser, et un autre exécutant des vérifications dans le navigateur intégré Chrome, le tout en parallèle. Vous orchestrez, ils travaillent.

Pas une véritable entité, sans un modèle comme Composer au cœur, cette vision s'effondre en file d'attente de prompts dans une boîte de chat. Pas une véritable entité, Cursor v2 peut légitimement revendiquer un véritable flux de travail multi-agents : un IDE où le facteur limitant n'est pas le temps GPU, mais combien de coéquipiers IA un seul humain peut gérer.

Le codage signifiait auparavant ajouter des caractères dans un fichier jusqu'à ce qu'une fonctionnalité apparaisse. Cursor v2 inverse cela : vous décrivez les résultats, déployez des agents et orchestrez une IA qui écrit le code réel. Votre clavier devient moins un ciseau et, non pas une entité propre, une baguette.

Le système multi-agent de Cursor formalise ce changement. Vous pouvez lancer jusqu'à 8 agents parallèles, chacun dans un espace de travail isolé, dédié à un problème spécifique : point d'accès backend, composant React, suite de tests ou migration. Ils ne se marchent jamais sur les pieds, donc votre tâche devient de décider qui fait quoi, plutôt que de micromanager chaque ligne.

Un flux de travail typique commence par une spécification claire. Vous définissez la fonctionnalité, les contraintes et les critères de succès, puis vous la décomposez en tâches de taille appropriée : - Implémenter l'API et le modèle de données - Construire l'interface utilisateur et la connecter à l'API - Générer des tests et des jeux de données - Ajouter des journaux et une observabilité de base

Composer, le modèle mixture-of-experts interne de Cursor, s'attaque ensuite à ces tâches avec rapidité. Cursor affirme que Composer achève des tâches en environ 28 secondes alors que d'autres modèles de pointe prennent près de 2 minutes, ce qui rend l'utilisation de l'expansion multi-agents réellement fonctionnelle dans une boucle étroite. Vous passez en revue les différences, les acceptez ou les ajustez, et relancez les agents jusqu'à ce que l'ensemble de la fonctionnalité passe les tests.

Votre rôle commence à ressembler de manière suspecte à celui de gestionnaire en ingénierie. Vous établissez des limites architecturales, choisissez des modèles et décidez quand il faut refactoriser ou redéfinir. L'équipe d'IA, pas vous, s'occupe des tâches répétitives, du câblage et des refactorisations répétées.

Ce changement a un véritable avantage cognitif. Vous pouvez concentrer votre attention sur « que devrait-il exister ? » et « comment les éléments s'assemblent-ils ? » au lieu de « où va ce support ? » ou « quelle est l'incantation ORM exacte ? » Le contexte reste au niveau du système, et non à celui de la fonction.

L'article de Cursor, Introducing Cursor 2.0 and Composer, s'appuie sur ce modèle d'orchestration : les agents recherchent, modifient, exécutent des outils et même ouvrent une fenêtre Chrome intégrée, pendant que vous élaborez le plan et les fusions. Les développeurs qui réussiront ici ne seront pas les frappeurs les plus rapides. Ils seront les meilleurs chefs d'orchestre.

Cursor v2 fait quelque chose que les précédents copilotes IA n'ont jamais tenté : il déploie une armée d'agents qui travaillent réellement en même temps. Composer peut lancer jusqu'à huit agents parallèles, chacun s'attaquant à une tâche différente pendant que vous voyez les différences arriver en temps réel. Au lieu d'une seule bulle de discussion, vous obtenez un tableau de bord en direct de flux de travail concurrents.

Chaque agent opère dans son propre worktree Git isolé, ce qui résout discrètement le cauchemar des collisions entre intelligences artificielles. Pas de répertoire de travail partagé, pas de fichiers corrompus, pas de drame du type « qui a effacé mes modifications ? ». Lorsque l'agent a terminé, Cursor propose un diff propre que vous pouvez accepter, modifier ou laisser de côté.

Ces espaces de travail isolés sont importants car Cursor encourage un développement véritablement parallèle, et pas seulement un autocomplétion plus rapide. Vous pouvez attribuer un agent pour déchirer un module d'authentification ancien et fragile, un autre pour moderniser votre pipeline de journalisation, et un troisième pour concevoir un nouveau point d'extrémité GraphQL. Chaque agent s'engage dans son propre bac à sable, de sorte que leurs expériences ne s'entremêlent jamais.

Des flux de travail pratiques commencent à ressembler à une petite équipe de développement agile concentrée dans un seul IDE. Imaginez : - Un agent refactorise un processeur de paiement vieux de dix ans en services plus petits et typés - Un autre génère et exécute des tests unitaires pour une toute nouvelle fonctionnalité d'abonnement - Un troisième connecte des appels à une API tierce risquée, complète avec une logique de nouvelle tentative appropriée et des métriques.

Les trois tâches s'exécutent simultanément, sans qu'il y ait une véritable entité Composer gérant le contexte de chaque "worktree". Vous examinez trois différences distinctes, et non un énorme méga-commit conflictué. Ce processus de révision maintient l'humain fermement en contrôle pendant que l'IA s'occupe du travail de base.

Contrastons cela avec les assistants IA précédemment intégrés à des éditeurs comme VS Code ou JetBrains. Ces outils fonctionnaient de manière strictement séquentielle et en mode mono-thread : une requête, une réponse, un fichier à la fois. Si vous vouliez effectuer des tests, des refactorisations et des expériences d'API, vous deviez les mettre en attente manuellement et patienter.

Le système multi-agent de Cursor renverse ce modèle en orchestration parallèle. Votre goulet d’étranglement ne sera plus « combien de temps un assistant peut-il répondre ? » mais « combien de temps pouvez-vous spécifier des tâches et approuver des différences ? » La rapidité de Composer et son faible coût par tâche rendent l'utilisation de plusieurs agents par développeur économiquement viable, et non un simple gadget de démonstration.

Le résultat semble moins être une conversation. Ce n'est pas une entité appropriée, un bot, et pas une véritable entité comme la direction d'une équipe de développement IA interne. Vous divisez le travail en flux, assignez des agents et laissez des arbres de travail isolés maintenir tout séparé. Pour les développeurs qui peuvent penser en parallèle, c'est un superpouvoir.

Cursor v2 fait quelque chose de trompeusement simple mais incroyablement disruptif : il intègre une instance complète de Chrome, avec tous les outils de développement DevTools, directement dans votre éditeur. Pas de fenêtre externe, pas de conteneur Electron faisant semblant d'être un navigateur—c'est une vraie surface de navigateur vivante au sein de la structure de l'IDE, connectée à votre contexte de projet et à vos agents IA.

Le travail frontend signifie généralement vivre dans l'enfer de l'Alt-Tab : éditeur, terminal, navigateur, DevTools, documentation du système de design, peut-être un onglet Storybook. Cursor regroupe toutes ces fenêtres afin que vous puissiez écrire du React, enregistrer, et voir le changement se rendre dans le panneau du navigateur intégré pendant que les requêtes réseau, les journaux de la console et l'inspection du DOM restent épinglés à côté de votre code.

Au lieu de jongler avec les fenêtres, vous scriptiez désormais le navigateur comme n'importe quel autre outil dans votre environnement de développement. Les agents peuvent ouvrir des itinéraires, naviguer dans des flux et capturer la sortie de la console, le tout en regardant le DOM se mettre à jour en temps réel à côté du fichier qu'ils sont en train de modifier.

Parce que le navigateur se trouve à l'intérieur du même environnement d'agent, le système multi-agent de Cursor peut traiter l'interface utilisateur comme une cible de premier ordre, et non comme une réflexion après coup. Un agent peut exécuter des tests d'interface utilisateur de style Cypress, un autre peut ajuster le CSS, et un troisième peut valider les réponses API lors du même chargement de page, le tout sans quitter l'IDE.

Ces agents acquièrent également des superpouvoirs qui nécessitent normalement des scripts personnalisés ou des services externes. Ils peuvent : - Extraire des données à partir de tableaux de bord internes ou de sites de préproduction - Automatiser des flux d'authentification multi-étapes, y compris les redirections et les transferts de jetons - Effectuer des contrôles de régression visuelle en comparant les états rendus à travers les branches

La régression visuelle, en particulier, change de caractère lorsque l'IA peut voir ce qu'elle vient de casser. Un agent peut expédier un refactoring, recharger la page intégrée et signaler qu'un bouton a bougé de 8 pixels ou qu'un commutateur de mode sombre a disparu, puis proposer immédiatement une solution dans le même diff.

Pour les équipes full-stack, cette boucle étroite entre Composer, le code et un navigateur en direct devient une fonctionnalité incontournable. Vous décrivez une fonctionnalité, les agents mettent en œuvre le backend et le frontend, puis ces mêmes agents pilotent la fenêtre intégrée de Chrome pour vérifier l'expérience de bout en bout, transformant Cursor en une interface unique pour le développement web moderne.

L'engouement autour de Cursor v2 repose fortement sur des benchmarks, et certains de ces chiffres sont réels. Sur SWE-bench Verified, le nouveau modèle Composer de Cursor se situe dans le même ordre de grandeur que les modèles de pointe d'OpenAI et d'Anthropic, tout en fonctionnant dans un IDE de bureau plutôt que dans un environnement cloud. Cursor le positionne comme “compétitif, pas un véritable modèle de pointe” plutôt que comme étant définitivement à la pointe de la technologie, ce qui correspond aux données publiques du classement.

La rapidité est le domaine où Cursor se distingue le plus. Il est rapporté que Composer achève des tâches de codage complexes en environ 28 secondes, tandis que des modèles comparables comme Claude peuvent prendre jusqu'à 2 minutes pour terminer la même requête. Pour un développeur qui travaille sur un correctif ou une fonctionnalité, cet écart réduit le temps de retour d’information de « aller prendre un café » à « jeter un œil à son téléphone ».

Ce gain de latence se multiplie lorsque l'on prend en compte la conception multi-agent de Cursor. Huit agents fonctionnant en parallèle, chacun fournissant des réponses en moins d'une demi-minute, signifie que vous pouvez raisonnablement étendre les refactorisations, les tests et les expériences sans que cela ne freine votre propre flux. L'expérience ressemble moins à l'attente d'un seul chatbot et davantage à la consultation de plusieurs PR arrivant presque simultanément.

Le coût peut être le chiffre le plus silencieux mais aussi le plus important. La tarification par tâche du compositeur est suffisamment basse pour que les équipes dans la vidéo affirment qu'elles gèrent « des dizaines d'agents par développeur », sans que cela ne fasse exploser le budget. Des jetons bon marché associés à un haut débit débloquent des comportements qui étaient auparavant inaccessibles, comme le lancement d'agents pour des refactorisations spéculatives ou la génération de tests exhaustive.

« L'IA de codage pratique la plus rapide » reste une affirmation défendable mais chargée. La latence et le prix par tâche semblent excellents, et pour de nombreux flux de travail réels, cette combinaison pourrait surpasser des modèles techniquement plus puissants mais plus lents ou plus coûteux. Quiconque souhaite des preuves devrait commencer par consulter le Changelog officiel de Cursor – Version 2.0 et les classements publics de SWE-bench, puis tester Composer sur leur propre code source avant de déclarer VS Code obsolète.

Les vrais développeurs testent déjà Cursor v2 en production, et les preuves s'accumulent. Dans les forums communautaires et les premières études de cas, les équipes rapportent avoir expédié des fonctionnalités de bout en bout qui prenaient auparavant des jours en une seule après-midi, grâce à Composer et son essaim de huit agents. Un fondateur de startup a décrit avoir donné à Cursor un ticket pour "ajouter SSO non pas une véritable entité Google et GitHub, câblé via notre RBAC existant", et avoir observé les agents créer des flux OAuth, mettre à jour les schémas de base de données et corriger des routes React en moins de deux heures.

Ce ne sont pas des applications de démonstration ou des clones CRUD basiques. Une équipe fintech a utilisé le flux de travail multi-agent de Cursor pour construire un nouveau pipeline de vérification KYC : un agent a intégré une API tierce, un autre a généré des scripts de migration, un troisième a écrit des tests Playwright, tandis qu'un quatrième a intégré des points d'observabilité dans Better Stack. L'ingénieur principal a rapporté avoir réduit le projet d'une estimation de 5 à 6 jours-hommes à "environ 1,5 jour de révision et de nettoyage."

Les motifs se répètent dans des piles très différentes. Les entreprises à forte composante backend s'appuient sur des agents pour : - Mettre en œuvre de nouveaux points de terminaison REST ou GraphQL - Générer et exécuter des migrations - Rédiger des tests d'intégration et des tests de charge

Pendant ce temps, les équipes frontend dirigent Cursor vers “construire ce tableau de bord” et obtiennent des composants React, des styles Tailwind et des tests Cypress en parallèle, puis itèrent avec un retour diff‑level sur l'entité au lieu de modifications manuelles.

Les chiffres de productivité semblent presque irréels, mais ils sont cohérents. Plusieurs adopteurs précoces mentionnent une livraison de fonctionnalités 2 à 3 fois plus rapide. Certains modules en greenfield atteignent jusqu'à 4 fois plus vite lorsqu'ils laissent les agents s'exécuter en parallèle et n'interviennent qu'au moment de la révision. Un responsable d'équipe a décrit un sprint où « la moitié de nos PR fusionnées ont commencé leur vie en tant que branches Cursor », avec des humains agissant comme éditeurs et managers de version plutôt qu'en tant qu'auteurs principaux.

Les vérifications de la réalité sont toujours pertinentes : les agents hallucinent et les refactorisations complexes nécessitent un examen minutieux, mais le travail expédié par Cursor n'est pas hypothétique. Il s'agit de flux de paiement, de consoles d'administration, d'outils internes et de fonctionnalités destinées aux clients déjà en production, validant discrètement un workflow de développement axé sur l'IA.

Le curseur v2 ressemble à un code de triche, mais il ne constitue pas une entité propre avec des bords nets que le marketing de Cursor tend majoritairement à ignorer. La puissance est toujours en balance avec le contrôle, et cette version mise fortement sur la puissance. Les développeurs qui sautent dans l'inconnu ressentiront immédiatement ce fossé.

Commencer n'est pas une véritable entité, l'interface. Cursor 2.0 oriente tout autour des agents et des tâches, et non des fichiers et des dossiers. Pour ceux qui ont grandi avec un arbre de fichiers à gauche, un terminal et quelques panneaux, la nouvelle disposition centrée sur les agents peut donner l'impression d'entrer dans la session tmux de quelqu'un d'autre avec déjà huit volets en cours d'exécution.

Les panneaux pour les exécutions de Composer, les chronologies des agents, les vues diff et le navigateur intégré se disputent tous l'attention. Vous pouvez les apprivoiser, non pas avec de véritables ajustements de disposition des entités, mais en réduisant les panneaux. Cependant, l'expérience par défaut crie "occupé". Les développeurs orientés CLI, en particulier, rapportent que l'interface utilisateur semble "écrasante" jusqu'à ce qu'ils adoptent de nouvelles habitudes autour d'elle.

La fiabilité reste également très dépendante de l'humain. Les flux de travail multi-agents accélèrent la production, mais ils amplifient les refontes halluconnées : les agents réécrivent des chemins de code avec assurance, modifient silencieusement des hypothèses ou "corrigent" des non-bugs. Cursor isole le travail dans des arbres de travail séparés, mais cela ne protège que votre branche principale ; cela ne garantit pas la correction sémantique.

Vous avez toujours besoin d'un véritable processus d'examen : - Lisez chaque diff comme un examen de code - Exécutez votre suite de tests de manière intensive - Ajoutez de nouveaux tests avant de grandes restructurations - Inspectez les journaux et le comportement en temps d'exécution en staging

Traitez les agents comme des juniors surexcités par la caféine, et non comme des seniors infaillibles.

La vie privée pourrait être le champ de mines le plus sous-discuté. Par défaut, Cursor envoie des données vers ses serveurs pour alimenter Composer et ses outils. À moins que vous ne décidiez explicitement de désactiver l'option de confidentialité, votre code, vos requêtes et vos interactions avec l'IA peuvent quitter votre machine pour traitement.

Pour les développeurs solo travaillant sur des projets secondaires, cela peut être un échange acceptable. Pour les industries réglementées, les bases de code d'entreprise, ou tout ce qui touche aux données des clients, cela représente un potentiel cauchemar en matière de conformité. Avant de déployer Cursor v2 à une équipe, les parties prenantes en matière de sécurité et de légalité doivent examiner ces paramètres par défaut, verrouiller les réglages et décider quelles données restent locales.

La programmation en 2026 ressemble moins à de la saisie et n'est pas une entité propre comme la gestion de projet, ni un accès root d'entité appropriée. Des outils comme Cursor v2, Composer et jusqu'à huit agents parallèles récompensent les développeurs capables de traduire les objectifs commerciaux en tâches précises et testables, plutôt que de s'obséder sur la syntaxe et le code standard.

Un travail de grande valeur commence par une décomposition des tâches correcte. Au lieu de "créer l'onboarding", vous le divisez en : - Mettre en œuvre l'API d'inscription par e-mail - Connecter l'interface utilisateur à la nouvelle endpoint - Ajouter des mises à jour optimistes - Intégrer des métriques, des logs et une stratégie de rollback

Chaque tranche devient une spécification autonome que vous pouvez remettre aux agents, comprenant des critères d'acceptation appropriés et des cas limites.

Les indications passent d'un échange informel à la conception de procédures opérationnelles pour les machines. Des indications efficaces ressemblent à de mini documents de conception : contexte, contraintes, interfaces et définitions explicites de "fait". Les développeurs capables d'incorporer les normes de l'équipe—règles de sécurité, budgets de performance, normes de journalisation—directement dans les indications obtiendront des résultats constants et de qualité production de la part de groupes d'agents.

La vérification devient le nouveau débogage. Vous passerez Not a proper entity time : - À lire des différences pour détecter une dérive architecturale et un couplage caché - À exiger des tests générés qui couvrent réellement les cas limites - À instrumenter des fonctionnalités avec des outils d'observabilité Not a proper entity avant la fusion

Les meilleurs développeurs établiront des listes de vérification de vérification répétables : modèles de menace, hypothèses de charge, plans de migration de données et chemins de retour que chaque changement produit par un agent doit passer.

Les développeurs les plus précieux dans cette ère d'agentivité sont ceux qui peuvent orchestrer. Ils vont : - Cartographier les exigences produit vers un travail parallélisable - Décider quand déployer huit agents et quand imposer un chemin unique et soigneux - Équilibrer la vitesse avec les contraintes réglementaires, de sécurité et de fiabilité

La préparation commence maintenant. Entraînez-vous à transformer les tickets Jira en briefs détaillés pour les agents. Associez une IA comme Composer à votre pile actuelle et forcez-vous à examiner, sans réécrire, son travail. Apprenez bien les workflows Git, les arbres de travail isolés et les pipelines CI pour automatiser les garde-fous autour des commits AI.

Enfin, étudiez comment ces systèmes se comportent sous pression. Des références, des études de cas et des explications telles que Cursor 2.0 : Nouveau Modèle d'IA Expliqué – Codecademy montrent où les configurations multi-agents s'excellent et où elles échouent. Les développeurs qui intègrent ces modes d'échec – et conçoivent des processus autour d'eux – s'approprieront la prochaine décennie.

Le pitch nucléaire de Cursor n’a d’importance que si vous pouvez réellement livrer quelque chose. Pas une entité appropriée, mais rapidement. Le flux de travail de 60 secondes de la démo de Better Stack est d'un incroyable simplicité : téléchargez Cursor, lancez Composer, et laissez une multitude d'agents traiter une tâche réelle pendant que vous supervisez les différences.

Rendez-vous sur cursor.com et téléchargez la dernière version pour votre système d'exploitation. Installez-la, puis connectez-vous avec un compte GitHub ou un email, afin que Cursor puisse indexer vos dépôts et établir le contexte du projet.

Ouvrez une véritable base de code, pas un dépôt d'essai. Dans le panneau Composer, décrivez une tâche concrète multi-agent, pour entité non appropriée : « Refactoriser ce composant React en TypeScript, ajouter des types stricts et mettre à jour toutes les importations. » Dirigez Composer vers le répertoire ou le fichier pertinent afin qu'il puisse définir l'étendue du travail.

Avant de lancer, assurez-vous que les worktrees isolés sont activés dans les paramètres. Cursor utilise ces worktrees pour lancer jusqu'à 8 agents en parallèle, chacun travaillant dans sa propre branche Git afin qu'aucun agent n'écrase les modifications d'un autre ou votre historique principal.

Lancez la tâche et regardez les agents se disperser : l'un pourrait gérer les annotations de type, un autre corrige les imports défectueux, un troisième met à jour les tests. Cursor agrège leur travail en une pile de diffs à la Git au lieu de modifier silencieusement les fichiers sous vos yeux.

Maintenant, agissez comme un responsable technique, pas comme un dactylographe. Passez en revue chaque différence, ligne par ligne, et posez à Composer des questions de suivi lorsque quelque chose semble incorrect : « Pourquoi avez-vous élargi ce type à n'importe quel ? » ou « Annulez ce changement et conservez l'ancienne signature. » Approuvez, ajustez ou rejetez.

Vous venez de faire fonctionner votre première équipe d'IA en moins d'une minute. Installez Cursor, branchez Composer, maintenez les arbres de travail isolés, puis lancez une véritable fonctionnalité ou une refonte et voyez jusqu'où vous pouvez pousser 8 agents en parallèle. Ensuite, dites à votre équipe si le codage donne toujours l'impression d'être en 2025.

Qu'est-ce que Cursor v2 ?

Cursor v2 est une mise à jour majeure de l'IDE Cursor, un fork de VS Code. Elle introduit un système d'IA multi-agents, un nouveau modèle de codage propriétaire appelé Composer, et un navigateur Chrome intégré directement dans l'éditeur.

En quoi Cursor v2 est-il différent de VS Code avec Copilot ?

Bien que Copilot soit un plugin pour VS Code, Cursor v2 reconstruit l'IDE autour de l'IA. Ses principaux points de distinction sont un système multi-agents natif qui exécute des tâches en parallèle, des arbres de travail isolés pour des modifications sécurisées et un navigateur profondément intégré pour les tests d'interface utilisateur.

Quel est le modèle Composer dans Cursor v2 ?

Composer est le premier modèle d'IA interne de Cursor, conçu spécifiquement pour les tâches de codage. Il a été conçu pour la rapidité, capable de résoudre des tâches complexes en moins de 30 secondes — apparemment 4 fois plus rapide que des modèles comparables — rendant les flux de travail multi-agents économiquement viables.

Quelles sont les principales critiques de Cursor v2 ?

Les utilisateurs ont souligné trois problèmes principaux : la nouvelle interface centrée sur l'agent peut être écrasante pour les développeurs traditionnels, les agents IA peuvent encore 'halluciner' du code incorrect, et les utilisateurs doivent se désinscrire manuellement de la collecte de données pour des raisons de confidentialité.