Design et UX quand l'IA dessine

Générez cinq écrans à la suite en décrivant chacun séparément. Pris isolément, tous sont présentables. Mis côte à côte, ils utilisent quatre nuances de bleu, trois rayons d'arrondi, deux échelles typographiques et des boutons qui ne se ressemblent pas. Aucun n'est raté ; l'ensemble est incohérent.

C'est la difficulté centrale du design en vibecoding, et elle est mal comprise. On croit à un problème de goût, on cherche de meilleurs prompts esthétiques. C'est un problème de mémoire : le modèle ne sait pas ce qu'il a produit hier, et redécide de tout à chaque écran.

Le vrai problème est l'incohérence

Un utilisateur ne juge pas une interface écran par écran. Il construit une attente : les actions principales sont à cet endroit, cette couleur veut dire danger, ce style de carte signifie qu'on peut cliquer. Chaque écart casse cette attente et coûte une fraction de seconde d'hésitation.

Cette dégradation ne se voit pas quand on développe, parce qu'on regarde un écran à la fois. Elle se voit immédiatement chez l'utilisateur qui traverse le parcours complet. C'est pourquoi les interfaces vibecodées produisent souvent une impression diffuse d'amateurisme sans qu'on puisse désigner un défaut précis.

Donner le cadre avant de demander l'écran

La solution n'est pas de mieux décrire chaque écran, mais de ne plus laisser le choix. Un système de design, même minimal, transforme une infinité de décisions possibles en un petit nombre d'options.

Minimal veut vraiment dire minimal. Des variables CSS pour les couleurs, une échelle d'espacement, deux ou trois niveaux de texte, un rayon d'arrondi, une ombre. Une trentaine de lignes suffisent à supprimer l'essentiel de la dérive.

:root {
  --color-primary: #003366;
  --color-accent: #e91e8c;
  --color-surface: #f0f3ff;
  --space-2: 8px;
  --space-4: 16px;
  --space-6: 24px;
  --radius: 12px;
  --text-sm: 14px;
  --text-base: 16px;
  --text-lg: 20px;
}

Ensuite, la consigne change de nature. Au lieu de « fais une carte avec un fond bleu clair et des coins arrondis », on demande « une carte utilisant les variables existantes, sans introduire de nouvelle couleur ni de nouvelle valeur d'espacement ». L'interdiction explicite compte autant que la demande.

Les angles morts systématiques

Au-delà de la cohérence, trois catégories manquent presque toujours, parce qu'on ne pense pas à les demander et que le modèle ne les propose pas.

Les états autres que le cas nominal

Une IA génère l'écran rempli de données. Elle ne génère ni l'état vide de la première utilisation, ni le chargement, ni l'échec réseau, ni le cas où un texte fait trois cents caractères au lieu de vingt. Or l'état vide est le premier que voit tout nouvel utilisateur : c'est celui qui décide s'il reste.

• Vide — que voit quelqu'un qui n'a encore rien créé, et que peut-il faire depuis là ?
• Chargement — que se passe-t-il pendant les deux secondes d'attente ?
• Erreur — le message explique-t-il quoi faire, ou seulement que ça a échoué ?
• Débordement — un titre très long casse-t-il la mise en page ?

L'accessibilité

Le code généré utilise volontiers un div cliquable là où un bouton s'impose. Visuellement identique, mais inaccessible au clavier, invisible pour un lecteur d'écran et non focalisable. Même logique pour les contrastes : une IA choisit des couleurs qui rendent bien sur son idée d'un écran, pas des couleurs qui passent un seuil de contraste.

Trois vérifications couvrent l'essentiel : tout ce qui est cliquable est-il atteignable en tabulant, chaque champ a-t-il une étiquette réellement liée, et le texte gris clair sur fond blanc reste-t-il lisible ?

Le mobile traité en second

Sauf demande explicite, le modèle conçoit pour un écran large et ajoute ensuite des adaptations. Le résultat tient sur mobile sans y être agréable : cibles tactiles trop petites, tableaux qui débordent, menus pensés au survol alors qu'il n'y a pas de survol au doigt. Demander le mobile d'abord coûte le même prix et donne un meilleur résultat aux deux extrémités.

Décrire une intention, pas un composant

La différence de résultat entre deux demandes tient souvent à ce qu'on décrit. Demander un composant donne un composant. Décrire à qui il s'adresse et ce qu'il doit provoquer donne des décisions cohérentes que vous n'auriez pas su formuler.

Un tableau de bord pour un artisan qui le consulte sur son téléphone entre deux chantiers, doigts sales, une main libre : il doit voir en trois secondes s'il a été payé.

Cette phrase impose d'elle-même de grandes cibles tactiles, un contraste élevé, une seule information dominante et pas de survol. Aucune de ces contraintes n'a été énoncée directement.

En pratique

1. Écrivez le socle de variables avant le premier écran, même approximatif. Le corriger plus tard est trivial ; le reconstituer après vingt écrans ne l'est pas.
2. Interdisez explicitement toute valeur hors système à chaque demande.
3. Demandez les quatre états dès la première génération, pas en rattrapage.
4. Regardez le parcours complet d'affilée, jamais écran par écran — c'est le seul moyen de voir l'incohérence.
5. Faites relire l'accessibilité par un second modèle : c'est une vérification mécanique, donc bien adaptée.