Des design systems qui ne se figent pas : un playbook d’agence pratique pour des composants flexibles à grande échelle | Blanche

Un design system n’est pas un produit. Dans le monde des agences, c’est un service — qui doit survivre à des périmètres mouvants, des équipes qui tournent, de nouvelles marques, et l’inévitable demande « il nous faut ça en prod pour vendredi ».

Si votre système ralentit la livraison, il n’est pas « mature ». Il est figé.

L’objectif n’est pas une cohérence parfaite. L’objectif, c’est un changement prévisible — sans sacrifier la qualité, l’accessibilité ou la vélocité.

Ce playbook s’adresse aux leads d’agence, aux responsables de design system et aux développeurs frontend qui ont besoin d’un système capable de s’étendre à plusieurs clients tout en restant assez flexible pour évoluer.

Pourquoi la plupart des design systems échouent en agence

Les design systems s’effondrent souvent sous des pressions qui semblent propres aux « agences », mais qui relèvent surtout de la réalité multi-produit.

Mode d’échec n°1 : la bibliothèque de composants devient le système

Les équipes livrent un ensemble de composants bien finis (boutons, cartes, modales), déclarent victoire, puis la réalité frappe :

Un nouveau client arrive avec une marque et une voix typographique différente
Un site legacy a des bizarreries de mise en page qui ne se mappent pas proprement
Le marketing a besoin d’une landing page one-shot qui casse la grille

Quand le système est défini comme « les composants », chaque écart ressemble à une trahison. Les designers contournent le système. Les développeurs le forkent.

À retenir : Une bibliothèque de composants est un résultat. Le système, ce sont les règles qui génèrent des résultats.

Mode d’échec n°2 : la gouvernance devient un goulot d’étranglement

Les agences copient souvent des modèles de gouvernance d’entreprise (comités, conseils, cycles de revue sur plusieurs semaines) parce que ça sonne « responsable ». Mais les délais d’agence punissent la bureaucratie.

Symptômes :

Les PR restent en attente d’approbation
Les designers cessent de contribuer parce que c’est « trop de process »
Le système devient un artefact maintenu par un seul héros

À retenir : La gouvernance doit augmenter la confiance et la vitesse, pas créer un deuxième backlog.

Mode d’échec n°3 : pas d’histoire de migration (donc le système reste théorique)

Si votre système ne fonctionne que pour des builds greenfield, il devient un slide deck.

Les agences vivent avec :

du spaghetti CSS legacy
des écosystèmes multi-marques
des refontes partielles

Sans stratégies de migration, les équipes ne peuvent pas adopter le système de façon incrémentale — donc elles ne l’adoptent pas du tout.

À retenir : L’adoption est un problème produit. Traitez la migration comme un onboarding.

Construire les bonnes fondations : tokens, primitives, accessibilité

Si vous voulez des composants qui ne se figent pas, il vous faut des contraintes flexibles : des règles qui créent de la cohérence sans dicter chaque forme finale.

Définir les « contraintes flexibles » (et pourquoi elles battent les bibliothèques rigides)

Une bibliothèque de composants rigide dit : « Utilisez cette carte. »

Des contraintes flexibles disent :

Voici les paliers d’espacement
Voici les échelles typographiques
Voici les patterns d’interaction
Voici les exigences d’accessibilité

Ensuite, les composants deviennent composables et adaptables à la marque.

Pensez en termes de physique, pas d’architecture : définissez les forces (tokens + garde-fous), pas le bâtiment.

Commencez par des tokens qui correspondent à des décisions, pas à des valeurs

Les tokens ne sont pas juste des variables. Ce sont des décisions nommées.

Une hiérarchie de tokens pratique qui fonctionne sur plusieurs clients :

Tokens de base (valeurs brutes) :
- color.blue.600: #2563EB
- space.4: 16px
- radius.2: 8px
Tokens sémantiques (sens) :
- color.text.primary
- color.surface.default
- color.border.subtle
- space.stack.md (rythme vertical)
Tokens de composant (optionnels, pour les composants à forte variance) :
- button.primary.bg
- button.primary.text

Règle empirique en agence :

Si plusieurs marques partagent le système, investissez davantage dans les tokens sémantiques.
Si une marque a beaucoup de produits, les tokens de composant peuvent réduire le churn.

Outils qui facilitent ça :

Figma Variables pour la modélisation des tokens côté design
Style Dictionary (Amazon) ou Tokens Studio pour les pipelines de tokens
Storybook pour documenter l’usage des tokens en contexte

Construisez des primitives avant les composants

Les primitives sont les « atomes » du système qui rendent les composants flexibles.

Un set de primitives pragmatique :

Typographie : Text, Heading, Link
Mise en page : Stack, Inline, Grid, Container
Surface : Card, Panel, Divider
Bases de formulaire : Input, Select, Checkbox, Radio
Feedback : Toast, Alert, Tooltip

Le move puissant, ce sont les primitives de layout. Les agences les sautent souvent, puis se demandent pourquoi chaque page est custom.

À retenir, concret : Si votre système a 40 composants mais pas de Stack ni de Grid, vous fabriquez des meubles sans bois standard.

Intégrez l’accessibilité dans la fondation (pas en phase QA)

L’accessibilité est l’indicateur le plus rapide pour savoir si votre système est réel.

Garde-fous non négociables :

Contraste des couleurs : les tokens doivent respecter les objectifs WCAG (AA par défaut ; savoir où AAA compte)
États de focus : anneaux de focus visibles pour la navigation clavier
HTML sémantique : les boutons sont des boutons ; les liens sont des liens
ARIA seulement quand nécessaire : évitez « ARIA comme styling »

Workflow pratique :

Ajoutez des critères d’acceptation d’accessibilité à chaque composant (voir ci-dessous)
Utilisez axe DevTools, Lighthouse et des patterns Testing Library
Documentez les interactions clavier dans Storybook (pas seulement les visuels)

Si un composant n’est pas accessible par défaut, ce n’est pas un composant — c’est un risque.

Une gouvernance sans paperasse

La gouvernance n’est pas un comité. C’est un ensemble de mécanismes légers qui maintiennent une qualité élevée tout en laissant les équipes avancer.

Choisissez un modèle de gouvernance adapté à la réalité des agences

Trois modèles qui fonctionnent vraiment :

Modèle mainteneur (idéal pour les petites équipes)
- 1–2 mainteneurs possèdent les standards et les merges
- Les contributeurs ouvrent des PR avec des templates
- Fenêtre de revue hebdomadaire de 30 minutes
Modèle fédéré (idéal pour les agences multi-squads)
- Chaque squad a un « représentant système »
- Les représentants tournent chaque mois
- Backlog partagé + cadence de revue prévisible
Modèle intégré côté client (idéal pour les longues missions en rétention)
- L’agence maintient le cœur
- L’équipe client possède les extensions spécifiques au produit
- Frontières claires : ce qui est core vs. ce qui est local

À retenir : Vous optimisez le débit + la confiance, pas le consensus.

Le process minimum viable : template de PR + changelog + cadence de release

Si vous ne mettez en place que trois artefacts de gouvernance, choisissez ceux-ci :

Template de PR qui force la clarté
Changelog qui dit aux équipes ce qui a changé et pourquoi
Cadence de release (même si c’est « toutes les deux semaines »)

Un template de PR qui évite le chaos :

Quel problème cela résout-il ?
Est-ce un breaking change ?
Checklist accessibilité (clavier, focus, notes lecteur d’écran)
Captures de régression visuelle
Notes de migration (si applicable)

Faites le pont entre design et engineering avec un langage partagé

La plupart des problèmes « d’alignement design-dev » sont en réalité des problèmes de naming.

Créez un langage système partagé :

Des noms de tokens qui correspondent à l’intention (surface.default, pas gray.50)
Des props de composants qui mappent à des décisions de design (tone, emphasis, density)
Des définitions claires : qu’est-ce qu’un pattern vs. un composant vs. un template

Puis ajoutez des critères d’acceptation que les deux côtés peuvent valider.

Exemple de critères d’acceptation pour un Button :

Supporte l’activation clavier (Entrée/Espace)
L’état de focus visible respecte les exigences de contraste
L’état disabled n’est pas uniquement basé sur la couleur (curseur + opacité + aria-disabled si nécessaire)
L’état de chargement annonce la progression (aria-busy ou pattern de live region)
Les tailles correspondent aux tokens d’espacement (pas de padding one-off)

À retenir : « Done » doit être testable, pas basé sur le ressenti.

Faire évoluer le système : versioning, dépréciation, migrations

Un système qui ne peut pas changer en sécurité finira par ne plus changer du tout.

Versionnez comme un produit (même si c’est « juste une bibliothèque »)

Utilisez le semantic versioning si vous distribuez du code :

MAJOR : changements d’API ou visuels cassants qui nécessitent une migration
MINOR : nouveaux composants/fonctionnalités, rétrocompatibles
PATCH : corrections

Si vous documentez surtout des patterns (fréquent dans des stacks très Webflow), versionnez quand même :

Versionnez vos guidelines
Versionnez vos tokens
Versionnez vos composants/patterns en tant qu’ensemble

Outils :

GitHub Releases + automatisation du changelog
Changesets pour les monorepos
Déploiements Storybook versionnés

La dépréciation est une fonctionnalité

Les agences évitent souvent la dépréciation parce que ça ressemble à de l’overhead. Mais sans elle, vous obtenez une divergence silencieuse.

Une politique de dépréciation propre :

Marquer comme déprécié dans la doc immédiatement
Le garder fonctionnel pendant un cycle de release minor (ou une fenêtre de temps)
Fournir un codemod ou des notes de migration
Le supprimer au prochain major

La dépréciation, c’est la façon de rester flexible sans accumuler de dette de design.

Stratégies de migration pour sites legacy et écosystèmes multi-marques

La plupart des systèmes d’agence doivent coexister avec du legacy pendant un moment. Planifiez-le.

Stratégie 1 : adoption « strangler » (recommandée)

Commencez par envelopper les pages legacy avec de nouvelles primitives :

Remplacez l’espacement et la typographie par des tokens
Introduisez des primitives de layout (Stack, Grid) pour réduire le CSS custom
Remplacez les composants seulement là où le ROI est évident (formulaires, navigation)

Cela réduit le risque et évite une réécriture big-bang.

Stratégie 2 : theming en double-run pour le multi-marque

Pour les écosystèmes multi-marques, vous voulez une structure partagée avec des skins spécifiques à chaque marque :

Primitives partagées + APIs de composants
Thèmes de marque exprimés via des tokens sémantiques
Overrides de marque sous forme de couches petites et explicites

C’est là que les variables CSS brillent :

:root définit les tokens sémantiques
[data-brand="x"] les surcharge

Stratégie 3 : « composants adaptateurs » pour les patterns legacy compliqués

Parfois, le markup legacy ne peut pas changer rapidement (contraintes CMS, exports Webflow, etc.). Créez des adaptateurs :

LegacyCard mappe l’ancien DOM vers les nouveaux tokens
LegacyButton normalise les états

Rendez les adaptateurs temporaires et suivez-les comme dette de migration.

À retenir : La migration n’est pas un projet one-shot. C’est une piste d’atterrissage gérée.

Métriques & outillage pour le garder vivant

Si vous ne pouvez pas mesurer la santé du système, vous retomberez sur des opinions — et les opinions ne passent pas à l’échelle entre équipes.

Mesurez ce qui compte : réutilisation, vitesse, accessibilité

Trois métriques pratiques que les leads d’agence peuvent réellement utiliser :

Taux de réutilisation
- % de l’UI construite avec les composants/primitives du système
- À suivre via l’usage des imports dans le code, l’usage des classes Webflow, ou des audits
Time-to-ship
- Cycle time pour des travaux courants (nouvelle landing page, nouveau formulaire, nouvelle section marketing)
- Surveillez les délais induits par la gouvernance (temps d’attente de review)
Couverture accessibilité
- % de composants avec un comportement clavier documenté
- % couverts par des checks a11y automatisés (axe)
- Nombre de régressions par release

Si la réutilisation est élevée mais que le time-to-ship se dégrade, votre système devient une porte — pas un levier.

Une stack d’outils adaptée aux workflows d’agence

Une base solide et moderne :

Figma (Variables + propriétés de composants)
Storybook (docs + tests d’interaction)
Chromatic (régression visuelle)
axe-core + Testing Library (a11y + comportement)
Changesets ou workflows GitHub Release (versioning)
Notion/Linear/Jira pour le backlog du système avec des labels clairs

Si votre production est très Webflow :

Traitez votre page Style Guide Webflow comme un artefact de déploiement
Miroitez les tokens en variables CSS et imposez l’usage via des conventions de classes
Documentez les patterns avec des sections réelles, copiables-collables (pas des captures)

À retenir : Investissez dans la toolchain qui réduit les débats et augmente la répétabilité.

Un exemple de template de sprint « maintenance système »

La plupart des systèmes meurent parce qu’ils n’obtiennent jamais de vrai temps au calendrier. Donc planifiez-le.

Voici un template de sprint léger que les agences peuvent exécuter chaque mois (ou toutes les 6 semaines) sans faire dérailler le travail client.

Objectif du sprint

Garder le système livrable : réduire la dérive, débloquer les équipes et améliorer la qualité.

1) Intake (1–2 heures)

Collectez les demandes des squads et des équipes client :

Besoins de nouveaux composants
Manques de tokens
Rapports de bugs
Problèmes d’accessibilité
Notes « on a dû bricoler autour de X »

Output : un backlog priorisé avec des labels :

bug, a11y, migration, new, docs, breaking

2) Triage + journal de décision (1 heure)

Tenez une courte réunion avec un binôme mainteneur designer + ingénieur.

Décidez :

Est-ce un besoin core ou une extension spécifique produit ?
Est-ce que cela nécessite des changements de tokens/primitives ?
Y a-t-il un risque de breaking change ?

Output : une entrée de journal de décision (1 paragraphe chacune). Cela devient votre mémoire institutionnelle.

3) Construire + valider (2–4 jours, selon le périmètre)

Pour chaque item :

Mettez à jour les tokens/primitives d’abord (quand applicable)
Implémentez les changements de composants
Ajoutez/ajustez les critères d’acceptation
Ajoutez des tests (unit + interaction + a11y)
Ajoutez des exemples Storybook (y compris les edge cases)

4) Release + communiquer (2–3 heures)

Livrez avec :

Bump de version
Entrées de changelog écrites pour des humains
Notes de migration
Message « ce qui a changé / quoi faire maintenant » dans Slack/Teams

5) Suivi d’adoption (1–2 heures)

Choisissez un projet réel et appliquez la mise à jour :

Mettre à jour un template de page
Refactorer un pattern legacy
Supprimer un composant adaptateur

À retenir : Chaque sprint de maintenance doit se terminer par une adoption en production, pas seulement par des améliorations dans la bibliothèque.

Conclusion : construire un système qui peut dire « oui » plus souvent

Un design system qui survit au travail en agence n’est pas celui qui a le plus de composants. C’est celui qui a :

Des contraintes flexibles (tokens + primitives + garde-fous)
Une gouvernance légère (reviews rapides, versioning clair, vrais changelogs)
Un langage partagé entre design et engineering (plus des critères d’acceptation testables)
Des parcours de migration qui respectent la réalité legacy
Des métriques qui révèlent quand le système aide — ou quand il vous ralentit silencieusement

Si vous voulez des composants qui ne se figent pas, arrêtez de traiter votre système comme un musée. Traitez-le comme un produit que vous opérez.

Les meilleurs design systems d’agence n’imposent pas la cohérence — ils permettent d’aller vite avec des standards.

Si vous voulez, je peux aussi fournir un template de PR prêt à copier-coller, une checklist de critères d’acceptation pour les composants courants, et un schéma de naming de tokens qui fonctionne sur des clients multi-marques.