CMS : qui, dans l’entreprise, doit pouvoir modifier quoi sur le site

La question « quel CMS choisir ? » arrive généralement trop tôt. Une autre la précède, et presque personne n’y répond consciemment : qui, dans votre entreprise, doit pouvoir modifier quoi sur le site, et à quelle fréquence. La réponse élimine la plupart des options avant que quiconque n’ouvre un comparatif de fonctions.

L’enjeu est d’ailleurs plus modeste que ne le laisse entendre la profession. D’après W3Techs, au 21 septembre 2026, 31,5 % des sites ne reposent sur aucun des systèmes de gestion de contenu que ce service surveille — autrement dit, près d’un site sur trois sur internet n’a pas de CMS, et cela ne gêne personne. Les 68,5 % restants en utilisent un, et ce marché est très concentré.

Ce texte sert de porte d’entrée : ce qu’est un tel système, quelles sont ses trois familles et comment choisir entre elles. Il ne compare pas de produits — c’est une décision distincte, qui se prend après celle-ci.

Ce qu’est un CMS — et ce qu’il ne règle pas

Un CMS, ou système de gestion de contenu, est la couche qui sépare le contenu de la manière de l’afficher. En pratique, cela signifie une seule chose : pour changer un prix sur le site, quelqu’un dans l’entreprise se connecte à une interface d’administration et modifie un chiffre dans un champ, au lieu de demander au prestataire de modifier un fichier.

Cela paraît banal tant qu’on n’a pas vu ce que coûte l’absence de cette couche. Un site sans CMS n’est pas techniquement moins bon — il est parfois plus rapide et plus sûr. Mais c’est un site que vous ne modifiez pas vous-mêmes, ce qui veut dire qu’au bout d’un an il décrit une offre que vous n’avez plus, parce que chaque correction demandait un courriel, un devis et de l’attente. Vous ne cessez pas de le mettre à jour parce que vous ne le voulez pas. Vous cessez parce que, chaque fois, cela prend du temps.

Il vaut la peine de nommer d’emblée trois choses qu’un CMS ne fait pas, parce qu’elles sont la source la plus fréquente de déception après la mise en service :

• Il ne fera pas de vous un concepteur. Pouvoir déplacer des blocs n’est pas la même chose que savoir composer une page qui vend. L’interface donne de la liberté, pas une compétence — et avec trop de liberté, au bout de six mois, le site ressemble à un assemblage de morceaux.
• Il n’écrira pas les contenus. La raison la plus fréquente pour laquelle un projet s’enlise n’est pas la technologie, mais l’absence de textes et de photos.
• Il ne remplacera pas la décision de qui est responsable de quoi. Le système n’imposera des rôles qu’une fois que vous les aurez définis vous-mêmes.

Trois familles de systèmes, pas vingt produits

Les comparatifs de CMS commencent le plus souvent par une liste de vingt noms, et c’est un mauvais départ : les noms changent tous les deux ans, les familles non. Il y a trois familles, et elles diffèrent sur un seul point : où vit le contenu, et qui en est responsable.

Le tableau range des catégories, mais la différence est physique et gagne à être vue : il s’agit de savoir où se trouve le contenu, où se trouve l’apparence, et qui en détient la clé.

La concentration du marché est d’ailleurs plus forte que ne le laisserait croire le nombre d’options disponibles. W3Techs, au 21 septembre 2026 : WordPress — un système de la famille classique — fait fonctionner 40,2 % de l’ensemble des sites et détient 58,8 % du marché des CMS. Les suivants du classement en sont à 5,4 %, 4,2 %, 2,4 % et 1,1 % — ensemble, moins d’un quart de ce que pèse le premier.

C’est le seul nom de produit d’un tiers qui apparaisse dans ce texte, et il apparaît parce qu’il porte un chiffre ; le reste du choix se fait au niveau des familles, pas des marques. La conclusion pratique de ce chiffre est la suivante : la famille classique n’est ni un choix risqué ni un choix de niche, quoi que suggère l’offre d’un prestataire intéressé par autre chose. Si quelqu’un vous la déconseille sans donner une raison qui tienne à votre situation, demandez-lui laquelle.

Le choix entre les familles ne se tranche pourtant pas sur les parts de marché, mais sur ce qui suit.

Qui modifie quoi, et à quelle fréquence : deux axes plutôt qu’une liste de fonctions

C’est la seule question que vous devez trancher vous-mêmes, parce que sa réponse ne figure dans aucune grille tarifaire. Elle a deux axes : la fréquence à laquelle le contenu change, et ce que coûte une erreur dans ce qui sera publié.

Rarement, risque faible. Les horaires d’ouverture, le numéro de téléphone, l’adresse. Un changement par trimestre, et le pire qui puisse arriver en cas d’erreur, c’est une coquille. La solution la plus simple que vous avez sous la main suffit ici — et c’est ici qu’on surpaie le plus souvent, en achetant un système pour des besoins qui n’existent pas.

Souvent, risque faible. Le blog, les actualités, les photos de réalisations. Ce qui compte, c’est la vitesse de publication, et qu’une seule personne s’en sorte seule, sans demander à qui que ce soit. Des droits sophistiqués sont inutiles ici — ils ralentissent.

Rarement, risque élevé. Les tarifs, les données du registre du commerce, les conditions générales, les informations dont vous répondez juridiquement. Elles changent quelques fois par an, mais une erreur peut coûter cher. Ce qu’il vous faut ici, c’est un aperçu avant publication et un historique des versions — c’est-à-dire la possibilité de vérifier qui a modifié tel chiffre, et quand. Vous n’avez pas besoin d’un éditeur sophistiqué.

Souvent, par plusieurs personnes, risque élevé. Les offres, les pages d’atterrissage de campagne, les pages produits modifiées par une équipe de plusieurs personnes. C’est le seul quadrant où le système se rentabilise réellement — parce que c’est seulement ici que vous avez besoin de rôles et de droits, de versions et d’un environnement de test, et seulement ici que leur absence coûte plus qu’une licence.

Mode d’emploi : notez ce qui a changé sur votre site au cours de l’année écoulée, qui l’a changé, et ce qui se serait passé si la modification avait été fausse. Ne planifiez pas sur la base de ce que vous « allez faire » : regardez ce que vous avez fait. La plupart des entreprises se retrouvent dans les trois premiers quadrants et achètent pour le quatrième.

Quand vous n’avez pas besoin d’un CMS

Revenons au chiffre du début, parce qu’il a une chute : si 31,5 % des sites se passent d’un système surveillé, cela vaut la peine de vérifier que vous ne faites pas partie de ce groupe — avant de payer pour une interface dans laquelle personne n’entrera.

Trois situations dans lesquelles un CMS est un coût sans contrepartie :

Le site compte cinq pages et change une fois par an. Un site vitrine avec l’offre, le contact et quelques réalisations. Une interface d’administration n’y accélère rien, puisqu’il n’y a rien à accélérer — et elle ajoute une couche qu’il faut mettre à jour et sécuriser. Un changement par an coûte moins cher sous forme de mandat que sous forme d’abonnement assorti de maintenance.

Le prestataire fait tout de toute façon. Si, malgré l’interface, chaque modification part par courriel parce que c’est plus rapide, vous payez pour une possibilité dont vous ne vous servez pas. Ce n’est pas un argument pour ne rien changer — c’est un argument pour changer le processus, ou pour cesser de payer le système.

Le contenu vit ailleurs. Les entreprises dont la présence repose sur une fiche d’établissement Google, sur les réseaux sociaux ou sur un annuaire professionnel mettent à jour ces endroits-là et traitent le site comme une carte de visite. C’est souvent une décision consciente et juste.

Le critère qui tranche n’a rien à voir avec la taille de l’entreprise : au cours des douze derniers mois, quelqu’un chez vous a-t-il voulu modifier quelque chose sur le site sans le faire, parce que c’était trop compliqué ? Si oui, un système vous servira. Si personne ne l’a voulu, ce n’est pas l’absence de système qui pose problème.

Il faut au passage distinguer deux choses faciles à confondre : l’absence de CMS n’est pas la même chose qu’un site négligé. La première est parfois un choix. Le second est un état, et on le reconnaît aux symptômes décrits plus bas.

Quatre rôles qui apparaîtront de toute façon — autant les nommer

La matrice ci-dessus dit que, dans un quadrant, il vous faut des rôles et des droits. Il vaut la peine de dire ce que cela signifie concrètement, car « rôles et droits » sonne comme une ligne de grille tarifaire, alors que c’est une décision d’organisation que vous prendrez de toute façon — consciemment ou par défaut.

Dans les entreprises où plus d’une personne touche au site, on en trouve généralement quatre :

• Quelqu’un qui rédige et publie le contenu. Cette personne doit pouvoir modifier les textes et les images des pages existantes. Elle ne devrait pas pouvoir modifier la mise en page ni les styles globaux — non parce qu’elle n’en serait pas capable, mais parce qu’un seul changement de couleur de bouton au mauvais endroit agit sur tout le site.
• Quelqu’un qui valide. Pour un contenu dont vous répondez juridiquement ou financièrement, rédiger et publier devraient être deux actes de deux personnes. C’est toute la différence entre « quelqu’un s’est trompé » et « quelqu’un s’est trompé et personne ne l’a vu ».
• Quelqu’un qui répond de l’apparence. Les modèles, les styles globaux, les nouveaux types de pages. En général le prestataire, du moins au début.
• Quelqu’un qui a accès à tout. Une personne de votre côté — pas seulement du côté du prestataire. C’est le rôle dont l’absence ne fait mal qu’au moment de la séparation.

La règle qui met de l’ordre dans tout cela sans lire la documentation : par défaut, accordez le minimum de droits suffisant pour accomplir la tâche. Vous aurez toujours le temps de les élargir ; retirer un accès après que quelqu’un a déjà déplacé quelque chose devient une conversation, et non plus un réglage.

Sur un site en plusieurs langues, ce découpage prend une dimension de plus : qui a le droit de publier dans quelle langue. La personne qui rédige en français n’est pas forcément celle qui doit valider la version allemande, et un système qui ne sait pas faire la différence oblige soit à tout confier à tout le monde, soit à tout faire passer par une seule personne.

Un site, plusieurs langues : là où s’arrêtent les systèmes simples

C’est la raison la plus fréquente pour laquelle une entreprise dépasse un système qui lui a suffi pendant trois ans — et la moins souvent anticipée au moment du devis. Ici, elle se pose plus tôt qu’ailleurs, parce qu’un site d’entreprise en une seule langue est l’exception : le français cohabite avec l’allemand, souvent avec l’anglais.

Tant que le site est monolingue, la structure du contenu va de soi : une page est une page. Dès la deuxième langue apparaît une question à laquelle les systèmes simples répondent mal : la version dans une autre langue est-elle un site distinct, ou une autre version du même contenu ? Si c’est un site distinct, vous avez au bout d’un an deux sites qui divergent sur le fond, et personne ne sait lequel est à jour. Si c’est le même contenu dans une autre version, le système doit le comprendre — et c’est une propriété qu’on n’ajoute pas avec une extension sans en payer le prix.

Concrètement, trois modèles existent sur le marché, et ils coûtent à peu près le même prix à l’achat, pas du tout le même à l’usage :

• La traduction comme champ supplémentaire du même document. Chaque page connaît ses traductions ; une correction de structure se fait une fois ; il se voit tout de suite qu’une langue est en retard.
• Un arbre de pages dupliqué par langue. Les pages sont reliées entre elles, mais chaque version vit sa vie ; les écarts s’installent sans bruit.
• Un site par langue. Deux ou trois projets à maintenir en parallèle, avec autant de jeux de réglages, d’extensions et de mises à jour.

Nous en parlons d’expérience, puisque ce site fonctionne en quatre versions linguistiques, et c’est ce qui a le plus influencé son architecture — davantage que l’apparence, et davantage que la performance.

En pratique : combien de langues, lesquelles, et si elles doivent rester à jour en parallèle, est une question à poser avant de choisir un système, pas après. Ajouter cela plus tard relève en général de la reconstruction, pas de l’extension. Ce que les versions linguistiques changent ensuite côté serveur — taille des sauvegardes, durée de construction, cache — est traité dans notre texte sur la plateforme et du côté de l’hébergement.

CMS gratuit : qu’est-ce qui est vraiment gratuit ?

Les systèmes classiques les plus répandus sont gratuits, et ce n’est pas un piège. Le cœur du logiciel ne coûte effectivement rien, et il ne cache aucune licence payante.

Le coût est ailleurs, et il est prévisible dans sa nature, pas dans son montant : l’hébergement sur lequel il tourne · les extensions pour ce que le cœur ne fait pas · le temps de la personne qui le met à jour. Le premier poste est connu d’avance. Le troisième est souvent sous-estimé. Le deuxième peut dépasser les deux autres réunis — nous le décomposons, chiffres des éditeurs à l’appui, dans le texte sur la couche d’édition visuelle au-dessus de WordPress.

La distinction à retenir, parce que la confondre coûte le plus cher : « gratuit », dans la famille classique, veut dire « sans licence », pas « sans coût ». Dans la famille fermée, c’est l’inverse — la facture est unique et visible, et ce qu’on ne voit pas, c’est le prix du renouvellement et la possibilité de repartir.

Comment savoir que votre système ne vous convient pas

Pas parce qu’il est ancien ou démodé. À quatre symptômes, chacun vérifiable cette semaine.

Personne dans l’entreprise n’entre dans l’interface. Si depuis six mois personne n’a rien modifié seul, le système ne fonctionne pas, quelle que soit la qualité de sa description. Regardez la date de la dernière modification.

Chaque changement passe par la même personne. Si tout transite par un seul individu — chez vous ou chez le prestataire —, ce n’est pas un système de gestion de contenu, c’est un goulot d’étranglement doté d’une interface d’administration.

Vous avez peur des mises à jour. Repousser les mises à jour parce que « la dernière fois, quelque chose s’est décalé » est un symptôme, pas de la prudence. Le sujet a son propre texte, parce que c’est la raison la plus fréquente pour laquelle les sites d’entreprise cessent d’être sûrs.

Publier demande du courage. S’il n’y a ni aperçu ni moyen d’annuler une modification, chaque retouche des tarifs est un petit stress — et elle a donc lieu moins souvent qu’elle ne le devrait. C’est le même diagnostic que dans le quadrant « rarement, risque élevé » plus haut.

Trois de ces quatre symptômes relèvent de l’organisation, pas de la technologie, et changer de système ne les fera pas disparaître. Mieux vaut l’établir avant le devis qu’après.

Ce qui se passe quand vous changez de système

Un changement de CMS est vendu comme une opération technique, et c’est la source de la plupart des déceptions, parce que la partie qui fait mal n’est pas technique.

Le contenu se transporte, pas la structure. Les textes, les images et les pages se transfèrent presque toujours. Ce qu’il faut reconstruire, c’est la façon dont le contenu est organisé — les types de pages, leurs champs, ce qui est relié à quoi. L’ancien système imposait une structure, le nouveau en imposera une autre, et la correspondance entre les deux est un travail humain, pas un export. Avec plusieurs langues, cette correspondance se fait une fois par langue, et c’est souvent là que les liens entre versions se perdent.

Les adresses se transportent — si quelqu’un s’en occupe. C’est le seul poste de cette liste qui, négligé, coûte durablement. Changer de système change généralement les adresses des pages, et une adresse qui cesse de répondre emporte avec elle tout ce que le moteur de recherche savait d’elle. Une redirection adresse par adresse est bon marché pendant la migration, et chère un an plus tard.

Les habitudes ne se transportent pas. La personne qui publiait dans l’ancienne interface publie plus lentement dans la nouvelle pendant les premières semaines — c’est normal, et non le signe d’un mauvais choix. Intégrez-le au calendrier plutôt que d’avoir à expliquer ensuite pourquoi « ça devait pourtant aller plus vite ».

L’ordre qui fait gagner le plus : établissez d’abord la structure du contenu, choisissez ensuite le système, migrez enfin. L’ordre inverse — le système d’abord, puis l’adaptation du contenu — est ce qui produit des sites à vingt types de pages dont on en utilise quatre.

Ce que coûte une telle opération et comment la mener sans perdre de positions, nous le détaillons à propos de la décision de refonte. Il vaut aussi la peine de la conclure par des tests avant la mise en ligne — c’est lors d’une migration que le plus de choses cassent en même temps.

Quand séparer le contenu de l’apparence a du sens, et quand c’est excessif

La famille headless — le contenu à un endroit, l’apparence construite à part — est parfois vendue comme l’étape suivante naturelle. Elle ne l’est pas. C’est un choix qui déplace la charge de la licence vers les personnes.

Nous l’écrivons de première main, parce que ce site repose sur un tel système — en l’occurrence Payload CMS. Il donne une liberté qu’aucune des autres familles n’offre : la structure du contenu est conçue pour ce que nous publions réellement, et non pour ce qu’avait prévu l’auteur d’un thème. Cela coûte exactement ce que cela laisse entendre : il faut dans l’équipe quelqu’un qui programme. Pas « quelqu’un de technique » — un développeur. Si vous n’en avez pas et n’envisagez pas d’en avoir, le headless sera chez vous un chemin de croix, pas une économie.

Quand cela a-t-il du sens, alors ? Quand le contenu doit aller à plus d’un endroit, quand la structure sort de l’ordinaire, et quand quelqu’un est là pour l’entretenir. Nous le développons dans le texte consacré à l’architecture headless, et vous pouvez situer votre cas entre elle et la famille classique grâce à un court quiz.