# Votre marque, sans étape de build.

> Habiller ApiGlow à vos couleurs sans étape de build : une entrée de config ou un bloc CSS, la sortie du générateur de thèmes daisyUI collée telle quelle.
>
> Source: https://apiglow.dev/fr/docs/theming/index.md


Un thème daisyUI 5 est un bloc de propriétés CSS personnalisées sous un sélecteur `data-theme`, ce qui permet à ApiGlow d'accepter le vôtre à l'exécution. Il y a deux canaux, et tous deux prennent la sortie du [générateur de thèmes daisyUI](https://daisyui.com/theme-generator/) telle quelle.

Le [builder](/fr/docs/builder/) en écrit un pour vous : choisissez une base, posez votre couleur, et il rédige l'entrée ci-dessous — avec un aperçu en direct de la console et un audit de contraste de chaque paire texte sur fond.

## Canal 1 : la config

Déclarez le thème dans `theme.custom`. L'app génère et injecte son CSS au démarrage.

```json
{
  "theme": {
    "default": "acme",
    "available": ["acme", "light", "dark"],
    "custom": [
      {
        "name": "acme",
        "extends": "dark",
        "tokens": {
          "--color-primary": "#6d28d9",
          "--color-primary-content": "#f5f3ff",
          "--radius-box": "0.5rem"
        }
      }
    ]
  }
}
```

- `name` — requis, de la forme `[a-z][a-z0-9-]*`. Le nommer comme un thème intégré tel que `light` ou `dark` restyle ce thème sur place. C'est le chemin le plus court vers « garder light et dark, brander le primary ».
- `extends` — optionnel, n'importe quel thème daisyUI **intégré** dont hériter. Le cas courant est « dark, mais à nos couleurs » : une poignée de tokens. Sans lui, les tokens absents retombent sur le thème par défaut du build : déclarez alors le jeu complet, le générateur émet tous les tokens de toute façon. Étendre un autre thème custom n'est pas pris en charge.
- `colorScheme` — optionnel, `"light"` ou `"dark"`. Il pilote l'UI fournie par le navigateur (barres de défilement, contrôles de formulaire), et est hérité d'`extends` quand il est absent.
- `tokens` — les variables de thème daisyUI 5 sous leurs noms exacts : les vingt `--color-*`, les rayons et tailles, `--border`, `--depth`, `--noise`. C'est ce qui permet de coller la sortie du générateur sans traduction.

Listez aussi le thème dans `theme.available`, sinon il est injecté mais pas sélectionnable.

## Canal 2 : votre CSS

Un bloc dans la feuille de style de la page hôte, plus le nom dans `theme.available`. Rien d'autre à configurer.

```css
[data-theme="acme"] {
  color-scheme: dark;
  --color-primary: #6d28d9;
  --color-primary-content: #f5f3ff;
  /* …le reste des variables de thème daisyUI… */
}
```

Les tokens non définis retombent sur les valeurs du thème par défaut. Pour restyler un thème intégré sur place, préférez le canal config : il reproduit les sélecteurs de daisyUI, donc il continue de fonctionner quelle que soit la façon dont daisyUI organise ses couches CSS.

## Une validation indulgente

Rien chez un thème n'a le droit de casser la page :

- Un token inconnu ou une valeur invalide est ignoré, avec un avertissement en console.
- Un nom custom absent d'`available` est signalé comme erreur de config probable, mais injecté quand même.
- Un nom en double avertit, et la première déclaration est conservée.

## En multi-spec

`theme.custom` reste à la racine, puisque les thèmes sont injectés une fois au démarrage. Une entrée `specs[]` peut toujours surcharger `theme.default` et `theme.available` : une spec restreint ce qui est sélectionnable, elle ne définit jamais un thème. Détails dans le [guide multi-spec](/fr/docs/multi-spec/).

Le reste du branding — nom du produit, logo, et la boîte « À propos » qui reste toujours — vit sur la page [Le portail](/fr/features/portal/).