Quand quatre étudiants du MIT, Michael Truell, Sualeh Asif, Aman Sanger et Arvid Lunnemark, fondent Anysphere en 2022, ils lancent un produit assez modeste sur le papier : un fork de VS Code avec de l’IA dedans.
Le timing est parfait. GitHub Copilot domine le marché de la complétion, mais l’expérience reste celle d’un autocomplete amélioré. Cursor parie l’inverse : faire de l’IA non pas une fonctionnalité de l’éditeur, mais le centre de gravité du produit.
Quatre ans plus tard, Anysphere est valorisée autour de 50 milliards de dollars, dépasse les 2 milliards d’ARR, et compte parmi ses clients OpenAI, Uber, Spotify et Instacart.
À côté, Microsoft a poussé Copilot vers l’agentique, OpenAI a racheté Windsurf pour 3 milliards, Cognition a sorti Devin, et une grappe d’outsiders comme Replit, Lovable ou Bolt se partagent le segment « vibe coding pour tous ». La concurrence s’est densifiée, mais Cursor et Claude code sont les références côté outils pour développeurs professionnels.
Ce qui est intéressant c’est la trajectoire produit. Cursor a fait trois métamorphoses en trois ans, chacune élargissant son périmètre et chacune éloignant le produit de ce qu’on appelle traditionnellement un IDE.
Cet article retrace ces trois phases, l’éditeur augmenté, l’agent autonome, puis le SDK ouvert sorti fin avril 2026, et se termine par un retour d’expérience sur ce SDK, à travers un générateur de slides construit avec.
Phase 1 : une IDE assistée par IA
Au début, Cursor reste fidèle à son ADN VS Code. L’utilisateur ouvre l’éditeur, écrit du code, et l’IA intervient en complément : autocomplétion plus intelligente que Copilot, chat contextuel sur le projet, édition multi-fichiers via une commande clavier.
Le différenciateur tient surtout dans la qualité du contexte, Cursor indexe le repo en arrière-plan via Turbopuffer, son fournisseur de base vectorielle, et utilise cet index pour nourrir les modèles avec les bons morceaux de code au bon moment.
Cette phase 1 est gagnante mais pas révolutionnaire. Tout le monde fait de l’autocomplétion, tout le monde commence à faire du chat-sur-repo. Cursor le fait mieux, plus vite, mais reste dans la même catégorie de produit que les autres.
Phase 2 : l’orchestrateur d’agents
La bascule vraiment structurante intervient quand Cursor cesse de positionner l’IA comme un copilote et la repositionne comme un agent.
L’utilisateur décrit une intention : « ajoute la pagination à cet endpoint », « fix le bug d’auth sur les routes admin » et l’agent agit : il lit, il édite, il run les tests, il itère. L’éditeur devient le tableau de bord d’un travailleur autonome qui tourne en arrière-plan.
Cursor pousse ensuite cette logique plus loin. L’agent quitte la machine du développeur. Avec Cursor Cloud Agents, on peut lancer un agent depuis une app web, sur une VM dédiée, avec un clone du repo, et le laisser bosser pendant qu’on dort.
L’agent ouvre une PR à la fin. La même infrastructure tourne via le CLI cursor agent, qui permet de scripter ces déclenchements depuis un terminal. L’éditeur n’est plus le seul point d’entrée. Il devient une des interfaces possibles d’un système d’agents qui vit ailleurs.
C’est à ce moment que Cursor cesse réellement d’être un IDE, même si l’IDE reste son client le plus visible.
Phase 3 : le SDK Cursor
Fin avril 2026, Cursor publie son SDK TypeScript. La proposition est simple : exposer le runtime complet qui fait tourner les agents Cursor : l’application desktop, le CLI, l’app web, sous forme d’une bibliothèque appelable depuis n’importe quel programme Node.
Six lignes suffisent à spawner un agent IA qui tourne sur un repo. On choisit le runtime (local, cloud Cursor, ou self-hosted dans son propre réseau), on choisit le modèle (Composer 2, GPT-5.5, Claude, etc.), on configure ses serveurs MCP, et on appelle.
import { Agent } from "@cursor/sdk";
const agent = await Agent.create({
apiKey: process.env.CURSOR_API_KEY,
model: { id: "composer-2" },
local: { cwd: process.cwd() },
});
const run = await agent.send("Refactor src/ to use named exports.");
for await (const event of run.stream()) console.log(event);Sur le papier c’est « encore un SDK d’agents de codage ». Anthropic a sorti son Claude Agent SDK, OpenAI a Codex SDK, tout le monde y va. Mais le pari de Cursor est différent.
Anthropic et OpenAI exposent leurs modèles comme assests principaux. Cursor expose son harness, c’est-à-dire toute la couche logicielle qui transforme un modèle en agent productif : la gestion du contexte, l’indexation Turbopuffer, le sandboxing des VMs, la persistance des sessions, l’orchestration des sous-agents, le système de hooks, l’intégration MCP. Le modèle, lui, est un paramètre. On peut brancher Composer 2, ou Claude, ou GPT-5.5, etc.
Le choix de la première verticale
Les startups gagnantes des dernières années, sont celles qui ont choisi une verticale et l’ont creusée. Harvey en juridique, Sierra en service client, Decagon en support, Cursor sur le code.
Ces entreprises ne sont pas toujours meilleures techniquement que les autres; elles ont juste résisté à la tentation de faire un assistant général, et ont accepté de devenir spécialistes d’un domaine. Le résultat, c’est qu’elles construisent des produits dont la profondeur d’usage est sans commune mesure avec un wrapper LLM généraliste.
Mon hypothèse, qui n’engage que moi, c’est que cette approche produit est duplicable presque partout. Un environnement de travail conçu autour de l’IA pour un métier donné, où le professionnel arrête de faire l’aller-retour entre dix outils et un chatbot, et commence à travailler dans un espace où l’agent vit en permanence à ses côtés.
Prenons la comptabilité. Un Cursor pour comptables, ce serait un environnement qui ouvre les écritures, les rapproche, lit les pièces justificatives, propose les imputations, alerte sur les anomalies, et laisse le comptable valider, corriger ou rediriger en langage naturel. Pas uniquement plugin Excel avec ChatGPT à côté. Un produit « AI agent first » orchestré par l’humain.
Idem pour la conformité financière, où le quotidien d’un analyste KYC ou d’un responsable LCB-FT consiste à croiser des documents, recouper des sources, produire des notes, exactement le profil de tâches qu’un agent bien câblé fait plus vite et plus consistant qu’un humain fatigué de son sixième dossier de la journée.
Idem dans le BTP pour le suivi de chantier, dans le juridique pour la due diligence, dans l’immobilier pour l’analyse de baux, dans la santé pour le codage médical. Partout où il existe un métier avec des workflows répétés, des artefacts documentaires structurés, et un coût à l’erreur qui justifie un humain dans la boucle, il y a probablement un Cursor à construire.
Le harness compte plus que le modèle
Voilà le point qui mérite d’être martelé, parce qu’il change la lecture de ce qui se passe dans l’industrie.
Cursor a sorti Composer 2 en mars 2026, son modèle de codage maison. Il a été entraîné sur la base du modèle open weight Kimi K2.5 de Moonshot AI, le labo chinois.
Ce qui rend Cursor difficile à concurrencer, ce n’est pas Composer 2. C’est tout ce qu’il y a autour. C’est l’indexation sémantique du repo via Turbopuffer, qui améliore mesurablement la précision des réponses de 12,5% selon leurs propres benchmarks internes.
C’est le harness qui orchestre les outils, gère la fenêtre de contexte, applique des hooks de politique projet, persiste les sessions cloud sur des VMs sandboxées.
C’est l’infra qui permet de lancer des centaines d’agents en parallèle sans gestion manuelle. C’est l’écosystème MCP, les sous-agents, les skills versionnés dans le repo.
Toutes ces couches sont plus difficiles à reproduire qu’un fine-tuning de modèle, parce qu’elles sont le résultat de centaines de petits choix d’ingénierie qui ne se voient nulle part dans une démo, mais qui font la différence à l’usage.
Pendant deux ans, l’industrie était convaincue que la course aux LLM se gagnerait sur la taille des modèles. Cette course est en train de se commoditiser. Les modèles convergent en qualité sur les tâches de code. Tout le monde a accès à GPT-5.5, à Claude, à Gemini. Ou même à des modèles d’une qualité proche disponible en open source/weights sur Hugging Face.
Ce qui distingue désormais un agent qui marche d’un agent qui patine, ce n’est plus le LLM. C’est le harness la couche d’ingénierie qui permet à un agent de tenir le cap pendant longtemps sur un objectif qui lui a été donné. Et le harness est une dépense de R&D qui ne se voit pas en démo mais qui fait la différence.
En exposant son harness avec le SDK Cursor, Cursor fait deux choses simultanément. Premièrement, il rend ce harness consommable hors de l’éditeur, donc le marché adressable explose. Deuxièmement, il valide publiquement la thèse selon laquelle le harness est l’asset, pas le modèle. Et cette thèse a des conséquences pour toutes les startups IA, pas seulement pour celles qui font du code.
Ce que le SDK permet, concrètement
Le SDK expose trois runtimes derrière une API unique :
- Local, où l’agent tourne dans le process Node de l’appelant et touche les fichiers du disque, pratique pour des scripts dev et des checks CI.
- Cloud (Cursor-hosted), où l’agent tourne dans une VM isolée chez Cursor, avec un clone du repo, et survit à la déconnexion de l’appelant, utile quand on lance plusieurs agents en parallèle ou qu’on veut intégrer le SDK dans un service backend.
- Cloud (self-hosted), où la même API tourne sur des VMs gérées par le client, pour les boîtes dont le code et les secrets ne peuvent pas sortir du périmètre.
Au-delà du runtime, le SDK donne accès à toutes les briques du harness. On peut configurer des serveurs MCP inline (HTTP ou stdio), définir des sous-agents spécialisés que l’agent principal spawne via un outil dédié, écouter les streams en temps réel pour pousser dans une UI ou une DB, lister et reprendre des agents cloud à distance, intercepter les deltas avec backpressure.
L’intégration Git est native : un flag autoCreatePR: true suffit à ce que l’agent ouvre une pull request à la fin de son run. L’écriture du code applicatif autour devient minime ; l’essentiel du travail d’ingénierie est déjà fait par Cursor.
Exemple pratique : un générateur de slides avec le SDK Cursor
Pour mettre les mains dedans, j’ai construit un petit projet : cursor-slides, une app Next.js qui prend en entrée un dossier de documents hétérogènes (PDF, images, notes Markdown) plus une instruction en langage naturel (« fais-moi un deck exécutif de 10 slides »), et qui renvoie un deck HTML rendu par un agent Cursor, exportable en PDF d’un clic. Le code est sur github.com/IlyesTal/cursor-slides.
J’ai codé ce petit projet pour deux raisons. D’abord, c’est l’exercice le plus court que j’aie trouvé pour tester le SDK de bout en bout : upload, agent, streaming, fichiers générés sur disque, rendu dans une UI.
Ensuite, parce que le vrai super-pouvoir de Cursor, indexer un workspace et raisonner dessus, n’est pas spécifique au code. Pointer un agent sur un répertoire de PDF et récupérer un artefact structuré (ici un deck), c’est exactement la primitive qui sous-tend la synthèse de recherche, la due diligence, la génération de matériel d’apprentissage ou les bases de connaissances internes. Les slides, c’est juste la version la plus visuelle.
Architecture
Le flux tient en une route Next.js et un fichier d’orchestration :
upload (drag & drop)
└─► POST /api/generate (SSE)
├─ écrit les fichiers dans jobs//inputs/
├─ extrait le texte des PDF avec pdf-parse → inputs/.extracted.txt
├─ écrit un WORKSPACE.md qui sert d'index à l'agent
├─ Agent.create({ local: { cwd: jobs/ } })
│
├─ Phase 1 scan → analysis.md (agent.send #1)
├─ Phase 2 plan → plan.md (agent.send #2)
└─ Phase 3 generate → slides/slide-NN.html (agent.send #3) Chaque phase est un agent.send() distinct, sur la même instance d’agent. Ça permet à l’UI de réinitialiser l’état d’avancement à chaque étape, et ça garde des prompts très ciblés au lieu d’un méga-prompt qui essaie de tout faire d’un coup. L’agent réutilise son contexte d’une phase à l’autre puisqu’il vit dans le même cwd.
Choix de runtime et de modèle
J’ai pris le runtime local (Agent.create({ local: { cwd } })) plutôt que cloud, pour deux raisons concrètes :
- Chaque job est sandboxé dans son propre répertoire
jobs/. Beaucoup plus simple à raisonner que de partager un repo./ - Itération rapide pendant le dev : pas de push, le
cwdest juste un dossier que je peux inspecter à la main entre deux runs.
Côté modèle, c’est paramétré par variable d’environnement et ça tient en un champ :
const MODEL_ID = process.env.CURSOR_SLIDES_MODEL || "composer-2";
agent = await Agent.create({
apiKey,
model: { id: MODEL_ID },
local: { cwd },
name: `slides-${jobId}`,
});Le stream
Le SDK Cursor permet d’extraire le stream pour monitorer l’agent en temps réel. run.stream() renvoie un AsyncIterable typé, et on choisit ce qu’on remonte à l’UI :
const run = await agent.send(prompt);
// Permet à l'utilisateur d'annuler depuis l'UI
signal.addEventListener("abort", () => run.cancel().catch(() => {}), { once: true });
for await (const event of run.stream() as AsyncIterable) {
switch (event.type) {
case "assistant":
// texte que l'agent "dit" → log d'activité
break;
case "tool_call":
// n'émet qu'à la complétion pour garder le log lisible
if (event.status === "completed" || event.status === "error") {
send("tool", { name: event.name, status: event.status });
}
break;
case "task":
send("log", { level: "info", text: event.text });
break;
// "thinking" : volontairement filtré côté UI
}
}
const result = await run.wait();
if (result.status === "error") throw new Error(result.result); 
Laisser un commentaire