Le problème de la page de réglages
Les pages de réglages sont l'endroit où l'intégrité d'un produit va mourir. Cinq archétypes, six règles, des exemples réels de Linear, Notion, Vercel, et un audit à livrer tel quel.
La page de réglages est l'écran le plus honnête de votre produit. Elle montre, en un seul scroll, exactement quelles décisions l'équipe a refusé de prendre. Chaque toggle est une dispute fossilisée. Chaque onglet imbriqué est un « on verra plus tard » que personne n'a jamais vu.
La plupart des pages de réglages sont des décharges. Trois ans de toggles déversés par des ingénieurs incapables de dire non, des marketeurs qui avaient besoin d'un opt-out, et des PM qui ont traité « rendons-le configurable » comme un synonyme de « décidons ». Résultat : un écran que l'équipe a honte de montrer en démo et que l'utilisateur a peur de toucher.
Voici le plaidoyer pour traiter les réglages comme une surface produit à part entière. Cinq archétypes, six règles, des exemples réels de produits que vous utilisez déjà, et un audit à passer avant de livrer.
Les réglages sont l'écran qui expose l'équipe
Le sprawl de réglages est un indicateur avancé (leading) du dysfonctionnement organisationnel. Quand une équipe n'arrive pas à s'aligner sur une valeur par défaut, le toggle part en prod. Quand un client se plaint et que personne ne veut résister, le toggle part en prod. Quand le PM n'arrive pas à trancher entre deux parcours, les deux sortent derrière un réglage.
Six mois plus tard, personne ne se souvient pourquoi la moitié des toggles existent. Supprimer un réglage exige la même décision que l'équipe a évitée la première fois, alors ils s'accumulent. Regardez n'importe quel produit vieux de plus de trois ans : vous pouvez compter les décisions non prises dans l'arbre des réglages.
Les cinq archétypes des mauvaises pages de réglages
Les mauvaises pages de réglages ne sont pas aléatoires. Elles suivent cinq schémas, chacun étant le point d'arrivée d'une forme précise de paresse organisationnelle.
1. La Décharge
Accrétion chronologique. Les réglages apparaissent dans l'ordre où ils ont été ajoutés, jamais regroupés. Le tout dernier feature flag côtoie une préférence de notification de 2019, elle-même voisine d'un toggle bêta censé avoir fini sa carrière il y a deux ans. Cursor glisse vers ça. Chaque release ajoute trois toggles à l'onglet Général, qui est devenu un scroll de 40 lignes de décisions sans rapport. La Décharge est l'état par défaut de toute page de réglages que personne ne dessine activement.
2. Le Tableur
Des préférences par ordre alphabétique. L'équipe a renoncé à la hiérarchie et laissé l'OS faire le tri. Chaque toggle a le même poids, chaque ligne est identique. Les préférences de notification de Slack vivent ici. Son, badge, mobile, canal, mot-clé, ne pas déranger, planning, personnalisé : tout aplati en un mur sans le moindre récit sur ce qui compte.
3. L'Impasse
Des réglages qui ne changent rien de visible. L'utilisateur active « Mode compact » et l'écran reste identique. Il active « Fonctionnalités avancées » et rien n'apparaît. La refonte des Réglages Système d'Apple sur macOS a livré toute une génération de ceux-là : des réglages écrasés en silence par d'autres réglages, des réglages qui exigent un redémarrage que l'écran ne mentionne jamais. L'Impasse apprend aux utilisateurs que les réglages ne marchent pas, et ils cessent de faire confiance au reste du produit.
4. Le Labyrinthe
Dix niveaux d'onglets imbriqués. Des réglages enterrés sous une catégorie, une sous-catégorie, un volet « Avancé », une modale. L'utilisateur sait que le toggle existe, l'a déjà activé, et ne le retrouve toujours pas. Le vieux Jira a bâti une carrière là-dessus : projet, board, workflow, schéma, schéma de permissions, schéma de notifications, tous dans des arbres séparés.
5. Le Musée
Des réglages que personne n'a touchés depuis trois ans. Ils existent parce que les supprimer paraît risqué. Ils renvoient à des fonctionnalités abandonnées en 2023. Tout produit SaaS historique a son aile Musée, et le coût, c'est la promesse de l'équipe de maintenir des chemins de code qui auraient dû mourir deux refactorings plus tôt.
Les réglages sont une surface produit, pas un placard
La plupart des équipes voient les réglages comme l'endroit où l'on range ce qui reste du produit. Ce cadrage est le bug. Les réglages sont l'une des surfaces à plus fort levier du produit, et les meilleures équipes les conçoivent ainsi.
Les réglages expriment la vision du monde du produit sur l'utilisateur. Ils communiquent quatre choses à la fois. Combien l'équipe fait confiance à l'utilisateur. Combien de contrôle elle accepte de partager. Ce qu'elle pense être les bonnes valeurs par défaut. Et si elle respecte assez le temps de l'utilisateur pour concevoir pour les 5 % qui changent les défauts sans punir les 95 % qui ne le font pas.
Linear a conçu les réglages comme une seule surface de recherche, pilotée par command-K, presque sans onglets imbriqués. Le message implicite : l'utilisateur est compétent, la recherche est rapide, l'équipe a fait le travail de hiérarchie pour que l'utilisateur n'ait pas à le faire. Notion est parti dans la direction opposée et a gagné de la même façon. Les réglages vivent à côté de ce qu'ils affectent. Réglages de page sur la page. Réglages de base de données sur la base de données. Les réglages contextuels disparaissent dans le travail.
Vercel utilise une hiérarchie par périmètre : projet, équipe et compte, chacun clairement étiqueté, chacun limité à la ressource qu'il gouverne. Le Dashboard Stripe va vers l'action, où chaque écran dit « fais cette chose », pas « configure cette préférence ». Les réglages de dépôt de GitHub réussissent le cadrage avec une séparation nette entre propriété du dépôt, de l'organisation et du compte.
Les six règles qui décident de toute page de réglages
Ces règles se cumulent. Cinq sur six et la page se lit comme une surface produit. Trois, et elle glisse vers l'un des archétypes en moins d'un an.
Règle 1 : La recherche d'abord
La hiérarchie est un plan B, pas un principe. L'utilisateur connaît le nom du réglage avant de savoir sous quel onglet il se trouve. Le command-K de Linear traite les réglages comme un type de résultat de premier rang. Figma a ajouté la recherche de réglages et le temps pour trouver un toggle a chuté immédiatement. Si votre page de réglages n'a pas de barre de recherche, vous pariez que les utilisateurs mémoriseront votre architecture de l'information. Ils ne le feront pas.
Règle 2 : Placement contextuel plutôt que registre central
Les réglages vivent à côté de ce qu'ils affectent. Réglages de notification dans le panneau de notifications. Réglages de page sur la page. Une page de réglages centrale convient aux enjeux de niveau compte comme le profil, la facturation et les sessions, et à presque rien d'autre. Notion est l'étalon-or. Le panneau de droite de Figma fait le même travail pour les propriétés de calque, de frame et de composant.
Règle 3 : Des défauts sensés qui gagnent la confiance
Chaque valeur par défaut est une décision produit. Elle exprime ce que l'équipe croit être la bonne réponse pour 80 % des utilisateurs. Si le défaut est mauvais, le toggle est un pansement. Les défauts de notification de Slack supposent que vous voulez être joignable, pas silencieux. Le pari est bon pour l'utilisateur médian. La plupart des équipes conçoivent d'abord le toggle et laissent le défaut en découler. Cet ordre est faux.
Règle 4 : La divulgation progressive plutôt que le sprawl à plat
L'utilisateur devrait voir les cinq réglages qui comptent pour 90 % des gens. Les 50 autres se trouvent un clic plus loin, derrière une affordance « Avancé » claire. Les réglages de projet de Vercel réussissent ça. Le premier écran met en avant le domaine, les variables d'environnement et la protection des déploiements. Les overrides de build, les configs de fonctions et les rewrites vivent dans Avancé.
Règle 5 : Pas d'orphelins
Chaque réglage appartient à un groupe. Chaque groupe a un nom. Le test de l'orphelin : lisez n'importe quel libellé à voix haute, sans autre contexte. Si un designer de votre équipe ne peut pas dire ce que fait le toggle, c'est un orphelin. Les orphelins sont les graines du Musée.
Règle 6 : Chaque réglage doit gagner sa place
Un réglage est un contrat. L'équipe s'engage à le maintenir, le documenter, le tester et raisonner sur ses interactions avec tous les autres réglages, pour toujours. La plupart des réglages ne peuvent pas payer ce loyer. La disposition par défaut face à tout nouveau réglage devrait être « non ». Les bonnes équipes tuent plus de réglages qu'elles n'en livrent.
Les anti-patterns qui signalent un problème plus profond
Trois schémas tuent plus de pages de réglages que tout le reste réuni. Chacun est le symptôme d'un problème qui n'est pas l'écran, mais l'équipe derrière.
Les réglages comme substitut aux décisions produit. L'équipe n'arrivait pas à s'accorder entre opt-in et opt-out, alors c'est sorti en toggle. L'utilisateur hérite de la dispute non résolue. Si vous entendez « rendons-le configurable » au daily, vous regardez cet anti-pattern se former. Pour aller plus loin, lisez concevoir la friction à dessein.
Les réglages qui compensent un mauvais design. Un toggle « mode compact » parce que la densité par défaut est trop lâche. Un toggle « contraste élevé » parce que les couleurs de marque échouent à l'accessibilité. Un toggle « vue classique » parce que la refonte a été rejetée. Chacun est une vraie correction déguisée en option. La solution : concevoir correctement densité, contraste et vues dès le départ.
Les réglages que personne ne sait expliquer en une phrase. Si un designer ne peut pas décrire ce que fait le réglage, ce qui change quand on l'active et à qui il s'adresse, le réglage ne doit pas sortir. Faites ce test avant que tout nouveau toggle n'atterrisse dans le code.
L'audit de la page de réglages
Passez chaque page de réglages à travers ces sept questions. Moins de six oui francs et la page n'est pas terminée.
- L'utilisateur peut-il trouver n'importe quel réglage en moins de cinq secondes ? Sinon, il manque la recherche ou la hiérarchie est cassée.
- Chaque réglage a-t-il une description d'une phrase qu'un non-ingénieur comprend ? Si le libellé demande un ingénieur pour l'expliquer, il n'a pas sa place dans la surface produit.
- Activer le toggle produit-il un effet visible et immédiat ? Les changements d'état cachés tuent la confiance.
- Les réglages sont-ils regroupés par tâche utilisateur, pas par équipe feature ? Une page organisée selon l'équipe qui possède la fonctionnalité est un artefact interne qui fuit dans le produit. Groupez par objectif utilisateur.
- Les défauts sont-ils défendus par écrit quelque part ? L'équipe devrait pouvoir pointer un doc, une décision de hiérarchie visuelle ou un principe de marque. Si le défaut est « ce que l'ingénieur a mis pendant le sprint », la page n'est pas finie.
- Pourriez-vous retirer la moitié des réglages sans qu'un utilisateur le remarque ? Si oui, faites-le. Le Musée est plus lourd que l'équipe ne le pense.
- La page ressemble-t-elle au reste du produit, visuellement et dans son ressenti ? Lisez-la à côté de vos principes de design de landing page. Si la marque s'effondre, la page de réglages est hors marque.
Une équipe qui passe cet audit deux fois par an livre une surface de réglages devant laquelle les utilisateurs ne tressaillent pas. L'équipe qui le passe ne livre jamais le genre de page de réglages qui devient un outil de recrutement pour la concurrence.
Choisissez le principe, puis élaguez la page
Les réglages sont la vision du monde de l'équipe, figée dans des toggles. Les bonnes équipes traitent la page comme un flux de premier rang, avec le même savoir-faire qu'elles apportent à l'onboarding, au dashboard et au site marketing.
Le moyen le plus rapide de réparer une page de réglages n'est pas de la redessiner. C'est d'en supprimer la moitié. Retirez chaque réglage qui échoue au test de l'orphelin, au test de la phrase unique et au test du « mérite sa place ». Ce qui reste est la colonne vertébrale d'une vraie surface de réglages.
Le lien avec les états vides n'est pas accidentel. Les deux écrans révèlent ce que l'équipe croit quand rien d'autre à l'écran ne vient la distraire. La même discipline apparaît dans les principes de web design.
Questions fréquentes
Combien de réglages un produit devrait-il avoir ?
Le moins possible. Chaque réglage est un contrat que l'équipe maintient pour toujours. La disposition par défaut face à tout nouveau réglage devrait être « non ». Si l'équipe ne peut pas défendre le réglage en une phrase, nommer l'utilisateur qu'il sert et décrire ce qui change visiblement quand on l'active, le réglage ne doit pas sortir.
Où les réglages doivent-ils vivre dans le produit ?
À côté de ce qu'ils affectent, pas dans une aile centrale de réglages. Réglages de page sur la page. Réglages d'espace de travail sur l'espace de travail. Réglages de notification dans le panneau de notifications. Une page de réglages centrale convient aux enjeux de niveau compte comme la facturation, le profil et les sessions, et à presque rien d'autre.
Comment nettoyer une page de réglages avec des années de toggles accumulés ?
Faites l'audit, puis supprimez. Groupez chaque réglage par tâche utilisateur. Identifiez les orphelins, les impasses et les pièces de musée. Retirez les 30 % du bas dès le premier passage et surveillez les tickets de support. Si personne ne se plaint, retirez encore 20 %.
Concevez la page de réglages comme la page d'accueil
La page de réglages n'est pas un sous-sol. C'est une pièce où vivent vos power users, et sur laquelle vos nouveaux utilisateurs vous jugent. Traitez-la comme la page d'accueil, l'onboarding, le dashboard. Appliquez le même savoir-faire. Livrez-la avec la même conviction.
Si vous voulez une équipe qui conçoit la page de réglages comme le reste du produit au lieu de l'hériter du backlog, engagez Brainy. Nous concevons les réglages comme un flux de premier rang, avec la discipline qui garde la page petite et des toggles qui paient leur loyer.
Want a settings surface that reads like the product instead of the bug tracker? Brainy designs settings as a first-class flow, not a graveyard.
Get Started
