Design-to-Code · 2 novembre 2026

La dette de design existe, et elle se mesure

On parle de dette technique avec des chiffres et de dette de design avec des impressions. Pourtant elle se compte, et le calcul tient en une heure.

La dette technique a ses chiffres : couverture de tests, temps de construction, nombre d'alertes, vulnérabilités ouvertes. On peut la mettre dans un tableau et la défendre devant une direction.

La dette de design, elle, se discute en impressions. « C'est devenu incohérent. » « On a dérivé. » « Il faudrait reprendre ça. »

Ces phrases ne pèsent rien face à une feuille de route chiffrée, et c'est la vraie raison pour laquelle les chantiers de design system passent toujours après.

Ce n'est pourtant pas une fatalité. Elle se compte.

Pourquoi elle est perçue comme non mesurable

Trois idées reçues, toutes fausses.

« C'est subjectif. » La cohérence d'une interface ne l'est pas. Soit un bouton a le même rayon, la même hauteur et la même graisse que son composant de référence, soit il ne les a pas. On peut le vérifier élément par élément.

« Ce n'est pas grave, ça reste joli. » C'est l'argument le plus trompeur, parce qu'il est en partie vrai. Une interface qui dérive reste souvent présentable. Le coût n'est pas esthétique : chaque composant recodé est un endroit de plus à modifier le jour où la marque change, un comportement de plus à tester, une correction d'accessibilité qui ne se propage pas.

« On le sait déjà. » Non. Les équipes qui mesurent découvrent presque toujours un chiffre très inférieur à leur estimation. Entre l'impression d'incohérence et son ampleur réelle, l'écart est systématique.

Ce qu'on compte exactement

La définition doit être écrite avant de commencer, sinon le chiffre n'est pas défendable.

On compte les composants d'interface visibles : boutons, champs, menus, cartes, onglets, étiquettes, badges, alertes, en-têtes de tableau. Pas le texte brut, pas les images de contenu, pas les conteneurs de mise en page.

Pour chacun, deux questions dans l'ordre. Existe-t-il un équivalent dans le système ? Et le rendu correspond-il ?

D'où trois catégories :

Conforme. Il vient du système, le rendu correspond.

Dérivé. Le composant existe au système, mais le rendu s'en écarte. Un rayon de 6 pixels au lieu de 8, une hauteur de 38 au lieu de 40.

Hors système. Rien ne lui correspond.

Trois catégories pour chaque composant visible : conforme, il vient du système et le rendu correspond ; dérivé, il existe au système mais le rendu s'en écarte, par exemple un rayon de 6 px au lieu de 8 ; hors système, rien ne lui correspond. Le piège : ranger les dérivés avec les conformes

La catégorie que tout le monde range du mauvais côté

Les dérivés.

C'est là que se joue la crédibilité de l'exercice. Un composant dérivé a toutes les apparences d'un composant conforme : il vient du bon endroit, il porte le bon nom, il ressemble à ce qu'il devrait être. On le compte donc avec les conformes, et le taux obtenu est flatteur.

Mais un dérivé ne se met pas à jour avec le système. Il porte sa propre valeur, écrite quelque part dans l'écran. Le jour du changement de marque, il faudra le retrouver à la main.

Compter les dérivés comme conformes, c'est précisément la raison pour laquelle les équipes pensent leur design system adopté alors qu'il ne l'est qu'à moitié. J'ai fait le calcul sur mon propre produit, et l'écart entre les deux manières de compter est considérable.

Le protocole, en une heure

Trois écrans, de nature différente. Un écran de consultation, un écran de saisie, et un écran secondaire que personne ne regarde jamais. Commencez par le troisième : c'est toujours là que l'écart est le plus grand, et vous aurez votre chiffre le plus parlant en dix minutes.

L'inspecteur du navigateur comme instrument. Clic droit sur un composant, inspecter, et le panneau des styles calculés donne les valeurs exactes. On compare avec la référence. Un écart d'un pixel suffit à classer en dérivé, et c'est factuel, pas une impression.

Une colonne pour l'origine. Pour chaque dérivé, noter s'il a été recodé entièrement ou importé puis modifié. Cette distinction est la plus utile du tableau, parce qu'elle sépare deux problèmes opposés : des développeurs qui ignorent le système, et des développeurs qui l'utilisent mais le contournent. Les corrections ne sont pas les mêmes.

Un taux par écran, et un total. Publier uniquement le total masque le fait qu'un seul écran porte souvent l'essentiel de l'écart.

Grille du protocole : les écrans consultation, saisie et écran secondaire, à commencer par ce dernier, puis un total, avec les colonnes conforme, dérivé, hors système et origine des dérivés (recodé ou importé puis modifié)

Ce que le chiffre change

Il transforme une opinion en point à l'ordre du jour.

« Je trouve qu'on a dérivé » ne déclenche aucune décision. « Sur nos trois écrans principaux, un composant sur quatre rend fidèlement le système, et la moitié des écarts viennent de composants recodés à la main » en déclenche une, parce que c'est un constat et non un avis.

Il donne aussi un point de départ. Remesurez dans trois mois : c'est le seul moyen de savoir si vos règles servent à quelque chose.

Ce qu'il faut retenir

Tant que la dette de design reste une impression, elle perdra tous les arbitrages face à des sujets chiffrés.

Une heure, trois écrans, une définition écrite. C'est le prix d'entrée pour que le sujet existe.


Vous soupçonnez un écart entre votre design system et votre produit ? Je mesure, et le chiffre rend la conversation possible. Parlons-en.