Cursor a annoncé son SDK TypeScript en beta publique mercredi (npm install @cursor/sdk), rendant l'agent qui roule dans les apps desktop, CLI pis web de Cursor appelable programmatiquement avec quelques lignes de code. Les pièces architecturales dans l'annonce se lisent comme une spécification de ce à quoi ressemble une plateforme d'agent de coding 2026. Chaque agent reçoit une VM dédiée avec un sandboxing fort, un clone du repo cible pis un environnement de développement entièrement configuré. Les agents persistent à travers les sleeps de laptop pis les drops de réseau ; les conversations peuvent être streamées pis reconnectées. Quand un agent finit, il peut ouvrir une PR, pusher une branche, ou attacher des démos pis screenshots. Les modèles sont pluggables (n'importe quel modèle frontière — même pattern de routage multi-modèle que Microsoft Copilot d'iter #72). Les outils externes se connectent via des serveurs MCP (le même protocole publié par Anthropic que SAS a adopté dans iter #56). Les skills au niveau repo vivent dans `.cursor/skills/`. Les hooks te laissent observer pis étendre la boucle d'agent. La délégation de sous-agents permet à un agent de spawner des agents enfants pour gérer des sous-tâches.
Le positionnement stratégique, c'est la partie la plus intéressante. Le pitch de Cursor — explicite dans l'annonce — c'est que « les agents de coding évoluent d'outils interactifs pour développeurs individuels à infrastructure programmatique pour les organisations ». Ce langage est délibéré : Cursor se repositionne d'IDE-avec-IA à plateforme-pour-déployer-des-agents-de-coding. Les formes de référence, c'est React (primitive UI), Stripe (primitive paiements), Twilio (primitive messagerie) — le move SDK transforme l'agent de Cursor d'une fonctionnalité en une primitive sur laquelle d'autres compagnies bâtissent. Les cas d'usage listés incluent l'invocation par pipeline CI/CD, l'automation de workflow end-to-end pis l'intégration d'agents dans des produits customer-facing. Ce dernier compte le plus : Cursor encourage maintenant activement le pattern où des compagnies SaaS tierces livrent des fonctionnalités alimentées par l'agent Cursor à l'intérieur de leurs propres produits, avec Cursor comme épine dorsale d'agent. Compare contre l'approche plus verticalement-intégrée de GitHub Copilot (Microsoft possède l'agent + IDE + cloud) ou Claude Code (Anthropic possède l'agent, mais l'utilisateur possède l'IDE) — le SDK de Cursor est un troisième pari, avec Cursor comme plateforme d'agent peu importe d'où viennent l'IDE ou le modèle.
Le détail d'adoption MCP est structurellement important. Cursor aurait pu bâtir un format d'appel d'outils propriétaire — la façon dont l'appel de fonction d'OpenAI a commencé, la façon dont les abstractions d'outils de LangChain marchent, ou la façon dont les actions Salesforce Einstein sont définies. Adopter le Model Context Protocol open d'Anthropic veut dire que les agents de Cursor sont interopérables avec n'importe quel outil qui expose un serveur MCP, incluant l'analytique Viya de SAS (iter #56), les outils de repo de GitHub, l'accès au système de fichiers, pis la longue queue de serveurs MCP construits par la communauté. Même décision architecturale que Microsoft a faite sur le routage multi-modèle de M365 Copilot, même pattern qu'Anthropic, GitHub pis maintenant SAS ont tous convergé sur. MCP comme couche de connexion entre agents IA pis outils externes est maintenant le standard de facto — pis les holdouts sont de plus en plus ceux avec des raisons stratégiques de fragmenter (la structure de prompt du Codex CLI d'OpenAI d'iter #60 mène pas avec MCP, même s'il le supporte). Pour les builders qui évaluent « est-ce que je devrais supporter MCP dans mon produit », la réponse est maintenant structurellement oui si tu veux être atteignable par les agents de coding majeurs.
Pour les builders, trois takeaways. Premièrement, le modèle de sandbox VM par agent devient le standard de production pour n'importe quel agent qui exécute du code. Le « VM dédiée par agent avec environnement dev complet » du SDK Cursor, c'est le même pattern architectural que l'agent de Replit utilise, que GitHub Codespaces fournit, pis que le sandbox terminal de Claude Code approxime. Si tu bâtis quoi que ce soit qui roule du code généré par LLM, planifie pour de l'isolation VM-par-tâche plutôt que processus-par-tâche ou conteneur-par-tâche — les propriétés de sécurité pis de persistance comptent plus que le coût des ressources à ce stade du cycle de vie de produit-d'agent. Deuxièmement, la fonctionnalité de délégation de sous-agents, c'est le détail technique le plus sous-apprécié. « Agent Cursor qui spawn des agents Cursor enfants », c'est le pattern agent-d'agents que Felix de Rogo utilise (iter #73 — Felix orchestre des sous-agents de screening d'entente + génération de CIM + diligence) pis vers lequel la recherche d'Anthropic sur l'orchestration multi-agents pousse. La délégation de sous-agents dans un SDK public veut dire que ce pattern bouge de la recherche à la pratique standard ; bâtis pour ça. Troisièmement, surveille quelles compagnies SaaS de grande entreprise annoncent des intégrations Cursor-SDK dans les six prochains mois. Les compagnies qui livrent des fonctionnalités « propulsées par Cursor » à l'intérieur de leurs produits seront celles qui voulaient pas bâtir leur propre stack d'agent-de-coding de zéro — c'est un signal buy-vs-build à la couche plateforme, parallèle au pattern IA verticale Aidoc/Rogo/Harvey (iter #82, #73, etc.) mais à la couche outillage-de-développeur. Les deux signaux pointent vers la même conclusion : en 2026, bâtir ta propre infrastructure d'agent IA de zéro est de plus en plus le mauvais appel à moins d'avoir une raison de différenciation.