Product Building · 2 novembre 2026

La page vide est l'écran le plus important de votre produit, et celui que personne ne dessine

Tout le monde conçoit l'écran plein. L'utilisateur, lui, arrive toujours sur le vide. Ce que coûte cet oubli, et comment le corriger.

Ouvrez n'importe quel fichier de maquettes. Vous y trouverez des tableaux remplis, des listes de douze éléments, des tableaux de bord avec des courbes qui montent.

Puis ouvrez le produit avec un compte neuf.

L'écart entre les deux est l'une des causes les plus banales d'abandon précoce, et l'une des plus faciles à corriger.

Pourquoi on dessine toujours plein

Trois raisons, toutes compréhensibles.

Parce que c'est plus facile à concevoir. Un écran rempli donne une structure à organiser. Un écran vide n'offre rien, et il faut inventer ce qu'on y met.

Parce que c'est plus agréable à montrer. Un tableau de bord avec des données impressionne en réunion. Une page vide ressemble à un produit inachevé, même quand elle est exactement ce qu'il faut.

Parce que l'équipe ne voit jamais le vide. Les comptes de test sont remplis depuis des mois. Les démonstrations utilisent un jeu de données préparé. Plus personne dans l'équipe n'a vu le produit tel que le découvre un nouvel utilisateur.

Le résultat est systématique : l'état le plus travaillé du produit est celui que l'utilisateur atteindra peut-être dans trois semaines, et l'état le moins travaillé est celui qu'il voit en premier.

Deux visages du même produit : l'équipe voit des comptes de test remplis ; l'utilisateur découvre un compte neuf et une page vide avec un bouton Créer. Puis ses trois questions : qu'est-ce que je suis censé faire ici, à quoi ça ressemblera rempli, est-ce que ça vaut le coup

Ce que l'utilisateur affronte vraiment

Il arrive sur une page vide avec trois questions, dans cet ordre.

Qu'est-ce que je suis censé faire ici ? Une page vide ne communique rien par elle-même. Le nom de la section et un bouton « Créer » supposent que la personne sait déjà ce qu'elle va créer et pourquoi.

À quoi ça ressemblera quand ce sera rempli ? C'est la question la plus sous-estimée. L'utilisateur ne sait pas à quoi il s'engage. Il hésite à investir cinq minutes dans quelque chose dont il n'imagine pas le résultat.

Est-ce que ça vaut le coup ? Au moment précis où il devrait fournir l'effort initial, il n'a encore reçu aucune valeur. C'est l'asymétrie fondamentale de tout démarrage.

Les quatre vides, qui n'appellent pas la même réponse

On range souvent tous les écrans sans contenu dans la même catégorie. Ils relèvent pourtant de situations très différentes.

Le vide de départ. La personne n'a encore rien créé. C'est un problème d'amorçage : il faut montrer à quoi ça ressemblera et réduire l'effort du premier pas.

Le vide de recherche. Un filtre ne ramène rien. C'est un problème d'issue : il faut dire pourquoi, et proposer un élargissement. Un écran de recherche vide qui ne propose rien oblige l'utilisateur à deviner ce qu'il a mal fait.

Le vide de réussite. La boîte de réception est à zéro, toutes les tâches sont traitées. C'est le seul vide qu'il faut célébrer, et presque personne ne le fait.

Le vide d'erreur. Rien ne s'affiche parce que quelque chose a échoué. Le pire des quatre, parce qu'il se confond visuellement avec les trois autres et laisse l'utilisateur croire que le produit est normalement vide.

Un même composant générique pour ces quatre cas est une erreur de conception courante.

Les quatre vides et leur réponse : départ, montrer à quoi ça ressemblera ; recherche, dire pourquoi et proposer un élargissement ; réussite, le seul à célébrer ; erreur, le pire des quatre, qui se confond avec les autres

Ce qui fonctionne pour le vide de départ

Le plus difficile des quatre mérite un traitement à part.

Montrer le résultat, pas la promesse. Un aperçu de ce à quoi la page ressemblera remplie, visuellement identifiable comme un exemple. L'utilisateur comprend en une seconde ce qu'il peut obtenir.

Réduire le premier pas à une action, pas à un formulaire. La plupart des produits demandent de créer un objet complet avant de montrer quoi que ce soit. L'inverse fonctionne mieux : produire quelque chose d'imparfait immédiatement, et laisser affiner ensuite.

Pré-remplir quand c'est possible. Si le produit peut déduire quoi que ce soit du contexte, il doit le faire. C'est d'ailleurs l'un des usages les plus rentables de l'IA dans un produit existant, et l'un des rares où une erreur coûte peu : l'utilisateur corrige un point de départ, il ne repart pas de zéro.

Ne jamais faire passer un exemple pour des données réelles. Si vous montrez un contenu de démonstration, dites-le. La découverte que les beaux chiffres affichés étaient faux détruit plus de confiance que la page vide n'en aurait coûté.

Le test à faire cette semaine

Créez un compte neuf sur votre propre produit, sans rien importer, et parcourez chaque section principale.

Notez pour chacune : est-ce que je comprends ce que je dois faire, et est-ce que je vois ce que ça donnera ?

La plupart des équipes qui font cet exercice découvrent entre cinq et dix écrans dont personne ne s'était occupé, et qui sont pourtant les premiers que voient tous leurs nouveaux utilisateurs.

Ce qu'il faut retenir

Votre produit a deux visages. Celui que l'équipe voit tous les jours, rempli, et celui que l'utilisateur découvre, vide.

Le second décide si le premier existera un jour pour lui.


Votre activation bloque sans que vous sachiez pourquoi ? Le premier endroit à regarder est rarement celui qu'on suspecte. Parlons-en.