Directives d'interface qu'un agent IA peut réellement suivre

Le modèle observé dans les catalogues de compétences d'agents consiste à prendre les Human Interface Guidelines d'Apple — ou Material, ou les directives d'accessibilité d'une plateforme — et à les repackager comme un élément chargé par l'agent avant de construire l'UI. Un ensemble publié décompose le HIG en quatorze compétences couvrant les plateformes, les bases et les composants : mise en page, contrôles, boîtes de dialogue, menus, recherche. D'autres le livrent comme une compétence de design unique promettant des composants natifs, une typographie appropriée et des couleurs sémantiques.

C'est un bon instinct. 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 fenêtre modale là où une transition push était conventionnelle, un contrôle existant sur le web mais pas sur la plateforme, des cibles tactiles dimensionnées pour une souris. Charger les règles de la plateforme corrige une catégorie réelle d'erreurs, et cela se fait à moindre coût.

Cela produit également un résultat inattendu, qu'il convient de préciser.

Cette deuxième ligne est le cœur du problème, et elle n'est pas spécifique à Apple. Une instruction non falsifiable ne peut pas changer le comportement, car le modèle peut la satisfaire avec ce qu'il croit déjà que le mot signifie. Demandez de la clarté et vous obtiendrez l'idée médiane de la clarté par le modèle, qui est la même pour tous les autres modèles ; c'est pourquoi tant d'UI générées par agent convergent vers les mêmes surfaces presque noires, la même palette une seule couleur d'accent et gris, les mêmes cartes aux coins uniformément arrondis.

Nous avons mesuré ce même échec sur le terrain. Sur 299 fichiers DESIGN.md publics — les documents que les développeurs rédigent spécifiquement pour qu'un agent les suive — 54 % contiennent au moins un adjectif non mesurable, le plus souvent « clean » (39 %) ou « modern » (36 %), et 44 % ne mentionnent jamais une seule valeur de taille concrète. Ces fichiers ressemblent à des orientations de design et servent de simple accord.

Voici la partie qui surprend ceux qui installent une compétence HIG en espérant que leur application devienne soudainement esthétique : 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 devrait pouvoir ouvrir une application qu'il n'a jamais vue et savoir comment elle fonctionne. La conformité est l'objectif, l'identité 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.

Une fois que l'on considère cela comme deux tâches distinctes, la solution devient évidente et les couches cessent de s'opposer.

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.

Le test est simple : quelqu'un peut-il regarder le résultat et dire, 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.

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.

Cela arrive moins souvent qu'on ne le craint, car les deux couches traitent principalement de questions différentes. Quand cela arrive, il s'agit généralement de l'un des trois cas suivants, et un seul d'entre eux constitue un véritable conflit.

1. Les minimums d'accessibilité face à une couleur de marque. Pas un conflit. Le minimum l'emporte, et votre couleur d'accentuation doit être ajustée pour cette surface. Un agent à qui l'on donne cette instruction explicitement s'exécutera ; un agent laissé à lui-même choisira généralement la couleur de la marque, car c'est l'instruction qui semblait la plus spécifique.
2. Convention de la plateforme face à un pattern maison. Un véritable arbitrage. Décidez une fois pour toutes, notez laquelle l'emporte et pourquoi, et inscrivez-le dans la couche d'identité pour éviter que cela ne soit remis en question pour chaque écran.
3. Stylisation par défaut de la plateforme face à vos tokens. Pas un conflit, même si cela en a l'air. Les guidelines précisent quel contrôle utiliser ; elles précisent rarement sa couleur exacte. Utilisez le composant de la plateforme, teinté avec vos tokens.

1. 1

   Chargez la couche plateforme sous forme de skill ou de fichier de règles

   Quel que soit le support de votre agent — un skill, .cursor/rules, .devin/rules, une section dans CLAUDE.md. Restez le plus proche possible de la guideline source, afin qu'elle puisse être remplacée intégralement lors d'une mise à jour de la plateforme.

2. 2

   Placez la couche d'identité dans le repo

   Un fichier de tokens plus un DESIGN.md contenant vos règles et vos interdictions. Il doit se trouver dans le dépôt plutôt que dans un prompt, car l'agent doit pouvoir le relire à chaque tâche, tout comme la personne suivante.

3. 3

   Définissez la priorité une seule fois

   Une phrase en haut du fichier d'identité désignant ce qui l'emporte en cas de conflit.

4. 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'a anticipé — un état vide, une erreur de permissions, un contrôle de pagination. Tout ce que l'agent invente est ce à quoi ressemblera chaque cas non couvert, et c'est là votre véritable mesure de couverture.

La dernière étape est celle qui mérite d'être répétée. Les deux couches couvrent les cas auxquels quelqu'un a pensé. Dans un produit construit par un agent, la plupart des écrans sont 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 : qu'est-ce qu'un DESIGN.md.