Une commande, et la maquette cesse d’être un document à recopier. Le compte officiel Claude Developers a annoncé le 17 août l’arrivée de /design dans Claude Code : un skill livré en research preview, c’est-à-dire ouvert à l’essai sans engagement de durée, qui fait entrer les planches à dessin de Claude Design dans la CLI (l’interface en ligne de commande) et l’application de bureau. Ce qui en sort tient dans un artefact modifiable, rangé du même côté que le code, là où il fallait jusqu’ici une image et quelqu’un pour la retranscrire.
La planche à dessin rend l’écran manipulable
Un agent IA sait déjà produire une interface : on lui décrit un écran, il génère les composants. L’intérêt d’ajouter une planche à dessin par-dessus tient à ce que la génération au fil de l’eau ne laisse rien à manipuler. Vous obtenez un résultat, vous le commentez en prose, l’agent recommence. La planche à dessin, elle, matérialise un état intermédiaire que l’on peut regarder, comparer, reprendre par morceaux. Elle réintroduit dans la conversation ce que le designer avait perdu en passant à l’agent : un objet stable devant les yeux.
Jusqu’ici, l’écran dessiné et l’écran livré parlaient deux langues distinctes, et un développeur servait de traducteur. Avec la planche à dessin, l’objet qu’on manipule est déjà rédigé dans la langue d’arrivée.
OpenAI a pris la route inverse : Codex passe par un accord avec Figma, dont le serveur MCP (Model Context Protocol, le format standard par lequel un modèle dialogue avec des outils extérieurs) fait circuler l’interface dans les deux sens, du fichier de maquette au code et de l’application qui tourne aux calques éditables. Anthropic, elle, rapatrie la planche à dessin dans son propre outil.
Les tokens donnent le vocabulaire, jamais la grammaire
Le mécanisme se comprend mieux par ce qui le fait échouer. Ne fournir à Claude Design que le système de design, sous forme de feuille de tokens, donne des propositions plausibles mais génériques. Les tokens décrivent les couleurs et les espacements disponibles : c’est un vocabulaire. Ils ne disent rien de la façon dont on assemble ces éléments dans un écran réel.
D’où un conseil qui revient dans les premiers retours d’usage : joindre au système un ou deux écrans de production aboutis, choisis parmi les vues clés et non parmi les vues secondaires. Le système de design fournit les variables, l’écran fini montre la composition. Avec les deux, l’outil dispose enfin de décisions de mise en page observables, et pas seulement d’une palette autorisée.
L’analogie est celle du dictionnaire et du texte. Donner un dictionnaire à quelqu’un ne lui apprend pas à construire une phrase ; il lui faut des phrases déjà écrites pour en attraper la mécanique. C’est exactement le comportement d’un modèle : il généralise beaucoup mieux à partir d’exemples composés qu’à partir de règles énoncées. Le design vient de rejoindre la longue liste des domaines où l’apprentissage par l’exemple bat la documentation.
Chez Amplitude, la maquette a quitté le circuit
Un cas concret circule depuis quelques jours, plus parlant qu’une démonstration théorique. Une designer d’Amplitude a rejoint une équipe partie de zéro pour concevoir Agent Analytics, une plateforme qui mesure et évalue le comportement des agents. Aucun fichier Figma à exploiter, des ingénieurs qui livraient plusieurs fois par jour, et une seule certitude : le design ne devait pas devenir le goulot d’étranglement.
Sa méthode tient dans une boucle quotidienne. Plutôt que des écrans figés, elle produit avec Claude des prototypes HTML cliquables, partagés, commentés et corrigés dans la même journée, puis remis à l’équipe avant le soir. Pour trancher un détail d’interaction, elle ne reconstruit pas un écran complet : elle demande trois à cinq variations d’un même composant et les compare.
Elle n’avait jamais ouvert la moindre pull request avant cette mission, et se décrit aujourd’hui comme quasiment seule responsable de l’interface de son équipe. Le prototype a fait disparaître le passage de relais entre deux métiers.
Le système de design devient une contrainte exécutable
Cette bascule, Anthropic la théorise en interne. Jenny Wen, qui dirige le design de Claude, a expliqué que l’enchaînement découverte, maquette, itération correspondait à une époque où construire était lent et coûteux, et que son équipe travaille désormais à façonner directement l’implémentation et la direction du produit. Sa formule est sans ambiguïté : la source de vérité du design devient le produit lui-même.
Conséquence pratique pour vous, si vous maintenez un système de design. Il n’était déjà plus vraiment lu par des humains ; il devient maintenant une entrée que consomme un agent. Un token mal nommé, une documentation périmée, un écran de référence qui ne reflète plus la production, et l’outil produira du faux avec application, puis le proposera à la revue. La maintenance du système de design glisse du registre documentaire vers l’ingénierie de contexte, cet art de soigner ce qu’on donne à lire au modèle, avec les mêmes exigences de fraîcheur que n’importe quelle dépendance.
Le geste à préparer est simple : versionner les tokens et deux écrans de référence au même endroit que le code, et les traiter comme du code.
La méthode ne se transpose pas à toutes les équipes
Le skill /design est explicitement exposé en research preview, donc susceptible de bouger ou de disparaître : personne ne devrait y adosser un processus critique cette semaine.
Le terrain compte autant que l’outil. L’expérience d’Amplitude repose sur un produit neuf, sans dette d’interface. Sur une application vieille de plusieurs années, dont les composants portent des exceptions accumulées, la même méthode se heurtera à bien plus de résistance.
La designer pose elle-même la limite la plus dure : sa vitesse vient d’un réservoir de modèles d’interaction accumulés au fil des années, qui lui permet de dire précisément ce qu’elle demande. L’agent exécute une intention qu’il ne sait pas produire. Le métier glisse vers l’amont, là où l’on décide ce qui mérite d’exister à l’écran.
Un dernier basculement, moins spectaculaire, pèsera pourtant plus lourd que les autres. Dans cette organisation, un écran n’est plus validé dans un fichier de maquettes : il l’est dans une pull request, avec une revue, une intégration continue et des droits d’écriture. Peu d’équipes ont préparé ce transfert d’autorité, et c’est pourtant lui qui déterminera qui a le dernier mot sur l’interface.
