Du Design au Code avec l'IA : Claude Code Change Tout
Quelque chose a basculé lors d'un atelier récent. J'ai participé à suffisamment de revues de design, de planifications de sprint et de sessions de passation entre designers et développeurs pour savoir quand un changement de workflow est cosmétique — et quand il est structurel. Celui-ci était structurel.
Diane, CEO et cofondatrice de The Design Project, avait Cursor ouvert à gauche, Figma à droite, et Claude Code en action entre les deux. Elle a tapé un prompt — "redesigne cette UI comme le ferait un designer produit de classe mondiale" — et a regardé l'IA lire l'intégralité du codebase, esquisser son plan, poser une question de clarification, puis commencer à modifier des fichiers.
Pas de document de passation. Pas de mockup annoté. Pas de ticket Jira dormant dans le backlog d'un développeur pendant deux semaines. Juste une designer qui génère du vrai code front-end à travers une IA qui comprenait le contexte du projet.
J'ai gardé cette image en tête un bon moment. Parce que ce que j'observais n'était pas un hack de productivité — c'était le workflow design-vers-développement qui commençait à se dissoudre. Et je pense que la plupart des équipes produit ne l'ont pas encore ressenti, mais ça viendra.
Voici ce que j'ai retenu de cette session, filtré par ma propre expérience de construction avec Claude Code. Je serai honnête sur les domaines où ce workflow change véritablement la donne et sur ceux où les limitations actuelles vous rattraperont si vous n'y prenez pas garde.
Il y a un moment précis dans la section implémentation qui a transformé ma façon de penser le mode de planification de l'IA. Gardez-le en tête pendant votre lecture.
L'Ancien Workflow Était Déjà en Train de Craquer Avant l'Arrivée de l'IA
Laissez-moi décrire la passation design-vers-développement que la plupart des équipes connaissent. Un designer termine ses mockups dans Figma. Il annote les espacements, tailles de police, états d'interaction, hover states. Il planifie une réunion de passation. Le développeur pose des questions que les annotations ne couvraient pas. Il y a des allers-retours. Un sprint démarre. Le développeur construit quelque chose qui s'en approche — mais pas tout à fait. Il y a un cycle de revue. Encore des allers-retours. Finalement, quelque chose est livré qui représente 80% de ce qui avait été conçu à l'origine.
Ça vous dit quelque chose ?
Le problème, ce ne sont pas les personnes. Les designers sont bons dans leur métier. Les développeurs sont bons dans le leur. Le problème, c'est la couche de traduction entre eux — le fossé où l'intention se perd, où les suppositions s'accumulent et où le contexte s'évapore pendant la passation. Même avec Zeplin, InVision ou le mode développeur de Figma, vous transférez toujours une représentation statique d'un design vers un medium qui nécessite du code dynamique, responsive et à états.
Ce que fait Claude Code — et ce que Diane a clairement démontré — c'est faire disparaître cette couche de traduction.
Quand vous donnez à Claude Code un prompt de design et que vous le laissez opérer sur un vrai codebase, il ne devine pas l'implémentation à partir d'une capture d'écran. Il lit la structure de code existante, comprend la hiérarchie des composants, sait ce qui existe déjà et génère des modifications qui s'intègrent à l'architecture existante. C'est quelque chose de qualitativement différent de la génération de code générique.
La distinction compte. Les générateurs de code génériques produisent du code qui peut sembler correct mais ne s'intègre pas à votre projet. Claude Code — travaillant en contexte — produit du code qui s'intègre à ce que vous avez déjà construit.
Mais avant d'entrer dans le détail du fonctionnement pratique, vous devez comprendre le stack d'outils spécifique que Diane a utilisé et pourquoi chaque choix compte.
Le Stack à Trois Outils qui Fonctionne Vraiment Ensemble
L'atelier était centré sur trois outils travaillant de concert. Je les ai tous les trois utilisés indépendamment. Les voir combinés dans un workflow délibéré m'a éclairé sur pourquoi cette combinaison spécifique est plus que la somme de ses parties.
Cursor comme environnement de départ. Cursor est un éditeur de code construit sur VS Code, avec des capacités d'IA intégrées au niveau de l'IDE plutôt qu'ajoutées comme extension. Pour des designers qui entrent dans un environnement de programmation pour la première fois, c'est fondamental. L'interface est suffisamment familière pour naviguer, le terminal est accessible sans être intimidant, et cloner un dépôt est simple via l'interface graphique.
Pour l'atelier, Diane a cloné le LLM Council d'Andrej Karpathy — un projet open-source qui permet d'interroger plusieurs modèles d'IA simultanément, ces modèles évaluant mutuellement leurs réponses. Le choix du projet était judicieux. C'est un vrai codebase de qualité production avec une structure non triviale, pas une application tutoriel jouet. Travailler avec quelque chose de réel est la seule façon de vérifier si un workflow tient vraiment la route.
Claude Code comme couche d'intelligence. C'est la partie qui m'intéresse le plus — et celle où j'ai le plus d'expérience directe pour comparer.
Claude Code ne fait pas que générer du code à partir d'une description. Il lit. Il commence par scanner le README, comprendre la structure du projet, identifier les dépendances, vérifier ce qui est déjà installé. Sur un dépôt fraîchement cloné, il gère l'installation des dépendances, la configuration de l'environnement et fait tourner le projet avant de toucher à un seul élément de design.
Cette compréhension contextuelle est ce que les générateurs de code génériques manquent. Quand Diane a demandé à Claude Code de redesigner l'UI du LLM Council, il n'a pas généré un nouveau composant de zéro en s'attendant à ce qu'elle l'intègre. Il a modifié les composants existants, dans la structure de fichiers existante, en utilisant les patterns de style existants — tout en appliquant la direction de design qu'elle avait spécifiée.
Figma MCP pour la synchronisation bidirectionnelle. Le Figma MCP (Multi-Component Plugin) est le pont entre design et code qui rend ce workflow bidirectionnel. Après que Claude Code génère des modifications d'UI dans le code, ces changements peuvent se synchroniser vers Figma — donnant aux designers un moyen de continuer à affiner au niveau du design sans redessiner manuellement ce qui a été généré. Les modifications faites dans Figma peuvent ensuite revenir dans le codebase.
L'avertissement honnête ici : cette synchronisation bidirectionnelle est véritablement impressionnante en concept et imparfaite en exécution pour le moment. Le mapping des tokens, les conventions de nommage des composants et le comportement responsive ne se traduisent pas parfaitement dans les deux sens. L'atelier de Diane a révélé exactement cela — du troubleshooting en direct, des limitations visibles, une démonstration en temps réel que ce n'est pas encore un problème résolu. J'y reviendrai dans la section sur les limitations réelles.
Le Mode Planification — La Partie que la Plupart des Gens Ignorent
Voici le moment que j'ai mentionné au début et qui a transformé ma façon d'utiliser Claude Code.
Quand Diane a demandé à Claude Code de redesigner l'UI, elle n'a pas simplement lancé le prompt et attendu du code. Elle l'a laissé tourner d'abord en mode planification.
Le mode planification est la phase où Claude Code expose ce qu'il a l'intention de faire avant de faire quoi que ce soit. Il lit les fichiers pertinents, identifie ce qui doit changer, trace la séquence des modifications et — point crucial — pose des questions de clarification si le prompt laisse place à l'interprétation.
Ce n'est pas anodin. La plupart des développeurs que j'ai observés utiliser des outils de programmation assistés par IA sautent directement à l'exécution. Ils lancent un prompt, obtiennent du code, l'exécutent, voient que ça casse, lancent un autre prompt pour corriger, et finissent dans une boucle de corrections allers-retours qui consomme plus de temps que d'écrire le code eux-mêmes.
Le mode planification casse ce schéma. Quand l'IA expose son approche en premier, vous détectez les malentendus au niveau du plan — avant tout changement de code. "Je prévois de modifier le composant Header et d'ajouter un nouveau schéma de couleurs au Tailwind config" est quelque chose que vous pouvez évaluer et rediriger en trente secondes. Découvrir que l'IA a modifié le mauvais composant après coup vous coûte dix minutes de debugging et de rollback.
Dans la chronologie de l'atelier, cette séquence planification-puis-exécution s'est déroulée entre les minutes 15 et 20 — le segment où les participants ont eu le plus de moments de révélation. Voir l'IA poser une question de clarification sur la palette de couleurs avant de toucher au CSS a rendu la démarche délibérée visible d'une manière qu'une simple démo avant/après ne permet pas.
Mon expérience personnelle confirme cela. Sur un projet récent, j'ai utilisé le mode planification de Claude Code pour redesigner un composant de tableau de données. Le plan a révélé que mon prompt était ambigu concernant la pagination — le nouveau design devait-il conserver la pagination côté serveur ou passer à la pagination côté client ? Cinq secondes pour clarifier. Le code résultant était correct du premier coup. Sans le mode planification, j'aurais obtenu du code qui présumait une approche, j'aurais découvert le problème en testant, et j'aurais passé du temps à corriger.
Traitez le mode planification comme obligatoire, pas optionnel. Les quatre-vingt-dix secondes supplémentaires qu'il ajoute au départ font gagner des multiples de ce temps à chaque étape suivante.
Déroulement du Workflow de l'Atelier — Étape par Étape
Permettez-moi de reconstituer le workflow que Diane a démontré, avec le niveau de détail d'implémentation utile si vous voulez le reproduire.
Étape 1 : Cloner le dépôt dans Cursor.
# In Cursor's integrated terminal
git clone https://github.com/karpathy/llm-council.git
cd llm-council
Pour les designers qui n'ont jamais utilisé un terminal, l'interface graphique de Cursor rend l'expérience moins intimidante. Vous pouvez aussi utiliser la palette de commandes de Cursor pour cloner — sans passer par le terminal.
Étape 2 : Laisser Claude Code lire et configurer le projet.
Ouvrez Claude Code et donnez-lui du contexte avant de demander quoi que ce soit lié au design :
Read the README.md file thoroughly. Understand the project structure,
what this application does, and what dependencies it needs. Then install
the dependencies and tell me what I need to set up to run this locally.
Claude Code va scanner le README, identifier le stack (dans le cas du LLM Council, un backend Python avec un frontend JavaScript), installer les dépendances via le gestionnaire de paquets spécifié et signaler toute configuration manquante — comme les variables d'environnement.
Étape 3 : Créer le fichier .env.
Le LLM Council, comme la plupart des vrais projets, a besoin d'API keys pour fonctionner. Claude Code vous dira exactement quelles variables sont nécessaires. Créez le fichier .env à la racine du projet :
# .env — never commit this file
ANTHROPIC_API_KEY=your_key_here
OPENAI_API_KEY=your_key_here
Claude Code se charge de signaler ce qui est nécessaire. Vous fournissez les clés réelles. C'est la bonne répartition des tâches — l'IA gère la forme de la configuration, vous gérez les secrets.
Étape 4 : Lancer le projet et vérifier qu'il fonctionne.
# Start the backend
python app.py
# In a separate terminal, start the frontend
npm run dev
Claude Code vous donnera les commandes exactes basées sur ce qu'il a lu dans les scripts du projet. Une fois l'application lancée localement et l'UI originale visible, vous êtes prêt à demander des modifications de design.
Étape 5 : Demander des modifications de design en utilisant le mode planification.
C'est l'étape critique. Structurez votre prompt de design pour invoquer explicitement le mode planification :
Before making any changes, enter planning mode. I want to redesign
this application's UI as a world-class product designer would. The
current UI is functional but visually sparse. I want:
- A dark, modern color scheme
- Improved typography hierarchy
- Better spacing and visual rhythm
- Clear visual separation between model responses
Plan your approach first. List every file you intend to modify and
why. Ask me any clarifying questions before you start.
La réponse de l'IA sera un plan — quelque chose comme : "Je prévois de modifier App.css pour le schéma de couleurs global, de mettre à jour ModelResponse.jsx pour la mise en page des cartes de réponse, d'ajuster le Tailwind config pour des valeurs d'espacement personnalisées. Question : dois-je préserver la structure de composants existante ou proposer une réorganisation ?"
Vous répondez à la question. Puis vous approuvez le plan. Puis l'exécution commence.
Étape 6 : Synchroniser avec Figma via MCP.
Une fois les modifications de code en place et la direction validée, le plugin Figma MCP vous permet d'importer ces changements de code dans un fichier Figma. En pratique, cela génère des frames Figma qui approximent ce que le code rend — utile pour partager avec les parties prenantes ou poursuivre l'itération de design dans Figma.
Étape 7 : Faire des modifications dans Figma et les renvoyer dans le code.
Les ajustements pixel-perfect sont souvent plus faciles dans Figma qu'en CSS. Effectuez ces modifications dans Figma, puis utilisez le MCP pour exporter les changements sous forme de modifications de code. Claude Code peut alors les intégrer au codebase existant.
Étape 8 : Faire un commit et un push de vos modifications.
# Stage your changes
git add -A
# Commit with a meaningful message
git commit -m "redesign: apply modern dark theme to LLM Council UI"
# Push to your fork
git push origin main
Si vous avez forké le projet pour faire des modifications indépendantes — ce que Diane recommandait — ce push va vers votre fork personnel sur GitHub. De là, vous avez la possibilité d'ouvrir un pull request vers le projet original si les changements méritent d'être contribués.
Si vous avez suivi mentalement ce workflow, vous comprenez déjà quelque chose que la plupart des gens mettent trois tentatives à saisir : l'IA ne conçoit pas à votre place. Elle implémente une direction que vous spécifiez. La qualité de ce que vous obtenez dépend presque entièrement de la qualité de votre formulation de prompt. C'est exactement pour cela que la phase de planification existe.
Maintenant, la partie honnête.
Ce que l'Atelier a Bien Compris sur les Limitations
Diane n'a pas présenté cela comme un workflow abouti. C'est la partie que j'ai le plus appréciée dans la session.
L'intégration Figma MCP a révélé des limitations réelles en direct à l'écran. Les incohérences de nommage des composants entre le codebase et Figma signifient que ce qui est importé dans Figma ne correspond pas toujours proprement aux composants de votre système de design existant. La gestion des tokens — design tokens pour la couleur, l'espacement et la typographie — ne se synchronise pas de manière fiable dans aucune direction pour le moment. Vous obtenez une approximation raisonnable du code vers Figma, mais "synchronisation bidirectionnelle pixel-perfect" est un langage marketing aspirationnel, pas une description fidèle de l'état actuel des outils.
Le problème des tokens est celui que je trouve le plus frustrant en pratique. Si votre codebase utilise un Tailwind config personnalisé avec des tokens de couleur nommés, et que votre fichier Figma a un système de design correspondant, vous vous attendriez à ce que la synchronisation préserve ces noms. Ce n'est souvent pas le cas. Vous vous retrouvez avec des valeurs hexadécimales au lieu de noms de tokens, et des overrides de composants au lieu d'instances de composants. Corriger cela manuellement annule une bonne partie du gain de temps.
Mon avis honnête : considérez la synchronisation Figma-vers-code et code-vers-Figma comme une étape "suffisamment proche pour continuer", pas comme une étape "précisément exacte". Utilisez-la pour communiquer une direction et arriver dans le voisinage du bon design. N'attendez pas qu'elle remplace la discipline méticuleuse du système de design.
L'autre limitation qui mérite d'être mentionnée : la fenêtre de contexte de Claude Code. Sur les codebases volumineux — des dizaines de milliers de lignes réparties sur des dizaines de fichiers — Claude Code peut perdre le fil du contexte du projet en cours de session. La phase de planification atténue cela dans une certaine mesure, car le plan sert d'ancrage. Mais sur de très grands projets, vous remarquerez que l'IA fait des suggestions qui contredisent des décisions antérieures dans la même session. Quand cela arrive, rétablir le contexte avec un prompt de résumé le remet généralement sur la bonne voie.
Aucune de ces limitations ne rend le workflow moins précieux. Elles en font un workflow qui nécessite une main expérimentée pour repérer les lacunes — ce qui est exactement ce que la session de Diane a démontré. Elle a rencontré le problème du MCP en direct et l'a géré en expliquant ce qui se passait et pourquoi. C'est le bon modèle : comprendre les limites de l'outil, travailler dans ces limites, et ne pas laisser les cas limites vous distraire de ce que le workflow fait bien.
Ce que Cela Change Concrètement pour les Équipes Produit
L'atelier a consacré sa session de Q&A finale à une question que je considère comme la plus intéressante : que deviennent les rôles quand cela se généralise ?
Le cadrage de Diane : les frontières entre Product Managers, designers et ingénieurs s'estompent. Les PMs prototypent directement. Les designers écrivent — ou du moins génèrent — du code. Les ingénieurs restent concentrés sur l'ingénierie, mais s'impliquent davantage dans les décisions de design et les PRDs plus tôt dans le processus.
J'ai observé le début de cette évolution dans les équipes avec lesquelles j'ai travaillé, et j'ajouterais quelques nuances.
L'estompement est réel. Mais il n'est pas uniforme. Ce que les outils d'IA comme Claude Code permettent, c'est que les spécialistes puissent s'aventurer plus loin dans les territoires adjacents sans devenir des généralistes. Une designer sans formation en programmation peut maintenant générer un prototype fonctionnel, l'évaluer dans le navigateur, itérer dessus et partager quelque chose de plus proche du résultat final que n'importe quel mockup. Cela ne fait pas d'elle une ingénieure. Cela fait d'elle quelqu'un dont les décisions de design sont désormais éclairées par ce que le code en fonctionnement produit réellement.
L'effet en aval : les revues de design changent. Au lieu de passer en revue un mockup statique dans Figma en imaginant le rendu dans le navigateur, vous examinez quelque chose avec lequel vous pouvez réellement interagir. Le feedback devient plus spécifique, plus ancré dans le réel et plus actionnable. "Ce bouton semble petit sur mobile" remplace "Je ne suis pas sûr de ce bouton" — parce que vous pouvez tester sur mobile avant la revue.
Pour les ingénieurs, le changement est plus subtil mais tout aussi réel. Quand les designers arrivent à la passation avec du code fonctionnel plutôt que des mockups, la conversation d'ingénierie passe de "peut-on construire ça ?" à "comment rend-on ça prêt pour la production ?" C'est une meilleure conversation. Elle élimine complètement la couche de traduction.
La compétence transversale qui devient essentielle — et j'encourage toute personne dans une équipe produit à la développer — c'est savoir formuler des prompts. Pas savoir coder. Pas savoir designer. Savoir articuler une intention avec suffisamment de clarté pour qu'une IA puisse l'exécuter avec précision. C'est une discipline. Ça demande de la pratique. Les personnes qui la développeront tôt auront un avantage significatif sur celles qui traitent les outils d'IA comme des boîtes magiques.
Mes Résultats Après Avoir Appliqué ce Workflow
Le week-end suivant l'atelier, j'ai appliqué le workflow design-vers-code à un projet client — une application de dashboard qui était dans les limbes du design depuis trois semaines parce que le designer et le développeur n'arrivaient pas à s'aligner sur la structure des composants.
J'ai cloné le codebase existant dans Cursor, donné à Claude Code du contexte sur le projet, puis je lui ai demandé de générer la mise en page du dashboard que la designer avait créée dans Figma. Le mode planification a fait émerger une question immédiate : le nouveau layout devait-il utiliser la structure CSS modules existante ou passer à Tailwind ? Une clarification. Le plan s'est mis à jour. L'exécution a démarré.
Quarante-cinq minutes plus tard, le développeur avait un prototype fonctionnel dans le navigateur qui correspondait à 85% du mockup Figma. Pas pixel-perfect. Mais suffisamment proche pour que la conversation de revue restante porte sur des ajustements spécifiques plutôt que sur des questions d'alignement fondamental. Nous avons livré la première version deux jours plus tard.
Par rapport au sprint où cela stagnait : trois semaines contre deux jours.
La version honnête : les 15% d'écart ont encore nécessité une édition manuelle. La synchronisation Figma MCP a ajouté environ trente minutes de nettoyage pour mettre à jour le fichier Figma afin qu'il reflète ce qui était réellement dans le code. Et la première passe de Claude Code sur les composants de visualisation de données a nécessité un second prompt pour obtenir le bon comportement responsive sur les écrans plus petits. Rien de tout cela n'était surprenant. Tout était plus rapide que l'alternative.
Ce qu'il faut mesurer si vous essayez : le temps entre l'approbation du design et le prototype fonctionnel (objectif : moins de 4 heures pour une seule fonctionnalité), le nombre de cycles de revue de design avant la passation au développeur (objectif : 1, pas 3), et la fréquence à laquelle l'intention de design survit intacte à la passation (suivez les écarts entre la spécification de design et la fonctionnalité livrée — ils devraient diminuer).
Une Chose à Faire Avant Votre Prochaine Passation de Design
Choisissez une fonctionnalité. Une seule — pas tout votre système de design, pas un redesign complet de page. Un seul composant ou une seule section qui attend dans Figma d'être développé.
Clonez votre codebase dans Cursor. Ouvrez Claude Code. Donnez-lui du contexte sur le projet, puis demandez-lui d'implémenter le design à partir de votre description Figma. Utilisez le mode planification. Laissez l'IA poser ses questions. Approuvez le plan. Observez ce qui se passe.
Vous obtiendrez un résultat imparfait. C'est normal. L'objectif de cet exercice n'est pas de livrer dès le premier prompt. L'objectif est de mesurer l'ampleur réelle de votre fossé actuel entre design et développement, et de ressentir ce que c'est qu'itérer dans le code plutôt que dans des mockups.
Les équipes qui construiront les meilleurs produits dans les trois prochaines années ne sont pas celles qui ont le plus de designers ou le plus de développeurs. Ce sont celles qui ont compris comment faire du design et du développement une seule conversation continue, accélérée par l'IA — avec Claude Code quelque part au milieu.
Le document de passation traditionnel a eu son heure de gloire. Son remplaçant est déjà là.
🤝 Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Ce serait un plaisir de vous accompagner.
- 🔗 Fiverr (builds et intégrations sur mesure) : fiverr.com/s/EgxYmWD
- 🌐 Portfolio : mejba.me
- 🏢 Ramlit Limited (solutions entreprise) : ramlit.com
- 🎨 ColorPark (design et branding) : colorpark.io
- 🛡 xCyberSecurity (services de sécurité) : xcybersecurity.io
