Un site sous constructeur de page (page builder) depuis 5 ans, des performances dégradées, une maintenance de plus en plus lourde. Le client ne voulait pas tout casser — il voulait le même design, sur des bases plus saines. C’est exactement le cas d’usage où la modularisation du design system FSE fait toute la différence.
Migrer sans reconstruire
La tentation, dans ce genre de situation, est de tout recommencer à zéro. Nouveau design, nouvelle architecture, nouveau contenu. C’est rassurant sur le papier — mais c’est souvent la mauvaise réponse.
Quand le design fonctionne et que les contenus sont solides, le problème n’est pas ce qui est visible. C’est ce qui se passe en dessous : un constructeur de page qui empile les modules, qui charge des dizaines de ressources inutiles, qui rend chaque modification risquée.
La migration vers un thème FSE (Full Site Editing) natif répond à ce problème sans tout effacer. On conserve le design, on change la fondation.
Le design system comme colonne vertébrale
Un thème FSE natif repose sur un design system défini dans theme.json. Ce fichier centralise les variables globales du thème : couleurs, typographie, espacements, styles de boutons.
Mais un design system, ça ne se pilote pas en bloc. Sur un projet complexe, la moindre modification en cascade peut devenir incontrôlable. La clé, c’est la fragmentation : chaque domaine est traité séparément, avec ses propres règles et ses propres procédures.
Concrètement, ça donne :
- Les couleurs dans leur domaine — palette définie une fois, réutilisée partout
- Les espacements dans le leur — valeurs calculées dynamiquement avec
calc(), cohérentes à toutes les tailles d’écran - La typographie séparée — tailles fluides qui s’adaptent au viewport sans breakpoint fixe
- Les styles de boutons à part — variantes isolées, modifiables sans risque
Chaque domaine devient une procédure documentée. Une règle claire, reproductible d’un projet à l’autre.
Claude Code comme partenaire de domaine
C’est là qu’intervient Claude Code. L’idée n’est pas d’utiliser un agent généraliste qui génère du code en vrac. C’est d’associer chaque discipline technique à un skill dédié — une instruction précise que Claude Code connaît et sait répéter.
Dans ma pratique, les skills sont organisés par technologie et par responsabilité :
- CSS — standards d’indentation, variables FSE, media queries
- JavaScript — conventions ESLint, JSDoc, patterns Gutenberg
- PHP — namespaces PSR-4, sécurité, phpDoc, performance
- FSE — gotchas de l’éditeur de site, Block Bindings, surcharges de templates
- Patterns — format des fichiers, comportement du cache, styles globaux
- Standard — orchestrateur qui détecte les fichiers modifiés et appelle les bons skills
- Security — audit de fin de session sur PHP et JavaScript
Chaque skill opère dans son périmètre sans empiéter sur les autres. Claude Code peut modifier du CSS sans risquer de casser la logique PHP. Travailler sur un pattern sans toucher aux conventions JavaScript. La précision vient du découpage — pas de l’outil lui-même.
Pour les tâches plus complexes — générer un bloc complet à partir d’une description — un agent s’appuie sur la bibliothèque de blocs existante et applique les standards du projet. Le design system devient son référentiel.
Des variables au chargement : la performance par construction
Les variables du design system ne servent pas qu’à maintenir la cohérence visuelle. Elles deviennent la base de tout le reste : composants, feuilles de style sur mesure, blocs JavaScript ou PHP quand l’éditeur ne suffit pas.
Et le chargement suit la même logique de fragmentation. Chaque feuille de style ne se charge que si le bloc correspondant est présent sur la page. Idem pour les scripts JavaScript associés aux blocs sur mesure. Pas de ressource inutile — ce qui était impossible avec un constructeur de page chargeant tout en permanence.
Pourquoi un générateur tout-en-un ne tient pas
La tentation est forte de vouloir un outil unique qui gère tout : design system, blocs, styles, contenu. En pratique, sur un site complexe, ce type d’approche est trop couplée pour être maintenable.
Quand tout dépend de tout, la moindre modification devient risquée. Et quand Claude Code intervient dans un système trop couplé, il perd le fil — les domaines se chevauchent, les variables entrent en conflit.
La modularisation résout ce problème à la racine. Chaque partie du système est indépendante, auditable, remplaçable. Le tout tient dans le temps — et il évolue proprement.
Conclusion
Migrer un site page builder vers FSE, ce n’est pas refaire un site. C’est lui donner une architecture qui peut évoluer sans s’effondrer.
La modularisation du design system est la condition pour que Claude Code soit réellement utile sur des projets complexes. Sans elle, l’outil amplifie le chaos au lieu de le réduire. Avec elle, chaque intervention est précise, documentée, reproductible.
Si tu travailles sur ce type de migration ou si tu veux structurer ton workflow FSE avec Claude Code, je suis disponible pour en discuter : contact
Article publié initialement sur LinkedIn
