Cursor atteint 5 millions de développeurs. VS Code regarde par-dessus son épaule.

VS Code reste l'outil dominant pour les développeurs selon tous les indicateurs qui comptent : 75,9 % d'utilisation quotidienne en 2025, un écosystème d'extensions massif, une intégration poussée avec GitHub et tout le poids de l'ingénierie de Microsoft derrière lui. Pourtant, la même année, Cursor – un fork de VS Code âgé de trois ans, bâti autour de workflows IA-first – a connu une croissance de 120 % sur un an pour atteindre 5 millions de développeurs en mai 2026, avec 67 % des entreprises du Fortune 500 qui le déploient dans au moins une équipe.

Cette trajectoire mérite qu'on s'y attarde. Non pas parce que VS Code est en train de perdre, mais parce que la croissance de Cursor révèle ce que les développeurs attendent désormais de leurs outils.

Ce que « natif IA » signifie réellement

La plupart des plugins et extensions d'IDE ajoutent l'IA sous forme de panneau latéral – un chat que vous invoquez, une suggestion que vous pouvez accepter ou ignorer. Le modèle de Cursor est différent : il considère la base de code comme le contexte principal de toutes les interactions IA. Son mode Composer permet d'apporter des modifications sur plusieurs fichiers simultanément, en faisant référence aux fonctions et structures de données de l'ensemble du projet, et pas seulement du fichier en cours d'édition.

L'autocomplétion au niveau diff ne se contente pas de suggérer des lignes – elle suggère des refactorisations multi-lignes dans le contexte du code environnant, anticipant souvent l'objectif de la modification en se basant sur la signature de la fonction et le code adjacent. Le chat contextuel de codebase permet de demander « pourquoi le middleware d'authentification rejette-t-il les requêtes avec cet en-tête ? » et d'obtenir une réponse qui a effectivement lu votre implémentation du middleware, plutôt qu'une explication générique du fonctionnement de JWT.

Ces fonctionnalités ne s'intègrent pas facilement dans un modèle de plugin. Elles nécessitent un accès à l'état complet de l'espace de travail au niveau de l'IDE. C'est pourquoi Cursor devait être un éditeur, pas une extension.

L'avantage de VS Code qui est aussi une contrainte

La domination de VS Code tient en partie à son écosystème d'extensions : plus de 50 000 extensions couvrant tous les langages, frameworks et workflows. Cursor en hérite entièrement – il exécute les extensions VS Code nativement, ce qui élimine la plupart des frictions de transition. Un développeur qui passe de VS Code à Cursor ne perd ni son thème, ni son serveur de langage, ni sa configuration de débogueur.

Mais cette rétrocompatibilité crée aussi des contraintes. L'architecture de VS Code a été conçue avant l'existence des modèles de langage de grande taille. L'API d'extension reflète des hypothèses sur ce à quoi ressemble une « suggestion de code » qui ne s'adaptent pas bien aux modifications génératives multi-fichiers. Microsoft a ajouté des capacités IA via Copilot, mais il travaille dans une architecture qui n'a pas été conçue pour cela.

Cursor, ayant fork VS Code au niveau de base, peut instrumenter le cœur de l'éditeur d'une manière que les extensions ne peuvent pas. C'est de là que vient sa performance sur les tâches multi-fichiers – ce n'est pas un contournement, c'est un accès architectural.

Zed : l'autre défi

Là où Cursor rivalise sur la profondeur IA, Zed rivalise sur les fondamentaux. L'éditeur natif Rust a lancé la v1.0 en avril 2026, avec des temps de démarrage de 0.12 à 0.4 seconde (contre 1.2 à 3.0 secondes pour VS Code) et une utilisation mémoire au repos de 142 à 200 Mo (contre 650 Mo à 1.2 Go pour VS Code).

Pour les développeurs qui travaillent sur des MacBook avec 16 Go de RAM et une douzaine d'onglets de navigateur ouverts, l'écart mémoire est perceptible. Le rendu à 120 fps de Zed via une mise en page de texte accélérée par GPU rend le défilement dans les fichiers volumineux radicalement différent du rendu basé sur navigateur que VS Code hérite d'Electron.

Le modèle d'extension de Zed utilise un sandboxing basé sur WASM – un écosystème plus petit que celui de VS Code, mais plus performant et plus sécurisé. Son intégration IA passe par une API ouverte plutôt qu'une implémentation spécifique au fournisseur, ce qui facilite l'échange des modèles sous-jacents.

Ce que les développeurs choisissent réellement

Le sondage AI Pulse de JetBrains de janvier 2026 a révélé que 18 % des développeurs utilisent Cursor au travail et 18 % utilisent Claude Code – l'agent de codage en ligne de commande – à quasi-parité mais bien en dessous de la base de VS Code. GitHub Copilot reste l'outil de codage IA le plus déployé en nombres absolus, mais sa croissance a ralenti à mesure que les alternatives gagnaient du terrain.

Le schéma qui se dessine : Cursor domine parmi les équipes qui font du développement greenfield ou qui travaillent sur des bases de code vastes et complexes où le contexte multi-fichiers est important. Zed attire les développeurs pour qui la performance est une contrainte – gros monorepos, matériel ancien ou préférence pour des outils légers. VS Code reste le choix par défaut pour les équipes où la standardisation et la compatibilité des plugins priment sur la profondeur IA ou les performances brutes.

La question pour Microsoft

Microsoft a les ressources pour construire ce que Cursor a construit – et il s'est déjà orienté dans cette direction avec l'intégration de plus en plus poussée de GitHub Copilot dans VS Code. Le défi, c'est que les décisions architecturales prises en 2015 contraignent désormais ce qui est possible sans une réécriture majeure.

La guerre des IDE n'est pas terminée, et VS Code n'est pas en danger de perdre sa pluralité. Mais la définition du « meilleur outil de développement » passe de « le plus de fonctionnalités et d'extensions » à « le plus efficace pour le développement assisté par IA ». C'est une course où un petit compétiteur focalisé, avec une flexibilité architecturale, bénéficie d'avantages que la part de marché et l'héritage ne compensent pas.