Par Thales (Juste Gnimavo) — CEO & Fondateur, ZeroSuite, Inc.
Note sur le client : L'ERP de gestion de flotte utilisé comme exemple concret dans cet article est désigné sous le pseudonyme KASSIA. Le nom réel de l'entreprise et son domaine sont masqués à la demande du client pendant l'achèvement de son site public, et seront rétablis dès son lancement.
J'ai longuement écrit sur Claude Code. Les agents parallèles, les boucles d'audit, les plans de travail sur plusieurs jours confiés à un ingénieur que j'ai formé à mon codebase. J'ai écrit sur Web Claude — le partenaire stratégique qui garde le contexte sur plusieurs jours et qui me reprend quand mon cadrage dérive.
Il y a un troisième membre de l'équipe dont presque personne ne me parle. Et c'est, de plus en plus, celui par lequel je commence chaque projet.
Claude Design.
L'espace de travail de Claude Design sur claude.ai. À gauche, un brief de design engagé en amont — esthétique, typographie, tokens de couleur, mise en page, animation. Au centre, les composants et les documents de specs qu'il a générés. À droite, un aperçu live du résultat. C'est une surface de design avec gestion de versions et de fichiers, pas une fenêtre de chat.
Quand les gens imaginent « construire du logiciel avec l'IA », ils imaginent la génération de code. Un prompt entre, une fonction sort. Toute la conversation sur le développement augmenté par l'IA est bloquée sur la surface ingénierie. Pendant ce temps, la partie du produit qui décide réellement si un utilisateur lui fait confiance — la partie qui décide si un parent à Abidjan confie son argent, si un gestionnaire de flotte croit les chiffres à l'écran — est traitée comme une réflexion après coup. « Rends-le joli. » « Ajoute un peu de finition. » Comme si le design était une couche de peinture qu'on applique à la fin.
Je procède désormais à l'inverse. Sur tout nouveau projet, Claude Design passe en premier, et il possède l'intégralité du système visuel et UX de bout en bout avant que Claude Code n'écrive une seule ligne de code de production. Pas une maquette. Pas un mood board. Un système de design complet, versionné, de niveau production — tokens, composants, prototypes fonctionnels, et le langage de design des fonctionnalités IA à l'intérieur du produit.
Laissez-moi vous montrer exactement ce que cela signifie, avec un exemple réel, puis vous donner le processus que je déroule à chaque fois.
L'erreur que presque tout le monde commet
Le workflow par défaut en 2026 ressemble à ceci : vous avez une idée, vous ouvrez Claude Code ou Cursor, vous décrivez l'application, et vous lui demandez de la construire. Le modèle échafaude un projet, câble quelques routes et — parce que vous avez demandé une application fonctionnelle — il prend des décisions de design à la volée. Il choisit une police. Il choisit un bleu. Il glisse quelques cartes arrondies et un dégradé. Il livre quelque chose qui fonctionne.
Et ça ressemble à tout ce qui est livré de cette façon. Les mêmes valeurs par défaut de shadcn. Le même dégradé hero indigo-vers-violet. La même odeur générique de SaaS. J'appelle ça du slop non pas parce que c'est cassé, mais parce que c'est anonyme. Ça n'a aucun point de vue. Personne n'a rien décidé ; les décisions étaient un effet secondaire d'un prompt d'ingénierie.
Voici ce que les product people expérimentés savent et que les débutants ignorent : on ne peut pas greffer un système de design après coup. Le temps que Claude Code ait écrit quarante composants, chacun a pris une décision indépendante sur l'espacement, sur le rayon des coins, sur l'aspect d'un état désactivé, sur ce que « danger » signifie visuellement. Il n'y a aucun langage partagé. Refactoriser tout ça vers la cohérence plus tard coûte plus cher que de l'avoir conçu en amont. C'est vrai pour les équipes humaines et c'est exactement aussi vrai pour les équipes IA.
La solution n'est pas « demander à Claude Code de faire plus attention au design ». La solution est de séparer complètement la surface. Le design est un contexte opérationnel différent, avec un format de sortie différent, un niveau d'exigence différent et un type de prompt différent. Le confondre avec l'ingénierie est l'erreur racine.
Ce que Claude Design produit réellement — un exemple concret
Il y a quelques semaines, j'ai démarré un nouveau projet : un ERP de gestion de flotte premium pour une entreprise de transport ouest-africaine — désignée ici sous le nom de KASSIA. Le produit gère de l'argent : dépôts des chauffeurs, contrôles anti-fraude, une piste d'audit en ajout seul, séparation des pouvoirs entre les rôles (le comptable valide ce que le caissier enregistre ; rien n'écrit dans la base de données sans qu'un humain disposant du bon rôle n'approuve). Le genre de produit où une faute de frappe dans un chiffre, ou un écran qui fait bon marché, vous coûte la confiance du client dès le premier jour.
C'était un projet greenfield. Aucun codebase existant. Aucun fichier Figma. Aucune équipe de design. Ce que j'avais, c'était un brief produit et une identité de marque héritée que je voulais élever, pas jeter.
J'ai donné ce brief à Claude Design. Voici ce qui est revenu — et je veux être précis, car le périmètre est tout l'enjeu :
Un système de tokens complet. Pas « voici quelques couleurs ». Un ensemble de fichiers de tokens CSS en couches : des rampes de couleurs primitives (un bleu marine profond pour la confiance et la précision, un bordeaux réservé aux actions sensibles et bloquantes, un or pour l'emphase premium, un dégradé azur-vers-violet comme signature des fonctionnalités IA), puis des tokens sémantiques par-dessus (surface, bordure, le vocabulaire des statuts anti-fraude — validé, en attente, bloqué, en retard — chacun associé à un sens, pas à un hex brut). Des tokens typographiques : une famille display, une famille de corps humaniste, une famille monospace réservée aux chiffres financiers et aux empreintes d'audit, avec des chiffres tabulaires partout où l'argent apparaît. Un espacement sur une grille de 4px. Un système complet d'élévation et de « glow » qui distingue la profondeur neutre (les ombres) du signal (le glow est réservé à l'orbe IA et aux états actifs — on ne fait jamais glow une surface neutre). Des tokens de motion : durées, courbes spring, les keyframes de la respiration et de l'écoute de l'orbe IA. Et tout cela thémé pour le mode clair et le mode sombre dès le départ, avec un mode sombre conçu pour être spectaculaire plutôt qu'une inversion bâclée après coup.
Une bibliothèque de composants — avec des contrats. Environ deux douzaines de primitives React : boutons, boutons à icône, badges, badges de statut, avatars, champs de saisie, interrupteurs, cartes, cartes de statistiques, onglets, sparklines, jauges, tableaux de données, modales, toasts, tooltips, une palette de commandes. Mais voici ce qui en fait un système et non un tas de maquettes : chaque composant est livré avec un contrat TypeScript .d.ts définissant ses props, et une carte .prompt.md expliquant quand et comment l'utiliser. Un manifeste relie le tout. Ce n'est pas « l'IA a dessiné quelques boutons ». C'est un designer senior qui livre une bibliothèque de composants typée avec sa documentation d'usage — l'artefact exact que produit une vraie équipe de design system, sauf qu'il est produit dans un workflow piloté par le chat, à partir d'un brief.
Le langage de design des fonctionnalités IA. Tout le moat de ce produit est une IA vocale embarquée — l'interface principale, pas un widget annexe. Claude Design en a produit le langage de design : un orbe vocal avec des états définis (respiration au repos, un égaliseur à l'écoute, un halo rotatif à la réflexion), une barre de commande avec une palette ⌘K, une carte de réponse IA et — point crucial — une bannière de brouillon qui encode la règle la plus importante du produit : l'IA prépare un brouillon, un humain disposant du bon rôle le valide, rien n'écrit dans la base de données sans cette validation. La discipline anti-fraude n'est pas seulement de la logique backend ; elle est visible dans le système de design comme un pattern réutilisable. Ça, c'est un designer qui réfléchit au produit, pas qui le décore.
Deux UI kits cliquables. Un back-office web complet (login, le tableau de bord du directeur avec un briefing IA, les flux IA « demander vs. agir », la liste des chauffeurs avec vues détaillées, la recherche ⌘K, un module d'aide et d'onboarding) et un portail chauffeur mobile séparé (login par téléphone + PIN, l'espace personnel du chauffeur — dette, dépôts, véhicule, un micro vocal). Cliquables. Réels. Navigables avant qu'une seule ligne de code de production n'existe.
À partir d'un brief. Dans un contexte de design. Avant que Claude Code ne touche à quoi que ce soit.
Le système de design KASSIA sous forme de carte de fichiers — 134 fichiers à partir d'un seul brief. Chaque composant livre trois fichiers : le visuel (.jsx, violet), le contrat de props typé (.d.ts, cyan) et la carte d'usage (.prompt.md, vert). Ce triplet qui se répète, plus les couches de tokens, les specimens de guidelines et deux UI kits cliquables, voilà ce qui en fait un système plutôt qu'une maquette.
Pourquoi c'est un système, et non un ensemble d'écrans
C'est la distinction que tout le monde manque, alors je veux la rendre nette.
Une maquette est l'image d'un écran. Un système de design est l'ensemble des décisions et des pièces réutilisables qui rendent chaque écran futur cohérent sans avoir à redécider quoi que ce soit. La différence entre les deux, c'est la différence entre un produit qui paraît cohérent à l'écran un et un produit qui paraît toujours cohérent à l'écran quarante.
Ce que Claude Design a livré, c'est la seconde chose. Les contrats typés font que Claude Code — quand il portera plus tard tout cela en production — ne devine pas quelles props prend un StatusBadge ; il lit le .d.ts. Les cartes .prompt.md font que lorsqu'un nouvel écran devra être conçu dans six semaines, les règles du « quand utiliser une carte plutôt qu'une carte de statistiques » existent déjà, par écrit. Les fichiers de tokens font que changer la couleur primaire de la marque est une seule édition, pas une recherche dans quarante fichiers. Le manifeste fait que le tout est navigable et auditable.
Ceci est une infrastructure de design versionnée, documentée, réutilisable. C'est exactement ce qu'un designer produit senior remet à une équipe d'ingénierie quand il fait bien son travail — une bibliothèque Figma plus des composants codés plus des guidelines écrites. La seule différence, c'est que c'est sorti d'un contexte de design piloté par le chat, en une fraction du temps et à coût marginal nul.
Les gens sous-estiment Claude Design parce qu'ils ne lui ont jamais demandé qu'un écran. Ils ne lui ont jamais demandé un système. Alors ils concluent que c'est un jouet pour générer des maquettes, alors qu'il est en réalité capable de produire l'artefact le plus à effet de levier de tout le build — celui dont tout le reste hérite.
Le passage de relais : comment le Design alimente le Code
C'est là que les deux surfaces se connectent, et c'est pourquoi les garder séparées paie.
La sortie de Claude Design est une implémentation de référence : du HTML et du JSX, de vrais tokens en CSS, des prototypes fonctionnels. Le travail de Claude Code est de porter cela dans la stack de production — dans notre cas, généralement SvelteKit et Tailwind. Le passage de relais est propre précisément parce que le système de design est explicite. Claude Code reçoit les fichiers de tokens (il les mappe sur les valeurs de thème Tailwind), les contrats de composants (il reproduit la même API de props) et l'UI kit (il a une cible au pixel près à reproduire). Aucune ambiguïté à résoudre, aucun goût à inventer. L'ingénierie devient un portage fidèle, pas un second tour de design-par-accident.
Comparez cela au workflow par défaut, où vous demandez à Claude Code de « construire un tableau de bord qui a l'air professionnel ». Maintenant la session d'ingénierie est aussi une session de design, menée par la surface la moins équipée pour ça, sans tokens, sans contrats, sans point de vue — et le résultat est le slop anonyme évoqué plus haut. La séparation n'est pas de la bureaucratie. C'est ce qui fait que les deux surfaces opèrent à leur sommet. Le Design décide ; le Code exécute la décision. Chacun fait ce qu'il fait de mieux.
C'est le même principe qui rend fiable le workflow d'ingénierie multi-agents : quand un travail traverse une interface, le producteur documente le contrat et le consommateur est briefé avec l'artefact, jamais laissé à le déduire. Claude Design est le producteur du contrat de design. Sautez-le, et chaque agent d'ingénierie en aval déduit le design à partir d'un prompt vague.
Le processus que je déroule sur chaque nouveau projet
C'est la partie à voler. Voici la séquence exacte, et elle est désormais non négociable pour moi sur tout projet greenfield.
Étape 1 — Écrire un brief de design, pas un prompt de build. Avant d'ouvrir un contexte de design, j'écris un brief destiné à un designer, pas à un ingénieur. Il contient : ce qu'est le produit et qui l'utilise, le registre émotionnel que je veux (pour KASSIA : « premium, profond, lumineux — confiance et précision, jamais tape-à-l'œil »), les assets de marque hérités le cas échéant, les contraintes dures (français d'abord, format de devise FCFA, pas d'emoji, accessibilité), et les surfaces dans le périmètre (back-office web plus portail mobile). Quinze minutes d'écriture. C'est la même discipline que le brief d'ingénierie, pointée vers une surface différente.
Étape 2 — Exiger un système de tokens d'abord, avant tout écran. Je demande explicitement à Claude Design d'établir les fondations — rampes de couleurs, tokens sémantiques, typographie, espacement, élévation, motion, clair et sombre — avant de dessiner la moindre page. C'est l'ordre qui empêche le slop. Les fondations d'abord, les écrans ensuite. Un écran construit sur des tokens est cohérent par construction ; un écran construit d'abord puis tokenisé plus tard ne converge jamais complètement.
Étape 3 — Exiger des contrats et des cartes d'usage avec chaque composant. Pas seulement le visuel. Le .d.ts et le .prompt.md. C'est ce qui transforme une maquette en artefact de passage de relais et ce qui fait survivre le système au-delà de la première session. Si un composant est livré sans son contrat, il n'est pas terminé.
Étape 4 — Obtenir des UI kits cliquables, un par surface. Un prototype réel et navigable pour chaque surface distincte (l'application web et le portail mobile sont des problèmes de design différents et obtiennent des kits différents). Je veux cliquer à travers les vrais flux — le login, le tableau de bord, l'interaction IA, les vues détaillées — et ressentir le produit avant qu'aucun code de production n'existe. C'est là que j'attrape les erreurs produit gratuitement, tant qu'elles ne coûtent rien à corriger.
Étape 5 — Concevoir les surfaces IA comme de première classe, pas comme une bulle de chatbot. Si le produit a de l'IA à l'intérieur — et tous les miens en ont — son langage de design fait partie du système : les états de l'orbe, la barre de commande, la carte de réponse et les règles qui encodent la discipline du produit (pour un produit qui gère de l'argent, le pattern brouillon-puis-validation est dans le design). L'IA est la colonne vertébrale de l'UX, alors elle est conçue comme une colonne vertébrale, pas greffée comme un widget.
Étape 6 — Seulement maintenant, passer le relais à Claude Code. Avec les tokens, les contrats et les UI kits en main, la session d'ingénierie est un portage, pas une invention. Claude Code mappe les tokens sur le framework de production, reproduit l'API des composants et reproduit le kit. Passage de relais propre. Pas de design-par-accident.
Six étapes. Les cinq premières vivent entièrement dans la surface design. Le temps que l'ingénierie commence, chaque décision visuelle et UX a déjà été prise, écrite et approuvée — par moi, devant un prototype cliquable, pas par un agent d'ingénierie qui improvise sous deadline.
Pourquoi c'est l'effet de levier le plus sous-estimé de toute la stack
Laissez-moi présenter l'argument business clairement, car ce n'est pas une préférence esthétique.
Pour les produits que je construis — IA vocale pour les élèves africains, orchestration de paiements, un ERP qui manipule de l'argent — le design est la confiance, et la confiance est la conversion. Un parent à Abidjan qui décide s'il met 100 FCFA dans une application de tutorat prend cette décision dans les trois premières secondes, au ressenti, avant d'avoir lu un mot. Un gestionnaire de flotte qui décide s'il croit les chiffres anti-fraude sur un tableau de bord les croit davantage quand le tableau de bord a l'air d'avoir été construit par des gens qui prennent l'argent au sérieux. Dans les marchés émergents en particulier, une interface premium, cohérente, digne de confiance n'est pas un luxe. C'est la différence entre un produit qui convertit et un produit qu'on désinstalle.
Cette surface — celle qui décide de la confiance — est celle que la plupart des bâtisseurs génèrent comme un effet secondaire d'un prompt d'ingénierie. Ils dépensent leur soin sur l'architecture que l'utilisateur ne voit jamais et improvisent la surface sur laquelle l'utilisateur les juge en trois secondes. C'est exactement à l'envers.
Claude Design corrige cela, et il le corrige à bas coût. Un système de design complet, de niveau production — tokens, deux douzaines de composants documentés, deux UI kits cliquables, un langage de design IA — à partir d'un brief, dans un contexte de design, pour le coût d'un abonnement. La sortie est l'artefact le plus à effet de levier du build, parce que chaque écran que le produit aura jamais en hérite. Faites-le bien une fois, en amont, et la cohérence est automatique pour toujours. Sautez-le, et vous payez l'incohérence sur chaque écran, pour toujours.
Trois surfaces, pas une. Web Claude possède la stratégie. Claude Code possède l'ingénierie. Et Claude Design possède le système que l'utilisateur touche réellement. Faites tourner les trois, et faites tourner le Design en premier. C'est le membre de l'équipe sur lequel vous fermez les yeux.
Un fondateur. Trois surfaces Claude. Sept produits. Le design d'abord.