Astro, Cloudflare et un CMS que la cliente peut piloter

Pour le site d'Eva, j'avais trois choix techniques à faire : le framework, l'hébergement et l'édition du contenu. Astro et Cloudflare Pages étaient retenus. Le CMS restait à choisir au moment où j'écrivais cet épisode.

Je suis Jim. Après le prototype HTML travaillé avec Eva, voici comment j'ai organisé son intégration et ce que j'attendais de l'interface d'édition.

Reprendre le prototype avec Astro

Le site contient surtout des textes, des photos, des animations et une vidéo dans le hero. Je n'avais pas besoin d'une application complexe pour afficher ces pages. En génération statique, Astro permet de préparer leur HTML au build, puis de le servir aux visites. Les interactions qui en ont besoin peuvent conserver du JavaScript.

Pour ce site éditorial, je peux donc regarder ce qui est envoyé au navigateur et réserver le JavaScript aux interactions qui le demandent.

L'autre intérêt était le portage du prototype. Les composants Astro acceptent du HTML, ce qui m'a permis de reprendre les pages sans refaire toute leur composition. J'ai isolé la navigation et le footer, remplacé les textes en dur par du contenu éditable et préparé les images.

Les optimisations restent à configurer. Les composants d'images d'Astro peuvent préparer des tailles et des formats adaptés. Le sitemap nécessite son intégration ou une autre génération, et le fichier robots.txt reste à prévoir.

Déployer avec Cloudflare Pages

Le workflow retenu repose sur Git. Une modification poussée dans le dépôt déclenche le build et le déploiement. Je n'ai donc pas à transférer les fichiers un par un sur un serveur.

L'offre gratuite de Pages répondait au budget prévu pour l'hébergement statique de ce chantier. Elle a des limites documentées, notamment sur les builds. Une fonction serveur ou un autre service ajouté au projet peut avoir sa propre facturation.

Les previews permettent de montrer une version avant de l'utiliser en production. Un point à préciser : leurs URL sont publiques par défaut. Cloudflare Access permet de restreindre l'accès si nécessaire.

Pages prend aussi en charge la distribution des fichiers sur son réseau et le HTTPS. C'est du travail d'infrastructure que je n'ai pas à gérer comme sur un serveur que j'administre moi-même. Il reste à surveiller les builds et les réglages du projet.

Délimiter ce qu'Eva peut modifier

Eva doit pouvoir corriger une phrase et remplacer une photo sans modifier le CSS. C'était le besoin principal pour le CMS. Donner accès au contenu ne demande pas forcément de donner accès à toute la composition.

Les champs envisagés étaient précis : textes du hero, manifeste, photos, descriptions des offres et mentions du footer. La structure, les couleurs, la typographie et les animations resteraient gérées dans le code.

Cette frontière évite qu'une correction de texte devienne une modification de mise en page. Je dois tout de même regarder les cas ordinaires : un paragraphe plus long, un titre sur deux lignes ou une photo mal cadrée. Ce sont ces changements qu'Eva fera sur son site.

Le CMS restait un choix à confirmer

Au moment de ce récit, je visais une édition visuelle avec TinaCMS comme candidat, et Sanity comme alternative. L'intérêt attendu était qu'Eva puisse regarder la page pendant qu'elle modifie son contenu.

Avec une intégration reliée à Git, les modifications peuvent devenir des commits. L'historique permet alors de retrouver un texte ou une version précédente, puis de la republier si nécessaire. Pour moi, c'est un intérêt pratique de ce type de CMS.

L'interface devait être jugée sur les actions d'Eva. Peut-elle trouver le texte à modifier ? Comprend-elle ce qui est sauvegardé et ce qui est publié ? Le résultat arrive-t-il sur la bonne page ? Ce sont ces vérifications qui permettent de parler d'autonomie.

Le budget prévu, hors temps de travail

Le chiffrage du chantier retenait environ 12 € par an pour le domaine, un hébergement Pages dans l'offre gratuite et un CMS à maintenir dans une offre gratuite adaptée au besoin. Le comparatif de travail situait l'abonnement Wix entre 20 et 50 € par mois. Ce sont les estimations utilisées pour ce chantier.

Il manque surtout le temps dans une comparaison limitée aux abonnements. Concevoir le site, intégrer le CMS et maintenir le code a un coût, même lorsque l'hébergement n'est pas facturé. Le contrôle recherché sur les pages doit justifier ce temps de construction et de maintenance.

Pour regarder ensuite le poids des médias et le chargement des pages, j'ai consacré un épisode à le travail de performance du site. J'ai rassemblé les choix que je garderais dans le bilan de la refonte.