Zombie UI : Comment empêcher l'IA de concevoir l'interface que tout le monde déploie

Des équipes de trois personnes peuvent désormais accomplir ce qui nécessitait autrefois des équipes de 30. Cet article enseigne les quatre parades pour y faire face : un point de vue, des standards encodés dans la machine, un éditeur qui refuse de confondre « terminé » et « réussi », et un budget pour l'atypique.

Le deuxième boom de la construction, et comment un style se transforme en zombies

Juste après la Seconde Guerre mondiale est survenu un boom de la construction, le plus grand de l'histoire selon la conférence. Ses constructeurs ont puisé dans le modernisme des années 1920 : géométries simples, surfaces nues et épurées, palettes monochromatiques, aucun ornement. Poussé par l'urgence de construire et de nouvelles méthodes de construction, ce style a été copié encore et encore sans aucune intention. La conférence qualifie le résultat de bâtiments zombies, des structures qui tiennent debout et fonctionnent, mais que rien ne différencie.

Un style est un ensemble de réponses à des problèmes spécifiques, et le copier sans avoir ces problèmes n'en conserve que la surface. Copiés de cette manière, les patterns ont cessé de correspondre aux lieux et aux personnes pour lesquels ils avaient été conçus.

La victime la plus célèbre de cette époque montre pourquoi cette leçon doit être prise au sérieux. Pruitt-Igoe à St. Louis fut salué par Architectural Forum comme le meilleur grand ensemble d'appartements de 1951, sa démolition a commencé en 1972, et il reste couramment cité pour illustrer les échecs du design moderniste. Charles Jencks est allé plus loin et a daté la mort de l'architecture moderne au dynamitage de ses barres d'immeubles le 15 juillet 1972. Les historiens ont depuis fait valoir que sa construction et sa gestion ont été façonnées par des conditions économiques et politiques profondément ancrées, et que blâmer les architectes détourne l'attention de ces causes institutionnelles.

L'argument central de la conférence est que nous vivons actuellement un autre boom de la construction : celui de l'IA. Une entreprise peut désormais développer 20 idées en une semaine. La Zombie UI (interface zombie) est le jumeau numérique du bâtiment zombie : une interface assemblée à partir des patterns les plus probables, techniquement compétente en surface mais interchangeable avec tous les autres produits conçus de la même manière. La recherche sur les interfaces générées par l'IA en dessine déjà les contours : des outils qui atteignent la conformité de base en matière d'accessibilité tout en s'appuyant sur des patterns de design homogénéisés.

La régression vers la moyenne : les language models excellent à vous donner la réponse la plus probable, et l'interface la plus probable est l'interface moyenne. La dérive vers le « terminé » : l'IA donne l'impression que les choses sont achevées très rapidement, bien trop souvent prématurément. La dérive vers le jetable : le travail est si rapide qu'il semble jetable et, pire encore, il est traité comme tel.

Chaque dérive nécessite son propre contrepoids, et la conférence présente le résultat comme un choix : ce boom peut éviter les zombies numériques et devenir une Renaissance créative.

Pourquoi la production de l'IA régresse vers la moyenne, et pourquoi de meilleurs prompts n'y changeront rien

Figure 1. Les trois dérives structurelles qui poussent la production de l'IA vers la Zombie UI, chacune nécessitant son propre contrepoids.

Un large language model, ou LLM, est entraîné pour prédire ce qui vient ensuite, il apprend donc à attribuer une forte probabilité aux suites qu'il a vues le plus souvent. C'est exactement en ce sens que les LLMs excellent à vous donner la réponse la plus probable.

Les chercheurs appellent ce rétrécissement la monoculture générative : une baisse significative de la diversité des résultats par rapport aux données d'entraînement, comme le fait de ne produire que des critiques positives pour des livres ayant reçu un accueil mitigé. Un autre axe de recherche attribue une partie de cette cause au biais de typicité : les personnes qui évaluent les résultats des modèles favorisent systématiquement les textes familiers. Les templates de formatage ajoutent leur propre pression, et une étude a révélé que l'effondrement de la diversité qui en résulte persiste même avec un échantillonnage à haute température (high-temperature sampling). Sur 14 modèles de langage, une autre équipe a constaté que la masse de probabilité était excessivement concentrée sur quelques continuations valides.

Une revue systématique des LLMs dans le design UI et UX note une dépendance à l'égard de patterns génériques ou conservateurs et avertit que les designers risquent de s'ancrer trop tôt sur les suggestions de l'IA, restreignant ainsi leur idéation. Une évaluation d'écrans conçus par l'IA a révélé un vernis visuel attrayant côtoyant des mots incorrects, des libellés illisibles et une absence de feedback interactif. Les praticiens testant un outil d'UI générative ont signalé qu'il peinait à conserver le liant entre les écrans : des styles cohérents, une mise en page partagée, un flux logique.

Le deuxième mécanisme est l'écart entre ce que vous voulez dire et ce que vous tapez. L'équipe de design de Stripe l'a constaté directement : trois personnes différentes pouvaient entrer le même prompt et obtenir trois résultats différents.

Le troisième mécanisme réside chez la personne qui révise, et non dans le modèle. L'image utilisée dans la conférence est celle d'un burrito au micro-ondes : 90 secondes entre la faim et le déjeuner, et cette rapidité vous rend prêt à fermer les yeux sur le fait qu'il est à peine mangeable. C'est la dérive vers le « terminé » en miniature.

Ce qui fonctionne, c'est de structurer trois points : un point de vue en amont, des standards encodés dans les outils par lesquels le modèle doit passer, et un éditeur responsable en aval. Le flux ci-dessous cartographie la méthode que le reste de cet article enseigne.

Première étape : construire un point de vue par l'observation

La première action a lieu avant même d'ouvrir le moindre modèle : définissez votre marque, ce qu'elle représente pour vous et ce qu'elle représente pour vos utilisateurs.

Le point de vue de Stripe est l'optimisme, et l'équipe l'insuffle dans tous les détails, des plus grands aux plus petits. Dans la conférence, cette valeur traverse les couleurs, l'écriture, les sujets traités et les produits déployés pour soutenir les entrepreneurs.

Un point de vue ne s'invente pas lors d'un atelier ; il se construit par l'observation. Observez ce dont vos utilisateurs ont besoin et ce qu'ils veulent, et pas seulement ce qu'ils disent. Observez également le monde extérieur, car les produits, l'art et la science signalent tous ce qui est perçu comme bon, excellent ou médiocre.

Figure 2. L'architecture de tokens à trois couches qui oblige les agents IA à respecter des standards basés sur l'intention plutôt que de deviner à partir de noms liés à l'apparence.

Modèle à adapter : Nous sommes [ce que vous êtes] pour [qui]. Nous croyons en [la conviction]. C'est pourquoi nous faisons toujours [comportement visible] et jamais [le choix par défaut probable que nous rejetons].

Deuxième étape : encoder vos standards dans la machine

La thèse la plus lourde de conséquences de la conférence est que l'objet du design n'est plus l'écran ; c'est le système lui-même. D'où la deuxième action : encoder vos standards dans la machine.

Leur IA lisait la documentation de design, et ce n'était pas assez précis : trois personnes avec le même prompt obtenaient toujours trois résultats différents. L'équipe a donc construit une CLI (une interface en ligne de commande) par-dessus son design system, et celle-ci fonctionne comme un harnais qui rend l'IA beaucoup plus obéissante.

Un guide de gouvernance de design system énonce le principe sans détour : un agent ne peut pas lire une page wiki et décider de suivre la convention de nommage, il a besoin de règles exprimées sous forme de données structurées avec des conditions, des contraintes et des conséquences explicites.

La composition est exactement le point faible des outils génératifs, comme les praticiens l'ont découvert lorsqu'un outil a peiné à maintenir la cohérence des styles et des flux entre les écrans.

Les recommandations actuelles les divisent en couches : les primitives contiennent des valeurs brutes, la sémantique contient le sens, et les composants consomment la couche sémantique. Nommez selon l'intention, et non l'apparence : color.blue.500 oblige à deviner parmi plusieurs bleus, tandis color.action.primary énonce clairement l'intention. Dans le format Design Tokens du W3C, le champ $description est ce qui indique à un agent quand utiliser un token plutôt qu'un autre qui lui ressemble. Un design system agentique open-source rédige sa règle absolue ainsi : les primitives ne sont jamais utilisées directement dans les composants.

Si votre source de design est Figma, ses propres recommandations indiquent que relier les composants au code avec Code Connect est le moyen le plus efficace d'amener un agent à réutiliser vos vrais composants ; sans cela, l'agent doit deviner. Les mêmes recommandations préconisent l'utilisation de variables pour l'espacement, la couleur, le rayon des angles et la typographie, des noms de calques qui décrivent leur fonction, et l'auto layout au lieu du positionnement absolu.

L'une d'entre elles expose un contrôle de conformité qui valide un extrait de code par rapport aux règles de design et renvoie les violations. Une autre conserve un fichier de contrat à côté de chaque composant et bloque la dérive du design system lors de l'intégration continue (CI). Le récit d'un développeur concernant un agent de design system a fait de la CLI le seul point d'entrée et y a inscrit des garde-fous stricts : une liste blanche d'écriture, aucune commande shell, aucune nouvelle dépendance.

L'encodage a ses limites, et la conférence l'illustre par une citation de Christopher Alexander : un système peut satisfaire à toutes les règles et être quand même mort. La recherche sur les organisations de design partage cette inquiétude : les leaders craignent que les systèmes structurant le design comme l'assemblage de composants prédéfinis ne restreignent l'éventail de compétences qu'ils observent lors des recrutements. Dans une autre étude, des praticiens ont jugé ces critiques souvent dénuées de contexte, ont réaffirmé la valeur des design systems et ont demandé une meilleure collaboration autour de ces derniers.

Troisième étape : éditez rigoureusement, et refusez de confondre « terminé » et « réussi »

La troisième action a un slogan qui mérite d'être affiché au mur : refusez de confondre « terminé » et « réussi ». Derrière lui se cachent deux habitudes que chaque équipe doit désapprendre : l'idée que ce qui est construit est terminé, et que ce qui est terminé est bon.

Le rôle qui remplace l'ancien filtre est celui de l'éditeur. Un éditeur assume la responsabilité de chaque décision, ce qui, à bien des égards, signifie chaque pixel. L'éditeur juge le résultat de bout en bout de la façon dont l'utilisateur le rencontre, et non écran par écran tel qu'il a été généré.

Chez Stripe, une critique sur une publicité assistée par l'IA s'est soldée par 17 points d'amélioration.

Parcourez le flux comme un utilisateur, du premier point d'entrée à la dernière confirmation, et notez où le parcours se brise plutôt que de repérer un écran qui a simplement l'air un peu raté. Ouvrez tous les états que les modèles dessinent rarement bien : états vides, chargement, erreur, données partielles, le nom le plus long, le plus petit écran. Lisez chaque mot, car les évaluations d'écrans conçus par l'IA continuent de révéler des mots incorrects et des libellés illisibles dissimulés derrière des mises en page attrayantes. Ensuite, confrontez le résultat à votre point de vue : si l'on retirait le logo, quelqu'un qui connaît la marque la reconnaîtrait-il comme étant la vôtre ?

Modèle à adapter : À l'endroit [emplacement], je vois [observation], ce qui enfreint [principe], changez-le donc par [instruction spécifique].

L'édition ne fonctionne que si l'éditeur peut bloquer un travail qui est déjà construit. Nommez un éditeur par périmètre, donnez-lui le droit explicite de bloquer une release, et faites de ce blocage une routine afin qu'il soit perçu comme une pratique normale plutôt que comme un veto personnel.

L'étape que la plupart des équipes ignorent est de boucler la boucle entre l'édition et l'encodage. Chaque remarque qui apparaît dans deux critiques est une règle qui attend d'être inscrite dans le système ; ainsi, le jugement de l'éditeur se capitalise au lieu d'être dépensé à nouveau sur chaque écran. Les recommandations de gouvernance font la même démarche dans l'autre sens : faire l'inventaire des règles qui vivent déjà dans les guides de contribution, les configurations de linter, les conventions de nommage Figma, les notes d'utilisation de tokens, les checklists de pull-request et les registres de décisions, puis exprimer chacune d'elles comme une contrainte vérifiable par la machine. Avec le temps, le harnais absorbe les jugements de routine et libère l'éditeur pour ceux que seul le goût peut trancher.

🛠 Pratique — Créer un standard de design auquel un agent IA obéit, et une barrière éditoriale qui bloque le "terminé-mais-pas-réussi"

1. Faites l'inventaire des règles qui existent déjà et de l'endroit où elles se trouvent : guides de contribution, configurations de linter, conventions de nommage Figma, notes d'utilisation des tokens, checklists de pull-request et registres de décisions.
2. Restructurez les tokens en une couche de primitives de valeurs brutes et une couche sémantique nommée par intention, pointez chaque composant vers la couche sémantique, et donnez à chaque token sémantique une description d'une phrase sur les cas où l'utiliser.
3. Connectez vos composants Figma au code avec Code Connect afin que l'agent réutilise de vrais composants au lieu de deviner.
4. Si vous adoptez une couche de contrat prête à l'emploi, initialisez-la dans votre dépôt ; Fragments, par exemple, détecte votre framework et rédige le contrat en une seule commande. npx @usefragments/cli init
5. Bloquez la dérive du design system dans l'intégration continue afin que tout résultat hors-système échoue avant d'atteindre l'étape de revue. fragments check --changed --ci

Quatrième étape : dépenser les économies dans l'atypique

Comme le souligne la conférence, l'IA peut nous aider à produire de la monotonie, mais c'est aussi le plus grand catalyseur créatif que nous ayons jamais eu. Sa devise est de protéger l'atypique : l'IA abaisse le coût de la création, donc une partie de ce qu'elle fait économiser devrait être allouée à des travaux inhabituels.

Lorsque chaque tentative coûte cher, les équipes éliminent rationnellement l'idée singulière en premier, car son bénéfice est incertain alors que son coût est certain. Quand les tentatives deviennent bon marché, cette même logique s'inverse : la variance devient abordable, et l'option inhabituelle gagne sa place à chaque cycle de conception.

L'exemple donné dans la conférence est l'animation d'ouverture d'un événement.

L'obstacle à l'atypique n'est pas seulement le modèle, mais aussi la fixation des personnes qui l'utilisent, un phénomène que les chercheurs décrivent comme encore sous-exploré dans l'IA générative.

Demandez donc au modèle un éventail d'options, pas une seule réponse. L'échantillonnage verbalisé (verbalized sampling), une stratégie de prompting sans entraînement supplémentaire, demande au modèle plusieurs réponses accompagnées de leurs probabilités, ce qui allège la pression de produire une réponse typique unique. En écriture créative, cela a augmenté la diversité de 1,6 à 2,1 fois par rapport au prompting direct.

Modèle à adapter : Donne-moi cinq directions pour cet écran d'onboarding, chacune avec la probabilité qu'une équipe produit typique la déploie, et fais en sorte qu'au moins deux d'entre elles soient des directions qu'une équipe typique ne choisirait jamais.

Figure 3. Les 290 variantes de caractères de Gutenberg et les colonnes non répétitives de Ruskin partagent le même principe : une variation porteuse de sens est intégrée dès la conception au système, et non laissée au hasard.

La tension avec la deuxième étape est réelle : un harnais conçu pour rendre l'IA obéissante tire dans la direction opposée à une voie conçue pour la rendre atypique. Appelons la solution la méthode des deux voies : une voie système où le harnais régit la navigation, les formulaires, les paramètres et chaque flux où les utilisateurs ont besoin de prévisibilité, et une voie d'expression où la marque s'exprime, soumise au point de vue et à l'exigence de l'éditeur plutôt qu'aux templates. Une étude sur les design systems note que leurs limites sur la créativité peuvent aussi être un atout, permettant aux designers de faire preuve de plus de créativité sur les problèmes que le système ne résout pas.

Leçons d'artisanat de Gutenberg et Ruskin : là où réside la variation

L'histoire de l'imprimerie est généralement racontée comme celle de la vitesse, mais la partie la plus utile pour quiconque construit avec l'IA est le système que Gutenberg a bâti autour de sa machine. Son moteur de mise à l'échelle était un moule portatif qui permettait de couler des centaines ou des milliers de caractères à partir d'une seule matrice.

Pour sa Bible, Gutenberg a créé 290 caractères uniques, incluant différentes largeurs, abréviations et ligatures. Environ 60 caractères auraient suffi pour composer le texte si l'objectif n'avait pas été d'éviter les espaces trop larges entre les mots. Le créateur de caractères Hermann Zapf a plus tard identifié ce secret comme étant des colonnes d'un gris uniforme, sans espaces vides perturbants entre les mots.

Le détail a son importance : la plupart de ces caractères supplémentaires étaient des ligatures et des abréviations, tandis que le nombre de caractères individuels aux largeurs variables était faible. Même pour une lettre identique, il fondait plusieurs pièces, chacune avec un design légèrement différent.

John Ruskin a abordé le même problème par l'autre bout, écrivant en 1850 sur la qualité et l'artisanat, en érigeant l'architecture gothique comme l'incarnation de l'excellence. Il a remarqué qu'aucun bâtiment gothique ne se ressemblait, et que pas même une colonne n'était identique à une autre. À la question de savoir si l'on pouvait faire du gothique en couvrant les bâtiments de trèfles, il a répondu que non, pas plus qu'un enfant ne peut écrire en latin en copiant des mots au hasard chez Cicéron.

Dans La Nature du Gothique, Ruskin a classé les éléments moraux de ce style ainsi : la Sauvagerie, la Mutabilité, le Naturalisme, le Grotesque, la Rigidité et la Redondance. Vus du côté du bâtisseur, il les a reformulés comme la Rudesse, l'Amour du changement, l'Amour de la Nature, l'Imagination perturbée, l'Obstination et la Générosité.

Les erreurs qui transforment un bon système en usine à zombies

La première erreur consiste à fixer une barre distincte, plus basse, pour le travail de l'IA. Une question posée un jour par un partenaire transverse pressé de livrer résume bien la chose : quel est le standard de qualité pour quelque chose fait avec l'IA ? La seule réponse valable est que c'est le résultat final qui compte : les utilisateurs se soucient de savoir si c'est réussi, et les créateurs devraient en faire autant.

La deuxième erreur consiste à considérer la conformité aux règles comme un gage de qualité, ce contre quoi Christopher Alexander nous mettait en garde lorsqu'il disait qu'un système peut satisfaire à toutes les règles tout en étant mort. Une étude portant sur quatre-vingt-dix interfaces générées par deux outils d'IA dans trois domaines d'application illustre ce piège dans la pratique. Les outils atteignaient systématiquement une conformité de base en matière d'accessibilité, mais ils s'appuyaient sur des patterns de design homogénéisés qui limitaient leur capacité à répondre aux besoins spécialisés des utilisateurs.

Les chercheurs ont dénombré 178 cas où les participants ont accepté les exigences sans poser de questions, et 41 cas où des binômes ont rejeté de nouvelles idées parce qu'elles s'écartaient des options initiales.

Des praticiens interrogés sur cette critique l'ont souvent trouvée malavisée ou manquant de contexte, et ont réaffirmé la valeur des design systems. Une autre étude note que cette limitation peut s'avérer être un atout, libérant les designers pour qu'ils fassent preuve de plus de créativité sur les problèmes que le système ne résout pas. Les leaders du design décrivent tout de même une véritable tension : ils dépendent de personnes capables de travailler au sein des contraintes du système, mais, lors des embauches, ils valorisent celles qui remettent en question les postulats et proposent des solutions inattendues.

Figure 4. Les deux fins possibles au boom de la construction par l'IA, et les quatre habitudes visibles qui distinguent une équipe de la Renaissance d'une usine à zombies.

Pruitt-Igoe, le projet de logements de St. Louis souvent cité comme l'échec du design moderniste, fut salué par Architectural Forum comme le meilleur grand ensemble d'appartements de 1951, et sa démolition débuta en 1972. Les historiens avancent qu'il ne s'agissait pas principalement d'un échec de design : les conditions économiques et politiques, les politiques publiques et le déclin de la ville ont scellé son sort.

Modèle à adapter : avant toute mise en production, l'éditeur répond par écrit à trois questions : un utilisateur préférerait-il ceci à la meilleure alternative faite à la main ; qu'est-ce qui, ici, ne pourrait venir que de nous ; et qui en sera le propriétaire dans six mois. Si l'une des réponses est vide, le travail est construit, mais pas terminé.

Choisir une Renaissance créative plutôt qu'une Zombie UI

Nous sommes dans un autre boom de la construction, le boom de l'IA, et le choix qui s'offre à nous est de fabriquer l'équivalent numérique des bâtiments zombies ou bien d'initier une Renaissance créative. L'Histoire propose ces deux fins, ce qui rend ce choix bien réel et non pas simplement rhétorique.

L'objet du design n'est plus l'écran, mais le système lui-même. C'est pourquoi le choix s'opère en amont, dans le point de vue et les standards encodés, bien avant que quiconque n'examine le moindre écran.

Le garde-fou à l'autre extrémité tient en une phrase : refusez de confondre « terminé » et « réussi ». Cela fonctionne parce que cela donne à un éditeur la permission d'arrêter un travail qui a déjà l'air fini, ce qui est exactement l'étape que l'IA nous tente le plus d'ignorer.

Une équipe qui choisit la Renaissance a quatre habitudes visibles : un point de vue écrit, un système qui livre des templates et des flux plutôt que des pièces détachées, un éditeur avec l'autorité de dire « pas encore », et un budget protégé pour l'atypique. Gutenberg a dépensé ses économies dans les caractères qui rendaient les pages de la machine dignes d'un travail manuel, et Ruskin faisait l'éloge des bâtisseurs dont les colonnes refusaient de se répéter.

Points clés

• Le boom de la construction de l'IA répète le schéma d'après-guerre : des formes copiées sans intention produisent des Zombie UI.
• Définissez un point de vue, construit en observant les comportements, avant même qu'un modèle ne touche au travail.
• Désignez le système, pas l'écran : encodez les tokens, les templates et les flux dans un harnais par lequel l'IA est obligée de passer.
• Construit n'est pas terminé, et terminé n'est pas réussi : un seul éditeur est responsable de chaque décision, jusqu'au pixel près.
• Dépensez une partie de ce que l'IA fait économiser dans des travaux atypiques, dans une voie qui leur est propre, soumis au même niveau d'exigence éditoriale.

Plan d'action

1. Effectuez le test de cohérence : trois personnes, un prompt, votre configuration IA actuelle, puis comparez les résultats côte à côte.
2. Choisissez une règle écrite de vos guidelines et encodez-la comme une contrainte vérifiable par machine que votre CI ou votre agent exécutera.
3. Renommez vos tokens sémantiques selon l'intention et donnez à chacun une description d'une phrase expliquant quand l'utiliser.
4. Nommez un éditeur pour votre prochaine release construite par l'IA, donnez-lui le droit de la bloquer, et menez une critique qui se conclut par des instructions écrites.

Testez-vous

Q. Pourquoi ne peut-on pas corriger les résultats génériques de l'IA simplement en augmentant la température ou en reformulant le prompt ?
R. La recherche montre que l'effondrement de la diversité persiste même avec un échantillonnage à haute température et que de simples modifications d'échantillonnage ou de prompting sont insuffisantes, car ce rétrécissement trouve probablement sa source dans l'alignement.

Q. Quelle est la différence entre documenter une règle de design et l'encoder ?
R. La documentation explique l'intention avec des mots qu'un agent pourrait ne pas suivre ; l'encodage exprime la règle sous forme de données structurées avec des conditions, des contraintes et des conséquences que les agents, les linters et la CI peuvent vérifier.

Q. Pourquoi nommer un token color.action.primary plutôt que color.blue.500 ?
R. Un agent lit le nom avant de choisir un token : un nom basé sur l'intention indique à quoi sert le token, tandis qu'un nom basé sur l'apparence oblige à deviner entre plusieurs options similaires.

Q. Contre quoi l'histoire de Pruitt-Igoe met-elle en garde les équipes produit ?
R. Blâmer uniquement la forme : les historiens soutiennent que son échec a été façonné par des conditions économiques, politiques et institutionnelles, le design moderniste n'étant qu'un facteur parmi d'autres.

Questions ouvertes

• Qui devrait occuper le rôle d'éditeur dans une organisation, et avec quelle autorité pour bloquer un travail déjà construit ?
• Comment des équipes de trois peuvent-elles trouver le temps pour un artisanat méticuleux quand la vitesse est la raison pour laquelle elles sont compétitives ?
• Qui maintient sur le long terme le grand volume de produits construits rapidement et générés par l'IA ?
• Comment concilier la protection de l'atypique avec la cohérence de marque qu'impose le harnais d'un design system ?
• Si le rétrécissement des résultats du modèle trouve sa source dans l'alignement, verra-t-on arriver des méthodes de fine-tuning qui préservent la diversité, et que changeront-elles pour le travail de design ?
• Les design systems restreignent-ils les compétences créatives développées par la profession du design, comme le craignent certains leaders du domaine ?

Pour aller plus loin

1. Good Accessibility, Handcuffed Creativity: AI-Generated UIs Between Accessibility Guidelines and Practitioners’ Expectations | Proceedings of the 2025 ACM Designing Interactive Systems Conference — Une étude de quatre-vingt-dix interfaces générées par l'IA montrant une conformité en matière d'accessibilité aux côtés de patterns de design homogénéisés.
2. Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity — L'article sur l'échantillonnage verbalisé : pourquoi les modèles alignés s'effondrent sur des réponses typiques, et un prompt sans entraînement qui restaure la diversité.
3. skills/governance-encoder/SKILL.md — Une skill étape par étape pour transformer les règles de gouvernance d'un design system en contraintes vérifiables par machine pour les agents IA.
4. How to structure your design system for AI: tokens, naming, LLM-readable docs | DesignSystems.one — Des conseils concrets sur la structuration des tokens en couches, le nommage par intention et la rédaction de descriptions sur lesquelles un agent peut s'appuyer.
5. MCP server best practices – Figma Learn - Help Center — Les bonnes pratiques de Figma pour structurer vos fichiers afin qu'un agent réutilise vos vrais composants et variables.
6. InDesign, the hz-program and Gutenberg's secret — Comment Gutenberg a utilisé 290 caractères, principalement des ligatures et des abréviations, pour obtenir sa justification uniforme.
7. The Nature of Gothic and Modern Oblivion | Church Life Journal | University of Notre Dame — La propre liste de Ruskin des éléments caractéristiques du gothique, de la sauvagerie à la redondance.
8. Why Did Pruitt-Igoe Fail? — Un bref récit des raisons de l'échec de Pruitt-Igoe, au-delà de l'histoire populaire qui blâme son architecture moderniste.