J'ai construit mon premier dashboard local avec Claude
JULIENWEB.FR · BLOG · IA & WORKFLOW
J'ai construit mon premier dashboard local avec Claude
Une session. Zéro template. Node.js + SQLite + 7 widgets. Voilà ce qui se passe quand on arrête de noter des choses dans des fichiers éparpillés et qu’on demande à une IA de construire l’outil à sa place.
📅 Avril 2026 · ✍️ Julien Guézennec · ⏱️ 8 min de lecture · 🏷️ Node.js · SQLite · IA · Claude
Le problème : la mémoire qui fuit
Depuis que j’ai intégré Claude Code dans mon workflow quotidien sur julienweb.fr, j’ai un problème de luxe : je travaille vite. Très vite. En quelques sessions, j’ai publié des articles, réécrit des schémas JSON-LD, exporté un wiki complet en Markdown, créé des CVs PDF avec ReportLab, et scrappé Pantin à la recherche de commerces sans site web.
Mais tout ça créait un autre problème : la dispersion. Mes notes de session dans un fichier .md. Mes candidatures dans un dossier PDF. Mes todos dans un autre fichier. Le wiki dans un troisième répertoire. Les skills Claude dans un quatrième. À chaque début de session, je passais du temps à me rappeler où j’en étais.
"Et si au lieu de noter ce que j'ai fait, j'avais un outil qui me le montrait ?"
L’idée d’un dashboard local m’a semblé évidente. Pas un Notion, pas une app SaaS avec compte et abonnement. Un truc qui tourne sur localhost:3001, qui lit mes fichiers locaux, qui parle à mon WordPress, et qui garde en mémoire mes todos et candidatures en SQLite. Mon outil, mes données, zéro cloud.
La stack choisie — et pourquoi
| Couche | Choix | Pourquoi pas l'alternative ? |
|---|---|---|
| Serveur | Node.js + Express | Déjà dans le projet, zéro nouvelle dépendance |
| Base de données | SQLite — better-sqlite3 | MongoDB = overkill. Zéro serveur, fichier unique, API synchrone |
| Frontend | Vanilla JS | React = overhead inutile pour un client local unique |
| API fichiers | REST + filesystem | GraphQL forcerait du base64 pour les PDFs — lent et inutile |
| Style | CSS custom dark theme | GitHub-inspired, rapide à maintenir, cohérent avec les polices du site |
La règle principale que j’ai appliquée : chaque choix de stack doit pouvoir se justifier en une phrase. Si je dois expliquer pourquoi j’utilise MongoDB pour une app mono-utilisateur local, le choix est mauvais.
Le dashboard en un coup d'oeil
Les 7 widgets — ce qu'ils font vraiment
Offres/*.pdf. Dropdown statut inline. SQLite côté données.wiki/**/*.md directement sur le filesystem. Frontmatter YAML parsé.awesome-claude-skills/. Recherche full-text, modal détail.cv/ via express.static(). Ouverts en un clic.La structure du code — propre et explicable
L’architecture du serveur tient en 30 lignes. C’est le signal que la conception est bonne :
const express = require('express');
const app = express();
app.use(express.json());
// Fichiers statiques (PDFs, assets)
app.use('/static/cv', express.static('../cv'));
app.use('/static/offres', express.static('../Offres'));
// Frontend (index.html + style.css + app.js)
app.use(express.static('public'));
// 9 routes API modulaires
app.use('/api/wiki', require('./api/wiki'));
app.use('/api/wordpress', require('./api/wordpress'));
app.use('/api/candidatures', require('./api/candidatures'));
app.use('/api/todos', require('./api/todos'));
app.use('/api/skills', require('./api/skills'));
app.use('/api/sessions', require('./api/sessions'));
app.listen(3001, () => console.log('Dashboard: http://localhost:3001'));
Chaque route est un module indépendant dans dashboard/api/. Si un widget casse, il est isolé. Si j’en ajoute un, je touche uniquement à server.js (une ligne) et au nouveau fichier. Pas d’effet de bord.
Le résultat — `npm run dashboard`
Aujourd’hui, je lance le dashboard en ouvrant un terminal et en tapant npm run dashboard. En deux secondes, http://localhost:3001 s’ouvre avec :
- Mes todos du moment, triés par priorité
- Mes candidatures en cours avec leur statut
- Les dernières actions de Claude (loggées automatiquement)
- Les 23 articles et 16 pages de mon wiki en lecture rapide
- Les derniers articles publiés sur julienweb.fr en live
- Tous mes skills Claude disponibles avec recherche full-text
"L'outil idéal c'est celui qui disparaît — qui est là quand tu en as besoin, sans que tu aies à y penser."
Ce que ça change vraiment
Construire cet outil avec Claude m’a confirmé quelque chose que je dis à mes clients depuis longtemps : la valeur de l’IA n’est pas dans le « wow » de la démo, c’est dans la réduction des frictions quotidiennes.
Avant ce dashboard, je perdais 5 à 10 minutes par session à reconstituer le contexte. Maintenant je ne perds plus rien. Sur une semaine de 5 sessions, ça fait 25 à 50 minutes récupérées — des heures facturables ou créatives. Et surtout : j’ai construit exactement l’outil dont j’avais besoin, avec des données qui restent chez moi, sur mon disque, sous mon contrôle.
Et maintenant ?
Le dashboard continue d’évoluer à chaque besoin. Prochaine étape probable :
- Widget Analytics — stats GA4 en temps réel
- Widget SEO Monitor — score Yoast et positions Google Search Console
- Notifications push navigateur pour les nouvelles candidatures
- Export hebdomadaire automatique en Markdown pour archive
Si vous voulez construire quelque chose de similaire pour votre workflow, contactez-moi. C’est exactement le genre de projet qu’on peut monter en une journée ensemble.
