Comment améliorer le design de votre application Shiny ?

R Shiny est né avec une promesse très forte :

Aucune compétence en développement web n’est requise.

Et c’est vrai.

On peut faire des applications Shiny à très haute valeur ajoutée avec uniquement du code R.

Zéro HTML, CSS, ou JS.

Mais…

Sous cette promesse se cache une réalité qu’on ne peut ignorer bien longtemps :

Quand on développe en R Shiny, on fait du développement web.

Et malgré toutes les possibilités permises par Shiny, ça reste une goutte d’eau dans l’océan massif de l’écosystème du dev web.

Faire du Shiny pur va très bien marcher pour créer un prototype.

Mais dès qu’on veut passer à l’étape suivante, il faut aller plus loin :

• Mettre en place de bonnes pratiques de développement
• Ajouter un portail d’authentification
• Déployer l’appli sur un serveur
• …

Et ce dont je veux parler dans cet article : Créer une interface intuitive et esthétique

Chez Data Champ’, on a créé une petite application Shiny en interne.

Voici à quoi elle ressemble (cliquez pour agrandir) :

CommChamp’ : état d’origine

Cette application nous permet de suivre nos statistiques sur LinkedIn :

• Pour la page entreprise Data Champ’.
• Et les pages de deux personnes de notre équipe : Charles Bordet et Cécile Uzel.

Que pensez-vous du design de notre appli ?

C’est du bslib par défaut. Ça marche, mais on repassera pour un effet waouh.

J’ai posé les éléments sans réfléchir :

• Des fileInput qui s’enfilent
• Un tableau DT::dataTableOutput()
• Un selectInput
• Et un graphique ggplot2

C’est une appli qu’on utilise exclusivement pour nos besoins internes.

Donc on s’en fout de son apparence. Je l’ai codée en un weekend, ça marche, et je suis passé à autre chose.

Le problème, c’est que 90% des applications Shiny dans la nature ressemblent à ça. Y compris celles qui sont destinées à des vrais utilisateurs.

Et c’est normal. Quand on développe une appli Shiny, on se concentre sur ce qui compte : les données, la logique métier, les interactions, etc.

Le design, c’est accessoire. Et en plus… c’est souvent trop éloigné de notre métier.

Sauf que c’est pas si accessoire que ça en réalité. Le design, c’est pas juste “faire joli”.

D’abord, c’est un réel levier de crédibilité : Il joue sur la confiance et l’adoption des utilisateurs. Et ça, que votre appli soit un SaaS B2B, B2C, ou un outil interne, ça compte.

Même pour moi, à mon niveau, j’ai un intérêt à soigner l’interface de mes outils internes. J’ai déjà remarqué qu’avec certains outils :

• L’interface n’est pas claire et je dois ré-expliquer plusieurs fois comment ça marche.
• « C’est chiant à utiliser », du coup la personne évite ou repousse à plus tard.
• Inconsciemment, on doute de ce qu’on voit, parce que si c’est pas soigné, on imagine que le reste a aussi été codé n’importe comment.

C’est un vrai biais cognitif qui a été étudié en psychologie : Ça s’appelle le aesthetic-usability effect (ou en français : l’effet d’esthétique-ergonomie).

Les utilisateurs perçoivent une interface esthétique comme étant plus facile à utiliser, même si elle ne l’est pas objectivement.

Si je fais un raccourci, on peut dire qu’une appli bien designée est perçue comme plus fiable, plus rapide, et plus professionnelle.

Dans cet article, je ne vais pas refaire de fond en comble notre appli Comm Champ’. Mais je vais vous donner les bases pour le faire vous-même, et je m’en servirai comme fil rouge pour illustrer.

Si vous aussi :

• vous avez une appli Shiny qui fonctionne mais qui a le look d’un formulaire administratif
• vous voulez lui donner un aspect professionnel sans passer des semaines à tout refaire,
• vous voulez comprendre les bases du design appliquées à Shiny
• et vous voulez savoir quels outils utiliser et comment,

alors cet article est pour vous.

On va aborder ça en plusieurs étapes :

• 1. Le package de base n’a aucune importance : On démystifie le choix entre shinydashboard, bs4Dash, bslib, etc.
• 2. Les principes de design : Typographie, couleurs, espacement, hiérarchie visuelle. Les bases à savoir avant de coder.
• 3. C’est quoi Bootstrap : Grille, composants, variables, lien avec Shiny.
• 4. Le thème Bootstrap : Créer un thème sur mesure pour donner une vraie identité à votre application.

C’est parti.

1. Le package de base n’a aucune importance

Mon client Xavier se posait déjà la question en 2021 :

J’ai développé le prototype avec bscollapse (qui est simple, non maintenu, limité). Je me demande s’il ne faudrait pas passer l’ensemble dans shinydashboard/shinydashboardPlus, mais j’ai vu qu’il y a d’autres options (bs4dash, shiny.react).

C’est la question que tout le monde se pose au démarrage d’une nouvelle appli :

• Utiliser shiny de base : on sait que c’est dépassé et ça fait plus très moderne
• Un shinydashboard ? pourquoi pas mais ça fait un peu daté aussi
• Pourquoi pas bslib ? J’en entends parler de plus en plus
• Ah et puis j’avais vu passé shiny.fluent, shiny.react, etc…

En fait, ce n’est pas la bonne question à se poser.

Parce que le package de base, quelqu’il soit, ne changera pas fondamentalement l’apparence de votre application si vous n’y mettez pas du CSS derrière.

Voici Comm Champ’ avec quatre packages différents :

Avec le package shiny

Avec le package shinydashboard

Avec le package bs4Dash

État d’origine

Oui, il y a des différences de structure :

• shinydashboard vous donne une sidebar et un header par défaut
• bs4Dash vous met du Boostrap 4 avec un look un peu plus moderne
• bslib vous donne Bootstrap 5 avec un style plus épuré

Mais fondamentalement, aucun de ces packages ne vous rendra votre application belle et intuitive. Ils vous donnent une structure et un point de départ. C’est tout.

Ça sert à rien de passer des heures à comparer shinydashboard et bs4Dash.

Le problème de design que vous avez, c’est :

• Comprendre les bases du design (on y vient dans la prochaine section)
• Écrire du CSS (ou du SASS) adapté à votre application
• Être cohérent dans vos choix visuels

Cela étant dit. Il faut bien choisir un package. Et pour ma part, le choix est fait depuis longtemps :

Je recommande bslib.

Pourquoi ?

• C’est le package officiel de Posit pour la mise en page et le theming.
• Il utilise Bootstrap 5, la version la plus récente et la plus moderne.
• Il est activement maintenu et reçoit régulièrement de nouvelles fonctionnalités
• Il offre un système de création de thème nativement
• Il propose des composants de layout modernes : layout_columns(), layout_sidebar(), card(), value_box(), navset_bar()

shinydashboard, c’est fini. Le package utilise Bootstrap 3, il n’est plus maintenu, et il vous enferme dans un look qui date de 2015. Si vous avez une appli existante sous shinydashboard, il sera probablement pertinent de migrer vers bslib à l’occasion.

bs4Dash a eu son utilité à une époque où bslib n’existait pas encore. Aujourd’hui, bslib le remplace largement. Et il n’est quasiment plus maintenu.

shiny.fluent et shiny.react ne sont plus maintenus non plus.

2. Avant de coder : les principes de design

Avant de parler de code, de CSS, de SASS, je vais vous parler de design.

Parce que les meilleurs outils du monde ne serviront à rien si vous ne savez pas quoi en faire.

Rassurez-vous. On ne va pas refaire un cours de design graphique. Juste les principes fondamentaux qui, une fois compris, vont transformer la manière dont vous construisez vos interfaces.

La typographie

La typographie, c’est le choix des polices de caractères.

Et si vous pensez que ça ne change pas grand-chose… c’est normal. C’est exactement ce que je pensais aussi. On est développeurs, pas graphistes. Une police, c’est une police.

Sauf que la typographie, c’est l’élément d’interface que vos utilisateurs regardent en permanence. Tout est du texte : les titres, les labels, les boutons, les tableaux, les messages d’erreur. La police est partout.

Et ce qu’elle véhicule, c’est un ressenti inconscient. Imaginez la même phrase, avec strictement le même contenu, écrite d’abord en Comic Sans, puis dans une police sobre comme Inter.

Vous ne savez peut-être pas expliquer pourquoi, mais l’une vous inspire plus confiance que l’autre. C’est ça, la typographie : elle influence la perception de sérieux, de modernité, et de professionnalisme de votre application, sans que l’utilisateur s’en rende compte.

La police par défaut de Bootstrap est une police système (la police native de votre OS). Elle est parfaitement lisible, mais elle est… générique. Exactement la même que celle de votre éditeur de texte, de votre navigateur de fichiers, de n’importe quel logiciel système. Votre application ne s’en distingue pas.

Changer la police, c’est la première étape pour dire : « cette application a une identité ».

Voici les règles de base :

• Limitez-vous à deux polices maximum. Une pour les titres, une pour le texte courant. Au-delà, ça donne une impression de désordre.
• Privilégiez la lisibilité. Pour le texte courant, choisissez une police sans-serif sobre : Inter, Open Sans, Source Sans Pro. Gardez les polices plus “expressives” pour les titres, si vraiment vous y tenez.
• Hiérarchisez vos tailles. Utilisez des tailles différentes pour les titres, sous-titres, et texte courant.

Où trouver des polices ? Google Fonts est la référence. C’est gratuit, il y a des centaines de polices, et bslib les intègre nativement avec font_google().

CommChamp’ : Avant

CommChamp’ : Avec les polices Data Champ’

Je l’admets : prise isolément, la différence n’est pas flagrante sur cet avant/après. Et c’est normal, parce que la typographie ne fait pas le boulot toute seule. C’est quand elle se combine avec les couleurs, l’espacement, et la hiérarchie visuelle que l’ensemble prend vie.

Mais cette typo pose les fondations. Elle sera présente sur chaque pixel de texte de l’application, et elle contribuera à faire naître cette sensation de « c’est du Data Champ’ ».

Les couleurs

Autre sujet bien complexe pour les développeurs. Et aussi celui où ils font le plus d’erreurs.

Voyez cette magnifique palette de couleurs que j’ai utilisée pour une application Shiny en 2019 :

Une appli aux couleurs bien pétantes

Vous vous dites peut-être : « Bon, c’est un peu flashy, mais ça se voit bien, non ? »

Le problème, c’est que quand tout crie, rien ne parle. Le jaune pétant, le rouge vif, le vert fluo : chaque couleur se bat pour attirer l’attention. L’œil ne sait pas où se poser. Et au bout de 10 minutes à fixer cet écran, vous avez mal à la tête.

Les couleurs vives ne sont pas interdites. Mais elles doivent être utilisées avec parcimonie, pour attirer l’attention sur quelque chose de précis : un bouton d’action, une alerte, un indicateur clé. Si tout est coloré, plus rien ne ressort.

Pour faire un parallèle simple : imaginez quelqu’un qui parle en criant tout le temps. Au bout de deux minutes, vous ne l’écoutez plus. C’est exactement ce que fait une palette trop saturée.

Voici les trois règles d’or :

Règle n°1 : Partez d’une couleur principale.

C’est la couleur de votre marque, ou la couleur dominante de votre application. Tout le reste en découle. Chez Data Champ’, c’est le bleu #023364.

Règle n°2 : Limitez votre palette.

Vous avez besoin de :

• 1 couleur principale (primary) : Pour les boutons d’action, les éléments interactifs, les mises en avant.
• 1 couleur de fond (background) : En général blanc ou très clair.
• 1 couleur de texte (foreground) : En général noir ou gris très foncé.
• 1 couleur de succès, 1 d’avertissement, 1 d’erreur : Les sémantiques classiques. Vert, orange, rouge.
• 1-2 couleurs secondaires, si votre application a besoin de distinguer des catégories.

C’est tout. Pas besoin de 15 couleurs.

Règle n°3 : Utilisez des outils.

N’inventez pas votre palette à la main. Utilisez :

• Coolors : Génère des palettes harmonieuses à partir d’une couleur de départ.
• Realtime Colors : Permet de visualiser instantanément votre palette sur un prototype de site web.

Avec ces outils, vous pouvez générer plusieurs palettes à partir d’une même couleur de départ et comparer leur effet immédiatement. Même application, mêmes composants, mêmes données : changez la palette, et chaque version raconte une histoire différente. C’est ça, le pouvoir des couleurs.

J’ai ajouté ma couleur principale en background de la barre de navigation sur Comm Champ’. Ce simple changement permet immédiatement d’apporter une petite touche Data Champ’ sur l’appli :

Ajout d’une couleur de fond sur la barre de navigation

L’espacement

C’est LE truc que j’ai appris le plus tardivement. Je le voyais déjà partout avant, mais je ne comprenais pas d’où venait cette sensation.

L’espacement, c’est la quantité d’espace entre les éléments de votre interface. On distingue :

• Le padding (l’espace à l’intérieur d’un élément)
• Le margin (l’espace autour d’un élément)

Dans une application Shiny, les espacements sont corrects parfois.

Mais même avec une application aussi simple que Comm Champ’, on remarque très vite les incohérences :

• Le titre « Comm Champ’ » et les onglets sont collés tout en haut. Zéro respiration.
• Les boutons « Update » sont plus proches du tableau que du fileInput qu’ils accompagnent. L’œil associe naturellement les éléments qui sont proches. Ici, le bouton semble appartenir au tableau plutôt qu’au champ de téléchargement. C’est un principe de design qui s’appelle la loi de proximité.
• La pagination du tableau est perdue dans le vide, éloignée du contenu qu’elle contrôle.

Tous ces problèmes viennent d’un manque d’espacement réfléchi. Les espacements vont donner une interface plus lisible, plus aérée, et plus professionnelle.

Les principes :

• Augmentez les marges entre les sections. Les blocs de l’application doivent avoir de l’espace entre eux.
• Augmentez le padding dans les composants. Les cartes, les tableaux, les boutons, tout doit avoir un peu d’air.
• Soyez consistant. Utilisez un système de multiples. Par exemple : 8px, 16px, 24px, 32px, 48px. Pas du 7px ici et du 13px à côté.

Bonne nouvelle : des classes utilitaires Bootstrap permettent de gérer l’espacement facilement, sans écrire de CSS à la main. C’est un sujet que je détaillerai dans un prochain article.

La hiérarchie visuelle

Quand un utilisateur ouvre votre application, son regard doit être guidé. Il doit comprendre en un coup d’œil :

• Qu’est-ce qui est important ?
• Qu’est-ce qui est secondaire ?
• Où est-ce que je dois cliquer ?

La hiérarchie visuelle, c’est l’art d’organiser les éléments pour répondre à ces questions sans que l’utilisateur le perçoive consciemment.

Pour ça, on utilise :

• La taille : Plus c’est gros, plus c’est important. Typiquement, le KPI principal d’un dashboard doit sauter aux yeux.
• Le contraste : Un bouton d’action doit se démarquer du reste de l’interface. Utilisez votre couleur principale pour les actions importantes, et des couleurs neutres pour le reste.
• La position : Ce qui est en haut et à gauche est vu en premier. C’est là qu’il faut mettre les informations clés.

Prenons un exemple concret. Regardez Comm Champ’ dans son état actuel : qu’est-ce qui saute aux yeux en premier ? Difficile à dire. Le titre, les onglets, les fileInput, le tableau, tout est au même niveau visuel. Rien n’est mis en avant, rien n’est secondaire.

Maintenant, imaginez la même page avec ces ajustements :

• Le KPI principal (nombre de contacts) est affiché en grand, en haut de la page, dans une value box colorée.
• Le bouton d’action principal (« Update ») est le seul élément en couleur vive.
• Les éléments secondaires (les fileInput) sont relégués dans la sidebar, visuellement en retrait.

Sans changer une seule ligne de logique métier, l’application guide l’utilisateur.

La cohérence

Dernier principe, et peut-être le plus important : la cohérence.

Vos boutons doivent se ressembler. Les tableaux doivent avoir le même style. Les titres la même taille. Si vous utilisez des coins arrondis (un border-radius), utilisez le même rayon partout.

Ça paraît évident, mais en pratique, c’est le problème le plus fréquent. Voici un exemple typique de ce que je vois :

• Un bouton avec des coins arrondis à 8px… et un autre à 0px sur la même page.
• Un titre en bleu foncé dans un onglet, et en noir dans un autre.
• Un tableau avec des bordures dans la section A, et sans bordures dans la section B.
• Un selectInput avec une ombre portée, à côté d’un textInput sans ombre.

Chaque choix isolé est peut-être acceptable. Mais l’accumulation crée un patchwork visuel qui casse toute impression de professionnalisme.

C’est comme si vous portiez une chemise à carreaux, un pantalon à rayures, et des chaussettes à pois. Chaque vêtement est correct individuellement. L’ensemble est un désastre.

Le meilleur moyen d’assurer la cohérence, c’est de définir un thème.

C’est exactement ce qu’on va voir dans les prochaines sections sur Bootstrap.

3. C’est quoi Bootstrap

Jusqu’ici, on a décidé d’utiliser bslib, et on a dit que ce package reposait sur Bootstrap.

Il est temps d’explorer en détail ce qu’est Bootstrap, ce qu’il nous apporte, et comment l’exploiter.

Bootstrap est un framework CSS créé par Twitter en 2011. C’est tout simplement le framework CSS le plus utilisé au monde en 2026 d’après W3Techs, suivi de près par TailwindCSS selon les sources.

Et c’est quoi un framework CSS exactement ? Il faut voir ça comme une boîte à outils complète pour construire des interfaces web. Pour bien comprendre Bootstrap, il faut décomposer ce qu’il fournit. On va détailler chaque aspect, parce qu’on en aura besoin dans la suite de l’article.

1. Un système de grille et des composants

Si vous faites du Shiny, vous connaissez déjà les fluidRow() et column(). Vous savez qu’une ligne fait 12 colonnes, et que vous pouvez combiner column(width = 4, ...) et column(width = 8, ...) pour créer un layout en 1/3 - 2/3.

Eh bien tout ça, c’est Bootstrap.

Shiny n’a rien inventé sur ce point. fluidRow() génère une <div class="row"> et column(4, ...) génère une <div class="col-sm-4">. Ce sont des classes Bootstrap standard.

De la même manière, les composants que vous utilisez en Shiny sont des composants Bootstrap :

• Les tabsetPanel() ? Ce sont les Navs & tabs de Bootstrap.
• Les modalDialog() ? Ce sont les Modals de Bootstrap.
• Les actionButton() ? Ce sont des <button class="btn btn-default"> : les Buttons de Bootstrap.
• Les card() de bslib ? Ce sont les Cards de Bootstrap.

Rien de magique. Shiny est un habillage R de composants Bootstrap. C’est rassurant, parce que ça signifie que toute la documentation Bootstrap s’applique directement à votre application Shiny.

2. Un système de variables pour personnaliser le thème

Ça, c’est la partie qui va nous intéresser le plus dans cette section.

Bootstrap définit des centaines de variables SASS qui contrôlent l’apparence de chaque composant. Chaque couleur, chaque taille de police, chaque espacement, chaque rayon de bordure est paramétrable via une variable.

Quelques exemples :

• $primary: #0d6efd : la couleur principale de votre application
• $font-family-base: system-ui : la police de base
• $border-radius: 0.375rem : l’arrondi des coins de tous les composants
• $spacer: 1rem : l’espacement de base, dont tous les autres sont dérivés
• $table-striped-bg: rgba(0,0,0,.05) : la couleur des lignes alternées de vos tableaux

Et il y en a des centaines d’autres. Pour vous donner une idée de l’ampleur, voici le fichier source complet : Github - bootstrap/scss/_variables.scss

Ce qui est puissant, c’est que beaucoup de variables sont dérivées d’autres variables. Si vous changez $primary, ça impacte automatiquement les boutons, les liens, les badges, les bordures actives, etc. Si vous changez $spacer, tous les espacements de l’application changent proportionnellement.

C’est ce mécanisme qui permet de créer un thème cohérent en ne modifiant qu’une dizaine de variables.

3. Des classes utilitaires (aperçu)

Dernier pilier de Bootstrap : les classes utilitaires. Ce sont des classes CSS prêtes à l’emploi qui permettent d’ajuster rapidement un élément individuel, sans écrire de CSS.

Par exemple : text-center pour centrer un texte, p-3 pour ajouter du padding, bg-primary pour appliquer la couleur principale en arrière-plan.

C’est un sujet assez riche que je détaillerai dans un prochain article. Pour l’instant, retenez que ça existe et que c’est très pratique.

Bootstrap et Shiny : le lien

Maintenant que vous savez ce qu’est Bootstrap, voyons comment il s’intègre concrètement dans Shiny.

Quand vous créez une application Shiny, même la plus simple, Bootstrap est automatiquement chargé dans la page. C’est ce qui permet à Shiny d’avoir un design agréable sans que vous n’ayez à taper une seule ligne de CSS.

Concrètement, quand vous utilisez fluidPage() (ou bslib::page_fluid(), bslib::page_navbar(), etc.), Shiny génère une page HTML qui inclut un fichier CSS Bootstrap et un fichier JavaScript Bootstrap.

Pour vous en convaincre, comparez une appli avec bslib::page_navbar() et la même avec un simple div() sans Bootstrap : la différence est spectaculaire. Toute la mise en page, les composants, les styles de base, tout ça vient de Bootstrap.

Petite subtilité : le package shiny de base charge Bootstrap 3, tandis que bslib charge Bootstrap 5, la version la plus récente. C’est pour ça qu’une appli construite avec bslib paraît tout de suite un peu plus moderne.

4. Le thème Bootstrap

C’est quoi un thème Bootstrap ?

On a vu que Bootstrap propose des centaines de variables pour contrôler le look de chaque composant. Un thème Bootstrap, c’est tout simplement un ensemble de valeurs assignées à ces variables.

Vous pouvez consulter la liste complète des variables sur le site de bslib : bslib - Bootstrap 5 variables.

Évidemment, il n’est pas nécessaire de renseigner toutes les variables. La plupart ont des valeurs par défaut très raisonnables. Mais le nombre élevé de variables disponibles permet de créer un thème avec beaucoup de finesse, sans écrire une seule ligne de CSS.

Malgré tout, on verra rapidement que ça ne suffit pas toujours et qu’il faudra souvent mettre la main à la pâte.

Exemple : créer un thème pour Comm Champ’

Voici ce que j’obtiens avec une bonne dizaine de variables :

CommChamp’ avec son thème Bootstrap

Et voici le thème que j’ai créé :

// -- Colors -------------------------------------------------------------------

$primary: #023364;
$body-bg: #F6F6F6;

// -- Typography ---------------------------------------------------------------

$font-family-base: sans-serif;
$headings-font-family: sans-serif;
$headings-color: #0466D3;
$headings-font-weight: 700;

// -- Navbar -------------------------------------------------------------------

$navbar-dark-color: #FFFFFF;
$navbar-dark-hover-color: #80ED99;
$navbar-dark-active-color: #80ED99;
$navbar-dark-brand-color: #FFFFFF;
$navbar-dark-brand-hover-color: #FFFFFF;
$navbar-brand-font-size: 1.75rem;

// -- Table --------------------------------------------------------------------

$table-striped-bg: white;

// -- Form controls ------------------------------------------------------------

$input-border-color: #DEE2E6;
$input-placeholder-color: #ADB5BD;
$input-border-radius: 0;
$border-radius: 0;

On retrouve la même identité que le blog que vous lisez actuellement :

• Le bleu profond apparaît dans la navbar et le sélecteur de page du tableau
• Le vert flashy apparaît dans les onglets de la navbar
• Le bleu plus clair est appliqué sur les titres
• L’appli utilise un fond gris clair comme sur le blog
• Les boutons sont sharp avec leurs coins acérés

Même si c’est loin d’être parfait, c’est déjà un bon début.

Et pour obtenir ce résultat, j’ai seulement configuré 17 variables.

Pour montrer la puissance de ce système, on pourrait appliquer des thèmes radicalement différents sur la même application : un look sombre façon Spotify, un look violet épuré façon Stripe, etc. Même application, mêmes composants, mêmes données, mais une identité radicalement différente, en ne modifiant à chaque fois qu’une dizaine de variables.

« Et Bootswatch alors ? »

Si vous avez déjà cherché à personnaliser une appli Shiny, vous connaissez peut-être Bootswatch. C’est un ensemble de thèmes Bootstrap pré-faits. Ça existait déjà en 2015 quand j’ai codé ma première appli.

C’est super tentant : un paramètre à changer dans bslib::bs_theme(bootswatch = "darkly") et magiquement l’application change de look.

Sauf que ça ne suit aucun des principes de design qu’on a expliqués plus tôt :

• L’appli n’a toujours pas d’âme. Elle est passée d’un template générique à un autre template générique.
• Les soucis d’espacement et de hiérarchie visuelle n’ont pas bougé.
• L’appli ressemble toujours à toutes les autres qui utilisent le même template. Aucune identité ne ressort.

C’est sympa pour testouiller, mais si vous souhaitez avoir une application professionnelle qui dégage une vraie identité de marque, il va falloir pousser un peu plus loin, exactement comme on vient de le faire.

Comment intégrer ce thème Bootstrap en Shiny ?

Vous avez plusieurs possibilités pour intégrer ce thème dans votre appli :

1. Utiliser le fichier _brand.yml et ajouter toutes les variables.
2. Utiliser la méthode native Bootstrap.

Personnellement, je ne suis pas fan du _brand.yml.

Si vous ne connaissez pas, vous pouvez le découvrir sur le site de sa documentation.

Ce qui me gène profondement avec cet outil, c’est que :

• On vous promet d’encoder toute l’identité visuelle de votre entreprise dans un simple fichier YAML.
• La documentation couvre seulement comment changer les couleurs et la typographie.
• Pour le reste, c’est « Vous pouvez mettre des variables Bootstrap aussi. Bye! »

Au final : Débrouillez-vous.

Mais surtout : Ce fichier n’apporte rien de plus que vous ne pouvez déjà faire nativement avec Bootstrap. Pour moi, c’est une simplification à l’extrême qui vous cache la puissance de Bootstrap.

C’est pourquoi je vous propose la deuxième méthode qui est équivalente et s’intègre très bien avec bslib.

Voici comment créer le thème avec bslib :

theme <- bslib::bs_theme() |>
    bslib::bs_bundle(sass::sass_layer(
        defaults = sass::sass_file("www/sass/defaults.scss")
    ))

Ensuite, vous pouvez passer cet objet theme dans la fonction de base que vous appelez. Pour mon appli :

bslib::page_navbar(
    title = "Comm Champ’",
    theme = theme,
    ...
)

Finalement, vous l’aurez compris, la liste des variables que je vous ai présentée plus haut se place dans le fichier www/sass/defaults.scss.

Comment trouver les variables qu’il vous faut ?

À présent que je vous ai montré un exemple, vous avez sans doute envie de créer un thème pour votre application à vous.

Mais par où commencer ? On l’a dit, il y a des centaines de variables ! On ne va pas s’amuser à toutes les tester une par une.

Pour savoir quelles variables pourraient être intéressantes à configurer, je suis ce processus :

1. J’identifie un élément de mon interface que je souhaite personnaliser. Par exemple, la barre de navigation.
2. Je trouve la page correspondante dans la documentation de Bootstrap. Dans ce cas : Navbar
3. Je scrolle jusqu’à la section Sass variables (généralement en fin de page)

Et là, je trouve toutes les variables paramétrables pour la barre de navigation :

Ensuite, à vous de jouer !

Les premières fois, vous serez sans doute un peu perdu dans la navigation. Voici quelques astuces pour vous aider :

• Tout ce qui est lié à la taille du texte est dans Typography ou Utilities/Text
• Tout ce qui est lié aux couleurs est dans Utilities/Colors
• Beaucoup de widgets Shiny sont en fait des composants Bootstrap. Par exemple, les Cards

Plus vous l’utiliserez, plus vous serez familier avec l’arborescence, et plus vous commencerez à connaître les variables utilisées les plus fréquemment.

Quand les variables ne marchent pas

En configurant le thème de Comm Champ’, j’ai voulu changer la taille du texte dans les onglets de navigation. J’ai cherché dans la documentation Bootstrap, j’ai trouvé la variable $nav-link-font-size, et je l’ai ajoutée à mon thème :

$nav-link-font-size: 1rem;

Et… rien ne s’est passé.

J’ai vidé le cache. Relancé l’appli. Vérifié le nom de la variable. Tout est correct. Mais la taille du texte ne bouge pas d’un pixel.

En inspectant l’élément avec les DevTools du navigateur (CTRL + Shift + I, puis clic sur l’onglet), j’ai fini par comprendre :

Le package bslib ajoute ses propres règles CSS par-dessus Bootstrap. Et certaines de ces règles écrasent des variables qu’on s’attendrait à pouvoir configurer avec un thème.

Voici l’extrait du code source de bslib qui cause le problème :

.nav-underline {
    --bs-nav-link-font-size: 0.875rem;
    // ...
}

bslib définit --bs-nav-link-font-size directement en CSS, ce qui est plus spécifique que la variable SASS $nav-link-font-size qu’on a définie dans notre thème. Résultat : notre variable est ignorée.

Et ce n’est pas un cas isolé. Le même fichier contient d’autres surcharges :

• Les boutons par défaut (actionButton()) sont transformés en variante outline via une règle CSS, quelles que soient vos variables de thème.
• Les modales ont un padding fixé à 1.5rem.
• Les cartes ont des règles d’ombre portée spécifiques.

Le problème, c’est que ce comportement n’est documenté nulle part par bslib. Vous ne le découvrirez qu’en vous cognant dessus, en inspectant les DevTools, et en fouillant le code source sur GitHub.

Le fix : pour contourner, il faut écrire du CSS qui cible directement la même classe. Dans mon cas :

.nav-underline {
    --bs-nav-link-font-size: 1rem;
}

C’est frustrant, parce qu’on se bat contre le framework qu’on a choisi. Mais une fois qu’on sait que ça existe, on sait où chercher. Et c’est précisément pour ça qu’un thème Bootstrap, même bien configuré, ne suffira jamais à 100%. Il faudra toujours compléter avec du CSS personnalisé.

Et après ?

On a fait un sacré bout de chemin. Récapitulons.

Notre application a maintenant une vraie identité, fidèle à la charte Data Champ’ (cliquez pour l’ouvrir en grand) :

CommChamp’ avec son thème Bootstrap

On est partis d’un constat simple : faire du Shiny, c’est faire du développement web, et le design n’est pas accessoire. Puis on a vu que :

• Le package de base (shinydashboard, bs4Dash, bslib…) n’a quasiment aucune importance. Ce qui compte, c’est le CSS derrière.
• Les principes de design (typographie, couleurs, espacement, hiérarchie, cohérence) sont à connaître avant de coder.
• Bootstrap est le socle, et bslib permet de l’exploiter pleinement.
• Un thème Bootstrap permet de poser une identité visuelle cohérente en ne modifiant qu’une dizaine de variables.

Un thème, c’est environ 80% du chemin. Mais il reste les 20% qui font toute la différence. Regardez bien notre appli, il y a encore à redire :

• Le titre et le menu sont un peu serrés
• Il y a une drôle de bordure tout autour du corps de la page
• Le tableau manque de substance et se fond avec l’arrière-plan
• Le bouton « Update » est quasi invisible
• Les fileInput sont ratatinés par la faible largeur de la sidebar

Ces finitions (classes utilitaires, CSS/SASS personnalisé, harmonisation des graphiques, icônes, dark mode, etc.) feront l’objet d’un prochain article. En attendant, vous avez déjà de quoi transformer radicalement l’allure de votre application.

Et si vous avez une application Shiny à faire passer du prototype au produit et que vous voulez en discuter, écrivez-moi.