Un petit site a-t-il besoin d’un système de design ?

En dessous de cinq pages, quelques conventions suffisent. À partir de dix pages, le système rembourse le temps qu’il a coûté, surtout si le site doit grandir ou paraître en plusieurs langues.

En quoi diffère-t-il d’une charte de marque ?

La charte décrit l’apparence visée. Le système est le code qui la produit. Un PDF ne peut jamais faire échouer un build, et c’est précisément cette fonction qui tient l’expression dans la durée.

Comment le thème sombre est-il traité ?

Chaque token porte une valeur pour le thème clair et une pour le thème sombre. Le contraste est calculé sur les deux, si bien qu’un thème ne peut jamais être moins bon que l’autre.

À qui appartient le système de design après la mise en ligne ?

À vous, et il vit dans votre dépôt. Il est bâti pour qu’une autre développeuse puisse reprendre : les valeurs à un seul endroit, les composants documentés et le contrôle intégré au build.

À quelle fréquence refait-on un système de design ?

Rarement en entier. Les tokens changent avec la marque et les composants s’ajoutent au fil de l’eau. Un système à réécrire tous les deux ans avait été bâti pour une seule campagne.

Peut-on introduire un système sur un site existant ?

Oui, un type de page à la fois. Commencez par les tokens et les composants les plus utilisés, activez le contrôle sur les dossiers déjà convertis, puis étendez de là.

Quand un système de design devient rentable

Torn StudioPublié 2026-08-273 min de lecture

Torn Studio est une agence d’IA qui construit des sites, des produits numériques et du contenu. Peu conventionnel.

Réponse courte

Un système de design se compose de tokens pour la couleur, la typographie et les espacements, de composants bâtis avec eux, et d’un contrôle dans le build qui refuse les valeurs libres. D’après notre expérience, il devient rentable vers la dixième page ou au deuxième changement de marque.

Un système de design est le plus souvent décrit comme une collection de composants. La partie la plus décisive est la règle sur l’endroit où les valeurs ont le droit d’habiter, car c’est elle qui décide si le système tient encore dans six mois.

Ce que le système contient réellement

Quatre couches, et la dernière est ce qui sépare un système d’un dossier de fichiers.

Les tokens : chaque couleur, espacement, rayon et taille de texte définis à un seul endroit
Les primitives : boutons, cartes, titres et champs bâtis avec les tokens
Les blocs : des sections finies à partir desquelles les pages sont assemblées
Un contrôle dans le build qui arrête les valeurs brutes dans le code des pages

Le contrôle est ce qui rend le système vrai

Un système qui n’existe que sous forme de document se disloque, parce que taper une couleur est toujours plus rapide que chercher le bon token. Ce site fait tourner ce contrôle : une étape du build lit le code et échoue à la première valeur hex ou pixel brute hors du système de design. Ensuite la question cesse de se poser.

Le contraste se calcule avant l’usage de la couleur

Chaque paire de couleurs du système est vérifiée face à WCAG AA, qui demande au moins 4,5:1 pour le texte courant. Le calcul étant fait au niveau des tokens, aucune page ultérieure ne peut devenir illisible, puisque la combinaison qui le provoquerait n’existe pas.

La taille à partir de laquelle c’est rentable

En dessous de cinq pages, un système coûte plus qu’il ne rapporte. À dix pages, l’équilibre est atteint. À 30 pages et neuf langues, c’est la différence entre une journée de travail et une semaine lorsqu’une chose doit changer partout — le calcul que nous avons fait pour ce site.

Les petits écrans font partie du système

Chaque composant est dessiné d’abord pour 320 pixels, puis grandit. Les tests parcourent chaque type de page dans neuf largeurs à partir de 320 pixels, et une page qui défile horizontalement fait échouer le build. Cela revient moins cher que de réparer une mise en page mobile cassée après la mise en ligne.

Preuves

Sur quoi repose cet article — une mesure que nous avons faite, une source datée ou une décision et son coût.

Décision2026-08-26
Le contraste est une barrière de build : un test recalcule à chaque modification chaque paire autorisée de texte et de surface à partir du fichier de tokens et fait échouer le build sous WCAG AA 4,5:1.
Ce qu’elle a coûté: Une couleur plus belle mais moins bien mesurée ne peut pas être livrée ; une partie de la palette est donc fermée par le calcul, et chaque modification de la gamme coûte une nouvelle exécution et souvent un réajustement des tokens voisins.

Questions fréquentes

Un petit site a-t-il besoin d’un système de design ?: En dessous de cinq pages, quelques conventions suffisent. À partir de dix pages, le système rembourse le temps qu’il a coûté, surtout si le site doit grandir ou paraître en plusieurs langues.
En quoi diffère-t-il d’une charte de marque ?: La charte décrit l’apparence visée. Le système est le code qui la produit. Un PDF ne peut jamais faire échouer un build, et c’est précisément cette fonction qui tient l’expression dans la durée.
Comment le thème sombre est-il traité ?: Chaque token porte une valeur pour le thème clair et une pour le thème sombre. Le contraste est calculé sur les deux, si bien qu’un thème ne peut jamais être moins bon que l’autre.
À qui appartient le système de design après la mise en ligne ?: À vous, et il vit dans votre dépôt. Il est bâti pour qu’une autre développeuse puisse reprendre : les valeurs à un seul endroit, les composants documentés et le contrôle intégré au build.
À quelle fréquence refait-on un système de design ?: Rarement en entier. Les tokens changent avec la marque et les composants s’ajoutent au fil de l’eau. Un système à réécrire tous les deux ans avait été bâti pour une seule campagne.
Peut-on introduire un système sur un site existant ?: Oui, un type de page à la fois. Commencez par les tokens et les composants les plus utilisés, activez le contrôle sur les dossiers déjà convertis, puis étendez de là.

Prochaines étapes

À lire ensuite

Aller plus loin

Travailler avec nous