Cursor franchit les 5 millions de développeurs : ce que son intelligence de code fait vraiment

Cursor a franchi le cap des 5 millions de développeurs actifs mensuels début 2025, contre environ 500 000 au début de 2024. C'est désormais l'outil pour développeurs qui connaît la croissance la plus rapide depuis npm. L'histoire de cette croissance est largement couverte — 400 millions de dollars en Série B pour une valorisation de 9,9 milliards en janvier 2025, adoption massive par des entreprises comme Stripe, Shopify et Samsung. Ce qui est moins bien expliqué, c'est l'architecture technique réelle qui distingue Cursor de GitHub Copilot (environ 1,8 million d'utilisateurs payants), de JetBrains AI Assistant ou d'Amazon Q. Cet article traite de ce que Cursor fait techniquement, pas commercialement.

Indexation du codebase : les fondations

L'architecture originale de GitHub Copilot reposait sur le contexte du document : le modèle voit le fichier courant, la position du curseur et une petite fenêtre de code environnant. Il n'a aucune connaissance structurelle du codebase dans son ensemble. La première fonction différenciatrice de Cursor a été l'indexation du codebase — un processus lancé à l'ouverture du projet qui produit un index vectoriel sémantique de chaque fichier du dépôt.

Le processus d'indexation combine analyse AST et génération d'Embedding. Le code est découpé au niveau des fonctions et des classes (pas par fenêtres d'octets arbitraires), et chaque morceau est encodé via un modèle d'Embedding spécialisé pour le code. Cursor utilise un modèle propriétaire fine-tuné sur du code, pas un modèle générique de texte. Ces Embedding sont stockés localement dans une instance LevelDB dans le répertoire .cursor, indexés pour une recherche par plus proche voisin approximative via FAISS.

Quand vous posez une question à Cursor ou déclenchez une complétion, la requête est aussi encodée, et une recherche sémantique récupère les 20 à 40 morceaux de code les plus pertinents dans tout le codebase. Ces morceaux sont injectés dans la fenêtre de contexte avant que le modèle ne voie votre demande. C'est du RAG appliqué spécifiquement au code — et c'est ce qui permet à Cursor de répondre correctement à des questions comme "comment fonctionne l'authentification dans ce codebase ?" alors que Copilot hallucinerait une réponse à partir de ses données d'entraînement.

L'espace de travail fantôme

La fonctionnalité la plus intéressante architecturalement de Cursor est ce qu'il appelle le shadow workspace. Quand vous demandez à Cursor de faire une modification, il ne se contente pas de diffuser des tokens dans votre éditeur. Il ouvre une version cachée en mémoire de votre fichier, applique la modification proposée, et exécute une série de validations avant de vous montrer le résultat.

Les validations incluent la vérification de types TypeScript (via l'intégration LSP tsserver), la résolution des imports (vérification que les nouveaux imports ajoutés par le modèle existent bien dans votre graphe de dépendances), et une vérification syntaxique via tree-sitter. Si l'une échoue, la boucle de contrôle de Cursor demande au modèle de réviser sa sortie — généralement 1 à 2 passes d'inférence supplémentaires — avant d'afficher le résultat.

C'est le mécanisme derrière le taux d'hallucination plus faible de Cursor sur les complétions de code par rapport aux sorties brutes du modèle. Le modèle hallucine toujours ; l'espace de travail fantôme rattrape une fraction significative des hallucinations avant qu'elles n'atteignent votre écran. Dans les benchmarks internes de Cursor (publiés dans un article de blog en octobre 2024), la validation du shadow workspace a réduit les sorties de code syntaxiquement invalides de 67 % et celles contenant des erreurs de type de 44 % par rapport au même modèle sans validation.

Éditions spéculatives et mode Apply

La fonctionnalité "Apply" de Cursor — où vous décrivez un changement en langage naturel et il est appliqué sur plusieurs fichiers — utilise un Pipeline en plusieurs étapes. D'abord, le modèle génère un plan de diff : une liste structurée des fichiers à modifier et du changement, en pseudocode. Ensuite, un second modèle (plus petit et plus rapide) convertit chaque élément du plan en un diff de code réel. Enfin, le shadow workspace valide chaque diff avant qu'il ne soit mis en scène.

L'approche avec deux modèles est cruciale car la génération de diff et l'écriture de code sont des tâches cognitives différentes. Un grand modèle de contexte (Claude 3.5 Sonnet ou GPT-4o dans le système de routage de Cursor) gère l'étape de planification, où la compréhension du contexte complet du codebase est essentielle. Un modèle plus petit et plus rapide (typiquement une version fine-tunée de DeepSeek Coder ou Code Llama) gère la traduction mécanique du plan en code, où la vitesse prime sur la compréhension en profondeur du contexte. La latence de Cursor sur les opérations Apply multi-fichiers est généralement de 3 à 8 secondes — compétitive avec le fait de taper la modification manuellement pour tout ce qui dépasse une fonction unique.

Routage des modèles et relation de Cursor avec les labs d'IA

Cursor n'entraîne pas ses propres modèles fondation. Il achemine les requêtes vers Anthropic, OpenAI et ses propres variantes fine-tunées selon le type de tâche. La logique de routage n'est pas publique, mais d'après les analyses de trafic réseau publiées par des chercheurs indépendants fin 2024, Cursor utilise Claude 3.5 Sonnet comme modèle principal pour les requêtes conversationnelles et le raisonnement multi-fichiers, GPT-4o pour les complétions Tab (où son entraînement sur le code est mieux adapté), et un petit modèle propriétaire fine-tuné pour la boucle de validation du shadow workspace.

Le modèle économique de Cursor signifie qu'il paie par Token à ces fournisseurs. Avec 5 millions d'utilisateurs actifs faisant plusieurs centaines de complétions par jour, le coût de calcul est substantiel — ce qui explique la levée de 400 millions de dollars. L'entreprise a indiqué travailler sur sa propre infrastructure d'entraînement, mais c'est un travail pluriannuel. Pour l'instant, la différenciation de Cursor est architecturale (l'indexation, le shadow workspace, la couche de routage) plutôt que la qualité du modèle.

Mode privé et déploiement en entreprise

Cursor propose un mode privé qui désactive la collecte de données d'entraînement sur le codebase. Dans ce mode, le code est toujours envoyé aux API des fournisseurs d'IA pour l'inférence, mais Cursor affirme ne pas stocker les paires requête/réponse. Pour les clients entreprise, une option auto-hébergée achemine toute inférence via les propres clés API du client et éventuellement via un chemin réseau privé.

Le niveau entreprise (40 $/utilisateur/mois) inclut la conformité SOC 2 Type II, le SSO via Okta et Microsoft Entra, et la journalisation d'audit. C'est le niveau qu'utilisent Stripe et Shopify. La certification de conformité a été terminée au T3 2024 — avant quoi, Cursor n'était pas largement déployable dans les entreprises ayant des exigences strictes de gouvernance des données.

Ce que Cursor ne fait pas bien (encore)

L'indexation du codebase de Cursor a une limite dure d'environ 100 000 tokens de contexte indexé par requête — environ 75 000 à 100 000 lignes de code indexées remontées par demande. Pour les gros monorepos de plusieurs millions de lignes, le code pertinent peut ne pas se trouver dans les morceaux récupérés, ce qui provoque les mêmes problèmes d'hallucination que les outils plus simples. L'équipe d'ingénierie a évoqué cette limitation connue dans plusieurs forums de développeurs.

La collaboration en temps réel est absente. Cursor est un éditeur mono-utilisateur. Les équipes qui l'utilisent travaillent en parallèle sur des instances séparées, ce qui crée des problèmes de coordination sur les fichiers partagés qu'un protocole de serveur de langage traditionnel gère naturellement. JetBrains et VS Code ont de meilleures réponses ici. La feuille de route produit de Cursor a mentionné des "fonctionnalités collaboratives" pour 2025-2026 sans précisions.

Points clés à retenir

• Si vous n'avez pas configuré l'indexation du codebase : ouvrez les paramètres de Cursor et vérifiez que "Codebase Indexing" est activé (il l'est par défaut). Consultez l'état de l'index sous Cursor > Settings > Features > Codebase Indexing. Les gros dépôts peuvent nécessiter 5 à 10 minutes pour une indexation complète à la première ouverture.
• Pour les modifications multi-fichiers, utilisez le mode Composer (pas Chat) : Composer déclenche le pipeline complet d'éditions spéculatives avec validation par le shadow workspace. Le mode Chat utilise une approche plus simple en un seul passage. La différence de qualité est significative pour les tâches de refactoring.
• En mode privé, votre code quitte quand même votre machine : il part vers les API d'Anthropic et OpenAI. Si vous avez besoin d'inférence vraiment locale, le chemin auto-hébergé entreprise de Cursor prend en charge le routage vers des instances Ollama locales – mais cela nécessite le niveau entreprise.
• Pour les gros monorepos : ancrez manuellement les fichiers pertinents dans le contexte en utilisant les mentions @ plutôt que de vous fier uniquement à la recherche sémantique. La récupération RAG n'est pas parfaite, et exposer explicitement les bons fichiers améliore nettement la qualité des sorties.