Construire un site WordPress, de bout en bout
Pourquoi cette méthode existe
Un agent conçoit mal quand sa boucle de rétroaction est lente. Positionner une page dans WordPress coûte trois à cinq minutes par itération — composer, enregistrer, sérialiser, purger, recharger, regarder. En HTML local avec un serveur de développement, la même boucle prend cinq secondes, et la qualité du design suit le nombre d'itérations bien plus fidèlement que n'importe quelle instruction esthétique.
La seconde moitié est une contrainte de livraison : le client modifie le site sans écrire de code. C'est ce qui interdit les blocs HTML bruts et le contenu appartenant aux templates — et cela contraint la conversion, jamais le dessin.
En une ligne : le design vit dans les fichiers, pas dans le contenu des pages. WordPress reçoit un thème fini, pas des instructions de mise en page.
Les deux règles qui viennent en premier
Règle 0 — dessiner la phase 2 comme si la phase 4 n'existait pas. Aucune contrainte de conversion n'entre dans la maquette. Anticiper « pas de core/html » en dessinant supprime silencieusement la profondeur, les chevauchements et l'objet central ; le résultat se convertit parfaitement et ne plaît à personne.
Règle 0′ — aucune liberté esthétique ne quitte la référence. Avec une référence, un modèle dérive vers son propre style maison : beige chaud là où la référence est blanc froid, une police sérif caractérielle là où elle a une sans-sérif, un accent qu'elle n'a jamais eu. Sept invariants de registre sont lus sur la référence et reproduits ; en changer un est une question pour le client, posée avant de coder. Les invariants, la porte du registre et le script de mesure se trouvent dans references/register.md.
Les dix règles
Chacune vient d'une erreur qui a réellement été commise.
- Exiger une référence visuelle. Sans elle, la production régresse vers le centre statistique : police neutre, dégradé violet, page blanche.
- Pas de maquette sans photos réelles. Une boîte grise ressemble à une image cassée.
- Rien n'arrive en production WordPress avant deux approbations du client : la maquette, puis le plan de déploiement.
- La page d'accueil est une page, jamais un template —
front-page.htmlcontient l'en-tête,post-content, le pied de page. - Zéro bloc
core/html. Composer avec des groupes, titres, paragraphes, images. - Les images vivent dans la médiathèque, avec un
idsur chaquecore/image. - Les variantes interactives sont toutes dans la page ; le script bascule une classe.
- Aucun thème tiers sous le design.
- Valider dans l'éditeur, pas en front-end — une page peut s'afficher parfaitement et être inutilisable dans Gutenberg.
- La fidélité pixel est mesurée, pas estimée : styles calculés et géométrie, sélecteur par sélecteur.
Phases et leurs portes
Ne commencez pas une phase tant que la porte précédente n'est pas franchie.
| Phase | Qui | Porte de sortie |
|---|---|---|
| 0 · Espace de travail | Agent | Projet dans le dossier de travail de l'utilisateur, accès en écriture testé |
| 1 · Brief | Client | Analyse de la référence, palette et typographie issues de la référence, liste « ce que j'ajoute » |
| 2 · Maquette | Itératif | Page d'accueil en HTML, porte du registre passée, approbation du client |
| 3 · Ensemble de pages | Agent | Chaque page assemblée à partir d'une seule source d'en-tête/pied |
| 4 · Thème à blocs + staging | Agent | Thème construit ; WordPress local configuré par des outils reproductibles ; portes 1 à 5 passées en staging |
| 5 · Déploiement | Agent, après approbation du plan par le client | Sauvegarde hors de la racine web, puis les mêmes outils exécutés en production |
| 6 · Acceptation | Agent | Portes 1 à 5 passées en production, ou retour en phase 4 |
Phases 0 à 3 et plan de déploiement : references/phases.md. Conversion HTML vers blocs : references/block-conversion.md. Les cinq portes avec leur code : references/acceptance.md.
Le staging est local, et chaque changement est un outil. Le contenu et la configuration sont écrits par des scripts PHP idempotents (tools/install-site.php, tools/configure-*.php) exécutés avec la CLI PHP contre une copie locale, jamais saisis dans wp-admin. Les mêmes scripts sont rejoués en production lors du déploiement, et en rejouer un deux fois ne change rien — c'est vérifié, pas supposé.
Choisir la branche
La méthode est la même pour chaque site ; ce qui change, c'est la phase 4 et au-delà.
| Site | Ce qui change | À lire |
|---|---|---|
| Vitrine | Pages, formulaires (Contact Form 7 + Flamingo), pages légales | ce fichier et les phases |
| Boutique | Templates de blocs WooCommerce, import de catalogue, filtres de produits, blocs panier/validation, consentement, paiements, newsletter, confirmation de commande | references/store.md |
| Application web | Types de publication personnalisés, rôles, REST, blocs dynamiques, flux de compte — la maquette pilote toujours chaque écran public | references/web-app.md |
references/store.md est mesuré sur une construction réelle (WooCommerce 11.2.2, validation en blocs, thème à blocs). references/web-app.md ne l'est pas : il le dit, et redirige vers les compétences qui le sont.
Les faits appartiennent au client
La maquette invente le contenu rédactionnel à partir du brief ; elle n'invente jamais les faits. Avis, notes, nombre de clients, logos de presse, délais de livraison, prix des services, clauses juridiques et identité de l'entreprise restent sous forme de placeholders visibles — à compléter pour ce que seul le client peut fournir, à vérifier pour ce qui a été lu sur l'ancien site et peut être obsolète. Un avis inventé franchit toutes les portes et est le seul défaut qui peut coûter cher au client sur le plan légal.
Dans les commentaires, messages de commit et rapports, indiquez quelles affirmations ont été mesurées (avec la date) et lesquelles ont été lues (avec la source).
Outillage
| Fichier | Quand |
|---|---|
scripts/serve.mjs | Phase 2 — serveur statique sans dépendance, essaie le port suivant lorsqu'un est pris |
scripts/assemble.mjs | Phase 3 — construit chaque page à partir d'un <head>, d'un en-tête et d'un pied de page sources |
scripts/fetch-fonts.mjs | Phase 4 — auto-héberge Google Fonts : aucune requête vers Google depuis les visiteurs, rien à déclarer sous le RGPD |
scripts/novamira.mjs | Phase 5 — appelle une capacité Novamira via HTTP sans enregistrer de serveur MCP |
assets/theme-skeleton/ | Phase 4 — thème à blocs minimal : theme.json avec blockGap: 0px, editor.css, polices dans l'éditeur |
Références
| Fichier | Lisez-le |
|---|---|
references/register.md | Avant la phase 1, et avant de montrer toute maquette |
references/phases.md | Phases 0 à 3, puis la séquence de déploiement de la phase 5 |
references/block-conversion.md | Pendant la phase 4, à chaque fois |
references/acceptance.md | Phases 4 et 6 — les cinq portes et l'hygiène de mesure |
references/store.md | Tout site WooCommerce |
references/web-app.md | Adhésion, réservation, tableaux de bord, tout ce qui implique des utilisateurs connectés travaillant |
references/pitfalls.md | Dès qu'un symptôme vous surprend |
Compétences connexes : wp-theme-block-fse pour theme.json et templates, wp-design-system pour les tokens, wp-woocommerce pour les hooks et HPOS, wp-deploy pour les migrations, wp-plugin-architecture et wp-blocks-gutenberg pour le code applicatif, wp-accessibility et wp-performance avant l'acceptation.