HTML d'abord, framework ensuite : concevoir en live avec sa cliente

J'ai conçu chaque page du site d'Eva en HTML/CSS pur avant de toucher au framework. Pas par nostalgie, par méthode. Une page HTML, Eva l'ouvre dans son navigateur et voit exactement le rendu final, sans rien installer. On itère ensemble, en direct, jusqu'à ce que ce soit juste. Astro vient après, quand il n'y a plus rien à décider côté design.

Je suis Jimmy. J'ai conçu et développé entièrement le nouveau site de La Puissance de l'Éveil. Après avoir raconté comment j'ai conçu pour une femme en renaissance, pas pour un moteur de recherche, voici le workflow qui a permis à Eva de rester dans la boucle du début à la fin.

Le problème : une cliente qui ne code pas

Eva n'a aucune notion technique. Pas de terminal, pas de npm, pas de Claude Code. Elle est coach holistique, pas développeuse, et c'est très bien ainsi.

Le piège classique, dans ce cas, c'est de concevoir seul dans son coin puis de montrer un résultat déjà figé. La cliente valide ou refuse un bloc, mais elle ne participe pas à la construction. Elle subit des allers-retours par captures d'écran, elle décrit ce qu'elle voudrait avec des mots, et le dev traduit comme il peut.

Sur un site aussi personnel que le sien, ça ne pouvait pas marcher. La direction créative se décide à deux, en regardant le même écran, au même moment. Il me fallait un support que je puisse modifier en direct et qu'elle puisse voir sans effort.

La règle : le HTML d'abord

Un fichier .html, c'est le support le plus simple du monde. On double-clique, ça s'ouvre dans le navigateur, ça montre le rendu final. Zéro installation, zéro dépendance, zéro écran d'erreur.

Concrètement, une session de travail avec Eva ressemble à ça. Elle arrive avec ses idées, ses textes, ses photos. On part d'une page vierge basée sur le gabarit déjà posé. On construit ensemble, section par section, et elle voit chaque changement apparaître en direct. On ajuste un titre, on déplace un bloc, on essaie l'or sur un mot plutôt qu'un autre. Quand elle dit « c'est ça », c'est validé.

Pourquoi pas Astro tout de suite

La question est légitime : le site final tourne sous Astro, pourquoi ne pas commencer directement dedans ?

Parce que la phase créative et la phase technique ne demandent pas les mêmes conditions. Chercher une direction artistique, c'est essayer, rater, recommencer vite. Un framework ajoute des étapes qui n'aident pas à ce moment-là : lancer npm run dev, gérer le hot reload, croiser une erreur TypeScript pendant qu'on hésite entre deux tailles de titre. Autant de micro-frictions qui cassent le rythme d'une session à deux.

Le HTML vanilla supprime tout ça. On reste sur le seul sujet qui compte en session : est-ce que la page dit ce qu'Eva veut dire, est-ce qu'elle la fait ressentir. Le reste, l'optimisation, la structure, le SEO, ce sont mes problèmes, pas les siens, et ils attendent très bien la fin de la session.

Le portage : quasi du copier-coller

Voici la bonne surprise, et la raison pour laquelle ce workflow tient : Astro accepte le HTML brut. Coller le <body> d'une page finalisée dans un fichier .astro, ça fonctionne presque tel quel. Le portage n'est donc pas une réécriture, c'est une mise en ordre.

Le vrai travail se résume à cinq gestes, toujours les mêmes :

Extraire le <head> dans un Layout.astro, une fois pour toutes, au lieu de le répéter sur chaque page.
Isoler ce qui se répète (la nav, le footer) dans des composants .astro réutilisables.
Remplacer les textes en dur par des variables, du frontmatter, ou du contenu piloté par le CMS.
Remplacer les <img> par le composant <Image> d'astro:assets, qui génère l'AVIF et le WebP à la build.
Ajouter le frontmatter SEO : title, description, balises Open Graph.

Rien de tout ça ne touche au rendu. Le visuel validé avec Eva reste identique au pixel près, ce qui est exactement le but : elle a validé une page, elle retrouve cette page en ligne, sans surprise.

Ce que ce workflow protège vraiment

Au-delà de la technique, ce découpage protège la relation avec la cliente. Eva n'a jamais eu à comprendre un outil, à installer quoi que ce soit, ni à faire confiance à une maquette abstraite. Elle a vu son site se construire sous ses yeux, page après page, dans le seul environnement qu'elle maîtrise déjà : son navigateur.

Et de mon côté, la validation arrive plus vite. Une décision prise en direct, devant le vrai rendu, ne se rediscute pas trois jours plus tard par message. On tranche une fois, ensemble, et on avance.

La suite

Le HTML validé, restait à le transformer en un vrai site vivant : hébergé, rapide, et surtout modifiable par Eva sans jamais m'appeler pour changer une virgule.

C'est l'objet du prochain article : Astro, Cloudflare et un CMS que la cliente peut piloter.

Envie de sauter directement à la fin de la série ? Le bilan complet, ce que j'ai appris en passant de Wix à un site sur-mesure.