Les Équipes Marketing Travaillent Ensemble. STRATUM Aussi, Maintenant.

"Tu es encore en alpha. Pourquoi tu construis des fonctionnalités d'équipe ?"

Question légitime. J'ai moins de 50 utilisateurs. La plupart des fondateurs de SaaS seraient focalisés sur atteindre les 100 utilisateurs avant de penser aux équipes.

Mais voilà ce que j'ai réalisé en observant mes utilisateurs alpha : ils ne travaillaient pas seuls. La directrice marketing partageait des captures d'écran avec son CEO. Le propriétaire d'agence copiait-collait des outputs IA dans WhatsApp pour ses collègues. Le fondateur transférait des emails à sa femme.

Venant de 18 ans dans la publicité, ça n'aurait pas dû me surprendre. Le marketing n'est jamais une activité solo. J'ai regardé des étages entiers d'agences fonctionner à travers un mélange chaotique de fils Slack, de transferts d'emails et de demandes "tu peux me faire une capture d'écran de ça ?". C'est comme ça que les équipes collaborent vraiment — et c'est pénible. Alors quand j'ai vu les mêmes patterns apparaître dans mon alpha, j'ai su que je ne pouvais pas l'ignorer.

Alors j'ai construit la collaboration d'équipe. En alpha. Pendant que des fondateurs "plus malins" auraient attendu. :P

Voici ce que j'ai livré, pourquoi j'ai construit ça comme ça, et ce que j'ai appris en chemin :

1. Le bon accès pour tout le monde — 15 rôles conçus pour comme les équipes SME et Agence fonctionnent vraiment, avec une isolation au niveau client pour les agences

2. Travailler ensemble sans les allers-retours — Approbations, commentaires, tâches et notifications remplacent tes fils Slack "tu as vu mon message ?"

3. Les nouvelles recrues productives immédiatement — Inviter → assigner un rôle → elles travaillent. 30 secondes, pas 3 jours.

Voici ce qui a été livré, pourquoi ça compte pour ton équipe, et les décisions qui l'ont rendu possible.

---

Avant ces fonctionnalités, voici comment les équipes utilisaient STRATUM :

Option A : Partager les identifiants (cauchemar de sécurité)

- Tout le monde utilise le même login

- Impossible de savoir qui a fait quoi

- Une personne change le mot de passe, tout le monde est bloqué

Option B : Comptes séparés (coûteux et fragmenté)

- Chaque personne paie séparément

- Les outputs IA vivent dans des comptes différents

- "Tu peux exporter cette stratégie et me l'envoyer ?"

Option C : Capture d'écran et collage (la réalité)

- Une personne fait tourner les agents IA

- Capture d'écran ou copier-colle pour les coéquipiers

- Le contexte se perd, le formatage se casse, personne ne peut construire sur ce travail

Aucune de ces options n'est une vraie collaboration. Ce sont des contournements.

Le coût commercial ? J'ai regardé un propriétaire d'agence passer 20 minutes par jour juste à déplacer des outputs IA entre les outils — transférer des emails, reformater dans Google Docs, réexpliquer le contexte aux coéquipiers qui ne pouvaient pas voir la conversation originale.

C'est 80+ heures par an. Pour une personne. Sur une seule équipe.

---

Fonctionnalité 1 : Donner à tout le monde le bon accès — sans la galère IT

Après 18 ans côté agence, je sais exactement comment fonctionnent les équipes marketing : différentes personnes ont besoin d'accès différents à différentes choses.

Ton stratège senior travaille sur le Client A et le Client B. Ton analyste junior apprend sur des comptes plus petits. Ton créatif freelance ne touche que les clients qui lui sont assignés. Et absolument personne ne devrait voir les données client qu'il n'est pas censé voir.

Ce n'est pas une question de contrôle des coûts (même si ça compte aussi). C'est une question de comment les équipes fonctionnent vraiment.

Deux modèles de permissions : SME vs Agence

J'ai appris assez tôt qu'une startup de 3 personnes et une agence de 15 personnes ont des workflows complètement différents. Essayer de les forcer dans un seul modèle de permissions aurait été un désastre — j'ai vu des outils enterprise faire ça, et ça se termine toujours avec de petites équipes noyées dans la complexité pendant que les grandes équipes n'ont pas assez de contrôle. J'ai donc construit deux modèles distincts.

Rôles SME (5 rôles)

Pour les petites et moyennes entreprises avec des hiérarchies plus simples :

|------|-------------|-----------------|-----------------|

Pourquoi ces cinq ? J'ai cartographié les vrais rôles que j'ai vus dans les équipes marketing SME. Le Owner qui fait tout. Le Director qui définit la stratégie. Le Manager qui exécute. L'Analyst qui mesure. L'assistant ou la personne comptabilité qui a juste besoin de voir ce qui se passe.

Rôles Agence (10 rôles)

Pour les agences gérant plusieurs clients avec des structures d'équipe complexes :

|------|-------------|--------------|-----------------|

Les rôles scopés par client

sont la révolution pour les agences. Quand tu assigne un Account Manager au Client A, il ne peut littéralement pas voir les données du Client B. Pas "caché dans l'UI" — appliqué au niveau de la base de données.

Gestion des Assignations Client

Pour les équipes agence, la page Team Management affiche maintenant une colonne Accès Client qui te montre en un coup d'œil à quels clients chaque membre d'équipe peut accéder. Clique sur le menu actions d'un membre pour :

- Accorder l'accès "Tous les Clients" : Les nouveaux clients leur deviennent automatiquement visibles

- Assigner des clients spécifiques : Choisis exactement quels clients ils doivent voir

- Mettre à jour les assignations à tout moment : Change l'accès au fur et à mesure que ton portefeuille client évolue

Ça signifie que ton Account Manager pour le Client A ne peut littéralement pas voir le tableau de bord, les campagnes ou les outputs IA du Client B — même s'il essaie. Le filtrage se fait au niveau de la base de données, pas juste dans l'UI.

Pour l'onboarding des nouveaux membres d'équipe : Quand tu invites quelqu'un, tu choisis son rôle ET son périmètre client dans le même flux. Pas d'étapes séparées. Plus d'oublis pour restreindre l'accès.

L'UI Consciente des Permissions

Voici ce qui rend ça vraiment utilisable : l'UI s'adapte à ton rôle.

Si tu ne peux pas inviter des membres d'équipe, tu ne vois pas les paramètres Équipe. Si tu ne peux pas accéder à un client, ce client n'apparaît pas dans ton tableau de bord. Si tu ne peux pas lancer un agent, il apparaît verrouillé avec un indicateur clair.

Plus de clics sur des options pour obtenir une erreur. Plus de confusion "pourquoi je peux voir ça mais rien en faire ?".

Pour les Directors Agence : Tes créatifs voient une interface propre et focalisée — uniquement leurs outils. Moins de formation, moins d'erreurs.

Pour les Fondateurs : Ton assistant en rôle viewer voit un tableau de bord simplifié. Il peut trouver et copier ce dont il a besoin sans être submergé.

37 Permissions Granulaires (que tu n'auras jamais à configurer)

Derrière ces rôles se trouvent 37 permissions individuelles — mais tu n'auras jamais à les configurer manuellement. Chaque rôle est pré-configuré en fonction de comment les équipes marketing fonctionnent vraiment :

| Catégorie | Pourquoi ça compte |

|----------|----------------|

| Agents IA (9) | Ton Creative ne peut pas accidentellement lancer l'agent Strategy sur le mauvais client |

| Campagnes (6) | Les Analysts peuvent voir les campagnes pour les reporter, mais ne peuvent pas accidentellement en archiver une |

| Clients (5) | Seuls les Owners et Admins peuvent ajouter de nouveaux clients — pas d'éparpillement de données accidentel |

| Analytics (3) | Tout le monde peut voir les stats de base ; seuls les analysts peuvent exporter les données brutes |

| Documents (3) | Protège les uploads sensibles — les assistants peuvent voir mais pas supprimer |

| Organisation (4) | Accès à la facturation limité aux Owners — plus de "qui a changé notre plan ?" |

| Équipe (3) | Les Managers ne peuvent pas inviter leurs amis sans l'approbation du Owner |

| Workspace (2) | Garde les workspaces organisés sans que tout le monde en crée de nouveaux |

| Admin (2) | Fonctions système réservées aux personnes qui savent ce qu'elles font |

Chaque rôle obtient exactement ce dont il a besoin pour faire son travail — ni plus, ni moins. Tu définis le rôle une fois ; les permissions suivent automatiquement.

---

Fonctionnalité 2 : Arrêter de courir après les captures d'écran et les fils Slack

C'est la fonctionnalité dans laquelle je suis le plus personnellement investi. Les permissions contrôlent qui peut faire quoi, mais la collaboration concerne comment les gens travaillent ensemble — et d'après mon expérience, c'est les allers-retours qui mangent vraiment ta journée. J'ai vécu ce problème pendant deux décennies côté agence :D

Campagnes & Outputs IA Partagés

L'ancien modèle : Tes campagnes. Tes outputs IA. Ton silo.

Le nouveau modèle : Collaboration scopée par organisation.

Quand ton stratège lance l'agent Persona, ce persona appartient à l'organisation — pas à son compte personnel. Maintenant ton copywriter peut :

- Voir le persona sans demander une capture d'écran

- Y faire référence quand il lance l'agent Content

- Construire dessus au lieu de repartir de zéro

Quand ton analyste génère une analyse concurrentielle, ton Marketing Director peut la réviser directement — pas via un PDF transféré.

Workflows d'Approbation

Le contenu n'est pas juste créé — il est relu et approuvé avant d'être publié.

|----------|-----------|-------------|----------|

Comment ça fonctionne :

1. Le Creative finit un contenu → clique sur "Demander une Approbation"

2. L'Account Manager reçoit une notification → révise en contexte

3. Approuve, rejette, ou demande des modifications avec des notes

4. Le Creative est notifié de la décision

5. Si des modifications sont demandées → réviser et resoumettre (suivi des rounds)

Plus de fils Slack qui demandent "tu as vu mon email sur le copy du Client A ?"

Commentaires & @Mentions

Discute du travail généré par IA directement sur l'output — pas dans des fils Slack qui se perdent.

- Commentaires threadés sur n'importe quelle campagne, output, ou persona

- @mentions qui notifient des membres d'équipe spécifiques

- Suivi de résolution pour savoir ce qui a été traité

- Scopé par client pour les agences — les freelancers ne voient que les commentaires sur leurs clients assignés

Assignation de Tâches

Pour les Marketing Directors SME : Arrête de suivre qui fait quoi dans des tableurs. Assigne la création de contenu, les révisions et les tâches de campagne directement depuis l'output — ton équipe voit sa file de travail, tu vois le statut.

Pour les Account Managers Agence : Garde les livrables client sur les rails. Assigne des tâches dans le périmètre de ton client, fixe les priorités et les délais, et sache instantanément quand quelque chose est bloqué.

Comment ça fonctionne :

- Types de tâches : Création de contenu, révision, analyse, configuration de campagne

- Niveaux de priorité : Faible, normale, haute, urgente

- Délais avec notifications d'approche de deadline

- Ressources liées : Les tâches se connectent à des campagnes ou outputs spécifiques — plus de "de quel document on parle ?"

- Suivi de statut : À faire → En cours → Révision → Terminé

La hiérarchie de rôles maintient la clarté — les Account Managers assignent dans leur périmètre client, les Directors peuvent assigner à leurs équipes, les Owners peuvent assigner à n'importe qui.

Notifications en Temps Réel : Ne Jamais Manquer Ce Qui Nécessite Ton Attention

Pour les Marketing Directors et Agency Owners occupés : Arrête de vérifier Slack toutes les 5 minutes en te demandant si quelqu'un a besoin de toi. STRATUM te dit exactement quand une action est requise :

- Quelqu'un demande ton approbation → tu le sais immédiatement

- Ta demande d'approbation est résolue → plus de "l'ont-ils vu ?"

- Tu es @mentionné dans un commentaire → les conversations pertinentes te trouvent

- Une tâche t'est assignée → elle apparaît dans ta file de travail

- Une date limite approche → tu es prévenu avant qu'il soit trop tard

Les notifications apparaissent en temps réel dans l'app, et se regroupent en digests email si tu les manques.

---

Fonctionnalité 3 : Nouvelles Recrues Productives en 30 Secondes, Pas 3 Jours

Avant : Un nouveau membre d'équipe ? Voici le processus :

1. Il s'inscrit séparément

2. Tu m'envoies un email pour l'ajouter manuellement à ton org

3. J'assigne son rôle dans la base de données

4. Il se connecte et... peut-être que ça marche ?

Maintenant :

1. Paramètres → Équipe → Inviter

2. Entrer l'email, choisir son rôle

3. Il clique sur le lien, crée un mot de passe

4. Il est dedans. Avec les bonnes permissions. Immédiatement.

Pourquoi 30 Secondes Comptent

Pour les Marketing Directors qui onboarde un nouvel analyste : il peut être productif le premier jour, pas le troisième.

Pour les propriétaires d'agence qui ajoutent un créatif freelance : pas de tickets IT, pas d'attente, pas de "je m'en occupe demain."

Pour les Fondateurs qui embarquent un assistant : donne-lui un accès en lecture dans le temps qu'il faut pour envoyer un message Slack.

Le Choix Technique Qui a Rendu Ça Possible

La plupart des plateformes utilisent des flux de confirmation email : invitation → email de confirmation → clic sur le lien → créer un mot de passe → autre confirmation → finalement se connecter.

J'ai sauté la confirmation redondante. Si tu as reçu l'email d'invitation, tu as déjà prouvé que tu possèdes cette adresse email. Pourquoi te faire le prouver deux fois ?

Le lien d'invitation est sécurisé, stocké sur nos serveurs (pas dans les paramètres URL où quelqu'un pourrait le falsifier), et expire dans 7 jours. Quand tu l'acceptes, tout se passe en une seule étape :

1. Ton compte est créé

2. Tu es ajouté à la bonne organisation

3. Tes permissions de rôle sont assignées

Si quelque chose échoue, rien n'est créé. Pas de comptes à moitié terminés. Pas de permissions manquantes. Pas de tickets de support "je les ai invités mais ils ne peuvent rien voir".

---

Défense en Profondeur : Comment j'ai Construit l'Isolation des Données

Je sais que cette section est peut-être plus technique que la plupart des lecteurs n'en ont besoin, mais je pense qu'il est important d'être transparent sur comment je pense à la sécurité — surtout pour les utilisateurs agence qui me font confiance avec les données de leurs clients. Je suis encore en private alpha, mais ça ne signifie pas que j'ai fait des compromis sur l'architecture. L'isolation des données a été construite dès le Jour 1 — pas ajoutée plus tard. Voici l'approche en couches :

Couche 1 : Application au Niveau Base de Données (Row Level Security)

Les permissions ne sont pas seulement vérifiées dans le code applicatif — elles sont appliquées par la base de données elle-même via la Row Level Security (RLS) de Postgres. Chaque requête filtre automatiquement par organisation. Ton analyste ne peut pas voir les données d'une autre org parce que la base de données ne les retournera pas — quelle que soit la demande de l'application.

Pour les rôles scopés par client, une seconde politique RLS filtre par clients assignés. Un Account Manager pour le Client A ne peut pas accéder aux données du Client B même s'il forge une requête API directe.

Couche 2 : Vérifications de Permissions au Niveau Application

L'UI respecte les mêmes règles de permissions. Si tu ne peux pas accéder à un client, il n'apparaît pas dans ton tableau de bord. Si tu ne peux pas lancer un agent, le bouton est désactivé. La navigation, les boutons et les pages vérifient tous la même source de permissions — pas d'incohérences où l'UI montre quelque chose que l'API rejette.

Couche 3 : Transactions Atomiques

Les opérations critiques comme l'acceptation d'invitation se produisent comme des transactions de base de données uniques. Créer un compte, ajouter à l'org, assigner un rôle, définir l'accès client — tout réussit ensemble ou tout échoue ensemble. Pas d'états à moitié terminés. Pas d'enregistrements orphelins.

Couche 4 : Secrets Côté Serveur

Les détails d'invitation (organisation, rôle, assignations client) sont stockés sur nos serveurs, référencés par un token sécurisé. L'URL d'invitation contient uniquement le token — falsifier ne donne pas un accès différent car les vraies permissions vivent dans notre base de données.

---

Transparence alpha : Nous avons construit ces couches délibérément, mais nous sommes une petite équipe et STRATUM évolue encore. Voir notre Politique de Confidentialité et nos Conditions d'Utilisation pour l'image complète de ce que nous pouvons et ne pouvons pas garantir pendant l'alpha.

---

Pourquoi Construire Ça en Alpha ?

Voici la réponse honnête : parce que retrofitter des fonctionnalités d'équipe, c'est brutal.

J'ai vu des entreprises essayer d'ajouter la multi-location après le lancement. C'est un cauchemar. Chaque table a besoin de nouvelles colonnes. Chaque requête a besoin de nouveaux filtres. Chaque vérification de permission doit être réécrite. Les migrations de données sont terrifiantes.

J'ai construit STRATUM avec des données scopées par organisation dès le Jour 2 (c'est une histoire pour un autre article). L'architecture était prête pour les équipes. Les fonctionnalités avaient juste besoin d'être... construites.

Construire des fonctionnalités d'équipe avec 50 utilisateurs signifie :

- Itération rapide : Je peux livrer, obtenir des retours, et corriger en jours, pas en mois

- Patterns d'usage réels : Je vois comment les équipes collaborent vraiment, pas comment j'imaginais qu'elles le feraient

- Pas de risque de migration : Pas de workflows d'équipe existants à casser

L'alternative — attendre d'avoir 1 000 utilisateurs puis dire "surprise, tu dois maintenant restructurer tout ton workflow pour les équipes" — semblait pire.

Essaie Maintenant

Les fonctionnalités d'équipe sont en ligne pour tous les utilisateurs STRATUM.

Si tu es un utilisateur existant :

1. Va dans Paramètres → Équipe

2. Clique sur "Inviter un Membre d'Équipe"

3. Regarde-les s'onboarder en 30 secondes

Si tu es nouveau :

Demande un accès alpha sur stratum.chandlernguyen.com. Mentionne "collaboration d'équipe" dans ta demande — je suis encore dans la phase "parler à chaque utilisateur", et j'adorerais te montrer comment ces fonctionnalités correspondent à ton équipe.

---

Le Pari Non Conventionnel

Construire des fonctionnalités d'équipe en alpha est non conventionnel. La plupart des conseils disent : obtiens d'abord des utilisateurs, ajoute la collaboration plus tard.

Mais les équipes, c'est comme le marketing fonctionne vraiment. La Marketing Director ne crée pas de stratégies seule. L'Agency Owner ne gère pas les comptes clients en solo. La collaboration n'est pas une fonctionnalité sympa à avoir — c'est comme le travail se fait.

Construire pour les équipes dès le début signifie que STRATUM grandit avec toi. Commence seul, invite ton premier coéquipier quand tu es prêt, monte en puissance vers une équipe d'agence complète sans changer de plateforme.

Ce pari pourrait être faux. Mais regarder mes utilisateurs alpha faire des captures d'écran et copier-coller pour contourner l'absence de partage... je ne pense pas que ce soit le cas.

Au bout du compte, construire des produits, c'est résoudre de vrais problèmes pour de vraies personnes — pas suivre un manuel qui dit "attends d'avoir 1 000 utilisateurs." Je préfère construire ce dont mes 50 utilisateurs ont vraiment besoin maintenant que courir après un chiffre sur un graphique de croissance.

Si tu gères une équipe marketing (ou une agence), j'adorerais sincèrement entendre comment tu gères la collaboration aujourd'hui. Tu es dans le camp "capture d'écran et coller" ? Le camp "partager un login" ? Quelque chose de mieux ? Dis-le-moi — j'apprends encore et chaque conversation m'aide à mieux construire cette chose.

Cordialement, Chandler

Je construis aussi DIALØGUE — si tu es curieux de voir ce qui se passe quand j'applique la même pensée "construire pour les équipes tôt" à la génération de podcasts IA, jette un œil.

Les Équipes Marketing Travaillent Ensemble. STRATUM Aussi, Maintenant.

Fonctionnalité 1 : Donner à tout le monde le bon accès — sans la galère IT