Créer un tableau de bord de données avec l’IA

Pour créer un tableau de bord de données avec l’IA, montrez vos données à un agent de code et demandez-lui d’écrire le code d’analyse : il lit vos données Excel, CSV ou SQL avec pandas, les nettoie et les résume, puis en fait en quelques heures un tableau de bord Streamlit interactif. Si le tableau de bord fait partie d’un produit, vous faites la même chose avec Next.js et une bibliothèque de graphiques. Ce qui demande votre attention n’est pas le code ; c’est de savoir si les chiffres sont justes et si les données restent privées.

Cet article va pas à pas d’un tableur de ventes à un tableau de bord partageable : outils, premier prompt, connexion à une base en lecture seule, vérification des calculs de l’IA et déploiement.

Ce que nous construisons

L’objectif est de remplacer un rapport Excel que vous mettez à jour à la main chaque semaine par un tableau de bord qui se met à jour tout seul. Un tableau de bord de ventes typique comprend : un total de période, l’évolution par rapport à la période précédente, un graphique du chiffre d’affaires mensuel, les meilleurs produits, une répartition par région ou canal, et un filtre de dates.

Nous le ferons à la façon du vibe coding : l’agent écrit le code, vous décrivez ce que vous voulez voir et vous vérifiez le résultat. Dans le travail sur les données, cette approche a une condition : vous devez connaître vos données assez bien pour questionner les chiffres qu’elle produit.

Quelle voie : Streamlit ou Next.js ?

La voie rapide : Python, pandas et Streamlit. Un seul fichier Python devient une interface web fonctionnelle. Filtres, tableaux, graphiques et cartes de métriques demandent quelques lignes chacun. Si vous avez besoin d’un tableau de bord interne pour vous, votre responsable ou une petite équipe, c’est le chemin le plus court. pandas lit aussi bien Excel, CSV que SQL.

La voie produit : Next.js et une bibliothèque de graphiques. Si des clients verront le tableau de bord et que vous avez besoin d’une connexion utilisateur, de permissions de données par utilisateur et d’un design à l’image de votre marque, une application basée sur React convient mieux. Recharts, Chart.js et ECharts sont des choix courants. Les données sont interrogées côté serveur, dans une route d’API, et seul le résumé dont l’utilisateur a besoin arrive au navigateur.

Dans le doute, commencez par Streamlit. Passer à un produit est bien plus facile une fois que vous savez quels graphiques les gens utilisent vraiment.

Étape 1 : installation

Un agent de code en terminal (Claude Code, Codex, Gemini CLI, la CLI de Cursor, etc.) et Python suffisent :

mkdir sales-dashboard && cd sales-dashboard
git init
python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install pandas openpyxl streamlit plotly
mkdir data && cp ~/Downloads/sales_2026.xlsx data/
echo "data/" >> .gitignore
echo ".env" >> .gitignore

Je garde data/ hors de git dès le départ ; les données clients n’ont rien à faire dans le dépôt.

Étape 2 : d’abord, connaître les données

L’erreur la plus courante est de dire à l’agent « fais-moi un tableau de bord » tout de suite. Demandez-lui de comprendre d’abord les données. Ce premier tour ne dessine rien ; il fait seulement un rapport :

Read data/sales_2026.xlsx with pandas and write me a data report:
- Sheet names, row and column counts per sheet
- Each column’s type, share of empty values and 5 sample values
- Format of date and money columns (any comma decimals or mixed formats?)
- Duplicate rows and likely key columns (such as order ID)
- Anything that looks inconsistent
Don’t change any file and don’t draw charts. Save the report as analysis/data_report.md.

Lisez ce rapport. Des constats comme « 37 lignes de la colonne Amount sont arrivées en texte » ou « le même identifiant de commande apparaît deux fois » touchent tous les chiffres qui suivent. C’est vous qui décidez lesquels sont des erreurs et lesquels sont réels (remboursements, commandes scindées) ; ne laissez pas l’agent corriger les données en devinant.

Étape 3 : le prompt du tableau de bord

Une fois les données propres, demandez le tableau de bord. Écrivez les questions auxquelles il doit répondre ; l’agent peut suggérer les types de graphiques :

Write app.py with Streamlit. Data: data/sales_2026.xlsx, sheet "Sales".

Put cleaning in its own function (load_data), cached with st.cache_data.
Refunds (Amount < 0) count towards revenue and are also shown as a separate metric.

The dashboard should answer:
1. Total revenue, order count and average order value for the selected date range
   (each with change versus the same period last year)
2. Monthly revenue trend (line chart)
3. Top 10 products by revenue (horizontal bar)
4. Revenue by region (bar) with a region filter

Rules:
- All calculations in metrics.py as pure functions.
- Write pytest tests for metrics.py using a small sample dataset with hand-calculated results.
- Format money with the right currency symbol and thousands separators.
When done, run the tests and tell me the streamlit run command.

Garder les calculs dans un fichier séparé de fonctions testables est la partie la plus importante de ce prompt. L’interface se change facilement ; une fonction de total fausse casse tous les graphiques.

pytest -q
streamlit run app.py

Regardez le tableau de bord dans le navigateur, puis demandez de petites modifications : « Les libellés de produits sont coupés, passe en horizontal. » « Mets le filtre de dates sur le mois en cours par défaut. » Faites un commit après chaque changement pour pouvoir revenir en arrière.

Étape 4 : se connecter à la base en lecture seule

Si les données vivent dans la base de votre application plutôt que dans un tableur, la règle clé est : l’utilisateur du tableau de bord ne peut que lire. Un utilisateur PostgreSQL distinct :

CREATE ROLE dashboard_reader LOGIN PASSWORD 'a-strong-password-here';
GRANT CONNECT ON DATABASE app TO dashboard_reader;
GRANT USAGE ON SCHEMA public TO dashboard_reader;
GRANT SELECT ON orders, order_items, products TO dashboard_reader;

Mettez la chaîne de connexion dans .env (DATABASE_URL=...) et ne donnez à l’agent que le nom de la variable. Quelques points pratiques de plus :

• N’accordez l’accès qu’aux tables nécessaires. Si la table des utilisateurs contient des e-mails et des numéros de téléphone dont le tableau de bord n’a pas besoin, il ne doit pas pouvoir les lire.
• Utilisez une réplique en lecture ou une copie nocturne quand vous le pouvez. Une requête lourde écrite par l’agent peut ralentir le système en production.
• Définissez un délai d’expiration des requêtes (statement_timeout dans PostgreSQL) et limitez la taille des résultats.
• Demandez à l’agent de garder le SQL dans des fichiers .sql séparés ; les requêtes sont plus faciles à lire et à exécuter à la main.

Étape 5 : vérifier les chiffres

C’est la section la plus importante. L’échec le plus dangereux d’un tableau de bord n’est pas de planter ; c’est d’afficher un chiffre faux dans un graphique convaincant.

Comparez les totaux clés à la main

Calculez 3 ou 4 chiffres clés d’une autre façon : un tableau croisé dynamique dans Excel, ou une requête SQL simple que vous écrivez vous-même. Le chiffre d’affaires de mars, par exemple :

SELECT SUM(total) FROM orders
WHERE created_at >= '2026-03-01' AND created_at < '2026-04-01'
  AND status <> 'cancelled';

Si le tableau de bord ne correspond pas, n’avancez pas tant que vous ne pouvez pas expliquer l’écart. La réponse est généralement l’une de celles-ci : les annulations sont-elles incluses, où sont les remboursements, la taxe est-elle incluse, quel fuseau horaire ?

La jointure fausse silencieuse

C’est l’erreur SQL que l’IA commet le plus souvent et la plus difficile à repérer :

-- WRONG: each order is repeated once per line item
SELECT SUM(o.total)
FROM orders o
JOIN order_items i ON i.order_id = o.id;

Une commande de trois articles devient trois lignes et o.total est additionné trois fois. La requête s’exécute bien, le résultat paraît plausible, et le chiffre d’affaires est gonflé. La correction est d’agréger au bon niveau : soit sommer sur orders seule, soit résumer d’abord les articles par commande puis faire la jointure. Pour vérifier, demandez à l’agent :

For each JOIN in this query: is the row count after the join the same as the
row count of the main table before it? Show COUNT(*) and COUNT(DISTINCT o.id).

Si les deux nombres diffèrent, des lignes se multiplient quelque part.

Autres pièges

• Bornes de dates : BETWEEN '2026-03-01' AND '2026-03-31' sur une colonne timestamp manque presque tout le 31 mars. Utilisez un intervalle semi-ouvert.
• Fuseaux horaires : si la base stocke en UTC, les commandes proches de minuit tombent sur le mauvais jour.
• Moyennes de moyennes : la moyenne des paniers moyens de chaque région n’est pas le panier moyen global.
• Valeurs manquantes : les lignes avec NaN disparaissent silencieusement de certaines opérations pandas.

Étape 6 : partager et déployer

• Streamlit : pour un usage interne, faites-le tourner sur un serveur ou dans un conteneur Docker derrière le réseau de votre entreprise ou une couche de connexion. Streamlit a aussi son propre service d’hébergement, mais ne mettez pas un tableau de bord avec des données clients sur une URL publique ; vous devez savoir qui y a accès.
• Next.js : déployez sur une plateforme comme Vercel ou sur votre propre serveur. Vérifiez côté serveur l’authentification et que chaque utilisateur ne voit que ses propres données ; filtrer seulement dans l’interface n’est pas de la sécurité.
• Garder les données à jour : pour les tableaux de bord basés sur des tableurs, lire le fichier depuis un dossier partagé ou le charger dans une base avec un petit script nocturne met fin aux mises à jour manuelles.

Ce que l’IA se trompe souvent à faire

• « Corriger » les données en devinant : remplir les blancs par zéro, supprimer les dates qu’elle ne sait pas lire. Faites-lui écrire explicitement chaque règle de nettoyage et validez-les.
• Des noms de colonnes inventés : sans voir le schéma, elle invente une colonne comme customer_name. Donnez-lui le vrai schéma.
• Formats de nombres : lire 1.234,56 comme 1.234. Demandez-lui d’afficher côte à côte les valeurs brutes et interprétées.
• Tout mettre en graphique : un tableau de bord de 15 graphiques est un tableau de bord que personne ne regarde. Limitez-le aux questions qui comptent.
• « J’ai vérifié » : un agent qui teste son propre code avec son propre test peut faire deux fois la même mauvaise hypothèse. Vérifiez un chiffre vous-même.

Sécurité et confidentialité

• Les détails de connexion dans .env, avec .env et data/ hors de git.
• Ne collez jamais un mot de passe ou une chaîne de connexion dans le chat. Donnez à l’agent le nom de la variable.
• N’envoyez pas de données clients brutes au modèle. L’agent a besoin du schéma et de quelques lignes d’exemple pour écrire du code ; anonymisez les exemples ou générez-en de faux. Le code traite les données sur votre machine, pas le modèle. Vos obligations RGPD (ou KVKK) sur les données personnelles ne changent pas.
• Lisez les commandes et le SQL que l’agent exécute. Exécuter quoi que ce soit avec DELETE, UPDATE ou DROP via l’utilisateur du tableau de bord doit de toute façon être impossible ; c’est le rôle de l’utilisateur en lecture seule.
• Sachez qui peut voir l’URL du tableau de bord. Partager un lien, c’est partager les données.

Le faire avec AgentVera

Rien de ce qui précède ne demande un outil particulier. Je fais ce genre de travail dans AgentVera parce qu’il raccourcit quelques étapes liées aux bases de données :

• Gestionnaire de bases de données. Le gestionnaire de bases de données se connecte à PostgreSQL, MySQL/MariaDB et SQLite. Une connexion que vous marquez « read-only » est aussi ouverte en lecture seule côté serveur. Vous pouvez exécuter vous-même le SQL de l’agent dans l’éditeur SQL pour comparer les totaux, et utiliser EXPLAIN pour repérer les requêtes lourdes.
• Accès contrôlé pour les agents. Si vous activez l’accès des agents pour une connexion, les agents qui prennent en charge MCP exécutent les requêtes via l’outil agentvera-db ; ils ne voient jamais le mot de passe, le mode est en lecture seule par défaut et chaque requête est journalisée. Le bouton « AI » qui transforme une demande en SQL envoie des noms de tables et de colonnes, pas des lignes de tables.
• DB Guard. Si l’agent écrit une migration d’index ou de vue pour le tableau de bord, DB Guard l’analyse à la fin du tour et signale les risques comme les créations d’index bloquantes ou les pertes de données.
• Agents parallèles et aperçus. Claude Code peut écrire le SQL et les métriques dans un volet pendant que Codex travaille sur l’interface dans un autre, chacun dans son propre worktree git. Les environnements d’aperçu démarrent le serveur de chaque worktree sur son propre port.
• Relecture du diff. La revue de code donne un second regard aux fonctions de métriques avant la fusion.

Le gestionnaire de bases de données et l’accès des agents sont dans les offres Pro et Team. Pour en savoir plus sur le contrôle du code écrit par des agents, voyez la revue de code par IA ; pour travailler en parallèle, voyez les worktrees git pour agents en parallèle.

Liste de contrôle rapide

• L’agent a d’abord écrit un rapport sur les données, et vous avez validé les règles de nettoyage
• Les calculs vivent dans des fonctions séparées et testées
• Au moins 3 chiffres clés vérifiés à la main d’une autre façon
• Nombre de lignes vérifié pour chaque JOIN
• La connexion à la base utilise un utilisateur limité à SELECT
• .env et data/ hors de git, aucune donnée client envoyée au modèle
• Accès au tableau de bord limité à des personnes connues

Conclusion

Créer un tableau de bord avec l’IA accélère le codage mais ne délègue pas la réflexion. L’agent écrit du code pandas, SQL et Streamlit en quelques minutes ; décider quel chiffre est juste et quelles données peuvent être partagées reste votre travail. Choisissez un rapport Excel que vous mettez à jour à la main cette semaine, demandez d’abord à l’agent un rapport sur les données, construisez le premier tableau de bord Streamlit et vérifiez trois chiffres vous-même.