Le scraping de dashboards via l’automatisation navigateur est l’approche pour les cas où il n’existe pas d’API ni d’accès à l’entrepôt. OpenClaw inclut un contrôle complet via le Chrome DevTools Protocol (CDP) à cet effet. Toute autre méthode d’accès aux données est plus fiable ; le scraping est une solution de repli pour les outils sans API, avec une API limitée, ou dont l’API retourne des chiffres différents de l’interface.
Comment fonctionne la boucle de scraping
Le scraping de dashboards dans OpenClaw suit un cycle en cinq étapes :
1. Naviguer vers l’URL du dashboard. L’agent utilise CDP pour ouvrir l’URL dans une session Chrome contrôlée. C’est le même navigateur que vous utiliseriez manuellement — le runtime Chrome complet, pas un parser HTML simplifié.
2. Attendre le chargement du contenu dynamique. Les dashboards modernes ne servent pas du HTML statique. Ils exécutent du JavaScript qui effectue des appels AJAX, rend des bibliothèques de graphiques et peuple des données depuis des API internes. L’agent doit attendre que cela soit terminé avant que les chiffres soient réellement visibles dans le DOM. La durée d’attente est un paramètre à ajuster : trop courte et les chiffres ne sont pas encore là, trop longue et vous ajoutez une latence inutile à chaque exécution.
3. Prendre une capture d’écran ou extraire le contenu de la page. Deux options ici. Une capture d’écran saisit ce qui est visible — utile quand la mise en page est importante ou quand vous souhaitez un enregistrement visuel. L’extraction DOM lit le HTML/texte brut de la page et donne à l’agent du contenu structuré (si peu ordonné) à parser. Pour l’extraction numérique, le contenu DOM tend à être plus fiable que demander à l’agent de parser une capture d’écran, mais les deux approches fonctionnent.
4. Parser les chiffres clés depuis les données visibles. C’est là qu’intervient l’interprétation de l’agent. Il lit le contenu et extrait les métriques spécifiques demandées — revenus, sessions, taux de conversion, ce que le dashboard affiche. Cette étape repose entièrement sur la capacité de l’agent à identifier correctement quels chiffres correspondent à quoi. Si la mise en page du dashboard est ambiguë (et beaucoup le sont), l’agent peut identifier une métrique de façon incorrecte.
5. Composer un résumé. L’agent formate ce qu’il a trouvé dans le format de sortie demandé et l’envoie vers le canal configuré.
Gestion de session : réutiliser les sessions authentifiées
Le principal défi pratique du scraping de dashboards est l’authentification. Les dashboards nécessitent une connexion, et planifier un job qui s’exécute à 6h le lundi ne fonctionne pas s’il doit compléter interactivement un flux OAuth.
OpenClaw gère cela via des profils navigateur. Si vous vous êtes connecté au dashboard d’un client une fois dans une session navigateur connectée et avez sauvegardé l’état de la session, OpenClaw peut réutiliser ce profil pour les visites automatisées ultérieures. Les cookies de session persistent, so le job automatisé navigue directement vers le dashboard sans rencontrer de mur de connexion.
Cela fonctionne de façon fiable jusqu’à ce que :
- La session expire (la plupart des systèmes SSO expirent les sessions après 30 à 90 jours)
- Le client change de fournisseur d’authentification ou ajoute du MFA
- Le profil navigateur devienne obsolète après une mise à jour de Chrome
Vous avez besoin d’une routine de maintenance : vérifier périodiquement que les sessions authentifiées fonctionnent toujours, les rafraîchir avant expiration, et surveiller les échecs d’authentification silencieux qui font que le job de scraping extrait le mauvais contenu (la page de connexion) au lieu du dashboard.
Quand le scraping de dashboards est pertinent
Trois catégories d’outils sont réellement mieux accessibles par scraping que par API :
Dashboards Looker avec états de filtre complexes. L’API Looker est puissante, mais répliquer programmatiquement une configuration de filtre spécifique est plus complexe que de simplement naviguer vers l’URL sauvegardée avec ces filtres déjà appliqués. Si un client a une vue hebdomadaire standard sauvegardée dans Looker Studio avec les bons découpage dimensionnels, scraper cette vue est parfois plus rapide que d’écrire la requête API Looker équivalente from scratch.
Outils BI internes personnalisés. Les équipes d’ingénierie client construisent souvent des dashboards internes par-dessus leur propre entrepôt de données sans aucune surface API. Si le dashboard n’a pas d’API, le scraping est le seul chemin d’accès automatisé court des credentials d’entrepôt directs.
Portails de plateformes publicitaires dont l’API est limitée. Certaines plateformes exposent des données agrégées via leur UI qui ne sont pas disponibles via leur API, ou l’API a des fenêtres d’attribution différentes du dashboard. Pour les plateformes où l’UI et l’API retournent réellement des chiffres différents, scraper l’UI peut être le seul moyen d’extraire les chiffres que les clients regardent effectivement.
Le problème de fragilité
Le scraping est fragile d’une manière que les API et les requêtes directes ne sont pas. Quand la structure du dashboard change — et elle changera — l’automatisation de scraping se casse. Le problème critique est qu’elle se casse silencieusement.
Une API retournant un code d’erreur échoue bruyamment. Une requête de base de données qui touche une table manquante lève une exception. Un sélecteur CSS modifié ou une mise en page de page changée fait extraire à l’agent les mauvais chiffres ou aucun chiffre, mais le job se termine quand même « avec succès ». L’agent rapporte un chiffre, l’envoie sur Slack et marque le job comme terminé. Il n’y a pas d’erreur. Vous obtenez un résumé confiant de données incorrectes.
Un exemple réel : un setup de scraping d’un dashboard Looker qui fonctionnait parfaitement pendant deux semaines s’est cassé quand l’équipe du client a mis à jour un composant de filtre. L’agent a commencé à extraire des chiffres d’une différente section de la page. Les chiffres semaine sur semaine semblaient encore plausibles (la nouvelle section affichait des métriques à une échelle similaire). Le rapport du lundi est parti avec des données erronées. Ce n’est qu’en faisant des vérifications manuelles ponctuelles que c’est été détecté — ce qui défiait une part significative de l’objectif de l’automatisation.
Les échecs silencieux sont plus dangereux que les échecs bruyants parce qu’ils sont plus difficiles à détecter. Vous pouvez alerter sur une exception ; vous ne pouvez pas facilement alerter sur « ce chiffre semble légèrement décalé par rapport à ce que j’attendrais ».
Des atténuations qui ne résolvent pas complètement le problème
Plusieurs approches réduisent le risque sans l’éliminer :
Contrôles de plausibilité. Demandez à l’agent de signaler les grandes variations semaine sur semaine (>50 %) comme potentiellement erronées plutôt que de les rapporter comme des faits. Cela attrape les cas où l’agent a extrait des chiffres de la mauvaise section, qui tendent à être dramatiquement différents des valeurs correctes. Cela n’attrape pas les erreurs plus petites.
Archivage des captures d’écran. Configurez le job pour sauvegarder une capture d’écran en plus des données extraites. Le lundi matin, vous pouvez jeter un œil à la capture d’écran pour confirmer que l’agent regardait au bon endroit. Plus de revue manuelle, mais cela vous donne un artefact de vérification.
Validation croisée par rapport à une valeur connue. S’il y a une métrique que vous pouvez vérifier via un autre canal (l’entrepôt, l’API GA4), incluez-la dans l’extraction de scraping. Si la valeur scrapée pour les sessions correspond à vos sessions GA4 API dans un écart de 5 %, le reste est probablement correct. Sinon, le rapport nécessite une révision.
Tests de smoke réguliers. Une fois par mois, parcourez manuellement le workflow de scraping : naviguez vers le dashboard, confirmez que l’agent extrait depuis les bons éléments, vérifiez les chiffres par rapport à une source de vérité connue. Traitez-le comme un test de smoke pour tout autre système automatisé.
Aucune de ces approches n’attrape tous les échecs silencieux. Elles réduisent le risque. La bonne posture est : utiliser le scraping de dashboards pour ce qui ne peut pas être accédé autrement, maintenir une cadence de vérification manuelle ponctuelle pour tout ce qui est client-facing, et migrer vers un accès API ou entrepôt dès que possible.
Les meilleures alternatives
Avant de recourir au scraping de dashboards, épuisez ces options :
Requêtes directes sur l’entrepôt — si le dashboard tire ses données d’un entrepôt auquel vous avez accès, passez directement par l’entrepôt et interrogez la source. Consultez les patterns de reporting KPI via requêtes directes sur l’entrepôt. Les requêtes d’entrepôt sont déterministes, ne se cassent pas lors des changements d’UI et vous donnent accès aux données sous-jacentes plutôt qu’à une vue pré-filtrée.
API officielles — même les API limitées sont plus fiables que le scraping. L’API Data de GA4 vous donne les mêmes chiffres que l’interface GA4 (en grande partie — voir les mises en garde sur l’échantillonnage). Looker a une API REST complète. La plupart des plateformes publicitaires ont des endpoints analytics. La mise en place de l’API prend plus de temps que la configuration du scraping, mais le coût de maintenance continu est considérablement plus faible.
Exports de données + parsing de fichiers — certains outils supportent des exports automatisés de données (rapports programmés par email, téléchargements planifiés) qui produisent des CSV. Parser un CSV est plus fiable que parser un DOM rendu, et le format d’export change généralement moins souvent que la mise en page de l’UI.
Le scraping de dashboards a un cas d’usage réel. Traitez-le simplement comme l’option que vous utilisez quand les meilleures options n’existent pas.