Regroupez les coéquipiers en départements pour que la visibilité des projets et l'accès aux messageries partagées se limitent au groupe où ils travaillent réellement. Assistance, Ventes et Marketing cessent par défaut de lire les campagnes et les fils clients les uns des autres, les responsables de département peuvent inviter au sein de leur propre groupe sans passer par le propriétaire du compte à chaque fois, et une messagerie individuelle reste privée à moins que le propriétaire ne l'ouvre via une dérogation journalisée exigeant un motif.
Un compte MailInApp qui dépasse une poignée de personnes n'avait jusqu'ici qu'un seul modèle de visibilité : chaque éditeur ou lecteur actif voyait chaque projet et chaque messagerie partagée que le compte possédait. C'est très bien pour une petite équipe où tout le monde voit déjà tout de toute façon. Cela cesse d'être adapté dès que « équipe » désigne des groupes fonctionnels distincts — l'assistance qui traite les fils clients, les ventes qui mènent leurs propres campagnes, le marketing qui mène les siennes — sans aucune raison professionnelle réelle pour qu'un groupe parcoure celles de l'autre.
Les départements se superposent aux rôles existants
Un département ne remplace pas les rôles propriétaire/éditeur/lecteur — il délimite ce qu'un éditeur ou un lecteur qui en fait partie peut voir. Le propriétaire du compte crée des départements depuis Paramètres, affecte les coéquipiers à un ou plusieurs d'entre eux, et à partir de là un projet ou une messagerie partagée étiqueté avec un département n'est visible que pour les membres de ce département, plus le propriétaire. Un projet ou une messagerie sans département défini se comporte exactement comme avant : visible pour tout le compte.
Les responsables de département déchargent le propriétaire des invitations
Promouvoir un coéquipier au rôle de responsable pour son propre département lui permet d'y inviter directement de nouvelles personnes — une vraie délégation, pas seulement une étiquette. La portée d'un responsable s'arrête à la frontière de son département : il ne peut pas inviter dans un groupe qu'il ne dirige pas, ne peut toucher ni à la facturation ni aux identifiants, et ne peut pas générer un autre responsable. Tout ce qui reste déjà réservé au propriétaire — paramètres SMTP, Stripe Connect, clés API, secrets de webhook, la gestion de l'équipe elle-même — reste réservé au propriétaire, y compris pour un responsable.
Les messageries individuelles sont privées, pas impossibles à ouvrir
Une adresse entrante revendiquée comme support@ peut être partagée avec tout un département, ou réglée sur individuelle et affectée à une seule personne précise. Une messagerie individuelle utilise une adresse appartenant à l'entreprise pour une correspondance professionnelle ordinaire, donc un mur technique absolu échangerait une véritable continuité d'activité — la messagerie d'un employé parti devenant des données d'entreprise définitivement irrécupérables — contre une garantie de confidentialité que la loi n'exige pas réellement pour une correspondance de travail sur un domaine d'entreprise. À la place, le seul chemin du propriétaire vers la messagerie individuelle de quelqu'un d'autre est l'accès propriétaire : choisir la messagerie, donner un motif, puis la lire — jamais répondre au nom du titulaire. L'accès est journalisé, et ce journal reste ensuite visible pour le titulaire de la messagerie, pas caché.
Chacun voit ce que cela signifie avant d'accepter une invitation
Parce qu'un département change ce qu'un coéquipier peut voir, et parce qu'un accès propriétaire à une messagerie individuelle est possible, la page d'acceptation d'invitation affiche d'abord un court avis en langage clair avant que quiconque ne rejoigne : ce que son département rend visible, et le fait que l'accès propriétaire exige toujours un motif et est toujours journalisé. Il n'y a pas de flux de consentement séparé à configurer — accepter l'invitation revient à reconnaître cet avis.
Ce que cela ne change pas
Les permissions d'éditeur et de lecteur au sein d'un département restent exactement ce qu'elles étaient déjà — un éditeur délimité par département peut toujours construire, envoyer, et lire les réponses pour ce qu'il peut voir ; un lecteur délimité par département reste en lecture seule. Les limites de volume, les niveaux de forfait, et les règles de rotation des identifiants sont inchangés par tout cela — les départements sont une couche de visibilité, pas un nouvel axe de tarification ni un nouvel ensemble de permissions d'écriture.
Pour commencer
Créez des départements qui correspondent à la structure réelle de votre organisation depuis Paramètres → Équipe, affectez-y les coéquipiers, et étiquetez les nouveaux projets avec un département depuis le sélecteur de création. Voir Départements pour la référence complète, Collaboration d'équipe pour la façon dont les rôles et les invitations fonctionnent en dessous, et Messagerie entrante pour configurer les adresses partagées et individuelles que les départements délimitent.