Comment créer un tableau de bord : sources de données, KPI, graphiques et droits d'accès

Pour construire un tableau de bord, partez des questions qu'il doit traiter et des personnes qui le liront, définissez précisément un petit nombre d'indicateurs, connectez les données dont ces indicateurs sont issus, et choisissez un graphique simple pour chacun. Décidez ensuite qui peut voir quels chiffres. Un générateur d'applications par IA peut produire un tableau de bord soigné en quelques minutes ; le plus difficile, et ce qui détermine si l'on lui fait confiance, c'est d'obtenir les bonnes données et les bonnes définitions.

Commencer par les questions, pas par les graphiques

Un tableau de bord qui tente de tout montrer ne sera ouvert qu'une fois. Avant de penser aux graphiques, répondez à ces questions :

• À qui est-il destiné ? Au fondateur, à l'équipe commerciale, aux opérations, aux investisseurs, à vos clients ?
• Quelles décisions soutient-il ? « Faut-il embaucher une autre personne au support ? » est une question à laquelle un tableau de bord peut répondre. « Montre-moi nos données » ne l'est pas.
• À quelle fréquence sera-t-il consulté ? Un tableau opérationnel quotidien a besoin de données fraîches et d'alertes ; une vue mensuelle pour un conseil d'administration n'en a pas besoin.

Rédigez trois à cinq questions. Chacune donnera un ou deux indicateurs.

Définir chaque indicateur avec précision

La plupart des débats autour d'un tableau de bord sont en réalité des débats sur les définitions. Rédigez une courte définition pour chaque chiffre :

Intégrez ces définitions dans votre consigne. Sinon, une IA choisira un calcul qui paraît raisonnable mais qui ne correspond peut-être pas à la façon dont votre entreprise compte.

D'où viennent les données

Deux principes s'appliquent partout :

1. Gardez les clés côté serveur. Les clés d'API et les mots de passe de base de données doivent figurer dans les variables d'environnement de l'application, jamais dans le code du navigateur.
2. Décidez de la fraîcheur des données. Interroger plusieurs API à chaque chargement de page est lent et peut atteindre les limites de requêtes. Pour la plupart des tableaux de bord métier, une synchronisation toutes les heures ou pendant la nuit dans votre propre base de données, avec une indication « dernière mise à jour » sur la page, est plus simple et plus fiable.

Si les API vous sont nouvelles, qu'est-ce qu'une API et qu'est-ce qu'une base de données expliquent les bases.

Choisir le bon graphique

• Un chiffre unique avec son évolution (« 42 000 €, en hausse de 8 % par rapport au mois dernier ») : une carte KPI. C'est l'élément le plus utile de la plupart des tableaux de bord.
• Une tendance dans le temps : un graphique en courbes. Utilisez les barres seulement pour un petit nombre de périodes.
• Comparer des catégories : un graphique à barres horizontales, trié par valeur.
• Une part d'un tout : des barres empilées. Les camemberts ne fonctionnent qu'avec deux ou trois parts.
• Le détail et les exceptions : un tableau avec tri, recherche et filtres. Il est souvent plus utile que n'importe quel graphique.

Gardez des couleurs cohérentes : une couleur pour « cette période », une couleur atténuée pour « la comparaison », et le rouge uniquement pour ce qui demande une attention.

Qui voit quoi

Décidez des accès avant de construire :

• En interne, tout le monde voit tout : le plus simple. Une connexion reste nécessaire si le tableau contient des données de l'entreprise.
• Par rôle : les commerciaux voient les chiffres de vente, la finance voit les marges, les managers voient leur propre équipe.
• Destiné aux clients : chaque client ne voit que ses propres données. Chaque requête doit filtrer par le compte du client, côté serveur. Testez en vous connectant avec deux clients différents.

Un tableau de bord contenant des données de chiffre d'affaires ou de clients, accessible sur une URL publique sans connexion, est une fuite de données qui n'attend que d'être découverte.

Une première consigne qui fonctionne

Construis un tableau de bord commercial pour une entreprise de logiciels B2B de 10 personnes. Public : les fondateurs et le responsable commercial, qui le consultent chaque lundi. Vue d'ensemble : des cartes KPI pour le nouveau MRR de ce mois, le MRR total, les nouveaux clients de ce mois, les clients perdus ce mois et la valeur du pipeline, chacune avec son évolution par rapport au mois précédent ; un graphique en courbes du MRR sur les 12 derniers mois ; un graphique à barres des nouvelles affaires par source. Une page Affaires avec un tableau consultable et triable (entreprise, responsable, valeur, étape, date de clôture) et des filtres par responsable et par étape. Définitions : le MRR est la somme des montants d'abonnements mensuels actifs, les forfaits annuels divisés par 12 ; le taux de résiliation compte les clients dont l'abonnement s'est terminé ce mois-ci. Utilise des données d'exemple réalistes dans une base de données pour l'instant ; nous connecterons Stripe plus tard. Affiche une heure de « dernière mise à jour ». Connexion obligatoire. Mise en page claire avec barre latérale.

Étapes de construction

1. Mise en page avec des données d'exemple. Mettez-vous d'accord sur les indicateurs et les graphiques pendant que les données sont fictives et faciles à modifier.
2. Connecter une vraie source. Vérifiez chaque chiffre à la main dans le système source. Si le MRR diffère de ce qu'affiche Stripe, trouvez pourquoi avant d'aller plus loin.
3. Ajouter les autres sources, une à une, en vérifiant chacune.
4. Actualisation planifiée ou requêtes au chargement, avec une étiquette « dernière mise à jour ».
5. Filtres : d'abord la plage de dates, puis un ou deux autres demandés par les utilisateurs.
6. Connexion et rôles.
7. États vides et erreurs : ce que la page affiche lorsqu'une source est indisponible ou qu'un filtre ne renvoie rien.
8. Partager avec le public visé, puis retirer tout ce que personne ne consulte au bout d'un mois.

Le rendre rapide

Un tableau de bord lent est moins consulté. Précalculez les totaux coûteux (une table de synthèse quotidienne au lieu de parcourir chaque commande), paginez les grands tableaux, et chargez d'abord les cartes principales pour que la page soit utile avant la fin du chargement des graphiques. Si un chiffre prend beaucoup de temps à calculer, affichez quand il a été calculé pour la dernière fois, plutôt que de le recalculer à chaque visite.

Erreurs fréquentes

• Trop de graphiques. Si tout est mis en évidence, rien ne l'est.
• Des indicateurs non définis. Deux personnes qui lisent le même tableau de bord doivent arriver à la même conclusion.
• Ne jamais vérifier les chiffres par rapport à la source. Un seul chiffre faux et les gens cessent de faire confiance à l'ensemble du tableau.
• Interroger chaque API à chaque chargement de page. Lent, fragile et parfois coûteux.
• Aucun repère de date. Affichez toujours la période et la comparaison.
• Des secrets dans l'interface. Une clé d'API visible dans le navigateur peut être copiée par quiconque ouvre la page.

Quand un outil de BI est le meilleur choix

Si vos données se trouvent déjà dans une base ou un entrepôt et que les principaux utilisateurs sont des analystes qui veulent les explorer, les découper et construire leurs propres graphiques, un outil de BI (Looker Studio, Power BI, Metabase et d'autres) les servira mieux qu'un développement sur mesure. Beaucoup d'outils SaaS proposent aussi de bons rapports intégrés ; vérifiez-les avant de les reconstruire. Un tableau sur mesure l'emporte lorsqu'il est destiné aux clients ou aux non-analystes, qu'il a besoin d'une logique ou de droits que l'outil de BI ne sait pas exprimer, qu'il combine des sources d'une façon propre à votre activité, ou qu'il doit s'intégrer à un produit que vous exploitez déjà.

Si la tâche consiste moins à consulter des chiffres qu'à modifier des enregistrements, c'est plutôt un espace d'administration ou un outil interne qu'il vous faut : voir comment créer un outil interne. Et si vos chiffres vivent aujourd'hui dans un tableur, comment transformer un tableur en application est une bonne lecture suivante.

Construire avec Mythex

Sur Mythex, vous décrivez le tableau de bord et l'agent construit les pages et les graphiques dans un aperçu en direct, en commençant par des données d'exemple réalistes, puis en passant à une base Postgres dédiée lorsque les chiffres doivent être conservés. Le cas d'usage tableau de bord de la documentation propose une consigne de départ. Si vos données se trouvent dans un outil comme Google Sheets, vous pouvez connecter le compte via Connecteurs et demander à l'agent de le lire et de construire un tableau de bord à partir de celui-ci.

Il n'existe pas de connecteurs d'entrepôt intégrés pour l'application elle-même : pour BigQuery, Snowflake, Stripe et services similaires, l'application appelle leurs API avec des clés que vous stockez comme secrets du projet. Les connexions et les rôles des personnes qui consultent le tableau de bord font partie de l'application que vous construisez. Pour partir d'une consigne, parcourez les modèles de tableaux de bord, comme le tableau de bord de métriques.

Questions