Un agent, douze clients : ne jamais mélanger les marques, les comptes et les liens

Comment une agence fait tourner un seul agent IA pour de nombreux clients dans Shager : un espace par client, un dossier de contexte et des garde-fous.

Par Yaniv PreslerFondateur de ShagerAgences et clients29 septembre 20267 min de lecture

Un seul agent peut servir de nombreux clients sans risque, à trois conditions : chaque client a son propre espace de travail Shager, chaque tâche commence par identifier l'espace et le nommer, et le ton, les faits et les règles du client vivent dans un dossier de contexte distinct que l'agent charge à chaque session. Le danger ne vient pas d'un manque de compétence de l'agent. Il vient du fait qu'une même clé voit tous les espaces de l'organisation : la séparation doit donc reposer sur la structure et sur les habitudes.

L'erreur que tout le monde redoute, c'est de publier l'offre du client A sur les pages du client B. Elle n'a rien de propre aux agents : les opérateurs humains la commettent aussi. Les parades ci-dessous l'interceptent dans les deux cas.

Pourquoi un espace de travail par client ?

Dans Shager, un espace de travail correspond à un client ou à une marque. Chaque compte connecté, chaque groupe de comptes, chaque publication et chaque lien suivi appartient à un seul espace. Rien ne franchit la frontière par accident : un appel create_post désigne un seul workspace_id, et les canaux et groupes ciblés proviennent des listes propres à cet espace.

Il suffit d'un appel pour en créer un. Les champs sont name, un timezone IANA (par défaut Asia/Jerusalem) et approval_required, qui impose la validation du client avant que quoi que ce soit dans cet espace puisse être programmé.

{
  "tool": "create_workspace",
  "arguments": {
    "name": "Aurora Furniture",
    "timezone": "Europe/London",
    "approval_required": true
  }
}

Régler approval_required client par client, c'est le bon niveau de finesse. Certains clients veulent voir chaque publication. D'autres ont validé un plan éditorial et ne veulent pas recevoir vingt e-mails de validation par semaine. L'agent n'a pas à retenir qui est qui : l'espace de travail s'en charge.

Un agent dans un environnement de test non revendiqué peut créer jusqu'à cinq espaces de travail, de quoi lancer un pilote avec quelques clients avant qu'une personne revendique l'organisation. Le parcours est décrit dans l'inscription autonome d'un agent et la revendication.

Schéma : l'agence crée un lien, le client se connecte à son propre Facebook ou Google et choisit ses pages, et les comptes apparaissent dans l'espace de l'agence sans aucun mot de passe. — Ni mot de passe ni compte Shager. Le client connecte, l'agence publie.

Connecter les comptes de chaque client sans mot de passe

Pour chaque espace, l'agent appelle create_connect_link avec un label qui indique à qui le lien est destiné. Le client ouvre le lien, se connecte lui-même au réseau (Facebook, Instagram, YouTube, X, LinkedIn ou TikTok), choisit ses comptes, et ceux-ci apparaissent dans list_channels pour cet espace uniquement. Pas de compte Shager pour le client, pas de mot de passe partagé.

curl -s https://app.shager.ai/api/v1/workspaces/ws_aurora/connect-links \
  -H "Authorization: Bearer $SHAGER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label":"Aurora marketing manager"}'

Les liens de connexion nécessitent une organisation revendiquée. L'article sur les liens de connexion client détaille ce que voit le client et ce qu'il faut lui envoyer avec le lien.

Le dossier de contexte : la mémoire de chaque client

L'espace de travail sépare les données. Il ne sépare pas les connaissances. Ce que l'agent sait du ton d'Aurora, de ses prix et des formules à proscrire doit bien être stocké quelque part, et si tout tient dans un long fichier d'instructions qui mélange douze clients, ça finira par fuiter.

Voici ma structure, pour Claude Code ou Codex :

agency/
  CLAUDE.md                 # agency-wide hard rules, no client facts
  clients/
    aurora/
      CLAUDE.md             # workspace name, voice, facts, do-not-say list
      brief-2026-w40.md
      crm/leads.csv
    beacon-dental/
      CLAUDE.md
      ...

Claude Code charge les fichiers CLAUDE.md de façon hiérarchique, et ceux des sous-dossiers sont chargés quand Claude travaille dans ces dossiers, comme l'explique sa documentation sur la mémoire. Lancer une session dans clients/aurora/ donne à l'agent les règles de l'agence et le fichier d'Aurora, et rien sur Beacon Dental. Codex fonctionne de manière comparable avec AGENTS.md, dont les fichiers sont concaténés depuis la racine du projet jusqu'au dossier de travail.

La première ligne de chaque fichier client est la plus importante :

Shager workspace: "Aurora Furniture". Act on this workspace only. If any tool
call would use a different workspace_id, stop and ask.

Les garde-fous contre la publication croisée

La structure réduit le risque. Ces habitudes comblent le reste.

Identifier et annoncer. Chaque tâche commence par list_workspaces, retrouve le client par son nom et affiche le nom et l'ID avant la première écriture. Une personne qui parcourt la transcription voit « Aurora Furniture (ws_aurora) » et peut tout arrêter.
Un client par session. Ne demandez pas à un agent de « faire la semaine d'Aurora et de Beacon ». Deux sessions, deux dossiers. Le surcoût est nul et le contexte reste propre.
Des libellés avec le nom du client. Chaque create_post porte un label du type « Aurora w40 sofa sale ». Dans list_posts comme dans le tableau de bord, un mauvais libellé dans le mauvais espace saute aux yeux.
Une campagne par client. Le champ campaign devient utm_campaign. Préfixez-le avec l'identifiant du client (aurora-sofa-sale) : une publication égarée apparaîtra aussi comme une ligne incongrue dans les statistiques du client.
Une relecture séparée. Une session de relecture, avec des outils en lecture seule, vérifie les brouillons par rapport à la liste des formules interdites du client avant toute validation. Le prompt se trouve dans les prompts pour un agent de contenu.

Schéma : trois niveaux de droits pour la clé d'un agent (read, write et publish), chaque action étant consignée dans le journal d'audit. — Donnez à l'agent uniquement ce dont il a besoin, et voyez tout ce qu'il fait.

Faut-il une clé API par client ?

Dans Shager, les clés appartiennent à l'organisation et portent des portées : read, write et publish. Une clé ne limite pas les espaces auxquels elle accède. Une clé par client ne crée donc pas de cloison étanche, mais elle aide de deux façons. Révoquer une clé n'interrompt pas le travail sur les autres, et le journal d'audit des appels d'agents, dans le tableau de bord des agents, se lit bien plus facilement quand les sessions de chaque client tournent avec leur propre clé.

Ce que je ne ferais pas, c'est donner par défaut une clé publish à chaque session client. La plupart des sessions rédigent des brouillons. L'étape de programmation peut tourner avec une autre clé, contrôlée par une personne. Le modèle de portées est expliqué dans clés API, portées et audit.

Des groupes à l'intérieur d'un client

Dans un espace de travail, les groupes de comptes permettent à l'agent de cibler un ensemble de comptes en un seul champ. Un client en franchise peut avoir des groupes par région, par langue ou par format de magasin. create_group prend un name et des channel_ids ; create_post accepte des group_ids et ajoute tous les canaux actifs de ces groupes. Comme tout le reste, les groupes appartiennent à un espace : l'agent doit donc toujours les lister dans l'espace du client plutôt que de réutiliser des ID de mémoire.

Capacité et formules

Les formules Shager sont tarifées selon le nombre de comptes connectés dans toute l'organisation, avec l'API, l'accès MCP et des utilisateurs illimités dans chaque formule. Pour une agence qui gère une douzaine de clients, c'est le nombre de comptes qu'il faut surveiller, pas le nombre d'agents ou de sièges. Les paliers figurent sur la page des tarifs.

FAQ

Deux agents peuvent-ils travailler sur le même client en même temps ?

Techniquement, oui. Les deux voient le même espace et peuvent tous deux créer des brouillons. En pratique, attribuez à chacun un rôle clair : l'un rédige, l'autre relit, ou l'un s'occupe des vidéos et l'autre des publications texte. Deux agents qui rédigent la même semaine produiront des doublons.

Et si le client gère aussi ses propres publications dans Shager ?

Il peut être ajouté comme utilisateur dans votre organisation, puisque chaque formule inclut des utilisateurs illimités. Veillez à ce que l'agent appelle list_posts avant de rédiger, pour voir ce que le client a déjà programmé et ne pas empiler les publications le même jour.

Comment se séparer d'un client ?

Arrêtez le travail de l'agent dans cet espace, annulez les publications programmées avec cancel_post et demandez au client de déconnecter ses comptes. Archivez le dossier de contexte en dehors du dossier de travail de l'agent, pour qu'il ne soit pas chargé par erreur plus tard.

Pour aller plus loin

Mettez en place la structure de dossiers dès maintenant, même avec deux clients. Séparer après coup les connaissances de douze clients est bien plus difficile que de partir sur des bases saines. Le point d'entrée pour les agents réunit les informations de connexion dont vous aurez besoin pour chaque client.