CMS headless — qui pourra changer quoi, dans quelle langue, et à quel prix

Dans une offre, le mot headless a l’air d’une décision technique que l’on peut laisser au prestataire.

Il ne l’est pas. C’est une décision sur qui, dans votre entreprise, pourra changer quoi — et, sur ce marché, dans quelle langue — puis sur ce que coûtera chaque modification que personne n’avait prévue. Un CMS headless n’est pas un meilleur système de gestion de contenu : c’est un autre partage du travail entre la rédaction et le développeur, et toute l’addition découle de ce déplacement.

Ce texte tranche la question de savoir à qui cet échange profite. Il s’adresse à la personne qui signe le contrat et qui vivra avec ses conséquences pendant plusieurs années.

Ce qu’est un CMS headless : le contenu d’un côté, l’apparence de l’autre

Un système de gestion de contenu classique garde au même endroit le contenu et le gabarit d’affichage. Vous changez un texte dans l’interface, le système le place dans le gabarit et sert une page finie. C’est ainsi que fonctionne WordPress, et la plus grande partie de ce que vous connaissez.

Un CMS headless ne garde que le contenu et le sert par une interface de programmation — sous forme de données, sans aucune apparence attachée. L’apparence est un programme distinct, qui récupère ces données et les met en page. Les deux graphies circulent — « headless CMS » à l’anglaise, « CMS headless » à la française — et désignent exactement la même chose.

Une analogie suffit pour décider : un CMS classique, c’est un magasin dont la vitrine et l’entrepôt occupent le même bâtiment. Le headless, c’est un entrepôt séparé, qui ignore à quoi ressemble la vitrine — et c’est à la fois tout son avantage et tout son coût.

Ce qui en découle immédiatement :

• Le même contenu peut alimenter plusieurs endroits — un site, une application, un écran en salle d’exposition, un catalogue envoyé à un partenaire — puisque personne n’a inscrit dedans à quoi il devait ressembler.
• Un rédacteur ne peut pas casser la mise en page, faute d’y avoir accès. Il remplit des champs, pas un éditeur libre.
• Et l’inverse est vrai : un rédacteur ne peut pas changer la mise en page, même quand il le faudrait vraiment. C’est une tâche de développeur.

CMS headless et « static CMS » : deux choses différentes qui voyagent ensemble

Ces deux notions se confondent en permanence, parce qu’elles apparaissent ensemble et ne désignent pas la même chose.

Le CMS headless est un entrepôt : il détient le contenu et le sert à la demande. Le générateur de site statique (vous le rencontrerez sous le nom de static site generator, SSG, parfois « static CMS ») est une usine : il prend le contenu dans l’entrepôt et en fabrique des fichiers HTML finis, avant que quiconque n’ouvre la page.

On peut avoir l’un sans l’autre : un headless qui assemble la page à chaque visite, ou un générateur statique qui lit le contenu dans des fichiers d’un dépôt, sans aucune interface d’administration. Ensemble, en revanche, ils forment le montage vendu pendant des années sous le nom de JAMstack — d’où la confusion.

Pour vous, la différence tient en une question : combien de minutes s’écoulent entre l’enregistrement d’une modification et le moment où un visiteur la voit. Avec une usine, le site doit être reconstruit ; sur un site important, cela se compte en minutes, pas en secondes. Et sur un site en trois langues, ce n’est pas une page qui est reconstruite, mais trois — nous y revenons plus bas, parce que c’est exactement ce qui abîme le travail de la rédaction.

Ce qui change réellement pour la personne qui publie

C’est la section qui ne figure dans aucune offre, et c’est elle qui décide si, dans deux ans, ce système vous conviendra encore.

Ce qui devient plus facile. Le contenu s’écrit dans des champs — titre, chapeau, prix, photo — de sorte qu’il ne peut être ni incomplet ni destructeur pour la mise en page. La même description de produit arrive partout où elle est nécessaire, sans copier-coller. Et les versions linguistiques cessent d’être trois sites parallèles pour devenir trois valeurs d’un même champ.

Ce qui devient plus difficile. Il n’y a pas de glisser-déposer. Il n’y a pas les vingt mille extensions par lesquelles, sous WordPress, on ajoute une fonction sans développeur. Un nouveau type de section — pas un nouveau texte, une nouvelle façon de présenter le contenu — est une tâche de développeur : elle entre dans une file d’attente, pas dans l’interface d’administration.

Trois langues : une fiche, ou trois fiches ?

Sur ce marché, la question ne se pose presque jamais au singulier. Un site d’entreprise existe ici en deux ou trois langues, et la façon dont le système modélise les traductions décide de ce que sera, au quotidien, le travail de la personne qui les tient à jour. C’est le prolongement direct de la question du titre : qui pourra changer quoi, et maintenant dans quelle langue.

Deux modèles existent, et ils ne se ressemblent pas.

Une fiche, des champs par langue. L’article, la page ou la fiche produit est un seul objet ; chaque champ y porte une valeur par langue, et l’on bascule d’une langue à l’autre dans le même écran. C’est le modèle de la plupart des headless CMS modernes. Ce que cela donne : la structure est commune, donc une section ajoutée quelque part existe d’emblée dans les trois versions ; il est immédiatement visible qu’une traduction manque, puisque le champ est vide ; et rien ne peut diverger silencieusement.

Une fiche par langue. Chaque version est un document autonome, avec son identifiant, son adresse et son historique, relié aux autres par une correspondance — c’est le fonctionnement habituel d’un monolithe équipé d’une extension de traduction. Ce que cela donne : chaque version vit sa vie, ce qui est une liberté quand la page destinée au marché alémanique doit dire autre chose que la française, et un piège quand personne ne remarque que la version allemande a deux modifications de retard.

Les conséquences sur les droits d’accès sont concrètes, et elles vont souvent à rebours de l’intuition. Avec une fiche par langue, confier une seule version à un traducteur externe est simple, parce que ce sont des documents distincts, que l’on ouvre ou non. Avec une fiche unique à plusieurs langues, c’est précisément là que ça coince : ouvrir la fiche pour qu’une personne y corrige l’allemand, c’est souvent lui ouvrir aussi le français et l’anglais. Certains systèmes savent restreindre les droits à une langue, d’autres non, et cela ne se lit dans aucune plaquette.

D’où deux questions à poser au prestataire, avant de signer, qui révèlent le modèle plus sûrement que n’importe quelle fiche technique :

• Quand j’ajoute un paragraphe dans la version française, que devient la version allemande : elle reste telle quelle, elle affiche le texte français, ou elle se retrouve incomplète ?
• Puis-je donner à un traducteur externe un accès limité à une seule langue, sans lui ouvrir les autres ?

Il faut savoir aussi ce que le système fait quand une traduction manque. Trois comportements sont possibles : afficher la langue principale à la place, masquer complètement la page dans cette langue, ou servir une page à moitié vide. Les trois sont défendables, aucun n’est un réglage par défaut universel, et c’est une décision de votre côté — pas une découverte à faire en ligne.

Enfin, une remarque de budget, parce que la question arrive toujours ensuite. Dans notre calculateur du coût d’un site web, une deuxième version linguistique représente +1 750 CHF, et ce montant couvre la mise en place technique, pas la rédaction : la traduction professionnelle de toutes les pages coûte à peu près autant une seconde fois. Autrement dit, la partie que l’architecture fait baisser n’est pas la plus grosse. Le headless supprime la duplication de structure ; il ne supprime pas le travail sur les mots, et aucun système n’y parviendra.

Le piège de l’aperçu, ou le plus grand choc après WordPress

Sous WordPress, un rédacteur écrit et voit le rendu. En headless, par défaut, il ne voit rien : l’interface d’administration ne détient que des données, et l’apparence vit dans un programme séparé.

Dans un headless mal mis en œuvre, cela ressemble à ceci : le rédacteur clique sur « Enregistrer », puis attend la reconstruction du site pour savoir si le titre ne s’est pas désolidarisé de la photo. Quelques dizaines de secondes sur un petit site, quelques minutes sur un grand. Trois corrections dans un même paragraphe, ce sont trois cycles de ce genre. Pour une équipe marketing habituée à l’aperçu instantané, c’est un changement que personne n’avait annoncé et qui mange des heures chaque semaine — et il se multiplie par le nombre de langues, puisque chaque version se relit séparément.

L’aperçu instantané est possible en headless, mais il faut le construire. Concrètement, cela suppose un mode brouillon côté interface publique, qui récupère la version non enregistrée directement depuis l’administration et l’affiche en direct ; dans l’univers Next.js, c’est le rôle du mode draft. C’est un travail d’ingénierie à part entière, pas un interrupteur — et s’il ne figure pas dans le devis, il ne figure pas dans le projet.

La question à poser au prestataire, avant de signer : à quoi ressemble l’aperçu d’une modification non enregistrée, combien de secondes séparent le clic sur « enregistrer » du résultat visible, et cela vaut-il pour chaque langue ? « Il faut rafraîchir après la reconstruction » est une réponse qui coûte du temps à la rédaction tous les jours.

WordPress ou headless : quand le monolithe suffit

Disons-le franchement : pour la plupart des sites d’entreprise, WordPress suffit, et le headless est une dépense sans retour.

L’échelle du monolithe est d’ailleurs difficile à surestimer. Selon W3Techs, 69,1 % des sites tournent sur un système de gestion de contenu identifiable, et WordPress à lui seul représente 40,7 % de tous les sites et 58,9 % du marché des CMS (chiffres vérifiés à la source le 9 septembre 2026). Ce n’est pas un argument en faveur de WordPress : c’est une information sur la facilité avec laquelle vous trouverez un prestataire, et sur celle avec laquelle vous en changerez.

Ce que cette statistique ne dit pas. Les outils qui mesurent les technologies d’un site détectent ce qui apparaît dans le code envoyé au navigateur. Or le headless cache le backend par définition : de l’extérieur, on voit le cadriciel d’affichage, tandis que le système qui sert le contenu reste invisible. La part de marché du headless ne peut donc pas être mesurée comme l’est celle de WordPress — et tout chiffre que vous rencontrerez à ce sujet vient d’un sondage, pas d’une mesure.

Le plus cité est celui-ci : 73 % des personnes interrogées utilisent déjà une architecture headless, et parmi celles qui ne l’utilisent pas, près de 98 % prévoient de l’envisager dans l’année. Avant de le rapporter à votre cas, il vaut la peine de savoir qui a été interrogé. L’étude a été menée par Censuswide pour le compte de WP Engine en juillet 2024 : 1 015 répondants — directeurs techniques, directeurs marketing et décideurs informatiques — dans des entreprises réalisant en moyenne environ 800 millions de dollars de chiffre d’affaires annuel, aux États-Unis, au Royaume-Uni et en Australie. Ce montant reste en dollars, non converti, parce qu’il décrit la taille d’entreprises américaines, britanniques et australiennes : le passer en francs donnerait l’impression fausse qu’il s’agit d’une échelle suisse.

Autrement dit : ce n’est pas une phrase sur le marché suisse, ni sur des entreprises de votre taille ; l’étude a été commandée par un fournisseur qui vend de l’hébergement pour headless ; et « nous utilisons le headless » est une déclaration du répondant, pas un état vérifié. Le chiffre est vrai et inutile pour votre décision — il parle de groupes dont le chiffre d’affaires se compte en centaines de millions de dollars et qui ont des équipes techniques salariées. Nous le citons parce que vous le rencontrerez dans des offres, en guise d’argument « tout le monde fait déjà comme ça ».

Quatre situations dans lesquelles le headless commence à être rentable :

1. Le même contenu part vers plus d’un endroit — le site, plus une application, plus un écran en point de vente, plus un catalogue pour un partenaire. Avec un seul canal, vous payez une souplesse dont personne ne se servira.
2. Vous publiez en deux ou trois langues et les versions doivent rester alignées — mêmes sections, mêmes champs, mêmes gabarits, avec pour seule différence les mots. Un monolithe y parvient au prix d’une extension et d’une discipline ; un headless le fait parce que c’est sa structure même.
3. Vous construisez de toute façon l’interface publique en React ou en Next.js — parce que l’application exige des interactions qu’un gabarit ne porte pas. Le headless n’ajoute alors pas une compétence nouvelle : il referme celle que vous avez déjà.
4. Des exigences de sécurité ou de performance qu’un monolithe à extensions ne porte pas — aucune administration accessible publiquement, aucune couche d’extensions comme surface d’attaque, un contenu servi sous forme de fichiers prêts.

Trois situations dans lesquelles il ne l’est pas :

1. Un seul canal, une seule langue, et rien qui annonce le contraire.
2. Une rédaction sans appui technique — si le marketing ajoute aujourd’hui lui-même des sections sur le site, il cessera de le faire ; et si la version allemande est tenue par un traducteur externe, vérifiez d’abord que le système sait lui ouvrir cette langue-là seulement.
3. Un budget sans ligne d’exploitation — deux systèmes au lieu d’un, ce sont deux cycles de mise à jour et deux endroits où quelque chose peut tomber.

Si ce que vous choisissez n’est pas une architecture mais un outil précis, c’est une autre décision, et nous la traitons dans notre comparaison des plateformes ; le niveau conceptuel des systèmes de gestion de contenu — ce qu’est un CMS et qui, dans l’entreprise, doit pouvoir changer quoi — est déplié dans notre texte sur les systèmes CMS. Pour une boutique en ligne, la même décision se présente autrement : le catalogue, le panier et le paiement pèsent davantage que le contenu, et le calcul change en conséquence.

Une voie intermédiaire : WordPress utilisé en headless

Il existe un chemin entre les deux, et il vaut la peine d’en connaître l’existence : c’est souvent la solution la moins chère pour une entreprise qui possède déjà un WordPress chargé d’années de contenu.

WordPress reste l’interface d’administration et l’entrepôt de contenu, mais cesse de dessiner la page : l’apparence est reprise par une interface publique distincte, qui récupère le contenu par une interface de programmation. La rédaction travaille là où elle travaillait, tout l’historique des publications reste en place, et vous gagnez en rapidité et en liberté du côté de l’apparence.

Ce que vous y gagnez : un coût de migration de contenu nul, une équipe qui n’apprend pas une nouvelle interface, et une amélioration réelle du temps de chargement, l’affichage cessant de traîner la couche du thème et des extensions.

Ce que vous y perdez : la plupart des extensions, puisqu’elles se greffent sur une apparence qui n’existe plus — formulaires, galeries, mécanismes de référencement sont à reconstruire côté interface publique. Et dans un site multilingue, l’extension de traduction fait partie du lot : la correspondance entre les versions reste dans WordPress, mais l’affichage de la bonne langue à la bonne adresse redevient un travail d’ingénierie. Le problème de l’aperçu revient tel qu’il est décrit plus haut. Enfin, il reste deux systèmes à entretenir au lieu d’un.

Quand cela a du sens : vous avez beaucoup de contenu et une rédaction attachée à son interface, et le problème est uniquement la performance et l’apparence. Quand cela n’en a pas : les extensions assurent chez vous la moitié des fonctions du site — démonter WordPress en deux coûte alors plus cher que de reconstruire.

Deux modèles de déploiement, et non un classement d’outils

Les noms que vous entendrez — Contentful, Sanity, Strapi, Payload — se répartissent en deux modèles, et c’est ce partage-là qui change votre addition, pas celui qui a la plus jolie interface de programmation.

Le choix d’un produit précis à l’intérieur d’un modèle est une autre conversation et un autre texte. Ici, il suffit de savoir quel modèle vous achetez : c’est lui qui décide si, dans trois ans, vous discutez d’une hausse d’abonnement ou cherchez quelqu’un pour mettre un serveur à jour.

Ce que le headless exige de l’entreprise avant de donner quoi que ce soit

Il vous faut un appui technique continu — et pas « quelqu’un qui connaît WordPress », mais une personne qui travaille en TypeScript et en React. Chaque changement d’apparence et chaque nouveau type de section est un travail dans le code.

Cela ne veut pas dire qu’il faut embaucher. Cela veut dire que cette ligne doit avoir un propriétaire : votre propre développeur, une agence sous contrat de suivi, ou un prestataire avec un délai de réaction inscrit au contrat. Le montage qui ne fonctionne jamais est toujours le même : un système construit une fois par quelqu’un qui a ensuite disparu. Le headless tient alors jusqu’à la première modification impossible à faire depuis l’interface, puis devient une chose à laquelle tout le monde a peur de toucher.

La question à se poser avant de décider n’est donc pas « avons-nous un développeur », mais « qui entretiendra cela dans deux ans, et combien cela coûte-t-il par mois ». S’il existe une réponse, le headless est jouable.

Deux systèmes au lieu d’un, cela signifie deux cycles de mise à jour, deux points de panne et deux choses à tester après chaque changement important. Il arrive aussi que l’administration et l’interface publique doivent faire l’objet de deux déploiements distincts — le cas précis que nous avons rencontré avec Payload et le mécanisme de pré-rendu de Next.js est décrit dans notre texte sur Next.js et React. La conséquence, pour l’organisation, est simple : ce sont deux choses à livrer, pas une.

Vous fuyez une dépendance pour entrer dans une autre

Le headless se vend parfois avec la formule « vous vous libérez de WordPress ». Il vaut la peine de savoir par quoi cette dépendance est remplacée.

Dans un monolithe, vous dépendez d’un outil — mais cet outil, la moitié du marché le connaît, si bien que vous changez de prestataire en une semaine. En headless, vous dépendez de compétences : une interface publique écrite en Next.js, avec son propre routage, son propre modèle de données et son intégration à une administration particulière, n’ira pas au « premier prestataire venu ». Elle ira à un développeur React de niveau intermédiaire ou confirmé, et il y en a moins, et ils coûtent davantage.

Ce n’est pas un argument contre le headless. C’est une question à poser avant de signer, et non le jour où l’agence relève son tarif : qui, en dehors de vous, est capable d’entretenir ce que vous construisez, et que recevons-nous en cas de séparation — le dépôt de code, la documentation, les accès à l’infrastructure ?

L’addition : où cela coûte plus, et où cela coûte moins

Nous ne donnons pas ici de montant pour une réalisation en headless, parce que nous ne connaissons pas d’étude qui compare les deux approches sur les mêmes projets. Ce qui peut être montré honnêtement, c’est le mécanisme, et l’écart tel qu’il apparaît dans notre propre tarif.

Le mécanisme. Dans un monolithe, changer l’apparence d’une section est parfois un travail d’interface, parfois une petite retouche de gabarit. En headless, la même modification touche généralement deux endroits : la structure de données dans l’administration, et le composant d’affichage qui présente cette structure — et il faut ensuite toucher aux deux ensemble, faute de quoi des versions désaccordées n’affichent rien. C’est pourquoi ce n’est pas une question de prix horaire, mais de nombre d’heures, et pourquoi il est si important, en headless, de savoir combien de types de sections vous recevez au départ.

L’écart dans notre tarif. Nos prix sont publics, alors autant s’en servir comme repère : dans le calculateur, l’option WordPress ajoute +1 250 CHF à la base, tandis que l’option headless (Payload) ajoute +3 000 CHF. C’est un écart de mise en place, pas le coût de l’architecture sur trois ans — l’entretien, les modifications d’apparence et la compétence à garder sous la main se trouvent ailleurs, et ce sont eux qui pèsent le plus lourd.

Les taux, ensuite, sont ceux du marché pour un développeur. Un devis d’agence et un devis d’indépendant pour le même cahier des charges chiffrent rarement le même périmètre, même lorsqu’ils nomment la même tâche : l’écart décrit ce qui est inclus, pas le même travail facturé autrement.

Là où le headless coûte moins cher. Un canal supplémentaire pour un contenu qui existe déjà, puisqu’il n’y a rien à réécrire. Les extensions que vous n’achetez pas. Les incidents de sécurité que vous n’avez pas, faute d’administration accessible publiquement et de couche d’extensions.

Là où il coûte plus cher. La réalisation. Chaque changement d’apparence. Et le maintien de la compétence, y compris pendant les six mois où rien ne change.

Ce que vous n’achetez pas avec un CMS headless

Vous n’achetez pas de la vitesse, vous en achetez la possibilité. Le headless n’affiche rien de lui-même ; c’est l’interface publique qui décide si la page arrive prête au navigateur ou si elle se compose encore sur place. On peut construire sur headless un site plus lent que WordPress.

Vous n’achetez pas de la visibilité dans Google. Une interface publique qui récupère le contenu seulement dans le navigateur montrera une page vide au robot — le mécanisme est déplié dans notre comparaison entre Next.js et React. Le headless ne tranche cela dans aucun sens.

Vous n’achetez pas non plus le référencement de vos versions linguistiques. Les liens qui déclarent à un moteur qu’une page française et une page allemande sont la même page dans deux langues sont produits par l’interface publique, à partir des données du CMS ; le système fournit la matière, il ne fournit pas la déclaration. Si votre devis ne mentionne rien à ce sujet, c’est un poste à ajouter avant la signature, pas après la mise en ligne.

Vous n’achetez pas l’indépendance vis-à-vis du prestataire — vous changez seulement ce dont vous dépendez.

Et vous n’achetez pas la raison pour laquelle quelqu’un viendrait sur votre site. L’architecture tranche la manière dont le contenu parvient au lecteur ; elle ne tranche pas s’il vaut la peine d’aller le chercher. Si la décision sur le système est prise avant que cette question soit réglée, elle est prise trop tôt — et la réponse se trouve dans la stratégie du site, pas dans une offre technologique.

D’où viennent ces chiffres

• Part de WordPress et des systèmes de gestion de contenu — W3Techs, vérifié à la source le 9 septembre 2026 : 69,1 % des sites sur un CMS identifié, WordPress 40,7 % de tous les sites et 58,9 % du marché des CMS.
• 73 % d’entreprises utilisant le headless et 98 % prévoyant de l’évaluer — étude Censuswide commandée par WP Engine, juillet 2024, 1 015 répondants (directeurs techniques, directeurs marketing et décideurs informatiques) dans des entreprises au chiffre d’affaires moyen d’environ 800 millions de dollars, aux États-Unis, au Royaume-Uni et en Australie ; vérifié à la source le 11 septembre 2026. C’est un sondage auprès de grands groupes, commandé par un fournisseur : ni une mesure de marché, ni une phrase sur les entreprises suisses. Le montant reste en dollars, tel qu’il est publié.
• Pourquoi il n’existe pas de mesure de la part du headless — les outils de détection de technologies ne voient que le code envoyé au navigateur, et le headless cache le backend. C’est une limite de la méthode, pas un trou dans les données.
• Le mode brouillon dans l’interface publique — documentation de Next.js, vérifiée à la source le 11 septembre 2026.
• Nos montants en francs — options publiées de notre calculateur du coût d’un site web : CMS WordPress +1 250 CHF, CMS headless (Payload) +3 000 CHF, deuxième version linguistique +1 750 CHF. Ce sont nos tarifs de départ, hors taxes, pas des prix de marché.
• Écart de prix entre une agence et un indépendant — donné volontairement comme mécanisme et non comme chiffre : nous ne connaissons pas, pour ce marché, d’étude que nous défendrions.
• Comparaison du coût entre headless et monolithe sur les mêmes projets — nous ne connaissons pas d’étude de ce genre, et c’est pourquoi aucun multiplicateur ni aucune fourchette ne figure ici.