Faire tourner un workflow de reporting OpenClaw pour plusieurs clients nécessite une conception d’isolation délibérée. Le passage d’un client à plusieurs soulève des questions que la configuration mono-client ne fait pas émerger : empêcher que les données d’un client apparaissent dans le rapport d’un autre, gérer l’expiration des credentials par client et contenir les échecs à un seul client plutôt qu’à tous.
Un job cron par client, sans exception
Chaque client reçoit son propre job cron isolé. Ce n’est pas une recommandation — c’est une exigence pour un comportement correct.
Un job cron isolé s’exécute dans sa propre session d’agent dédiée, séparée de chaque autre job et de la conversation active. Les données du Client A ne touchent pas le contexte du Client B. Un échec des credentials du Client A ne bloque pas le rapport du Client B. Les jobs sont indépendants, ce qui est exactement ce qu’on veut quand chacun gère les données d’un client différent.
Un workflow du lundi matin pour trois clients ressemble à ceci :
# Client A : GA4 + BigQuery, 6hopenclaw cron add --name "client-acme-weekly" \ --cron "0 6 * * 1" \ --tz "Europe/Paris" \ --session isolated \ --message "Run the weekly KPI report for Acme Corp. Pull GA4 sessions and conversions for the past 7 days. Query BigQuery for revenue metrics using ~/reports/acme/revenue-weekly.sql. Compare this week to last week. Format as a Slack summary and post to the channel." \ --announce \ --channel slack \ --to "channel:C0ACME_REPORT"
# Client B : Snowflake + dashboard, 6h10openclaw cron add --name "client-pvcp-weekly" \ --cron "10 6 * * 1" \ --tz "Europe/Paris" \ --session isolated \ --message "Run the weekly KPI report for PVCP. Query Snowflake for sessions and conversion metrics using ~/reports/pvcp/snowflake-weekly.sql. Format as a Slack summary and post to the channel." \ --announce \ --channel slack \ --to "channel:C0PVCP_REPORT"
# Client C : BigQuery uniquement, 6h20openclaw cron add --name "client-xyz-weekly" \ --cron "20 6 * * 1" \ --tz "Europe/Paris" \ --session isolated \ --message "Run the weekly KPI report for XYZ. Query BigQuery for pipeline metrics using ~/reports/xyz/pipeline-weekly.sql. Format as a Slack summary and post to the channel." \ --announce \ --channel slack \ --to "channel:C0XYZ_REPORT"Décalez les heures de démarrage de 10 minutes. Si chaque rapport prend 5 minutes à s’exécuter, cela évite les chevauchements sans avoir à savoir à l’avance exactement combien de temps chaque job prend. Le mode de session isolée signifie qu’un chevauchement ne causerait pas de contamination des données de toute façon, mais l’exécution en série évite de concourir pour les limites de taux d’API.
Isolation des échecs : pourquoi cette architecture importe
Si le token OAuth GA4 du Client A expire à 5h le lundi, ce job échoue. Les Clients B et C reçoivent leurs rapports à l’heure, comme planifié. OpenClaw applique un backoff exponentiel au job en échec du Client A et le relance ; une notification d’échec est reçue.
Sans isolation par client, une configuration partagée unique se propagerait en cascade : un seul échec de credentials pourrait laisser sans aucun rapport pour aucun client. Avec l’isolation, le rayon d’impact de tout échec unique est exactement le rapport d’un seul client.
Voir mécanique du scheduler cron OpenClaw pour la mécanique complète de la façon dont OpenClaw gère les relances, le backoff et les notifications d’échec. Le point clé pour les configurations multi-clients est que chaque job a son propre état d’échec, sa propre file de relance et son propre chemin de notification.
La réalité de la gestion des credentials
C’est là que l’architecture devient inconfortable. Les sources de données de chaque client nécessitent des credentials :
- GA4 : tokens OAuth ou clés de compte de service
- BigQuery : fichiers JSON de compte de service
- Snowflake : nom d’utilisateur, mot de passe, identifiant de compte
- Looker : credentials API
- Plateformes publicitaires : tokens API, tokens OAuth
OpenClaw stocke la configuration dans des fichiers en texte clair sous ~/.openclaw/. Sur une machine exécutant les jobs de reporting de cinq clients, cela représente cinq ensembles de fichiers de credentials, tous accessibles à tout processus s’exécutant en tant qu’utilisateur.
Les infostealers — RedLine, Lumma, Vidar — ont ajouté les chemins de fichiers de configuration d’OpenClaw à leurs listes de cibles. Hudson Rock a documenté le premier cas réel d’exfiltration d’une configuration OpenClaw complète. Si la machine est compromise par n’importe quel vecteur (phishing, extension de navigateur malveillante, dépendance compromise), les credentials d’entrepôt de chaque client sont exposées.
Le risque n’est pas hypothétique. Voir risques de sécurité OpenClaw documentés pour les incidents documentés. La question pertinente pour le travail en agence n’est pas « est-ce risqué ? » (oui) mais « quelles mitigations sont disponibles ? »
Options d’isolation des credentials
Variables d’environnement au lieu de fichiers de config. Au lieu de stocker les credentials dans ~/.openclaw/config/, les passer comme variables d’environnement. Cela n’élimine pas le risque (les variables d’environnement sont également lisibles par les processus s’exécutant en tant qu’utilisateur), mais maintient les credentials hors des chemins de fichiers spécifiques que ciblent les infostealers.
Intégration avec un secrets manager. Récupérer les credentials depuis un secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault) au moment de l’exécution du job plutôt que de les stocker localement. OpenClaw n’a pas d’intégration native avec les secrets managers au début de 2026, mais les commandes CLI peuvent être encapsulées pour récupérer les credentials avant l’exécution :
# Récupérer les credentials et exécuter en une seule commandeexport BQ_CREDENTIALS=$(gcp-secrets-manager get client-acme-bigquery-key) && \ openclaw cron add ...Cela ajoute de la complexité et dépend de la bonne gestion de l’injection des credentials par l’agent, mais déplace le matériel sensible hors des fichiers en texte clair.
VMs isolées par client. L’architecture la plus propre : chaque client tourne sur une machine virtuelle séparée sans credentials partagées. La VM du Client A n’a que les credentials du Client A. La compromission d’une VM n’expose pas les données d’aucun autre client. C’est ce qu’on implémenterait pour construire cela comme un service de production plutôt que comme une automatisation personnelle. La surcharge (provisionnement de VM, maintenance de cinq installations OpenClaw séparées) est significative pour un consultant indépendant.
Comptes utilisateurs séparés. Moins d’isolation que les VMs, plus qu’un seul environnement partagé. Chaque client reçoit un compte utilisateur OS séparé avec son propre répertoire home et son propre chemin ~/.openclaw/. Une fuite de credentials d’un compte n’expose pas automatiquement les credentials d’un autre compte, en supposant que la compromission n’escalade pas les privilèges.
Aucune de ces solutions n’est intégrée à OpenClaw. L’architecture de sécurité doit être assemblée soi-même.
Commencer en interne, puis élargir
L’architecture prête pour la production pour le reporting multi-clients nécessite un travail d’ingénierie significatif. Avant de l’appliquer aux sorties destinées aux clients, validez le workflow sur le reporting interne — les propres métriques de l’équipe, les données de ses propres projets, rien n’appartenant à un client.
L’usage interne fait remonter les cas limites (chiffres incorrects, problèmes de formatage, gestion des credentials en échec) avant qu’ils n’affectent les clients, calibre la confiance dans la précision des sorties de l’agent, et établit les pratiques de gestion des credentials nécessaires avant que les données clients soient impliquées. Un mois de reporting interne fiable fournit des preuves sur ce qui fonctionne réellement — la base pour décider si et quels clients inclure, compte tenu de la posture de sécurité actuelle.
Coût à l’échelle
Chaque rapport hebdomadaire consomme des tokens API pour l’appel au LLM. Un rapport qui tire de 2-3 sources de données et génère un résumé formaté coûte environ 0,50-2,00€ par exécution, selon la quantité de données traitées par l’agent et le modèle utilisé.
Pour cinq clients avec des rapports hebdomadaires, cela représente 10-40€/mois en coûts d’API. Pas prohibitif. À surveiller à mesure que les clients s’ajoutent, car les coûts s’accumulent plus vite que prévu si les clients commencent à demander des rapports supplémentaires (mises à jour quotidiennes, points d’étape en milieu de semaine).
Voir coût des outils IA pour consultants indépendants pour comment ces coûts par exécution s’inscrivent dans le budget global des outils IA pour une pratique de conseil en analytique.