Headless CMS
Vos équipes gardent leur interface, le site change de moteur
Un CMS headless sépare la gestion du contenu de son affichage. Ceux qui écrivent ne changent pas d’outil ; les pages, elles, sont générées à l’avance et servies instantanément.
- L’interface d’administration que vos équipes connaissent déjà
- Des pages générées à l’avance, servies sans calcul
- La partie publique n’expose plus le CMS
- Le contenu reste réutilisable ailleurs qu’au format page
Le principe
Deux métiers dans un seul logiciel
Ce qu’un CMS classique fait en même temps
Un CMS traditionnel range votre contenu et fabrique la page au moment où le visiteur la demande. Les deux dans le même logiciel, sur le même serveur, avec les mêmes extensions. C’est simple, et c’est ce qui explique le succès de WordPress.
C’est aussi ce qui crée trois problèmes le jour où le site prend de l’importance : chaque visite coûte du calcul, la partie publique expose l’administration et ses extensions, et le contenu n’est réutilisable que sous forme de pages web.
Découpler, sans changer d’outil d’écriture
Une approche headless — littéralement « sans tête » — coupe le CMS en deux. Il garde la gestion du contenu et l’interface d’administration ; il cesse de fabriquer les pages. Celles-ci sont produites à l’avance par un autre outil, qui lit le contenu par une interface de programmation.
Le point important est ce qui ne change pas : ceux qui écrivent gardent l’écran qu’ils connaissent. Une refonte technique qui oblige la personne chargée du contenu à réapprendre son métier échoue à l’usage, quelle que soit sa qualité par ailleurs.
WordPress fait très bien la tête coupée
C’est la réponse la plus pragmatique et celle que nous employons le plus souvent. Gatsby, par exemple, se branche facilement sur WordPress, dont il récupère alors la gestion de contenu et l’interface d’administration. Astro sait faire de même.
Vous conservez donc un outil d’édition que tout le monde connaît, que n’importe quel prestataire saura reprendre, et dont la documentation existe en français — tout en obtenant un site public qui n’a plus rien de WordPress.
Ce que ça change concrètement
La vitesse : plus rien n’est calculé au moment de la visite. La sécurité : la partie publique n’expose ni base de données, ni extensions, ni page de connexion ; l’administration peut même n’être joignable que depuis vos locaux. La réutilisation : un contenu accessible par API alimente aussi bien un site qu’une application mobile ou un écran en boutique.
Ce que ça coûte
Deux systèmes au lieu d’un, et un délai de publication : une modification doit être régénérée pour apparaître. Cela se traite — régénération ciblée plutôt que du site entier — mais c’est un point à décider en début de projet, pas à découvrir en cours de route.
Sur un site de vingt pages mis à jour trois fois par an, la complexité ajoutée ne se justifie pas. Nous vous le dirons.
La mise en place
Ce que nous construisons
-
WordPress en mode headless
L’interface d’administration que vos équipes connaissent, exposée par API. Vous gardez l’outil, vous changez ce qu’il y a devant.
-
La vitrine générée
Astro sur la plupart des projets, Gatsby quand l’écosystème React le justifie. Dans les deux cas, des pages produites avant la visite.
-
La chaîne de publication
Ce qui se passe entre « je publie » et « c’est en ligne » : régénération ciblée des pages concernées, plutôt que du site entier.
-
Administration à l’abri
La partie publique n’expose plus le CMS. L’administration peut n’être joignable que depuis vos locaux, ce qui retire l’essentiel de la surface d’attaque.
-
Contenu réutilisable
Une fois accessible par API, le même contenu alimente un site, une application ou un écran — sans être ressaisi.
-
Indexable
Les pages existent avant la visite et s’indexent normalement — l’inverse d’une application front, dont le référencement est souvent impossible.
Questions fréquentes
Headless CMS : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Devons-nous abandonner WordPress ?
Non, et c’est souvent le contraire : WordPress fait très bien le rôle de CMS headless. Il garde la gestion du contenu et son interface d’administration, un autre outil fabrique les pages publiques. Vos équipes ne changent pas d’écran, et vous restez sur un outil que n’importe quel prestataire sait reprendre.
Une modification est-elle visible immédiatement ?
Pas instantanément : les pages étant générées à l’avance, une modification doit être régénérée. C’est le compromis de l’approche, et il se règle en début de projet — régénération ciblée des pages concernées plutôt que du site entier, ce qui ramène le délai à quelques instants.
Est-ce plus sûr qu’un CMS classique ?
Sur la partie publique, nettement : elle n’expose ni base de données, ni extensions, ni page de connexion, et n’exécute rien à la demande. Le CMS reste à protéger, mais il peut n’être joignable que depuis vos locaux — ce qui retire l’essentiel de la surface d’attaque.
Est-ce pour tous les sites ?
Non. Sur un site de vingt pages mis à jour trois fois par an, la complexité ajoutée ne rapporte rien : un WordPress bien hébergé fait le travail pour moins cher. Le headless prend son sens quand le trafic est là, quand la sécurité est un sujet, ou quand le contenu doit servir ailleurs que sur le site.
Employez-vous un CMS headless dédié ?
Notre réponse la plus fréquente est WordPress en mode headless, parce qu’elle ne demande à personne de réapprendre son outil. Si votre contexte impose autre chose — une équipe déjà formée, un besoin éditorial particulier — parlons-en : c’est un choix qui se discute au cas par cas.
Qui écrit vos contenus, et dans quel outil ?
C’est la question qui décide. Si la réponse est « WordPress, et ça leur va », vous pouvez le garder — et changer tout le reste.