J’avais les trois paradigmes d’interface à ma disposition quand j’ai commencé à construire ce produit, et j’ai choisi le plus ennuyeux. Cet article explique pourquoi, avec le vrai calcul d’interaction plutôt qu’un tableau de fonctionnalités — parce que ce choix « ennuyeux » était le résultat délibéré d’une véritable analyse d’arbitrages, pas un manque d’imagination.
Chaque outil de favoris sur le marché — sans exception — s’engage sur l’une de ces trois formes. Une barre qui se place au-dessus de la page. Une sidebar qui vit à côté d’elle. Un tableau de bord qui remplace la page de nouvel onglet et attend que vous veniez le consulter. Personne ne mélange ces approches ; la forme est une décision fondatrice qui détermine presque tout le reste de la sensation d’usage de l’outil. Ça vaut donc la peine de vraiment réfléchir à quelle forme convient à quel usage, plutôt que de la traiter comme un simple choix esthétique.
Les trois paradigmes
Barre (toujours visible, changement de contexte nul). C’est ce qu’est la barre de favoris native de Chrome, et c’est aussi ce que fait une seconde barre. Elle se place au-dessus de la page que vous regardez déjà, en permanence, en prenant une fine bande fixe d’espace vertical, que vous l’utilisiez à un instant donné ou non.
Sidebar (panneau persistant, remodèle la page). Un panneau vertical qui vit à côté de votre contenu — pensez à un gestionnaire de favoris épinglé ouvert à côté de votre navigation. Elle est toujours disponible, comme une barre, mais elle prend de l’espace horizontal plutôt que vertical, ce qui fait que la page en dessous devient plus étroite, pas plus courte.
Tableau de bord (une destination que l’on visite). Une page de démarrage ou une prise de contrôle du nouvel onglet affichant vos liens, dossiers ou sessions enregistrés. Contrairement aux deux autres, il n’est pas présent pendant que vous naviguez — vous y allez, vous l’utilisez, puis vous en repartez.
La plupart des comparatifs de cette catégorie sautent directement à un tableau de fonctionnalités — recherche, tags, dossiers, synchronisation, tout avec des coches — comme si la forme de l’outil était un contenant neutre et que les fonctionnalités racontaient toute l’histoire. Ce n’est pas le cas. La forme détermine quand l’outil vous gêne, quand il est invisible, et ce qu’il vous coûte sur les quatre-vingt-dix-neuf récupérations où vous ne pensez pas du tout à l’outil, juste à retrouver une page. C’est cette partie-là qui mérite vraiment d’être creusée.
Analyse du coût d’interaction
La façon honnête de comparer ces approches, ce n’est pas des listes de fonctionnalités, c’est ce que chacune vous coûte à trois moments différents : quand vous enregistrez quelque chose, quand vous récupérez quelque chose, et quand vous ne l’utilisez pas du tout.
Coût d’un enregistrement. Une barre et une sidebar sont toutes deux déjà à l’écran, donc enregistrer se fait par glisser-déposer ou par un clic, sans naviguer nulle part. Un tableau de bord vous oblige soit à ouvrir un nouvel onglet (en perdant celui en cours, à moins de le dupliquer), soit à utiliser un mécanisme d’enregistrement séparé qui écrit dans le stockage du tableau de bord en coulisses — une couche supplémentaire entre l’action et l’endroit où elle atterrit.
Coût d’une récupération. C’est là que les paradigmes divergent le plus fortement. Une barre : un coup d’œil, un clic, terminé — zéro navigation. Une sidebar : pareil, sauf qu’elle prend déjà de la largeur à l’écran, donc elle est peut-être déjà visible ou à un simple bascule près. Un tableau de bord : ouvrir un nouvel onglet, attendre qu’il se charge, trouver ce que vous cherchez, puis soit l’ouvrir là (en perdant le contexte de votre onglet actuel), soit recopier un lien. Chaque récupération sur un tableau de bord est un petit aller-retour.
Coût quand vous ne l’utilisez pas. C’est celui que les gens sous-estiment. Une barre coûte une bande fixe d’espace vertical, en permanence, que vous la regardiez ou non — mais ce coût est faible et prévisible, et il n’entre pas en conflit avec la mise en page de la page elle-même. Une sidebar coûte de l’espace horizontal réel en continu, ce qui, sur tout écran plus étroit qu’un grand moniteur de bureau, veut dire que le contenu réel de la page que vous lisez se retrouve sensiblement comprimé, et peut visuellement casser des mises en page responsives qui supposaient toute la largeur de la fenêtre. Un tableau de bord ne coûte rien quand vous ne l’utilisez pas — parce que vous n’y êtes tout simplement pas. C’est un véritable avantage pour lui, et c’est le seul endroit où les tableaux de bord gagnent structurellement.
Pourquoi Chrome lui-même a choisi une barre
Ce n’est pas un hasard. Une barre suit le grain de la façon dont l’interface du navigateur fonctionne déjà — la barre de favoris native de Chrome est une barre, la bande d’onglets est une barre, la barre d’adresse est une barre. Empiler une seconde barre sur ce motif est additif ; ça n’entre pas en conflit avec le langage visuel existant du navigateur comme le fait une sidebar, parce qu’une sidebar doit répondre à « quel côté, quelle largeur, et qu’arrive-t-il à la mise en page de la page quand je l’ouvre » — des questions qu’une barre n’a jamais à se poser.
Une sidebar honnête doit réserver une vraie largeur sur la page. Sur un grand moniteur de bureau, c’est une taxe mineure. Sur un ordinateur portable, surtout dans la fourchette la plus courante de 13 à 14 pouces, ou dans une fenêtre de navigateur maximisée sur un écran plus petit, une sidebar persistante qui mange un nombre fixe de pixels peut pousser les points de rupture responsives d’une application web dans un état à l’étroit que l’auteur du site n’a jamais testé — des boutons qui s’enroulent bizarrement, des colonnes qui s’effondrent trop tôt, des mises en page qui supposaient plus d’espace qu’elles n’en reçoivent.
J’ai vu ça se produire de mes propres yeux en testant des extensions de type sidebar sur le même ensemble d’applications web que j’utilise au quotidien : un tableau de gestion de projet qui réduit sa propre sidebar en mode icônes seules parce qu’il croit que la fenêtre a rétréci, une application de chat qui empile sa barre de composition d’une manière pour laquelle elle n’a jamais été conçue, un éditeur de documents qui bascule vers une barre d’outils au format mobile. Rien de tout ça n’est vraiment la faute de l’extension sidebar — elle réclame réellement la largeur qu’elle annonçait — mais c’est un coût réel et visible que le paradigme de la barre ne crée tout simplement pas, parce qu’une barre prend de la hauteur, que la page a généralement en réserve, et non de la largeur, que la logique de mise en page de la page elle-même surveille activement.
Là où chaque paradigme gagne honnêtement
Rien de tout ça ne rend les barres universellement justes — ça les rend justes pour un usage précis, et les deux autres justes pour d’autres usages :
- Les tableaux de bord gagnent pour les transferts de session et de projet. Si ce que vous organisez, c’est « voici l’état du projet X au vendredi » — un ensemble d’onglets soigné, destiné à être revisité comme un tout, ou transmis à un coéquipier — le modèle du tableau de bord fondé sur une destination convient. Vous ne récupérez pas un lien cinquante fois par jour ; vous ouvrez une collection une seule fois. Toby est l’outil le plus connu entièrement construit autour de ce schéma — voir le comparatif honnête sur Toby pour savoir où ce modèle vaut le coup et où il ne le vaut pas.
- Les sidebars gagnent pour le travail intensif en références sur un seul écran. Si vous croisez activement un document avec une douzaine d’onglets ouverts en continu, avoir la liste visible à côté de votre travail sans changer de contexte peut valoir la largeur que ça coûte — surtout sur un écran assez large où cette largeur n’est pas rare.
- Les barres gagnent pour la récupération à haute fréquence. Si votre habitude réelle consiste à revenir vers les trente mêmes endroits des dizaines de fois par jour — une file de support, un CRM, un site de documentation, un outil de design — le coût quasi nul de récupération d’une barre s’accumule favorablement. Cinquante récupérations par jour à coût quasi nul battent cinquante récupérations par jour payant chacune la taxe de largeur persistante d’une sidebar ou l’aller-retour d’un tableau de bord.
| Barre | Sidebar | Tableau de bord | |
|---|---|---|---|
| Coût d’enregistrement | Clic/glisser, sans navigation | Clic/glisser, sans navigation | Nouvel onglet ou parcours séparé |
| Coût de récupération | Quasi nul | Quasi nul | Naviguer puis revenir |
| Coût au repos | Faible, fixe, vertical | Continu, horizontal | Nul |
| Colle au grain visuel natif de Chrome | Oui | Pas nativement | Pas nativement |
| Usage idéal | Récupération à haute fréquence | Références intensives, grands écrans | Transfert de session/projet |
Comment Second Bookmark Bar implémente la barre
Compte tenu de ce raisonnement, la barre était un choix délibéré, pas une option par défaut. Second Bookmark Bar ajoute une seconde barre compacte au-dessus de la page grâce à un rendu iframe isolé avec une couche de superposition parente pour les menus et popups — et elle réserve soigneusement son propre espace sur les mises en page modernes de type app-shell, pour que des éléments comme le bouton d’envoi d’une appli de chat ou la barre d’outils inférieure d’un tableau de bord ne se retrouvent pas poussés hors écran en dessous. Ce détail — « réserver de l’espace plutôt que simplement flotter par-dessus » — compte plus qu’il n’y paraît ; une superposition naïve entrerait exactement en conflit avec le type de mises en page app-shell qu’une sidebar peine déjà à gérer.
Ce détail d’espace réservé résout un coût de rendu, cependant — pas un coût de récupération. Une barre statique a un coût résiduel que le calcul d’interaction ci-dessus ne capture pas : afficher le mauvais dossier pour le site sur lequel vous êtes réellement, ce qui transforme une récupération en un clic en un changement de dossier plus une récupération. Deux mécanismes font passer le coût de la barre sous ce chiffre « un clic » du tableau. Le Changement automatique (Auto-switch) fait basculer la barre vers le dossier que vous avez associé au site actuel — une étoile sur le sélecteur d’emplacement indique quand il s’est déclenché, et vous pouvez toujours le forcer à la main — de sorte que le bon dossier est souvent déjà affiché avant même que vous leviez les yeux. Et pour le cas où ça rate, « c’est quelque part par là », il y a un panneau de recherche intégré à la barre, avec des résultats étiquetés par dossier et par domaine, ouvert directement sur la page où vous vous trouvez déjà — au lieu de l’aller-retour vers le Gestionnaire de favoris qui est le coût du tableau de bord dans le tableau ci-dessus — payé exactement au moment où vous en avez le moins envie.
La limite honnête, et je préfère la dire clairement plutôt que vous la laisser découvrir : les extensions Chrome ne peuvent injecter aucune interface — barre, sidebar ou autre — sur les pages chrome:// ni sur le Chrome Web Store lui-même. C’est une restriction de la plateforme Chrome, pas une lacune propre à cette extension, et elle s’applique également à tous les outils de favoris de ce comparatif. Sur ces pages, vous revenez à la barre unique native de Chrome.
Si votre habitude en matière de favoris ressemble davantage à « les trente mêmes endroits, toute la journée, tous les jours », la barre gagne le calcul réel, pas juste l’impression. Si elle ressemble plutôt à « organiser un projet et le transmettre », un tableau de bord fait le bon travail pour une autre question. Ça vaut le coup de regarder où se situent Raindrop et les outils de bibliothèque similaires dans ce même cadre, et où les contrôles de sites exclus et de masquage rapide de la seconde barre complètent le modèle de la barre pour les moments où vous ne la voulez pas visible du tout. Et si vous voulez cette même honnêteté en clics et en navigation appliquée à chaque moyen natif que Chrome vous offre déjà pour atteindre un favori avant même d’envisager une seconde barre, voici ce décompte, chiffré.
Pour ce même argument transformé en tableau face à chaque outil précis, nommément — Raindrop, Toby, Chrome natif, et d’autres — voir les pages de comparaison côte à côte.