CMS ou site sur mesure : comment choisir la bonne solution ?

Quand on crée un site web, le choix de la technologie arrive souvent très tôt.

« On part sur WordPress ? »

« Est-ce qu'il faut un CMS ? »

« Pourquoi ne pas faire le site sur mesure ? »

Ces questions sont légitimes. Elles sont pourtant rarement les premières auxquelles il faudrait répondre.

Un CMS peut être une excellente solution. Un site développé sur mesure peut également être parfaitement adapté. Aucun des deux n'est intrinsèquement meilleur que l'autre.

Le bon choix dépend surtout de ce que le site doit faire, de la manière dont il sera utilisé et de ce qu'il devra devenir dans quelques années.

Chez LB Studio, je développe notamment des sites avec Next.js, mais cela ne signifie pas que je considère le développement sur mesure comme la réponse à tous les projets. Le choix technique doit rester au service du projet, et non l'inverse.

CMS et site sur mesure : de quoi parle-t-on exactement ?

Avant de comparer les deux approches, il faut clarifier les termes.

Qu'est-ce qu'un CMS ?

Un CMS, ou Content Management System, est un système de gestion de contenu.

Son objectif principal est de permettre à une ou plusieurs personnes de créer, modifier et organiser du contenu sans avoir à modifier directement le code du site.

Un CMS fournit généralement une interface d'administration permettant par exemple de :

• créer une page ;
• publier un article ;
• modifier un texte ;
• ajouter une image ;
• gérer des catégories ;
• administrer des utilisateurs ;
• parfois gérer des produits, des commandes ou d'autres données métier.

WordPress est l'exemple le plus connu, mais il existe de nombreux autres CMS.

Certains sont généralistes, d'autres spécialisés dans le commerce électronique, la documentation, l'édition ou encore la gestion de contenus structurés.

Qu'est-ce qu'un site sur mesure ?

Un site sur mesure est développé spécifiquement pour répondre aux besoins du projet.

Cela ne signifie pas nécessairement que tout est recréé de zéro.

On peut utiliser un framework, des bibliothèques, des services externes ou des composants existants. Le principe est simplement que l'architecture et le comportement du site sont conçus en fonction du besoin, plutôt que de partir d'un système généraliste auquel on ajoute ensuite des extensions.

Chez LB Studio, Next.js est notamment utilisé dans cette approche.

Le code n'est alors pas une fin en soi. Il sert à construire précisément ce dont le projet a besoin.

---

Le premier critère : qui devra faire vivre le site ?

C'est probablement l'une des questions les plus importantes, et elle est parfois oubliée.

Un site ne s'arrête pas au jour de sa mise en ligne.

Il faudra peut-être modifier une offre, ajouter une réalisation, publier des articles, changer une photo, mettre à jour des tarifs ou créer de nouvelles pages.

Un CMS donne de l'autonomie

Si une entreprise publie plusieurs contenus chaque semaine et souhaite que plusieurs personnes puissent intervenir sur le site, disposer d'une interface d'administration peut être un avantage considérable.

Le responsable communication peut publier un article sans attendre le développeur.

Le commercial peut mettre à jour une offre.

L'équipe peut gérer son catalogue.

Dans ce contexte, ne pas proposer de CMS simplement parce qu'un site statique serait plus léger n'aurait pas beaucoup de sens.

Le coût humain de chaque modification finirait par devenir plus important que le bénéfice technique.

Mais l'autonomie a un coût

Un CMS ne supprime pas la complexité. Il la déplace en partie vers le système d'administration.

Il faut maintenir le CMS, ses extensions, ses dépendances et parfois son infrastructure.

Il faut également gérer les comptes utilisateurs, les permissions, les sauvegardes et la sécurité.

Et surtout, il faut apprendre à utiliser l'outil.

Pour une entreprise qui publie trois articles par an et modifie rarement ses pages, disposer d'une interface d'administration très complète n'est pas forcément un avantage.

Il faut donc se poser une question simple :

À quelle fréquence le contenu changera-t-il, et qui effectuera ces modifications ?

---

Un site sans CMS n'est pas forcément un site difficile à gérer

L'absence de CMS est parfois perçue comme un inconvénient automatique.

Ce n'est pas aussi simple.

Pour un petit site vitrine composé de quelques pages relativement stables, il peut être plus pertinent de gérer le contenu directement dans le projet.

Le site peut alors être pré-rendu et servir des pages très légères, avec peu de dépendances.

Mais il faut être transparent sur la conséquence :

si le client souhaite modifier lui-même le contenu, il faut prévoir un autre mécanisme.

Cela peut être :

• une intervention ponctuelle du développeur ;
• un CMS ;
• un système d'administration sur mesure ;
• un CMS headless ;
• une source de contenu externe ;
• ou une combinaison de plusieurs solutions.

Le choix doit donc être fait avant le développement, et non découvert lorsque le client demande quelques mois plus tard :

« Je peux modifier le texte de cette page moi-même ? »

---

Le vrai sujet : où vivent les contenus ?

Techniquement, un CMS répond à une question assez simple :

Où stocke-t-on le contenu, et comment le modifie-t-on ?

Dans un site classique avec CMS, on peut avoir une architecture de ce type :

Utilisateur
    ↓
Site web
    ↓
CMS
    ↓
Base de données

Le CMS gère les contenus et les stocke généralement dans une base de données.

Avec une approche différente, on peut avoir :

Utilisateur
    ↓
Site Next.js
    ↓
Contenus prévus dans le projet

Ou encore :

Utilisateur
    ↓
Site Next.js
    ↓
API / CMS headless
    ↓
Base de données

Cette dernière approche est particulièrement intéressante : Next.js et un CMS ne sont pas nécessairement opposés.

Le site peut être développé avec Next.js tout en utilisant un CMS pour administrer les contenus.

C'est ce qu'on appelle généralement une approche headless : le système de gestion de contenu et l'interface visible du site sont séparés.

---

Le CMS headless : séparer le contenu de l'interface

Dans un CMS traditionnel, l'administration et la génération du site sont souvent fortement liées.

Avec un CMS headless, le CMS s'occupe principalement des données et des contenus.

Le frontend, lui, peut être développé avec Next.js.

On obtient alors quelque chose comme :

                    ┌───────────────┐
                    │   CMS         │
                    │               │
                    │ Articles      │
                    │ Pages         │
                    │ Produits      │
                    └───────┬───────┘
                            │ API
                            ↓
                    ┌───────────────┐
                    │   Next.js     │
                    │               │
                    │ Interface    │
                    │ SEO           │
                    │ Performance   │
                    └───────┬───────┘
                            ↓
                         Visiteur

Cette séparation apporte beaucoup de liberté.

Mais elle ajoute aussi une couche technique.

Pour un projet qui en a réellement besoin, c'est une très bonne architecture.

Pour un site de cinq pages dont le contenu change une fois par an, cela peut être inutilement complexe.

La sophistication technique n'est pas une qualité en soi.

---

Alors, pourquoi ne pas toujours utiliser un CMS ?

Parce qu'un CMS généraliste apporte souvent beaucoup de fonctionnalités dont un petit site n'a pas besoin.

Prenons un site vitrine classique :

• Accueil
• Services
• À propos
• Réalisations
• Contact

Si son contenu change rarement, ajouter une interface d'administration complète, une base de données et plusieurs couches de maintenance peut augmenter la complexité sans apporter de bénéfice proportionnel.

Dans ce cas, un site léger développé sur mesure peut être une solution plus cohérente.

L'objectif n'est pas d'avoir le plus d'outils possible, mais d'avoir les bons outils.

---

Et pourquoi ne pas toujours faire du sur mesure ?

Pour la raison inverse.

Développer sur mesure demande du temps.

Chaque besoin particulier doit être pensé, développé, testé et maintenu.

Si une entreprise a besoin d'un système d'administration complet, de nombreuses personnes avec des rôles différents, d'un catalogue de milliers de produits ou d'un processus éditorial complexe, réinventer toutes ces fonctions n'est pas forcément pertinent.

Un CMS existant peut déjà résoudre une grande partie du problème.

Dans certains projets, utiliser une solution éprouvée permet de consacrer le budget à ce qui apporte réellement de la valeur : le design, l'expérience utilisateur, les contenus, le référencement ou les fonctionnalités métier.

---

Le coût réel ne se résume pas au prix de création

C'est une distinction importante.

Deux solutions peuvent avoir des coûts de développement très différents, mais des coûts d'exploitation inversés sur plusieurs années.

Il faut regarder au moins quatre dimensions :

Le coût initial

Combien faut-il investir pour construire la première version ?

Le coût de maintenance

Combien faut-il consacrer aux mises à jour, à la sécurité, aux dépendances et aux interventions techniques ?

Le coût des évolutions

Que se passe-t-il lorsqu'on souhaite ajouter une fonctionnalité ou modifier profondément le site ?

Le coût humain

Combien de temps les personnes de l'entreprise devront-elles consacrer à l'administration du site ?

Ce dernier coût est souvent invisible dans un devis.

Pourtant, s'il faut former plusieurs personnes, gérer une interface complexe ou effectuer manuellement des opérations répétitives chaque semaine, il peut rapidement devenir significatif.

---

La performance : avantage du sur mesure, mais pas exclusivité

On entend parfois :

« Un site sur mesure est forcément plus rapide qu'un site sous CMS. »

Ce n'est pas vrai dans l'absolu.

Un site sur mesure peut être extrêmement performant parce qu'il permet de limiter précisément ce qui est envoyé au navigateur.

Mais un CMS bien conçu peut également produire d'excellentes performances.

À l'inverse, un projet sur mesure mal développé peut être lent.

La performance dépend de nombreux facteurs :

• architecture ;
• stratégie de rendu ;
• JavaScript envoyé au navigateur ;
• poids des images ;
• polices ;
• hébergement ;
• cache ;
• requêtes réseau ;
• qualité du code ;
• contenu de la page.

Avec Next.js, je peux notamment choisir différentes stratégies de rendu selon les besoins du projet et limiter le JavaScript côté client lorsque l'interactivité n'est pas nécessaire.

Mais le framework ne fait pas disparaître les problèmes par magie.

Une bonne technologie permet de faire de bons choix. Elle ne les fait pas à notre place.

---

Et le SEO dans tout ça ?

Le choix entre CMS et sur mesure n'est pas non plus une bataille entre « bon pour le SEO » et « mauvais pour le SEO ».

Un site WordPress peut être très bien référencé.

Un site Next.js peut être très bien référencé.

Un site développé avec n'importe quelle autre technologie peut également être très bien référencé.

Le référencement dépend notamment :

• de la qualité et de la pertinence des contenus ;
• de l'architecture du site ;
• de son maillage interne ;
• de ses performances ;
• de son accessibilité aux moteurs ;
• de ses métadonnées ;
• de sa popularité et de ses liens entrants ;
• de la réponse qu'il apporte aux recherches des utilisateurs.

La technologie intervient principalement comme support de cette stratégie.

C'est d'ailleurs l'une des raisons pour lesquelles j'apprécie Next.js pour certains projets : il offre un contrôle important sur le rendu, les métadonnées, les performances et l'architecture du site.

Mais choisir Next.js ne dispense évidemment pas de faire le travail SEO.

---

La question de la sécurité

La sécurité est un autre élément souvent sous-estimé.

Un CMS largement utilisé bénéficie d'une communauté importante et de nombreux outils de sécurité. Mais sa popularité en fait également une cible fréquente.

Plus un projet utilise de plugins, extensions ou dépendances, plus il faut surveiller leur maintenance et leur compatibilité.

Un site sur mesure n'est pas automatiquement sécurisé non plus.

Le code spécifique doit lui aussi être correctement conçu et maintenu.

Dans les deux cas, il faut notamment considérer :

• les mises à jour ;
• les dépendances ;
• les accès administrateurs ;
• les sauvegardes ;
• la gestion des données ;
• les secrets et clés d'API ;
• la surveillance des erreurs.

Encore une fois, il n'y a pas de solution magique.

Il existe seulement des architectures dont les risques sont connus, compris et correctement gérés.

---

Le choix doit aussi tenir compte de l'avenir

Un site ne devrait pas être conçu uniquement pour répondre au besoin d'aujourd'hui.

Il ne faut pas pour autant prévoir toutes les fonctionnalités imaginables.

C'est là qu'intervient une notion importante en architecture logicielle : l'évolutivité.

Prenons deux situations.

Une entreprise locale avec un site vitrine

Elle possède cinq services, souhaite présenter son activité et recevoir des demandes de contact.

Elle ne prévoit pas de publier régulièrement du contenu et n'a pas d'équipe dédiée au site.

Une architecture simple peut être largement suffisante.

Une entreprise qui veut construire progressivement un outil métier

Elle souhaite commencer avec quelques fonctionnalités, puis ajouter un espace client, des comptes utilisateurs, des automatisations, des tableaux de bord et des intégrations avec d'autres outils.

Dans ce cas, les choix d'architecture initiaux deviennent beaucoup plus importants.

Il peut être pertinent de prévoir dès le départ une base technique capable d'évoluer.

La différence n'est donc pas seulement :

CMS vs sur mesure

mais plutôt :

quel niveau de complexité est justifié par le projet aujourd'hui, et quelle évolution raisonnable faut-il anticiper ?

---

Une grille simple pour prendre la décision

Il n'existe pas de formule mathématique universelle, mais quelques questions permettent déjà de dégrossir le choix.

| Question | CMS | Sur mesure | | ---------------------------------------------------- | ------------------------ | ---------------------------------------- | | Le contenu change très régulièrement ? | Très adapté | Possible | | Plusieurs personnes doivent administrer le site ? | Très adapté | Possible | | Le site possède peu de contenus stables ? | Possible | Souvent pertinent | | Le fonctionnement est très spécifique ? | Possible avec extensions | Très adapté | | Il faut une interface métier particulière ? | Possible | Souvent pertinent | | Le budget initial est très contraint ? | Peut être avantageux | À évaluer | | Le site doit évoluer vers une application complexe ? | À étudier | Souvent pertinent | | L'équipe veut gérer elle-même les contenus ? | Très adapté | CMS headless ou administration à prévoir | | Le référencement est prioritaire ? | Compatible | Compatible |

Cette grille ne donne pas automatiquement une réponse.

Elle permet surtout de poser les bonnes questions.

---

Quelques exemples concrets

Un petit site vitrine

Cinq à dix pages, peu de modifications, formulaire de contact et quelques contenus permanents.

Dans ce cas, un site léger sans CMS peut être parfaitement pertinent.

Il peut être rapide, simple à maintenir et peu exposé aux problèmes liés à une multitude d'extensions.

Mais il faut prévoir comment les futures modifications seront réalisées.

Un site avec un blog actif

Si l'entreprise publie plusieurs articles par mois, un système de gestion de contenu devient beaucoup plus intéressant.

Le contenu doit pouvoir être créé et publié sans intervention technique à chaque fois.

Un CMS classique ou headless peut alors être pertinent.

Un catalogue important

Si le site comporte des centaines ou milliers de références, avec des filtres, des catégories et des informations qui évoluent régulièrement, une gestion structurée des contenus devient presque indispensable.

La question n'est plus seulement « avons-nous besoin d'un CMS ? », mais aussi :

Quel système de données permettra de gérer efficacement ce catalogue ?

Un outil métier

Si le projet doit gérer des utilisateurs, des permissions, des données spécifiques, des workflows et des automatisations, on sort progressivement du simple site web.

Le sur-mesure devient alors beaucoup plus intéressant.

C'est notamment le cas lorsqu'un logiciel existant ne correspond pas suffisamment au fonctionnement de l'entreprise.

---

Le piège du « on verra plus tard »

L'une des erreurs les plus coûteuses consiste à repousser certaines décisions importantes.

Par exemple :

« On fera sans CMS pour commencer et on verra plus tard. »

C'est parfois une bonne décision.

Mais il faut savoir ce que signifie “plus tard”.

Si le site est conçu dès le départ comme un ensemble de pages statiques sans structure de contenu adaptée, ajouter un système d'administration quelques mois après peut demander une refonte importante.

À l'inverse, prévoir immédiatement une architecture complexe « au cas où » peut faire payer au client une complexité dont il n'aura peut-être jamais besoin.

La bonne approche consiste donc à identifier les évolutions probables et suffisamment importantes, sans essayer de prédire tout l'avenir.

---

Chez LB Studio : partir du besoin, puis choisir la technologie

Chez LB Studio, j'utilise régulièrement Next.js parce qu'il correspond bien à de nombreux projets que je développe : sites vitrines, sites métiers et projets qui doivent pouvoir évoluer.

Il me permet notamment de contrôler finement :

• le rendu des pages ;
• les performances ;
• la structure du site ;
• les métadonnées SEO ;
• les interactions ;
• les intégrations avec des services externes ;
• l'évolution future du projet.

Mais cela ne signifie pas que chaque client a besoin d'un site entièrement sur mesure.

Si un CMS apporte une réelle autonomie au client et répond correctement à ses besoins, il peut être le meilleur choix.

Et si le contenu change très peu, ajouter un CMS uniquement « parce qu'un site doit avoir un CMS » n'est pas forcément pertinent.

Le rôle du développeur n'est pas seulement de choisir une technologie qu'il aime utiliser.

Il doit aussi être capable d'expliquer pourquoi elle est adaptée au projet et quelles seront ses conséquences pour le client.

---

Le bon choix est celui que l'on peut encore assumer dans trois ans

Le meilleur choix technique n'est pas forcément celui qui produit le plus beau code, utilise le framework le plus récent ou propose le plus grand nombre de fonctionnalités.

C'est celui qui reste cohérent lorsque le projet est réellement utilisé.

Un CMS peut être le bon choix parce qu'il donne de l'autonomie à une équipe.

Un site sur mesure peut être le bon choix parce que le projet a besoin de performances, de liberté ou de fonctionnalités spécifiques.

Un CMS headless peut être pertinent lorsqu'on veut combiner une gestion éditoriale confortable avec une interface entièrement personnalisée.

Et parfois, la meilleure décision consiste simplement à ne pas ajouter une couche technique dont personne n'a besoin.

Il n'existe pas de technologie universellement meilleure. Il existe une solution adaptée au projet, à son budget, à ses utilisateurs et aux personnes qui devront le faire vivre après sa mise en ligne.

C'est avec cette logique que je préfère aborder un projet web : comprendre d'abord, choisir ensuite, et ne développer que ce qui apporte réellement quelque chose.