1. Contexte : votre App — l’invité dans la maison de ChatGPT
Avant de dessiner des boutons et de choisir des polices, il faut accepter la réalité : l’utilisateur n’ouvre pas « votre site », il est dans ChatGPT. ChatGPT possède déjà ses :
- schémas de couleurs,
- polices et tailles,
- espacements et mise en page des éléments.
Votre widget s’affiche dans cet environnement, le plus souvent dans un iframe. Conclusion importante : visuellement, l’App doit ressembler à une extension naturelle de l’interface de ChatGPT, et non à une bannière sortie de 2008.
Les directives officielles d’OpenAI disent justement cela : ne pas casser les couleurs et les polices système, n’ajouter que des accents de marque modérés et suivre la typographie et la grille de base de la plateforme.
Concrètement, cela signifie trois choses.
Premièrement, le fond, la couleur de texte de base, la typographie standard — tout cela doit être hérité de ChatGPT ou des variables système, pas « je suis artiste, je le vois comme ça ».
Deuxièmement, si vous voulez « votre style », il doit se concentrer sur les accents : boutons principaux, badges, états mis en avant. Mais pas de fond arc‑en‑ciel ni de police personnalisée Comic Sans — même si vous en avez très envie au fond de vous.
Troisièmement, les modes inline et fullscreen d’une même App doivent visuellement faire partie du même monde : mêmes couleurs pour les CTA, mêmes rayons et espacements pour les cartes, même typographie. L’utilisateur ne doit pas avoir l’impression qu’en passant de l’inline au fullscreen il arrive sur un autre produit.
Voyons ensuite par couches : couleurs et thèmes, typographie, espacements et grille, puis — comment Tailwind et shadcn/ui aident à assembler le tout.
Insight
Le bac à sable de ChatGPT ne se contente pas de limiter les fonctionnalités de votre widget, il lui ajoute aussi ses styles.
Premièrement — c’est l’en‑tête HTML
Original depuis le site :
<html lang="ru">
Dans le bac à sable :
<html lang="en-US" data-theme="light" class="light" style="--safe-area-inset-top: 0px; --safe-area-inset-bottom: 0px; --safe-area-inset-left: 0px; --safe-area-inset-right: 0px;">
Deuxièmement — ce sont les styles CSS natifs, pour que votre widget ressemble davantage à ChatGPT :
<style>
html,body,#root{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;margin:0;padding:0}
html,body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Helvetica Neue,Arial,sans-serif!important}
button,input,textarea,select{font-family:inherit}
html{background-color:#fff}
html.dark{background-color:#212121}
html.mobileSkybridge.dark{background-color:#000}
@supports (font: -apple-system-body){html.mobileSkybridge{font:-apple-system-body}}
</style>
Mieux vaut s’en souvenir — il y aura moins de surprises.
2. Thèmes et couleurs : vivre dans les univers clair et sombre
Thèmes clair et sombre
L’interface de ChatGPT prend déjà en charge les thèmes clair et sombre. Votre widget s’affiche dans l’un d’eux, et l’utilisateur peut passer de l’un à l’autre à tout moment. Donc, tout fond blanc ou noir « en dur » est une mine potentielle.
Imaginez un widget qui dessine un fond blanc et un texte noir. Dans le thème clair, ça passe. Dans le thème sombre — c’est un projecteur dans les yeux. La situation inverse avec un fond noir en thème clair n’est pas meilleure. C’est pourquoi les recommandations officielles conseillent de ne pas hardcoder les couleurs, mais de s’appuyer sur le thème/les variables de l’hôte.
Dans l’Apps SDK, l’environnement vous donne généralement une API ou des variables CSS pour le thème actuel. La documentation mentionne des variantes comme window.openai.theme et l’utilisation de variables CSS standard de ChatGPT. Et il y a toujours prefers-color-scheme et l’utilitaire dark: de Tailwind.
L’idée est à peu près la suivante : votre widget doit automatiquement adapter à la thématique de l’hôte des éléments tels que :
- le fond des cartes (légèrement plus clair/sombre que le fond de base),
- la couleur du texte (contraste suffisant),
- les bordures, ombres et états de survol.
Exemple d’un simple wrapper de thème avec Tailwind :
// components/AppShell.tsx
export function AppShell({ children }: { children: React.ReactNode }) {
return (
<div className="bg-background text-foreground">
{/* bg-background/text-foreground sont surchargés par le thème */}
{children}
</div>
);
}
Ici, bg-background et text-foreground ne sont pas des classes Tailwind standard, mais des alias vers des variables CSS de votre design system (par exemple issues de shadcn/ui), elles‑mêmes reliées aux thèmes clair/sombre de ChatGPT.
Couleurs système vs accents de marque
OpenAI dit assez clairement : les couleurs système de ChatGPT ne se modifient pas. Le texte de base, les panneaux standard du chat, le fond — tout cela doit rester dans les couleurs de la plateforme. Votre terrain de jeu : les accents à l’intérieur du widget : boutons CTA (call to action — action principale), badges, petits éléments.
Dans la pratique GiftGenius, cela signifie que :
- le fond de la carte cadeau est proche du système,
- le texte — de couleur standard, comme dans le chat,
- la couleur de marque de GiftGenius est utilisée pour le bouton principal « Choisir un cadeau » et, éventuellement, pour un badge de remise.
On peut imaginer un tableau :
| Élément | À faire | À éviter |
|---|---|---|
| Fond du widget | Hériter de ChatGPT | Mettre un dégradé de marque criard |
| Texte principal | Hériter de la couleur système | Le rendre coloré/grisé au point d’être illisible |
| Bouton CTA principal | Utiliser la couleur d’accent de la marque | Lui mettre un « arc‑en‑ciel » et 5 couleurs |
| Boutons/liens secondaires | Proches des liens système | Les rendre aussi tape‑à‑l’œil que le CTA |
| Ombres/bordures | Douces, minimalistes | Contours néon épais |
Mini‑exemple Tailwind pour la couleur principale :
// styles/globals.css (extrait)
:root {
--gift-accent: 222 84% 56%; /* hsl */
}
.dark {
--gift-accent: 222 84% 64%; /* un peu plus clair pour le mode sombre */
}
// components/GiftButton.tsx
export function GiftButton({ children }: { children: React.ReactNode }) {
return (
<button className="rounded-md bg-[hsl(var(--gift-accent))] px-4 py-2 text-sm font-medium text-white hover:opacity-90">
{children}
</button>
);
}
Vous ne touchez pas au fond du widget entier, mais appliquez délicatement votre couleur au bouton CTA principal.
Contraste et WCAG sans dogmatisme
Même si vous ne préparez pas un examen WCAG, il y a un repère simple : le texte doit être lisible. Plus la police est petite, plus le contraste doit être élevé. Les cours sur l’accessibilité conseillent de maintenir le contraste du texte par rapport au fond à ~4,5:1 pour le texte principal. Nous n’entrons pas ici dans les détails des normes d’accessibilité : nous voulons un repère pratique — un contraste suffisant entre le texte et le fond.
En pratique :
- n’utilisez pas de texte gris clair sur fond gris clair au nom de « l’élégance » ;
- évitez le texte gris foncé sur fond presque noir en thème sombre ;
- vérifiez au moins à l’œil : si vous plissez les yeux, l’utilisateur souffrira aussi.
Fixez‑vous une règle : tout texte secondaire (légendes, aides) reste lisible, simplement un peu moins accentué par la couleur et la taille, mais pas « fantomatique ».
3. Typographie : polices système, hiérarchie et bon sens
Polices système au lieu de votre propre fonte
Les directives officielles recommandent d’utiliser les polices système de la plateforme, comme SF Pro, Roboto et leurs équivalents, et de ne pas imposer votre webfont. La raison n’est pas seulement la performance, mais aussi le fait que votre App doit sembler un élément natif de l’interface.
Dans une application Next.js, le plus simple est de faire en sorte que tout à l’intérieur du widget hérite de la pile système de base. Avec Tailwind, c’est généralement déjà configuré via font-sans. Si vous voulez être plus explicite :
// app/layout.tsx (extrait)
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="en">
<body className="font-sans antialiased">
{children}
</body>
</html>
);
}
Inutile de charger 3 familles via Google Fonts. Pour notre GiftGenius pédagogique, une police système stricte aura un rendu plus soigné qu’un hypothétique Lobster.
Hiérarchie des tailles
Quelques niveaux de typographie suffisent : titre de bloc, sous‑titre/paramètre clé, texte principal et légende.
Pour une carte inline de GiftGenius, par exemple, il est pratique de se mettre d’accord sur ces niveaux :
| Rôle | Classe Tailwind | Exemple |
|---|---|---|
| Titre de la carte | |
Nom du cadeau |
| Paramètre clé | |
Prix ou catégorie |
| Description | |
Brève description |
| Légende/détails | |
Livraison, boutique |
Mini‑composant de carte :
// components/GiftCard.tsx
type GiftCardProps = {
title: string;
price: string;
description: string;
};
export function GiftCard({ title, price, description }: GiftCardProps) {
return (
<div className="rounded-lg border bg-card p-4">
<h3 className="text-base font-semibold">{title}</h3>
<p className="mt-1 text-sm font-medium text-emerald-600">{price}</p>
<p className="mt-2 text-sm text-muted-foreground">{description}</p>
</div>
);
}
Ici :
- il n’y a pas d’énorme H1 ;
- toutes les informations sont compactes ;
- la hiérarchie se lit via la taille et la graisse.
Alignement et longueur de ligne
Une interface de chat est en général étroite, surtout en inline. Inutile donc de se compliquer la vie avec une typographie complexe : un alignement à gauche classique et une longueur de ligne de 40–60 caractères sont confortables.
Bonnes habitudes :
- ne centrez pas les longs textes dans une carte — ils sont plus difficiles à lire ;
- n’écrivez pas TOUT EN MAJUSCULES ;
- ne descendez pas en‑dessous de 14 px pour le texte de base (avec Tailwind, c’est text-sm) sans très bonne raison.
En cas de doute, souvenez‑vous : c’est une personne fatiguée dans le métro sur téléphone qui lira, pas vous sur un écran parfait de 27 pouces.
4. Espacements, densité et grille
Si les couleurs et les polices sont la « peinture », les espacements sont l’air. Sans eux, même les cartes les plus soignées deviennent brouillonnes.
OpenAI souligne dans ses recommandations : les éléments ne doivent pas être « collés », il vaut mieux prendre les espacements et les rayons dans une design system ou un framework UI (Tailwind, shadcn/ui, etc.), et réduire au minimum le scroll horizontal.
Principe « respirer »
Le pattern le plus simple : utiliser une échelle d’espacements unifiée (par exemple un pas de 4 px ou 8 px) et ne pas réinventer la taille à chaque fois. Dans Tailwind, c’est déjà intégré : p-2, p-3, p-4, gap-3, etc.
Exemple d’une petite grille pour la liste des cadeaux en inline :
// components/GiftListInline.tsx
export function GiftListInline({ children }: { children: React.ReactNode }) {
return (
<div className="flex flex-col gap-3">
{children}
</div>
);
}
Chaque carte est séparée par gap-3, possède ses p-4 internes, et cela suffit déjà pour que la liste ne ressemble pas à une « feuille à rallonge ».
Colonnes : inline vs fullscreen
La documentation UX des Apps SDK recommande pour un widget inline de rester sur 1–2 colonnes de cartes, et en fullscreen on peut se permettre 2–3 si la largeur est suffisante.
La raison est simple : dans le chat, la largeur est limitée, surtout sur mobile, et deux colonnes, c’est déjà la limite en termes de lisibilité. En fullscreen, vous disposez de presque tout l’écran et pouvez resserrer le contenu.
Schéma indicatif :
flowchart LR
subgraph Inline
A[1 colonne
écran étroit]
B[2 colonnes
sur desktop]
end
subgraph Fullscreen
C[2 colonnes
scénario principal]
D[3 colonnes
pour grilles/catalogues]
end
Implémentation avec Tailwind pour GiftGenius :
// components/GiftGrid.tsx
export function GiftGrid({ fullscreen, children }: { fullscreen?: boolean; children: React.ReactNode }) {
const base = fullscreen ? "grid-cols-2 md:grid-cols-3" : "grid-cols-1 sm:grid-cols-2";
return (
<div className={`grid gap-4 ${base}`}>
{children}
</div>
);
}
En mode inline, vous donnez une colonne sur mobile et deux sur des écrans plus larges. En fullscreen, vous passez directement à 2–3 colonnes selon la largeur.
Éviter le scroll horizontal
Par nature, le chat est vertical. L’utilisateur est habitué à faire défiler vers le bas, pas sur les côtés. Donc :
- essayez de faire en sorte que tableaux et cartes rentrent dans la largeur du conteneur ;
- n’imposez pas des largeurs fixes comme width: 600px; à un élément qui vit dans un conteneur flexible ;
- utilisez max-w-full, overflow-x-auto seulement en « dernier recours », pas par défaut.
Pour les cartes GiftGenius, il est pratique de définir w-full et de laisser la grille décider du nombre par ligne.
5. Adaptation à l’intérieur du conteneur ChatGPT
En frontend classique, vous contrôlez entièrement le viewport. Dans ChatGPT, ce contrôle est limité : votre widget est placé dans le conteneur du chat, avec ses propres dimensions et règles. L’Apps SDK fournit quelques ponts utiles : hauteur maximale, safe area pour les encoches, type d’appareil, etc.
maxHeight et contraintes verticales
En mode inline, ChatGPT peut limiter la hauteur du widget pour qu’il ne « mange » pas tout l’écran. Des hooks comme useMaxHeight() vous permettent de savoir combien d’espace il est possible d’occuper, et d’ajouter des scrolls internes là où nécessaire.
Pseudocode :
// Pseudocode, pas une API réelle:
const maxHeight = useMaxHeight();
return (
<div style={{ maxHeight, overflowY: "auto" }}>
<GiftGrid>{/* ... */}</GiftGrid>
</div>
);
Ainsi, vous évitez la situation où le widget bute contre le bas de l’écran et où les messages du chat « partent » dans une autre vie.
safeArea et appareils mobiles
Sur mobile, il peut y avoir des encoches en haut et en bas, une barre d’état, des panneaux système. L’Apps SDK permet d’obtenir la safeArea et d’ajuster les espacements afin que rien ne parte sous « l’encoche » du téléphone.
Au niveau CSS, vous pouvez ajouter des paddings supplémentaires :
// Pseudocode
const { top, bottom } = useSafeArea(); // admettons qu’il renvoie { top: 8, bottom: 16 }
return (
<div style={{ paddingTop: top, paddingBottom: bottom }}>
{/* contenu */}
</div>
);
Dans le cadre du cours, l’important est de comprendre le principe : le widget doit respecter la limite de hauteur et la zone sûre, sinon l’UX se transforme immédiatement en « scrolle encore trois fois pour voir le bouton ».
6. Tailwind et shadcn/ui : ne réinventez pas les boutons
Écrire tout l’UI à la main en CSS pur, c’est presque du sport de haut niveau aujourd’hui. Dans le contexte des ChatGPT Apps, il est bien plus simple de prendre une bibliothèque éprouvée et de l’adapter aux exigences de la plateforme. Dans ce cours, nous nous appuyons sur Tailwind et shadcn/ui comme stack de base.
Tailwind comme dictionnaire d’espacements et de couleurs
Tailwind fournit un ensemble pratique d’utilitaires :
- espacements (p-4, gap-3),
- tailles (text-sm, text-base),
- couleurs (text-muted-foreground, bg-card), qui, dans shadcn/ui et systèmes similaires, sont déjà reliées aux variables CSS du thème.
C’est parfaitement aligné avec les exigences de ChatGPT :
- vous n’inventez pas des espacements arbitraires,
- vous définissez les tailles de texte de façon consistante,
- vous ne cassez pas les couleurs système, vous utilisez des tokens pré‑approuvés.
shadcn/ui comme ensemble de composants soignés
shadcn/ui (et des bibliothèques similaires) fournit des Card, Button, Input, Tabs, etc., prêts à l’emploi et configurés sur le thème Tailwind. Cela accélère grandement l’assemblage d’une interface propre et minimaliste, notamment pour les cartes GiftGenius.
Exemple de GiftCard avec shadcn/ui :
// components/GiftCardShadcn.tsx
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";
import { Button } from "@/components/ui/button";
type GiftCardProps = {
title: string;
price: string;
description: string;
};
export function GiftCardShadcn(props: GiftCardProps) {
return (
<Card>
<CardHeader>
<CardTitle className="text-base">{props.title}</CardTitle>
</CardHeader>
<CardContent className="space-y-2">
<p className="text-sm font-medium text-emerald-600">{props.price}</p>
<p className="text-sm text-muted-foreground">{props.description}</p>
<Button className="mt-2">Choisir un cadeau</Button>
</CardContent>
</Card>
);
}
L’essentiel ici, ce ne sont pas shadcn en soi, mais les principes :
- le titre n’est pas gigantesque ;
- la description est lisible ;
- le bouton est stylé selon la design system commune, pas « à sa façon ».
Ajustement pour ChatGPT
Dans un projet réel, vous pouvez adapter la palette au style minimaliste de ChatGPT : fond clair, ombres douces, rayons soignés. Le plan du module propose justement de s’appuyer sur une design system existante, et non de créer votre propre univers.
Approche simple :
- prendre la base shadcn/ui ;
- garder la police système ;
- configurer une ou deux couleurs de marque dans les tokens primary / accent ;
- vous assurer que l’inline et le fullscreen utilisent les mêmes tokens.
Vous obtenez ainsi un noyau visuel cohérent sans efforts superflus.
7. Langage visuel de GiftGenius : tout assembler
Systématisons ce que nous pouvons déjà considérer comme le « langage visuel » de notre GiftGenius.
Premièrement, le schéma de couleurs. Le fond et le texte héritent de ChatGPT ; la couleur d’accent — discrète mais visible — s’applique aux boutons CTA et, éventuellement, aux badges de remise. En thème sombre, cet accent est un peu plus clair afin de conserver le contraste.
Deuxièmement, la typographie. Police système de base, tailles text-sm pour le texte principal et text-base pour les titres des cartes. L’italique et les capitales sont utilisés rarement, uniquement à bon escient. Les titres dans le master fullscreen sont un cran au‑dessus, mais toujours sans text-4xl criard.
Troisièmement, espacements et grille. En mode inline, la liste des cadeaux — une ou deux colonnes avec gap-3/gap-4, chaque carte avec p-4. En fullscreen — 2–3 colonnes, des étapes du master avec des espacements suffisants entre formulaires et boutons. Pas de scroll horizontal pour les scénarios principaux.
Petit schéma pour les écrans de GiftGenius :
graph TD A[Inline: liste de cadeaux] --> B[GiftCard
couleurs/typographie/CTA] A --> C[GiftGrid 1–2 colonnes] D[Fullscreen: assistant de sélection] --> E[Étape 1
formulaire] D --> F[Étape 2
filtres/plages] D --> G[Étape 3
confirmation] B --> H[GiftButton
accent de marque]
Quatrièmement, la compatibilité avec le contexte de l’hôte. Tous les éléments se comportent correctement lors du basculement clair/sombre, respectent maxHeight et ne se cachent pas sous la safe‑area. Les couleurs n’entrent pas en conflit avec ChatGPT, et les boutons CTA ont le même aspect partout, pour que l’utilisateur sache « à la mémoire musculaire » où cliquer.
Ce set de décisions rend déjà votre application présentable non seulement aux développeurs, mais aussi aux utilisateurs réels ou aux product managers : il y aura de la matière à discuter, au‑delà de « ici nous avons MCP, et là Agents SDK ».
8. Accessibilité (Accessibility Guidelines, WCAG AA)
Nous avons déjà mentionné WCAG en parlant du contraste texte/fond dans la section 2.3. Là, un seul repère pratique nous intéressait — ne pas tuer la lisibilité. Voyons maintenant l’accessibilité un peu plus largement : comment la même interface est perçue par celles et ceux qui ne la voient pas, et par ChatGPT en mode vocal.
WCAG AA — c’est un niveau du standard d’accessibilité issu de l’ensemble de règles international WCAG (Web Content Accessibility Guidelines), qui décrit comment rendre les sites et interfaces accessibles aux personnes ayant des limitations visuelles, motrices, cognitives, etc.
L’idée principale de WCAG AA — transformer une interface non seulement « théoriquement accessible » en une interface vraiment utilisable. Ce niveau inclut des dizaines d’exigences qui influencent directement la qualité de l’interaction. Parmi elles — le seuil de contraste texte/fond d’environ 4,5:1 dont nous avons parlé, ainsi que des exigences sur la taille des zones cliquables, les états de focus, les erreurs de formulaires, etc.
Un autre volet — la prise en charge des technologies d’accessibilité, y compris les lecteurs d’écran. Le niveau AA exige une sémantique correcte : les titres doivent être des titres, les listes — des listes, les boutons — des boutons, et les éléments interactifs doivent avoir des rôles correctement assignés et des alternatives textuelles. Cela permet aux utilisateurs de VoiceOver, TalkBack ou NVDA de comprendre pleinement la structure et le sens de l’interface.
Screen reader (lecteur d’écran)
Screen reader (lecteur d’écran) — un programme qui vocalise et/ou structure le contenu de l’écran, permettant aux personnes malvoyantes d’utiliser un ordinateur, un smartphone ou des applications web.
Mais un lecteur d’écran n’est pas simplement « un programme qui lit le texte à voix haute ». C’est un véritable système d’interaction avec l’interface qui transforme la représentation visuelle d’un site ou d’une application en une navigation sonore et structurée accessible.
ChatGPT, screen reader et WCAG AA
Si votre widget est balisé selon les principes de WCAG AA (rôles appropriés, titres corrects, libellés pour les boutons), il devient compréhensible non seulement pour les lecteurs d’écran, mais aussi pour ChatGPT en mode vocal. L’utilisateur parle à ChatGPT, et le modèle, en s’appuyant sur cette même structure sémantique, peut « virtuellement » faire la même chose qu’une personne : trouver les éléments d’interface, cliquer sur des boutons, suivre des liens, etc.
Selon les exigences du ChatGPT Store, le support du standard WCAG AA est obligatoire pour chaque application. Chaque widget et chaque tool doivent avoir des descriptions de qualité maximale et détaillées, et le markup — être conforme aux standards WCAG AA : sémantique correcte, libellés lisibles, états prévisibles.
C’est pourquoi l’exigence WCAG AA n’est pas une « fonctionnalité pour personnes avec besoins spécifiques », mais un principe de design de base pour que ChatGPT Apps puisse fonctionner pleinement avec votre application, notamment lorsque l’utilisateur interagit en mode vocal.
Nous reviendrons sur les scénarios de voice‑UX, les différences entre dialogue vocal et texte, et les exigences du ChatGPT Store — dans d’autres leçons de ce module et dans le module sur la publication d’une App. Mais tout cela repose sur le socle que vous avez vu maintenant : mode vocal = multimodalité + accessibilité (WCAG AA + lecteurs d’écran).
9. Erreurs courantes de design visuel d’une ChatGPT App
Erreur n° 1 : fonds blanc/noir et couleurs de texte codés en dur.
Un développeur dessine un fond blanc et un texte noir sans penser au thème sombre. En thème clair, ça passe encore, en sombre — ça devient un projecteur et gâche tout l’UX. Mieux vaut utiliser les couleurs système et le thème de l’hôte (variables CSS, prefers-color-scheme ou API des Apps SDK), et garder vos couleurs pour les accents.
Erreur n° 2 : branding trop agressif.
Un fond en dégradé criard, une police personnalisée, des bordures criardes. Le widget commence à ressembler à une bannière promo, pas à une partie de l’interface de ChatGPT. Les directives exigent au contraire : un aspect minimaliste et « natif », avec une utilisation soignée de la couleur de marque seulement dans les éléments clés, par exemple les boutons principaux.
Erreur n° 3 : absence de hiérarchie typographique.
Tous les textes ont la même taille et le même poids, ou au contraire — trois niveaux de titres sur une petite carte, en plus en capitales. L’utilisateur ne comprend pas ce qui est important : nom, prix ou description. Mieux vaut définir 3–4 niveaux et s’y tenir partout : titre, paramètre clé, texte principal, légende.
Erreur n° 4 : éléments collés sans espacements.
Les cartes sont collées entre elles, le texte est au ras du bord, les boutons collent au texte. Sur desktop, ça passe encore, sur mobile, cela devient du bruit visuel. Recommandation : utilisez une échelle d’espacements unifiée (par exemple les classes Tailwind p-4, gap-3) et ne soyez pas avare d’air.
Erreur n° 5 : vouloir caser 4–5 colonnes en mode inline.
Le développeur est mentalement encore sur une page d’e‑commerce et crée une mosaïque de quatre cartes étroites dans le chat. Sur grand écran, c’est discutable, sur mobile — illisible, et on ajoute du scroll horizontal. En widget inline, une à deux colonnes suffisent en général ; gardez la troisième pour le mode fullscreen.
Erreur n° 6 : ignorer les limites de hauteur et la safe‑area.
Le widget dessine une liste géante sans scroll interne et sans tenir compte de maxHeight, si bien que les boutons se retrouvent « sous le fond de l’écran ». Ou des éléments se cachent sous l’encoche sur mobile. Il faut utiliser les données de hauteur maximale et de zone sûre pour répartir correctement la hauteur et les espacements internes.
Erreur n° 7 : incohérence des boutons et cartes entre inline et fullscreen.
En inline, le bouton est vert et arrondi, et en fullscreen — bleu et carré. L’utilisateur perd la sensation d’un produit unifié. Il faut extraire les styles de base des boutons et des cartes dans un composant/thème commun et les utiliser dans tous les modes.
Erreur n° 8 : police « d’auteur » et fioritures décoratives.
Charger une webfont lourde « pour faire joli » casse la cohérence visuelle avec ChatGPT et parfois la performance. Les recommandations de la plateforme préconisent d’utiliser les polices système et une typographie soignée. Si vous voulez vous exprimer en tant que designer — mieux vaut travailler les icônes et le microcopy, pas faire une révolution typographique.
GO TO FULL VERSION