Cursor a abandonné son CMS — votre entreprise devrait-elle l'imiter ?

Ce que Cursor a réellement fait

Cursor — l'entreprise qui se cache derrière l'éditeur de code IA populaire — gère l'un des sites web à la croissance la plus rapide dans le domaine du logiciel. En décembre 2025, l'équipe a retiré cursor.com de son CMS headless. Lee Robinson a reconstruit le site en code brut et en Markdown, et il documenté chaque numéro. La migration a duré trois jours. Elle a coûté $260,32 en jetons, répartis sur 344 requêtes d'agent. Le journal des commits indique 67 commits, 43 000 lignes ajoutées et 322 000 supprimées.

Observez attentivement la formulation. Cursor n'a pas développé un nouveau CMS. Il en a plutôt retiré un. Le contenu vit désormais dans des fichiers Markdown au sein d'un dépôt Git, modifié exactement comme les ingénieurs modifient du code. Il n'y a aucun portail d'édition, aucune interface de publication et aucun service de contenu distinct — seulement des fichiers, des pull requests et des déploiements.

Ce chiffre a fait le tour rapidement. Une entreprise a remplacé son infrastructure de contenu pour le prix d'un dîner d'équipe, et le débat qui a suivi a fait beaucoup de bruit. Comme on pouvait s'y attendre, la question du « faire-soi-même » ou de l'« achat » d'un CMS est revenue sur le bureau de tous les DSI. Avant donc que votre prochaine revue d'architecture ne présente le $260 comme une obligation, il est utile de faire la distinction entre ce qui s'est réellement passé et ce que cela implique pour vous.

Pourquoi cela a fonctionné pour Cursor

La migration a réussi parce que la situation de Cursor est vraiment inhabituelle. Premièrement, chaque personne qui touche au site web écrit du code. Robinson est explicite à ce sujet : chez Cursor, les designers sont des développeurs. Par conséquent, un flux de travail basé sur Git n'ajoute aucune friction, car c'est tout simplement la façon dont toute l'équipe travaille déjà.

Ensuite, le site a exactement une seule destination. Le contenu se rend sur cursor.com et nulle part ailleurs. Par conséquent, personne n'a besoin de diffuser la même description de produit vers une application mobile, un portail partenaire ou un outil de vente.

Troisièmement, Cursor expédie le contenu rarement et le régule légèrement. Il n'y a pas de chaînes d'approbation, pas d'audits de conformité, et pas de permissions basées sur les rôles au-delà de ce que GitHub propose déjà. Enfin, Robinson lui-même a tracé la ligne : “Pour de nombreuses équipes, le coût de l'abstraction du CMS en vaut la peine. Elles ont besoin d'un portail où les rédacteurs ou les responsables du marketing peuvent se connecter.”

Autrement dit, l'ingénieur qui a mené la migration vous a dit clairement qu'elle ne se généralise pas. Cette mise en garde compte bien plus que le chiffre marquant de 260 $.

La décision « développer ou acheter un CMS » change à l'échelle de l'entreprise

Avec 500 employés ou plus, presque aucune des conditions de Cursor n'est remplie. En fait, la décision de créer ou d'acheter un CMS porte rarement sur le CMS lui-même. Au lieu de cela, elle se résume à deux questions : qui édite votre contenu et combien d'endroits ce contenu doit-il atteindre.

D'abord, songez à qui publie. Les marketeurs, les chefs de produit, les réviseurs juridiques, les équipes régionales et les agences externes touchent tous à un site d'entreprise. La plupart d'entre eux n'écrivent pas de code, et, franchement, ils ne devraient pas avoir à le faire. Une pull request Git est une interface hostile pour un responsable marketing qui met à jour une page de campagne.

Ensuite, songez à où va le contenu. Le contenu d'entreprise n'a presque jamais une destination unique. La même grille tarifaire, la même clause juridique ou la même fiche technique apparaît sur le site web, dans l'application mobile, dans les outils d'aide à la vente et sur les microsites régionaux. Par conséquent, lorsqu'un fait change, il doit changer partout en même temps.

Enfin, considérons la langue. La propre liste de frustrations de Cursor incluait même des “ complications d’internationalisation ”. Pour une entreprise québécoise, une diffusion bilingue AN/FR n’est pas un « plus » – c’est une attente légale et de la clientèle. Les fichiers Markdown rendent la traduction structurée plus difficile, pas plus facile. Cette seule exigence écarte l’approche de Cursor pour la plupart des organisations que nous conseillons.

Les coûts cachés de développer son propre CMS

Le chiffre $260 est séduisant précisément parce qu'il masque les coûts récurrents. Développer son propre CMS — même un CMS Markdown allégé — revient en réalité à refaire le travail dont une plateforme commerciale se charge déjà. Comme l'équipe de Sanity argumenté dans une réponse détaillée, vous échappez rarement à ce travail ; vous le déplacez simplement.

Commençons par le contenu structuré. Lorsqu'un fait vit sur plusieurs pages, vous mettez à jour chaque fichier à la main ou vous construisez un système de gabarits qui puise dans une source canonique unique. Ce système de gabarits est, bien sûr, une fonction de CMS que vous maintenez désormais vous-même.

Ensuite, songez à la collaboration. Git résout les conflits de code de façon mécanique, car le code se compare ligne par ligne. Les conflits de contenu, en revanche, sont sémantiques, donc ils exigent un jugement humain. Les équipes finissent par bâtir des processus de révision élaborés qui deviennent des goulots d'étranglement — ou par coordonner les modifications sur Slack pour éviter les collisions.

Ensuite, il y a la requête. Une demande comme “ tous les articles mentionnant ce produit, publiés après septembre ” est triviale dans un CMS. Contre des fichiers Markdown plats, elle nécessite un moteur de requête que vous devriez écrire. Enfin, la gouvernance disparaît simplement : pas de piste d'audit, pas de permissions basées sur les rôles au-delà de l'accès au dépôt, et pas de coédition en temps réel. Pour une entreprise réglementée, ce n'est pas une lacune mineure, c'est un audit raté.

Un cadre « développer ou acheter un CMS » pour les DSI

Alors, comment un DSI devrait-il réellement trancher ? En pratique, la question « développer ou acheter un CMS » se résout nettement une fois que vous évaluez honnêtement votre organisation selon cinq critères.

1. Qui modifie le contenu ? Si chaque rédacteur écrit du code, un flux de travail basé sur le code est viable. Si des équipes marketing, juridiques ou régionales publient, il vous faut une véritable interface éditoriale.
2. Combien de canaux le consomment ? Un seul site web favorise la simplicité. Plusieurs applications, sites et outils favorisent un contenu structuré et piloté par API.
3. À quelle fréquence publiez-vous ? Des publications espacées et groupées tolèrent les flux de travail Git. Une publication quotidienne et sensible au temps, non.
4. Qu'exige la gouvernance ? Une gouvernance légère convient à une configuration sur mesure. Les pistes d'audit, les approbations et l'accès basé sur les rôles vous orientent vers une plateforme conçue pour cela.
5. Combien de langues servez-vous ? Une seule langue se gère dans des fichiers. Une livraison bilingue ou multilingue exige les flux de traduction qu'offre un CMS mature.

Si vos réponses se situent majoritairement dans la première moitié de chaque paire, une approche de type Cursor pourrait réellement convenir. Si elles se situent dans la seconde moitié — comme c'est le cas pour presque toutes les entreprises — alors remplacer votre CMS échange un coût connu contre une série de coûts cachés. Par conséquent, la réponse honnête à la question “créer ou acheter” un CMS est rarement “créer”. Bien plus souvent, il s'agit de “acheter quelque chose de mieux” ou de "adapter ce que vous possédez déjà".”

Ce que Cursor a bien fait — et qui vaut la peine d'être repris

Rejeter d'emblée l'histoire de Cursor serait une erreur. L'équipe avait raison sur un point bien réel : leur ancienne configuration était plus lourde que leurs besoins réels. Ils avaient dépensé 56 848 $ en coûts de CDN pour un site appuyé sur un CMS, et ils ont vu la publication de contenu ralentir. C'est un véritable problème — et bien des entreprises ont exactement le même. Elles ne l'ont simplement pas encore mesuré.

Alors volez la discipline, pas la tactique. Auditez votre CMS par rapport à ce que votre équipe utilise réellement. Par exemple, de nombreuses entreprises gèrent une DXP poids lourd simplement pour publier ce qui est en fait un site vitrine, payer pour des moteurs de personnalisation, des modules de flux de travail et des fonctionnalités que personne n'utilise. C'est un vrai gaspillage. Cependant, la solution est de tailler sur mesure, pas de supprimer.

C'est exactement là où un approche composable Il fait ses preuves. Plutôt qu'une plateforme monolithique — ou aucune plateforme du tout — vous choisissez une couche de contenu adaptée à vos éditeurs, à vos canaux et à votre gouvernance, et rien de plus. La leçon tirée de Cursor n'est pas “ le CMS est mort ”. C'est “ ne payez que pour l'abstraction dont vous avez réellement besoin ” — et cette nuance est au cœur de toute décision honnête entre construire et acheter un CMS.

Prenez la décision « développer ou acheter un CMS » en toute confiance

La plupart des décisions de plateforme tournent mal pour une seule raison : chaque conseiller a quelque chose à vendre. Le fournisseur de CMS défend le CMS. L'agence qui développe du logiciel sur mesure défend le logiciel sur mesure. Par conséquent, un conseil véritablement neutre est rare — et difficile à trouver.

Sengo est conçue exactement pour cette décision. Nous sommes un partenaire d'implémentation officiel de huit plateformes — Sitecore, Optimizely, Contentful, Storyblok, Kentico, Coveo, Netlify et ai12z — et nous développons aussi sur mesure lorsque c'est véritablement la bonne réponse. Parce que nous pouvons livrer l'une ou l'autre voie, nous n'avons aucun intérêt à pousser l'une plutôt que l'autre. Notre équipe détient deux prix Sitecore Technology MVP, et nous avons livré des plateformes d'entreprise pour le Cirque du Soleil, iA Groupe financier, le FTQ, la CCQ et LCI Éducation. De plus, nous travaillons entièrement en mode bilingue, en anglais et en français, depuis le Québec.

Lorsqu'un DSI nous demande s'il faut copier Cursor, nous appliquons le cadre de développement ou d'achat de framework CMS ci-dessus à l'organisation réelle — ses éditeurs, ses canaux, sa charge de conformité, ses langues — et nous donnons alors une réponse directe. Parfois, cette réponse est “ moderniser ”. Parfois, c'est “ conservez ce que vous avez ”. Ce n'est jamais “ quoi que ce soit qui nous rapporte le plus gros projet ”.”

Avant que votre prochaine revue d'architecture ne transforme un chiffre marquant de 260 $ en stratégie, obtenez une lecture neutre de votre propre pile technologique.