Aller au contenu principal

Module 9 — Thème, apparence et ergonomie

Une application qui fonctionne mais n'a pas l'air d'appartenir à son entreprise reçoit toujours la même remarque : « c'est bien mais ce n'est pas pour nous ». Ce module traite les aspects visuels et ergonomiques qui font qu'une application est adoptée : thème aux couleurs de la marque, logo, ordre des actions, messages d'aide, et bascule vers une organisation multipages quand un seul écran ne suffit plus.

Le fichier de configuration du thème​

Streamlit lit ses paramètres dans un fichier .streamlit/config.toml à la racine du projet. Trois sections concernent l'apparence : [theme], [server] et [browser].

[theme]
primaryColor = "#0057A0"                # couleur des boutons principaux et curseurs
backgroundColor = "#FFFFFF"             # fond principal de la page
secondaryBackgroundColor = "#F1F5F9"    # fond des barres latérales et widgets
textColor = "#0F172A"                   # texte
font = "sans serif"                     # sans serif, serif, ou monospace

[server]
maxUploadSize = 100                     # cf. module 7

[browser]
gatherUsageStats = false                # désactive la télémétrie

Les quatre couleurs suffisent à donner à l'application l'identité visuelle d'une entreprise. Un bleu institutionnel en primaryColor colore les boutons de soumission, les curseurs et les cases cochées ; il n'est pas rare qu'une équipe marketing signe la mise en production dès qu'elle voit son bleu correct. La font reste limitée à trois familles standard, ce qui empêche les explorations typographiques hasardeuses ; c'est une contrainte utile.

Le thème sombre s'active automatiquement selon la préférence du navigateur si l'on définit une section [theme] complémentaire nommée theme.dark. Sur un tableau de bord destiné à un affichage mural la journée, on force le mode clair ; sur une application consultée par des développeurs, on laisse la bascule automatique.

Un logo et un pied de page​

Le logo se place dans la barre latérale, en haut, avec une image locale ou une URL. Streamlit 1.35 introduit st.logo qui simplifie l'appel :

import streamlit as st

st.logo(
    "assets/logo_operateur.png",
    icon_image="assets/favicon.png",   # version compacte pour barre repliée
    link="https://intranet.exemple.fr/scoring-resiliation",
)

Pour un pied de page discret — version de l'application, contact d'équipe, mention légale — on utilise un simple st.caption en bas de page ou dans la barre latérale :

with st.sidebar:
    st.divider()
    st.caption("Application v1.4 — équipe data.")
    st.caption("Contact : equipe-data@exemple.fr")

L'ordre des actions​

L'ergonomie d'une application se joue autant dans l'ordre des composants que dans leur choix. Trois règles simples couvrent la grande majorité des cas.

Du général au spécifique. Un tableau de bord commence par les filtres globaux dans la barre latérale, puis les indicateurs synthétiques en haut de page, puis le détail. L'utilisateur qui doit vérifier un seul chiffre s'arrête aux indicateurs sans jamais dérouler.

Une action principale par écran. Le bouton type="primary" doit être unique sur la page ou dans un formulaire ; deux boutons primaires forcent l'utilisateur à choisir sans hiérarchie visuelle. Les actions secondaires — annuler, aide, exporter — restent en couleur neutre.

Les messages près de leur cause. Une erreur qui apparaît en haut de page pour une saisie du bas trouble l'utilisateur ; on affiche st.error, st.warning et st.success immédiatement sous le composant concerné. La fonction st.toast est réservée aux notifications transitoires — « fichier téléchargé », « configuration sauvegardée » — qu'il ne faut pas laisser flotter.

Les messages d'aide contextuels​

Chaque composant accepte un argument help="..." qui affiche une bulle d'information au survol d'une petite icône. C'est le bon endroit pour expliquer la signification métier d'un champ, sans encombrer la page.

seuil = st.slider(
    "Seuil de risque",
    0.0, 1.0, 0.4, step=0.05,
    help=(
        "Probabilité à partir de laquelle un client est considéré comme à risque. "
        "Un seuil plus bas identifie plus de clients mais augmente les faux positifs. "
        "Réglage recommandé : entre 0,35 et 0,45 selon la campagne."
    ),
)

La règle est de dire ce que le composant signifie pour le métier, pas ce qu'il est techniquement. « Seuil de risque » n'a pas besoin d'expliquer ce qu'est un curseur ; il a besoin d'expliquer à quoi ce curseur correspond dans la décision commerciale.

Passer à une application multipages​

Un écran unique atteint sa limite au bout de trois ou quatre onglets. Streamlit gère nativement les applications à plusieurs pages avec un dossier pages/ à côté du script principal. Chaque fichier Python dans ce dossier devient une page, listée dans la barre latérale automatiquement.

app.py
pages/
  1_🏠_Vue_ensemble.py
  2_🔍_Scoring_individuel.py
  3_📦_Scoring_en_lot.py
  4_📈_Suivi_hebdomadaire.py
  5_⚙️_Paramètres.py
.streamlit/
  config.toml

Le préfixe numérique fixe l'ordre d'apparition et disparaît à l'affichage. L'émoji tient lieu d'icône. Chaque fichier est une application Streamlit complète et indépendante, avec son propre st.set_page_config. L'état de session st.session_state est en revanche partagé entre pages — c'est ce qui permet, par exemple, à un utilisateur qui a téléversé un fichier sur la page « Scoring en lot » de retrouver les résultats sur la page « Suivi ».

L'API récente st.navigation permet de définir dynamiquement les pages depuis un script principal, ce qui est utile pour cacher des pages selon le rôle de l'utilisateur :

import streamlit as st

pages = [
    st.Page("pages/1_vue_ensemble.py", title="Vue d'ensemble", icon="🏠"),
    st.Page("pages/2_scoring_individuel.py", title="Scoring individuel", icon="🔍"),
    st.Page("pages/3_scoring_lot.py", title="Scoring en lot", icon="📦"),
]
if st.session_state.get("role") == "admin":
    pages.append(st.Page("pages/5_parametres.py", title="Paramètres", icon="⚙️"),)

navigation = st.navigation(pages)
navigation.run()

Un dernier détail : l'accessibilité​

Une application interne a rarement besoin de conformité totale aux standards d'accessibilité, mais quelques gestes simples améliorent l'usage pour tous. Utiliser label_visibility="visible" sur les composants — plutôt que "collapsed" — pour que les lecteurs d'écran annoncent le libellé. Vérifier que le contraste entre textColor et backgroundColor reste supérieur à 4,5 pour 1, mesurable avec n'importe quel outil de contraste web. Ne pas coder l'information par la seule couleur : un st.error accompagne toujours un texte, jamais un simple rectangle rouge.

Le premier test d'utilisabilité

Avant de déployer, faites tester l'application à une personne du métier qui ne l'a jamais vue, sans lui montrer. Regardez ce qu'elle cherche des yeux, où elle hésite, ce qu'elle clique à côté. Chaque hésitation de plus de trois secondes signale un défaut de mise en page à corriger. Cet exercice coûte trente minutes et évite un mois d'incompréhensions à distance.

En résumé​

  • Le fichier .streamlit/config.toml fixe les quatre couleurs du thème et la police, ce qui suffit à donner à l'application l'identité visuelle de l'entreprise.
  • st.logo ajoute un logo cliquable dans la barre latérale ; un st.caption en pied de page suffit pour la version et le contact.
  • L'ordre naturel va du général au spécifique, avec une seule action principale par écran et des messages près de leur cause.
  • Les applications multipages s'obtiennent avec un dossier pages/ ou avec st.navigation ; l'état de session est partagé entre pages, ce qui rend la navigation naturelle.

Module suivant : le déploiement, sur Community Cloud ou en conteneur, avec un contrôle d'accès simple.