Design-to-Code · 2 novembre 2026

Le débat « le designer doit-il coder » est mal posé

La vraie question n'est pas d'écrire du code, c'est de connaître le coût de ce qu'on dessine. Un designer qui sait qu'une animation coûte trois jours ne dessine pas la même chose.

C'est une question qui revient tous les deux ans, qui divise sincèrement, et qui ne se résout jamais. Normal : elle est mal formulée.

Parce que personne ne cherche vraiment à savoir si un designer sait écrire une boucle. Ce qu'on cherche à savoir, c'est s'il comprend ce que ses décisions coûtent.

Et ça, ce n'est pas la même compétence.

Les deux camps ont chacun une bonne raison

Contre. Le temps passé à apprendre un langage est du temps qui ne va pas à la recherche utilisateur, à la pensée systémique, à la compréhension du métier. Un designer médiocre en code reste un designer qui a sacrifié son cœur de métier pour une compétence qu'un développeur exerce mieux que lui.

Pour. Un designer qui ne connaît rien à la fabrication dessine des choses irréalisables, découvre les contraintes trop tard, et passe son temps à renégocier des décisions déjà prises.

Les deux arguments sont justes, ce qui explique que le débat dure. Ils ne parlent simplement pas de la même chose.

Ce qui compte vraiment : connaître le coût

Un designer qui sait qu'un tableau avec colonnes réordonnables, tri multiple et édition en ligne représente plusieurs semaines ne le dessine pas de la même façon que celui qui l'ignore.

Il ne va pas forcément y renoncer. Mais il va poser la question autrement : de quoi a-t-on réellement besoin dans cette liste, et qu'est-ce qui peut attendre ?

C'est cette connaissance qui change les conversations, et elle ne demande pas de savoir programmer. Elle demande de savoir ce qui est cher et pourquoi.

Quelques exemples de choses qu'il est précieux de savoir, sans écrire une ligne de code : qu'une liste qui doit rester fluide à dix mille éléments ne se construit pas comme une liste de cinquante. Qu'un état en temps réel partagé entre plusieurs utilisateurs est un problème d'une autre nature qu'un affichage simple. Qu'une animation sur un élément qui se déplace coûte beaucoup plus cher qu'une animation sur un élément qui change de couleur. Qu'une exception dans une règle métier se paie à chaque écran, pour toujours.

Aucun de ces points n'est du code. Ce sont des ordres de grandeur.

Ce que le designer gagne vraiment à savoir faire

Si l'on sort du débat binaire, trois compétences techniques changent réellement le travail, et aucune ne consiste à construire une fonctionnalité.

Lire le produit existant. Ouvrir l'inspecteur du navigateur, regarder les valeurs réelles d'un composant, constater un écart avec la référence. C'est ce qui permet de mesurer la dette de design plutôt que de la ressentir.

Penser en composants et en propriétés. Raisonner comme le code compose plutôt que comme l'outil de design empile. C'est la condition pour qu'un système existe des deux côtés.

Produire une version fonctionnelle imparfaite. Pas pour livrer, pour décider. Une interface qui marche à moitié tranche une question en vingt minutes là où une maquette en demande trois.

Cette troisième compétence est celle qui a le plus changé récemment, parce qu'elle est devenue accessible sans maîtriser un langage. C'est aussi ce qui retire au wireframe une partie de sa raison d'être.

L'inverse est tout aussi vrai

On pose rarement la question dans l'autre sens, et elle mériterait de l'être.

Un développeur qui ne connaît rien au design produit des interfaces qui fonctionnent et que personne ne comprend. Il recode un composant plutôt que d'importer celui du système, parce qu'il n'a jamais vu ce que la dérive coûte à l'échelle du produit.

La question « le développeur doit-il designer » est exactement aussi mal posée, et sa bonne version est la même : est-ce qu'il connaît le coût de ses décisions pour l'utilisateur ?

La formulation que je préfère

Plutôt que « le designer doit-il coder », je pose : est-ce qu'il peut estimer, à l'ordre de grandeur près, ce que coûte ce qu'il vient de dessiner ?

Cette question a trois avantages. Elle ne présuppose aucune compétence particulière, elle se vérifie en une conversation, et elle a une réponse utile : si c'est non, la solution n'est pas une formation au code, c'est une habitude de travail. Demander systématiquement l'estimation avant de valider une direction.

Une équipe où cette conversation a lieu à chaque écran produit des designers qui connaissent les coûts au bout de quelques mois, sans que personne n'ait appris un langage.

Ce qu'il faut retenir

Savoir coder est un moyen, pas un objectif. Certains designers passent par là, d'autres acquièrent la même connaissance en travaillant étroitement avec des développeurs.

Ce qui n'est pas optionnel, c'est de savoir ce que ça coûte. Un designer qui l'ignore ne conçoit pas, il propose.

Votre équipe design et votre équipe technique renégocient les mêmes décisions à chaque sprint ? C'est presque toujours un problème de coût invisible. Parlons-en.