Cinq façons de placer un CMS derrière un site HTML qui existe déjà, et ce que chacune coûte vraiment en temps de mise en place, en changements de code et en déménagement d'hébergement. L'une d'elles est la nôtre, et nous disons sans détour où elle est la mauvaise réponse.
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.
| Couche par balise script | Refonte WordPress | CMS sur git | Headless CMS | PHP en fichiers plats | |
|---|---|---|---|---|---|
| Exemples | Qixoo | WordPress + un thèmeElementor, Bricks | TinaCMS, DecapCloudCannon, Sveltia | Contentful, SanityStoryblok, Prismic | Sitecake, CouchCMSGetSimple |
| 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ôtreVotre logo via le module marque blanche, 29 $ une fois | 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/moL'offre gratuite couvre 1 site | L'hébergement plus votre tempsLe logiciel est gratuit | Free–$100/moDecap et Tina sont open source | $100–$500+/mo | Licence uniqueSouvent moins de 100 $ |
| 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. La première fois, avec n'importe lequel, vous serez plus lent.
Chaque option de cette page est la meilleure pour quelqu'un. Voici qui devrait passer son chemin devant chacune.
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, trois personnes qui valident un paragraphe.
Convient à : les sites vitrines, les landing pages et les sites de commerces locaux — ceux qui changent quelques fois par mois.
Reconstruire un site déjà terminé sous WordPress 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. Quelqu'un paie ça pour toujours, et c'est en général vous.
Cela jette aussi tout ce qui rendait votre site d'origine rapide et propre.
Convient à : les sites qui ont réellement besoin d'extensions : adhésions, réservations, une vraie boutique.
Decap, Tina et CloudCannon sont de bons outils, bon marché ou gratuits, et ils gardent le contenu dans votre dépôt. Ils supposent aussi un dépôt, un build et un déploiement qui se déclenche quand le contenu change. Quelqu'un doit assumer cette chaîne.
Quand le build casse, la modification du client n'apparaît pas — et c'est vous qu'il appelle.
Convient à : les sites tenus par des développeurs, la documentation et les équipes qui vivent déjà dans git.
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 et à réécrire des gabarits pour résoudre un problème qui tenait en une phrase.
Le prix mensuel est lui aussi d'un tout autre ordre de grandeur.
Convient à : le contenu multicanal, les applications et plusieurs sites partageant un même fonds de contenu.
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 d'ailleurs pas reçu de vraie mise à jour depuis des années.
Convient à : l'hébergement mutualisé classique avec cPanel et FTP.
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 ».
Collez-la une fois avant </head> sur chaque page, ou dans le champ de code personnalisé du head de la plateforme qui héberge le site. Rien d'autre ne change dans le balisage.
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.
Il ouvre son propre site et le modifie dans un éditeur allégé qui ne porte aucune marque Qixoo. Sans compte, sans tableau de bord, sans code. Mettez-y votre propre logo avec le module marque blanche.
Textes et titres, images, liens, boutons, éléments de liste, menus, galeries et carrousels — ce que les clients demandent réellement de changer. Vous pouvez aussi insérer des blocs prêts à l'emploi (une FAQ, une grille de tarifs, une rangée de témoignages) sans écrire de balisage.
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 l'édition structurelle, pas un verrou sur la page sous-jacente. Il n'héberge pas non plus votre site — c'est toujours votre hébergeur qui sert le HTML.
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 ou un paragraphe d'introduction 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.
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, qui remplacent toutes deux la façon dont les pages sont générées.
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. Le contenu modifié est réappliqué dans le navigateur, un texte changé peut donc ê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.
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.
Cela fonctionne sur tout site qui sert du HTML, quel que soit l'hébergeur : HTML écrit à la main, générateurs statiques, sites Webflow ou Framer exportés, thèmes WordPress, et tout ce qui tourne sur Netlify, Vercel, Render, cPanel ou un VPS. 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.
Il reste en ligne avec toutes les modifications enregistrées intactes : les visiteurs voient le contenu à jour. Seule l'édition se met en pause jusqu'à ce qu'un forfait redevienne actif. Rien n'est supprimé, rien n'a à être rapatrié.
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. Le HTML rendu côté serveur et les exports statiques sont le cas fiable.
Plusieurs. Decap CMS et TinaCMS sont gratuits et open source si le site vit dans un dépôt git et qu'une chaîne de build vous convient. 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.
Alors commencez par la page écrite exactement pour ça : le remplacement de l'ancien Editor et de la marque blanche Webflow. Elle couvre les Client Seats, ce qui a changé le 4 août 2026 et comment remettre l'édition au clic sous votre propre marque.
Une ligne de code. Le premier site est gratuit, sans limite de durée et sans carte.
Commencer gratuitement →