Mettre à jour un site sans CMS fonctionne ainsi : vous envoyez la demande en langage courant par WhatsApp, e-mail ou Slack, un agent IA l'implémente dans le code du site, puis un lien de prévisualisation revient pour votre validation. Après relecture par un développeur senior, la modification part en ligne. Pas de panneau d'administration, pas de mises à jour de plugins, pas de mise en page qui casse discrètement.
Vous songez à quitter WordPress depuis un moment, et une question vous arrête à chaque fois : qui changera les horaires d'ouverture s'il n'y a plus de back-office où se connecter ?
Cette crainte est fondée : pendant vingt ans, quitter le CMS signifiait envoyer un e-mail à un développeur et payer un minimum horaire pour une correction de deux minutes. Cet article détaille le workflow de mise à jour exact que webvise utilise sur les sites clients, à quoi ressemble une demande de modification en pratique, et dans quels cas un CMS headless comme Sanity est le meilleur choix. À la fin, la question de l'édition ne devrait plus être la raison de garder une installation WordPress en vie.
- Le langage courant remplace le panneau d'administration. Les demandes de modification passent par WhatsApp, e-mail ou Slack, avec les mots que vous utiliseriez avec un collègue.
- Chaque modification revient sous forme de lien de prévisualisation : une copie privée complète du site avec la modification appliquée, à sa propre URL, avant toute mise en ligne.
- Deux étapes de validation au lieu de zéro. Le client valide la prévisualisation, et un développeur senior relit le code modifié avant la mise en ligne.
- Chaque modification est versionnée dans git, ce qui permet de restaurer n'importe quel état antérieur du site.
- Un volume élevé de modifications justifie toujours un CMS. Les équipes qui publient chaque jour reçoivent plutôt une intégration Sanity dans le build.
La peur qui bloque chaque migration
La question qui ouvre presque tous les appels de migration webvise commence par une variante de « pourrai-je encore modifier mon site après coup ? ». Elle arrive avant le coût, avant le délai, parfois avant le SEO. La FAQ de migration WordPress vers Next.js répond à onze objections courantes, et c'est celle-là qu'on pose en premier.
Cette peur a une histoire. Quitter le CMS signifiait autrefois attendre trois jours qu'un développeur change une photo, ce qui rendait rationnel le fait de garder une installation WordPress alourdie, même au prix des 1 500 à 5 000 € par an que cela coûte réellement. Le panneau d'administration achetait un sentiment de contrôle, et la facture annuelle était le prix de ce sentiment.
Deux évolutions ont mis fin à ce compromis : des agents IA capables d'implémenter des modifications ciblées dans un vrai code source, et des déploiements de prévisualisation qui montrent chaque modification avant sa mise en ligne. Le service de migration WordPress de webvise intègre ce workflow d'édition à chaque refonte. La suite de cet article montre à quoi cela ressemble du côté client.
Le workflow : message envoyé, lien de prévisualisation en retour
La boucle comporte six étapes, et vous n'intervenez que dans deux d'entre elles.
| Étape | Qui | Ce qui se passe |
|---|---|---|
| 1. Envoyer la demande | Vous | Un message en langage courant par WhatsApp, e-mail ou Slack. Captures d'écran et photos fonctionnent aussi. |
| 2. Implémentation | Agent IA | L'agent effectue la modification dans le code du site, en suivant le système de design existant. |
| 3. Déploiement de prévisualisation | Automatique | Une copie complète du site avec la modification appliquée est publiée à sa propre URL privée. |
| 4. Validation | Vous | Ouvrez le lien sur votre téléphone, répondez par un OK ou des corrections. Les corrections renvoient à l'étape 2. |
| 5. Relecture du code | webvise | Un développeur senior relit la modification réelle avant la fusion. Rien n'est mis en ligne sur la seule sortie de l'agent. |
| 6. Mise en ligne | Automatique | La modification est déployée sur le site de production. L'état précédent reste restaurable depuis l'historique git. |
Le lien de prévisualisation est ce qui supprime la crainte. C'est le site réel avec votre modification appliquée, donc ce que vous validez est exactement ce qui part en ligne. WordPress ne vous a jamais offert cela : vous modifiiez le back-office en espérant que le frontend suive.
La relecture du code compte tout autant. Je relis chaque modification avant sa fusion, une exigence plus stricte que celle imposée par n'importe quel CMS. Un panneau d'administration publie tout ce que la dernière personne connectée y a tapé.
À quoi cela ressemble en pratique
Le site que vous lisez fonctionne sur cette boucle exacte. webvise.io est disponible en 7 langues, le blog qui l'accompagne compte 124 articles et 868 fichiers de contenu dans un seul dépôt git, et chaque article, mise à jour de prix ou changement de texte passe par un agent, un déploiement de prévisualisation et une relecture avant fusion. Il n'y a aucun CMS dans toute la stack, et cet article vous est parvenu par ce même pipeline.
Les demandes des clients sont banales, et c'est bien le but. De nouveaux horaires d'ouverture, l'arrivée d'un membre de l'équipe, des photos de projet récentes, une bannière saisonnière, une liste de prix mise à jour : chacune tient en un message de deux lignes, au lieu d'une connexion et d'une session dans un page builder qui peut casser la mise en page sans prévenir. Le délai ne dépend plus de l'agenda d'un développeur, car l'implémentation démarre dès que la demande arrive. Les deux humains dans la boucle, vous qui validez et moi qui relis, sont la seule attente.
Tout ce qui dépasse une simple modification de contenu est d'abord cadré. Une nouvelle page, un flux de réservation, une troisième langue : cela passe par un devis rapide avant qu'un agent ne touche au code. Le canal sert aux modifications courantes qui justifiaient autrefois de garder un CMS installé.
Canal de mise à jour, administration WordPress ou CMS Sanity
Trois modèles d'édition couvrent presque tous les sites professionnels. Voici la comparaison honnête :
| Administration WordPress | CMS Sanity (headless) | Canal de mise à jour | |
|---|---|---|---|
| Qui effectue la modification | Vous, dans un page builder | Vous, dans un éditeur structuré | Vous décrivez, un agent implémente |
| La mise en page peut casser | Oui, régulièrement | Non, le contenu est séparé du design | Non, chaque modification est du code relu |
| Relecture avant mise en ligne | Aucune | Brouillons optionnels | Lien de prévisualisation et relecture du code |
| Historique des versions | Articles seulement, avec des plugins | Par document | Le site entier, dans git |
| Le mieux adapté à | L'habitude | Publication quotidienne, contenu structuré | Une poignée de modifications par mois |
| Poste de coût récurrent | Plugins, hébergement, correctifs | Abonnement CMS plus le build | Forfait de support |
La variable décisive est le volume de modifications. Une entreprise qui met à jour ses références deux fois par an et publie une offre d'emploi par trimestre ne tire rien d'une licence CMS, hormis ses correctifs de sécurité. Une équipe éditoriale qui publie chaque matin a besoin d'un accès direct, et aucun canal de messages ne devrait s'y interposer.
Quand Sanity est la bonne réponse
Intégrer Sanity dans un build Next.js se justifie dès que le volume de modifications appelle une vraie interface éditoriale. L'expérience d'édition se rapproche de WordPress, le frontend reste statique et rapide, et la publication ne passe par aucune boucle de validation. Ce qu'est un CMS headless, son coût, et où se situent les compromis sont expliqués dans le guide du CMS headless en langage simple.
- Publication au calendrier. Articles de blog, actualités ou études de cas publiés chaque semaine ou plus souvent.
- Plusieurs rédacteurs. Marketing, RH et ventes touchent tous au contenu, avec brouillons et rôles.
- Contenu structuré. Catalogues de produits, sites ou formations : des données avec des champs, pas des pages.
- Publication à la minute, car le volume rend une boucle de validation impraticable.
Les deux modèles cohabitent très bien sur un même build. Un site peut servir ses pages produits depuis Sanity tandis que les modifications de design et de fonctionnalités continuent de passer par le canal. Les deux répondent à des questions différentes : qui édite, et à quelle fréquence.
Ce que cela coûte et comment c'est structuré
Le travail de mise à jour s'inscrit dans le cadre de support continu de webvise : surveillance, correctifs, petites améliorations, et un rythme de support convenu avant le début de la mission. Aucun forfait n'est jamais obligatoire, et une formule à la demande existe pour les sites qui changent deux fois par an. Ce qu'un budget de maintenance doit ou ne doit pas inclure est détaillé dans le guide des coûts de maintenance de site.
Comparez cela aux 1 500 à 5 000 € par an que coûte le maintien en vie d'un site WordPress typique de petite entreprise. La majeure partie de cette dépense achète simplement le statu quo : renouvellements de plugins, paliers d'hébergement, correctifs de sécurité. Un canal de messages transforme ce même budget en modifications visibles sur le site.
Si la question de l'édition est ce qui vous a fait garder WordPress, le workflow ci-dessus y répond. webvise prend en charge la refonte via le service de migration WordPress, puis met en place le canal de mise à jour, une installation Sanity, ou les deux, selon votre volume de modifications. Pour toute autre demande, webvise.io/#contact permet de joindre Sebastian directement.
Les pratiques de webvise sont alignées sur les normes ISO 27001 et ISO 42001.