CrdaN
Administrateur
PREMIUM
Marchand
Level 5
Level 4
Level 3
Level 2
Level 1
- 29 Avr. 2012
- 5,336
- 437
- 999
- Discord
- crdan
Cursor 3.5 : automatisations multi-repo et agents sans repo, mode d’emploi
Cursor a publié la version 3.5 le 20/05/2026. La nouveauté intéressante n’est pas juste “un agent de plus” : Cursor pousse ses Automations directement dans la fenêtre Agents, avec deux usages qui peuvent vraiment changer un workflow de dev : les automatisations multi-repo et les automatisations sans repo.
Source :
Pour Cheat-Gam3, c’est typiquement le genre d’évolution à surveiller si vous gérez un bot Discord, un petit site, un panel admin, une doc serveur, une veille sécurité, ou plusieurs projets qui se parlent entre eux. L’intérêt est réel, mais il faut poser des limites claires avant de laisser un agent tourner tout seul.
D’après le changelog officiel, Cursor 3.5 améliore surtout les Cursor Automations :
Le point important : on sort du modèle “j’ouvre mon repo et je demande une modification”. On arrive vers “je programme un agent pour surveiller, résumer, déclencher une action ou préparer un travail”. C’est puissant, mais c’est aussi là que les erreurs de configuration deviennent plus coûteuses.
Beaucoup de projets ne vivent pas dans un seul dépôt. Exemple classique :
Avant, un agent qui ne voyait qu’un seul repo pouvait proposer une correction incomplète. Il modifiait l’API, mais oubliait le front. Il changeait un schéma, mais pas la doc. Il corrigeait un bot, mais pas le fichier d’exemple.
Avec une automatisation multi-repo, l’agent peut mieux comprendre le système complet. Pour un admin communautaire, ça peut servir à préparer une PR propre qui touche plusieurs parties : commande Discord, endpoint API, page d’aide, test, changelog.
Le mode sans repo est presque plus intéressant pour les créateurs et admins. Tous les workflows utiles ne sont pas du code.
Exemples propres :
Attention : “sans repo” ne veut pas dire “sans risque”. Si l’agent a accès à des messages privés, exports clients, données de paiement, logs serveur ou infos internes, il faut limiter son périmètre. Un digest utile n’a pas besoin d’accéder à tout.
Avant de cliquer partout, je conseille de définir l’automatisation comme une mini-procédure :
Le meilleur agent n’est pas celui qui fait tout. C’est celui qui fait une tâche claire, produit un résultat vérifiable et s’arrête au bon endroit.
Ce cadrage évite de transformer une automation pratique en agent flou qui agit trop large.
Quelques idées réalistes pour la communauté :
Le gros avantage : l’agent peut faire la partie pénible de tri et de préparation. Le membre garde la décision finale.
Cursor 3.5 confirme une tendance nette : les IDE IA deviennent des plateformes d’agents programmables. C’est très utile pour les devs solo et les petites communautés, parce qu’on peut automatiser de la veille, de la maintenance et de la préparation de PR sans monter une usine à gaz.
Mais il faut rester carré. Multi-repo ne veut pas dire “accès à tout”. Sans repo ne veut pas dire “sans données sensibles”. Une bonne automation doit être limitée, lisible, auditable et facile à couper.
Si vous testez Cursor Automations, commencez petit : un digest, une PR de maintenance, une checklist changelog. Quand le résultat est fiable pendant plusieurs runs, seulement là vous élargissez le périmètre. L’IA doit vous faire gagner du temps, pas devenir une boîte noire qui décide à votre place.
Cursor a publié la version 3.5 le 20/05/2026. La nouveauté intéressante n’est pas juste “un agent de plus” : Cursor pousse ses Automations directement dans la fenêtre Agents, avec deux usages qui peuvent vraiment changer un workflow de dev : les automatisations multi-repo et les automatisations sans repo.
Source :
Vous devez etre connecte pour voir les liens.
Pour Cheat-Gam3, c’est typiquement le genre d’évolution à surveiller si vous gérez un bot Discord, un petit site, un panel admin, une doc serveur, une veille sécurité, ou plusieurs projets qui se parlent entre eux. L’intérêt est réel, mais il faut poser des limites claires avant de laisser un agent tourner tout seul.
Ce que Cursor 3.5 ajoute concrètement
D’après le changelog officiel, Cursor 3.5 améliore surtout les Cursor Automations :
- Automations dans la fenêtre Agents : on peut créer et gérer des automatisations depuis le même espace que les agents.
- Automations multi-repo : une automatisation peut être attachée à plusieurs dépôts pour travailler sur un système composé de plusieurs projets.
- Automations sans repo : un agent peut surveiller ou résumer des outils sans forcément avoir un dépôt Git attaché.
- Templates marketplace : Cursor cite notamment des exemples type digest Slack, FAQ produit, analytics, finance ou monitoring client.
Le point important : on sort du modèle “j’ouvre mon repo et je demande une modification”. On arrive vers “je programme un agent pour surveiller, résumer, déclencher une action ou préparer un travail”. C’est puissant, mais c’est aussi là que les erreurs de configuration deviennent plus coûteuses.
Pourquoi le multi-repo est utile
Beaucoup de projets ne vivent pas dans un seul dépôt. Exemple classique :
- un bot Discord dans un repo ;
- un dashboard web dans un autre ;
- une API séparée ;
- une doc ou un wiki ;
- des scripts de déploiement à côté.
Avant, un agent qui ne voyait qu’un seul repo pouvait proposer une correction incomplète. Il modifiait l’API, mais oubliait le front. Il changeait un schéma, mais pas la doc. Il corrigeait un bot, mais pas le fichier d’exemple.
Avec une automatisation multi-repo, l’agent peut mieux comprendre le système complet. Pour un admin communautaire, ça peut servir à préparer une PR propre qui touche plusieurs parties : commande Discord, endpoint API, page d’aide, test, changelog.
Les automatisations sans repo : très pratique pour la veille
Le mode sans repo est presque plus intéressant pour les créateurs et admins. Tous les workflows utiles ne sont pas du code.
Exemples propres :
- résumer chaque matin les messages importants d’un canal Slack/Discord interne ;
- surveiller les questions fréquentes et proposer une réponse basée sur la documentation ;
- préparer un digest de changelogs IA ou gaming ;
- repérer les tickets qui attendent une réponse ;
- compiler les retours utilisateurs avant une mise à jour.
Attention : “sans repo” ne veut pas dire “sans risque”. Si l’agent a accès à des messages privés, exports clients, données de paiement, logs serveur ou infos internes, il faut limiter son périmètre. Un digest utile n’a pas besoin d’accéder à tout.
Workflow conseillé avant de créer une automation
Avant de cliquer partout, je conseille de définir l’automatisation comme une mini-procédure :
- Objectif exact : résumer, surveiller, préparer une PR, lister des anomalies, répondre en brouillon ?
- Sources autorisées : quels repos, quels canaux, quels outils ?
- Actions interdites : pas de suppression, pas de déploiement, pas d’envoi public sans validation.
- Sortie attendue : rapport court, checklist, PR, brouillon, ticket ?
- Fréquence : quotidien, hebdo, à la demande, après événement ?
- Validation humaine : qui relit avant merge, publication ou réponse officielle ?
Le meilleur agent n’est pas celui qui fait tout. C’est celui qui fait une tâche claire, produit un résultat vérifiable et s’arrête au bon endroit.
Prompt de cadrage pour Cursor Automations
Ce cadrage évite de transformer une automation pratique en agent flou qui agit trop large.
Cas d’usage Cheat-Gam3
Quelques idées réalistes pour la communauté :
- Bot Discord : vérifier chaque semaine les commandes cassées, ouvrir une PR avec tests.
- Forum/XenForo : préparer un résumé des sujets IA, gaming ou sécurité à mettre en avant.
- Serveur Minecraft ou Palworld : comparer changelog + config serveur + plugins à mettre à jour.
- Projet web : surveiller les issues, regrouper les bugs similaires et proposer un plan.
- Création de contenu : transformer patch notes et docs en brouillons d’articles, sans inventer de sources.
Le gros avantage : l’agent peut faire la partie pénible de tri et de préparation. Le membre garde la décision finale.
Checklist sécurité avant activation
Mon avis
Cursor 3.5 confirme une tendance nette : les IDE IA deviennent des plateformes d’agents programmables. C’est très utile pour les devs solo et les petites communautés, parce qu’on peut automatiser de la veille, de la maintenance et de la préparation de PR sans monter une usine à gaz.
Mais il faut rester carré. Multi-repo ne veut pas dire “accès à tout”. Sans repo ne veut pas dire “sans données sensibles”. Une bonne automation doit être limitée, lisible, auditable et facile à couper.
Si vous testez Cursor Automations, commencez petit : un digest, une PR de maintenance, une checklist changelog. Quand le résultat est fiable pendant plusieurs runs, seulement là vous élargissez le périmètre. L’IA doit vous faire gagner du temps, pas devenir une boîte noire qui décide à votre place.
