Cursor a fait son choix : exit Spokes, place à Continuity.

Le premier est un système de stockage distribué fondé sur le consensus. Né au début des années 2010, il est devenu le substrat de nombreux services d’hébergement Git.

Le second est une tentative d’en pallier les limites – tant en matière de scalabilité que de maintien de la cohérence. Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grands lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle.

Sur cette base, Cursor a développé une forge qu’il a appelée Origin. Mi-août, il a commencé à y donner accès, en bêta, pour les abonnés à ses forfaits payants.

En façade, il n’y a pour le moment pas de spécificités fonctionnelles par rapport à la concurrence. Il y a surtout beaucoup moins d’intégrations : le catalogue se limite à Vercel, Depot et Buildkite.

Cursor a soigné les passerelles avec GitHub, mais tout n’est pas encore synchronisé (issues et workflows CI, par exemple). Il promet notamment, sur le court terme, des jonctions avec ses agents.

Pannes répétées pour GitHub, victime de « surcharge agentique »

L’annonce d’Origin est tombée le jour même où GitHub a connu sa dernière panne majeure en date. Au pic, les taux d’erreur web et API ont avoisiné 20 % (50 % sur l’archivage et le téléchargement de fichiers). En cause, une saturation réseau sur des load balancers aux États-Unis. Le problème découlait d’une politique d’autoscaling mal configurée, en conséquence de quoi un pod Istio avait atteint ses limites de concurrence.

GitHub a connu d’autres pannes importantes ces dernières semaines. En particulier sur le CI. Le 9 juillet, la dégradation d’un service de provisionnement d’exécuteurs hébergés a empêché certains workloads d’en acquérir. Dix jours plus tard, une expiration de certificat SSL a entraîné une perte de connectivité pour certains runners. Début août, à la suite d’un déploiement de routnie vers un service interne de traitement d’événements et de création de jobs, jusqu’à 70 % des flux CI ont échoué. Une autre perturbation est survenue à la fin du mois, due à une saturation des écritures vers une base de données exploitée par les déclencheurs.

Ces derniers mois, la plate-forme a plus globalement souffert d’un net accroissement de la charge dans le contexte du développement agentique. Le problème n’est toutefois pas tant lié à GitHub qu’à Git. Ainsi Cursor n’a-t-il pas seulement conçu Origin, mais aussi Continuity.

Remédier aux limites de scalabilité de Spokes

Git s’accommode mal de la cohérence éventuelle. Il est préférable de la maintenir en continu. Pour cela, Spokes accepte un coût de complexité très élevé.

À son lancement, trois répliques par dépôt représentaient le compromis idéal, d’après Cursor. Aujourd’hui, les choses ont changé : les repos se sont massifiés.

Dès lors qu’on commence à ajouter des répliques apparaît un problème de la longue traîne, la latence de chaque étape étant déterminée par le serveur le plus lent du cluster. Cette contrainte de scalabilité vaut aussi dans l’autre sens. Lorsque des agents travaillent sur un monorepo, ils opèrent souvent en dehors, créant un grand nombre de petits dépôts. Soit autant de répliques à maintenir pour garantir entièrement la cohérence.

Cursor souligne un autre défaut de Spokes : puisque les dépôts sur disque constituent toujours la source de vérité pour le consensus, chaque copie est importante. Il faut donc savoir exactement où se trouve chaque dépôt. Ce qui ajoute une dépendance envers une table de routage externe.

Pas de consensus ni d’état

Pour garantir une scalabilité horizontale entièrement cohérente, le composant central de Continuity est donc le journal d’écriture anticipée. Chaque push y est stocké sous la forme d’un objet distinct. Le packfile (format de sérialisation binaire de Git) est à la fois envoyé sur disque et téléversé sur S3. Un push ne devient cependant visible qu’après préparation de la transaction de référence sur une copie locale du dépôt et enregistrement d’un pointeur vers l’entrée WAL dans le fichier d’index. L’ensemble garantit que tous les pushs sont linéarisables, explique Cursor.

Comme il suffit de synchroniser la transaction de référence avec un seul dépôt local plutôt qu’avec un quorum de répliques, le système peut ingérer les pushs aussi vite que le permet le disque.

Continuity élimine aussi le besoin de suivre l’emplacement de chaque dépôt sur chaque serveur. La source de vérité reste le journal d’écriture anticipée. Le système est sans état et ne nécessite ni tables de routage, ni base de données relationnelle. Si un dépôt est absent du disque local lors d’un accès sur un hôte, on le matérialise à partir du WAL.
Il n’y a pas non plus de consensus : n’importe quel serveur peut être le principal. La synchronisation du WAL se fait par une opération atomique de comparaison et d’échange sur S3. Il est donc toujours sûr que n’importe quelle instance d’un dépôt reçoive un push, prétend Cursor.

Jusqu’à 300 pushs par seconde

Continuity effectue une réplication optimiste en envoyant des paquets UDP de gossip dans le cluster. Chaque réplique connaît l’ETag (entity tag) de la dernière version de l’index WAL qu’elle a rattrapée. Les opérations de lecture sur une réplique consistent en des requêtes GET conditionnelles avec l’ETag attendu. Avoir S3 comme source de vérité évite les problèmes quand le paquet UDP se perd ou arrive sur le mauvais serveur. Le système passant à l’échelle dans les deux directions, chaque dépôt dispose du bon nombre de répliques, selon Cursor. Et le débit des opérations Git en lecture seule (clone, fetch…) augmente linéairement.

Continuity amortit par ailleurs le coût du compactage. Seul le nœud principal l’effectue. Le résultat s’applique à la fois au dépôt sur disque et au WAL. Comme toutes les répliques suivent le WAL, elles suivent aussi les événements de compactage.

Le débit des pushs d’un cluster dépend de la latence de mise à jour du WAL. Avec S3 Standard, Cursor parvient à maintenir 120 pushs par seconde. Avec Express One Zone, il atteint 300 pushs/s. Le facteur limitant est la vitesse à laquelle Git peut compacter les données sur disque. Cursor dit travailler sur des méthodes d’organisation de ces données afin de réduire l’impact du compactage.

Illustration générée par IA

The post Cursor s’appuie sur S3 pour repenser Git… et concurrencer GitHub appeared first on Silicon.fr.

OpenAI a annoncé qu'il allait couper l'accès de ses modèles à Cursor, l'éditeur de code dopé à l'IA que s'arrachent les développeurs. En cause, le rachat de Cursor par SpaceXAI, l'entité née de la fusion des activités IA d'Elon Musk.

Officiellement, OpenAI laisse du temps. La coupure est fixée au 12 novembre 2026, soit le délai le plus long permis par le contrat, même si Cursor peut décider d'arrêter plus tôt.

Le motif, lui, est assez clair. OpenAI dit ne pas pouvoir faire confiance à SpaceXAI pour respecter ses conditions d'utilisation, en s'appuyant sur son expérience des entreprises de Musk qui violent les contrats.

Il faut dire que les deux camps se détestent depuis un bail. Musk a été l'un des premiers investisseurs d'OpenAI, avant de claquer la porte en 2018 quand on lui a refusé le contrôle du conseil. En 2024, il a attaqué OpenAI en justice pour l'empêcher de devenir une société commerciale. En mai dernier, un jury lui a donné tort sur toute la ligne.

Surtout, OpenAI ressort dans l'affaire une révélation gênante du procès. Lors d'un contre-interrogatoire, Musk a reconnu que xAI avait entraîné ses propres modèles à partir des réponses d'OpenAI, une technique appelée distillation. Autrement dit, faire apprendre son IA en recopiant celle du voisin. Difficile, ensuite, de laisser Cursor entre les mains du même Musk sans se poser de questions.

OpenAI en profite pour mettre en avant son prochain modèle, Astra, et une vigilance accrue sur son usage. Un modèle que l'entreprise a d'ailleurs ralenti récemment, après que ses agents se sont échappés de leur bac à sable pour aller taper sur la plateforme Hugging Face.

Du côté de Cursor, le patron Michael Truell relativise. Il assure qu'OpenAI ne pèse que 5 pour cent des usages de l'outil, et que les discussions continuent pour trouver une sortie de crise. Anthropic, le grand rival, a tout de suite tendu la main, en promettant plus de puissance de calcul pour faire tourner ses modèles Claude dans Cursor.

Résultat, Anthropic récupère des développeurs sans lever le petit doigt, pendant que Musk et OpenAI continuent de se regarder dans le blanc des yeux.

Source : OpenAI

Le rachat de la plateforme de programmation par SpaceX soulève de nombreuses questions stratégiques. Elon Musk a récemment réuni les nouvelles recrues lors d’une assemblée générale mémorable. Le milliardaire a exposé sans détour ses ambitions face à la concurrence féroce d’Anthropic et d’OpenAI. Un tel discours interne révèle une volonté farouche de rattraper un déficit ... Lire plus

SpaceX ne perd pas de temps. À peine remis des feux d’artifice de son entrée en Bourse, le groupe d’Elon Musk annonce le rachat d’Anysphere, la société derrière l’agent de codage IA Cursor, pour la somme record de 60 milliards $.

L’opération devrait être finalisée au troisième trimestre 2026.

Le mouvement n’est pas une surprise totale. SpaceX avait sécurisé en avril une option lui permettant soit de racheter Cursor pour 60 milliards $, soit de payer 10 milliards pour un simple partenariat.

C’est la première option, la plus ambitieuse, qui a finalement été retenue. Selon les documents déposés mardi, Cursor recevra l’intégralité de la somme en actions SpaceX.

Fondée en 2023 par quatre diplômés du MIT à l’origine comme projet de messagerie chiffrée, Cursor s’est réorientée vers les outils de codage par IA.

Sa technologie permet aux développeurs de basculer entre plusieurs modèles d’IA, ceux d’OpenAI, d’Anthropic, de xAI ou de Google, pour concurrencer Claude Code d’Anthropic et Codex d’OpenAI.

La société, qui avait décliné plusieurs offres de rachat de grands groupes d’IA l’an dernier, avait été valorisée 29,3 milliards $ lors d’un tour de table en novembre.

Renforcer xAI sur le terrain du codage

Pour SpaceX, l’enjeu est de donner à xAI, le concepteur du chatbot Grok, une présence plus solide sur le marché du codage assisté par IA. Cursor pourra s’appuyer sur Colossus, le supercalculateur d’entraînement IA développé par xAI à Memphis, dans le Tennessee, doté d’une puissance équivalente à un million de puces H100.

Dans un message publié sur X au moment de l’annonce de l’option en avril, SpaceX décrivait l’objectif : combiner le produit phare de Cursor et sa distribution auprès des développeurs experts avec la puissance de calcul de Colossus.

Le rapprochement entre les deux équipes avait d’ailleurs déjà commencé. En mars, deux responsables de l’ingénierie produit chez Cursor avaient rejoint SpaceX pour travailler sur les projets lunaires du groupe ainsi que sur xAI.

The post SpaceX avale Cursor pour 60 milliards $ appeared first on Silicon.fr.

Elon Musk a de l’intérêt pour Cursor… au point de songer à l’acquérir.

Le nouvel ensemble SpaceX – xAI a posé une option d’achat à 60 Md$. Si l’opération n’est pas bouclée d’ici à la fin de l’année, il versera 10 Md$ à la start-up, officiellement « pour ses travaux ».

SpaceXAI and @cursor_ai are now working closely together to create the world’s best coding and knowledge work AI.

The combination of Cursor’s leading product and distribution to expert software engineers with SpaceX’s million H100 equivalent Colossus training supercomputer will…

— SpaceX (@SpaceX) April 21, 2026

xAI, fournisseur d’infra GPU pour Cursor

Les travaux en question portent sur le développement d’une « IA pour le codage et le travail de la connaissance ». L’entraînement se fera sur Colossus, supercalculateur pour lequel SpaceX revendique une puissance équivalente à 1 million de H100.

Cette IA est peut-être Composer 2.5, prochaine génération du modèle référent de Cursor. La semaine dernière, on avait en tout cas appris que xAI allait louer de la puissance de calcul (« des dizaines de milliers de GPU ») à la start-up.

En mars, deux pontes de Cursor avaient rejoint xAI, où ils supervisent désormais l’équipe produit. La start-up visait alors, dans le cadre d’un tour de table à venir, une valorisation de 50 Md$ – cohérente, donc, avec le prix d’achat proposé.

Début 2026, en extrapolant son niveau de CA mensuel, Cursor en était à environ 2 Md$ d’ARR. Il en prévoit le triple pour fin 2026. Le développement de ses propres modèles, assorti d’une possibilité de bascule vers des LLM moins onéreux comme ceux de Moonshot AI (famille Kimi), lui a permis d’atteindre une marge brute positive. Sur ce plan, les ventes aux entreprises sont rentables ; pas celles aux développeurs individuels.

À consulter en complément :

Qualité logicielle : les effets cumulés des agents de codage
Ce qu’a révélé le leak de Claude Code
Les services, nouvel eldorado de l’IA
Pourquoi les mots de passe générés par IA deviennent un vrai problème

Illustration générée par IA

The post SpaceX pose une option d’achat à 60 milliards $ sur Cursor appeared first on Silicon.fr.

Au nom de l’assurance qualité logicielle, les assistants de codage IA ont besoin de nouvelles formes d’autodiscipline.

Des universitaires de Carnegie Mellon le postulent après avoir examiné l’impact de l’adoption de Cursor sur des projets open source. Leur analyse, conduite en août 2025, a fait l’objet d’un article publié en novembre et actualisé plusieurs fois depuis (dernière version : janvier 2026).

Cette analyse s’inscrit dans une littérature foisonnante. En particulier, dans la lignée d’une étude ayant associé l’Université Queen’s (Canada) et le Collège doctoral de sciences et techniques de Nara (Japon). Des centaines de PR GitHub générés par Claude avaient été analysés pour déteminer leur taux d’acceptation.

L’expérience menée à Carnegie Mellon est allée au-delà de cet indicateur. Elle a porté sur les effets « longitudinaux » au niveau des projets, à l’appui de métriques de vélocité et de qualité.

Une analyse centrée sur Cursor et les projets open source

L’usage de Cursor a été considéré exclusivement en mode agentique. Pour déterminer si des projets l’avaient adopté sous cette forme, les chercheurs se sont basés sur la présence de fichiers de configuration .cursorrules dans les dépôts GitHub. La date du premier commit touchant ces fichiers de configuration indique le début probable de l’adoption.

Il en a résulté un échantillon de 806 repos ayant adopté Cursor « agentique » entre janvier 2024 et mars 2025. Y a été associé un groupe de contrôle de 1380 repos qui présentaient des caractéristiques similaires avant adoption.

Dans chaque groupe, on s’assure de disposer d’au moins 6 mois d’historique avant et après adoption. On collecte, à intervalle mensuel, le nombre de commits et le nombre de lignes ajoutées. Ainsi que, à l’aide d’un serveur SonarQube Community local, trois indicateurs de qualité :

• Alertes d’analyse statique (nombre de problèmes de fiabilité, de « maintenabilité » et de sécurité)
• Taux de lignes dupliquées dans la codebase (SonarQube l’estime différemment selon les langages ; un bloc est généralement jugé ainsi s’il contient au moins 10 déclarations consécutives ou au moins 100 tokens doublonnés)
• Complexité de la codebase (niveau d’interprétabilité du code)

Des gains en vélocité… sur les deux premiers mois

L’adoption de Cursor engendre, pour reprendre les termes employés, un gain de vélocité « modestement important ». En tout cas si on se réfère au volume de code produit : environ 28,6 % de lignes en plus. Il n’y a en revanche pas d’effet net sur le volume de commits.

Dans l’un et l’autre cas, les gains ne sont significatifs que dans les deux mois suivant l’adoption (+ 281,3 % de lignes le premier mois et + 48,4 % le second ; + 54,4 % de commits le premier mois et + 14,5 % le second).

Sur l’aspect qualité, le volume d’alertes augmente en moyenne de 30,3 %. La complexité du code, de 41,6 %. Il n’y a pas d’effet significatif sur les lignes en double. Au contraire des gains de vélocité, ces hausses persistent au-delà de la période initiale d’adoption.

À assistant IA, codebase plus complexe

Sur l’ensemble des dépôts analysés, toutes choses étant égales par ailleurs, une augmentation de la vélocité de développement ne produit pas un effet significatif sur le volume d’alertes et la complexité du code.

L’adoption de Cursor n’a pas un effet significatif sur le volume d’alertes. Lorsque celui-ci augmente, la taille de la codebase en est un déterminant majeur. Cependant, même en contrôlant cette dimension, l’effet de Cursor sur la complexité du code demeure important (+ 9 % en moyenne par rapport à des projets aux caractéristiques similaires qui n’utilisent pas l’assistant).

En moyenne, là aussi toutes choses étant égales par ailleurs, un doublement de la complexité du code est corrélé à une baisse de 64,5 % du nombre de lignes. Tandis qu’un doublement des alertes est associé à une réduction de 50,3 % du nombre de lignes.
L’adoption de Cursor entraînant une augmentation moyenne de 84 % des lignes ajoutées, le gain en vélocité serait complètement annulé par un triplement de la complexité ou par un quintuplement des alertes.

Pour résumer, l’adoption de Cursor engendre une codebase intrinsèquement plus complexe, tandis que l’accumulation d’alertes et de complexité réduit la vélocité.

Des résultats globalement indépendants du niveau d’utilisation de Cursor

La méthodologie adoptée permet de détecter les traces de Cursor, mais pas la manière dont les projets s’en servent. Pour vérifier si leurs constats s’appliquaient autant aux repos utilisant Cursor de manière active qu’à ceux où l’engagement est minimal, les chercheurs ont élaboré un test. Ils ont identifié, sur chaque repo, les contributeurs ayant modifié les fichiers .cursorrules. Et calculé leur part de commits. Les repos où cette part était supérieure ou égale à 80 % ont été considérés comme « à forte adoption » de Cursor. Un deuxième ensemble a été constitué en isolant les commits ayant modifié ces fichiers post-adoption.

Les résultats sur les deux ensembles accréditent les conclusions générales. Sur les repos où l’usage de Cursor est plus élevé, l’accumulation des alertes et de la complexité est plus importante. Sur ces mêmes repos apparaît également une augmentation de vélocité. Ce qui semble indiquer que l’abandon de Cursor après adoption annule au moins une partie des gains de vélocité.

L’analyse a une autre limite : ellle ne tient pas compte de l’éventuel usage d’autres IA. Y compris des outils qui ne laisseraient pas de traces dans les repos, comme la version web de ChatGPT. Pour identifier ces repos, les chercheurs ont examiné la présence de certains éléments ; par exemple de dossiers .vscode. Sur les 806 repos du groupe principal, 382 sont concernés (345 avec GitHub Copilot, 63 avec Claude Code, 37 avec Windsurf, etc.).
Entre ces repos et ceux n’ayant vraisemblablement eu recours qu’à Cursor, les principaux résultats persistent. Il sont même amplifiés sur les repos où l’usage antérieur d’outils IA est moins probable.

L’hypothèse du cycle « excitation-frustration-abandon »

L’effondrement des gains de vélocité après les deux premiers mois contraste avec les améliorations de productivité dont certaines études témoignent au niveau des tâches.

Comme on l’a vu, l’accroissement de la vélocité est corrélé à l’accroissement de la taille de la codebase… et donc potentiellement de la dette technique. L’effet négatif de cette dette ne suffit toutefois sans doute pas à expliquer l’effondrement en question, suggèrent les chercheurs. Il faudrait effectivement, comme susmentionné, que la complexité triple – ou que les alertes quintuplent – pour annuler complètement le gain de vélocité, ce qui semble peu probable.

Une autre explication plausible réside dans le cycle « excitation-frustration-abandon ». L’effet « tout beau, tout neuf » de Cursor et C^ie pousserait à expérimenter sur les tâches où l’IA excelle, contribuant ainsi à la hausse de la vélocité. Mais lorsqu’on arrive sur des scénarios où l’IA est plus limitée, peut survenir de la frustration. Associée à la charge cognitive qu’induit la vérification de ce que produit l’IA, elle est susceptible de réduire l’usage des assistants de codage, voire d’en entraîner l’abandon. En tout cas au sein des projets open source, qui sont le point focal de l’analyse.

Les chercheurs sont formels à ce sujet : il faut interpréter leurs conclusions dans le contexte de ces projets. Qui, par rapport aux projets d’entreprise, ont leurs spécificités. Notamment des niveaux de collaboration variables qui réduisent potentiellement les revues de code. Et des contraintes de ressources qui peuvent limiter les tests et l’assurance qualité indépendamment de la vitesse de développement. Des facteurs qui amplifient probablement le cycle excitation-frustration-abandon.

Avec ou sans IA, aligner l’assurance qualité sur la vélocité

L’analyse révèle une relation nuancée la vélocité de production du code et sa qualité. Si les niveaux absolus d’alertes augmentent après l’adoption de Cursor, l’effet est en grande partie attribuable à l’accroissement de la vélocité, qui elle-même accroît la taille de la codebase, qui elle-même accroît la dette technique.

Si les assistants IA de codage permettent de produire du code plus rapidement, ils n’introduisent pas forcément davantage de problèmes de qualité qu’au sein des projets « sans IA » ayant la même vélocité. Une telle relation plaide pour un passage à l’échelle de l’assurance qualité en fonction de la vélocité.

La complexité du code mérite une attention particulière, en ce qu’elle est distincte des problèmes de qualité. Elle augmente même en tenant compte des dynamiques de vélocité. Ce qui tend à prouver que le code que génère Cursor est intrinsèquement plus complexe que celui qu’écrit l’humain*. La dette créée peut en être d’autant plus lourde. Une autre raison potentielle du gain très éphémère de vélocité.

Envisager un mécanisme de bridage

Si l’adoption de Cursor n’engendre pas de changements importants sur la duplication des lignes, le phénomène est un peu plus net chez les « gros » utilisateurs de l’assistant.

Pour le passage à l’échelle de l’assurance qualité, les chercheurs suggèrent notamment des sprints de refactoring déclenchés par l’atteinte de seuils. Ils estiment que ces seuils pourraient aussi guider le comportement des assistants. Lesquels pourraient, par exemple, se mettre à produire moins dès lors que la codebase franchirait un niveau de complexité et/ou de dette, forçant les développeurs à optimiser avant de continuer. De manière moins « agressive », ils pourraient aussi suggérer des tests et recommander des pistes de refactoring.

* Cet écart tient peut-être aux objectifs d’entraînement des modèles sous-jacents. En l’occurrence, une priorisation de la réussite aux tests par rapport à la satisfaction des exigences non fonctionnelles comme la lisibilité du code.

Illustration principale générée par IA

The post Qualité logicielle : les effets cumulés des agents de codage appeared first on Silicon.fr.