Comment je fais du design en tant que dev backend?

Imaginez le lieu. Il fait sombre, il n’est que 18h mais l’hiver et le froid se sont invités.

Nous sommes dans une salle de classe, insalubre et pas chauffé comme toutes les salles de classe de banlieue parisienne, parce que Monsieur “C’EST NOTRE PROJET !!!” a décidé que c’était plus intéressant de payer des millions d’Euros pour des powerpoint McKinsey que d’investir dans notre avenir ! … Je m’égare.

Bref, un cercle de personnes se réunit, sur des petites chaises en bois qui font mal au cl sa #!@ . Je suis présent, la mine grave. Non en fait j’ai pas écouté Jean-Michel qui vient de parler mais j’essaye toujours de comprendre comment les Spurs ont pu merder à ce point dans les derniers matchs de cette finale NBA 2026.

Et puis je me lève et je me présente.

“Bonjour je suis Hugo Lassiège, je suis avant tout développer backend et voici ma première version de Malt en 2012”

Bref, je suis nul en design.

Alors comment en 2026 j’arrive à proposer des designs comme celui de ce blog ? C’est ce que je vous propose de voir dans ce billet.

2011, l’armée des clones

2012 c’était quand même il y a longtemps et à l’époque j’utilisais Bootstrap majoritairement, ce qui explique ce petit style très caractéristique de la première capture d’écran (mixé avec des goûts esthétiques franchement discutables, je vous l’accorde).

Parce que oui, en 2011 sort un framework, Bootstrap si vous avez suivi, qui propose de mettre à disposition l’UI kit officiel utilisé chez Twitter. On retrouve dedans les lignes directrices pour faire des boutons, des formulaires, des barres de progression, tout ça dans l’esprit de l’oiseau bleu. On retrouve également tous les outils pour faire plus facilement des sites responsives avec le fameux système de grille qui va perdurer longtemps. Très longtemps.

Pour les devs backend comme moi, c’est à dire ceux ayant un gout plus que modéré pour le design, c’était l’occasion de partir sur des bases simples pour, enfin, faire des sites web qui n’ont pas l’air sorti de l’imaginaire d’un koala sous acide.

Dans la foulée de Bootstrap plusieurs autres librairies vont sortir, Foundation, Materializecss, et j’en passe mais toujours avec ce petit syndrome pour les sites qui les utilisent de “mais bordel, c’est quoi cette armée de clones”.

Du design atomique aux design systems

Maintenant c’était bien beau d’avoir une grille standard et des boutons, encore fallait il les assembler ensemble. Si les boutons, champs de saisie, blocs de texte étaient des atomes, il fallait donner une structure pour les assembler sous forme de molécules.

C’est exactement cette analogie qui sera poussée progressivement à partir de 2013/2014 par Brad Frost, sous le nom d’Atomic Design.

Cette notion de molécules, c’est en réalité aussi ce qu’on pourrait appeler un composant. Un composant fixe l’assemblage de nos molécules ainsi qu’un comportement. Et c’est exactement ce qu’on retrouve dans plusieurs frameworks sortis dans la même période, React (2013), Vue (2014) et même plus généralement les Web Components (2011).

Pour l’anecdote, dans ma précédente boite (Malt) on a grandi dans la même période, on s’est dit que ce serait une super idée de mixer tout ça. On a fait du Bootstrap, puis on a regroupé tout ça avec un framework maison (les HopModules), on a ajouté Vue vers 2015, puis construit des Web Component, puis utilisé Nuxt un peu plus tard pour finalement se rendre compte vers 2023 que quand même, ca faisait beaucoup tout ça…

(Mais c’est une autre histoire que je raconte ici).

Bref, on a commencé à construire des “composants” qu’on a assemblé, standardisé pour finalement aboutir à ce qu’on appelle aujourd’hui, un design system, c’est à dire des sortes de briques de légo qu’on peut assembler ensemble et qui garantissent une certaine identité, une voix pour un site. Design system qui sont même souvent publics et que vous pouvez trouver et étudier sur différents sites.

Tailwind et les design tokens

Pour construire un design system, il manquait une brique. C’est bien beau de dire par exemple que vos boutons ont un border radius de 4px. 4, pas 2, pas 6 mais 4.

Et c’est plutôt simple à exprimer globalement :

.button { border-radius: 4px; }

Mais imaginons que vous vouliez aussi aligner ce radius sur toutes vos card ?

Imaginons que vous souhaitiez définir un padding global, une couleur “primaire” pour vos boutons principaux, les tailles de polices possibles sur l’ensemble du site.

Si le bouton est l’atome, il réalité il manquait un élément en dessous, comment on créé nos atomes ?

Courant des années 2010 (peut être via Jina Anne chez Salesforce en 2014), une personne introduit un nouveau terme : le design token.

Un design token c’est la définition de la structure de l’interface par ces tokens.

Par exemple :

• #0055ff devient le token color-brand-primary
• 16px devient le spacing-medium

etc…

Et c’est exactement l’approche de Tailwind en 2017 qui arrive avec des définitions de design tokens via tout un tas de classes utilitaires qui vont devenir très très utilisé dans les sites actuels.

Alors, Tailwind ne fait pas l’unanimité pour de nombreuses raisons et ca n’a jamais été introduit chez Malt. Mais pour mes nouveaux projets, c’est devenu la solution par défaut. Et maintenant on peut parler de mon workflow de design :)

Mon workflow pré 2024, Tailwind et ses librairies de composants

Pré 2024 (bientôt on parlera de l’ère pré agent IA…) je lançais Hakanai.io. On va pas se voiler la face, c’est mieux que ce je faisais en 2012, mais ça reste aussi gai qu’un jour d’automne à Melun.

Malgré tout, ici on retrouve mon workflow design de 2024, l’usage de Tailwind et de libraires de composants tels que preline.io ou Flowbite.com. C’est un assemblage de blocs plus ou moins cohérents visuellement mais qui ont l’avantage d’avoir une cohérence structurelle via les designs tokens de Tailwind.

Ca a l’air de rien mais c’est déjà bien. Les espacements et les respiration sont cohérents, les couleurs donnent une identité, les polices sont uniformes, bref, c’est un design system correctement utilisé. Alors oui, même Harry Potter vidé de son âme par un détraqueur a meilleure mine mais, ça marche.

Et c’est globalement l’esprit de la plupart des sites “indie” sortis dans cette période. Correct. Mais qui casse pas 3 pattes à un canard.

Et puis vint l’IA

A partir de 2024 jusque début 2025, mon workflow est devenu moins manuel. J’ai commencé à construire des interfaces en demandant à Claude de le faire. C’était encore des copiers coller entre le chat dans le navigateur et mon IDE. C’était uniquement du HTML/JS/CSS et ensuite je faisais l’adaptation à la main.

Et puis Claude est passé dans l’IDE, donc il a pu directement créer les maquettes dans mon code. Cependant Claude reproduit le style qu’il voit dans les autres pages, donc puisque le site a été créé pré 2024, eh bien il a reproduit mon style un peu “meeehhh” d’avant.

Donc déjà en 2025, j’ai commencé à changer de workflow pour certaines pages et notamment les premiers thèmes disponibles sur writizzy.com. J’ai commencé à partir d’une feuille blanche, en donnant quelques contraintes mais en faisant en sorte que Claude ne se repose pas un existant.

Parfois je lui ai demandé de s’inspirer de logiciel connus, ici avec Notion :

Malgré tout, Claude à une certaine tendance au bout d’un moment à produire un peu toujours les mêmes patterns et on peut de plus en plus reconnaitre une interface faite par une IA. C’est propre, c’est mieux que ce que je produis seul, mais ça manque d’originalité. Pour interface d’administration dans un SAAS c’est pas bien grave mais pour se démarquer sur internet, il faut faire plus d’efforts.

J’ai commencé à voir apparaitre des skills pour éviter la “slopification” : tasteskill et impeccable mais que je n’ai pas personnellement testé. Par contre depuis quelques temps j’utilise systématiquement Claude Design et là, je vois une amélioration significative de ce que je produis.

Déjà, Claude Design, qu’est ce que c’est ?

Claude design est spécialement optimisé pour la création d’interface, que ce soit pour ses instructions systèmes qui sont optimisés pour l’UI (mais pas l’UX !!), et par son outillage.

CD va en effet pouvoir visualiser le résultat et itérer en autonomie via des screenshots. Vous pourrez avoir un panneau de “tweaks” pour visualiser des options, faire des mockups low fidelity ou des interfaces abouties, commenter des zones, etc…

Mais surtout CD peut partir d’un screenshot pour avoir une ambiance. Donc si je prends le theme tux qu’on peut apercevoir dans la capture d’écran ci-dessus, je suis parti d'un site dont j’appréciais l’ambiance graphique, je lui ai fourni une image et des instructions pour qu’il reprenne l’essence : les quadrillages, les accents particulièrement vifs à certains endroits, les soulignés inclinés et épais etc… J’ai du itérer, le premier jet avait des soucis mais le résultat est plutôt intéressant.

La grande limitation c’est que CD ne peut pas comprendre les animations (sauf à lui copier coller le code de la page html), or c’est une des forces du site d’origine et pour l’instant ca reste encore une faiblesse de mon workflow.

Un autre cas d’usage, c’est de partir d’un design system. Vous pouvez en définir un directement, ou itérer sur la base du modèle qui vous semble le plus pertinent. Ici par exemple, c’est le dashboard Writizzy dans son nouveau style. Et désormais chaque nouvelle page repart de celle-ci qui sert de “design system” pour construire les suivantes.

En condensé mes workflows sont les suivants :

• création d’une maquette avec Claude Design avec 3 options :
  • à partir d’un brief
  • à partir d’un screenshot
  • à partir d’un design system
• implémentation dans mon propre code via un skill "implement-mockup” qui explique comment transcrire le code html produit par Claude dans mes technos (nuxt-ui, tailwind)

Et plus récemment, je suis en train de tester :

• utilisation de agent-browser ou playwright pour faire tester l’interface, notamment en responsive

Alors ne vous y trompez pas, je préfère largement bosser avec un designer et je le ferais quand Writizzy sera plus gros. Mais pour démarrer, pour un site indie, ca reste largement mieux que ce que je pouvais faire avant et le niveau d’attente par les utilisateurs est devenu tellement plus grand désormais que de toute façon, c’est plus vraiment une option de faire “comme avant”. Parce que oui, le design ça donne une voix à un site, une identité. Ca et bien sûr le texte, sur la page, la façon dont on s’adresse aux lecteurs. Sans identité, un site, une application, ça ne retient pas l’attention.

C’est bien sûr moins vrai sur un article de blog, vous venez lire le contenu, pas le contenant, ou sur une interface d’administration d’un logiciel. Mais quand même, vous avez pas envie d’être puni visuellement et de donner une impression de “meeehhh”.

Maintenant prenons un peu de hauteur, est ce que c’est parfait ? Non.

Oui si on regarde le chemin parcouru en 15 ans, c’est plus simple de construire des sites web. Depuis Bootstrap on a cherché l’ordre, la structure, la standardisation et ça marche.

Mais à quel prix ? On a classé des composants, documenté des marges, figé des systèmes. On a rationalisé le beau. Le problème, c’est qu’à force de tout vouloir systémiser, on a créé un web incroyablement propre, mais terriblement chiant. Un web sans friction, mais sans âme. Et l’IA, par sa nature même, est la reine absolue pour reproduire ce genre de consensus tiède. Si vous lui demandez du "propre", elle vous fera du propre.

Est-ce que je suis des fois un peu nostalgique du web moche du début des années 2000 ? Peut-être.

Enfin, pas toujours…. Ca dépend ! Je sais pas !!!

Mais peut-être que justement, si l’IA nous déleste de la tuyauterie, si la technique est automatisée, c’est l’occasion pour nous de remettre de l’intention, de l’identité, de l’émotion (je pensais pas écrire ça un jour). Peut-être que c’est ça l’évolution des prochaines années, casser les codes, et refaire du moche, mais avec une belle voix.