Les design systems sont censés vous faire aller plus vite. Alors pourquoi tant d’agences finissent-elles par aller plus lentement—à débattre du rayon des boutons pendant que les deadlines brûlent ?

La vérité qui dérange : les design systems d’agence n’échouent pas parce que les équipes s’en fichent. Ils échouent parce que les agences évoluent dans un environnement à forte variance—clients différents, niveaux de maturité différents, stacks différentes, politiques différentes—et la plupart des conseils “best practice” supposent une seule organisation produit avec une seule roadmap.

Voici un playbook pratique pour construire un design system vivant qui aide une agence à livrer plus vite sans aplatir l’expression de marque en un template stérile.

---

Pourquoi la plupart des design systems d’agence échouent en pratique

Les équipes en agence tombent généralement dans un (ou plusieurs) de ces pièges :

1) Sur-standardisation : le système devient un plafond créatif

Quand un système est traité comme une vérité universelle, il finit par rejeter le travail réel.

• Chaque nouvelle mise en page devient “hors périmètre”
• Les besoins spécifiques à la marque sont forcés dans des composants génériques
• Les designers finissent par designer autour du système plutôt qu’avec lui

Signe révélateur : vous entendez “on ne peut pas faire ça parce que le système ne le supporte pas” plus souvent que “étendons le système.”

Un design system doit être une plateforme de décisions, pas une interdiction de décider.

2) Sous-documentation : la connaissance tribale gagne

Un système à moitié construit avec des guidelines vagues est pire que pas de système du tout. Il crée une fausse confiance.

• Le même composant est reconstruit de trois façons différentes
• Les nouveaux membres de l’équipe ne savent pas ce qui est canonique
• Les devs/implémenteurs font des suppositions “raisonnables” qui dérivent de l’intention design

Signe révélateur : la documentation la plus fiable, c’est “demande à Alex.”

3) Dérive de plateforme : Figma dit une chose, Webflow/le code en dit une autre

C’est le tueur silencieux pour les agences qui livrent des sites.

• Les tokens existent dans Figma mais pas dans les variables CSS
• Les noms de composants ne correspondent pas entre design et build
• Les classes Webflow prolifèrent jusqu’à rendre le système introuvable

Signe révélateur : les audits révèlent plusieurs bleus, plusieurs styles “H2”, et des échelles d’espacement incohérentes.

---

Le Minimum Viable System (MVS) : tokens, composants, patterns de contenu

Les systèmes d’agence les plus rapides ne commencent pas par “une bibliothèque complète”. Ils commencent par un Minimum Viable System—le plus petit ensemble de contraintes qui débloque une livraison répétable.

Choisir le bon niveau de “système” selon la maturité du client

Tous les clients ne méritent pas—ou ne peuvent pas maintenir—le même système. Alignez le système sur leur réalité opérationnelle.

Niveau 0 : site de campagne (faible maturité, faible maintenance)

Objectif : livrer vite, rester suffisamment propre pour être éditable.

• Un petit set de tokens (couleur, typo, espacement)
• Une poignée de sections flexibles
• Une documentation légère (une page)

À éviter : une gouvernance lourde, des taxonomies de composants profondes.

Niveau 1 : équipe marketing avec mises à jour fréquentes

Objectif : scaler les pages sans casser la cohérence.

• Set complet de tokens + nommage sémantique
• Bibliothèque de composants pour les sections courantes
• Patterns de contenu (comment construire des landing pages)
• Versioning basique et changelogs

Niveau 2 : écosystème produit + marketing

Objectif : cohérence multi-surfaces et réutilisation fiable.

• Tokens mappés sur des variables CSS
• Composants avec variantes et règles d’usage claires
• Cadence de revue formalisée
• Politique de dépréciation
• Modèle de contribution inter-équipes

Avis tranché : les agences survendent souvent des systèmes Niveau 2 à des clients Niveau 0. Résultat : un système que personne ne maintient et que tout le monde déteste.

Commencer par les tokens (mais les rendre sémantiques)

Les tokens sont la fondation—mais seulement s’ils décrivent l’intention.

Au lieu de :

• blue-500
• gray-900

Préférez :

• color-brand-primary
• color-text-default
• color-surface-raised

Pourquoi ? Parce que les marques changent. L’intention, elle, tend à rester.

Catégories minimales de tokens pour les sites d’agence :

• Couleur : marque, texte, surfaces, bordures, états
• Typographie : familles de polices, échelle typographique, interlignages
• Espacement : une échelle cohérente (p. ex. basée sur 4/8)
• Rayons & ombres : petit set, lié aux surfaces
• Motion (optionnel) : durées/easings si les interactions comptent

Construire des composants qui représentent des décisions réutilisables (pas des pixels réutilisables)

Les agences construisent souvent des composants trop tôt, au mauvais niveau d’abstraction.

Une meilleure heuristique :

• Si ça apparaît 3+ fois et qu’il y a des règles, c’est un composant.
• Si ça apparaît 3+ fois mais que c’est toujours différent, c’est un pattern.

Exemples de composants à fort levier pour une agence :

• Boutons + groupes de boutons
• Champs de formulaire
• Navigation (principale, mobile)
• Cartes (avec variantes)
• Modales / drawers
• Tableaux de pricing (si pertinent)

Exemples de patterns (pas des composants stricts) :

• Compositions de hero
• Grilles de fonctionnalités
• Layouts d’études de cas

Ne pas oublier les patterns de contenu (c’est là que les agences gagnent)

La plupart des design systems ignorent le fait que les sites marketing sont des machines à contenu.

Créez des “recettes” qui expliquent aux équipes comment assembler des pages :

• Patterns de structure de landing page (Hero → Preuve → Bénéfices → CTA)
• Pattern d’étude de cas (Problème → Approche → Résultat → Métriques)
• Pattern d’article de blog (TOC, citations mises en avant, règles d’images)

C’est comme ça que vous protégez la cohérence de marque sans forcer chaque page dans la même mise en page.

---

Une gouvernance sans bureaucratie : rôles, revues et versioning

La gouvernance est l’endroit où les systèmes deviennent soit un moteur de croissance, soit un goulot d’étranglement.

Définir des rôles qui collent à la réalité d’une agence

Vous n’avez pas besoin d’un comité. Vous avez besoin d’une ownership claire.

Modèle de rôles pratique :

• System Steward (Design) : responsable des tokens, des specs de composants, des règles d’usage
• System Steward (Build) : responsable de l’implémentation dans Webflow/CSS/composants
• Contributeurs (Design/Build) : proposent des changements via un processus léger
• Approbateur (Directeur Créatif / Tech Lead) : uniquement pour les breaking changes ou les évolutions au niveau de la marque

Dans les petites agences, deux personnes peuvent couvrir tout ça—ce qui compte, c’est la clarté.

Utiliser un processus de changement à deux voies : “Livrer maintenant” vs “Systématiser ensuite”

Les équipes les plus rapides séparent la livraison de la standardisation.

Voie 1 : changements de livraison

• Tenir la deadline client
• Utiliser des overrides locaux si nécessaire
• Suivre la “dette système” de façon intentionnelle

Voie 2 : changements du système

• Après livraison, réintégrer les décisions répétables dans le système
• Convertir les overrides en tokens/variantes

Le système doit servir la livraison. La livraison doit nourrir le système.

Approbations : les réserver aux breaking changes

Les approbations coûtent cher. Utilisez-les seulement quand le risque est réel.

Bons candidats à une approbation :

• Changements de tokens qui impactent beaucoup de pages (p. ex. taille de police de base)
• Changements d’API de composants (renommer des variantes, changer la structure)
• Dépréciations

Ne demandez pas d’approbation pour :

• Nouveaux composants qui n’impactent pas les existants
• Nouvelles variantes qui suivent des patterns établis
• Mises à jour de documentation

Versioning : rester simple, mais réel

Même les agences bénéficient d’un versioning sémantique léger.

• MAJOR : breaking changes (structure de composant, signification d’un token)
• MINOR : nouveaux composants/variantes
• PATCH : corrections de bugs, corrections de doc

Maintenez un changelog court. Si vous êtes dans des workflows très Webflow, la “version” peut être :

• Une note de mise à jour de Webflow Library
• Un tag Git (si basé sur du code)
• Une note de release Figma

L’essentiel : les équipes doivent pouvoir répondre à “Qu’est-ce qui a changé depuis la dernière release ?”

---

Outillage & handoff : Figma → Webflow/Code sans perdre l’intention

Le gap design-to-build est l’endroit où les systèmes meurent en silence. La solution n’est pas plus de réunions—c’est des primitives partagées et du nommage.

Faire le pont avec des variables : les tokens doivent exister en design et en build

Si vos tokens ne vivent que dans Figma, l’implémentation va dériver.

En pratique :

• Figma Variables pour couleur/typo/espacement
• Variables CSS (ou variables Webflow) pour le même set

Principe de mapping :

• Nom du token Figma = nom de la variable CSS/Webflow (ou une transformation prévisible)

Exemple de nommage :

• --color-brand-primary
• --space-4
• --radius-md

Si vous livrez en code, des outils comme Style Dictionary peuvent aider à générer des outputs par plateforme. Si vous êtes sur Webflow, considérez Variables + un système de classes discipliné comme votre “compilateur.”

Conventions de nommage : choisir un système et l’appliquer avec empathie

Vous n’avez pas besoin d’un nommage parfait—vous avez besoin d’un nommage cohérent.

Pour les équipes très Webflow, une approche pragmatique est un hybride BEM-ish ou utility-ish :

• c- pour les composants (p. ex., c-card, c-nav)
• l- pour les primitives de layout (p. ex., l-container, l-grid)
• u- pour les utilitaires (p. ex., u-hide-mobile, u-text-center)
• is- pour l’état (p. ex., is-active, is-disabled)

Puis définissez ce qui est autorisé :

• Les utilitaires peuvent ajuster l’alignement/la visibilité
• Les composants ne doivent pas encoder des espacements spécifiques à une page
• Les primitives de layout gèrent la structure ; les composants gèrent le contenu

Patterns réutilisables : concevoir des variantes qui se mappent aux variantes en build

Un échec fréquent en agence : designer 12 cartes “uniques” qui sont en réalité 3 cartes avec du contenu différent.

Dans Figma :

• Utilisez les propriétés de composants et les variantes
• Documentez quand utiliser chaque variante

En build :

• Répliquez les variantes sous forme de classes/modifiers ou de props de composant

Exemple :

• c-card + is-featured
• c-card + is-compact

Des artefacts de handoff qui aident vraiment

Au lieu de specs interminables, livrez de petits artefacts à fort signal :

• Une page “Token Map” : nom du token → usage → exemples
• Un “Component Contract” : ce qui peut changer vs ce qui doit rester stable
• Une section “Do/Don’t” pour chaque composant

Référencez les outils que les équipes utilisent déjà :

• Figma (variables, propriétés de composants)
• Webflow (Libraries, Variables, Components)
• Storybook (pour les systèmes basés sur du code)
• Chromatic (régression visuelle pour les bibliothèques de composants)

---

Comment mesurer et faire évoluer le système dans le temps

Si vous ne pouvez pas prouver que le système aide, il devient un side project. Les agences ont besoin de métriques connectées à la livraison.

Les métriques qui comptent (et qui sont réalistes pour les agences)

Vous n’avez pas besoin d’un data warehouse. Commencez avec un dashboard simple ou un audit récurrent.

1) Cycle time

Mesurez le temps entre :

• début du design → design approuvé
• design approuvé → build terminé

Si le système fonctionne, le cycle time doit diminuer pour des types de pages similaires.

2) Défauts / taux de rework

Suivez :

• le nombre de tickets QA liés à des incohérences (espacement, typographie, états hover)
• le nombre de corrections “le design ne matchait pas le build”

Un bon système les réduit.

3) Audits de cohérence

Faites un audit mensuel ou à chaque release :

• Combien de styles de texte uniques existent ?
• Combien de couleurs uniques sont utilisées ?
• Combien de valeurs d’espacement one-off apparaissent ?

Outils et tactiques :

• En code : règles stylelint, enforcement des tokens
• Dans Webflow : sessions périodiques de nettoyage des classes/variables
• En design : checks d’usage des styles/variables dans Figma

4) Taux d’adoption

Si une seule équipe utilise le système, ce n’est pas un système—c’est une préférence.

Suivez :

• % des nouvelles pages construites avec des composants du système

• d’overrides par page (objectif : réduire dans le temps)

Faire des “system retros” comme des sprint retros

Faites de l’évolution une partie de la livraison.

Une cadence simple :

• Toutes les 2–4 semaines : retro système de 30 minutes
• Revoir : ce qu’on a dupliqué, ce qu’on a bricolé, ce qu’on devrait formaliser
• Décider : 1–3 améliorations du système seulement (restez petit)

Prévoir la dépréciation (sinon la dérive gagne)

Si vous ne retirez jamais les anciens patterns, votre système devient un musée.

Politique de dépréciation pratique :

1. Marquer le composant/token comme déprécié
2. Fournir des consignes de remplacement
3. Fixer une date de suppression (ou une version de suppression)
4. Mettre à jour la documentation et les templates

---

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

Mode d’échec : “On a tout standardisé—et maintenant tous les sites se ressemblent”

Correctif : séparer la couche marque de la couche structure.

• Structure : grilles, échelle d’espacement, anatomie des composants
• Marque : couleur, typo, illustration, photographie, ton

Laissez les clients exprimer leur marque via la couche qui communique réellement la marque.

Mode d’échec : “On a construit une bibliothèque, mais personne ne l’utilise”

Correctif : optimiser les chemins par défaut, pas des règles parfaites.

• Fournir des templates de démarrage
• Fournir des sections de page faciles à assembler
• Faire en sorte que “la bonne façon” soit la façon la plus simple

Mode d’échec : “Figma est clean, Webflow est le chaos”

Correctif : traiter Webflow comme du code de production.

• Appliquer des conventions de nommage
• Limiter les classes one-off
• Créer un petit set de primitives de layout
• Utiliser Variables de façon cohérente

Mode d’échec : “Le système nous a ralentis”

Correctif : installer le processus à deux voies et réduire les approbations.

• Livrer d’abord
• Systématiser ensuite
• N’approuver que les breaking changes

---

Conclusion : construire un système qui se comporte comme une agence

Un design system vivant pour une agence n’est pas un monument—c’est un modèle opératoire.

• Commencez avec un Minimum Viable System : tokens sémantiques, composants réutilisables et patterns de contenu
• Adaptez la profondeur du système à la maturité du client (pas à votre ambition)
• Utilisez une gouvernance qui protège la vitesse : ownership claire, versioning léger, approbations uniquement pour les breaking changes
• Faites le pont design-to-build avec des variables et un nommage partagés pour que l’intention survive au handoff
• Prouvez l’impact avec le cycle time, les défauts, les audits et l’adoption—puis faites évoluer via des retros régulières

Si vous voulez livrer plus vite sans tuer la créativité, arrêtez de traiter votre design system comme un règlement. Traitez-le comme un produit : conçu pour de vrais utilisateurs (vos équipes), testé sous de vraies deadlines (le travail client), et amélioré en continu.

Les meilleurs design systems d’agence n’éliminent pas les exceptions—ils rendent les exceptions moins chères, plus sûres, et plus faciles à réintégrer dans le système.

---

Besoin d’aide pour construire un système vivant que votre équipe utilisera vraiment ?

Si vous êtes une agence ou un studio qui livre dans Webflow ou sur une stack front-end et que vous voulez un design system qui accélère la livraison (au lieu de devenir un fardeau de maintenance), nous pouvons vous aider à définir le bon niveau de système, mettre en place tokens/variables, et créer une gouvernance adaptée au travail client réel.