OpenAI coupera Cursor le 12 novembre : les développeurs devront basculer
OpenAI a notifié SpaceX le 28 août 2026 de son intention de résilier le contrat par lequel ses modèles sont directement fournis à Cursor. Dans son annonce officielle sur la rupture, l’entreprise propose une coupure le 12 novembre 2026 et exclut déjà la livraison de ses futurs modèles à l’éditeur.
Cette décision ne signifie pas que Cursor fermera à cette date. Elle vise une relation de fourniture précise : l’accès aux modèles qu’OpenAI livre à Cursor pour les intégrer à son offre. Les développeurs qui dépendent de ce circuit devront changer de modèle ou utiliser un accès OpenAI distinct ; les autres fonctions de l’éditeur ne disparaîtront pas automatiquement.
La rupture vise le contrat conclu avec Cursor
Le contrat personnalisé comprend une fenêtre de résiliation limitée après un changement de contrôle. Le rachat de Cursor par SpaceX a déclenché cette possibilité, et l’échéance proposée correspond au préavis maximal prévu afin de maintenir temporairement l’accès aux modèles déjà utilisés.
La justification publiée repose sur les doutes d’OpenAI quant au respect futur de ses conditions d’utilisation par SpaceX, au regard de précédents impliquant d’autres entreprises d’Elon Musk. Il s’agit de la position contractuelle d’OpenAI, et non de la constatation d’une infraction future commise par Cursor ou par ses utilisateurs.
La séparation doit donc rester nette : OpenAI ne désactive ni l’application Cursor ni les modèles provenant d’autres fournisseurs. En revanche, Cursor perdra, si le calendrier est confirmé, le canal commercial lui permettant d’intégrer et de revendre les modèles fournis directement par OpenAI. Les prochaines générations de modèles OpenAI sont déjà exclues de cet accord.
Avant et après le 12 novembre : ce qui change réellement
Pendant la transition, les modèles OpenAI déjà utilisés par Cursor doivent rester accessibles par le circuit actuel. La date du 12 novembre demeure toutefois proposée : elle doit encore être confirmée entre les entreprises, et Cursor peut décider d’interrompre cet accès plus tôt.
- Avant la coupure : les modèles OpenAI actuellement couverts restent fournis à Cursor pendant la période de transition prévue.
- Après la coupure : la sélection de ces modèles via l’offre directement gérée par Cursor devrait disparaître.
- Modèles futurs : OpenAI ne prévoit pas de les livrer à Cursor dans le cadre de ce contrat.
- Éléments qui restent : l’éditeur, ses modèles propres et les offres d’autres fournisseurs, sous réserve de leurs accords respectifs.
Le compte rendu d’ITmedia confirme que Cursor doit rester utilisable avec Claude, Gemini et ses propres modèles ; il relaie également l’estimation de son dirigeant Michael Truell, pour qui les modèles OpenAI représentent environ 5 % du trafic utilisateur et font encore l’objet de discussions.
Cette proportion ne permet pas d’évaluer la dépendance d’une équipe particulière. Un projet qui impose un modèle OpenAI dans Chat ou Agent peut être directement touché, même si l’essentiel du trafic global de Cursor emprunte déjà d’autres routes. À l’inverse, un flux reposant sur Claude, Gemini ou un modèle propre à Cursor n’entre pas automatiquement dans le périmètre de la rupture.
Une clé API ne remplacera pas toutes les fonctions
Trois voies permettent de conserver certains usages des modèles OpenAI dans Cursor : connecter une clé API personnelle ou d’organisation, installer l’extension Codex pour IDE, ou passer par un fournisseur compatible comme Azure ou Amazon Bedrock. Elles établissent un accès séparé du contrat résilié, mais ne reproduisent pas nécessairement l’intégration native actuelle.
La documentation d’OpenAI consacrée à Cursor limite la clé personnelle aux requêtes compatibles de Chat et Agent dans l’application locale, avec une facturation distincte sur le compte API. Elle exclut Cursor Tab, le routage Auto, les agents Cloud ou Background, les automatisations, la CLI ainsi que l’API et le SDK de Cursor.
L’extension Codex constitue pour sa part une expérience indépendante à l’intérieur de l’éditeur. Elle ne remplace pas le modèle utilisé par Chat, Agent, Tab ou les services distants de Cursor. Une passerelle compatible peut également acheminer certaines requêtes, mais les modèles disponibles, les contrôles transmis et la prise en charge du format attendu varient selon le fournisseur.
La migration comporte ainsi deux problèmes différents. Conserver un modèle OpenAI pour une tâche locale peut passer par une clé, Codex ou une passerelle ; remplacer une fonction gérée par Cursor dépendra des modèles que l’éditeur décidera de router après la rupture.
Les réglages à préserver avant la transition
Une migration ciblée commence par l’inventaire des dépendances réelles, sans déplacer les projets qui utilisent déjà d’autres fournisseurs. L’objectif est d’identifier les tâches liées à un modèle OpenAI fourni par Cursor, puis de vérifier séparément les fonctions qui ne peuvent recevoir aucun identifiant externe.
- Recenser les modèles explicitement sélectionnés dans Chat et Agent, ainsi que les règles de routage partagées.
- Sauvegarder les instructions de projet, les règles, les réglages et les configurations nécessaires pour reproduire l’environnement.
- Choisir pour chaque flux concerné entre une clé API OpenAI, l’extension Codex, une passerelle compatible ou un autre modèle disponible dans Cursor.
- Tester la solution sur une tâche non critique, en vérifiant le contexte du dépôt, les appels d’outils et le mode de facturation.
- Traiter séparément Tab, Auto, les agents distants, les automatisations et la CLI, qu’une clé OpenAI ne prend pas directement en charge.
Dans une organisation, l’emploi d’une clé API déplace aussi la gestion des identifiants et des dépenses vers le compte OpenAI concerné. Les droits d’accès, les plafonds de consommation et la rotation des clés doivent donc être définis avant de remplacer une configuration partagée.
Trois éléments restent à préciser : la date contractuelle définitive, la liste exacte des modèles qui quitteront le sélecteur géré par Cursor et les solutions retenues pour chaque fonction intégrée. À ce stade, le scénario confirmé reste plus limité qu’un arrêt du service : Cursor continuera, mais les parcours dépendant de la fourniture directe d’OpenAI devront basculer avant la coupure effectivement convenue.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.