mindxassociates/practice-website-kit

Kit Site de Cabinet — Astro + PagesCMS + Cloudflare Pages

La pile technique, et pourquoi

Couche	Choix	Pourquoi
Cadre du site	Astro	Génère du HTML statique avec quasiment zéro JavaScript par défaut — rapide sur mobile, rien à patcher, contenu en Markdown avec frontmatter typé.
Édition de contenu	PagesCMS (app.pagescms.org)	Gratuit, open-source, basé sur Git : le personnel édite via des formulaires web ; chaque sauvegarde est un commit Git. Pas de base de données, pas de serveur CMS à maintenir.
Hébergement	Cloudflare Pages	Le niveau gratuit convient parfaitement à un site de cabinet (minutes de build et bande passante généreuses, nombreux domaines personnalisés), sans marque, usage commercial autorisé, CDN mondial, HTTPS automatique. Déployer = connecter le dépôt Git.
Dépôt	GitHub (propriété du cabinet)	L'unique maison du site : Astro le lit, PagesCMS y écrit, Cloudflare le construit.

La règle d'architecture qui fait fonctionner l'ensemble : le site web est une publication, pas une application. Les pages, profils et articles sont du contenu. Les réservations, paiements, messageries et annuaires ont déjà des systèmes — le site les intègre et les lie ; il ne les réimplémente jamais et ne reçoit jamais leurs données.

Instructions pour l'agent

• Livrable = un dépôt fonctionnel que le cabinet possède + les trois connexions établies (PagesCMS → dépôt, Cloudflare Pages → dépôt + domaine) + une modification bout en bout vérifiée via le CMS. Si vous n'avez pas accès aux comptes, produisez le dépôt complet et une liste de connexion étape par étape pour le propriétaire.
• Menez d'abord l'entretien de configuration. N'inventez jamais les faits du cabinet — agréments, licences, réseaux de soins, honoraires, langues, années d'exercice. Utilisez des espaces réservés, signalés, jusqu'à ce que le propriétaire les fournisse.
• Vérifiez chaque comportement de la plateforme à partir de la configuration en direct, pas de mémoire : la règle du modèle de nom de fichier PagesCMS dans references/pagescms-config.md a coûté à un vrai site sa première sauvegarde — considérez le test de sauvegarde CMS comme la définition de « configuré ».

Entretien de configuration (à poser une fois, avant de construire)

1. Identité du cabinet — nom du cabinet, domaine (et où réside le DNS — l'hébergement Cloudflare est plus fluide quand le DNS est aussi chez Cloudflare), logo/couleurs éventuels, téléphone/e-mail à afficher.
2. Structure — solo ou groupe ; liste des praticiens (noms, diplômes, États d'agrément, disponibilité de photos) pour les pages de profil.
3. Pages — confirmez le plan dans references/site-blueprint.md (ajoutez/supprimez : par exemple, une page dédiée par service ? une section ressources/blog ? un annuaire d'orientation intégré ?).
4. Langues — une seule langue, ou une arborescence miroir (par exemple anglais à /, chinois à /zh/) ? Le miroir signifie des pages traduites de qualité humaine avec leurs propres slugs — budgétez la traduction ; ne traduisez jamais automatiquement un contenu clinique et ne le publiez pas sans relecture.
5. Intégrations dynamiques — quels systèmes existants apparaissent sur le site (page de réservation, application de formulaire de contact, annuaire d'orientation, point d'entrée de messages sécurisés) et leurs URL. Ceux-ci deviennent des intégrations iframe + des liens de secours.
6. Éditeurs — qui met à jour le contenu après le lancement (propriétaire uniquement ? un administrateur ? des praticiens qui écrivent des articles ?) — cela détermine l'accès à PagesCMS et la quantité du site gérée par le CMS vs. par le code.
7. Actifs existants — contenu du site actuel à migrer, photos (et leurs droits), Profil Google Business et annuaires avec lesquels le site doit rester cohérent.

Règles strictes

1. Le cabinet possède tous les comptes — registraire de domaine, GitHub, Cloudflare. Configurez-les avec les identifiants du cabinet, avec des options de récupération que le cabinet contrôle.
2. Le contenu est une donnée, pas du code. Tout ce qu'un éditeur pourrait modifier (biographies des praticiens, services, honoraires, FAQ, articles) réside en Markdown/frontmatter derrière un schéma de contenu — jamais codé en dur dans des modèles .astro.
3. Les modèles de nom de fichier PagesCMS utilisent {fields.slug} (ou le chemin de champ réel de la collection). Un {slug} nu est invalide et fait toujours échouer la sauvegarde CMS avec une erreur opaque. Après avoir corrigé la configuration, rechargez le CMS — il met en cache la configuration par session.
4. Le site ne collecte rien de clinique. Pas de champs de texte sur les symptômes, pas de formulaires « dites-nous ce qui se passe ». Contact = lien/intégration de réservation, téléphone, et une application de formulaire routée si nécessaire — plus la ligne de crise (311 en France, 911 pour les urgences) sur la page de contact et toute page qui invite au contact, dans les langues du site.
5. Les intégrations ont des liens de secours. Chaque iframe (réservation, annuaire) est associé à un lien simple vers le même système, afin qu'un cadre bloqué ne laisse jamais un client sans issue.
6. Discipline des informations : les réseaux, honoraires, diplômes et disponibilités sur le site doivent correspondre à la source de vérité du cabinet (son registre/dossier). Le site web est le dernier endroit où un fait devrait être modifié — si un chiffre vit à deux endroits, indiquez lequel prévaut.
7. La performance est une fonctionnalité sur un site de thérapie — les gens arrivent anxieux, sur mobile, depuis un annuaire. Comprimez les images avant qu'elles n'entrent dans le dépôt ; une photo d'en-tête de 2 Mo est un bug, pas un atout.

Ordre de construction

1. Dépôt + échafaudage Astro + modèle de contenu selon references/astro-setup.md, pages selon references/site-blueprint.md.
2. Build local OK ; espaces réservés de contenu signalés et listés pour le propriétaire.
3. Configuration PagesCMS + le vrai test de sauvegarde selon references/pagescms-config.md.
4. Connexion Cloudflare Pages + domaine personnalisé selon references/cloudflare-pages-deploy.md.
5. Passage SEO/performance selon references/seo-and-performance.md.
6. Remise selon references/maintenance-and-handoff.md ; vérification selon references/test-checklist.md.

Fichiers de référence

• references/architecture-and-stack.md — les trois couches, flux de données, ce que signifie « statique » pour un cabinet
• references/site-blueprint.md — les pages, ce que chacune doit contenir, impératifs propres à la thérapie
• references/astro-setup.md — structure du projet, collections de contenu + schéma, arborescence multilingue
• references/pagescms-config.md — .pages.yml, collections, médias, la règle du modèle de nom de fichier
• references/cloudflare-pages-deploy.md — configuration du projet, paramètres de build, domaine personnalisé, aperçus
• references/seo-and-performance.md — métadonnées, données structurées, sitemap/RSS, llms.txt, images
• references/maintenance-and-handoff.md — workflow d'édition, mises à jour, sauvegardes, qui possède quoi
• references/test-checklist.md — tests d'acceptation, le test de sauvegarde CMS en premier