Analyse de Cursor Composer et SWE‑1.5 – Pourquoi une entreprise de 10 milliards de dollars a-t-elle sorti un modèle médiocre.
Analyse de Cursor Composer et SWE‑1.5 – Pourquoi une entreprise de 10 milliards de dollars a-t-elle sorti un modèle médiocre.
Introduction
Le marché des assistants de codage IA s’enflamme, et cette semaine deux acteurs majeurs – Cursor et Windsurf – ont dévoilé de nouveaux modèles, Cursor Composer et SWE‑1.5. Tous deux promettent une latence ultra‑faible pour le « codage agentique », mais la technologie sous‑jacente et les performances soulèvent de sérieuses questions. Cet article décortique les capacités revendiquées des modèles, la méthodologie de test, et explique pourquoi les résultats risquent de décevoir même les utilisateurs les plus indulgents.
Contexte sur les nouveaux modèles
Cursor Composer
- Présenté comme un modèle « de pointe » quatre fois plus rapide que les LLM comparables.
- Conçu pour des tâches de codage à latence faible et à plusieurs étapes, la plupart des tours se terminant en moins de 30 secondes.
- Bâti sur une base « open‑weights » non divulguée, prétendument issue d’un modèle de classe 4,6.
- Aucun résultat de benchmark public n’a été publié, ce qui rend la vérification indépendante difficile.
SWE‑1.5 (Windsurf)
- Promu comme le plus rapide des deux, atteignant jusqu’à 950 tokens par seconde sur du matériel Cerebras.
- Entraîné sur une base open‑source non précisée, avec des données d’apprentissage par renforcement propriétaires.
- Positionné comme une alternative à haut débit pour la génération de code.
Méthodologie de test
L’évaluation a utilisé les outils CLI officiels fournis par chaque éditeur :
- Cursor Composer – accessible via le CLI de Cursor (l’interface éditeur n’affichait que le modèle plus ancien Cheetah).
- SWE‑1.5 – accessible via l’éditeur Windsurf.
Les deux modèles ont été confrontés à une batterie de défis de codage représentatifs, allant de simples calculateurs à des prototypes d’applications web plus complexes. Le temps d’exécution, la justesse et le taux d’erreurs ont été enregistrés pour chaque tâche.
Aperçu des performances
Cursor Composer
- Application de suivi de films – de nombreuses erreurs d’interface ; la vue « discover » était cassée.
- Calculatrice UI Goatee – fonctionnait correctement, montrant que le modèle peut gérer une logique simple.
- Jeu Godo – ne s’est pas exécuté ; des modèles modernes comme GLM‑4.5 et Miniax le font aisément.
- Grande tâche Open‑code – n’a pas été terminée.
- Application Spelt – seule l’écran de connexion apparaissait ; les erreurs côté serveur étaient omniprésentes.
- Recadrage d’image Rust Tari – non fonctionnel.
- Classement global : 11ᵉ sur le tableau interne, derrière des modèles tels que Kilo, Miniax et GLM‑4.5.
SWE‑1.5
- Classé 19ᵉ sur le même tableau.
- A pu générer une interface de calculatrice mais n’a pas effectué les calculs.
- A régulièrement produit du code incorrect ou incomplet tout au long de la suite de tests.
Pourquoi les résultats importent
- Manque de transparence – Les deux entreprises cachent le modèle de base exact qu’elles ont affiné. La description laisse penser à une lignée GLM‑4.5 ou Qwen‑3‑Coder, mais aucune preuve concrète n’est fournie.
- Compromis vitesse vs qualité – Bien que SWE‑1.5 atteigne un débit de tokens supérieur, la qualité du résultat est souvent inutilisable. La vitesse seule ne compense pas un code défectueux.
- Benchmarks manquants – Sans évaluations reconnues par la communauté (par ex. HumanEval, MBPP), les affirmations de performance « de pointe » restent non étayées.
- Problèmes éthiques potentiels – Déployer un modèle open‑source affiné sans attribution peut violer les normes communautaires et, dans certaines juridictions, les termes de licence.
Analyse technique
- Choix du modèle – Le comportement observé correspond davantage à Qwen‑3‑Coder ou à un checkpoint plus ancien de GLM‑4.5 qu’à un véritable modèle de classe 4,6. L’absence de raisonnement avancé et d’utilisation d’outils suggère un alignement pré‑entraînement insuffisant.
- Impact de l’apprentissage par renforcement (RL) – Les gains modestes du fine‑tuning RL sont éclipsés par le mauvais choix du modèle de base. Un alignement correct dès le pré‑entraînement serait nécessaire pour voir de réelles améliorations.
- Considérations matérielles – Les deux modèles tournent sur du matériel à haut débit (Cerebras pour SWE‑1.5, non précisé pour Cursor). Cependant, des modèles open‑source plus récents (par ex. Miniax, GLM‑4.5) atteignent déjà des vitesses comparables ou supérieures sur le même matériel, rendant l’avantage de vitesse discutable.
Implications industrielles
- Fossé de transparence – Le refus de divulguer le modèle sous‑jacent sape la confiance. Les utilisateurs ne peuvent pas vérifier si le produit est une vraie innovation ou simplement un checkpoint open‑source re‑brandé.
- Coût d’opportunité – Des entreprises valorisées à 10 milliards de dollars pourraient soit constituer des équipes ML dédiées pour développer leurs propres modèles propriétaires, soit, au minimum, créditer ouvertement le modèle de base qu’elles affinent.
- Réaction de la communauté – L’absence de critiques de la part de la communauté IA plus large laisse entrevoir une complaisance croissante autour de l’attribution des modèles.
Recommandations pour les praticiens
- Prioriser les modèles open‑source éprouvés – Quand la vitesse est cruciale, envisager des poids ouverts établis tels que Miniax, GLM‑4.5 ou Mistral‑7B et appliquer votre propre fine‑tuning.
- Valider avant d’intégrer – Exécuter une petite suite de benchmarks (génération de code, utilisation d’outils, gestion d’erreurs) avant d’adopter un nouveau modèle fournisseur.
- Exiger la transparence – Insister sur une documentation claire du modèle de base, des données d’entraînement et de la licence afin d’éviter les écueils juridiques et de performance.
Conclusion
Cursor Composer et SWE‑1.5 promettent une génération de code ultra‑rapide, mais la réalité se résume à des sorties rapides mais défectueuses. Les modèles peinent sur des tâches basiques que des checkpoints open‑source plus anciens exécutent aisément, et le processus de développement opaque soulève des questions éthiques. Tant que les entreprises ne dévoilent pas leurs fondations ou ne livrent pas un modèle réellement supérieur, les développeurs seront mieux servis en s’en tenant à des alternatives bien documentées et validées par la communauté.
Cet article reflète une évaluation technique indépendante et n’appuie aucun produit en particulier.