La checklist design system pour chaque équipe produit en 2026

La plupart des équipes qui construisent un design system finissent avec un magnifique fichier Figma que personne ne regarde six mois plus tard. Les composants s'éloignent du produit live. Les développeurs implémentent des choses from scratch parce que c'est plus rapide que de se battre avec le système. Les designers mettent à jour la bibliothèque et oublient de prévenir qui que ce soit.

Ce n'est pas un problème de design. C'est un problème de processus et de priorisation. Les équipes qui construisent des design systems réellement utilisés font trois choses différemment : elles commencent plus petit qu'elles ne le pensent nécessaire, elles sont obsédées par l'expérience de handoff développeur, et elles traitent le système comme un produit vivant plutôt qu'un livrable.

Dans l'écosystème des startups et scale-ups marocaines — que ce soit à Casablanca, Rabat ou Marrakech — ce défi est particulièrement répandu. Les équipes produit grandissent vite, les designs system sont construits dans l'urgence, et le résultat est souvent une incohérence coûteuse à long terme.

Voici la checklist qu'elles utilisent — et les principes qui la sous-tendent.

Ce qu'est réellement un design system (pas juste une bibliothèque de composants)

Un design system est la combinaison de trois éléments : les design tokens (vos primitives visuelles), les composants (les éléments UI réutilisables), et la documentation (les règles qui régissent comment et quand utiliser chaque élément).

Une bibliothèque de composants est juste la couche intermédiaire. C'est la partie qui semble la plus impressionnante dans une capture d'écran de portfolio, donc les équipes la construisent en premier. C'est à l'envers.

Sans tokens, vos composants sont codés en dur avec des valeurs magiques qui les rendent impossibles à thématiser, à mettre à jour globalement, ou à transmettre clairement. Sans documentation, vos composants sont utilisés incorrectement ou ignorés.

La checklist ci-dessous couvre les trois couches, dans l'ordre dans lequel vous devriez les construire.

La checklist : ce qu'il faut inclure

Fondation : les tokens

Les design tokens sont les valeurs atomiques que chaque composant référence. Ils sont la source de vérité unique pour votre langage visuel. Définissez-les en premier. Chaque décision en aval en dépend.

Tokens de couleur

Primaire de marque (et variantes sémantiques : hover, actif, désactivé)
Secondaire de marque
Échelle neutre (gray 50 à 950)
Couleurs sémantiques : succès, avertissement, erreur, info — chacune avec des variantes surface, défaut, et premier plan
Tokens de fond et de surface (fond de page, surface de carte, overlay)

Tokens d'espacement

Une échelle cohérente (base 4px la plus courante : 4, 8, 12, 16, 24, 32, 48, 64, 96)
Nommés comme space-1 à space-24 ou équivalent
Ne jamais utiliser de valeurs en pixels arbitraires dans les composants — toujours référencer un token

Tokens de typographie

Familles de polices (principale, mono si applicable)
Échelle typographique : display, niveaux de titre (h1–h4), corps grand/normal/petit, légende, label
Graisses référencées par nom (regular, medium, semibold, bold)
Hauteurs de ligne et espacements entre lettres par niveau d'échelle

Tokens de rayon de bordure

Un petit ensemble : aucun, sm, md, lg, full
Appliqués uniformément sur tous les composants

Tokens d'ombre

Niveaux d'élévation : sm (cartes), md (dropdowns), lg (modals)
Éviter les ombres ponctuelles dans des composants individuels

Composants de base

Ce sont les composants qui apparaissent dans chaque produit SaaS. Construisez ceux-ci avant tout le reste.

Bouton

Variantes : primaire, secondaire, ghost, destructif, lien
Tailles : sm, md, lg
États : défaut, hover, focus, actif, désactivé, chargement
Avec icône (avant et arrière), variante icône seule

Champ de texte

États : défaut, focalisé, rempli, erreur, désactivé, lecture seule
Avec label, placeholder, texte d'aide, message d'erreur
Avec icône ou ornement avant/arrière

Select / Dropdown

Sélection unique et multiple
Recherche intégrée
En-têtes de groupe
Option de suppression

Checkbox et Radio

Tous les états incluant indéterminé pour la checkbox
Disposition en groupe (vertical et horizontal)

Toggle / Switch

États on, off, désactivé
Avec label

Modal / Dialog

Structure en-tête, corps, pied de page
Tailles : sm, md, lg, plein écran
Comportement du bouton de fermeture

Toast / Notification

Types : succès, erreur, avertissement, info
Avec et sans bouton d'action
Comportement de disparition automatique

Badge et Tag

Couleurs sémantiques
Variante supprimable

Avatar

Avec image, fallback initiales, fallback icône générique
Tailles et variante groupe/pile

Composants de mise en page

Container — Wrapper max-width avec padding réactif Grid — Grille de colonnes réactive avec tokens de gouttière Stack — Utilitaire d'espacement vertical et horizontal Divider — Horizontal et vertical, avec label optionnel

Bibliothèque de patterns

Les patterns sont des compositions de composants de base résolvant des problèmes de design récurrents. Ils sont plus difficiles à construire mais éliminent le travail le plus répété.

Patterns de formulaires — Groupes de champs, mise en page de formulaire, labellisation requis/optionnel, résumé de validation Patterns de tableaux — Colonnes triables, sélection de ligne, pagination, état vide, skeleton de chargement États vides — Avec emplacement pour illustration, titre, corps de texte, action principale États de chargement — Écrans skeleton (préférés aux spinners pour les vues riches en contenu), indicateurs de progression Dialogues de confirmation — Pattern de confirmation d'action destructive avec structure oui/annuler claire En-tête de page — Titre, fil d'Ariane, description, emplacement d'action

Documentation

La documentation est ce qui distingue un design system d'une collection de frames Figma.

Pour chaque composant, rédigez :

Guide d'utilisation — Quand utiliser ce composant, quand ne pas l'utiliser
Explications des variantes — À quoi sert chaque variante (pas seulement à quoi elle ressemble)
Exemples à faire / à ne pas faire — Les cas d'usage incorrects les plus fréquents avec des exemples visuels
Props et tokens — Pour le handoff développeur : chaque prop, son type, sa valeur par défaut, et le token auquel elle correspond
Notes d'accessibilité — Comportement clavier, rôles ARIA, exigences de contraste minimum

Ce qu'il ne faut PAS inclure dans la V1

C'est là où la plupart des équipes échouent. Elles essaient de tout construire avant de livrer quoi que ce soit.

Ne construisez pas :

Chaque variante de cas limite avant que le composant de base soit validé
Les composants graphiques et de visualisation de données (ceux-ci sont assez complexes pour être un projet à part entière)
Les composants de pages marketing/landing (ceux-ci appartiennent à un système marketing séparé)
Des composants très personnalisés et ponctuels avant d'avoir été utilisés dans au moins deux contextes produit réels
Le système d'animation et de mouvement (tokenisez cela plus tard, une fois les composants stables)

Livrez une V1 du système avec les tokens de fondation, l'ensemble des composants de base, et la documentation. Tout le reste est V2.

Le rendre developer-friendly

Un design system que les développeurs ne peuvent pas implémenter efficacement ne sera pas utilisé. Cela signifie :

Variables Figma plutôt que styles statiques. Utilisez le système de variables de Figma pour mapper vos design tokens. Quand un développeur inspecte un composant, il doit voir color/primary/default, pas #4F46E5. Les noms des tokens doivent correspondre exactement à l'implémentation dans le code.

Auto-layout partout. Chaque composant doit être construit avec auto-layout pour que le redimensionnement et les changements d'état se comportent de manière prévisible. Les composants qui ne se redimensionnent pas correctement dans Figma ne seront pas utilisés.

Conventions de nommage qui correspondent au code. Les noms de vos composants dans Figma doivent correspondre aux noms de vos composants dans la base de code. Button/Primary/Large/Default dans Figma doit correspondre à <Button variant="primary" size="lg" /> dans le code.

Spécifications de handoff explicites. Pour chaque composant, documentez les valeurs de padding, l'espacement entre les éléments, la taille et la graisse de police, les valeurs de bordure et tous les changements d'état. Les développeurs ne devraient pas avoir besoin de demander à un designer à quoi ressemble l'état hover.

Le maintenir dans le temps

Un design system qui n'est pas maintenu devient une responsabilité. La façon de le maintenir est de le traiter comme un produit.

Assignez la propriété. Il doit y avoir une personne nommée (ou une rotation nommée) responsable de la révision des changements, de la mise à jour de la documentation, et de la communication des mises à jour à l'équipe.

Versionnez-le. Chaque changement cassant doit être versionné. Les équipes utilisant le système doivent savoir ce qui a changé et pourquoi.

Créez un processus de contribution. Quand un designer construit quelque chose de nouveau qui appartient au système, il doit y avoir un processus clair pour proposer, réviser, et merger cela. Sans cela, le système prend du retard sur le produit.

Auditez-le trimestriellement. Tous les trois mois, vérifiez quels composants ont divergé du produit live, lesquels ne sont pas utilisés, et quels nouveaux patterns ont émergé et doivent être codifiés.

Construire un design system est l'un des investissements à plus fort effet de levier qu'une équipe produit peut faire. Bien réalisé, il réduit le délai design-développement, élimine les incohérences visuelles et accélère l'ensemble du cycle produit.

Mal réalisé, c'est un fichier Figma que personne n'ouvre.

Je suis Mehdi Yatrib, designer produit basé à Casablanca. J'aide les équipes SaaS au Maroc et à l'international à construire des design systems que leurs développeurs utilisent vraiment — de l'architecture des tokens à la documentation des composants.

Réservez un projet design system sur yatrib.me