Tous les articles

Claude Code pour les équipes, ce qui change quand les agents deviennent multi-tenant

Ton agent tourne nickel avec un seul utilisateur. Le jour où il en a dix mille, tu te retrouves à construire des orgs, des rôles, de l'audit, des quotas, de l'impersonation et des webhooks. Voici la liste de ce qu'il te faut, et le pattern qu'on a piqué à Stripe pour le faire correctement.

Appstrate
multi-tenantéquipesapi

👤 Ton agent a un utilisateur. Maintenant il en a dix mille.

Claude Code, Cursor, OpenClaw, Antigravity : les agents de code autonomes de 2025 et 2026 sont devenus très bons, très vite. La forme du produit reste la même : un dev, un laptop, un agent. Les credentials, ce sont ceux du dev. Le filesystem, c'est celui du dev. Les logs atterrissent dans son terminal.

Cette forme tient tant que l'agent a exactement un utilisateur. À la minute où tu décides de livrer cette capacité à une vraie équipe (la tienne via un outil interne partagé, ou tes utilisateurs qui embarquent un agent dans un SaaS que tu opères) tu découvres un second produit planqué dans le premier.

Ce second produit, c'est organisations, rôles, invitations, quotas, logs d'audit, impersonation, clés API, idempotence, webhooks, versioning, et quelques autres trucs. Stripe a mis une décennie à bien faire sa version de ce produit. Il y a de bonnes chances que tu n'aies pas envie de tout reconstruire.

Cet article parle de ce qui change quand un agent passe d'« un utilisateur » à « plein d'utilisateurs », et des patterns qui rendent la transition survivable.

📐 Les sept trucs que tu construiras (et que tu ne devrais sans doute pas construire)

L'écart entre un agent perso et un agent d'équipe, c'est une série de features qui semblent optionnelles jusqu'à ce qu'elles ne le soient plus. Voici la liste, dans l'ordre où tu regretteras de ne pas les avoir.

1. Organisations et membership

À la seconde où deux personnes partagent un agent, il existe une organisation implicite autour. Quelqu'un est owner. Quelqu'un est admin. Quelqu'un est membre. Quelqu'un doit être retiré quand il part. Quelqu'un doit être invité, avec un email, via un lien qui expire, sur un rôle donné.

Tu écriras cette couche. Deux semaines de boulot.

2. Rôles et permissions, les vrais

Trois rôles (owner / admin / member) : c'est le minimum qui survit au contact des utilisateurs. Ça ne suffit pas pour une plateforme. Le vrai RBAC croise des verbes (read, write, delete, invite, billing) avec des ressources (agents, runs, models, webhooks, api_keys, connections). Tu finis avec trente à cent combinaisons de permissions.

Chez Appstrate, on a atterri à 78. C'est pas de la coquetterie de design : c'est le chiffre qu'il te faut si tu ne veux pas que le premier évaluateur enterprise éclate de rire devant ta démo.

3. Clés API scopées, pas bearer-to-root

Une seule clé API qui fait tout : pratique le jour 1, incident de sécurité le jour 300. Les vraies clés API sont scopées (cette clé peut lire les runs mais pas créer d'agents), attribuables (qui l'a créée, quand, dernière utilisation), révocables sur le champ et rate-limitées par clé.

Elles ont aussi besoin d'un préfixe sensé (ask_ dans le cas d'Appstrate) pour que ton outillage de détection puisse les grep dans les repos publics.

4. Logs d'audit côté trusted

Quand un utilisateur d'un utilisateur de ta plateforme exfiltre des données, les logs du processus agent ne sont pas recevables. Il te faut un audit trail côté plateforme, écrit par le runtime, pas par quoi que ce soit que l'agent puisse influencer. Qui a lancé quoi, pour le compte de qui, à quelle heure, depuis quelle IP, avec quel résultat. Stocké assez longtemps pour que la conformité valide.

5. Quotas, rate limits et kill switch

Un utilisateur peut lancer un agent autant de fois qu'il veut sur sa propre machine. Sur une plateforme partagée, ça devient une facture et un vecteur de DoS. Il te faut des plafonds de concurrence par org, des rate limits à la minute, des budgets journaliers plafonnés et un kill switch pour couper les runs en cours quand quelque chose part en vrille.

Celui qui prend les équipes de court : un kill switch global pour « coupe tous les runs de la plateforme, partout, maintenant », parce qu'un jour tu déploieras une mauvaise version d'agent et tu en auras besoin.

6. Impersonation pour le support

Ton premier ticket de support sera « mon agent a pas marché » et tu ne pourras pas le reproduire sans devenir cet utilisateur pendant cinq minutes. Tout système multi-tenant mature a de l'impersonation. Ceux qui la font bien ont un audit trail sur l'impersonation elle-même : qui a impersonné qui, quand, combien de temps.

7. Webhooks, idempotence, versioning

Tout ce qui est long et multi-tenant a besoin d'un mécanisme de callback async. Tout ce qui fait des retries a besoin de clés d'idempotence, sinon les actions dupliquées deviennent la norme. Tout ce qui expose une API publique a besoin d'une stratégie de versioning pour que les breaking changes ne cassent pas les consommateurs.

Rien de tout ça n'est optionnel si tu veux tourner en prod. Et tout est pénible à faire correctement.

🎭 Dashboard users vs end-users, la distinction Stripe

Voilà la partie subtile. Quand tu rends ton agent multi-tenant, tu dois gérer deux types d'utilisateurs, et les confondre est la cause numéro un de plateforme cassée.

Les dashboard users, ce sont tes utilisateurs. Ton équipe. Les devs et les admins qui se connectent directement à la plateforme, configurent les agents, regardent les logs, gèrent les clés API. Ils ont des mots de passe. Ils ont la 2FA. Ils voient une UI. Ils appartiennent à des orgs.

Les end-users, ce sont les utilisateurs du truc que tu as construit sur la plateforme. Ils ne se connectent jamais à ton dashboard d'agents. Ils vivent dans ton produit. Leur nom est dans ta table de clients. Ils portent un externalId que tu leur as assigné. Ils connectent leur propre Gmail, leur propre Notion, leur propre GitHub aux agents qui tournent pour leur compte.

Stripe a pigé ça tôt. User dans le dashboard, c'est une personne de ton équipe. Customer, c'est une personne qui te paie. Deux tables, deux modèles, deux cycles de vie, deux jeux de règles. La même séparation doit exister dans une plateforme d'agents :

┌──────────────────────────────────────────────────────────────┐
│ Organisation (ton entreprise)                                │
│                                                              │
│   Dashboard users ──── les personnes de ton équipe           │
│   ────────────────     mot de passe, rôle, login dashboard   │
│                                                              │
│   Application ──────── un produit que tu expédies            │
│   ────────────────     ton SaaS, ton outil interne           │
│                                                              │
│       End-users ──── les utilisateurs de ton produit         │
│       ─────────────  externalId, metadata, leurs credentials │
│                      leurs runs, leurs webhooks              │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Sans cette séparation, tu finis avec un de ces deux scénarios pourris. Soit les end-users voient des données dashboard (une fuite), soit les dashboard users héritent des contraintes end-user et ton système de rôles s'effondre sous son propre poids.

Dans Appstrate, les dashboard users vivent dans la table users, les end-users dans end_users, et les clés API qui créent des runs end-user portent un header Appstrate-User: eu_…, la même forme que le header Stripe-Account de Stripe, pour exactement la même raison.

🎛️ L'impersonation, faite proprement

Le pattern est le même que pour le reste : piquer aux systèmes de paiement, ne rien réinventer.

POST /api/runs
Authorization: Bearer ask_live_…
Appstrate-User: eu_01HZXY…
Idempotency-Key: run-2026-03-28-abc123
Content-Type: application/json

{ "agentId": "agent_inbox_triage", "input": { … } }

Quatre points à retenir dans cette requête, parce que chacun correspond à une leçon qu'on a apprise en se plantant la première fois :

  • Appstrate-User est rejeté sur l'auth par cookie. Les sessions dashboard ne peuvent pas impersonner : seule l'auth par clé API le peut, et l'application liée à la clé doit correspondre à celle de l'end-user. Ça empêche l'erreur de support la plus classique (« j'avais oublié sur quel user j'étais connecté ») de virer à l'incident.
  • Idempotency-Key rend les retries safe. La plateforme stocke la réponse pendant 24 h. Une clé dupliquée avec un body identique renvoie le résultat en cache ; une clé dupliquée avec un body différent renvoie un 422. C'est comme ça que tu lances un agent depuis un cron qui retry sans double-facturer.
  • Le run hérite des connexions de l'end-user, pas du dashboard user. Quand l'agent appelle Gmail via le broker, il utilise le token de eu_01HZXY, pas le tien. C'est le câblage le plus important : pour qui l'agent agit-il, là, maintenant ?
  • Chaque impersonation émet un enregistrement d'audit : l'ID de requête, l'ID de clé API, l'ID de l'end-user impersonné, l'IP, le user agent. Le log vit sur la plateforme, pas dans le processus agent.

Tu peux construire tout ça en un trimestre. Tu ne devrais pas. Ou plutôt : tu devrais, mais seulement les morceaux spécifiques à ton produit. La plomberie multi-tenant reste la même pour chaque équipe qui construit sur des agents.

🧱 À quoi ressemble vraiment « Claude Code pour les équipes »

L'expression est un raccourci. Ce n'est pas un port littéral de Claude Code : c'est un pattern.

Un agent de code mono-utilisateur, c'est une personnalité. Un agent d'équipe, c'est une plateforme autour de cette personnalité. Tu obtiens :

  • Le même prompt qui marchait sur ton laptop, qui tourne pour tes coéquipiers.
  • Le même agent package (prompt + schema + skills + tools), versionné et installable sur plusieurs applications.
  • Des rôles qui reflètent qui a le droit d'exécuter quoi.
  • Des rate limits pour qu'un utilisateur ne bouffe pas le budget de l'org.
  • Des logs d'audit pour que ta revue sécurité passe.
  • Des clés API pour que ta CI puisse déclencher des runs.
  • Des webhooks pour que ton produit réagisse à la fin des runs.
  • De l'impersonation pour que ton support puisse reproduire le bug.

Un agent d'équipe, ce n'est pas un meilleur Claude Code. C'est Claude Code emballé dans une centaine de morceaux d'infra chiants dont chaque produit multi-tenant finit par avoir besoin. La raison d'être d'une runtime platform : livrer ces cent morceaux une bonne fois, correctement, et laisser les auteurs d'agents se concentrer sur le prompt.

📚 Liens

Autres articles

Documentation Appstrate