Je savais ce dont les agences avaient besoin — alors j'ai construit le multi-tenant dès le Jour 2
Après 20 ans en agence, je savais que l'architecture multi-tenant ne pouvait pas attendre — alors dès le Jour 2, avec un seul agent IA fonctionnel, j'ai triplé ma complexité de développement pour éviter une réécriture future.
21 août 2025. Jour 2 de la construction de STRAŦUM.
J'étais assis à mon bureau avec un seul agent IA fonctionnel (Business Strategy), une authentification de base, et un modèle de données très simple. Le café qui refroidit. Je savais exactement pour qui je voulais construire : des PME qui avaient besoin d'aide en marketing IA, ET des agences qui pourraient l'utiliser sur plusieurs clients.
Les deux audiences. Dès le Jour 1.
Après 20 ans côté agence, je comprenais ce dont les agences ont réellement besoin — pas la version marketing brillante, mais la réalité désordonnée de gérer 10 à 15 clients avec des stratégies différentes, des chartes graphiques différentes, tout différent. Je savais aussi que les PME avaient désespérément besoin d'aide stratégique abordable.
Mais au Jour 2, à fixer mon modèle de données simple, j'ai réalisé quelque chose d'inconfortable : construire pour les deux audiences signifiait construire une architecture multi-tenant. Maintenant. Pas plus tard.
En fin de journée, je m'étais engagé dans une décision qui allait tripler ma complexité de développement et étendre mon calendrier de plusieurs semaines.
J'ai construit une architecture multi-tenant dès le Jour 2.
Était-ce ambitieux ou insensé ? Honnêtement, je n'étais pas sûr. Je ne suis toujours pas sûr à 100 %. Mais voici l'histoire de pourquoi cette décision — prise avec presque aucun produit fonctionnel — s'est avérée être l'un des choix techniques les plus importants que j'aie faits.
Pourquoi les deux audiences ? 20 ans d'expérience en agence
La vision n'a jamais été PME uniquement. Dès le départ, je voulais construire pour deux audiences distinctes :
PME (Petites entreprises, 1-30 employés) — Le Co-Fondateur Stratégique que tu peux te permettre :
- Ne peuvent pas se payer des agences marketing ou des consultants
- N'ont pas d'expertise en marketing stratégique
- Ont besoin de victoires rapides sans courbe d'apprentissage
Agences (gérant 5 à 15+ clients) — Développe ta capacité stratégique, pas tes effectifs :
- Noyées sous le travail de stratégie sur plusieurs clients
- Ont besoin de cadres cohérents qui s'adaptent à l'échelle
- Requièrent une isolation complète des données entre les clients
Pourquoi les agences ? Parce que j'ai passé 20 ans côté agence. Je connais la douleur de l'intérieur.
J'ai vu des stratèges jongler avec 12 clients et 12 chartes graphiques différentes, copier-coller du contexte entre les outils, en priant de ne pas accidentellement envoyer la mauvaise stratégie au mauvais client. J'ai regardé des agences perdre de bons collaborateurs à cause du burnout parce qu'il n'y a aucun moyen de faire évoluer la réflexion stratégique sans faire évoluer les effectifs.
Et honnêtement ? Je voulais me challenger. Construire uniquement pour les PME aurait été plus simple — un utilisateur, une organisation, un routage direct. Construire pour les agences signifiait des dashboards multi-clients, l'isolation des données, des permissions basées sur les rôles, tout scopé au client.
Je voulais construire quelque chose de complexe. Quelque chose qui résout vraiment les problèmes difficiles que j'avais vus pendant deux décennies.
La réalisation du Jour 2 : on ne peut pas retrofitter le multi-tenant
Voici ce que j'ai compris au Jour 2, en fixant mon modèle de données simple :
Architecture PME (ce que j'avais) :
```
users → campaigns → agent_outputs
```
Architecture multi-tenant (ce dont j'avais besoin pour les agences) :
```
organizations (SME or AGENCY)
↓
clients (agencies only)
↓
campaigns
↓
agent_outputs (with org_id AND client_id)
```
La différence n'est pas juste "ajouter quelques colonnes." C'est un modèle de données fondamentalement différent.
Si j'avais d'abord construit pour les PME et ajouté le support agence plus tard, je me serais retrouvé à :
- Migrer chaque table existante pour ajouter org_id
- Retrofitter les politiques RLS sur toute la base de données
- Réécrire le routage frontend pour le contexte client
- Re-tester tout avec des scénarios multi-tenant
Ce n'est pas un ajout de fonctionnalité. C'est une réécriture.
Plus j'attendais, plus le retrofit serait coûteux. Le Jour 2, c'était bon marché. Le Jour 60 aurait été douloureux. Le Jour 200, ça aurait été "peut-être qu'on construit juste un produit séparé pour les agences."
Alors j'ai tranché : construire le multi-tenant dès le Jour 2, ou accepter que les agences ne seraient jamais des citoyens de première classe.
Les compromis : ce que le multi-tenant coûte vraiment
Voici le moment où j'aurais dû faire une pause et me demander : "Tu es sûr de ça ? Tu as UN agent fonctionnel. UN."
Mais je n'ai pas fait de pause. À la place, j'ai commencé à écrire des schémas SQL comme un forcené. Le multi-tenant dès le Jour 2 signifiait accepter des coûts qui feraient reconsidérer n'importe quelle personne raisonnable :
Coût 1 : Complexité de développement (3X)
Chaque table avait besoin d'org_id. Les tables d'agence avaient besoin de client_id. Les politiques RLS avaient besoin des deux filtres. Chaque requête, chaque endpoint API, chaque route frontend — tous devaient être conscients du multi-tenant.
Augmentation estimée de la complexité : 3X le temps de développement pour les mêmes fonctionnalités.
(Spoiler : c'était en fait plus proche de 4X. J'ai sous-estimé. Classique :P)
Coût 2 : Calendrier de développement étendu
Construire pour les deux audiences dès le Jour 1 signifiait un chemin plus long vers le lancement. Voici à quoi ça ressemblait :
Calendrier :
- 20 août : Début de la construction (multi-tenant dès le Jour 1)
- 15 septembre : 4 semaines après, 3 agents fonctionnels, ciblant octobre
- Octobre : Tombé malade pendant 10 jours, impossible de coder
- 5 novembre : Lancement Private Alpha (75 jours au total)
Ce qu'a ajouté le multi-tenant :
- Routage de schéma entre les tables publiques et d'agence
- Politiques RLS sur chaque table (arrivé à 83 sur 26 tables)
- Propagation du contexte client à travers chaque agent
- Modèles de routage doubles (URLs PME vs agence)
Aurais-je lancé plus vite avec une architecture PME uniquement ? Probablement 3 à 4 semaines plus tôt. Mais ensuite je me serais retrouvé face à une réécriture quand les agences auraient frappé à la porte.
Coût 3 : Exigences de sécurité (risque plus élevé)
L'isolation des données pour les PME est le minimum syndical. L'isolation des données pour les agences est critique.
Exigences ajoutées :
- 83 politiques RLS sur 26 tables
- Isolation au niveau du schéma (schémas public vs agence)
- Fonctions de routage de base de données pour chaque opération CRUD
- Journalisation d'audit complète
- Option d'authentification multi-facteurs
Complexité de sécurité : 5X plus élevée que PME uniquement.
J'ai passé plus de temps sur les politiques Row-Level Security que sur le développement réel des agents IA certaines semaines. Laisse ça mariner.
Coût 4 : Complexité des tests (2X de cas de test)
Chaque fonctionnalité avait besoin d'être testée pour :
- ✅ Flux PME (plus simple)
- ✅ Flux agence (scopé au client)
- ✅ Isolation des données (Nike ≠ Adidas)
- ✅ Limites de permission (les agences peuvent-elles voir les données PME ? Non.)
Maintenance des tests : Doublée.
Tu sais ce qui est fun ? Écrire le même test deux fois avec des contextes légèrement différents. Dit personne jamais.
---
Pourquoi j'ai quand même fait ce compromis
Donc laisse-moi récapituler : 3X la complexité, calendrier étendu, 5X la surcharge de sécurité, tests doublés... et je l'ai quand même fait ?
Ouais. Voici le raisonnement (tel qu'il était) :
Raison 1 : Le retrofit, c'est un cauchemar
Jour 2 : Presque aucun code écrit. Modèle de données encore flexible. Aucun utilisateur à migrer.
Jour 60 : 45 tables, 200 000 lignes de code, 15 utilisateurs alpha. Ajouter le multi-tenant aurait nécessité de réécrire la moitié du codebase.
Leçon : Les décisions architecturales deviennent exponentiellement plus difficiles à changer avec le temps.
Coût au Jour 2 : ~5 heures pour reconcevoir le modèle de données.
Coût au Jour 60 : ~200 heures pour tout refactoriser.
J'ai vu des entreprises essayer de retrofitter le multi-tenant. C'est brutal. Tu es essentiellement en train de reconstruire l'avion en plein vol. Avec des passagers. Qui te paient.
Raison 2 : Je comprends vraiment les agences
Ce n'était pas une étude de marché théorique. J'ai passé 20 ans à regarder des agences se battre exactement avec ce problème.
Je sais qu'elles ont besoin :
- D'une isolation complète des données (le client 1 ne peut pas voir la stratégie du client 2)
- Que tout soit scopé au client (chartes graphiques, personas, campagnes)
- D'un accès basé sur les rôles (account managers vs stratèges)
- D'un potentiel white-label pour les présentations clients
Je pouvais construire ça correctement parce que j'avais vécu la douleur. C'est un avantage que je ne voulais pas gaspiller en livrant PME-uniquement et en "ajoutant les agences plus tard."
Raison 3 : Le défi était le but
Voici quelque chose que je dis rarement : je *voulais* la complexité.
Je suis un fondateur d'âge mûr avec une famille, pas un gamin de 22 ans qui peut survivre avec des energy drinks et sans sommeil. Si je vais passer un an à construire quelque chose, il vaut mieux que ce soit quelque chose qui me challenge. Quelque chose dont je suis techniquement fier.
Une architecture multi-tenant avec une isolation des données correcte, des politiques RLS, un routage de schéma — c'est difficile. C'est intéressant. C'est le genre de problème d'ingénierie qui me garde engagé.
Construire uniquement pour les PME aurait été plus rapide. Mais aurais-je été aussi motivé pour traverser les moments difficiles ? Probablement pas.
Raison 4 : Les deux audiences se rendent meilleures l'une l'autre
Les PME et les agences ne sont pas des cas d'usage concurrents. Ils sont complémentaires :
- Les agences valident le produit : Si les agences lui font confiance avec les données des clients, les PME le feront aussi
- Les PME fournissent le volume : Plus d'utilisateurs signifie plus de feedback, une itération plus rapide
- L'architecture sert les deux : Les comptes d'équipe, les permissions de rôles, et le white-label fonctionnent pour les deux audiences
Construire pour les deux signifiait construire la solution *complète*, pas une version simplifiée dont je dépasserais les capacités.
Raison 5 : Anticiper l'avenir
Même au-delà des agences, l'architecture multi-tenant a permis :
- Les comptes d'équipe (PME avec plusieurs utilisateurs)
- Les partenariats revendeurs
- Les opportunités white-label
- Les ventes entreprise (si on voulait jamais aller dans cette direction)
Valeur optionnelle : Le multi-tenant a débloqué des modèles business que je ne pouvais même pas envisager au Jour 2.
L'implémentation : à quoi ressemblaient les décisions architecturales du Jour 2
Voici ce que j'ai réellement construit le 21 août :
Schéma de base de données (décision centrale)
```sql
-- Organizations table (SME or AGENCY)
CREATE TABLE organizations (
id UUID PRIMARY KEY,
name TEXT,
type TEXT CHECK (type IN ('SME', 'AGENCY')), -- Critical distinction
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Clients table (agencies only)
CREATE TABLE clients (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Which agency owns this
company_name TEXT,
slug TEXT UNIQUE, -- For URL routing
created_at TIMESTAMPTZ DEFAULT NOW(),
-- Constraint: Only agencies can have clients
CONSTRAINT clients_agency_only CHECK (
(SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
)
);
-- Campaigns table (multi-tenant aware)
CREATE TABLE campaigns (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Always required
client_id UUID REFERENCES clients(id), -- Required for agencies, null for SMEs
name TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Agent outputs (multi-tenant + client-scoped)
CREATE TABLE agent_outputs (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id),
client_id UUID REFERENCES clients(id),
campaign_id UUID REFERENCES campaigns(id),
agent_type TEXT,
content JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
Décisions clés au Jour 2 :
- org_id sur chaque table (permet RLS)
- client_id nullable (les PME n'ont pas de clients)
- Discriminateur type sur les organizations (SME vs AGENCY)
- Contrainte : Seules les agences peuvent créer des clients
Row-Level Security (Planification du Jour 2)
```sql
-- RLS policy for campaigns (multi-tenant isolation)
CREATE POLICY campaigns_org_isolation ON campaigns
FOR ALL TO authenticated
USING (
org_id = get_user_org_id() AND
(client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
);
```
Cette politique garantit :
- ✅ Les utilisateurs voient uniquement les campagnes de leur organisation
- ✅ Les utilisateurs d'agence ne peuvent pas voir les campagnes des PME
- ✅ Les agences ne peuvent pas voir les clients des autres agences
Coût : 5 politiques RLS initiales écrites au Jour 2. Arrivé à 83 au lancement.
Routage URL (Multi-tenant dès le Jour 1)
```typescript
// Frontend routing structure (planned Day 2)
// SME routes (simple)
/campaigns/:campaignId
/agents/strategy/:campaignId
// Agency routes (client-scoped)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```
Cette structure d'URL a permis :
- ✅ Contexte client dans chaque URL (agences)
- ✅ Séparation claire entre les flux PME et Agence
- ✅ URLs bookmarkables et partageables
- ✅ Tracking analytics par client
Les résultats : est-ce que ça en valait la peine ?
Date de lancement : 5 novembre 2025 (75 jours depuis le début)
Surcharge de développement due au multi-tenant :
- Conception de schéma et migrations
- 83 politiques RLS sur 26 tables
- Fonctions de routage de base de données
- Modèles de routage doubles (URLs PME vs agence)
- Propagation du contexte client
Avec Claude Code et Gemini 2.5 Pro, le codage réel est allé plus vite qu'en solo. Mais déboguer des politiques RLS qui *devraient* fonctionner mais ne fonctionnent pas ? C'est quand même douloureux, peu importe l'assistance IA.
Ce que j'ai maintenant :
- Isolation complète des données entre les organisations
- Architecture prête pour les agences avec scoping client
- 83 politiques RLS sur 26 tables
- Routage au niveau du schéma (schémas public vs agence)
- Potentiel white-label intégré dès le Jour 1
- Un produit qui peut genuinement servir les PME et les agences
Est-ce que ça en valait la peine ?
Demande-moi dans 6 mois quand j'aurai de vrais clients qui paient de l'argent réel. Pour l'instant je suis en private alpha avec 15+ utilisateurs, j'apprends encore ce qui fonctionne et ce qui ne fonctionne pas.
Mais voici ce que je sais : j'ai l'architecture pour servir correctement les deux audiences. Si j'avais construit PME-uniquement et essayé d'ajouter les agences plus tard, je me retrouverais maintenant face à une réécriture de 3 mois. À la place, je me concentre sur le product-market fit, pas sur la dette architecturale.
Ça me semble être le bon compromis.
Le cadre : quand construire le multi-tenant tôt
Tous les produits n'ont pas besoin du multi-tenant dès le Jour 2. Utilise ce cadre :
Construis le multi-tenant tôt si :
✅ Le marché cible inclut des agences/revendeurs (valeur plus élevée par client)
✅ L'isolation des données est critique (exigences légales/de conformité)
✅ B2B avec des comptes d'équipe probables (modèle Slack, Figma)
✅ Des opportunités white-label existent (stratégie GTM revendeur)
✅ Les ventes entreprise sont possibles (besoin de multi-client dès le Jour 1)
Passe le multi-tenant tôt si :
❌ Produit B2C (utilisateurs individuels, pas de hiérarchie organisationnelle)
❌ Le MVP a besoin de vitesse (teste d'abord le product-market fit)
❌ Aucun cas d'usage équipe/agence (outils mono-joueur)
❌ Modèle de données simple (ajouter org_id plus tard est facile)
❌ Fondateurs solos qui apprennent (la complexité peut être trop importante)
Leçons apprises : construire pour ton expertise
1. La connaissance de l'audience devrait driver l'architecture
Ne conçois pas pour des utilisateurs hypothétiques. Conçois pour des utilisateurs que tu comprends vraiment.
Mon avantage : 20 ans d'expérience en agence signifiait que je savais exactement ce dont les agences avaient besoin — isolation des données, scoping client, accès basé sur les rôles.
Mauvaise approche : "Construisons d'abord pour les PME et ajoutons les agences plus tard quand on les comprendra"
Bonne approche : "Je comprends déjà les agences. Construisons pour elles maintenant pendant que c'est peu coûteux."
Si tu as une expertise profonde dans un segment de marché, utilise-la. Ne reporte pas à "plus simple d'abord."
2. La complexité précoce bat le refactoring tardif
Coût d'architecture au Jour 2 : 5 heures pour reconcevoir le modèle de données.
Coût d'architecture au Jour 60 : 200 heures pour tout refactoriser.
Différence de 40X.
Si tu es sûr à 80 % d'avoir besoin du multi-tenant, construis-le tôt. Plus tu attends, plus ça coûte cher.
3. Le défi technique peut être une motivation
Celle-ci est personnelle : je *voulais* construire quelque chose de difficile.
Une architecture multi-tenant avec des politiques RLS, un routage de schéma, et une isolation des données correcte — c'est intéressant d'un point de vue ingénierie. Ça m'a gardé engagé à travers les moments difficiles.
Si tu es un fondateur solo, ne sous-estime pas la motivation. Construire quelque chose qui te challenge peut valoir plus que de livrer plus vite.
4. L'architecture permet des modèles business
Le multi-tenant n'était pas juste une décision technique. Il a permis :
- Des niveaux de prix pour les agences (quand je figurerai les prix)
- Des opportunités white-label
- Un potentiel de ventes entreprise
- Des comptes d'équipe pour les PME
Architecture = optionnalité business sous forme de code.
5. Les fondateurs solos peuvent construire du multi-tenant
"Le multi-tenant est trop complexe pour une seule personne" → Faux.
Avec les outils modernes (Supabase RLS, fonctions de base de données, développement assisté par IA), les fondateurs solos peuvent construire du multi-tenant de niveau entreprise.
Coût en temps : 70 jours (à temps partiel).
Ce que tu obtiens : Une vraie isolation des données, pas un hack que tu regretteras plus tard.
Ça en vaut la peine si tu es sérieux à propos de servir les deux audiences
Réflexions finales
Le Jour 2, il était bien trop tôt pour savoir si STRAŦUM réussirait. J'avais un agent. Aucun utilisateur. Aucune validation. Juste 20 ans d'expérience en agence me disant ce dont les agences ont réellement besoin.
Le calendrier étendu était parfois douloureux. Regarder d'autres lancements pendant que je débogais encore des politiques RLS et écrivais des fonctions de routage de base de données ? Frustrant ne commence pas à le couvrir. Il y avait des jours où je me demandais si la complexité en valait la peine.
Mais voici ce que je sais maintenant : construire pour les deux audiences dès le Jour 1 était la bonne décision. Pas parce qu'un calcul d'économie d'unité astucieux — je ne sais toujours pas quel pricing fonctionnera. Mais parce que j'ai l'architecture pour servir correctement les deux audiences.
Le multi-tenant dès le Jour 2 n'était pas juste une décision technique. C'était un pari sur la construction pour des utilisateurs que je comprends vraiment, pas des utilisateurs hypothétiques que j'aurais compris plus tard.
Ce pari a-t-il payé ?
Je suis encore en Private Alpha avec 15+ utilisateurs. Je n'ai pas encore la réponse. Mais je peux te dire ceci : quand une agence contacte et demande "peut-on utiliser ça pour plusieurs clients avec une vraie isolation des données ?" je peux dire oui. Je n'ai pas à dire "on travaille dessus."
Ça me semble être la bonne fondation.
Le temps dira si j'étais ambitieux ou juste entêté. (Probablement un peu des deux, honnêtement.) :)
Tu as déjà fait un pari architectural tôt qui semblait trop ambitieux à l'époque — et est-ce que ça a payé ? J'adorerais entendre ton histoire.
Cordialement, Chandler
La série architecture STRAŦUM : Cette décision du Jour 2 n'était que le début. Au Jour 67, j'ai dû reconstruire toute la couche multi-tenant quand un audit de sécurité a révélé des failles architecturales. Puis sont arrivés 31 écrans blancs à cause d'un contexte de navigation perdu, et une découverte que ma base de données était techniquement correcte mais 296x trop lente.
---
Tu construis un SaaS multi-tenant ? L'architecture de STRAŦUM supporte les clients PME et Agence dès le Jour 1. Demande l'accès alpha sur https://stratum.chandlernguyen.com/request-invitation
---
Apprenant encore que les décisions architecturales sont des décisions business déguisées. Déboguant encore des politiques RLS. Remettant encore en question mes décisions du Jour 2 (mais moins maintenant). Plus d'aventures de construction sur https://www.chandlernguyen.com/.
---
