Je voulais un tableau de bord qui montre ce que font mes agents d’IA. Pas de surveillance au niveau de Grafana avec des métriques et des alertes — j’ai déjà ça. Je voulais quelque chose que je puisse consulter 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 nécessite mon attention.
Alors, j’en ai construit un en React. Une application monopage qui se connecte aux données d’OpenClaw et les affiche sous la forme d’un tableau de bord propre et adapté aux mobiles. Cela m’a pris un week-end à réaliser et c’est devenu la première chose que je regarde chaque matin.
Ce que le Tableau de Bord Montre
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 peux voir d’un coup d’œil que l’agent de briefing matinal a fonctionné à 8h00, l’agent de surveillance a vérifié les serveurs à 8h15, et l’agent d’email est inactif en attente de nouveaux messages.
Panneau 2 : Activité d’Aujourd’hui
Une vue chronologique de toutes les actions des agents aujourd’hui. Codée par couleur selon le type : bleu pour les appels de modèle d’IA, vert pour les exécutions d’outils, orange pour les interactions utilisateur, rouge pour les erreurs. Défilable. Montre l’activité la plus récente en premier.
C’est ici que je repère les problèmes. Un groupe d’entrées rouges signifie que quelque chose échoue de façon répétée. Un écart dans la chronologie signifie qu’un travail attendu n’a pas été exécuté. 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
Total en cours d’aujourd’hui, comparé à la moyenne quotidienne. Décomposé par modèle et par agent. Un mini graphique à barres montrant les 7 derniers jours pour la comparaison des tendances.
Panneau 4 : Attention Requise
Éléments qui nécessitent mon intervention : brouillons d’email en attente d’approbation, éléments de modération signalés, tâches échouées nécessitant un examen, alertes budgétaires. Chaque élément a un bouton d’action : approuver, rejeter ou voir les détails.
Ce panneau est la raison principale pour laquelle le tableau de bord existe. Tout le reste est informatif. Ce panneau est actionnable.
La Stack Technologique
Frontend : React avec Vite. Pas de bibliothèque de composants — juste du CSS pur avec flexbox/grid. L’ensemble du bundle fait moins de 200 Ko. Charge instantanément, même sur mobile via le réseau cellulaire.
Source de données : Fichiers journaux d’OpenClaw, analysés et fournis par une petite API Express. L’API lit les journaux, extrait les points de données pertinents et les fournit sous forme de JSON. Environ 200 lignes de code.
Hébergement : Fonctionnant sur la même machine qu’OpenClaw. La build React produit des fichiers statiques servis par l’API Express. Pas besoin de serveur web séparé.
Authentification : Authentification de base avec un seul nom d’utilisateur/mot de passe. Ce n’est pas une application multi-utilisateurs — c’est mon tableau de bord personnel. Une authentification simple est suffisante.
Construction de la couche de données
La partie la plus difficile n’était pas le frontend React — c’était d’obtenir des données propres d’OpenClaw.
Les journaux d’OpenClaw sont basés sur du texte et semi-structurés. J’ai écrit un analyseur qui extrait :
– Les horodatages de tous les événements
– Les comptes de tokens des appels API
– Les noms des outils et les temps d’exécution
– Les messages d’erreur et les traces de pile
– Les ID de session pour regrouper les événements connexes
L’analyseur s’exécute toutes les 30 secondes, traite les nouvelles entrées de journaux et stocke les données extraites dans une base de données SQLite. L’API interroge SQLite, qui est suffisamment rapide pour un tableau de bord à utilisateur unique.
Code total de pipeline de données : environ 300 lignes de JavaScript. Pas élégant, mais ça fonctionne de manière fiable.
L’expérience Mobile
J’ai spécifiquement conçu cela pour une visualisation d’abord sur mobile. La mise en page est une seule colonne qui empile les quatre panneaux verticalement. Chaque panneau est réductible — je garde généralement le Panneau 1 et le Panneau 4 développés, et je réduis les Panneaux 2 et 3 sauf si j’en ai besoin.
Les principales décisions de conception :
– Grandes cibles tactiles (pas de petits boutons)
– Couleurs à fort contraste (lisibles en plein soleil)
– Données minimales par panneau (montrer le résumé, pas le détail)
– Tirer pour rafraîchir (interaction mobile naturelle)
Fonctionnalités que j’ai Ajoutées Plus Tard
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, et déclencher des exécutions manuelles de tâches programmées. Ces boutons m’ont épargné de me connecter en SSH au serveur pour des opérations courantes.
Vue historique. Un sélecteur de date qui montre l’activité d’un jour précédent. Utile pour enquêter sur les scénarios “que s’est-il passé hier pendant que je dormais ?”.
Projections de coûts. Basé sur les 7 derniers jours d’utilisation, le tableau de bord projette les coûts mensuels. Cette projection se met à jour quotidiennement et a été précise à 10% près des coûts réels.
Ce que je Ferais Différemment
Utiliser des WebSockets au lieu de consulter. Le tableau de bord interroge l’API toutes les 30 secondes pour des mises à jour. Les WebSockets fourniraient des mises à jour en temps réel sans le surcoût de l’interrogation. Je ne me suis pas donné la peine de le changer car des mises à jour toutes les 30 secondes conviennent à mes besoins, mais c’est l’amélioration évidente.
Ajouter une intégration de notification. Actuellement, les alertes passent par Grafana/Slack. Faire en sorte que le tableau de bord envoie des notifications push directement regrouperait mes canaux d’alerte.
Commencer plus simplement. J’ai trop développé la première version avec des fonctionnalités que je n’avais pas besoin (répartition des coûts par agent par heure, graphiques de tendances historiques, recherche de journaux). Les fonctionnalités que j’utilise réellement quotidiennement sont : aperçu de l’état, éléments nécessitant attention et actions rapides. J’aurais pu construire une v1 utile en quelques heures au lieu d’un week-end.
🕒 Published: