Il existe une promesse spécifique faite à propos de l'IA dans le travail créatif et produit : elle s'occupera des parties répétitives pour que vous puissiez vous concentrer sur la réflexion. Après six mois d'intégration de Claude Code dans toutes les phases d'un projet de design produit, du cadrage initial à la livraison finale, le tableau honnête est plus nuancé. La promesse est partiellement vraie. Les aspects qu'elle réussit sont significatifs. Ceux qu'elle rate sont instructifs.

Cadrage : de l'ambiguïté aux exigences structurées

La première phase où Claude Code s'est révélé véritablement utile est le cadrage. Avec un brief de projet (même approximatif et conversationnel), Claude Code peut produire un document d'exigences structuré : user flows, cas limites, questions ouvertes, inventaire grossier des composants. Ce n'est pas un remplacement des conversations avec les parties prenantes, mais cela accélère le travail qui vient après ces conversations. L'output donne à tout le monde un artefact concret avec lequel être en désaccord, ce qui est beaucoup plus productif que travailler à partir d'une compréhension partagée floue.

Les diagrammes de user flow ont été un gain spécifique. Décrire un parcours utilisateur en langage naturel et obtenir en retour un flow structuré en syntaxe Mermaid, qui peut ensuite être rendu et affiné, a comprimé une tâche qui nécessitait autrefois une session de design complète à environ vingt minutes. Les diagrammes n'étaient pas parfaits au premier passage, mais suffisamment complets pour être utiles, et le cycle d'itération était rapide.

Design : lire Figma, produire du code de composants

Avec le Figma MCP en place, Claude Code peut lire les fichiers de design et produire du code de composants. Cela a bien fonctionné pour les composants atomiques où l'intention de design était claire depuis la structure du fichier. Boutons, éléments de formulaire, composants typographiques, utilitaires d'espacement : ces éléments ont été implémentés avec une haute fidélité dès les premiers passages. Le travail de traduction qui siégeait autrefois entre design et ingénierie, les allers-retours sur les valeurs exactes, les corrections, les re-vérifications, a été en grande partie éliminé pour ces éléments.

Les composants plus complexes ont nécessité une description explicite. Les systèmes de navigation, les layouts de dashboard et les hiérarchies de modales nécessitaient des prompts allant au-delà de « implémente ce composant » pour décrire le comportement, les breakpoints responsive et la logique d'interaction en termes précis. C'est là que la capacité du designer à communiquer avec précision devient la contrainte structurante. Le modèle s'exécute bien face à des spécifications claires. Face à des spécifications vagues, il produit quelque chose d'apparence plausible qui ne résout pas réellement le problème.

Prototypage : des applications fonctionnelles en quelques heures

C'est la phase où l'accélération est la plus dramatique et la plus visible. Déployer un prototype fonctionnel sur Vercel, qu'une partie prenante peut ouvrir sur son téléphone et avec lequel interagir lors d'une réunion, représentait autrefois un investissement temporel significatif. C'est désormais une tâche qui tient dans un après-midi de travail. Cela change entièrement l'économie du prototypage.

L'implication n'est pas seulement une itération plus rapide. C'est une qualité différente de retour. Une partie prenante interagissant avec une vraie interface sur son appareil réagit différemment de celle qui regarde une présentation Figma. Elle tape des choses, elle mal-interprète des éléments, elle anticipe des comportements qui n'ont pas été spécifiés. Ce contact avec la réalité produit des informations qu'aucune revue de design ne produit. Y arriver plus vite, plus tôt dans le processus, avec moins de coût irrécupérable, est une amélioration structurelle de la façon dont les décisions de design sont validées.

Les prototypes construits durant cette période de six mois tournaient sur React et Next.js avec Tailwind CSS. La cohérence de la stack importait : Claude Code produit un code plus fiable et plus idiomatique pour une stack avec laquelle il a une profonde familiarité. Changer de framework en milieu de projet introduit un bruit qui coûte plus qu'il n'économise.

Documentation : specs, matériaux de livraison, changelogs

La documentation technique est la phase où l'assistance IA est la plus directement utile et la moins susceptible de produire des erreurs subtiles. Générer des specs de composants depuis un fichier de design, produire des notes de livraison pour l'ingénierie, rédiger des entrées de changelog : ce sont des tâches où l'output peut être vérifié rapidement et où le coût d'un premier brouillon imparfait est faible. Claude Code gère tout cela correctement.

Ce qu'il ne gère pas bien, c'est la documentation nécessitant un jugement interprétatif : expliquer pourquoi une décision de design a été prise, capturer les arbitrages qui ont été considérés et rejetés, décrire l'intention derrière un système plutôt que sa mécanique. Ce contenu doit être rédigé par le designer, car il reflète des décisions prises à travers un processus auquel l'IA n'était pas présente. La distinction importe, parce que la documentation de livraison qui capture le « quoi » sans le « pourquoi » a tendance à être ignorée ou mal appliquée en aval.

Les points de friction qui ne disparaissent pas

Des instructions ambiguës produisent des résultats ambigus. Ce n'est pas une critique de l'outil : c'est une description du fonctionnement du langage. Un prompt qui dit « rends ça plus engageant » produit un output qui diffère de l'intention de façons difficiles à déboguer, car l'instruction elle-même ne spécifiait pas ce que « engageant » signifie dans ce contexte. L'expérience de six mois a clairement montré que la précision dans les instructions n'est pas une compétence que l'on peut sauter. Si quoi que ce soit, les workflows assistés par IA exigent plus de précision que les workflows humain à humain, car un ingénieur humain demandera une clarification quand quelque chose est flou, tandis que le modèle produira une interprétation d'apparence plausible et avancera.

La posture du designer s'en trouve modifiée. Le travail consiste moins à produire l'artefact directement et davantage à orchestrer un pipeline de production : écrire des instructions claires, évaluer l'output par rapport à un standard précis, décider de ce qu'il faut itérer et de ce qu'il faut accepter, gérer le contexte que le modèle tient tout au long d'une session. C'est un changement cognitif significatif. C'est aussi une position plus levier : quand ça fonctionne, une personne produit ce qui nécessitait autrefois une équipe. Quand ça ne fonctionne pas, le mode d'échec est généralement un prompt qui nécessitait plus de précision, pas un outil qui a échoué.

Ce que six mois changent vraiment

Le bilan honnête est le suivant : Claude Code intégré sur un cycle de vie de projet complet accélère les phases où le travail est bien défini et les spécifications sont claires. Documents de cadrage, implémentation de composants, déploiement de prototypes, documentation technique : tout cela va significativement plus vite. Les phases nécessitant un jugement interprétatif, des décisions stratégiques et la communication de l'intention de design n'accélèrent pas, mais bénéficient de disposer d'artefacts plus propres et plus rapides sur lesquels s'appuyer.

Le designer qui travaille ainsi pendant six mois développe un ensemble différent d'instincts. Il devient meilleur pour cadrer les problèmes avec précision, car le coût de l'imprécision est immédiat et concret. Il se concentre davantage sur les décisions qui comptent réellement, car celles qui ne comptent pas sont gérées par le pipeline. Et il développe un sens plus clair de là où l'assistance IA apporte véritablement de la valeur et là où elle produit l'apparence du progrès sans la substance. Ce dernier instinct est probablement la chose la plus précieuse que ces six mois ont produite.