AIREITERL’architecture de Cursor, basée sur un coordinateur et des sous-agents, apporte une vraie valeur lors des migrations de grandes bases de code — mais elle ne transforme pas l’outil en bouton magique de réécriture autonome. Elle est particulièrement efficace lorsque le travail peut être découpé en étapes délimitées et testables. En revanche, les risques augmentent dès que les agents partagent des contrats, des fichiers ou des règles métier non documentées. Le terme « Projects » mérite également quelques précautions : la documentation officielle actuelle met surtout l’accent sur les sous-agents, l’exécution asynchrone, les agents cloud et le développement de longue durée, plutôt que sur une page produit Projects unique et clairement documentée.
Ce que la bêta de Cursor Projects apporte réellement aux équipes de migration
La documentation actuelle de Cursor sur les sous-agents décrit un agent parent qui délègue des tâches spécialisées à des fenêtres de contexte distinctes. Un sous-agent renvoie son résultat à l’agent parent, peut fonctionner au premier plan ou en arrière-plan, et disposer de ses propres outils, modèle et autorisations d’écriture.
Pour une migration, c’est une unité d’architecture particulièrement pertinente : un coordinateur conserve la vision d’ensemble et arbitre les décisions, tandis que des spécialistes explorent le dépôt, implémentent des changements limités, exécutent les tests ou relisent le résultat. Cursor documente également des sous-agents cloud dotés de leur propre machine virtuelle, branche et clone du dépôt. Une approche nettement plus sûre que de laisser plusieurs agents modifier le même checkout.
La réserve concernant la bêta est importante. Une discussion de février 2026 sur une mise à jour de Cursor annonçait les sous-agents asynchrones et imbriqués, mais des utilisateurs ont signalé des déclenchements en arrière-plan peu fiables. Un membre de l’équipe Cursor a indiqué qu’un problème lié à is_background: true devait être corrigé dans Cursor 2.6. Il faut donc considérer la disponibilité et le comportement de ces fonctions comme dépendants de la version, et non comme un plan de contrôle garanti.
Le workflow de migration qui profite vraiment de la coordination
Un coordinateur est utile lorsqu’il orchestre la séquence, pas lorsqu’il tente d’écrire chaque ligne de code. Pour une migration de framework ou de langage, on peut répartir les rôles de la manière suivante :
| Rôle | Résultat utile | Pourquoi le séparer dans un autre contexte |
|---|---|---|
| Explorateur du dépôt | Cartographie des dépendances, points d’entrée et frontières du code généré | Les résultats de recherche peuvent noyer le fil principal |
| Planificateur de migration | Lots de travail ordonnés et invariants à préserver | La planification nécessite une vue globale du dépôt |
| Implémenteur | Modifications dans un module, un service ou un worktree | Un périmètre réduit limite les changements hors sujet |
| Agent de test | Nouveaux contrôles et vérifications existantes pour une étape | Les journaux de test sont volumineux et exploitables séparément |
| Relecteur | Détection des régressions, problèmes de sécurité et écarts aux conventions | Un contexte vierge est moins impliqué dans l’implémentation |
| Coordinateur | Vérification des contrats, arbitrage des conflits et préparation de la prochaine vague | Un point central doit réconcilier les résultats incompatibles |
Le rapport de Cursor sur le développement de longue durée décrit une structure comparable, organisée autour de planificateurs, travailleurs et juge. Dans son expérimentation de migration de Solid vers React, Cursor fait état de plus de trois semaines de travail et d’environ 266 000 ajouts contre 193 000 suppressions, tout en précisant qu’une relecture attentive restait nécessaire. Cela montre que l’architecture peut soutenir un chantier important, pas qu’une migration devient sûre pour la production par défaut.
Les points forts de l’architecture dans les grandes bases de code
1. Inventaire et cartographie des dépendances
Les grandes migrations échouent souvent dès le départ parce qu’un point d’appel, un script de build, un fichier généré ou une hypothèse de déploiement a été oublié. Un explorateur dédié peut parcourir ces différentes surfaces pendant que le coordinateur transforme les résultats en registre de migration.
Cette méthode est plus solide que de demander à un seul agent de « migrer le dépôt » : le résultat devient vérifiable. On obtient la liste des packages concernés, les liens de dépendance, les interfaces publiques, la couverture de tests et les hypothèses encore en suspens. Les recommandations de Cursor pour la modernisation conseillent d’utiliser le Plan Mode, .cursor/plans/ et des règles de migration comme .cursor/rules/migration.mdc.
2. Transformations répétitives et bien délimitées
Les sous-agents sont bien adaptés à des tâches comme la mise à jour d’appels d’API obsolètes, la conversion de modules isolés ou la migration de services dont les interfaces sont stables. La bonne frontière ne correspond pas forcément au nom d’un dossier. Il faut plutôt une étape définie par :
- Un responsable et un périmètre de fichiers clairement nommés.
- Un contrat d’entrée et de sortie écrit.
- Une commande de build et de test.
- Une branche ou un worktree isolé.
- Une définition claire de ce qui constitue un résultat terminé.
La documentation de Cursor avertit que plusieurs sous-agents partageant le checkout par défaut peuvent écraser les modifications des uns et des autres. Les worktrees isolés ou les branches cloud permettent de garder les changements séparés jusqu’à leur fusion par le coordinateur ou par un humain.
3. Files de maintenance et vérification en arrière-plan
Les tâches de maintenance se prêtent souvent naturellement au parallélisme : analyser des tests instables, examiner des alertes de dépendances, mettre à jour la documentation et relire une pull request peuvent avancer indépendamment. L’exécution en arrière-plan laisse le parent disponible, tandis que les agents cloud peuvent continuer à travailler sur leurs propres machines virtuelles.
Pour la relecture, la documentation d’Agent Review de Cursor propose les modes Quick et Deep. Le mode Deep est plus lent et plus coûteux ; Cursor le recommande pour la logique complexe, le code sensible sur le plan de la sécurité et les refactorings importants. Le workflow Source Control compare l’ensemble des changements locaux avec la branche principale, et pas uniquement la dernière modification.
L’architecture est donc utile pour la maintenance, mais la relecture doit rester un véritable point de contrôle. Le rapport positif d’un sous-agent n’équivaut ni à une suite d’intégration réussie ni à une pull request approuvée.
Quand les workflows coordinateur/sous-agents atteignent leurs limites
Les contrats transverses limitent le parallélisme sûr
Les changements frontend, backend, base de données et services ne peuvent pas toujours être parallélisés simplement parce qu’ils concernent des répertoires différents. Une modification de schéma peut invalider une API, une modification d’API peut casser des clients générés et un utilitaire partagé peut provoquer des collisions entre deux changements qui semblaient indépendants.
Une demande de fonctionnalité publiée sur le forum Cursor autour d’un « Monorepo Execution Plan » décrit bien la discipline qui fait encore défaut : les workers associés à un périmètre devraient recevoir les exigences globales, les contrats d’API et les changements de schéma, puis un coordinateur devrait valider les routes, les types et les schémas avant l’intégration. Cette publication est une demande, pas la preuve que chaque étape de ce workflow est déjà entièrement automatisée.
Lors d’une migration, verrouillez les contrats avant de lancer les agents d’implémentation. Si un contrat doit évoluer, prévoyez une phase de compatibilité ou faites de cette évolution la prochaine décision séquentielle du coordinateur.
L’isolation du contexte entraîne aussi une perte d’informations
Les sous-agents démarrent avec un contexte vierge ; ils n’héritent pas automatiquement de la conversation du parent. Le coordinateur doit donc transmettre explicitement les règles pertinentes, les modèles à suivre, les contraintes et les artefacts nécessaires. Un résumé trop court peut omettre précisément le cas limite qui deviendra critique six heures plus tard.
Mieux vaut s’appuyer sur des artefacts durables que sur la mémoire d’une conversation :
migration-plan.mdpour le périmètre et l’ordre des opérations.migration-ledger.csvpour l’état des packages et les exceptions.contracts/pour les instantanés des API et des schémas.decisions.mdpour conserver la trace des options écartées.- Un rapport de tests associé à chaque branche d’implémentation.
Cette méthode permet également de limiter les décisions obsolètes. Un coordinateur persistant peut conserver l’historique, mais l’historique ne devient pas automatiquement la vérité. Il faut revalider les hypothèses après une mise à niveau de dépendance, une modification de schéma ou la découverte d’un comportement historique inattendu.
Multiplier les agents peut augmenter les coûts et les interférences
La documentation de Cursor estime que cinq sous-agents parallèles utilisent environ cinq fois plus de tokens qu’un travail comparable effectué par un seul agent. Elle précise également que le modèle sélectionné peut être remplacé si un administrateur bloque ce modèle, si l’offre ne le prend pas en charge ou si une ancienne formule nécessite le Max Mode. Ne construisez donc pas votre budget en vous basant uniquement sur le modèle de l’agent parent.
Les retours d’utilisateurs montrent pourquoi une boucle de contrôle explicite est nécessaire :
« trop peu et les messages restent en file d’attente indéfiniment, trop et ils commencent à se gêner les uns les autres » — @siggelabor, X
Une discussion Reddit rapporte que certains utilisateurs ont vu les sous-agents consommer plus de ressources modèle que prévu et s’appuyer sur .cursorrules pour décourager la délégation, tout en précisant que cette règle n’était pas garantie. Limitez la concurrence, réservez les modèles moins coûteux à l’exploration, gardez les modèles plus performants pour la planification et la relecture, puis vérifiez l’utilisation avant d’élargir la vague suivante.
Des tests au vert ne prouvent pas qu’une migration a réellement abouti
Le préprint SWE Refactor Bench constitue un avertissement utile pour toute revue de Cursor Projects. Sur 520 exécutions couvrant 20 tâches de migration de dépôts entiers, seules 28 exécutions — soit 5,4 % — ont réussi l’audit de migration, les tests comportementaux corrigés et la vérification contradictoire. L’étude a également constaté que les réécritures de langage obtenaient en moyenne 5,6/100, contre 31,4/100 pour les réécritures de l’outillage de build.
La leçon est avant tout méthodologique : une migration doit disposer de contrôles distincts pour vérifier le remplacement et la préservation. Vérifiez que l’ancienne stack a disparu du code source et de la clôture de build, puis comparez les comportements, avant de lancer une vérification indépendante destinée à révéler les différences cachées. « La CI est au vert » n’est qu’un indicateur, pas un verdict.
Une manière plus sûre d’utiliser Cursor pour une migration
- Établissez une référence de l’ancien système. Avant toute modification, consignez les commandes de build, les interfaces publiques, des sorties représentatives, les chemins sensibles aux performances et les exceptions connues.
- Demandez à un explorateur en lecture seule de cartographier le dépôt. Incluez les packages, les artefacts générés, la configuration, les scripts de déploiement et les lacunes de couverture de tests.
- Créez un plan et un registre de migration. Découpez le travail selon les comportements et les responsabilités, pas uniquement selon les répertoires.
- Commencez par une étape limitée. Utilisez une implémentation de référence migrée pour fixer les conventions de nommage, de gestion des erreurs, de compatibilité et de tests.
- Lancez les implémenteurs dans des branches isolées et avec un périmètre précis. Indiquez dans chaque prompt le contrat exact et les chemins qu’il est interdit de modifier.
- Validez chaque étape localement. Exigez les contrôles de types, les tests unitaires et d’intégration, la sortie du build ainsi qu’un résumé du diff avant d’accepter le succès annoncé.
- Organisez une relecture indépendante. Utilisez un relecteur avec un contexte vierge et choisissez Deep Agent Review pour les changements à haut risque ou transverses.
- Intégrez par vagues. Le coordinateur réconcilie les contrats ; un humain approuve les fusions qui touchent aux données, à l’authentification, à l’infrastructure ou aux API publiques.
- Relancez les vérifications différentielles. Comparez le système migré avec la référence sur des entrées représentatives et des scénarios d’échec.
- Arrêtez-vous lorsque les signaux se dégradent. Davantage de parallélisme ne constitue pas un progrès si les files d’attente, les conflits, les nouvelles tentatives ou les problèmes relevés en revue augmentent.
Verdict sur la bêta de Cursor Projects selon le type de charge
| Charge de travail | Adéquation | Recommandation |
|---|---|---|
| Changements répétitifs dans des modules indépendants | Élevée | Utilisez des implémenteurs parallèles avec des branches isolées et des règles partagées |
| Mise à niveau de dépendances ou de framework | Moyenne à élevée | Planifiez d’abord, testez un module pilote, puis élargissez par vagues |
| Réécriture importante d’un langage avec peu de tests | Moyenne à faible | Utilisez les agents pour l’inventaire et les étapes ciblées ; gardez la validation comportementale sous contrôle humain |
| Migration de schémas et d’API entre services | Moyenne | Séquencez les décisions liées aux contrats et ne parallélisez l’implémentation qu’une fois le contrat stabilisé |
| Maintenance continue des tests, PR et dépendances | Élevée | Utilisez les agents en arrière-plan ou cloud avec des limites de concurrence et de coûts |
| Formatage ponctuel ou mise à jour d’un changelog | Faible | Préférez une commande ou une skill ; un sous-agent ajouterait une complexité inutile |
| Renommage massif déterministe avec une bonne couverture de tests | Moyenne | Préférez les scripts et la CI lorsque la transformation est mécanique et facilement réversible |
Mon avis : l’architecture coordinateur/sous-agents de Cursor mérite un projet pilote pour les grandes migrations lorsque le dépôt possède des frontières testables et que l’équipe peut imposer l’isolation des branches. Pour un système mal documenté et peu couvert par les tests comportementaux, utilisez le coordinateur comme responsable de l’inventaire et de la vérification, pas comme implémenteur autonome.
FAQ sur la bêta de Cursor Projects
La bêta de Cursor Projects est-elle la même chose que les sous-agents Cursor ?
La documentation officielle de Cursor est organisée autour des sous-agents, de l’exécution asynchrone, des agents cloud et du développement multi-agents ; « Projects » est un intitulé bêta dont le périmètre peut varier selon la version et le compte.
Les sous-agents Cursor peuvent-ils fonctionner en parallèle ?
Oui, mais les tâches indépendantes nécessitent tout de même des périmètres, des contrats et des worktrees isolés clairement définis afin d’éviter les conflits.
Un sous-agent peut-il lancer un autre sous-agent ?
Cursor documente les sous-agents imbriqués. Utilisez cette possibilité avec parcimonie : les arborescences plus profondes augmentent les coûts de coordination, de tokens et de vérification.
Les agents continuent-ils à travailler après la fermeture de mon ordinateur portable ?
Les sous-agents cloud peuvent continuer à fonctionner sur leurs propres machines virtuelles ; Cursor précise que la configuration MCP locale n’est pas automatiquement réutilisée dans le cloud.
Puis-je imposer un modèle particulier à chaque sous-agent ?
Cursor permet d’utiliser un modèle hérité ou un modèle précis, mais les règles liées à l’administrateur, à l’offre et aux anciennes formules peuvent déclencher un remplacement. Vérifiez donc le modèle réellement utilisé.
Comment empêcher les sous-agents de se lancer ?
Utilisez les instructions de tâche et les règles du dépôt, puis vérifiez le comportement avec votre offre et votre version ; les retours d’utilisateurs suggèrent que ces contrôles ne sont pas toujours garantis.
La décision à prendre avant d’activer un essaim d’agents
Lancez un projet pilote d’une semaine sur une seule étape de migration. Ne généralisez l’approche que si le nombre de régressions découvertes après coup n’augmente pas et si le temps gagné dépasse celui consacré aux reprises du coordinateur, aux relectures et à la consommation de modèles. Dans le cas contraire, utilisez des scripts, la CI ou un agent unique pour cette catégorie de changement.