# Ajouter un CMS à un site HTML existant : cinq solutions comparées
> Version Markdown de https://qixoo.app/fr/articles/add-cms-to-html-site.html
## Réponse courte
Le moyen le plus rapide d'ajouter un CMS à un site HTML existant est d'y attacher une
couche d'édition hébergée avec une seule balise script. Le balisage, les styles et
l'hébergement restent exactement tels quels, et le contenu devient modifiable sur place
— généralement en moins de cinq minutes.
Toutes les autres solutions impliquent de toucher au build. Une refonte WordPress
remplace la façon dont les pages sont générées. Un CMS sur git exige un dépôt et une
chaîne de déploiement. Un CMS headless exige quelqu'un pour modéliser le contenu et le
câbler aux gabarits. Un CMS PHP en fichiers plats exige PHP sur le serveur et des
droits d'écriture sur la racine web.
Choisissez avec deux questions : **faut-il toucher au code ?** et **le client a-t-il
besoin d'un compte quelque part ?** Tout le reste n'est que détail.
## Les cinq options face à face
| | Couche par balise script | Refonte WordPress | CMS sur git | CMS headless | PHP en fichiers plats |
|---|---|---|---|---|---|
| Exemples | Qixoo | WordPress + un thème | TinaCMS, Decap, CloudCannon, Sveltia | Contentful, Sanity, Storyblok, Prismic | Sitecake, CouchCMS, GetSimple |
| Mise en place réaliste | ~5 minutes | 1–3 jours | 2–6 heures | 1–2 jours de dev | 1–2 heures |
| Faut-il toucher au code ? | Une ligne | Reconstruit de zéro | Les gabarits sont annotés | Gabarits réécrits | Balises de commentaire par zone |
| Le site déménage-t-il ? | Non — il reste où il est | En général oui | Exige git et un build | Exige un build ou un serveur | Exige un hébergement PHP |
| Le client a besoin d'un compte | Non — lien d'invitation | Oui, un utilisateur WordPress | Oui, en général un accès git | Oui, un siège dans le CMS | Oui, un mot de passe du CMS |
| À quelle marque appartient l'éditeur | Neutre, ou la vôtre avec le module marque blanche | WordPress | Variable, souvent celle de l'éditeur du logiciel | Celle du fournisseur | Celle de l'outil |
| Maintenance continue | Aucune de votre côté | Mises à jour du cœur, du thème, des extensions | Entretien de la chaîne de build | Entretien de l'intégration | Mises à jour PHP, droits sur les fichiers |
| Coût habituel | 0–99 $/mois, l'offre gratuite couvre 1 site | L'hébergement plus votre temps | Gratuit–100 $/mois | 100–500+ $/mois | Licence unique |
| Le contenu vit dans le HTML source | Réappliqué dans le navigateur | Oui | Oui, au build | Oui, si rendu côté serveur | Oui, écrit dans le fichier |
Les durées valent pour un site vitrine de cinq pages remis à un client non technique,
par quelqu'un qui a déjà utilisé l'outil.
## Quand chacune est le mauvais choix
**Couche par balise script — passez votre chemin si le contenu est le produit.** Un
blog avec un article par jour, une boutique de mille références, un site d'offres
d'emploi : tout ce où le contenu est produit en volume et doit se trouver dans le HTML
source à l'instant où il change relève d'un vrai CMS avec gabarits et base de données.
Passez votre chemin aussi s'il vous faut un circuit éditorial : brouillons, relecture,
publication programmée, validations. Convient aux sites vitrines, aux landing pages et
aux sites de commerces locaux qui changent quelques fois par mois.
**Refonte WordPress — passez votre chemin si c'est pour un seul client.** Reconstruire
un site déjà terminé coûte des jours, et le jour où vous finissez vous avez adopté un
travail de maintenance : mises à jour du cœur, mises à jour des extensions, sécurité,
sauvegardes. Convient aux sites qui ont réellement besoin d'extensions : adhésions,
réservations, une vraie boutique.
**CMS sur git — passez votre chemin si le client n'est pas technique.** Decap, Tina et
CloudCannon gardent le contenu dans votre dépôt, mais supposent un dépôt, un build et
un déploiement qui se déclenche quand le contenu change. Quand le build casse, la
modification du client n'apparaît pas et c'est vous qu'il appelle. Convient aux sites
tenus par des développeurs, à la documentation et aux équipes qui vivent déjà dans git.
**CMS headless — passez votre chemin pour un site de cinq pages.** Contentful, Sanity
et Storyblok sont conçus pour du contenu à grande échelle sur de nombreux canaux. Pour
un restaurant avec une carte et un bloc d'horaires, vous passerez une journée à
modéliser des types de contenu pour résoudre un problème qui tenait en une phrase, à un
coût mensuel d'un tout autre ordre. Convient au contenu multicanal et à plusieurs sites
partageant un même fonds de contenu.
**PHP en fichiers plats — passez votre chemin si le site n'est pas sur un hébergement
PHP.** Sitecake et CouchCMS réécrivent directement dans vos fichiers HTML, ce qui est
élégant, et cela exige PHP, des droits d'écriture sur la racine web et un hébergeur qui
tolère les deux. Netlify, Vercel et Cloudflare Pages ne le tolèrent pas. Plusieurs
outils de cette catégorie n'ont pas reçu de vraie mise à jour depuis des années.
Convient à l'hébergement mutualisé classique avec cPanel et FTP.
**Règle simple.** Si la personne qui modifie le site est développeuse, mettez le
contenu dans git. Si une équipe marketing le modifie tous les jours, achetez un vrai
CMS. Si c'est un restaurateur qui veut changer un prix un dimanche et ne s'est jamais
connecté à quoi que ce soit, gardez l'édition sur la page elle-même. La mauvaise
réponse est toujours « envoyez-moi les changements, je m'en occupe ».
## La voie de la balise script, concrètement
1. **Une ligne dans la page.** Collez-la une fois avant `` sur chaque page, ou
dans le champ de code personnalisé du head de la plateforme qui héberge le site :
``
2. **Cliquez sur ce qui doit être modifiable.** Ouvrez le site en ligne en étant
connecté et cliquez sur un titre, un paragraphe, une image ou un lien pour le
changer. Le contenu enregistré est réappliqué à chaque chargement de page.
3. **Envoyez un lien au client.** Il ouvre son propre site et le modifie dans un
éditeur allégé sans marque Qixoo. Sans compte, sans tableau de bord, sans code.
**Ce que « modifiable » recouvre :** textes et titres, images, liens, boutons, éléments
de liste, menus, galeries et carrousels. Vous pouvez aussi insérer des blocs prêts à
l'emploi sans écrire de balisage.
**Ce qu'il ne fait délibérément pas :** il ne restructure pas votre mise en page, et ce
n'est pas un bac à sable de permissions — l'éditeur client est une interface réduite
qui masque les fonctions réservées à l'opérateur, pas un verrou sur le contenu de la
page. Il n'héberge pas non plus votre site ; c'est toujours votre hébergeur qui sert le
HTML.
**À propos du SEO.** Votre hébergeur continue de servir le HTML que vous avez écrit, un
robot reçoit donc toujours une page complète. Le contenu modifié via la couche est
réappliqué dans le navigateur, ce qui veut dire qu'une modification peut être prise en
compte plus tard qu'un changement du fichier source. Pour un titre qui change quelques
fois par an, cela n'a aucune importance. Si tout le contenu d'une page doit être indexé
le jour où il change, modifiez aussi le HTML.
## Questions fréquentes
**Dois-je reconstruire le site pour y ajouter un CMS ?**
Non. Une couche d'édition par balise script s'attache au HTML que vous avez déjà
publié : balisage, styles et hébergement restent tels quels. Reconstruire n'est
nécessaire que sur la voie WordPress ou headless.
**Ajouter un CMS de cette façon nuit-il au référencement ?**
Le HTML d'origine continue d'être servi par votre hébergeur, la page que reçoit un
robot est donc celle que vous avez écrite. Un texte changé peut être vu plus tard qu'un
changement statique. Parfait pour des textes qui changent de temps en temps ; modifiez
aussi la source si une page doit être indexée le jour où elle change.
**Mon client a-t-il besoin d'un compte pour modifier le site ?**
Avec Qixoo, non : vous envoyez un lien d'invitation et il modifie son propre site en
ligne. Avec les Client Seats de Webflow, WordPress ou un CMS headless, chaque personne
qui modifie a besoin d'un compte sur cette plateforme.
**Est-ce que ça marche avec Webflow, Framer, WordPress ou Netlify ?**
Cela fonctionne sur tout site qui sert du HTML, quel que soit l'hébergeur. Sur les
sites hébergés chez Webflow, la balise se place dans Site Settings → Custom Code, ce
qui nécessite un forfait de site payant.
**Qu'arrive-t-il au site si j'arrête de payer ?**
Il reste en ligne avec toutes les modifications enregistrées intactes. Seule l'édition
se met en pause jusqu'à ce qu'un forfait redevienne actif. Rien n'est supprimé.
**Est-ce que ça marche sur une application monopage en React ?**
Au mieux. Les applications qui refont le rendu du DOM après le chargement peuvent
écraser le contenu injecté : testez une page avant de le promettre à un client.
**Existe-t-il un moyen gratuit de faire ça ?**
Plusieurs. Decap CMS et TinaCMS sont gratuits et open source si le site vit dans un
dépôt git. L'offre gratuite de Qixoo couvre un site sans limite de durée. Le logiciel
WordPress est gratuit ; l'hébergement, le temps de migration et la maintenance ne le
sont pas.
Voir aussi : [Remplacement de l'ancien Editor Webflow](https://qixoo.app/fr/articles/webflow-alternative.md) ·
[Qixoo en français](https://qixoo.app/fr/index.md) ·
[Documentation](https://qixoo.app/fr/docs/index.md)