Que fait Ingénierie UI Frontend ?
Aperçu
Construisez des interfaces utilisateur de qualité production, accessibles, performantes et visuellement soignées. L'objectif est une UI qui semble avoir été construite par un ingénieur conscient du design dans une grande entreprise, et non générée par une IA. Cela implique le respect d'un véritable système de design, une accessibilité correcte, des motifs d'interaction réfléchis, et l'absence d'"esthétique IA" générique.
Quand l'utiliser
- Construire de nouveaux composants UI ou pages
- Modifier des interfaces utilisateur existantes
- Implémenter des mises en page responsives
- Ajouter de l'interactivité ou de la gestion d'état
- Corriger des problèmes visuels ou d'expérience utilisateur
Architecture des composants
Structure des fichiers
Regroupez tout ce qui concerne un composant :
src/components/
TaskList/
TaskList.tsx # Implémentation du composant
TaskList.test.tsx # Tests
TaskList.stories.tsx # Stories Storybook (si utilisé)
use-task-list.ts # Hook personnalisé (si état complexe)
types.ts # Types spécifiques au composant (si nécessaire)
Motifs de composants
Privilégiez la composition à la configuration :
// Bien : Composable
<Card>
<CardHeader>
<CardTitle>Tâches</CardTitle>
</CardHeader>
<CardBody>
<TaskList tasks={tasks} />
</CardBody>
</Card>
// À éviter : Trop configuré
<Card
title="Tâches"
headerVariant="large"
bodyPadding="md"
content={<TaskList tasks={tasks} />}
/>
Gardez les composants concentrés :
// Bien : Fait une seule chose
export function TaskItem({ task, onToggle, onDelete }: TaskItemProps) {
return (
<li className="flex items-center gap-3 p-3">
<Checkbox checked={task.done} onChange={() => onToggle(task.id)} />
<span className={task.done ? 'line-through text-muted' : ''}>{task.title}</span>
<Button variant="ghost" size="sm" onClick={() => onDelete(task.id)}>
<TrashIcon />
</Button>
</li>
);
}
Séparez la récupération de données de la présentation :
// Conteneur : gère les données
export function TaskListContainer() {
const { tasks, isLoading, error } = useTasks();
if (isLoading) return <TaskListSkeleton />;
if (error) return <ErrorState message="Échec du chargement des tâches" retry={refetch} />;
if (tasks.length === 0) return <EmptyState message="Aucune tâche pour l'instant" />;
return <TaskList tasks={tasks} />;
}
// Présentation : gère le rendu
export function TaskList({ tasks }: { tasks: Task[] }) {
return (
<ul role="list" className="divide-y">
{tasks.map(task => <TaskItem key={task.id} task={task} />)}
</ul>
);
}
Gestion d'état
Choisissez l'approche la plus simple qui fonctionne :
État local (useState) → État UI spécifique au composant
État remonté → Partagé entre 2-3 composants frères
Context → Thème, auth, locale (lecture intensive, écriture rare)
État d'URL (searchParams) → Filtres, pagination, état UI partageable
État serveur (React Query, SWR) → Données distantes avec mise en cache
Store global (Zustand, Redux) → État client complexe partagé dans l'application
Évitez de percer des props à plus de 3 niveaux. Si vous passez des props à travers des composants qui ne les utilisent pas, introduisez un context ou restructurez l'arbre des composants.
Adhérence au système de design
Qualité UI guidée par les références
Lorsque le produit nécessite une direction visuelle distincte, collectez des preuves avant de choisir une mise en page :
- Recherchez un catalogue de références de confiance ou utilisez les références fournies par l'équipe produit.
- Étudiez deux ou trois écrans pertinents. Enregistrez les décisions concernant la hiérarchie, la densité, la navigation, les contrôles, le comportement responsive et les états d'interaction.
- Transformez ces décisions en un court contrat de design avant l'implémentation. Nommez le travail de l'écran, l'action principale, les états requis, les règles responsives et les motifs à rejeter.
- Reconstruisez la structure utile avec les propres composants, tokens, contenu et langage visuel du produit. Ne copiez jamais la marque, le texte propriétaire, l'imagerie ou la disposition exacte d'un autre produit.
Utilisez les références comme des preuves, pas comme des modèles. Si les références sont indisponibles, documentez les hypothèses et vérifiez le résultat par rapport au système de design existant du produit.
Évitez l'esthétique IA
L'UI générée par l'IA a des motifs reconnaissables. Évitez-les tous :
| Défaut IA | Pourquoi c'est un problème | Qualité production |
|---|---|---|
| Tout violet/indigo | Les modèles par défaut utilisent des palettes visuellement "sûres", rendant chaque application identique | Utilisez la palette de couleurs réelle du projet |
| Dégradés excessifs | Les dégradés ajoutent du bruit visuel et entrent en conflit avec la plupart des systèmes de design | Dégradés plats ou subtils correspondant au système de design |
| Tout arrondi (rounded-2xl) | L'arrondi maximal signale "amical" mais ignore la hiérarchie des rayons de bordure dans les designs réels | border-radius cohérent du système de design |
| Sections hero génériques | Mise en page basée sur un modèle sans lien avec le contenu réel ou le besoin utilisateur | Mises en page d'abord par le contenu |
| Texte factice Lorem ipsum | Le texte de remplacement cache les problèmes de mise en page que le contenu réel révèle (longueur, retour à la ligne, débordement) | Contenu de remplacement réaliste |
| Padding surdimensionné partout | Des espacements égaux et généreux détruisent la hiérarchie visuelle et gaspillent l'espace de l'écran | Échelle d'espacement cohérente |
| Grilles de cartes standard | Les grilles uniformes sont un raccourci de mise en page qui ignore la priorité de l'information et les habitudes de lecture | Mises en page guidées par l'objectif |
| Design chargé d'ombres | Les ombres superposées ajoutent de la profondeur qui concurrence le contenu et ralentit le rendu sur les appareils bas de gamme | Ombres subtiles ou absentes, sauf si le système de design le spécifie |
Espacement et mise en page
Utilisez une échelle d'espacement cohérente. N'inventez pas de valeurs :
/* Utilisez l'échelle : incréments de 0,25rem (ou ce que le projet utilise) */
/* Bien */ padding: 1rem; /* 16px */
/* Bien */ gap: 0.75rem; /* 12px */
/* Mauvais */ padding: 13px; /* Pas sur une échelle */
/* Mauvais */ margin-top: 2.3rem; /* Pas sur une échelle */
Typographie
Respectez la hiérarchie typographique :
h1 → Titre de page (un par page)
h2 → Titre de section
h3 → Titre de sous-section
body → Texte par défaut
small → Texte secondaire/d'aide
Ne sautez pas de niveaux de titres. N'utilisez pas de styles de titres pour du contenu qui n'est pas un titre.
Couleur
- Utilisez des tokens de couleur sémantiques :
text-primary,bg-surface,border-default— pas de valeurs hexadécimales brutes - Assurez un contraste suffisant (4,5:1 pour le texte normal, 3:1 pour le grand texte)
- Ne vous fiez pas uniquement à la couleur pour transmettre l'information (utilisez aussi des icônes, du texte ou des motifs)
Accessibilité (WCAG 2.1 AA)
Chaque composant doit répondre à ces normes :
Navigation clavier
// Chaque élément interactif doit être accessible au clavier
<button onClick={handleClick}>Cliquez-moi</button> // ✓ Focusable par défaut
<div onClick={handleClick}>Cliquez-moi</div> // ✗ Non focusable
<div role="button" tabIndex={0} onClick={handleClick} // ✓ Mais préférez <button>
onKeyDown={e => {
if (e.key === 'Enter') handleClick();
if (e.key === ' ') e.preventDefault();
}}
onKeyUp={e => {
if (e.key === ' ') handleClick();
}}>
Cliquez-moi
</div>
Labels ARIA
// Étiquetez les éléments interactifs qui manquent de texte visible
<button aria-label="Fermer la boîte de dialogue"><XIcon /></button>
// Étiquetez les champs de formulaire
<label htmlFor="email">Email</label>
<input id="email" type="email" />
// Ou utilisez aria-label lorsqu'aucun label visible n'existe
<input aria-label="Rechercher des tâches" type="search" />
Gestion du focus
// Déplacez le focus lorsque le contenu change
function Dialog({ isOpen, onClose }: DialogProps) {
const closeRef = useRef<HTMLButtonElement>(null);
useEffect(() => {
if (isOpen) closeRef.current?.focus();
}, [isOpen]);
// Piège le focus à l'intérieur de la boîte de dialogue lorsqu'elle est ouverte
return (
<dialog open={isOpen}>
<button ref={closeRef} onClick={onClose}>Fermer</button>
{/* contenu de la boîte de dialogue */}
</dialog>
);
}
États vides et d'erreur significatifs
// N'affichez pas d'écrans vierges
function TaskList({ tasks }: { tasks: Task[] }) {
if (tasks.length === 0) {
return (
<div role="status" className="text-center py-12">
<TasksEmptyIcon className="mx-auto h-12 w-12 text-muted" />
<h3 className="mt-2 text-sm font-medium">Aucune tâche</h3>
<p className="mt-1 text-sm text-muted">Commencez par créer une nouvelle tâche.</p>
<Button className="mt-4" onClick={onCreateTask}>Créer une tâche</Button>
</div>
);
}
return <ul role="list">...</ul>;
}
Design responsive
Concevez d'abord pour le mobile, puis étendez :
// Tailwind : responsive mobile-first
<div className="
grid grid-cols-1 /* Mobile : une colonne */
sm:grid-cols-2 /* Petit : 2 colonnes */
lg:grid-cols-3 /* Grand : 3 colonnes */
gap-4
">
Testez à ces points de rupture : 320px, 768px, 1024px, 1440px.
Chargement et transitions
// Squelette de chargement (pas de spinners pour le contenu)
function TaskListSkeleton() {
return (
<div className="space-y-3" aria-busy="true" aria-label="Chargement des tâches">
{Array.from({ length: 3 }).map((_, i) => (
<div key={i} className="h-12 bg-muted animate-pulse rounded" />
))}
</div>
);
}
// Mises à jour optimistes pour une rapidité perçue
function useToggleTask() {
const queryClient = useQueryClient();
return useMutation({
mutationFn: toggleTask,
onMutate: async (taskId) => {
await queryClient.cancelQueries({ queryKey: ['tasks'] });
const previous = queryClient.getQueryData(['tasks']);
queryClient.setQueryData(['tasks'], (old: Task[]) =>
old.map(t => t.id === taskId ? { ...t, done: !t.done } : t)
);
return { previous };
},
onError: (_err, _taskId, context) => {
queryClient.setQueryData(['tasks'], context?.previous);
},
});
}
Voir aussi
Pour les exigences d'accessibilité détaillées et les outils de test, voir ../../references/accessibility-checklist.md.
Rationalisations courantes
| Rationalisation | Réalité |
|---|---|
| "L'accessibilité est un bonus" | C'est une exigence légale dans de nombreuses juridictions et un standard de qualité technique. |
| "Nous le rendrons responsive plus tard" | Adapter le design responsive après coup est 3 fois plus difficile que de le construire dès le départ. |
| "Le design n'est pas final, donc je vais sauter le style" | Utilisez les valeurs par défaut du système de design. Une UI non stylée crée une première impression négative pour les relecteurs. |
| "Ce n'est qu'un prototype" | Les prototypes deviennent du code de production. Construisez les fondations correctement. |
| "L'esthétique IA est acceptable pour l'instant" | Elle signale une faible qualité. Utilisez le système de design réel du projet dès le début. |
Drapeaux rouges
- Composants de plus de 200 lignes (divisez-les)
- Styles en ligne ou valeurs pixel arbitraires
- États d'erreur, de chargement ou vides manquants
- Absence de test de navigation clavier
- Couleur comme seul indicateur d'état (rouge/vert sans texte ni icônes)
- "Look IA" générique (dégradés violets, cartes surdimensionnées, mises en page standard)
Vérification
Après avoir construit l'UI :
- Le composant se rend sans erreurs dans la console
- Tous les éléments interactifs sont accessibles au clavier (parcourez la page avec la touche Tab)
- Le lecteur d'écran peut transmettre le contenu et la structure de la page
- Responsive : fonctionne à 320px, 768px, 1024px, 1440px
- Les états de chargement, vide, erreur, succès et permission sont gérés le cas échéant
- Respecte le système de design du projet (espacement, couleurs, typographie)
- Le résultat rendu passe une revue finale spécifique à l'UI
- Aucun avertissement d'accessibilité dans les outils de développement ou axe-core