L'état de chargement, c'est le produit

Additionnez chaque état de chargement que votre produit affiche en un an. Chaque utilisateur, chaque session, chaque rafraîchissement. Ce chiffre, en heures-utilisateur, c'est l'écran le plus regardé que vous livrez. La plupart des équipes le traitent comme si personne ne regardait.

Le dashboard a droit à une revue de design. L'état vide, si vous avez lu les états vides sont le produit, a droit à une revue de design. L'état de chargement, lui, hérite d'un spinner de 16 pixels tiré d'une feuille de style de 2012 et d'une prière. C'est l'écran que l'utilisateur voit toujours, et celui que personne ne dessine.

L'état de chargement est une impression de marque

Chaque état de chargement est un contrat de confiance. Le produit dit à l'utilisateur : « Je travaille, je n'ai pas planté, l'attente est voulue. » Ce que l'écran affiche ensuite devient la façon dont la marque gère la pression.

Les états de chargement de Linear ressemblent à Linear. Des lignes squelettes en forme de liste de tickets, une création inline qui valide avant que le serveur confirme, des transitions de marque avec une cadence réfléchie. Ceux de Stripe ressemblent à Stripe. Le shimmer du bouton de paiement, les squelettes en forme de cartes dans le dashboard, le reçu qui se résout en état final. Les deux traitent l'attente comme le produit.

La mauvaise version, c'est le vieux gif qui tourne sur fond blanc. Aucune forme de contenu, aucun signal de progression, aucune marque. On dit à l'utilisateur : « On a eu du monde et on vous a oublié. » C'est bien une impression de marque. Simplement, pas celle que l'équipe voulait livrer.

Les cinq archétypes d'état de chargement

La plupart des équipes voient « l'état de chargement » comme un seul problème de design. Il y en a cinq. Chacun convient à un type d'attente différent et échoue pour une raison différente.

1. L'écran squelette

Une mise en page provisoire qui reprend la forme du contenu final. Des lignes là où seront les lignes, des cartes là où seront les cartes. L'œil s'accroche à la structure avant l'arrivée du contenu, et l'attente se lit comme une résolution, pas comme un départ.

La liste de tickets de Linear livre des squelettes en forme de lignes qui collent au pixel près à la liste finale. Stripe Dashboard livre des squelettes en forme de cartes dans la section des métriques, qui se résolvent en cartes remplies. Notion livre des emplacements en forme de blocs qui deviennent de vrais blocs au chargement du document. Même promesse : la forme du chargement prédit la forme finale.

À utiliser quand la structure est connue. À éviter quand la mise en page est assez dynamique pour que le squelette mente sur la suite.

2. L'UI optimiste

Afficher l'action de l'utilisateur immédiatement, avant la confirmation du serveur. Réconcilier en arrière-plan. Si le serveur est d'accord, l'UI ne clignote pas. S'il ne l'est pas, l'UI revient en arrière avec un chemin d'annulation visible.

La création inline de tickets de Linear est l'étalon-or. Appuyez sur C, tapez un titre, validez : le ticket est dans la liste avant la fin de l'aller-retour réseau. Le curseur et les déplacements de sélection de Figma sont optimistes sur toute la session multijoueur. L'utilisateur ne sent jamais le réseau.

À utiliser quand l'échec est rare et réversible. À éviter quand l'action est destructrice ou que l'utilisateur a besoin de la réponse du serveur pour continuer.

3. Le partiel en streaming

Afficher le premier morceau pendant que le reste est encore sur le fil. L'attente disparaît dans le résultat parce que l'utilisateur est déjà en train de le consommer.

Le flux de tokens de Claude est l'exemple le plus propre livré à ce jour, avec une cadence lissée qui se lit à vitesse humaine. Cursor streame le diff token par token, si bien que l'utilisateur lit du code avant que le modèle ait fini de l'écrire. Vercel streame le log de déploiement en direct : l'utilisateur regarde le build au lieu de l'attendre. L'article sur le design face à la latence de l'IA couvre la stratégie de latence plus large.

À utiliser quand le résultat a une cadence naturelle. À éviter quand les morceaux ne sont pas utiles isolément.

4. La progression comme contenu

L'attente elle-même est la valeur. Le log de déploiement, le pipeline de build, la trace de raisonnement d'un agent. L'utilisateur n'attend pas le résultat. Il lit le résultat.

La vue de déploiement de Vercel est l'exemple canonique. Le log de déploiement est l'état de chargement, et l'écran le plus livré de la plateforme. GitHub Actions fait pareil avec la sortie d'exécution étape par étape. Le panneau d'agent de Cursor montre la trace de raisonnement en direct, si bien qu'une tâche de plusieurs minutes a l'air d'avoir un but au lieu d'être bloquée. v0 et Lovable livrent cela sur des surfaces de prompt vers application, où le streaming du build est l'état de chargement et l'aperçu la récompense.

À utiliser quand l'attente est la valeur. À éviter quand les étapes n'ont aucun intérêt pour un utilisateur qui ne se soucie que de l'état final.

5. Le spinner de marque

La micro-pulsation, le dégradé, le shimmer. Le moment où le produit gagne un token de personnalité. Le shimmer du bouton de paiement de Stripe, la barre de progression en dégradé de Vercel, la micro-pulsation de Linear sur les attentes de transition. Aucun ne fait le travail seul. Ils se posent sur l'un des quatre premiers patterns, ajoutant un vernis de marque à une attente qui a déjà une structure.

À utiliser quand l'attente est courte et l'enjeu élevé. À éviter quand il n'y a ni squelette ni flux derrière. Un spinner de marque sans l'un des quatre premiers patterns en dessous, c'est un spinner de 1996 avec un code hex de 2026.

Les squelettes battent les spinners presque à chaque fois

Un squelette prédit la forme de ce qui arrive. Un spinner signale seulement que quelque chose se passe quelque part. Même attente, deux expériences différentes.

Le squelette du dashboard de Stripe est à peine plus rapide à l'horloge qu'une version avec spinner, mais l'écart de vitesse perçue est bien plus grand. L'utilisateur voit une mise en page en forme de cartes et commence à s'orienter avant l'arrivée des données. Quand les métriques se résolvent, l'œil est déjà en position. Avec un spinner, l'utilisateur fixe le centre de l'écran en attendant la permission de regarder ailleurs. Si vous pouvez prédire la mise en page, livrez un squelette. Sinon, livrez une ligne de statut.

L'UI optimiste est le code de triche

L'attente devient invisible parce que l'action est validée avant que l'attente commence.

Linear a livré de l'optimiste partout. Création de ticket, changement de statut, changement d'assigné, ajout de label, déplacement de cycle. Chacun écrit dans le store local dès l'intention et réconcilie après la réponse du serveur. Le multijoueur de Figma est optimiste sur les déplacements de curseur, la sélection et la plupart des modifications. Notion est optimiste sur l'édition de documents. Chaque produit a l'air d'un logiciel local parce que le réseau est caché sous la couche optimiste.

Deux choses font que ça marche. L'échec doit être rare et réversible, sinon l'UI clignote et l'utilisateur cesse de lui faire confiance. Et les erreurs doivent être visibles. Une action optimiste qui avale silencieusement une erreur serveur est pire que pas d'optimisme, parce qu'elle apprend à l'utilisateur que l'action a marché alors que non. Chaque écriture optimiste a besoin d'un undo, d'un toast ou d'un rollback que l'utilisateur peut voir.

Cinq règles pour de grands états de chargement

Respectez-en quatre sur cinq et l'attente se lit comme pensée. Respectez-en trois et l'état de chargement commence à sentir l'après-coup.

1. La forme du chargement prédit la forme finale. Des lignes squelettes pour des lignes, des cartes squelettes pour des cartes. Aucun saut de mise en page à la résolution du contenu.
2. L'attente reçoit du contenu quand c'est possible. Streamez les tokens, livrez le log, affichez le partiel. Un utilisateur qui lit n'attend pas.
3. Toute attente de plus de 800 ms reçoit un retour. Sous 800 ms, une transition propre suffit. Au-delà, l'utilisateur a besoin d'un signal que le système est vivant, même si ce n'est qu'une divulgation progressive de la structure d'abord, du contenu ensuite.
4. Les actions optimistes ont besoin d'un chemin d'annulation visible. Un toast, un rollback, un état d'erreur clair. L'optimisme sans récupération, c'est du gaslighting.
5. Pas de spinner sans raison de marque. Les spinners de marque se posent sur l'un des quatre premiers patterns, ils ne les remplacent jamais. Si la seule chose à l'écran est le spinner, le design n'est pas fini.

Le contexte plus profond se trouve dans l'analyse plus large des principes de web design et dans la manière dont les core web vitals traitent le décalage de mise en page comme un échec de performance perçue.

Les anti-patterns qui tuent les états de chargement

Six modes d'échec sont livrés plus souvent qu'ils ne devraient. Chacun se corrige, et chacun est en production quelque part en ce moment.

Le spinner indéfini sans progression. Un spinner qui tourne depuis quinze secondes sans aucun signal. L'utilisateur ne sait pas si la requête est vivante, morte ou coincée. Remplacez-le par une ligne de statut, une barre de progression ou une surface en streaming.

La modale bloquante impossible à fermer. Une modale de chargement qui prend tout l'écran en otage et refuse que l'utilisateur scrolle, copie ou lise le reste du produit. L'attente devient une prise d'otages.

La mise en page qui saute quand le squelette se résout. Un squelette qui ne correspond pas à la vraie mise en page. Les lignes bougent, les cartes se réagencent, l'en-tête se déplace. Le squelette n'est pas un autre design, c'est le même design sans contenu.

Le texte « Chargement... » en boucle infinie. Trois points qui tournent, aucune progression, aucun statut. L'utilisateur apprend en deux sessions à l'ignorer, ce qui tue le canal pour tout vrai statut que la surface livrera ensuite.

L'UI optimiste qui avale les erreurs en silence. L'action est validée dans l'UI, le serveur échoue, le produit ne dit jamais rien à l'utilisateur. La solution : un toast visible, un bouton d'annulation ou un rollback.

Les spinners de marque sur une attente de 100 ms. Un shimmer pour une attente qui se termine avant que l'utilisateur la remarque. Du pur surcoût. Les surfaces rapides méritent un fondu. Les surfaces lentes méritent une structure.

Concevoir la friction à dessein couvre les rares cas où une attente doit être visible volontairement. Les états de chargement n'en font pas partie. Ce sont des attentes qui doivent être invisibles, dessinées ou transformées en contenu.

L'audit des états de chargement

Six questions. Faites passer chaque surface de chargement par elles avant la prochaine release.

1. La forme du chargement prédit-elle la forme finale ? Des squelettes pour les mises en page prévisibles, des lignes de statut pour les imprévisibles. Aucun saut de mise en page à la résolution.
2. L'attente porte-t-elle de l'information ? Un squelette, un flux, un log de progression, une ligne de statut. Toute attente de plus de 800 ms sans rien dessus est une fuite.
3. Y a-t-il un seul message principal par attente ? « Chargement du dashboard » bat quatre signaux qui se chevauchent. Un signal, et la hiérarchie visuelle fait le travail.
4. L'état de chargement correspond-il à la voix de marque ? Lisez le texte de chargement à côté de l'écran rempli. Si le ton change, l'état de chargement porte une autre marque.
5. Les actions optimistes sont-elles réversibles et visibles en cas d'échec ? Chaque écriture optimiste a un undo, un toast ou un rollback. Aucun échec silencieux.
6. L'écran de chargement vendrait-il le produit à un inconnu ? Si le seul écran qu'il voyait était l'état de chargement, aurait-il l'impression du produit auquel il s'est inscrit ? Sinon, l'écran le plus regardé de votre app est aussi le plus mal dessiné.

Un produit où chaque état de chargement passe ces six tests paraît rapide même sur un réseau lent.

Choisissez le pattern, puis livrez l'attente

Les états de chargement ne sont pas la couche de finition. Ils sont la couche de marque, la couche de confiance et la couche de performance perçue, compressées dans l'écran que l'utilisateur voit plus que tout autre. Chaque attente est un choix de design, que l'équipe l'ait fait volontairement ou non.

Squelette là où la structure est connue. Optimiste là où l'échec est réversible. Streaming là où le résultat a une cadence. Progression comme contenu là où l'attente est la valeur. Spinner de marque seulement quand les quatre premiers font déjà leur travail. L'analyse des principes de design de landing page est la version page marketing de cette discipline.

Arrêtez de traiter l'état de chargement comme des excuses pour être lent. Cumulativement, c'est le produit. Faites que l'attente vaille leur temps.

FAQ

Quelle est la différence entre un écran squelette et un spinner de chargement ?

Un squelette prédit la forme du contenu final avec une mise en page provisoire, si bien que l'utilisateur commence à s'orienter avant l'arrivée des données. Un spinner signale seulement que quelque chose se passe, sans forme, sans structure, sans aperçu. Les squelettes réduisent l'attente perçue. Les spinners non.

Quand utiliser l'UI optimiste plutôt qu'une réponse en streaming ?

L'UI optimiste quand l'action de l'utilisateur est le travail, comme ajouter un ticket, basculer un statut ou déplacer une carte. Le streaming quand c'est le serveur qui fait le travail et que le résultat a une cadence naturelle, comme la génération de texte, la sortie d'un log ou un pipeline de déploiement. Les deux se combinent.

Est-il jamais acceptable de livrer un simple spinner ?

Seulement en solution de repli sous une seconde, seulement quand la mise en page est vraiment imprévisible, et seulement avec une raison de marque. Un squelette, une ligne de statut ou une surface en streaming bat le spinner sur toutes les métriques de performance perçue. Par défaut, le spinner passe en dernier.

Dessinez l'attente, livrez le produit

L'attente est l'écran que l'utilisateur voit le plus. L'impression de marque qu'il reçoit le plus souvent, le signal de confiance qu'il lit le plus souvent, et le test de performance perçue qu'il fait à chaque chargement de page. Une équipe qui dessine le dashboard pendant six semaines et l'état de chargement pendant un après-midi livre la mauvaise proportion de travail par rapport à l'endroit où l'utilisateur vit vraiment.

Si vous voulez une équipe qui dessine les états de chargement comme une partie du produit plutôt que comme le dernier sprint avant le lancement, engagez Brainy. Nous livrons des produits où l'attente fait partie de la marque et où la performance perçue bat la performance littérale.