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

Ce que Cursor a réellement fait

Cursor — the company behind the popular AI code editor — runs one of the fastest-growing websites in software. In December 2025, the team moved cursor.com off its headless CMS. Lee Robinson rebuilt the site on raw code and Markdown, and he documented every number. The migration took three days. It cost $260.32 in tokens across 344 agent requests. The commit log shows 67 commits, 43,000 lines added, and 322,000 removed.

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.

That headline number traveled fast. A company replaced its content infrastructure for the price of a team dinner, and the debate that followed was loud. Predictably, the build vs buy CMS question landed back on every CIO’s desk. So before your next architecture review treats $260 as a mandate, it helps to separate what actually happened from what it means for you.

Pourquoi cela a fonctionné pour Cursor

The migration succeeded because Cursor’s situation is genuinely unusual. First, every person who touches the website writes code. Robinson is explicit about it — at Cursor, the designers are developers. Therefore, a Git-based workflow adds zero friction, because it is simply how the whole team already works.

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.

Third, Cursor ships content infrequently and governs it lightly. There are no approval chains, no compliance audits, and no role-based permissions beyond what GitHub already provides. Finally, Robinson himself drew the line: “For many teams, the cost of the CMS abstraction is worth it. They need a portal where writers or marketers can log in.”

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

At 500 or more employees, almost none of Cursor’s conditions hold. In fact, the build vs buy CMS decision is rarely about the CMS itself. Instead, it comes down to two questions: who edits your content, and how many places that content has to reach.

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.

Finally, consider language. Cursor’s own list of frustrations even included “internationalization complications.” For a Quebec enterprise, bilingual EN/FR delivery is not a nice-to-have — it is a legal and customer expectation. Markdown files make structured translation harder, not easier. That single requirement rules the Cursor approach out for most organizations we advise.

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

The $260 figure is seductive precisely because it hides the recurring costs. Building your own CMS — even a lightweight Markdown one — quietly recreates the work a commercial platform already handles. As the team at Sanity argued in a detailed response, you rarely escape that work; you just relocate it.

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.

Then there is querying. A request like “every article mentioning this product, published after September” is trivial in a CMS. Against flat Markdown files, it needs a query engine you would have to write. Finally, governance simply disappears: no audit trail, no role-based permissions beyond repository access, and no real-time co-editing. For a regulated enterprise, that is not a minor gap — it is a failed audit.

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.

If your answers land mostly in the first half of each pair, a Cursor-style move may genuinely fit. If they land in the second half — as they do for nearly every enterprise — then ripping out your CMS trades one known cost for a stack of hidden ones. As a result, the honest build vs buy CMS answer is rarely “build.” Far more often, it is “buy something better” or “right-size what you already own.”

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é.

So steal the discipline, not the tactic. Audit your CMS against what your team genuinely uses. For example, many enterprises run a heavyweight DXP just to publish what is effectively a brochure site, paying for personalization engines, workflow modules, and features nobody touches. That is real waste. However, the fix is right-sizing, not removal.

This is exactly where a composable approach earns its keep. Rather than one monolithic platform — or no platform at all — you choose a content layer matched to your editors, your channels, and your governance, and nothing more. The lesson from Cursor is not “the CMS is dead.” It is “pay only for the abstraction you actually need” — and that nuance is the heart of any honest build vs buy CMS decision.

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.

When a CIO asks us whether to copy Cursor, we run the build vs buy CMS framework above against the real organization — its editors, its channels, its compliance load, its languages — and then we give a straight answer. Sometimes that answer is “modernize.” Sometimes it is “keep what you have.” It is never “whatever earns us the bigger project.”

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.