Claude Site Starter : le kit open source pour créer un site avec Claude Code

Le problème que je voulais résoudre

Le site que vous consultez a été construit entièrement avec Claude Code. Sans framework, sans CMS, avec un déploiement par SFTP sur un hébergement mutualisé OVH à quelques euros par mois. Le résultat, c'est un site rapide, sécurisé, que je modifie en une phrase. Pas de mise à jour WordPress le lundi matin, pas de plugin à 99 € par an, pas de panneau admin à sécuriser dans la durée.

Mais pour arriver à cette simplicité, j'ai tâtonné. J'ai inventé des conventions au fur et à mesure des pages, répété des workflows qui auraient dû être automatisés dès le départ, et commis quelques erreurs de sécurité que j'aurais préféré éviter. C'est le genre d'apprentissage qu'on ne peut pas vraiment éviter sur un premier projet, mais qui pèse sur les délais et sur la concentration.

Au moment de recommencer pour un client, j'ai voulu figer la méthode dans un dépôt réutilisable. Puis je me suis dit que ce dépôt pourrait servir à d'autres consultants, freelances ou petites équipes qui veulent construire leur présence en ligne avec Claude Code. C'est la raison d'être de Claude Site Starter : un kit de démarrage open source, public sur GitHub, forkable en un clic avec le bouton « Use this template ». Licence MIT, utilisable pour vos projets personnels comme pour des missions client.

Ce que contient le starter

L'idée est simple. Vous clonez le dépôt, vous lancez claude dans le dossier, et vous tapez /start-new-site. Un wizard vous pose alors les questions essentielles : le nom de votre marque, la structure des pages que vous souhaitez, les modules à activer (prise de rendez-vous, newsletter, analytics), l'hébergement cible. À la fin de la conversation, votre projet est configuré et prêt à recevoir vos premiers contenus.

Concrètement, voici ce que vous récupérez après le wizard :

• Un site statique prêt à déployer, avec une page d'accueil, un blog, les mentions légales et la politique de confidentialité.
• Un environnement de staging protégé par mot de passe, généré automatiquement depuis un secret GitHub.
• Un déploiement en production sur la branche main, orchestré par GitHub Actions et SFTP.
• Des en-têtes HTTP durcis (HSTS, CSP stricte, anti-clickjacking), pré-configurés dans un .htaccess.
• Un fichier CLAUDE.md à la racine du projet, qui documente vos règles non négociables pour toute future session avec l'assistant.

Les partis pris techniques, assumés

Ce starter fait des choix forts qui ne conviennent pas à tous les projets. Je les expose en détail dès le départ pour que vous sachiez exactement ce qui vous attend, et que vous puissiez décider si l'outil correspond à votre besoin ou s'il vaut mieux regarder ailleurs.

Pas de CMS

Le starter produit des sites statiques : HTML, CSS et JavaScript vanille. Pas de base de données, pas de panneau d'administration pour éditer le contenu sans toucher au code. C'est un choix assumé, pas une limitation technique. Si votre équipe publie régulièrement du contenu sans passer par un développeur, WordPress ou Webflow restent des outils plus adaptés. Pour un site de consultant, une landing page SaaS ou un portfolio qui évolue quelques fois par mois, ce n'est pas nécessaire.

Pas de framework

Pas de Next.js, pas d'Astro, pas de Vite. Ce choix repose sur trois constats tirés de projets réels. D'abord, la complexité d'un framework n'est pas justifiée pour un site marketing d'une dizaine de pages. Ensuite, un site sans build est un site qui ne casse pas trois ans plus tard quand les dépendances deviennent incompatibles entre elles. Enfin, Claude Code manipule du HTML vanille sans se tromper, là où il commet parfois des erreurs subtiles dans un projet TypeScript complexe. Quand l'outil et le matériau parlent la même langue, le rendu est plus propre.

PHP 8 et SFTP

Le starter cible les hébergements mutualisés à 3 à 5 € par mois, comme OVH, Infomaniak, o2switch ou LWS. C'est l'hébergement le moins sexy mais le plus fiable du monde, et le plus économique pour un site qui ne reçoit pas des millions de visiteurs par jour. Les formulaires et les intégrations tierces (Brevo, Cal.com, Mailchimp) passent par de petits scripts PHP côté serveur, ce qui permet de garder les clés API hors du navigateur et de conserver une surface d'attaque minimale.

La marque avant le code

Le starter ne produit pas un beau site tout seul. Il fournit un squelette fonctionnel, avec les bonnes briques techniques et une structure propre. Mais un site qualitatif demande une identité de marque définie en amont : typographie, palette, logo, photographies, textes, direction éditoriale. Le README du dépôt insiste lourdement sur ce point. Si vous sautez l'étape marque, le rendu restera générique quel que soit l'outil utilisé. Le starter accélère la partie technique, pas la réflexion stratégique qui la précède.

Claude Code comme webmaster senior

C'est la partie qui change le plus la manière de travailler. Le starter embarque dix slash commands qui transforment Claude Code en un membre d'équipe qui connaît votre site par coeur. Pas un assistant générique qui redécouvre le projet à chaque session, mais un collaborateur qui lit systématiquement votre design system, vos conventions et votre ton de voix avant de proposer quoi que ce soit. C'est un peu comme embaucher un webmaster senior qui a lu votre documentation avant de rejoindre la réunion.

Chacune de ces commandes couvre un moment précis du cycle de vie du site :

• /start-new-site : un wizard complet pour démarrer un nouveau projet depuis zéro.
• /adopt-existing-site : même logique, adaptée à la reprise d'un site déjà en place.
• /brand-setup : la commande qui crée ou met à jour le document de marque lu par toutes les autres.
• /new-page : Claude lit le design system et les composants existants, puis construit la nouvelle page en réutilisant ce qui existe déjà dans le projet.
• /new-section : ajoute une section sur une page existante sans casser la cohérence visuelle.
• /new-blog-article : un article rédigé dans votre ton de voix, avec une illustration générée par Gemini à partir d'un prompt cohérent avec votre palette, un podcast deux voix en TTS style NotebookLM, et le sitemap mis à jour automatiquement.
• /deploy : la discipline staging vers production. La commande refuse de pousser sur main sans confirmation que staging a été testé.
• /audit-brand : vérifie que le site respecte les tokens, les règles éditoriales, le SEO et l'accessibilité.
• /setup-integration : configure une intégration tierce (Cal.com, Calendly, Brevo, Mailchimp, GA4, Plausible, Umami).
• /setup-staging-auth : (re)génère la protection par mot de passe du staging.

La boucle de travail la plus productive, celle que j'utilise tous les jours, tient en quelques étapes : je déploie sur staging, je lance Google Lighthouse dans les DevTools Chrome, je copie les opportunités et diagnostics, et je les colle à Claude en lui demandant de corriger ce qui peut l'être. Il propose, je valide, on re-teste. Performance, SEO, accessibilité, best practices : tout peut être traité en une après-midi, là où il aurait fallu plusieurs jours sans cette automatisation.

La sécurité par défaut

C'est ce que j'aurais aimé avoir il y a six mois. Le starter embarque par défaut, sans configuration supplémentaire, l'essentiel des protections qu'on oublie trop souvent quand on démarre un nouveau projet sous la pression du lancement.

Côté en-têtes HTTP, un .htaccess préparé active HSTS, une CSP stricte, la protection anti-clickjacking, une Permissions-Policy restrictive et un COOP. Côté staging, la protection par .htpasswd est générée automatiquement par le workflow GitHub à partir de secrets qui ne sont jamais commités dans le dépôt. Côté secrets API, un loader PHP dédié lit un fichier .env côté serveur, jamais commité, jamais lu par Claude, jamais exposé au navigateur.

Le starter embarque aussi des pre-commit hooks qui rappellent de relire les diffs avant de pousser, en particulier quand des fichiers sensibles sont modifiés. Et la documentation consacre un chapitre entier aux pièges spécifiques au développement avec IA : ne jamais coller une vraie clé dans un prompt, ne pas accorder de permissions larges à une skill inconnue, refuser les corrections CSP paresseuses que Claude propose parfois par facilité.

Sur les données personnelles traitées par Claude, le principe est simple. Un site marketing statique n'a rien de sensible dans son code. Les formulaires passent par des scripts PHP côté serveur qui ne sont pas lus par l'assistant. Les secrets ne sont jamais présents dans le dépôt. Le .gitignore exclut par défaut tout fichier .env ou .credentials, et le document CLAUDE.md rappelle explicitement ces règles à chaque session.

À qui s'adresse ce starter

Le starter a été pensé pour les consultants indépendants, les freelances et les petites équipes qui ont essayé WordPress, Webflow ou Squarespace, et qui ont senti les limites : lenteur, bloat, factures mensuelles qui s'accumulent, plugins qui cassent au pire moment. Si vous êtes déjà à l'aise avec l'idée d'un assistant IA en ligne de commande, ou prêt à vous y mettre, vous êtes exactement au bon endroit.

Il ne conviendra pas à tout le monde. Si vous voulez glisser-déposer des blocs dans un éditeur visuel, si vous refusez de toucher à Git, si vous avez besoin d'un back office pour qu'une équipe non technique publie sans passer par un développeur, ou si vous voulez un site e-commerce complet avec catalogue produit et paiement, d'autres outils sont tout simplement meilleurs pour ces cas. Shopify pour l'e-commerce, Webflow pour le no-code avancé, WordPress pour les sites à forte volumétrie éditoriale. Je les recommande sans arrière-pensée quand c'est pertinent.

Comment démarrer

Une fois Git et Claude Code installés sur votre machine, une seule commande suffit pour partir.

gh repo create mon-site --template Littlpinguin/claude-site-starter --public --clone
cd mon-site
claude

Puis dans Claude Code, vous tapez /start-new-site. Le wizard prend la main et la conversation démarre.

Un abonnement Claude Max (environ 100 € par mois) est recommandé pour cette méthode. Claude est utilisé intensivement : brainstorming, planification, implémentation, audit, itérations Lighthouse. Un plan Pro atteint ses limites en une après-midi sur un projet réel. À l'inverse d'un WordPress où la facture mensuelle s'accumule en hébergement et plugins premium, ici l'essentiel du coût est concentré sur la phase de construction, puis décline fortement une fois le site en production.

La promesse, et ce qu'elle n'est pas

La promesse n'est pas « un site en cinq minutes ». C'est autre chose : un site qualitatif si vous avez fait le travail de marque en amont, un code qui reste sous votre contrôle, une facture d'hébergement à 5 € par mois, et un assistant qui devient de plus en plus pertinent à mesure que vous remplissez son contexte. C'est un outil pour les gens qui veulent rester propriétaires de leur site et de leur méthode, plutôt que dépendre d'une plateforme propriétaire qui peut changer de stratégie du jour au lendemain.

Le dépôt est public, mais ce n'est pas un projet communautaire. Je n'accepte pas de pull requests, je ne monitore pas les issues, je ne tiens pas de roadmap publique. C'est un starter personnel que je rends visible, dans le même esprit que les skills et plugins que j'utilise moi-même au quotidien. Forkez-le, adaptez-le, utilisez-le pour vos clients si vous voulez : il est fait pour ça.

Pour aller plus loin sur la méthode elle-même, voir comment j'ai construit jessem.fr avec Claude Code. Et pour le reste de l'outillage IA que j'utilise, ma sélection 2026 est ici.