Ce que les gens font concrètement
Le modèle qui apparaît dans les catalogues de compétences pour agents consiste à prendre les Human Interface Guidelines d'Apple (ou Material, ou les guides d'accessibilité d'une plateforme) et à les reconditionner pour qu'un agent puisse les charger avant de construire l'UI. Un ensemble publié divise le HIG en quatorze compétences couvrant les plateformes, les fondations et les composants : mise en page, contrôles, dialogues, menus, recherche. D'autres le proposent comme une compétence de design unique promettant des composants natifs, une typographie appropriée et des couleurs sémantiques.
C'est un bon réflexe. Un agent de code à qui l'on demande un écran de réglages iOS sans directives produira quelque chose qui fonctionne, mais qui semble subtilement incorrect : une modale là où un push était conventionnel, un contrôle qui existe sur le web mais pas sur la plateforme, des zones tactiles dimensionnées pour une souris. Charger les règles de la plateforme corrige une catégorie d'erreurs bien réelle, et ce, à moindre coût.
Cela produit également un effet inattendu, sur lequel il convient d'être précis.
Ce qui survit à la traduction, et ce qui ne survit pas
| Exemple | Réaction de l'agent | |
|---|---|---|
| Règles prescriptives | Taille minimale de la zone tactile, choix du contrôle selon la tâche, préférence d'une feuille (sheet) sur un push, minimums de contraste | Les applique systématiquement. Ces règles sont vérifiables, donc une mauvaise réponse est visiblement erronée |
| Principes | « Clarté », « déférence », « profondeur » | Est d'accord avec eux, puis fait ce qu'il avait déjà prévu de faire |
Cette seconde ligne représente tout le problème, et cela ne concerne pas seulement Apple. Une instruction infalsifiable ne peut pas modifier le comportement, car le modèle peut la satisfaire avec sa propre définition du mot. Demandez de la clarté et vous obtiendrez l'idée médiane de la clarté du modèle, qui est la même pour tous les autres modèles. C'est pourquoi tant d'UI générées par des agents convergent vers les mêmes surfaces presque noires, la même palette gris et une seule couleur d'accentuation, et les mêmes cartes aux coins uniformément arrondis.
Un agent peut suivre une règle. Il ne peut qu'approuver un principe.
Nous avons mesuré ce même échec sur le terrain. Parmi 299 fichiers DESIGN.md publics (les documents que les développeurs écrivent spécifiquement pour qu'un agent les suive), 54 % contiennent au moins un adjectif non mesurable, le plus souvent « clean » (39 %) ou « moderne » (36 %), et 44 % ne mentionnent aucune valeur de taille concrète. Ces fichiers se lisent comme une direction artistique et fonctionnent comme un simple accord de principe.
Ce qu'une directive de plateforme ne cherche pas à vous apporter
C'est ici que les personnes qui installent une compétence HIG en espérant que leur application devienne soudainement esthétique sont surprises : les directives de plateforme sont délibérément partagées. Chaque application de la plateforme les suit. C'est tout l'intérêt. Un utilisateur doit pouvoir ouvrir une application qu'il n'a jamais vue et savoir comment elle fonctionne. La conformité est l'objectif, et l'identité visuelle ne l'est explicitement pas.
Ainsi, une compétence HIG peut rendre votre interface *correcte* (bons composants, bonne navigation, tailles de cibles appropriées, bon contraste), mais être correct n'est pas synonyme d'être distinctif. Si deux équipes chargent la même directive sans autre contexte de design, elles devraient produire des interfaces interchangeables. C'est généralement ce qui arrive.
C'est un avantage, jusqu'à ce que ça ne le soit plus
Pour un utilitaire, un plugin ou tout élément intégré dans l'environnement d'un tiers, se fondre dans la masse est la bonne approche et la directive constitue l'intégralité du brief. Le décalage n'apparaît que lorsque l'objet construit est un produit qui doit être reconnaissable, et cela se découvre généralement vers le cinquième écran.
La configuration à deux couches
Une fois que l'on considère cela comme deux tâches distinctes, la solution devient évidente et les couches cessent de s'opposer.
| Couche plateforme | Couche identité | |
|---|---|---|
| Réponses | Comment cela doit-il se comporter ici ? | À quoi cela doit-il ressembler, partout ? |
| Source | Les directives de la plateforme, sous forme de compétence ou de fichier de règles | Votre ensemble de design tokens et vos règles écrites, dans le repo |
| Évolue quand | La plateforme change | Votre marque change |
| Échec si absent | Une UI d'apparence correcte mais qui semble étrangère à la plateforme | Une UI parfaitement conforme à la plateforme, mais indiscernable de toutes les autres applications |
Gardez-les dans des fichiers séparés. Il est tentant d'intégrer votre marque dans la compétence HIG pour n'avoir qu'un seul élément à charger, mais cela pose problème dès la première mise à jour de la plateforme ou le premier rebranding, car vous devez alors démêler quelles phrases appartenaient à quel ensemble.
Token specimen · real values
Ambient Sage
Live renderAmbient Sage's actual tokens — the same values its exports use.
Rédiger une règle qu'un agent peut vérifier
Le test est simple : quelqu'un peut-il regarder le résultat et affirmer, sans ambiguïté, si la règle a été respectée ? Si deux personnes raisonnables peuvent être en désaccord, l'agent le sera aussi, et il résoudra le litige en faveur de ses paramètres par défaut.
| Accepté avec | Respecté | |
|---|---|---|
| Couleur | Utiliser une palette propre et moderne | Utiliser uniquement les tokens sémantiques. Jamais de hex brut dans un composant. Un seul accent par écran |
| Typographie | La typographie doit paraître raffinée | Deux familles : display et body. Échelons d'échelle à 1,25×. Jamais de troisième graisse dans le corps du texte |
| Surfaces | Garder des surfaces légères et aérées | Les cartes sont plates. Pas d'ombre sur une surface plate. Bordure 1px, token border |
| Mode sombre | Supporter le mode sombre | Chaque rôle de couleur défini dans les deux modes. Ne jamais livrer une modification du mode clair sans son équivalent en mode sombre |
Remarquez combien d'entrées à droite sont des prohibitions. Ce n'est pas un choix stylistique : une préférence ajoute une option, tandis qu'une prohibition élimine toutes les autres. « Utilisez notre vert » laisse tous les défauts génériques valides ; « n'introduisez jamais une couleur qui n'est pas un token » ne le permet pas. Dans notre corpus, 76 % des fichiers ne listaient que des préférences, ce qui explique précisément pourquoi ils cessent de fonctionner.
Quand la directive et votre image de marque divergent
Cela arrive moins souvent qu'on ne le craint, car ces deux couches répondent généralement à des questions différentes. Lorsque cela se produit, il s'agit généralement de l'un des trois cas suivants, et un seul d'entre eux constitue un réel conflit.
- Minimums d'accessibilité versus couleur de marque. Ce n'est pas un conflit. Le minimum l'emporte, et votre couleur d'accentuation doit être ajustée pour cette surface. Un agent à qui on l'indique explicitement le fera ; un agent laissé libre de choisir conservera généralement la couleur de marque, car c'est l'instruction qui lui semblera la plus spécifique.
- Convention de plateforme versus pattern interne. Un véritable arbitrage. Décidez une fois pour toutes, notez laquelle l'emporte et pourquoi, et placez-le dans la couche d'identité pour éviter de devoir trancher à nouveau pour chaque écran.
- Style par défaut de la plateforme versus vos tokens. Ce n'est pas un conflit, même si cela en a l'air. Les directives précisent quel contrôle utiliser ; elles précisent rarement sa couleur exacte. Utilisez le composant de la plateforme, stylisé avec vos design tokens.
Précisez quelle couche l'emporte, dans le fichier
Un agent disposant de deux documents sans priorité établie fera un choix arbitraire à chaque tour, sans vous dire lequel. Une seule ligne (« en cas de conflit, les minimums d'accessibilité l'emportent, puis les conventions de plateforme, puis le style interne ») élimine toute une catégorie d'incohérences qu'il serait autrement presque impossible de diagnostiquer à partir du résultat.
Configuration pratique
- 1
Chargez la couche plateforme comme une compétence ou un fichier de règles
Selon ce que supporte votre agent : une compétence,
.cursor/rules,.devin/rules, ou une section dans CLAUDE.md. Gardez-la aussi proche que possible de la directive source, afin qu'elle puisse être remplacée intégralement lors des mises à jour de la plateforme. - 2
Placez la couche d'identité dans le repo
Un fichier de tokens accompagné d'un DESIGN.md contenant vos règles et interdictions. Il doit se trouver dans le dépôt plutôt que dans un prompt, car l'agent doit le relire à chaque tâche, tout comme le fera la personne suivante.
- 3
Définissez la priorité une seule fois
Une phrase en haut du fichier d'identité précisant ce qui l'emporte en cas de conflit.
- 4
Testez sur l'écran que personne n'a conçu
Demandez quelque chose de plausible que ni l'une ni l'autre couche n'avait anticipé : un état vide, une erreur de permissions, un contrôle de pagination. Ce que l'agent inventera sera le reflet de tous les cas non couverts, et c'est là votre véritable mesure de couverture.
La dernière étape est celle qu'il convient de répéter. Les deux couches couvrent les cas auxquels quelqu'un a pensé. Dans un produit conçu par un agent, la plupart des écrans correspondent à des cas auxquels personne n'a pensé, c'est pourquoi la couche d'identité doit énoncer des règles générales et des refus plutôt que d'énumérer des composants. Pour en savoir plus sur le contenu de ce fichier : ce qu'est un DESIGN.md.
La couche d'identité, sous la forme d'un seul fichier installable
Chaque kit Identity Forge se sérialise en un DESIGN.md complet (tokens sémantiques en mode clair et sombre, un véritable appairage de polices, des motifs et des interdictions explicites) aux côtés du fichier de tokens. Il coexiste avec les directives de plateforme que vous chargez, sans jamais entrer en conflit avec elles.
FAQ
Un agent IA peut-il suivre les Human Interface Guidelines d'Apple ?
Les parties prescriptives, oui : choix des contrôles, patterns de navigation, cibles tactiles minimales, contrastes minimums. Ces éléments sont vérifiables, l'agent les applique donc de manière fiable. Les parties basées sur des principes (clarté, déférence, profondeur) ne peuvent pas modifier le comportement, car un agent satisfait une instruction non falsifiable selon sa propre interprétation du mot.
Une compétence HIG rendra-t-elle mon application esthétique ?
Elle la rendra correcte, ce qui est différent. Les directives de plateforme sont délibérément partagées par toutes les applications afin que les utilisateurs puissent transférer leurs connaissances d'une app à l'autre. Deux équipes chargeant la même directive et rien d'autre devraient produire des interfaces interchangeables. La distinction provient d'une seconde couche : vos propres tokens et règles.
Les directives de plateforme et mon design system doivent-ils être dans un seul fichier ?
Non. Ils évoluent selon des cycles différents (l'un lors des mises à jour de la plateforme, l'autre lors de l'évolution de votre marque) et les fusionner reviendrait à devoir démêler plus tard quelles phrases appartiennent à qui. Conservez deux fichiers et précisez lequel l'emporte en cas de conflit.
Que faire quand une couleur de marque ne respecte pas un minimum d'accessibilité ?
Le minimum l'emporte et la couleur d'accentuation doit être ajustée pour cette surface. Précisez-le explicitement dans vos règles : un agent laissé libre de choisir conserve généralement la couleur de marque, car cette instruction lui semble plus spécifique qu'une note générale sur l'accessibilité.
Comment savoir si une règle est assez bien écrite pour un agent ?
Demandez-vous si un relecteur pourrait regarder le résultat et affirmer, sans ambiguïté, que la règle a été suivie. « Utilisez une palette épurée » échoue à ce test. « Utilisez uniquement les tokens sémantiques, jamais de hex brut, un seul accent par écran » le réussit.