Migration headless CMS : le guide complet Sanity + Astro (2026)

Une migration headless CMS consiste à séparer le contenu de votre site (géré dans un CMS comme Sanity) de son affichage (codé avec un framework comme Astro), les deux communiquant par API. Vous gagnez un contrôle total sur le SEO technique, un back-office taillé pour votre équipe et une architecture que l'IA peut piloter.

Ce que vous ne gagnez pas automatiquement : de la vitesse. C'est le premier mythe que ce guide va déconstruire, chiffres à l'appui.

Chez l'agence web Gemeos, on construit des sites pour des startups et scale-ups depuis plusieurs années, sur Webflow, WordPress et désormais en headless. Ce guide rassemble tout ce qu'on sait sur le sujet : quand migrer, quand ne pas migrer, combien ça coûte, et comment le faire sans perdre une seule position Google.

Headless CMS : la définition en 30 secondes

Un CMS headless est un système de gestion de contenu sans « tête », c'est-à-dire sans couche d'affichage intégrée. Il stocke et structure le contenu, puis le distribue par API à n'importe quel front-end : un site, une app mobile, un agent IA, un écran en boutique.

À l'inverse, un CMS monolithique (WordPress classique, Webflow, Drupal, Wix) gère dans le même outil le contenu, le design, le code et l'hébergement.

Monolithique, headless, hybride : les trois architectures

Pourquoi on dit « découplé »

Dans un site headless, votre équipe marketing publie un article dans Sanity. Sanity envoie un signal (webhook), le site Astro récupère le contenu et régénère la page concernée. Le visiteur reçoit une page HTML statique, servie depuis le CDN le plus proche de lui.

Chaque brique peut évoluer indépendamment. Vous voulez refaire le design ? Le contenu ne bouge pas. Vous voulez changer d'hébergeur ? Le CMS ne le sait même pas.

Pourquoi 2026 est le bon moment pour migrer

Le headless existe depuis dix ans. Ce qui a changé, c'est que quatre évolutions récentes le rendent accessible et rentable pour une scale-up, pas seulement pour les grands groupes.

1. Astro a un avenir garanti

En janvier 2026, Cloudflare a racheté The Astro Technology Company. Le framework reste open source sous licence MIT, avec une gouvernance publique. Astro 6 est sorti en mars 2026 avec les Live Content Collections (contenu récupéré à la requête, sans rebuild) et une CSP intégrée.

Pour une entreprise qui choisit sa stack pour cinq ans, c'est un signal fort : Astro n'est plus un projet de passionnés, c'est l'infrastructure d'un acteur qui sert une part majeure du web.

2. Webflow a revu son modèle

En mai 2026, Webflow a fusionné ses plans CMS et Business en un plan Premium (25 $/mois en annuel, 20 000 items CMS, 40 collections) et lancé un plan Team pour les équipes en croissance, uniquement en annuel et sur devis.

Bonne nouvelle pour les petits sites : les limites d'items reculent. Mais pour une équipe de 8 à 15 personnes qui publie en plusieurs langues, la facture se joue désormais sur les sièges, la localisation et le plan Team. C'est exactement le moment où la question du headless se pose.

3. Les agents IA savent piloter un CMS

Depuis décembre 2025, le serveur MCP de Sanity est disponible pour tous. Concrètement, Claude Code, Cursor ou VS Code peuvent lire votre schéma de contenu, créer des documents, préparer des releases et même guider une migration depuis WordPress, Contentful, Strapi ou Drupal.

Un CMS dont la configuration est du code devient un CMS que l'IA peut faire évoluer. Un CMS configuré à la souris, beaucoup moins.

4. Le GEO récompense le contenu structuré

ChatGPT, Perplexity et Gemini citent les sources qu'ils comprennent le mieux : définitions claires, données structurées, FAQ, entités identifiables. Un CMS headless vous oblige à structurer votre contenu en champs plutôt qu'en blocs de texte libres. C'est un avantage direct pour être cité.

Le comparatif : Webflow vs WordPress vs Drupal vs Sanity + Astro

Aucune plateforme ne gagne sur tous les critères. Sanity + Astro gagne sur le contrôle, la flexibilité et l'évolutivité. Webflow gagne sur le time-to-market et l'autonomie visuelle. WordPress gagne sur l'écosystème. Drupal gagne sur les besoins institutionnels complexes.

Ce qu'il faut lire entre les lignes

Webflow reste un excellent choix jusqu'à un certain stade. Pour un site marketing de 20 à 200 pages, une petite équipe et un besoin de lancer vite, il est difficile à battre. Nous l'utilisons d'ailleurs sur une grande partie de nos projets. On l'a détaillé dans notre comparatif Webflow ou WordPress : quel CMS choisir.

WordPress a un écosystème inégalé, mais chaque plugin ajoute une dette. Au-delà d'un certain volume, la maintenance, la sécurité et la performance deviennent un poste à part entière.

Drupal est taillé pour les institutions : permissions très fines, contenus complexes, conformité. Il est souvent surdimensionné pour une scale-up. Voir notre comparatif Webflow vs Drupal.

Sanity + Astro devient pertinent quand le contenu devient un actif stratégique : plusieurs langues, plusieurs équipes, du SEO programmatique, des produits ou des données à synchroniser, ou une volonté de piloter le site avec l'IA.

Ce que le headless change vraiment en SEO

Le headless ne rend pas un site plus rapide par magie. Il vous donne le contrôle total de ce que Google et les LLMs reçoivent. La nuance est importante, et les données le montrent.

Le mythe du « headless = plus rapide »

Le rapport Core Web Vitals de HTTP Archive mesure la part de sites qui valident les trois indicateurs de Google (LCP, INP, CLS) sur de vrais utilisateurs Chrome. Les chiffres de 2025 et 2026 sont éclairants :

Deux enseignements :

1. Astro fait bien mieux que WordPress, mais pas mieux que Webflow en moyenne. Un site Astro mal construit (images non optimisées, scripts tiers en pagaille) peut être lent.
2. Les plateformes fermées ont de bons scores parce qu'elles limitent ce que vous pouvez faire. Moins de liberté, moins de risques. Le headless inverse la logique : liberté totale, donc la performance dépend de la qualité du build.

La vraie promesse du headless, c'est donc un plafond plus haut, pas un plancher plus haut. Avec Astro, un site bien construit envoie zéro JavaScript par défaut et atteint des scores Lighthouse proches de 100. Mais c'est un choix d'ingénierie, pas un acquis.

Le vrai gain : le contrôle du SEO technique

Voici ce qu'un site Sanity + Astro permet de faire nativement, sans contournement :

Le SEO programmatique devient accessible

C'est probablement le levier le plus sous-estimé. Le SEO programmatique consiste à générer des pages à grande échelle à partir de données structurées : une page par intégration, par ville, par cas d'usage, par comparatif.

Sur Webflow, c'est possible jusqu'aux limites du CMS (20 000 items sur le plan Premium). En headless, le modèle de contenu et les templates Astro permettent de générer des milliers de pages, chacune avec ses propres données structurées, son maillage et ses règles d'indexation.

Exemple type pour un SaaS : une page par intégration (« Connecter [votre outil] à HubSpot »), alimentée par un document Sanity qui contient les fonctionnalités, les cas d'usage, les captures et la FAQ propre à l'intégration.

Les trois risques SEO d'une migration headless

1. Le rendu côté client. Si le front charge le contenu en JavaScript après l'affichage, Google peut l'indexer mal ou tard. Avec Astro, le rendu est statique ou côté serveur par défaut : le risque disparaît, à condition de ne pas le réintroduire.
2. La perte des redirections. C'est la première cause de chute de trafic après une migration. Chaque ancienne URL doit rediriger en 301 vers sa nouvelle équivalente. Nous y revenons dans la checklist.
3. La preview qui fuit. Les environnements de prévisualisation mal configurés se retrouvent indexés. Il faut des règles noindex strictes et une authentification sur tout ce qui n'est pas la production.

Pour aller plus loin sur les fondamentaux, notre guide 9 étapes pour optimiser son site Webflow pour le SEO reste valable quelle que soit la stack.

GEO : être cité par ChatGPT, Perplexity et Gemini

Le GEO (Generative Engine Optimization) consiste à optimiser son contenu pour être repris et cité par les moteurs de réponse IA. Un CMS headless aide sur trois points : la structure, la cohérence et la distribution.

La structure : un modèle de contenu plutôt qu'un gros bloc de texte

Un LLM extrait mieux une information qui a un nom. Dans Sanity, une définition peut être un champ definition, une FAQ une liste de paires question / answer, un chiffre clé un objet stat avec sa valeur, sa source et sa date.

Résultat : ces éléments peuvent être rendus proprement en HTML sémantique, balisés en JSON-LD, et réutilisés partout sur le site avec la même formulation.

La cohérence : une seule source de vérité

Votre tarif, votre nombre de clients, la définition de votre produit : si ces informations existent à un seul endroit dans le CMS et sont référencées partout, elles restent cohérentes. Les LLMs pénalisent les sources contradictoires.

La distribution : servir les machines aussi bien que les humains

Avec Astro, il devient simple de générer en plus des pages HTML :

• un fichier llms.txt qui résume le site et pointe vers les pages clés
• des versions markdown de chaque page (par exemple /blog/mon-article.md), plus légères à lire pour un agent
• des flux JSON pour les partenaires ou les intégrations
• un balisage JSON-LD complet (Organization, Article, FAQPage, Product, BreadcrumbList)

Administrabilité : le CMS maison vraiment agile

C'est l'argument qui convainc le plus nos clients, bien avant la performance. Avec Sanity, le back-office n'est pas un outil générique auquel votre équipe s'adapte : c'est un outil construit autour de votre équipe.

Un Studio sur mesure

Sanity Studio, l'interface d'édition, est une application configurée en code. Cela permet de :

• Nommer les choses comme votre équipe les nomme. « Page intégration », « Témoignage client », « Offre », plutôt que « Collection 7 ».
• Guider la saisie. Aide contextuelle sous chaque champ, exemples, limites de caractères, champs obligatoires.
• Empêcher les erreurs. Règles de validation : une meta description de plus de 155 caractères, un article sans image de partage ou une page sans mot-clé ne peuvent pas être publiés.
• Organiser par métier. Une vue « Blog » pour le content manager, une vue « Produit » pour le PMM, une vue « Légal » pour le juridique.

La prévisualisation visuelle

Le reproche historique au headless : « on édite des formulaires sans voir le résultat ». C'est réglé. L'outil Presentation de Sanity affiche le site en direct à côté des champs. On clique sur un titre dans l'aperçu, le champ correspondant s'ouvre. On modifie, l'aperçu se met à jour.

Des workflows éditoriaux dignes de ce nom

Ce que le marketing fait seul, ce qui reste au dev

La frontière n'est pas figée. Avec le vibe coding (on y vient), une partie de la colonne de droite passe à gauche.

Design system : la vraie clé de l'agilité

On parle souvent du CMS quand on parle d'agilité. C'est une erreur : un Studio bien configuré permet de publier du contenu, mais c'est le design system qui permet de créer des pages. Sans lui, chaque nouvelle landing page redevient un projet de design et de développement. Avec lui, c'est un assemblage de blocs que le marketing fait seul, en respectant la marque.

Autrement dit, l'agilité d'un site headless se décide au moment du design, pas au moment du code. C'est pour ça qu'on traite le design system comme un livrable à part entière de la migration, pas comme une étape du build.

Ce que le design system change pour votre équipe

Ce qu'un bon design system contient

• Des fondations : les design tokens (couleurs, typographies, espacements, rayons, ombres), définis une fois et nommés par intention (« fond marque », « texte secondaire »).
• Des composants : boutons, cartes, tags, formulaires, avec leurs états et leurs variantes.
• Des blocs de page : hero, logos, features, témoignages, pricing, FAQ, CTA. Ce sont eux que le marketing manipule dans Sanity.
• Des règles d'usage : quel bloc pour quel objectif, combien de caractères par titre, quelles combinaisons éviter.
• Une source unique : les mêmes noms dans Figma, dans le code Astro et dans le Studio Sanity. Le designer, le développeur, le marketing et l'agent IA parlent de la même chose.

Exemple : les blocs interactifs de ce guide

Les huit blocs interactifs de ce guide (le schéma d'architecture, le comparatif filtrable, le graphique Core Web Vitals, la démo de page builder, la stack, le simulateur d'abonnements, le diagnostic et la frise de migration) ont été créés de toutes pièces avec Claude Cowork, en reprenant le design system de notre produit, l'app Gemeos.

Concrètement, l'agent a lu nos maquettes Figma (conteneurs, cartes, toggles, onglets, tags, KPI cards), en a extrait les tokens (couleurs, ombres, rayons, typographies), puis a codé chaque bloc uniquement à partir de ces fondations. Nous avons relu et ajusté le contenu, sans redessiner un seul bloc : c'est le design system qui a garanti la cohérence.

C'est exactement ce qui se passe sur un site headless bien conçu. Quand les fondations sont claires, un agent IA produit de nouveaux composants qui ont l'air d'avoir toujours fait partie du site. Sans design system, il aurait inventé un style par bloc.

Le page builder par blocs

Un site headless bien conçu donne au marketing la liberté de créer des pages, sans lui donner la possibilité de casser la marque. Le page builder à blocs contraints est la partie visible du design system.

Le principe : un bloc Sanity = un composant Astro. Chaque section du site (hero, grille de logos, témoignages, tableau de prix, FAQ, CTA) existe deux fois :

• dans Astro, sous forme de composant codé, qui respecte le design system
• dans Sanity, sous forme de bloc avec ses champs (titre, texte, image, variante)

Le marketing assemble une page en empilant des blocs dans Sanity. Astro affiche chaque bloc avec le composant correspondant. Une nouvelle landing page se monte en 20 minutes, sans ticket au dev.

Des tokens pour ne jamais sortir de la charte

Les design tokens sont les valeurs de base de votre identité : couleurs, typographies, espacements, rayons, ombres. Dans un site headless, ils sont définis une seule fois dans le code et utilisés partout.

Côté Sanity, on ne propose jamais un sélecteur de couleur libre. On propose des variantes nommées : « Fond clair », « Fond marque », « Fond sombre ». Le marketing choisit une intention, le design system applique la bonne valeur.

Les garde-fous qui évitent la dérive

C'est la différence avec un outil visuel libre : on ne demande pas au marketing d'avoir l'œil d'un designer. On lui donne un système qui produit toujours un bon résultat. Et plus le design system est riche en blocs et en variantes, plus la colonne « le marketing fait seul » s'allonge. C'est un sujet qui nous tient à cœur, on l'explique dans pourquoi l'image de marque compte plus que vous ne le pensez.

Vibe coding et agents IA sur un CMS headless

Le vibe coding désigne le fait de construire ou modifier un logiciel en décrivant ce qu'on veut en langage naturel à un agent IA, qui écrit le code. Sur un site headless, c'est un changement profond : le site devient un projet que l'équipe peut faire évoluer avec l'IA, sans attendre le sprint suivant.

Pourquoi le headless s'y prête mieux qu'un outil visuel

Dans Sanity + Astro, tout est du code ou des données structurées : le schéma de contenu, les composants, le design system, la configuration. Un agent IA peut donc tout lire, tout comprendre et proposer des modifications vérifiables.

Dans un outil visuel, l'état du site est enfermé dans une interface. L'IA peut aider, mais elle travaille à travers une API plus étroite.

Ce que permet le serveur MCP de Sanity

Le MCP (Model Context Protocol) est un standard qui permet à un agent IA d'utiliser des outils externes. Le serveur MCP de Sanity, compatible avec Claude Code, Cursor, VS Code, Claude Desktop, v0 et Lovable, expose plus de 40 outils :

Un workflow type : du besoin au déploiement

1. Le growth lead ouvre Claude Code : « Ajoute un bloc "Comparatif" avec un tableau à 3 colonnes et une ligne mise en avant. »
2. L'agent crée le schéma du bloc dans Sanity et le composant Astro, en réutilisant les tokens existants.
3. Il ouvre une pull request avec une preview du site.
4. Un dev relit en 10 minutes, valide, fusionne.
5. Le bloc est disponible dans le Studio pour toute l'équipe.

Les agents de contenu

Au-delà du code, l'IA travaille directement sur le contenu :

• traduire une page dans 4 langues en respectant un glossaire
• remplir les meta descriptions manquantes selon vos règles
• proposer des liens internes pertinents à partir des références existantes
• détecter les contenus obsolètes (chiffres datés, produits retirés)

Les limites à connaître

Le vibe coding ne supprime pas le besoin d'expertise. Il le déplace.

• La relecture humaine reste indispensable, sur le code comme sur le contenu.
• Les permissions comptent. Un agent doit travailler avec un jeton limité, sur un dataset de test avant la production.
• La qualité dépend du socle. Un agent qui travaille sur un design system propre produit du propre. Sur un socle désordonné, il amplifie le désordre. Les blocs interactifs de ce guide, générés à partir du design system de notre app, en sont un bon exemple.

C'est pour cela que l'architecture initiale compte autant : elle détermine ce que l'IA pourra faire correctement pendant des années.

Pourquoi Astro (et quand préférer Next.js)

Astro est un framework web conçu pour les sites orientés contenu : sites marketing, blogs, documentation, e-commerce éditorial. Son principe clé est l'architecture en îlots : la page est en HTML statique, et seuls les éléments interactifs (un formulaire, un calculateur) chargent du JavaScript.

Astro vs Next.js pour un site marketing

Quand choisir Next.js

Si votre site marketing et votre produit partagent beaucoup de composants, ou si le site comprend une vraie partie applicative (espace client, configurateur complexe), Next.js est un choix cohérent.

C'est le cas d'Allo, l'assistant téléphonique IA : leur site tourne sur Next.js avec Sanity comme CMS. Même logique headless, autre framework.

Pour un site dont la mission principale est de ranker, convaincre et convertir, Astro est notre choix par défaut.

Notre stack de référence

Voici l'architecture que nous recommandons pour une scale-up B2B qui migre en headless.

{cta}

Coûts et TCO : combien coûte vraiment une migration headless

Pendant longtemps, le headless coûtait plus cher : il fallait des semaines de développement pour modéliser le contenu, coder les composants et configurer le back-office. En 2026, ce n'est plus vrai. Avec les agents IA, le serveur MCP de Sanity et des composants Astro générés à partir du design system, le coût de construction d'un site headless est désormais comparable à celui d'un site Webflow. Et côté abonnements, le headless est souvent moins cher dès que l'équipe grandit.

Les quatre postes de coût

Exemple chiffré : une équipe de 10 personnes

Hypothèses : 2 personnes qui ont besoin d'un accès complet (design, admin), 8 éditeurs de contenu, un seul site. Tarifs annuels publics en septembre 2026, hors taxes.

Sur cet exemple, le headless revient environ 100 $ moins cher par mois, soit plus de 1 200 $ par an. L'écart se creuse avec chaque langue ajoutée et chaque personne qui rejoint l'équipe. Le simulateur ci-dessous refait le calcul avec votre situation.

Pour le détail côté Webflow, voir nos guides sur les abonnements et tarifs Webflow et le coût d'une refonte de site sur Webflow.

Faut-il passer en headless ? Le diagnostic

Le headless n'est pas une montée en gamme obligatoire. C'est une réponse à des problèmes précis. Si vous ne les avez pas, restez sur votre stack actuelle et investissez ailleurs.

Les 10 questions du diagnostic :

1. Votre site dépasse-t-il 300 pages ou 5 000 contenus CMS ?
2. Publiez-vous dans plus de deux langues ?
3. Plus de 5 personnes publient-elles régulièrement sur le site ?
4. Avez-vous besoin de workflows de validation (relecture, juridique, lancement groupé) ?
5. Votre contenu doit-il alimenter d'autres canaux (app, produit, partenaires, agents IA) ?
6. Voulez-vous faire du SEO programmatique à grande échelle ?
7. Rencontrez-vous des limites techniques sur votre plateforme actuelle ?
8. Avez-vous un développeur en interne ou une agence partenaire sur la durée ?
9. Voulez-vous faire évoluer le site avec des agents IA ?
10. Le site est-il un canal d'acquisition majeur pour votre croissance ?

Quand ne pas migrer

On le dit à nos clients aussi clairement qu'ici : ne migrez pas si

• votre site fait moins de 50 pages et évolue peu
• personne ne pourra maintenir le code sur la durée
• votre problème est le contenu ou la conversion, pas la plateforme
• vous devez relancer le site dans un délai très court, sans marge pour l'audit
• vous êtes early-stage et votre positionnement va encore changer

Dans ces cas, un site Webflow bien construit vous rendra plus de services. On a aussi écrit un guide sur le prix d'un site internet pour calibrer votre budget.

La migration headless en 7 étapes

Une migration headless réussie se joue avant la première ligne de code. Les trois premières étapes (audit, modélisation, plan de redirections) déterminent 80 % du résultat SEO.

Étape 1 : l'audit de l'existant

On inventorie tout ce qui a de la valeur avant de toucher à quoi que ce soit.

• crawl complet du site (toutes les URLs, statuts, balises, profondeur)
• export Search Console : pages qui reçoivent des clics et des impressions
• pages qui reçoivent des backlinks
• inventaire des types de contenu, des champs, des médias
• inventaire des scripts, intégrations et formulaires

Livrable : un fichier de référence qui liste chaque URL avec son trafic, ses backlinks et son sort (conserver, fusionner, supprimer).

Étape 2 : la modélisation du contenu

C'est l'étape la plus stratégique. On définit les types de documents (article, page, cas client, intégration, auteur), leurs champs et leurs relations.

La règle : modéliser le contenu selon ce qu'il est, pas selon comment il s'affiche. Un « témoignage » est un document réutilisable, pas un bloc de texte dans une page.

Livrable : le schéma Sanity documenté, validé par le marketing.

Étape 3 : le plan de redirections

Chaque URL de l'ancien site qui a du trafic ou des backlinks doit avoir une destination. Idéalement la même URL. Sinon, une redirection 301 vers la page la plus proche.

Livrable : la table de correspondance ancienne URL → nouvelle URL, importée dans Sanity.

Étape 4 : le design system, puis le build

C'est l'étape qui décide de l'agilité future de votre équipe. On commence par le design : les tokens, les composants et la bibliothèque de blocs, pensés à partir des pages dont le marketing aura besoin dans les 12 prochains mois, pas seulement de celles qui existent aujourd'hui. Ensuite seulement, on construit les composants Astro, le page builder et les templates, et on configure le Studio (vues, validations, preview).

Livrable : un design system documenté et un site fonctionnel sur un environnement de préproduction, non indexable.

Étape 5 : la migration du contenu

La migration se fait par script, jamais à la main au-delà de quelques dizaines de pages. Le script récupère l'ancien contenu (API, export CSV ou crawl), le transforme vers le nouveau modèle, télécharge les médias et crée les documents dans Sanity.

C'est ici que le serveur MCP de Sanity et un agent IA font gagner le plus de temps : écriture du script, transformation du rich text, contrôle de cohérence.

Livrable : 100 % du contenu dans Sanity, vérifié par échantillonnage.

Étape 6 : la QA SEO

On compare l'ancien et le nouveau site, URL par URL : balises title et meta, H1, canonicals, hreflang, données structurées, maillage interne, performance, redirections.

Livrable : un rapport de QA sans erreur bloquante.

Étape 7 : le lancement et le monitoring

Bascule du DNS, soumission des sitemaps, surveillance quotidienne pendant 2 semaines, puis hebdomadaire pendant 3 mois.

Livrable : un tableau de bord de suivi (pages indexées, erreurs 404, positions, trafic organique).

Combien de temps dure une migration ?

Ça dépend du scope. Deux sites de 200 pages peuvent demander des plannings très différents selon ce qu'on migre et ce qu'on refait. C'est pour ça qu'on ne donne jamais de durée avant l'audit : on la chiffre une fois le scope connu.

Le levier le plus sous-estimé : migrer par étapes. Lancer d'abord le blog ou une section en headless permet de valider l'approche vite, puis d'étendre au reste du site.

La checklist SEO de migration

Gardez cette checklist ouverte pendant tout le projet. Chaque point non coché est un risque de perte de trafic.

Ils ont migré : exemples et résultats

Les exemples ci-dessous montrent un point commun : la migration headless n'est pas un projet technique, c'est un projet d'autonomie pour les équipes marketing.

Amplitude : de WordPress à Sanity

Amplitude tournait sur un WordPress personnalisé depuis plus de dix ans. Seuls 3 ingénieurs pouvaient modifier le site, et l'équipe publiait 4 à 5 contenus par mois.

Après la migration vers Sanity, réalisée sans interruption de service sur des milliers de pages :

Gong : 400 pages sorties de WordPress

Gong, la plateforme de revenue intelligence, a migré plus de 400 pages de WordPress vers Sanity. Le moteur du projet : sortir le marketing de sa dépendance à l'équipe technique pour chaque mise à jour.

Calendly, Allo et la vague SaaS

Calendly fait partie des SaaS B2B qui ont choisi Sanity pour leur site. Allo, la startup française de téléphonie IA, s'appuie aussi sur Sanity, avec un front Next.js. Le schéma se répète : quand le site devient une machine d'acquisition, le contenu passe dans un CMS structuré.

Cloudflare, IKEA, Porsche : Astro en production

Côté framework, Astro est utilisé par Cloudflare (sites, documentation, blog), IKEA, Porsche ou OpenAI. Webflow lui-même a choisi Astro pour Webflow Cloud. Autrement dit : même les plateformes no-code misent sur Astro quand il faut du code.

Vous hésitez encore sur la plateforme de départ ? Nos comparatifs Webflow vs HubSpot CMS et les meilleures alternatives à Webflow donnent une vue d'ensemble.

FAQ

Conclusion

La migration headless CMS n'est pas une mode technique. C'est le choix de faire de votre site un actif que vos équipes, et demain vos agents IA, peuvent faire évoluer sans friction, à condition de lui donner un design system solide.

Chez Gemeos, on accompagne des startups et scale-ups sur Webflow, WordPress et en headless avec Sanity + Astro. Notre règle est simple : choisir la stack qui sert la croissance du client, pas celle qui est à la mode. Si vous vous posez la question pour votre site, on commence toujours par l'audit.