Accueil › Cursor › Agent Mode

Cursor Agent Mode : le guide complet du mode autonome

Le mode Agent de Cursor est le mode par défaut et le plus autonome de l’éditeur IA : il explore votre codebase, édite plusieurs fichiers, exécute des commandes terminal et corrige les erreurs sans intervention manuelle.

Si vous utilisez Cursor uniquement pour de l’auto-complétion, vous passez à côté de l’essentiel. Le mode Agent transforme l’éditeur en véritable développeur autonome, capable de comprendre un projet entier, planifier les modifications, les implémenter et vérifier le résultat. Depuis la version 2.0 (février 2026), il constitue le cœur de l’expérience Cursor, avec l’arrivée du modèle propriétaire Composer, des Background Agents cloud et des Automations déclenchées par événements.

Ce guide couvre tout : l’activation du mode Agent, les différents sous-modes (Agent, Ask, Manual, Plan), le YOLO mode, les Background Agents, les Cloud Agents, le tout nouveau Composer 2, et les bonnes pratiques pour tirer le maximum de chaque session.

Qu’est-ce que le mode Agent de Cursor ?

Le mode Agent est le mode d’interaction principal de Cursor. Contrairement aux assistants de code traditionnels qui se contentent de suggérer du texte, l’agent Cursor opère comme un développeur autonome à l’intérieur de votre éditeur. Il dispose de tous les outils nécessaires pour mener une tâche de bout en bout : lecture de fichiers, recherche dans la codebase, édition multi-fichiers, exécution de commandes terminal, navigation web et correction automatique des erreurs.

Concrètement, quand vous donnez une instruction à l’agent, il suit un processus systématique en cinq étapes :

La différence fondamentale avec un GitHub Copilot classique : l’agent ne se limite pas au fichier ouvert. Il a une vision complète du projet grâce à l’indexation de la codebase par un modèle d’embedding dédié, ce qui lui permet de comprendre les dépendances, les conventions et l’architecture globale de votre code.

Les quatre modes de Cursor (et quand les utiliser)

Cursor ne se limite pas à un seul mode d’interaction. Depuis la version 2.0, l’éditeur propose quatre modes principaux, chacun optimisé pour un type de tâche spécifique. Vous basculez entre eux avec Cmd+. (Mac) ou Ctrl+. (Windows/Linux), ou en appuyant sur Shift+Tab depuis la zone de saisie.

Mode Agent : le pilote automatique

C’est le mode par défaut et le plus puissant. L’agent a accès à tous les outils : lecture/écriture de fichiers, terminal, recherche dans la codebase, navigation web, MCP (Model Context Protocol). Il fonctionne en autonomie quasi totale. Utilisez-le quand vous savez ce que vous voulez construire et que la tâche touche plusieurs fichiers.

Exemple typique : vous tapez « Ajoute un système d’authentification JWT avec refresh token sur les routes /api/users » et l’agent crée le middleware, modifie les routes, ajoute les types TypeScript, installe les dépendances et lance les tests.

Mode Ask : l’expert en lecture seule

Le mode Ask est en lecture seule. Il explore votre codebase et répond à vos questions sans modifier un seul fichier. C’est votre outil d’investigation avant d’agir. Il est 10 fois plus rapide que de faire du grep manuellement pour comprendre une logique métier complexe.

Exemple : « Comment fonctionne le système de cache dans ce projet ? Quels fichiers sont impliqués ? » L’agent scanne le code, identifie les patterns et vous explique l’architecture sans toucher à rien.

Mode Manual : le contrôle chirurgical

Le mode Manual n’édite que les fichiers que vous sélectionnez explicitement. Pas de recherche automatique, pas de commandes terminal, juste des modifications ciblées. Il est idéal quand vous connaissez exactement les fichiers à modifier et que vous voulez un contrôle total.

Mode Plan : la stratégie avant l’action

Le Plan Mode est probablement le mode le plus sous-utilisé. Il crée un plan d’implémentation détaillé avant d’écrire une seule ligne de code. L’agent explore votre codebase, vous pose des questions de clarification, et génère un plan que vous pouvez revoir et modifier avant de lancer la construction.

Le workflow recommandé pour les tâches complexes : commencez en mode Plan pour définir la stratégie, passez en mode Ask pour investiguer les zones d’ombre, puis lancez le mode Agent pour exécuter le plan validé. Cette approche Plan → Ask → Agent réduit considérablement les erreurs sur les refactorings majeurs.

Modes Custom

Cursor permet aussi de créer vos propres modes avec des combinaisons spécifiques d’outils et d’instructions. Vous pouvez par exemple créer un mode « Review » qui a accès à la lecture de fichiers et au terminal (pour lancer les tests) mais pas à l’écriture de fichiers. C’est un levier puissant pour standardiser les workflows dans une équipe.

Comment activer le mode Agent

Le mode Agent est activé par défaut dans Cursor. Si vous ouvrez le panneau Composer (Cmd/Ctrl + I), vous êtes déjà en mode Agent. Voici comment vérifier et basculer entre les modes :

Méthode 1 : raccourci clavier

Appuyez sur Cmd+. (Mac) ou Ctrl+. (Windows/Linux) pour afficher le sélecteur de mode. L’interface affiche clairement le mode actif (Agent, Ask, Manual, Plan).

Méthode 2 : interface graphique

Ouvrez le panneau Composer (Cmd/Ctrl + I) et regardez le sélecteur en haut du panneau. Cliquez dessus pour basculer entre les modes. En mode Agent, la zone de saisie affiche un texte du type « tell me what to build » au lieu de « ask me code questions ».

Méthode 3 : CLI

Depuis la mise à jour CLI du 16 janvier 2026, vous pouvez lancer directement un mode depuis le terminal avec les flags --mode=agent, --mode=plan, etc.

Indicateurs visuels confirmant que le mode Agent est actif :

Choisir le bon modèle pour l’agent

Le choix du modèle est déterminant pour la qualité et le coût de chaque session Agent. Cursor est multi-fournisseur : vous accédez aux modèles d’OpenAI, Anthropic, Google, xAI et désormais au modèle propriétaire Cursor Composer.

Composer 2 : le nouveau modèle maison de Cursor

Lancé le 19 mars 2026, Composer 2 est le deuxième modèle propriétaire de Cursor, spécifiquement entraîné pour le code. Construit à partir d’un pré-entraînement continu (base : Kimi K2.5 open-source) puis affiné par apprentissage par renforcement sur des tâches de codage longues (centaines d’actions), il offre un rapport intelligence/coût très agressif.

Composer 2 atteint un niveau compétitif face à Claude Opus 4.6 et GPT-5.4 sur les benchmarks de codage, pour une fraction du prix. Le co-fondateur Aman Sanger a précisé que le modèle a été entraîné exclusivement sur des données de code : il ne rédigera pas vos emails et n’écrira pas de poèmes, mais il excelle sur les tâches de développement.

Recommandations par cas d’usage

Le mode Auto de Cursor sélectionne automatiquement le modèle optimal coût/qualité et ne consomme pas vos crédits premium. C’est le choix par défaut recommandé pour la majorité des tâches. Voici quand passer en sélection manuelle :

YOLO Mode : l’autonomie totale

Le YOLO mode (You Only Live Once) est le niveau d’autonomie maximal du mode Agent. Quand il est activé, l’agent exécute les commandes terminal sans vous demander de validation. Il installe des packages, lance des serveurs, exécute des scripts et corrige les erreurs en boucle, le tout sans intervention humaine.

Activer le YOLO mode

Allez dans les paramètres de Cursor, section Features. Cochez la case YOLO mode et acceptez l’avertissement de risque. Vous pouvez configurer :

Une liste d’autorisation (allow list) : les commandes que l’agent peut exécuter sans demander (ex : pnpm, git, npm run dev). Une liste d’exclusion (deny list) : les commandes toujours bloquées. La protection contre la suppression de fichiers : empêche l’agent de supprimer des fichiers sans validation.

Comment ça fonctionne en pratique

En YOLO mode, l’agent suit une boucle autonome : il écrit le code, l’exécute dans le terminal, analyse la sortie, corrige les bugs éventuels, relance, et répète jusqu’à ce que tout fonctionne. C’est spectaculaire quand ça marche : vous pouvez partir d’un répertoire vide et obtenir un projet fonctionnel en quelques minutes.

Voici un scénario typique observé par les utilisateurs :

1. Vous donnez l’instruction : « Crée un serveur Express avec TypeScript, une connexion PostgreSQL et des routes CRUD pour les utilisateurs. »
2. L’agent initialise le projet (npm init), installe les dépendances (express, pg, typescript).
3. Il crée la structure de fichiers, le tsconfig.json, les routes, le modèle de données.
4. Il lance le serveur, détecte une erreur de connexion à la base de données.
5. Il corrige la configuration, relance, vérifie que tout répond correctement.
6. Il vous résume les changements effectués.

Background Agents : le coding parallèle

Les Background Agents sont des agents asynchrones qui s’exécutent dans le cloud, indépendamment de votre machine locale. Ils clonent votre repository GitHub, travaillent sur une branche séparée et poussent leurs modifications sous forme de Pull Request. Vous pouvez en lancer plusieurs en parallèle sur des tâches différentes.

Fonctionnement

Le processus est le suivant : l’agent clone votre dépôt GitHub dans une VM Ubuntu isolée dans le cloud Cursor. Il travaille sur sa propre branche, a accès à internet et peut installer des packages. Une fois la tâche terminée, il pousse le code et crée une PR pour votre revue.

Les Background Agents fonctionnent exactement comme le mode Agent local, mais sans limite de tool calls. Ils peuvent tourner pendant des dizaines de minutes sur des tâches complexes sans que votre laptop ait besoin de rester connecté.

Prérequis

Pour utiliser les Background Agents, vous devez :

Avoir un plan Cursor payant (Pro minimum à 20 $/mois). Connecter votre repository GitHub avec les droits de lecture/écriture. Activer le usage-based spending avec un minimum de 10 $ de fonds. Désactiver le Privacy Mode (le code est envoyé vers des environnements distants).

Stratégies d’utilisation

Les équipes de Cursor elles-mêmes partagent leurs pratiques. Elles lancent souvent plusieurs modèles différents sur le même problème et choisissent la meilleure solution. Les tâches sont distribuées le matin avant d’arriver au bureau, via cursor.com/agents. Pour les features complexes, la stratégie est de créer un plan détaillé localement en mode Plan, puis de transférer l’exécution vers un Cloud Agent.

Les cas d’usage les plus adaptés aux Background Agents sont les petites corrections de bugs, les tâches de migration répétitives, les ajouts de tests unitaires et les refactorings bien définis. Pour les tâches architecturales complexes, il reste préférable de travailler en mode Agent local avec un feedback itératif.

Cloud Agents et Automations

Cloud Agents

Les Cloud Agents sont une évolution des Background Agents. Ils offrent une fiabilité de 99,9 %, un démarrage instantané et une interface de gestion accessible depuis l’éditeur Cursor, le web (cursor.com/agents), Slack, Linear et GitHub. Vous pouvez lancer jusqu’à 8 agents en parallèle sur un seul prompt, chacun isolé dans sa propre copie de la codebase via des git worktrees ou des machines distantes.

Automations (mars 2026)

Depuis le 5 mars 2026, Cursor supporte les Automations : des agents toujours actifs qui se déclenchent automatiquement en fonction d’événements. Les sources de déclenchement disponibles sont Slack, Linear, GitHub, PagerDuty et les webhooks. Quand un événement se produit, l’agent crée un sandbox cloud et exécute vos instructions en utilisant les MCP et modèles que vous avez configurés.

Chaque agent d’automation a aussi accès à un outil de mémoire qui lui permet d’apprendre des exécutions précédentes et de s’améliorer avec le temps. Vous créez vos automations sur cursor.com/automations ou à partir de templates prédéfinis.

Exemple concret : configurez une automation qui écoute les nouvelles issues GitHub avec le label « bug-minor ». Quand une issue est créée, l’agent la lit, explore le code, propose un fix et crée une PR. Vous n’avez plus qu’à reviewer.

Cursor 2.0 : l’interface centrée agents

La version 2.0 de Cursor a redessiné l’interface autour des agents. Les changements majeurs :

Modèle Composer : Cursor dispose désormais de son propre modèle de coding (Composer 2 depuis mars 2026), optimisé pour la vitesse et l’intégration native avec les outils de l’éditeur.

Sidebar agents : une nouvelle barre latérale affiche tous vos agents actifs et leurs plans. Vous gérez jusqu’à 8 agents en parallèle.

Browser intégré : le navigateur est maintenant GA (Generally Available). L’agent peut ouvrir des pages web, sélectionner des éléments du DOM et transmettre les informations au contexte. C’est utile pour débugger des interfaces frontend ou vérifier visuellement les résultats.

Sandbox terminal : les commandes de l’agent tournent par défaut dans un bac à sable isolé sur macOS. Le sandbox a un accès lecture/écriture au workspace mais pas d’accès internet, sauf si vous l’autorisez explicitement.

MCP Apps : depuis la version 2.6 (mars 2026), les plugins MCP peuvent afficher des interfaces interactives directement dans le chat de l’agent. Des graphiques Amplitude, des diagrammes Figma ou des whiteboards tldraw s’affichent inline.

Debug mode amélioré : Cursor instrumente votre code et utilise les données d’exécution réelles pour localiser les bugs. L’agent identifie la cause, propose le fix et l’applique en un clic.

Agent Mode vs Claude Code : deux philosophies

La question revient souvent : faut-il utiliser le mode Agent de Cursor ou Claude Code ? Les deux outils opèrent comme des agents de coding autonomes, mais avec des approches fondamentalement différentes.

Notre verdict : Cursor Agent Mode convient mieux aux développeurs qui veulent une interface graphique complète, le choix entre plusieurs modèles et des agents cloud intégrés. Claude Code est préférable pour les développeurs terminal-first qui veulent un accès direct au filesystem local avec la puissance brute de Claude Opus 4.6. Pour une comparaison détaillée, consultez notre page Cursor vs Claude Code.

Bonnes pratiques pour le mode Agent

Rédiger des prompts efficaces

L’agent n’est pas télépathe. La précision du prompt détermine directement la qualité du résultat. Voici les règles qui fonctionnent :

Soyez spécifique plutôt que vague. « Optimise la complexité temporelle de cette fonction en utilisant une hash table » donne de bien meilleurs résultats que « optimise le code ». Mentionnez les technologies, les patterns et les contraintes.

Fournissez le contexte du projet. Utilisez un fichier Cursor Rules (.cursor/rules) pour décrire votre stack, vos conventions de code et vos préférences architecturales. L’agent les consulte automatiquement à chaque requête.

Découpez les tâches larges. Au lieu de « ajoute l’authentification à l’API », préférez « ajoute le middleware JWT sur les routes /api/users uniquement ». Les agents performent mieux sur des tâches bien délimitées.

Utilisez les mentions @. Pointez vers des fichiers (@file), des dossiers (@folder), de la documentation (@docs) ou des recherches web (@web) pour enrichir le contexte de l’agent.

Workflow recommandé

Le workflow le plus efficace observé chez les utilisateurs avancés de Cursor suit un cycle en quatre temps :

1. Commit Git avant chaque session Agent. C’est votre filet de sécurité. Si l’agent produit un résultat inutilisable, un git checkout . vous ramène à l’état initial.

2. Plan d’abord, exécution ensuite. Pour toute tâche touchant plus de 3 fichiers, démarrez en mode Plan. Validez la stratégie, puis transférez au mode Agent ou à un Cloud Agent.

3. Review systématique des diffs. Cursor 2.0 facilite la revue des changements multi-fichiers avec une vue consolidée. Ne mergez jamais les changements de l’agent sans les avoir inspectés.

4. Itération courte. Préférez 5 prompts ciblés à 1 prompt monstre. Chaque cycle court permet de corriger la trajectoire avant que l’agent ne s’éloigne trop de votre intention.

Erreurs courantes à éviter

Prompt trop large. « Refactorise toute l’application » est un prompt voué à l’échec. L’agent va toucher des dizaines de fichiers de façon incohérente. Limitez le scope.

Ne pas indexer la codebase. L’indexation est le fondement de l’intelligence contextuelle de l’agent. Vérifiez l’indicateur d’indexation dans la barre de statut. Sans indexation complète, le mode Ask et le mode Agent perdent beaucoup en pertinence.

Corriger par follow-up au lieu de recommencer. Si l’agent a pris une mauvaise direction, un nouveau prompt propre depuis l’état Git propre est souvent plus efficace qu’une série de corrections successives qui brouillent le contexte.

Ignorer le mode Auto. Beaucoup de développeurs sélectionnent manuellement Claude ou GPT-5.4 par réflexe. Le mode Auto est illimité sur tous les plans payants et suffit pour 80 % des tâches quotidiennes. Réservez les modèles premium aux tâches qui les justifient.

Prix et consommation de crédits

Comprendre le système de facturation est essentiel pour utiliser le mode Agent sans mauvaises surprises. Depuis juin 2025, Cursor fonctionne avec un système de crédits indexé sur le coût API réel des modèles utilisés.

Le mode Auto est votre meilleur allié économique : il est effectivement illimité sur tous les plans payants. Cursor sélectionne un modèle optimisé coût/qualité (souvent Composer 2 ou un modèle léger) et ne prélève rien de votre pool de crédits. Les crédits ne sont consommés que lorsque vous sélectionnez manuellement un modèle premium (Claude Sonnet, GPT-5.4, etc.).

Pour les Background Agents, la facturation est séparée et toujours en usage-based, même si vous n’avez pas épuisé vos crédits mensuels. Comptez entre 3 et 10 $ par tâche selon la complexité et le modèle choisi.

Plugins et Marketplace

Depuis mars 2026, le Cursor Marketplace s’est considérablement enrichi avec plus de 30 nouveaux plugins partenaires : Atlassian (Jira), Datadog, GitLab, Glean, Hugging Face, monday.com, PlanetScale, entre autres. La plupart intègrent des MCP utilisables par les Cloud Agents et les Automations.

Sur les plans Teams et Enterprise, les administrateurs peuvent créer des marketplaces privés pour distribuer des plugins internes avec gouvernance centralisée. C’est un levier important pour standardiser les workflows d’une équipe de développement.

L’intégration JetBrains (via l’Agent Client Protocol, ACP) est aussi disponible depuis le 4 mars 2026. Les développeurs utilisant IntelliJ IDEA, PyCharm ou WebStorm peuvent accéder aux agents Cursor directement dans leur IDE JetBrains, sans abonnement JetBrains AI supplémentaire. Il suffit d’avoir la version 2025.3.2 ou ultérieure et d’installer l’ACP depuis le registre.