Vous confiez une interface à une IA, et le rendu paraît correct. Jusqu’à ce que vous posiez deux écrans côte à côte : boutons qui changent de taille, marges qui dansent, palette à peu près respectée. La question naïve mérite d’être posée franchement : pourquoi un modèle capable d’écrire du code propre dessine-t-il une UI (interface utilisateur) aussi instable ?
Il y a quelques jours, nous consacrions un article aux sous-agents IA, à ces quatorze réglages qui pèsent souvent plus lourd que le choix du modèle. La leçon tenait en une phrase : la qualité d’un agent dépend moins de sa puissance brute que de la façon dont on l’équipe et on l’oriente. Le design obéit à la même logique, mais par un levier distinct, qu’on a tendance à confondre avec le précédent.
Pourquoi l’agent improvise
Par défaut, Claude Code (l’agent de développement d’Anthropic) est calibré pour l’ingénierie. Quand on lui demande une interface, il ne dispose d’aucun cadre visuel propre à votre produit. Il comble donc les trous comme n’importe quel intervenant sans consigne : avec des conventions génériques, plausibles, mais réinventées à chaque écran.
D’où l’incohérence. Ce n’est pas un défaut d’intelligence, c’est une absence de mémoire partagée. L’agent ne sait pas que votre bouton primaire mesure 40 pixels de haut, que vos titres suivent une échelle précise, que telle carte existe déjà dans votre bibliothèque. À chaque requête, il repart d’une page blanche.
La pile de design, et son chaînon décisif
Pour corriger cela, on parle désormais de pile de design, par analogie avec la pile technique que tout développeur fixe avant la première ligne de code. Elle réunit trois éléments fournis à l’agent dès le départ : le brief, les connaissances en design et les outils. On la configure une fois, elle sert ensuite à chaque tâche.
Le brief et les outils comptent, mais le maillon vraiment déterminant pour la cohérence visuelle est le deuxième : les connaissances en design. C’est lui qui distingue une UI tenue d’un patchwork d’écrans corrects pris isolément.
Donner une mémoire visuelle à l’agent
Concrètement, ces connaissances se rangent en trois familles, du plus abstrait au plus concret.
- Les design tokens : les valeurs atomiques de votre système, couleurs, espacements, rayons, typographie. Ce sont les unités de base que l’agent doit réutiliser plutôt que d’en inventer d’approchantes.
- Les conventions de composants : la manière dont vos éléments s’assemblent, quel bouton pour quelle action, quelle structure de formulaire, quelles règles d’espacement entre blocs.
- Les exemples : des écrans déjà validés, qui montrent le résultat attendu mieux qu’aucune description. L’agent infère la règle implicite à partir du cas concret.
L’image juste est celle de l’arrivée d’un designer dans une équipe. On ne le lâche pas sur une maquette en lui disant « fais au mieux ». On lui transmet d’abord la charte, la bibliothèque de composants, quelques écrans de référence. Sans cette mise au courant, même un excellent professionnel devine, et deviner produit des écarts. Fournir ces connaissances à l’IA revient exactement à ce travail d’accueil, sauf qu’il ne se fait qu’une fois. Anthropic n’est d’ailleurs pas seule sur ce terrain : Vercel a formalisé la même logique avec v0 et ses systèmes de design, qui apprennent une fois à l’agent vos vrais composants, tokens et conventions plutôt que de le laisser approximer.
Le goût compte moins que le référentiel
Le glissement est important. Tant qu’on attend d’un modèle qu’il « ait du goût », on reste tributaire de son entraînement et de la chance du prompt. Dès qu’on lui donne un référentiel, on déplace la question : il ne s’agit plus de talent inné, mais d’information disponible. L’agent cesse d’improviser parce qu’il a de quoi se conformer.
C’est aussi ce qui sépare ce levier de l’orchestration de sous-agents abordée précédemment. Multiplier les agents spécialisés répartit le travail et fiabilise l’exécution. Nourrir l’agent en connaissances design agit ailleurs : sur la cohérence du rendu lui-même. On peut très bien avoir une orchestration impeccable et une UI décousue, faute d’avoir transmis le référentiel. Les deux chantiers se complètent, ils ne se remplacent pas.
La conséquence pratique tient en peu de mots : avant d’affiner les prompts à l’infini, mieux vaut investir dans ce que l’agent sait de votre design. Documenter ses tokens, formaliser ses conventions, rassembler quelques écrans exemplaires, c’est un effort initial qui se rentabilise à chaque génération suivante. Le modèle ne dessine pas mieux parce qu’il devient plus malin, mais parce qu’on cesse de lui demander de tout inventer.
Reste une zone à surveiller : un référentiel mal tenu vieillit, et un agent fidèle reproduira fidèlement vos incohérences passées. La cohérence promise n’est jamais meilleure que la base qu’on lui confie. C’est peut-être la discipline que cette approche impose vraiment : tenir son système de design à jour devient un acte de pilotage de l’IA, plus seulement une affaire de designers.
