Vibecoder son site avec Claude : retour d'expérience complet

Pour la première version de jimsagnier.com, j'ai passé environ 20 heures de travail sur dix jours. Quinze heures à préparer le projet, cinq à le mettre en code avec Claude Code. Le temps de préparation comprenait le design, les textes, le tone of voice et les règles du projet.

Ce retour raconte cette première mise en place. Le site a évolué depuis, mais la répartition du travail m'intéresse toujours : l'agent a accéléré le code, et j'ai passé beaucoup de temps à décider ce que je voulais lui faire construire.

Ce qu'il y avait au premier lancement

La première version avait quatre pages : accueil, journal, projets et à propos. Le journal contenait un article, celui-ci. La stack était déjà celle que j'utilise ici : Astro 6, TypeScript strict, CSS artisanal, Markdoc pour les articles et Keystatic pour les éditer.

Le site tournait sur Cloudflare Pages. Les balises de partage, les adresses canoniques, les fils d'Ariane et les données structurées WebSite et Person étaient en place. Le panel Keystatic me permettait de travailler sur le contenu en local.

Je ne donne pas de score Lighthouse pour cette version : je n'ai pas la capture initiale dans les fichiers du projet. Sans date ni conditions de mesure, ce serait juste un chiffre difficile à interpréter.

Comment je travaille avec Claude Code

Pour ce projet, le vibecoding a consisté à décrire ce que je voulais, laisser l'agent modifier les fichiers, puis regarder le résultat et demander des corrections. Claude Code pouvait lire le projet, lancer des commandes et reprendre une erreur sans que je copie-colle du code entre plusieurs outils.

J'avais testé Cursor, Copilot et ChatGPT. J'ai retenu Claude Code pour cette boucle de travail et pour deux possibilités que j'utilisais déjà ailleurs : les skills et le MCP.

Un skill décrit une méthode à suivre pour une tâche. Un agent peut prendre en charge un travail délimité, comme analyser une page ou préparer une variante de design. J'ai détaillé comment j'organise mes skills et mes agents dans un autre article.

Le MCP permet de connecter l'assistant à des outils externes. Dans mon cas, il me donnait notamment accès à mon Second Cerveau Obsidian, où j'avais accumulé environ 600 notes sur dix ans. Ça m'aidait à retrouver des décisions et de la documentation sans repartir de zéro à chaque conversation.

Ces possibilités comptent pour mon usage quotidien. Pour quelqu'un qui veut seulement quelques pages, elles ne sont pas toutes nécessaires.

Avant Astro, j'avais préparé les pages

J'ai commencé par la direction artistique. Plusieurs pistes générées avec Google Stitch, des essais en HTML statique, puis cinq maquettes : accueil, article, journal, projets et à propos.

La direction retenue à ce moment-là s'appelait « Galerie Curatée v2 » : un fond clair, une mise en page éditoriale et du cyan pour les accents. C'est le point de départ du site, pas sa direction artistique actuelle.

J'avais aussi préparé les photos, optimisées en WebP sous 70 Ko, les logos détourés, les favicons et les variables CSS de la palette. Quand j'ai demandé à Claude de porter les maquettes dans Astro, ces choix étaient donc déjà visibles dans des fichiers.

Ce travail me servait de référence pendant le portage. Je pouvais comparer une page au rendu préparé, plutôt que juger chaque proposition sans savoir ce que je cherchais.

Sur le site d'Eva, j'ai repris cette façon de travailler : concevoir en HTML avant de passer au framework. Elle permettait aussi de montrer les pages dans un navigateur à une cliente qui ne code pas.

Les textes avaient besoin de leur propre préparation

Pour ma voix, je suis parti de huit calls Fireflies, soit environ 30 000 mots transcrits. J'ai demandé à un agent Claude Opus d'en extraire les formulations récurrentes, le rythme et les façons d'expliquer.

Le résultat était un document avec une voix de fond et plusieurs modulations : expliquer, répondre brièvement, raconter un cas, montrer l'expérience ou conclure. Il donnait un point de départ à la rédaction. Il ne supprimait pas la relecture.

J'ai appliqué une démarche comparable au site d'Eva pour codifier une voix sans la lisser, à partir de ses textes et de son brief.

Sur mon site, le copywriting est resté la partie la plus longue. Un texte peut être propre, bien structuré, et ne pas dire les choses comme je les dirais. Il faut alors revenir sur la phrase, parfois sur l'idée derrière. Un guide de voix aide à cadrer ce travail ; il ne garantit pas que le premier jet me ressemble.

Le fichier CLAUDE.md pour garder le contexte

J'avais écrit les règles du projet dans CLAUDE.md : qui je suis, l'angle du site, la stack, la palette et ce que l'agent peut faire. Ce fichier est chargé au début des sessions Claude Code.

Ça évite de réexpliquer tout le projet. Les décisions restent dans un fichier que je peux relire et corriger. Au moment de cette première version, sa préparation m'avait pris environ deux heures.

Le brief visuel, les maquettes et les règles écrites répondaient à des questions différentes. Les maquettes montraient le rendu attendu. Le guide de voix cadrait la rédaction. CLAUDE.md donnait le contexte de travail et les consignes d'opération.

Ce qui est entré dans les cinq heures de code

Le squelette Astro et le dépôt GitHub existaient déjà, mais il n'y avait encore ni page, ni composant, ni layout. Les maquettes, la palette, les photos, les favicons et les règles étaient prêts.

Les deux premières heures ont servi à poser la structure Astro : les layouts, les composants communs, les collections de contenu et les métadonnées.

Le projet utilisait les content collections pour valider les champs des articles, avec un schéma TypeScript. Le layout commun gérait les titres, les descriptions, les adresses canoniques, Open Graph et les données structurées. C'était important pour moi de poser cette structure avant de commencer à publier.

L'heure suivante a servi à installer Keystatic et à définir les champs éditables. Dans la configuration locale de ce site, Keystatic travaille sur les fichiers du dépôt : les articles sont enregistrés dans src/content/articles/ et le panel s'ouvre sur /keystatic quand le serveur de développement tourne.

Markdoc m'a permis d'ajouter les blocs Conseil, MonAvis, EnPratique, FAQ, Embed et RawHTML. La FAQ produit aussi un JSON-LD à partir des questions et réponses affichées. Le balisage suit le contenu du composant ; il reste à vérifier que ce contenu est utile et juste.

Entre la troisième et la quatrième heure, les maquettes ont été portées dans les pages Astro. La navigation, le footer, les sections de l'accueil, le journal, les projets et la page à propos ont pris leur place dans une structure commune.

À la cinquième heure, quand la home s'est affichée avec les maquettes portées, j'étais bluffé par la vitesse à laquelle elle avait pris forme. J'avais préparé les éléments séparément ; là, je pouvais enfin naviguer dans le site.

Il y a aussi eu des corrections. Un cache Vite désynchronisé m'a fait croire pendant cinq minutes que le CSS de la home était cassé. Dans ce cas précis, supprimer les caches .astro et node_modules/.vite a réglé le problème. C'est le genre d'incident qui rappelle de regarder ce qui tourne réellement avant de reprendre tout le CSS.

Pourquoi cette stack convenait à ce site

Le site est principalement composé de textes, de photos et de pages de projets. Je voulais servir ces pages en HTML, garder la main sur le CSS et limiter les dépendances.

Astro permet de rendre la majorité d'une page en HTML et d'ajouter du JavaScript aux composants qui en ont besoin. Pour ce projet, je n'avais pas besoin de construire toute la navigation comme une application côté navigateur.

Keystatic me permettait d'éditer les articles sans mettre en place une base de données supplémentaire pour le contenu. Markdoc reliait les textes aux composants que j'avais préparés.

Cloudflare Pages prenait en charge l'hébergement et le déploiement depuis GitHub. Le site se reconstruisait à partir du dépôt. Je pouvais donc garder le code et le contenu dans le même workflow.

Ce sont des choix adaptés à ma façon de travailler. Si plusieurs personnes non techniques devaient publier tous les jours, je regarderais aussi la facilité de l'éditeur et la manière de gérer leurs accès. Mon besoin personnel ne suffit pas à choisir leur outil.

Ce que ça change pour mon travail de lead acquisition

Je m'occupe de pages, de SEO, de contenu et d'outils au quotidien. Pouvoir passer d'une idée à un prototype sans attendre une intégration complète m'aide à tester une structure ou un widget.

Sur ce projet, j'avais préparé l'angle, les pages et les éléments visuels. Claude m'a aidé à les mettre en code. La préparation représente environ trois quarts des vingt heures, mais je ne prends pas ce ratio comme une règle pour tous les projets. Une reprise de code existant, un outil métier ou un site édité par une équipe poseront d'autres questions.

L'IA m'aide aussi à produire des premiers jets et à préparer le contenu pour le CMS. La relecture reste nécessaire, notamment pour vérifier les faits, la voix et les liens. C'est une partie du travail que la vitesse de génération ne fait pas disparaître.

Les limites que je garde en tête

D'abord, un rendu fonctionnel ne suffit pas à valider un design. Dans ce projet, les maquettes ont servi à prendre les décisions visuelles avant le portage.

Ensuite, je dois pouvoir comprendre les changements proposés. Pas forcément écrire chaque ligne moi-même, mais regarder les fichiers modifiés, lire les erreurs et vérifier le résultat. Le fait qu'une page s'affiche ne prouve pas que tout le reste est correct.

Enfin, l'outil ne choisit pas à ma place ce que ce site doit raconter. Le positionnement et les sujets étaient un travail préalable. Ils continuent à demander des décisions quand le contenu évolue.

Le coût dans mon cas

Au moment de cette première version, je comptais environ 12 dollars par an pour le domaine et un abonnement Claude Code à 100 euros par mois. Ce sont les montants de mon récit de départ, pas une grille tarifaire actuelle.

L'abonnement servait déjà à mes projets professionnels et personnels : refonte, contenu, CRM, automatisations et coups de main à des indépendants. Je n'avais donc pas pris cet abonnement uniquement pour construire mon site.

C'est pour cette raison que je ramenais le coût supplémentaire du site à environ un euro par mois pour le domaine. Si tu prends un abonnement uniquement pour faire quelques pages, le calcul sera différent. Regarde d'abord ce que tu comptes en faire et les outils dont tu disposes déjà.

Ce que je retiens de cette première version

J'avais un site en production, un éditeur local pour les articles et une structure que je pouvais reprendre. Les cinq heures de mise en code avaient été possibles avec les maquettes, les textes et les règles préparés avant.

Je garderais cette préparation sur un prochain projet. Et je prévoirais du temps pour les textes : c'est le point sur lequel j'ai le plus besoin de revenir pour que le site me ressemble.

Je documente les évolutions dans le journal. Pour le contexte et les projets sur lesquels je travaille, je raconte aussi mon parcours.