Core Web Vitals : ce qui compte vraiment pour le SEO
3 min de lecture
À retenir
- Le headless se justifie à partir de deux surfaces à alimenter, pas avant.
- Le coût du headless n’est pas la licence, c’est le développement du rendu.
- L’autonomie éditoriale se perd très vite si la prévisualisation n’est pas soignée.
- Un CMS traditionnel bien tenu reste excellent pour un site vitrine unique.
- Vérifiez l’export de vos contenus avant de vous engager : c’est votre porte de sortie.
« On va partir sur du headless. » La phrase est devenue un réflexe, souvent adoptée pour des raisons qui n’ont rien à voir avec le besoin réel : c’est moderne, c’est rapide, c’est ce que font les autres.
Le headless est un excellent choix dans certaines situations, et un surcoût pur dans d’autres. La ligne de partage est assez nette.
Ce que le headless change vraiment
Un CMS traditionnel fait deux choses : il stocke les contenus et il génère les pages. Un CMS headless ne fait que la première. Le rendu devient votre responsabilité.
Cela a trois conséquences directes.
Vous gagnez la liberté du rendu. Même contenu servi à un site, une application mobile, un écran en magasin, une newsletter. C’est le vrai argument, et le seul qui soit décisif.
Vous perdez le « prêt à l’emploi ». Ce qu’un thème apportait gratuitement — pages, menus, recherche, formulaires, prévisualisation — se développe.
Vous déplacez le coût. La licence baisse, le développement monte. Le total est presque toujours supérieur sur un projet mono-site.
La question qui tranche
Combien de surfaces distinctes devez-vous alimenter avec le même contenu ?
- Une seule — un site web : un CMS traditionnel bien tenu, ou un site statique généré, restera plus simple et moins cher.
- Deux ou plus — un site plus une application, ou plusieurs sites par pays, ou un site plus des écrans physiques : le headless devient rentable, et cette rentabilité augmente avec chaque surface.
Tout le reste — la performance, le SEO, la sécurité — dépend bien davantage de la qualité de réalisation que du type de CMS.
Le test de l’équipe éditoriale : demandez à la personne qui publiera réellement de modifier une page et de voir le résultat avant publication. Si cela demande plus de deux minutes ou l’intervention d’un développeur, l’autonomie éditoriale est perdue — et avec elle la principale raison d’avoir un CMS.
Les critères qui comptent réellement
1. La prévisualisation
C’est le point que les comparatifs ignorent et qui décide de l’adoption. Sans prévisualisation fidèle, l’équipe éditoriale publie à l’aveugle, corrige en production, et finit par redemander l’ancien outil.
À vérifier avant de choisir : la prévisualisation fonctionne-t-elle sur les contenus non publiés, sur les pages composées de plusieurs blocs, et sans intervention technique ?
2. La modélisation du contenu
Un bon modèle sépare le fond de la forme : un article a un titre, un chapô, un corps, un auteur, une image — pas « une colonne de gauche avec un encart bleu ».
C’est l’investissement le plus rentable du projet, et le plus difficile à corriger après coup. Une modélisation bâclée transforme le CMS en éditeur de mise en page, ce qui annule l’intérêt du découplage.
3. Le rendu servi au navigateur
Le contenu doit être présent dans le HTML reçu par le navigateur. Un site headless qui charge tout côté client est plus lent et moins bien indexé qu’un site traditionnel — c’est le principal reproche, justifié, fait aux premières générations de projets headless.
Génération statique ou rendu côté serveur : les deux fonctionnent, l’important est de ne pas laisser le navigateur assembler la page. Les seuils à tenir sont ceux décrits dans notre article sur les Core Web Vitals.
4. La réversibilité
Avant de vous engager, exportez vos contenus. Vraiment : faites l’export, ouvrez le fichier, vérifiez que les relations entre contenus et les fichiers joints y sont.
Un CMS dont l’export est partiel ou payant vous enferme, et cet enfermement se paiera au prochain changement.
5. Les droits et les circuits de validation
Qui peut publier quoi, qui valide, comment on programme une publication. Trivial sur un CMS traditionnel, souvent à développer ou à payer en option sur les offres headless.
Les trois familles d’offres
| Famille | Pour qui | Attention à |
|---|---|---|
| Service en ligne clé en main | Équipes sans compétence d’hébergement | Coût par utilisateur et par contenu, réversibilité |
| Solution auto-hébergée | Équipes disposant d’un profil technique | Charge de maintenance et de mises à jour |
| Contenu dans un dépôt de code | Sites de documentation, blogs techniques | Autonomie éditoriale quasi nulle pour un profil non technique |
La troisième famille mérite une mise en garde : elle est séduisante pour une équipe technique et généralement inutilisable pour une équipe marketing. Si les contenus doivent être publiés par des personnes qui n’écrivent pas de code, écartez-la.
Quand le CMS traditionnel reste le bon choix
Sans nostalgie ni provocation, c’est le cas de figure le plus fréquent :
- un seul site à alimenter ;
- une équipe éditoriale autonome qui publie souvent ;
- des besoins standards — pages, articles, formulaires, multilingue ;
- un budget qui doit aller au contenu plutôt qu’à l’infrastructure.
Dans cette configuration, un CMS traditionnel correctement configuré, allégé de ses extensions inutiles et hébergé sérieusement, donne un excellent résultat pour la moitié du budget. Le passer en headless plus tard reste possible si un second canal apparaît.
2Nombre de surfaces à partir duquel le headless devient rentable
≈ 50 %Part d’un projet de migration consacrée à restructurer les contenus
< 2 minTemps cible pour modifier une page et voir le résultat
Le meilleur CMS est celui dont votre équipe éditoriale se sert sans appeler personne. Toutes les autres qualités passent après celle-là.
Notre recommandation par défaut
Pour un site professionnel unique avec une équipe éditoriale non technique : un CMS éprouvé, bien configuré, avec un thème sur mesure et un hébergement sérieux.
Dès qu’une deuxième surface apparaît — une application mobile, un second site, des écrans — le headless devient le bon investissement, à condition de traiter en priorité la modélisation du contenu et la prévisualisation. Ce sont ces deux points, et non le choix de l’outil, qui feront la différence entre un système utilisé et un système contourné.
