Je voulais un tableau de bord qui montre ce que font mes agents IA. Pas un monitoring de niveau Grafana avec des métriques et des alertes — j’ai déjà ça. Je voulais quelque chose que je puisse consulter en un coup d’œil sur mon téléphone et savoir : quels agents sont actifs, sur quoi ils travaillent, combien ils ont dépensé aujourd’hui et si quelque chose requiert mon attention.
Alors j’en ai construit un en React. Une application monopage qui se connecte aux données d’OpenClaw et les affiche dans un tableau de bord clair et adapté au mobile. Ça m’a pris un week-end à coder et c’est devenu la première chose que je consulte chaque matin.
Ce que le tableau de bord affiche
Panneau 1 : État des agents
Une liste de tous les agents configurés avec leur état actuel : actif (vert), inactif (jaune), erreur (rouge). Chaque agent affiche l’horodatage de sa dernière activité et une description en une ligne de ce qu’il a fait récemment. Je vois d’un coup d’œil que l’agent de briefing matinal a tourné à 8h, que l’agent de surveillance a vérifié les serveurs à 8h15, et que l’agent email est inactif en attente de nouveaux messages.
Panneau 2 : Activité du jour
Une vue chronologique de toutes les actions des agents aujourd’hui. Codée par couleur selon le type : bleu pour les appels aux modèles IA, vert pour les exécutions d’outils, orange pour les interactions utilisateurs, rouge pour les erreurs. Scrollable. Affiche les activités les plus récentes en premier.
C’est là que je repère les problèmes. Un regroupement d’entrées rouges signifie qu’une erreur se répète. Une absence dans la timeline indique qu’un travail attendu n’a pas eu lieu. Une barre bleue anormalement longue signifie qu’un appel API a pris beaucoup plus de temps que d’habitude.
Panneau 3 : Suivi des coûts
Le total cumulé d’aujourd’hui, comparé à la moyenne quotidienne. Détaillé par modèle et par agent. Un mini graphique en barres montre les 7 derniers jours pour comparer les tendances.
Panneau 4 : Actions requises
Éléments nécessitant mon intervention : brouillons d’emails en attente d’approbation, contenus signalés en modération, tâches échouées à revoir, alertes budgétaires. Chaque élément a un bouton d’action : approuver, rejeter ou voir les détails.
Ce panneau est la raison d’être du tableau de bord. Tout le reste est informatif, celui-ci est interactif.
La stack technique
Frontend : React avec Vite. Pas de bibliothèque de composants — juste du CSS pur avec flexbox/grid. Le bundle complet fait moins de 200KB. Chargement instantané, même en 4G sur mobile.
Source des données : fichiers logs d’OpenClaw, analysés et servis par une API Express légère. L’API lit les logs, extrait les données pertinentes et les fournit en JSON. Environ 200 lignes de code.
Hébergement : Sur la même machine qu’OpenClaw. La compilation React produit des fichiers statiques servis par l’API Express. Pas besoin de serveur web distinct.
Authentification : Auth basique avec un seul identifiant/mot de passe. Ce n’est pas une application multi-utilisateurs — c’est mon tableau de bord perso. Une simple authentification suffit.
Construire la couche données
Le plus difficile n’a pas été le frontend React, mais d’extraire des données propres depuis OpenClaw.
Les logs OpenClaw sont du texte semi-structuré. J’ai écrit un parseur qui extrait :
– Les horodatages de tous les événements
– Le nombre de tokens des appels API
– Les noms d’outils et leur temps d’exécution
– Les messages d’erreur et traces de pile
– Les identifiants de session pour regrouper les événements liés
Le parseur s’exécute toutes les 30 secondes, traite les nouvelles entrées du log, et stocke les données extraites dans une base SQLite. L’API interroge SQLite, ce qui est assez rapide pour un tableau de bord mono-utilisateur.
Code total de la pipeline de données : environ 300 lignes de JavaScript. Pas très élégant, mais fiable.
L’expérience mobile
J’ai conçu spécifiquement pour une consultation mobile-first. Le layout est une colonne unique qui empile les quatre panneaux verticalement. Chaque panneau peut se replier — je laisse généralement le panneau 1 et le panneau 4 ouverts, et replie les panneaux 2 et 3 sauf si j’en ai besoin.
Les choix clés de design :
– Grandes zones cliquables (pas de petits boutons)
– Couleurs à fort contraste (lisibles en plein soleil)
– Données minimales par panneau (afficher le résumé, pas le détail)
– Pull-to-refresh (interaction mobile naturelle)
Fonctionnalités ajoutées par la suite
Actions rapides. Depuis le tableau de bord, je peux : redémarrer OpenClaw, mettre en pause/reprendre des agents spécifiques, approuver des éléments en attente, lancer manuellement des tâches planifiées. Ces boutons m’évitent de me connecter en SSH pour les opérations courantes.
Vue historique. Un sélecteur de date qui affiche l’activité de n’importe quel jour précédent. Pratique pour savoir « que s’est-il passé hier pendant que je dormais ? »
Projections de coûts. Basées sur les 7 derniers jours d’utilisation, le tableau de bord prévoit les coûts mensuels. Cette estimation se met à jour quotidiennement et s’est avérée précise à 10 % près.
Ce que je ferais différemment
Utiliser WebSockets au lieu du polling. Le tableau de bord interroge l’API toutes les 30 secondes pour les mises à jour. WebSockets permettraient des mises à jour en temps réel sans ce surcoût. Je ne l’ai pas fait car 30 secondes suffisent pour mes besoins, mais c’est l’amélioration évidente.
Ajouter une intégration de notifications. Pour l’instant, les alertes passent par Grafana/Slack. Faire que le tableau de bord envoie directement des notifications push permettrait de centraliser mes canaux d’alerte.
Commencer plus simple. J’ai trop construit la première version avec des fonctionnalités dont je n’avais pas besoin (coût par agent et par heure, graphiques historiques, recherche dans les logs). Les fonctions que j’utilise vraiment au quotidien sont : aperçu du statut, éléments nécessitant une action, actions rapides. J’aurais pu faire un v1 utile en quelques heures au lieu d’un week-end.
🕒 Published: