Personnaliser la bibliothèque de composants
- 1.Pourquoi la séquence compte plus que l'ampleur
- 2.Niveau 1 : les tokens de theming, source unique de vérité pour les valeurs de marque
- 3.Niveau 2 : les surcharges de composants, ciblées, justifiées, documentées
- 4.Niveau 3 : les garde-fous de l'éditeur, la liberté avec un système
- 5.Le chemin comme séquence
- 6.Ce qui casse quand on saute le chemin
- 7.Pour aller plus loin
Vous avez choisi un ensemble de composants métier prêt à l'emploi parce qu'il fait gagner du temps. C'est le bon choix. Le Laioutr B2C Growth-Kit fournit des composants prêts au lancement pour les listes de produits, les barres de filtres, les sections hero, les tiroirs de panier et les parcours de checkout : testés, performants et conformes WCAG 3.0 dès le départ. Mais dès votre première vraie revue de marque avec un client, une question surgit : jusqu'où peut-on personnaliser sans casser le design system en dessous ?
La réponse tient au chemin de personnalisation. Ni « on surcharge tout », ni « merci de ne rien toucher ». Cet article vous fait parcourir les trois niveaux où la personnalisation doit avoir lieu, pourquoi la séquence compte plus que l'ampleur, et où se cachent les vrais anti-patterns.
Pourquoi la séquence compte plus que l'ampleur
Le schéma le plus courant dans les projets UX qui utilisent des ensembles de composants prêts à l'emploi : les équipes commencent au mauvais niveau. Les surcharges CSS directes arrivent en premier, les tokens n'arrivent jamais. Six semaines plus tard, la carte produit a une couleur de survol différente de celle du bouton panier, le breakpoint du header mobile est décalé de deux pixels, et personne ne sait quelle surcharge a cassé quoi.
Le chemin de personnalisation sur l'architecture Composable Visual Page Builder suit trois niveaux clairs. Parcourez-les dans le bon ordre et vous obtenez un storefront cohérent, même après six mois de changements itératifs.
Niveau 1 : les tokens de theming, source unique de vérité pour les valeurs de marque
Les tokens de theming sont le niveau de personnalisation le plus bas et, en même temps, le plus puissant. Ils gouvernent les couleurs de marque, l'échelle typographique, la grille d'espacement, les valeurs de border-radius et les définitions d'ombres. Définissez-les une fois, et chaque composant qui référence ces tokens reprend les changements automatiquement.
Un workflow de tokens concret :
Commencez par l'ensemble des tokens de couleur. Votre marque a une couleur primaire, une secondaire et une couleur d'accent. Mappez-les sur des rôles sémantiques : color.brand.primary, color.brand.secondary, color.feedback.success, color.feedback.error. Ces rôles sont déjà attribués dans le Growth-Kit : vous remplacez la valeur, pas la structure.
Gardez l'échelle typographique cohérente. Si les polices de votre marque imposent des ratios de taille différents de ceux du kit par défaut, changez les valeurs des tokens, pas les composants individuels. Les changements d'échelle faits au niveau des tokens se propagent automatiquement aux titres, aux libellés, aux textes de boutons et aux textes secondaires.
L'espacement et le rayon définissent le caractère de la marque plus que la couleur. Des tokens de padding généreux produisent une impression premium. Des rayons serrés sur les boutons et les cartes paraissent plus corporate que des rayons doux. Prenez cette décision une fois, au niveau des tokens, pas composant par composant.
Anti-pattern au niveau 1 : dupliquer des valeurs de tokens pour des cas d'usage isolés. Un token color.button.primary.bg qui contient par hasard la même valeur hexadécimale que color.brand.primary n'est pas un design system : c'est de la dette technique qui explose au prochain rafraîchissement de marque.
Niveau 2 : les surcharges de composants, ciblées, justifiées, documentées
Une fois les tokens en place, si un composant ne se comporte toujours pas comme la marque l'exige, le niveau 2 s'applique. Les surcharges de composants vous permettent d'ajuster le comportement ou la mise en page d'un seul composant sans forker le code du cœur.
Scénarios de surcharge légitimes :
- Votre marque utilise un jeu d'icônes qui n'est pas inclus par défaut dans le kit. Surcharger la prop du slot d'icône est propre.
- La section hero a besoin d'une autre mise en page pour votre secteur, par exemple une vidéo en arrière-plan plutôt qu'une image statique. Surcharge du conteneur de mise en page par slot.
- Un style de bouton spécifique pour les CTA primaires a une structure de padding différente parce que le système de votre marque l'exige.
Ce que les surcharges de composants ne doivent pas résoudre :
- Les corrections de couleur ou de typographie. Si vous devez surcharger la couleur d'un composant, vous n'avez probablement pas terminé le niveau 1.
- Les corrections de mise en page qui sont en réalité des questions de tokens d'espacement.
- Les changements fonctionnels dans la logique d'un composant (comportement des filtres, état du panier). Cela relève de l'ingénierie, pas d'une surcharge.
Documentez chaque surcharge avec une raison directement dans le fichier de configuration du composant ou, si vous travaillez sur la plateforme Agentic Frontend Management Platform - dans le champ de commentaire du Cockpit. « Nous avons changé ceci parce que... » est la note qui sauvera votre prochain collègue dans six mois.
Niveau 3 : les garde-fous de l'éditeur, la liberté avec un système
Le troisième niveau est le plus sous-estimé. Les tokens sont définis, les surcharges sont justifiées, les composants ont la bonne allure. Maintenant, l'équipe marketing doit remplir le contenu.
Sans garde-fous dans votre éditeur visuel, voici ce qui se passe : les arrière-plans hero sont remplacés par des images uploadées dont la tonalité ne correspond pas à la marque. Les CTA reçoivent des textes qui ne respectent pas la spécification de design du bouton. L'espacement des sections est surchargé manuellement au niveau du composant parce que quelqu'un a trouvé que le blanc « paraissait trop grand ».
Les garde-fous de l'éditeur ne sont pas une restriction de l'autonomie du marketing : ils sont la condition pour que cette autonomie fonctionne sans éroder la marque.
Des garde-fous qui tiennent en pratique :
Limitez le sélecteur de couleurs à la palette de la marque. Quand l'éditeur ne propose que les tokens de marque comme couleurs sélectionnables, personne ne peut introduire par accident une teinte hors marque dans la section hero. Un champ de couleur libre semble flexible : en pratique, il produit une dérive de marque.
Limitez le choix typographique à l'échelle des tokens. Pas de saisie libre en pixels pour les tailles de police. L'échelle compte cinq paliers, tous définis dans l'ensemble de tokens : ce sont les seules options dans l'éditeur.
Validation des slots de contenu pour les composants critiques. Des champs de titre hero avec un nombre maximal de caractères aligné sur l'intention du design system. Un titre hero de 140 caractères casse la mise en page visuelle : c'est le système qui l'empêche, pas un sprint de relecture.
Contraintes d'upload d'images. Validation du ratio d'aspect pour les assets hero, les images produit et les visuels de bannière. Une erreur d'upload vaut mieux qu'un storefront déformé.
Pour la cohérence de marque, cette couche de garde-fous est l'implémentation opérationnelle : le système impose la cohérence, de sorte que chaque changement n'a pas besoin de passer par une revue de design.
Le chemin comme séquence
Quand vous configurez un Growth-Kit de zéro pour une nouvelle marque, la séquence ressemble à ceci :
- Remplir l'ensemble de tokens (couleur, typographie, espacement, rayon) : comptez de 2 à 4 heures pour un système de marque complet.
- Prévisualiser les composants : qu'est-ce qui convient déjà grâce à la propagation des tokens, qu'est-ce qui demande encore de l'attention ?
- Construire la liste des surcharges : quels composants ont réellement besoin d'une surcharge, et pourquoi ? Objectif : le moins possible.
- Configurer les garde-fous de l'éditeur pour les champs de contenu que le marketing va remplir.
- Terminer par une revue en direct de tout le parcours client, sur l'ensemble des composants, avant le début du premier sprint de remplissage de contenu.
Ce chemin fonctionne parce qu'il prend au sérieux le principe du design system : prendre les décisions le plus près possible de la source, pas le plus près possible du résultat.
Ce qui casse quand on saute le chemin
Le symptôme le plus courant d'un chemin de personnalisation escamoté n'est pas un design cassé : c'est une dérive de marque dans le temps. Le storefront a la bonne allure au lancement. Six mois plus tard, après plusieurs phases de campagne et d'innombrables changements dans l'éditeur, chaque section a une interprétation légèrement différente de la marque. Aucun changement pris isolément n'était faux, mais le résultat est incohérent.
La dérive de marque coûte cher. Un audit qui corrige les écarts de marque après six mois demande bien plus d'efforts qu'un chemin de personnalisation propre au lancement. Le niveau des tokens est l'assurance contre cet effort.
Pour aller plus loin
Cet article couvre la perspective MOFU sur la personnalisation : comment adapter sans perdre la gouvernance. Pour un panorama du Growth-Kit et de ses variantes sectorielles, l'article hub est le bon point de départ : UI Growth-Kits: Component Sets for 8 Industries.
Si vous voulez comprendre comment fonctionne l'ensemble de la couche frontend sous ces composants, de la fondation Nuxt au deployment managé, la page Agentic Frontend Management Platform est l'étape suivante logique.