Si tu cherches comment utiliser Cursor 3.0 avec des agents parallèles sans finir avec une PR illisible, tu es au bon endroit. Cursor 3.0 apporte des trucs très concrets pour bosser “agentic” sans transformer ton repo en décharge, notamment l’exécution sur worktrees et une orchestration d’agents plus assumée. Mais la feature ne fait pas le process.
Mon angle est simple et volontairement terrain : un agent = une tâche courte = un worktree, et tu n’ouvres pas une PR tant que tu n’as pas des preuves (tests, captures, logs, reproduction). Ça paraît rigide. En réalité, c’est ce qui rend les agents utilisables au quotidien, surtout en équipe.
Pourquoi les agents produisent des PR “poubelle” (et pourquoi ce n’est pas la faute du modèle)
Le pattern que je vois partout est le même. Tu demandes “corrige le bug”, l’agent part explorer, touche à des fichiers connexes, “améliore” des abstractions, renomme deux trucs, reformate trois autres… et au final tu as 1 fix noyé dans 39 modifications. La revue devient un jeu de piste. Et comme personne n’a envie de relire 800 lignes de diff générées à la chaîne, ça finit soit mergé à l’aveugle, soit abandonné.
Le problème n’est pas que l’agent “fait n’importe quoi”. Le problème, c’est que tu lui donnes un espace de travail où tout est connecté : même branche, mêmes fichiers, même historique, mêmes tentations. L’agent optimise localement ce qu’il voit. Toi, tu paies globalement en dette de compréhension.
Cursor 3.0, avec ses agents parallèles et ses exécutions sur worktrees (et plus largement son “Agents Window” qui assume l’orchestration), rend ce mode encore plus tentant. Donc il faut monter d’un cran en discipline, sinon tu industrialises juste le chaos.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Worktrees : l’outil le plus sous-coté pour isoler un agent
Un git worktree, c’est un clone “léger” du repo qui partage l’historique, mais avec un répertoire de travail séparé. Concrètement, tu peux avoir plusieurs répertoires côte à côte, chacun sur sa branche, sans jongler avec des stash et sans risquer de mélanger deux sujets.
Avec des agents, c’est exactement ce qu’on veut : un agent doit pouvoir faire ses modifications sans polluer ton contexte principal. Et toi, tu dois pouvoir dire “stop” et jeter le worktree si ça part en vrille, sans avoir à démêler une branche sale.
Cursor 3.0 ajoute justement des commandes et une intégration orientées “worktrees” (par exemple via /worktree). Mon avis : ce n’est pas un gadget. C’est la brique qui rend le mode parallèle réellement vivable.
Mon workflow “safe” : un worktree par tâche (pas par feature)
Le piège, c’est de créer un worktree pour “la feature X” et de laisser l’agent bricoler dedans pendant deux jours. Tu retombes dans le travers des grosses PR. À la place, je découpe par tâches qui se reviewent vite : un fix, un refactor local, l’ajout d’un test, une migration, un nettoyage d’API, une perf ciblée. Une tâche qui a une fin claire.
Ça veut aussi dire que tu acceptes de faire plusieurs PR plutôt qu’une seule “mega PR”. Oui, ça fait plus de tickets. Mais tu récupères du débit réel, parce que la review redevient possible et que tu réduis le risque. Et quand un agent se plante, tu ne jettes pas toute la feature, tu jettes une petite brique.
Dans Cursor, ça se traduit très bien en pratique : tu lances un agent avec un objectif très précis et un périmètre explicite, dans un worktree dédié. Un autre agent peut bosser en parallèle sur un test ou une doc, dans un autre worktree, sans collision.
Deux commandes Git qui changent ta vie quand tu fais du parallèle
# Crée une branche et un worktree associé
git worktree add -b agent/fix-typo ../wt-fix-typo
# Liste les worktrees actifs
git worktree list
# Quand c'est fini (ou à jeter), supprime le worktree
git worktree remove ../wt-fix-typo
# Optionnel : supprime la branche si tu abandonnes
git branch -D agent/fix-typoLe point important n’est pas la commande. C’est l’intention : isoler, itérer vite, pouvoir abandonner proprement. Un agent doit être “jetable”. Si ton setup ne te permet pas de jeter, tu vas garder des modifications douteuses “parce que ça a l’air de marcher”. Mauvais signe.
Rendre les diffs lisibles : la règle “moins de fichiers, plus de preuves”
Je préfère une PR qui change 2 fichiers mais qui apporte une preuve (un test qui échoue puis passe, une reproduction claire, une capture avant/après), plutôt qu’une PR qui “améliore l’architecture” sur 25 fichiers sans démontrer quoi que ce soit. Avec un agent, c’est encore plus vrai, parce que la confiance se mérite à la lecture du diff, pas à l’énergie que l’agent a mise à générer du code.
Ce que je fais très concrètement : je demande à l’agent de proposer une solution, puis je le force à se contraindre. “Ne touche pas au formatage”, “ne renomme rien”, “pas de refactor hors du module X”, “si tu dois changer plus de N fichiers, tu t’arrêtes et tu me demandes”. Cursor 3.0 pousse l’orchestration, donc c’est toi qui dois pousser les garde-fous.
Et surtout, je refuse la PR “gloubi-boulga” qui mélange : fix + refactor + nettoyage + upgrade de dépendances. Ce n’est pas “plus efficace”. C’est juste plus dur à reviewer, et ça augmente ton risque de régression silencieuse.
Discipline de commits : un agent n’a pas le droit de faire un commit “fourre-tout”
Je ne suis pas un ayatollah du commit parfait. Par contre, quand tu bosses avec des agents, un historique propre devient un outil de debug et de review. Typiquement, je veux voir une progression lisible : d’abord un test qui reproduit, ensuite le fix, ensuite éventuellement un refactor local si c’est vraiment nécessaire.
Le commit “misc changes” est un anti-pattern total ici. Parce qu’il empêche de comprendre ce qui a été fait, et donc de faire confiance. Si l’agent a généré beaucoup de modifications, je préfère squasher après review, mais sur une base qui a été structurée pendant le travail.
Autre point qui sauve du temps : je garde le formatage et les changements mécaniques (lint, prettier, tri imports) hors du scope de la tâche. Si tu veux les faire, tu les fais dans une PR dédiée. Sinon tu noies ton signal dans du bruit.
Agents parallèles : comment éviter qu’ils se marchent dessus
Cursor 3.0 permet de lancer plusieurs agents en parallèle (local, worktrees, cloud, SSH selon le contexte). C’est puissant, mais le risque est évident : deux agents peuvent résoudre le même problème de deux manières différentes, ou modifier la même zone du code avec des hypothèses incompatibles.
Mon approche, c’est de paralléliser par axes indépendants. Un agent bosse sur la reproduction et les tests. Un autre bosse sur le fix minimal. Un troisième peut préparer une note de release ou mettre à jour une doc. Si tu parallélises “deux implémentations concurrentes” sans cadrage, tu vas surtout produire des conflits Git et des débats inutiles.
Et même quand ça marche, je me fixe une règle bête : je merge rarement deux PR d’agents “en même temps” sur la même zone critique. Je préfère séquencer. Les agents accélèrent la production de code, pas la capacité de ton équipe à comprendre ce qui change.
Garde-fous concrets : secrets, actions dangereuses, contexte et permissions
Le mode agentic donne envie de tout automatiser : commandes, scripts, accès à l’environnement, déploiements. Là, je mets un stop net. Un agent est un outil. Ce n’est pas ton SRE. Tu peux lui donner de l’autonomie, mais pas une carte blanche.
Première règle : pas de secrets dans le contexte. Ni tokens de prod, ni dumps de config, ni logs qui contiennent des clés. Même si tu fais “juste un test”, tu vas oublier, ça va fuiter dans un prompt ou dans un fichier. Si tu as besoin d’accéder à des services, passe par des credentials de dev limités, expirables, et idéalement isolés.
Deuxième règle : pas d’actions dangereuses sans confirmation humaine explicite. Les commandes qui suppriment, qui migrent, qui publient, qui déploient, qui touchent aux règles de sécurité, ça doit être un “human-in-the-loop”. Cursor 3.0 parle aussi d’Enterprise controls et d’intégrations (MCP dans le changelog). Très bien. Mais la réalité, c’est que la meilleure sécurité reste souvent une règle d’équipe simple : “l’agent propose, un humain exécute”.
Troisième règle : scope strict. Si tu donnes à l’agent tout le repo, il va prendre des libertés. Si tu lui donnes un module, un dossier, un ticket, une définition de done, et un worktree, tu récupères de la qualité.
La definition of done avant d’ouvrir la PR (sinon tu fais perdre du temps à tout le monde)
Une PR d’agent, c’est souvent une PR “rapide”. Et c’est précisément pour ça qu’elle doit être carrée. La PR rapide qui casse la CI ou qui ne prouve rien, ce n’est pas “vite”. C’est juste du transfert de charge vers le reviewer.
Voilà un template que j’utilise, et que tu peux coller tel quel dans la description de PR. Ce n’est pas une checklist pour faire joli. C’est un contrat de review. Si ce n’est pas rempli, la PR n’est pas prête.
## Objectif
- (1 phrase) Ce que cette PR change, et pourquoi.
## Périmètre
- Zone touchée : ...
- Hors scope (volontairement) : ...
## Preuves
- Repro avant : ...
- Résultat après : ...
- Tests : (commande + résultat)
## Risques
- Ce qui pourrait casser : ...
- Rollback : ...
## Notes review
- Fichiers clés à lire : ...Tu remarqueras le mot “preuves”. Je le mets partout. Un agent peut être brillant, mais sans preuve tu es juste en train de merger de la prose compilée.
Quand ce workflow ne marche pas (et ce que je ferais à la place)
Il y a des cas où worktrees + agents ne sauvent pas grand-chose. Typiquement : une migration cross-cutting énorme, un changement d’architecture, une refonte de design system, ou un sujet où tu ne sais même pas ce que tu veux au départ. Dans ces cas-là, l’agent peut aider à explorer, à prototyper, à écrire des scripts de migration, à générer des tests, mais il ne doit pas “piloter” la branche principale.
Sur ces gros chantiers, je reviens à un truc plus robuste : une branche d’intégration manuelle, des PR incrémentales, et des worktrees pour les spikes. L’agent devient un accélérateur local, pas un chef de projet qui pousse des changements globaux.
Conclusion : Cursor 3.0 te donne de la vitesse, à toi d’imposer la gouvernance
Cursor 3.0 rend le mode “agents parallèles” beaucoup plus accessible, et l’intégration worktrees est exactement le genre de feature qui peut transformer un gadget en workflow pro. Mais si tu ne changes pas ton hygiène Git et ta définition de done, tu vas juste produire des PR plus vite… et les reviewer encore moins bien.
Le bon compromis, je le résume comme ça : isolation forte (worktree), tâches petites (scope serré), diffs lisibles (peu de fichiers), et preuves (tests, repro, logs). Le reste, c’est du bruit.
