Stratégie de thèmes multimarques

Multi-brand theming means a single codebase renders different visual identities for different clients, products, or sub-brands. A SaaS company might share one React application between ten enterprise customers, each expecting their logo colors and typography. With a well-designed Tailwind token system, switching brands requires only swapping a set of CSS variable values — no code changes, no separate builds.

The simplest multi-brand strategy uses a data attribute on the root element to scope different variable sets. Each brand's variables live under a [data-brand='brandname'] block. JavaScript reads the active brand from configuration, an API, or a URL parameter and sets the attribute on document.documentElement. Tailwind utility classes reference the variables, so they automatically adopt the active brand's values.

Organize each brand's design decisions in a dedicated token file. This could be a JSON file, a JS module, or even fetched from an API. Keeping brand tokens isolated means a non-developer designer can update a brand's color by editing one JSON file without touching any component code. During deployment, the appropriate brand token file is selected based on the target environment or tenant ID.

When the active brand is known at runtime (from user login or URL), inject its variables into the page dynamically using JavaScript. Iterate over the token object and call style.setProperty on document.documentElement. This approach does not require a page reload and works seamlessly with frameworks like React, where the brand context can be stored in a provider and updated on route change.

The Tailwind config remains brand-agnostic in a multi-brand setup. It only knows semantic variable names, not specific brand values. This is the key architectural decision: the config defines what tokens exist, but the brand files define what they mean. This clean separation means you can add a new brand without touching your Tailwind config or component classes at all.

For applications where the brand is known at build time (different deployments for different clients), you can use environment variables to select the brand token file and inject it into the HTML as static CSS. This approach generates the smallest possible CSS for each brand and avoids any runtime variable-switching overhead. Each brand gets its own deployed artifact with hardcoded CSS variables.

Beyond colors, brands often need different logos, illustrations, and icon styles. Use a brand context in your framework to serve the correct assets. For logos, define a logo URL as a CSS variable and render it with an img tag whose src is set by JavaScript. For icons, use a brand-specific icon set mapped through the same token system.

Testing a multi-brand system requires verifying that every component looks correct in every brand theme. Create a theme switcher in your development environment that cycles through all registered brands with a single click. Write visual regression tests using tools like Playwright or Storybook's visual testing addon, capturing screenshots under each brand to catch unintended style leaks between themes.

White-labeling is multi-brand theming taken to its logical extreme: the client's brand is so complete that your company's identity is invisible. White-labeling requires careful planning of every visual element — not just colors but typography, border radii, spacing scales, and even motion design. Map all of these to tokens, confirm every component respects the token layer, and audit for any hardcoded values that would reveal the underlying platform.

Always provide fallback values for CSS variables to prevent invisible elements when a brand token file fails to load. The var(--name, fallback) syntax ensures a sensible default is used if the variable is undefined. These fallbacks should be your primary brand's values, so the base experience is always functional even if the brand switching mechanism fails.

Storybook is an excellent environment for developing and previewing multi-brand themes. Add a toolbar selector using the @storybook/addon-toolbars package that lists your available brands. When a brand is selected, apply its token file to the Storybook preview iframe. This lets you visually test every component story in every brand without switching between codebases or deployments.

In this lesson you learned: data attribute selectors scope brand variable sets to the root element, brand token files isolate each brand's design decisions, and the Tailwind config stays brand-agnostic referencing only semantic variable names. Next up we look at governing and documenting your token system for team consistency.