Cursor Automations sur Cloud Mac : agents planifies, Webhooks et repartition Background Agent

1. Pourquoi separer declenchement et execution en 2026

Trois lignes paralleles : dispatch a la demande (Background/Cloud Agent), pilotage par evenements (Automations), orchestration maison (launchd, cron, n8n+MCP). Les confondre mene a des builds iOS forces dans Linux, des clics Background par PR, ou dix cron sur Cloud Mac sans lecture des logs.

Ce qui ralentit rarement le modele mais l'entree de workflow : d'abord « activer Automations ? » (voir documentation officielle Automations), puis « Archive auto apres merge ? » (pas Linux seul), enfin « Webhook vers Cloud Mac ? » — la chaine de decision de cet article.

Contexte : test terrain Background Agent repond « sur quel Mac » ; FAQ launchd Agent planifie l'orchestration macOS maison. Ici : limites des Automations Cursor et complement Cloud Mac.

2. Cursor Automations : Cloud Agent always-on

Selon le changelog 2026-03-05 et l'annonce officielle, Cursor Automations configurent des agents toujours actifs avec declencheurs + instructions en langage naturel + outils optionnels.

Creation sur cursor.com/automations ; en juin le skill /automate genere la config depuis le chat (ameliorations 06-18).

Types de declencheurs (un seul suffit) :

• Scheduled : cadence ou cron ;
• GitHub/GitLab : PR opened/pushed/merged, push branche, CI completed, commentaire review, etc. ;
• Slack : messages canal, reactions emoji ;
• Linear/PagerDuty : Issue, Cycle, Incident ;
• Webhook : endpoint HTTP prive + cle API apres enregistrement.

Chaque declenchement lance un sandbox cloud avec commentaires PR, Slack, MCP, memoire inter-runs. Modes repo : sans repo (Slack/MCP/Webhook seulement), mono-repo, multi-repos — sans repo pas de code ni PR.

Conclusion asymetrique : la valeur d'Automations est l'ecosysteme de declencheurs, pas le runtime macOS — « quelqu'un enquete 30 s apres le merge » paie l'entree de reponse.

3. Background Agent : une longue course que vous lancez

Background Agent (Cloud Agent) est a la demande : tache explicite dans l'IDE, cursor.com/agents, Slack @Cursor ou API ; execution jusqu'au PR, logs ou echec. Pas de scan hebdo ni « CI rouge → fix auto » sans Automations ou cron comme substitut du clic.

Mnemonique :

• Automations : « quand X → template Y » ; ops repetitives ;
• Background Agent : « fais cette tache complexe maintenant » ; refactor exploratoire ;
• launchd Cloud Mac : « sur mon macOS selon mon plist » ; Keychain, Xcode, MCP local.

Cas PagerDuty : Incident → Automation → MCP Datadog → changements → Slack + PR de fix — Linux suffit. Si xcodebuild archive est requis, il faut un canal macOS separe.

4. Ou tournent les Automations : sandbox Linux comme Cloud Agent

Doc officielle : sandbox cloud heberge par Cursor (Linux + Dockerfile/snapshot optionnel). Donc :

• ✅ Node/Python/Go, tests, PR, MCP cloud ;
• ❌ xcodebuild natif, Simulateur iOS, signature Keychain, CLI macOS-only ;
• ⚠️ computer use de juin reste dans le sandbox — pas un remplacement de la toolchain Apple.

Same conclusion as our article runtime Background Agent : cloud Cursor = Linux d'abord. Pas de runtime macOS dedie cote declencheurs.

« Configurer Automations sur Cloud Mac » : ① config dans la console Cursor ; ② taches macOS via Webhook/CI completed → Cloud Mac dedie. La plupart des recherches visent ②.

5. Ce que Cloud Mac comble dans la pile

Un Cloud Mac dedie (Mac mini M4) joue quatre roles :

1. Noeud d'execution macOS : xcodebuild, Flutter iOS, notarytool, Simulateur — comme depannage CI Archive ;
2. Recepteur Webhook : HTTP via tunnel ou intranet ;
3. Hote launchd : Claude Code, Codex CLI (FAQ launchd Agent) ;
4. MCP co-localise (guide de placement MCP).

Equipes Windows : code local, build iOS sur Cloud Mac, Automations pour hygiene PR, Webhook post-merge pour Archive — trois couches plus stables qu'une seule Automation.

6. Comparatif cinq dimensions

Declenchement vs execution : Automations = diversite des declencheurs, Background = profondeur tache unique, Cloud Mac = capacite OS. L'hybride est obligatoire.

7. Hybride : Webhook chaine Automations → Cloud Mac

Stack hybride standard recommande (valide sur location journaliere) :

[GitHub PR merged]
       ↓
[Cursor Automation : declencheur = PR merged, repo = unique]
       → sandbox Linux : lint / test / PR docs (optionnel)
       → outil : Webhook POST → https://<cloud-mac-tunnel>/hooks/ios-archive
       ↓
[Service Cloud Mac : nginx/caddy + auth]
       → launchd ou script ponctuel : git pull → xcodebuild archive → exportArchive
       → echec : alerte webhook Slack / Feishu
       ↓
[TestFlight / distribution interne]

Points cles :

• L'outil Webhook ajoute le payload aux instructions — ou Automation Webhook seul sans repo pour le routage ;
• Cote Cloud Mac : jetons courts, jamais d'endpoint nu ;
• Ne pas remettre le build macOS dans l'Automation Linux — pipeline Archive sensible Keychain/Scheme ; plist/Fastlane valides sur Cloud Mac ;
• « Lundi 9h audit dependances » en Automations ; « Lundi 9h30 regression iOS » sur launchd Cloud Mac.

8. Matrice de scenarios

9. Combinaisons et lignes rouges

Combo A (Web + petit iOS) : Automations hygiene PR ; merge iOS → Webhook → Archive Cloud Mac ; Background pour grosses migrations.

Combo B (indie iOS) : Cloud Mac 16 Go mensuel ; launchd la nuit ; Automations PR comment seulement (isolation dual-Agent).

Combo C (plateforme/SRE) : PagerDuty → Automations → MCP Datadog ; fix iOS termine par Webhook Cloud Mac — pas d'Archive dans Linux.

Lignes rouges : ① pas de code sans repo ; ② apres Team Owned rotation cle Webhook + OAuth MCP ; ③ Webhook avec auth + rate limit ; ④ pas ferme Simulateur + Background + Archive sur 16 Go.

10. Idees recues

• Mythe 1 : Automations remplace Background — enveloppe de declencheurs seulement.
• Mythe 2 : Automations remplace Cloud Mac — partie Linux seulement.
• Mythe 3 : Webhook = automatisation finie — script recepteur et Keychain sont le coeur.
• Mythe 4 : doublon article launchd — orchestration macOS vs liaison Automations Cursor.
• Mythe 5 : tout agent planifie = cron — preferer Automations Scheduled.

11. Checklist 7 etapes

1. At cursor.com/automations une Automation test : Scheduled 6 h ou Webhook, « dependances obsoletes vers Slack ».
2. Location journaliere Cloud Mac, checklist d'accueil pour SSH + baseline disque.
3. Recepteur Webhook minimal (caddy + Bearer), git pull && ./scripts/smoke-build.sh seulement.
4. Deuxieme Automation : GitHub « Workflow run completed » ou « PR merged » → Webhook → Cloud Mac avec SHA.
5. En parallele Background Agent manuel — comparer delai et reproductibilite.
6. Build macOS dans launchd/Fastlane ; pas de long shell dans les instructions Automation.
7. 48 heures : merge reel + echec volontaire ; puis mensuel, SOP rotation cle Webhook.

12. FAQ

Q : Automations et Background Agent, un seul produit ?

Oui : Automations = declencheurs + Cloud Agent template ; Background = declenchement manuel. Meme runtime Linux.

Q : SSH depuis Automation vers Cloud Mac ?

Pas d'outil SSH officiel. Webhook → HTTP sur Cloud Mac ou runner self-hosted en parallele.

Q : Automation sans repo ?

Slack, PagerDuty, MCP externe, routage Webhook — pas de code. PR exige un repo.

Q : Pourquoi changer la cle Webhook apres Team Owned ?

Compte service equipe ; anciennes cles invalides ; OAuth MCP en credentials equipe.

Q : 16 Go Cloud Mac suffisent ?

Un worktree + Archive occasionnel : 16 Go journalier OK. Ferme Simulateur + parallele : 24 Go mensuel.

13. Conclusion

Cursor Automations productise l'agent always-on en couche de declencheurs — a adopter en premier en 2026. Partage le sandbox Linux avec Background ; pas Xcode/Keychain.

Trois couches : Automations evenements/templates ; Background taches profondes ponctuelles ; Cloud Mac Webhook/launchd pour macOS. Aligner entree et frontiere d'execution.

Cette semaine : une Automation Webhook, une chaine Archive fumee sur location journaliere — en 48 h vous verrez ou placer chaque couche.