Des design systems qui survivent aux passations client : tokens, docs et playbook de stratégie de sortie | Blanche

Un design system qui ne survit pas à une passation client n’est pas un système — c’est un instantané.

La plupart des équipes n’échouent pas parce qu’elles manquent de composants. Elles échouent parce qu’elles livrent une belle bibliothèque sans modèle d’exploitation : pas de source de vérité pour les tokens, pas de patterns de documentation alignés sur la façon dont les gens travaillent, et pas de gouvernance adaptée à une petite équipe qui jongle avec une roadmap produit.

Si votre design system exige que votre agence reste « en retainer » pour rester cohérent, ce n’est pas un design system. C’est une dépendance.

Cet article propose une architecture pratique, prête pour la passation : tokens → composants → templates → docs → gouvernance, avec une « stratégie de sortie » intégrée.

Le coût caché d’un système « joli »

Un fichier Figma soigné et un Storybook peuvent malgré tout produire du chaos six mois après la passation. Les coûts cachés apparaissent sous forme de :

Dérive de versions : Figma dit une chose, le CSS en production en dit une autre, Webflow une troisième.
Overrides ponctuels : les styles « juste pour cette fois » se multiplient jusqu’à ce que plus rien ne soit réutilisable.
Composants sans propriétaire : personne ne sait qui peut valider les changements, donc les changements se font au fil de l’eau (ou pas du tout).

Le résultat est familier : le système devient un musée, et le produit devient un patchwork.

Le test de passation (à utiliser avant de dire que c’est « terminé »)

Posez ces questions :

Un nouveau designer peut-il livrer une nouvelle page avec le système en moins d’une journée sans vous demander ?
Un développeur peut-il modifier les valeurs de couleur de marque en toute sécurité sans devoir fouiller manuellement dans le CSS et les composants ?
Un builder Webflow peut-il implémenter une nouvelle section en utilisant des patterns approuvés sans overrides personnalisés ?
Existe-t-il un workflow clair « voilà comment on fait évoluer le système » ?

Si une réponse est « non », vous n’avez pas encore un système prêt pour la passation.

Une architecture prête pour la passation : tokens → composants → templates

Les systèmes qui survivent à la passation partagent généralement un trait : ils séparent les décisions des implémentations.

Les tokens capturent les décisions (couleur, échelle typographique, espacements, rayons, ombres, motion).
Les composants implémentent ces décisions (boutons, cartes, navigations).
Les templates/sections assemblent les composants en mises en page réutilisables (blocs de pricing, variantes de hero).

Cette approche en couches est la façon dont des équipes comme Shopify (Polaris) et IBM (Carbon) maintiennent la cohérence sur de grandes surfaces — et elle est encore plus critique pour les petites équipes côté client, car elle réduit la charge cognitive.

Tokens-first vs component-first : quand choisir quoi

Les deux approches peuvent fonctionner. L’essentiel est de choisir selon les contraintes du projet, pas selon une idéologie.

Choisissez tokens-first quand :

Vous supportez plusieurs plateformes (web + Webflow + email + natif).
Le travail de marque évolue encore et vous voulez un changement maîtrisé.
Vous anticipez plusieurs implémenteurs (agence + devs client + prestataires).
Vous avez besoin de theming (clair/sombre, variantes de marque, multi-marque).

À retenir : tokens-first vous donne une colonne vertébrale résiliente. Les composants peuvent changer ; les tokens restent stables.

Choisissez component-first quand :

Vous avez une surface limitée (ex. site marketing uniquement) et vous devez aller vite.
L’UI est déjà construite et vous retrofittez la cohérence.
L’équipe client est minuscule et a besoin de briques immédiatement.

À retenir : component-first peut être plus rapide, mais vous devez ensuite compléter avec des tokens une fois les patterns stabilisés — sinon vous figez l’incohérence dans la bibliothèque.

Un hybride pragmatique qui marche en agence

Démarrez component-first pour la vélocité, mais imposez une règle :

Chaque composant doit être mappé à des tokens en v2.

Cela signifie que vous pouvez livrer du « suffisamment bien » au départ, mais vous planifiez la refactorisation vers des tokens dans le cadre de la mission — avant la passation.

Comment mapper les tokens vers les variables CSS, les styles Figma et les builders no-code

Un système prêt pour la passation a besoin d’un pipeline de tokens qui ne repose pas sur une connaissance implicite.

Étape 1 : Définir des niveaux de tokens (pour que les clients puissent raisonner sur le changement)

Utilisez trois niveaux :

Tokens core : valeurs brutes (ex. blue-600, space-16, radius-8).
Tokens sémantiques : alias basés sur le sens (ex. color-bg-surface, color-text-primary, space-page-gutter).
Tokens de composant (optionnels mais puissants) : décisions au niveau du composant (ex. button-bg-default, card-radius).

Bénéfice concret : si la couleur de marque change, vous mettez à jour les mappings sémantiques — pas chaque composant.

Les tokens core sont ce que vous avez. Les tokens sémantiques sont ce que vous voulez dire. Cette séparation est ce qui survit aux rebrands.

Étape 2 : Mapper les tokens vers des variables CSS (la source de vérité côté web)

Une approche de nommage simple et durable :

Core : --color-blue-600: #2563eb;
Sémantique : --color-bg-surface: var(--color-neutral-0);
Espacement sémantique : --space-page-gutter: var(--space-24);

Ensuite, les composants consomment les tokens sémantiques :

.button { background: var(--color-action-primary); }
.card { border-radius: var(--radius-md); }

Règle actionnable : découragez l’usage direct des tokens core dans les composants sauf raison solide. Les tokens core devraient surtout servir à définir les tokens sémantiques.

Étape 3 : Garder Figma aligné sans en faire la « vérité »

Figma est essentiel pour l’adoption, mais ce n’est pas une excellente source de vérité unique parce que :

les styles peuvent dériver,
les variables peuvent être mal appliquées,
et les copies prolifèrent.

Cela dit, vous pouvez rendre Figma durable en :

Utilisant les Figma Variables pour les tokens sémantiques (rôles de couleur, rôles d’espacement).
Limitant les styles publiés à ce dont les builders ont réellement besoin.
Créant une page « Ne pas modifier » qui explique ce qui est synchronisé et ce qui est manuel.

Pattern de mapping pratique :

Variable Figma Color / Background / Surface → CSS --color-bg-surface
Variable Figma Space / Page / Gutter → CSS --space-page-gutter

Si vous utilisez Token Studio (anciennement Figma Tokens) ou un outil similaire, définissez un workflow clair :

Les tokens sont édités à un seul endroit.
Les mises à jour sont exportées vers le code.
Figma récupère le même set de tokens.

Étape 4 : Rendre les tokens utilisables dans Webflow et les autres builders no-code

Les builders no-code échouent souvent avec des systèmes de tokens « purs » parce que les équipes peuvent surcharger les styles très vite. Il vous faut des garde-fous.

Pour Webflow en particulier, visez :

Des classes globales qui représentent des tokens sémantiques : text-primary, bg-surface, radius-md, space-section-lg.
Un petit set de classes utilitaires pour les primitives de layout (grid, stack, container).
Une interdiction des styles inline « au hasard », sauf via des échappatoires clairement documentées.

Approche concrète qui survit à la passation :

Mettez vos variables CSS dans une seule feuille de style globale.
Utilisez les classes Webflow pour référencer ces variables.
Documentez la liste des classes « approuvées » et quand utiliser chacune.

L’objectif n’est pas d’empêcher les overrides. C’est de rendre la bonne solution plus rapide que la mauvaise.

Des docs qui sont utilisées : patterns, do/don’t et exemples

La plupart des documentations de design system échouent parce qu’elles se lisent comme une spec, pas comme une boîte à outils.

Les meilleures docs de passation côté agence sont :

orientées tâches (comment construire une page de pricing),
riches en exemples (patterns à copier/coller),
et affirmées (do/don’t clairs).

La pile de documentation qui réduit la dépendance future à l’agence

Visez quatre couches :

Quickstart (1 page) : comment construire une page, où vivent les tokens, ce qu’il ne faut pas toucher.
Fondations : tokens, typographie, espacement, grille, règles d’accessibilité.
Composants : usage, variantes, états, règles de contenu.
Templates/sections : compositions approuvées et quand les utiliser.

Des outils qui fonctionnent bien dans la vraie vie :

Storybook pour l’usage des composants et les états.
Zeroheight, Notion ou Confluence pour les docs narratives et le process.
Un site vivant (même une URL privée) qui montre les templates et des exemples de contenu réel.

Écrivez les docs comme si vous onboardiez un prestataire au jour 1

Pour chaque composant, incluez :

Objectif : à quoi ça sert et à quoi ça ne sert pas.
Anatomie : parties et nomenclature.
Variantes : ce qui existe et pourquoi.
États : hover/focus/disabled/loading.
Règles de contenu : limites de caractères, usage des icônes, ratios d’images.
Accessibilité : comportement clavier, attentes de contraste.
Exemples : au moins 3 exemples réels.
Do / Don’t :
- Do : « Utilisez le bouton Primary une seule fois par vue. »
- Don’t : « Créez une nouvelle variante ‘Secondary-Alt’ pour une seule page. »

À retenir : la documentation doit empêcher que « inventer une nouvelle UI » devienne le comportement par défaut.

Gouvernance et ownership dans la vraie vie (surtout pour les petites équipes)

Beaucoup de clients n’ont pas de responsable design system dédié. La gouvernance doit partir du principe qu’il y a :

des priorités concurrentes,
des prestataires qui tournent,
et peu de temps.

Des modèles de gouvernance légers qui marchent vraiment

Modèle A : le « Two-Key Turn » (meilleur défaut)

Les changements nécessitent deux validations :

une côté design (ou lead design),
une côté engineering/implémentation (lead frontend ou lead Webflow).

Cela évite les changements unilatéraux qui cassent l’autre côté.

Modèle B : la rotation « Librarian »

S’il n’y a pas de propriétaire, faites tourner un « bibliothécaire du système » chaque mois :

examine les demandes entrantes,
planifie de petits nettoyages,
fait avancer le backlog.

Ça fonctionne étonnamment bien pour des équipes de 3 à 8.

Modèle C : le modèle « Platform » (pour les plus grandes organisations)

Une petite équipe cœur possède les tokens et les primitives ; les équipes produit possèdent les composants de fonctionnalités.

À retenir côté agence : même si le client n’est pas prêt pour le Modèle C, vous pouvez concevoir le système pour qu’il puisse y grandir plus tard.

Définissez un workflow de changement (ou la dérive le définira pour vous)

Votre package de passation doit inclure un process simple de type RFC :

Demande : quel problème résout-on ?
Impact : quels tokens/composants/templates sont affectés ?
Décision : ajouter vs modifier vs déprécier.
Déploiement : versioning et notes de migration.

Gardez-le léger : un template Notion ou un formulaire d’issue GitHub suffit.

Modes d’échec courants (et comment concevoir pour les éviter)

Mode d’échec 1 : dérive de versions entre Figma, le code et Webflow

Symptômes : les designers se réfèrent à d’anciens styles ; les développeurs implémentent des plus récents ; les pages Webflow sont « proches mais pas tout à fait ».

Comment l’éviter :

Choisissez une source de vérité unique pour les tokens (souvent le code + un JSON de tokens).
Publiez un tableau « Versions actuelles » dans la doc :
- version de la librairie Figma
- version du package de tokens
- version de la librairie de composants
Planifiez une tâche récurrente de « sync » (mensuelle suffit souvent).

Mode d’échec 2 : les overrides ponctuels deviennent la norme

Symptômes : valeurs de padding personnalisées, couleurs ad hoc, composants dupliqués.

Comment l’éviter :

Prévoyez des échappatoires avec des règles :
- « Autorisé : espacement de layout ponctuel uniquement dans les templates. »
- « Interdit : couleurs ponctuelles ; demandez un token sémantique. »
Ajoutez des templates de « composition » pour que les builders n’aient pas à improviser.

Mode d’échec 3 : accumulation de composants sans propriétaire

Symptômes : personne ne sait si un composant peut être modifié ; la peur mène à des forks.

Comment l’éviter :

Ajoutez un champ de responsabilité par composant (même si c’est un rôle, pas une personne).
Ajoutez un label de stabilité :
- Stable (réutilisation sûre)
- Experimental (peut changer)
- Deprecated (ne pas utiliser)

À retenir : les labels réduisent l’anxiété qui provoque la duplication silencieuse.

Checklist de migration et de maintenance (prête pour la passation)

Utilisez ceci comme gate avant passation.

Tokens

Niveaux de tokens définis : core + sémantique (+ tokens de composant si nécessaire)
Conventions de nommage documentées avec des exemples
Tokens exportés en variables CSS dans un emplacement global unique
Tokens sémantiques utilisés par défaut dans les composants
Stratégie de dépréciation définie (que fait-on des anciens tokens)

Figma

Variables/styles mappés aux tokens sémantiques
Process de publication de la librairie documenté
Pages « Ne pas modifier » et « Comment utiliser » incluses
Pages d’exemple construites uniquement avec les composants de la librairie

Code / Frontend

La librairie de composants a un versioning clair (même simple)
Storybook (ou équivalent) inclut les états et des notes d’accessibilité
Linting ou règles de style qui découragent les valeurs hardcodées quand c’est possible

Webflow / Implémentation no-code

Classes globales alignées sur les tokens sémantiques
Utilitaires approuvés documentés (container, stack, grid)
Guide clair sur les overrides et quand ils sont acceptables
Librairie de templates/sections créée pour les patterns de pages courants

Documentation

Un Quickstart existe et se lit en moins de 10 minutes
Do/Don’t pour les 10 principaux composants
Exemples réels avec patterns à copier/coller
Workflow « Comment demander un nouveau composant/token »

Gouvernance

Validation à deux clés définie (design + implémentation)
Labels de responsabilité/stabilité assignés
Rituel mensuel de maintenance planifié (30–60 minutes)

Conclusion : construire des systèmes avec une stratégie de sortie

Un design system qui survit à la passation n’est pas celui qui a le plus de composants — c’est celui qui a la structure de décision la plus claire et le coût de maintenance le plus faible.

Si vous voulez que votre système survive à la mission :

Construisez des tokens aux templates, pas seulement des composants.
Mappez proprement les tokens entre CSS, Figma et Webflow.
Écrivez une documentation qui répond à de vraies tâches, avec des do/don’t et des exemples.
Choisissez une gouvernance adaptée à la réalité : légère, basée sur des rôles, et répétable.

La meilleure passation client est celle où votre absence ne crée pas de chaos — elle crée de la confiance.

Si vous planifiez une refonte ou une migration de plateforme (surtout avec Webflow dans l’équation), traitez le design system comme un produit que vous livrez : avec du versioning, des règles d’exploitation et un plan de maintenance. C’est ce qui transforme « joli » en durable.