Objectif #

Un tableau de bord doit être :

• lisible ;
• simple à maintenir ;
• compréhensible rapidement par un autre concepteur ;
• cohérent entre les environnements et les projets.

Même sur un projet simple, appliquer quelques règles de base facilite fortement les évolutions et la maintenance.

1. Nommage des composants #

Principe général #

Le nom technique d’un composant doit :

• être explicite ;
• permettre d’identifier rapidement le type de composant ;
• rester homogène sur l’ensemble des tableaux de bord.

Format conseillé :

<Type>_<NomFonctionnel>

Exemples :

l_TitreGeneral
l_DateMAJ
ts_BonCommande
tc_CAParMois
g_Filtres
b_ExporterExcel

Préfixes conseillés #

L’objectif n’est pas d’avoir une liste exhaustive, mais une convention simple et partagée.

Bonnes pratiques de nommage #

À faire #

ts_CommandesEnCours
gr_EvolutionCA
l_TitreSynthese

À éviter #

tableau1
graph2
libelle_test
composant_nouveau

2. Limiter la surcharge visuelle #

Un tableau de bord trop chargé devient difficile à lire et plus complexe à maintenir.

Recommandations #

• éviter la multiplication excessive des composants ;
• privilégier plusieurs tableaux de bord simples plutôt qu’un seul très dense ;
• regrouper les informations par thème ;
• limiter le nombre de graphiques visibles simultanément ;
• utiliser des groupes et des espacements cohérents.

Approche conseillée #

Préférer : #

• un tableau de bord « Synthèse » ;
• puis plusieurs tableaux détaillés.

Exemple :

- Dashboard_Synthese
- Dashboard_Commandes
- Dashboard_Facturation
- Dashboard_Stocks

Plutôt qu’un unique tableau regroupant tous les sujets.

3. Gestion des catégories #

Les catégories permettent d’organiser les tableaux de bord et de distinguer les environnements.

Dans de nombreuses installations, un même serveur contient plusieurs environnements :

• DEV ;
• RECETTE ;
• PRE_PROD ;
• PROD.

Convention de nommage conseillée #

Environnements hors production #

[DEV] Ventes
[REC] Ventes
[PREPROD] Ventes

Production #

Éviter le préfixe :

Ventes

La catégorie étant visible par les utilisateurs finaux, il est préférable d’avoir un nom propre et lisible en production.

Recommandations complémentaires #

• conserver une structure identique entre environnements ;
• éviter les catégories trop nombreuses ;
• utiliser des noms courts et compréhensibles ;
• ne pas mélanger technique et fonctionnel.

4. Renseigner les propriétés du tableau de bord #

Les propriétés du tableau de bord sont souvent négligées alors qu’elles facilitent la maintenance.

Il est recommandé de renseigner :

• la description ;
• les notes ;
• les informations de suivi.

Informations utiles à conserver #

Exemple de contenu :

Date de livraison : 15/05/2026

Création :
- 02/05/2026 - Stéphane H. - Création du tableau

Modifications :
- 08/05/2026 - Ajout filtre société
- 12/05/2026 - Optimisation chargement graphique CA
- 14/05/2026 - Correction export Excel

Datasource principale :
- DS_Ventes_Synthese

Remarques :
- Utilise les droits agence
- Rafraîchissement quotidien

Avantages #

Cette documentation permet :

• d’identifier rapidement l’auteur ;
• de comprendre les dernières modifications ;
• de faciliter les reprises de projet ;
• d’améliorer la maintenance ;
• de simplifier les échanges entre équipes.

5. Homogénéité globale #

Sur un projet BiBOARD, la cohérence est plus importante que la complexité des règles.

Quelques conventions simples appliquées partout sont préférables à des règles très avancées mais peu respectées.

Recommandations finales #

• définir une convention de nommage dès le début du projet ;
• conserver les mêmes préfixes partout ;
• éviter les tableaux trop riches ;
• documenter les tableaux de bord ;
• organiser clairement les catégories ;
• privilégier la lisibilité pour les utilisateurs et les concepteurs.