Gouvernance

Une organisation correspond à une instance Mankomail. Ses administrateurs décident de ce que les membres peuvent faire — quels nœuds ils peuvent utiliser, quels expéditeurs n’entrent jamais dans les workflows, si un mail peut seulement quitter l’instance — et détiennent les secrets que les membres ne voient jamais : applications OAuth, clés des fournisseurs d’IA, clés d’API. Cette page recense chaque contrôle, où il se trouve et ce qu’il change.

Les rôles

Il existe deux rôles :

Rôle	Affiché	Peut
member	Membre	connecter ses propres boîtes, construire et publier ses propres workflows, modifier son carnet, son périmètre et ses réglages
admin	Administrateur	tout ce que peut un membre, plus la page Administration et les sections de Connexions réservées aux administrateurs

Un administrateur est un membre doté de droits supplémentaires, pas un autre type de compte : il peut connecter des boîtes et construire des workflows comme tout le monde, ou gérer l’organisation sans aucune boîte. Les boîtes, workflows et exécutions de chaque membre lui appartiennent ; les écrans d’administration montrent des compteurs (boîtes, workflows publiés), pas le contenu des autres membres.

La page Administration

Onglet	Ce qu’il contrôle
Membres	les comptes, les rôles, les invitations, la désactivation
Périmètre	les règles de l’organisation : les expéditeurs qui n’entrent jamais dans les workflows, pour tout le monde (Périmètre)
Nœuds	les nœuds que les membres peuvent utiliser (voir « Politique de nœuds » ci-dessous)
Applications OAuth	les applications Google et Microsoft de l’organisation, nécessaires pour connecter des boîtes et les services Google ou Microsoft
Clés d’API	les clés qui permettent à des systèmes extérieurs d’appeler l’API
Calendrier ouvré	ce que « jour ouvré » veut dire pour toute l’organisation : jours travaillés, heures d’ouverture, jours fériés et fermetures, utilisés par les attentes et les échéances comptées en temps ouvré
Envois	le coupe-circuit d’envoi et le plafond horaire

Les fournisseurs d’IA, leurs modèles et leurs coûts se gèrent sur la page Connexions, dans des sections que seuls les administrateurs voient (voir « Les modèles d’IA et leurs coûts » ci-dessous).

Membres et invitations

Inviter quelqu’un

1. Ouvrez Administration → Membres.
2. Sous « Invitations », saisissez l’adresse e-mail, choisissez le rôle (Membre par défaut) et cliquez Inviter.
3. Copiez le lien et transmettez-le vous-même, par le canal de votre choix : Mankomail n’envoie pas les invitations par e-mail. « Ce lien n’est affiché qu’une fois : il n’est pas conservé et ne pourra pas être réaffiché. »
4. La personne invitée ouvre le lien, choisit un nom et un mot de passe, puis se connecte.

Une invitation est valable 7 jours. Les invitations en attente sont listées avec leur échéance et peuvent être révoquées ; une invitation expirée doit être émise de nouveau.

Changer un rôle. Choisissez le nouveau rôle dans la ligne du membre. Le rôle du dernier administrateur actif ne peut pas changer : l’instance doit en garder un.

Désactiver un compte. « Désactiver » coupe immédiatement l’accès d’un membre. La fenêtre liste ce qui va se passer, puis ce qui s’est réellement passé :

• ses sessions sont révoquées : la déconnexion est immédiate ;
• ses boîtes sont déconnectées : la synchronisation s’arrête (leur miroir est conservé) ;
• ses workflows publiés sont mis hors ligne : leurs déclencheurs sont désarmés.

« Réactiver » rend l’accès, mais le membre reconnecte lui-même ses boîtes et republie ses workflows. Vous ne pouvez désactiver ni votre propre compte, ni le dernier administrateur actif.

Politique de nœuds

Administration → Nœuds liste tout le catalogue de nœuds, rangé comme dans l’éditeur, avec l’effet de chaque nœud — « Sans effet externe », « Écrit à l’extérieur » ou « Envoie un e-mail » — et l’un de trois états :

État	Conséquence
Autorisé (par défaut)	tous les membres peuvent utiliser le nœud
Administrateurs seulement	le nœud disparaît du panneau d’ajout des membres ; les administrateurs peuvent toujours l’utiliser
Interdit	le nœud disparaît du panneau d’ajout de tout le monde

Où s’applique la politique :

• Dans l’éditeur : un nœud interdit n’est pas proposé à l’ajout.
• À la publication : un workflow qui contient un nœud interdit — ou, pour un membre, un nœud réservé aux administrateurs — est refusé avec workflow.forbidden_node (« Ce workflow contient un nœud interdit par votre organisation, ou réservé aux administrateurs. »). Les nœuds désactivés ne sont pas vérifiés.
• À l’installation d’un template ou à l’acceptation d’une proposition de l’analyseur qui contient un nœud interdit.

Jamais à l’exécution. Un workflow publié avant l’interdiction d’un nœud continue de tourner : « Les workflows qui l’utilisent déjà restent lisibles, mais leur publication est refusée. » Pour arrêter un tel workflow, mettez-le hors ligne, ou coupez les envois (ci-dessous).

La politique se règle par type de nœud et par rôle ; il n’y a pas de règle par fournisseur d’IA autre que les types de nœuds eux-mêmes (llm.anthropic, llm.openai…). Par l’API : GET et PUT /api/v1/admin/node-policy. PUT est partiel : seuls les types listés changent, avec { "entries": [ { "nodeType": "http.request", "allowed": true, "restrictedToRole": "admin" } ] }. Poser allowed: true et restrictedToRole: null rend au nœud son réglage par défaut.

Le coupe-circuit d’envoi

Administration → Envois — « Ce qui part vraiment de cette instance — et l’interrupteur pour tout arrêter. » — affiche l’état effectif (« Les envois sont ACTIFS » ou « Les envois sont COUPÉS ») et les deux interrupteurs dont il dépend :

Interrupteur	Réglé par	Se change
Instance	le réglage SEND_ENABLED du serveur (vrai par défaut)	seulement en modifiant la configuration et en redémarrant ; en lecture seule sur cette page
Organisation	un administrateur, avec Couper les envois / Rouvrir les envois	aussitôt, sans redémarrage

Un mail ne part que si les deux sont ouverts. Rouvrir l’interrupteur de l’organisation ne fait rien tant que celui de l’instance est coupé (« L’instance a coupé les envois (SEND_ENABLED=false). »).

Ce que « coupé » veut dire :

• Retenus : les envois réels — réponses, transferts, nouveaux messages — des workflows, des demandes d’approbation et du composeur du webmail.
• Continuent : les brouillons, les classements, les étiquettes, les marquages, les analyses — tout ce qui ne sort pas de l’instance. Les workflows continuent de tourner.
• À la réouverture, ce qui était retenu repart. Rien n’est perdu, rien n’est envoyé deux fois.

Servez-vous-en quand quelque chose tourne mal : un workflow qui répond aux mauvaises personnes, une boucle, un doute sur un template. Mettez ensuite le workflow en pause ou corrigez-le, puis rouvrez les envois. Par l’API : GET et PUT /api/v1/admin/send-settings avec { "enabled": false } ; la réponse indique lockedByInstance quand l’interrupteur de l’instance est coupé.

Arrêter des workflows

Aucun interrupteur ne suspend toutes les exécutions de l’organisation. Les leviers sont :

Levier	Qui	Effet
Mettre en pause un workflow	son propriétaire	aucune nouvelle exécution ne part des mails, planifications ou sondages ; les exécutions en cours se terminent
Mettre hors ligne un workflow	son propriétaire	tous les déclencheurs sont désarmés ; les exécutions en cours se terminent
Couper les envois	un administrateur	aucun mail ne quitte l’organisation ; tout le reste continue
Désactiver un membre	un administrateur	met hors ligne tous ses workflows et déconnecte ses boîtes

Voir Brouillon, version publiée et historique pour la pause et la mise hors ligne.

Les limites d’envoi

Réglage	Par défaut	Effet
SEND_MAX_PER_HOUR	100	plafond horaire des envois. Au-delà, les mails attendent leur tour — ils ne sont pas perdus. Affiché sous « Plafond horaire » sur la page Envois
SEND_MAX_BYTES	25 Mo	taille maximale d’un message composé, pièces jointes comprises

Ce sont deux réglages d’instance (voir Variables d’environnement). Les fournisseurs appliquent en plus leurs propres limites : Gmail et Microsoft 365 limitent le nombre de messages et de destinataires par jour.

Les modèles d’IA et leurs coûts

Les fournisseurs d’IA sont configurés une fois pour toute l’organisation, par un administrateur, sur la page Connexions. Les membres ne voient jamais les clés : « Les fournisseurs d’IA sont configurés une fois pour toute l’organisation, par un administrateur. »

Un administrateur :

• ajoute un fournisseur (Anthropic, OpenAI, Mistral AI, OpenRouter, Ollama, ou une API compatible OpenAI) avec sa clé — jamais réaffichée — et, si besoin, l’URL de son serveur ;
• liste les modèles activés de chaque fournisseur : un modèle non activé est refusé quand un nœud l’utilise ;
• choisit Quelle IA pour quel usage : un défaut, et au besoin un modèle par usage (classer, rédiger, extraire, usage général, analyse de boîte, assistant de workflows) ;
• consulte Usage et coûts de l’IA : les appels et leur coût estimé, par période, pour les exécutions de workflows (essais compris), les évaluations, l’analyseur et l’assistant.

L’instance limite les appels à LLM_MAX_REQUESTS_PER_MINUTE par fournisseur (60 par défaut). Il n’existe pas de budget de dépense : surveillez les coûts dans Usage et coûts de l’IA. Chaque fournisseur est décrit sous Intégrations.

Les accès pour les systèmes extérieurs

Applications OAuth. Les boîtes, espaces de fichiers et agendas Google et Microsoft se connectent par l’application OAuth propre à l’organisation, enregistrée une fois dans Administration → Applications OAuth : la page donne l’URI de redirection à coller dans la console du fournisseur et un guide pas à pas. Le secret client n’est jamais réaffiché. Voir Google et Microsoft.

Clés d’API. Administration → Clés d’API crée des clés pour l’accès machine à l’organisation — « un CRM qui clôt un dossier, un logiciel de gestion qui signale un mandat signé ». Une clé ne s’affiche qu’une fois (« Copiez cette clé maintenant ») ; seule une empreinte est conservée. Chaque clé reçoit ce qu’elle a le droit de faire ; aujourd’hui, la seule permission est « émettre des signaux (réveiller ou annuler une attente) ». Envoyez-la dans l’en-tête Authorization: Bearer …. La révocation est immédiate et définitive. Voir la référence de l’API.

Les templates

Les templates sont des workflows prêts à installer, partagés avec toute l’organisation. Un administrateur construit un workflow, puis Promouvoir en template le met à disposition des membres ; les templates peuvent être modifiés, désactivés (« invisible pour les membres ») ou supprimés depuis la page Templates. Installer un template qui contient un nœud interdit par l’organisation est refusé.

Le journal d’audit

Les actions sensibles sont consignées dans un journal d’audit, avec qui a agi (un membre, le système ou un webhook entrant) et quand, jamais avec des secrets ni le contenu des mails. Il couvre :

• les connexions, les connexions échouées et les déconnexions ;
• les invitations, les changements de rôle, les changements de mot de passe, les désactivations et réactivations ;
• les modifications des applications OAuth, des fournisseurs d’IA, des connexions, des clés d’API et du calendrier ouvré ;
• les décisions d’approbation, les signaux émis et les attentes reprises à la main ;
• la mise en pause, la reprise et la suppression de workflows ;
• les imports dans le carnet partagé ;
• la déconnexion et la suppression de boîtes.

Les modifications du périmètre, de la politique de nœuds et de l’interrupteur d’envoi n’y figurent pas. Le journal se lit uniquement par l’API, par les administrateurs : GET /api/v1/admin/audit, filtrable par action, auteur et date. Les entrées sont conservées 365 jours par défaut (AUDIT_LOG_RETENTION_DAYS, 30 au minimum).

Pages liées

• Périmètre
• Boîtes mail et miroir
• Workflows
• Configuration