Guide de l’administrateur Goooy

Tout ce dont un administrateur a besoin pour exécuter, sécuriser et exploiter Goooy : votre alternative auto-hébergée à Microsoft Exchange / Office 365.

Goooy est une suite de groupware complète que vous hébergez vous-même : courrier, calendrier, contacts, tâches, notes, conversation, fichiers, réunions vidéo, office collaboratif et une console d’administration, le tout depuis une seule application, un seul modèle de données et un seul chart Helm. Vous possédez les serveurs, les données et les clés.

Ce guide s’adresse aux personnes qui exploitent Goooy. Pour les fondations techniques de la plateforme (l’architecture, le déploiement avec Helm ou Docker Compose et l’essentiel de la configuration), consultez le Guide du développeur. Pour la vue des applications côté utilisateur final, consultez le Guide de l’utilisateur. Pour les détails techniques approfondis, le dossier docs/ contient des références dédiées (architecture, sécurité, serveur de messagerie, multi-tenancy, déploiement, migration et les protocoles clients natifs).

Sommaire

• La console d’administration
• Organisations, domaines et utilisateurs
• Authentification et politique d’accès
• Le serveur de messagerie
• Clients natifs et gestion des appareils
• Migrer depuis un autre système
• Multi-tenancy et isolation
• Sécurité et conformité
• Sauvegardes et exploitation
• Inscription en libre-service et votre vitrine marketing

La console d’administration

Connectez-vous en tant qu’administrateur et vous obtenez une zone Admin protégée par RBAC (la surface REST est /api/v1/admin, restreinte aux rôles SYSADMIN / ORGADMIN et cloisonnée par organisation). Depuis celle-ci, vous pouvez :

• Gérer les organisations, domaines, utilisateurs et groupes (créer, modifier, supprimer).
• Consulter un tableau de bord de statistiques d’utilisation de la plateforme/organisation.
• Exécuter la gestion des appareils mobiles : lister les appareils enrôlés et demander des effacements à distance.
• Intégrer un annuaire : importer des utilisateurs en masse et synchroniser depuis LDAP.
• Configurer le SSO par organisation et la politique de sécurité (obligation de 2FA, application du SSO).
• Vérifier la propriété d’un domaine via des enregistrements DNS TXT.
• Exécuter des migrations depuis d’autres systèmes de messagerie (Admin ▸ Migrations).

Organisations, domaines et utilisateurs

La colonne vertébrale de la tenancy de Goooy est Organisation → Domaine → Utilisateur. Chaque utilisateur possède une boîte aux lettres avec une arborescence de dossiers typée (courrier, calendrier, contacts, tâches, notes, fichiers), donc un seul modèle de stockage et de permissions sous-tend chaque application. La suppression d’une organisation, d’un utilisateur ou d’une boîte aux lettres se répercute proprement en cascade sur tout ce qui se trouve en dessous.

Rôles (RBAC)

Les actions d’un ORGADMIN sont automatiquement cloisonnées à son orgId ; un ORGADMIN ne peut pas créer d’organisations ni accorder le rôle SYSADMIN. Chaque requête multi-tenant filtre selon l’organisation de l’appelant, si bien que les tenants ne voient jamais les données des autres.

Ajouter des utilisateurs

Créez les utilisateurs individuellement dans la console, importez-les en masse, ou synchronisez depuis LDAP avec ldapts. Chaque nouvel utilisateur est automatiquement provisionné avec une boîte aux lettres et l’arborescence de dossiers par défaut. Les mots de passe suivent votre politique (voir ci-dessous).

Vérification de la propriété d’un domaine

Avant qu’un domaine ne gère du vrai courrier, un administrateur peut prouver qu’il en a le contrôle de la même façon que Google Workspace et Microsoft 365 :

1. La console affiche un enregistrement TXT à publier (_goooy-verify.<domain> avec une valeur de jeton stable).
2. Publiez-le dans votre DNS.
3. Cliquez sur Vérifier maintenant. Goooy effectue une recherche DNS en direct et marque le domaine comme vérifié.

Cette opération est cloisonnée par organisation et auditée ; un ORGADMIN ne peut vérifier que les domaines de sa propre organisation.

Authentification et politique d’accès

Goooy prend en charge toute la gamme des contrôles d’accès modernes. Les valeurs par défaut sont sûres ; renforcez-les par organisation selon vos besoins.

Mots de passe

• Hachés avec bcrypt (coût 12), les mêmes empreintes que Dovecot vérifie, si bien qu’il y a un seul magasin d’identifiants pour le webmail et l’IMAP/POP3 natif.
• Une politique de mot de passe est appliquée à chaque définition/changement/ réinitialisation/inscription : une longueur minimale (PASSWORD_MIN_LENGTH, 10 par défaut) et une vérification optionnelle des fuites via Have I Been Pwned (k-anonymat : seul un préfixe SHA-1 quitte le serveur, et elle échoue en mode ouvert pour qu’une panne de HIBP ne bloque jamais un changement de mot de passe).
• La réinitialisation de mot de passe en libre-service est protégée contre l’énumération et révoque toutes les autres sessions à son utilisation.

Authentification multifacteur

• Codes d’authentification TOTP avec des codes de récupération à usage unique, plus des passkeys FIDO2/WebAuthn (avec détection de clonage).
• Définissez Organization.requireMfa pour imposer la 2FA à une organisation. Les utilisateurs sont guidés à travers l’enrôlement et bloqués hors de l’application jusqu’à ce qu’ils aient terminé.

Défense contre la force brute et le détournement de compte

• Deux couches de limitation : une limitation de débit par IP sur les points de terminaison de connexion/MFA, et un verrouillage par compte (après un seuil de tentatives échouées, le compte se verrouille pour une fenêtre à croissance exponentielle) qui déjoue le credential-stuffing distribué.
• Audit des connexions : chaque tentative est enregistrée (IP, user-agent, résultat) et les utilisateurs peuvent voir leurs connexions récentes dans Paramètres → Sécurité.
• Alertes de nouvel appareil : la première fois qu’un appareil se connecte, le compte reçoit un e-mail de « nouvelle connexion » ; les changements de mot de passe et de MFA notifient également l’utilisateur (conditionné par SECURITY_EMAILS_ENABLED).

Authentification unique (OIDC par organisation)

Configurez une connexion OIDC générique par organisation (flux Authorization Code). L’organisation est résolue à partir du domaine de messagerie de l’utilisateur (home-realm discovery), les utilisateurs sont provisionnés à la volée si leur domaine est hébergé, et le secret client est en écriture seule (scellé au repos, jamais renvoyé).

Vous pouvez imposer le SSO à une organisation (ssoEnforced) pour désactiver entièrement la connexion par mot de passe, avec deux garde-fous pour ne pas vous verrouiller dehors : cela ne prend effet que tant qu’une connexion SSO utilisable existe, et les comptes SYSADMIN conservent toujours la connexion par mot de passe comme dispositif de secours.

Voir Intégration en libre-service et authentification externe pour l’API d’auth complète, et Sécurité pour la référence approfondie.

Le serveur de messagerie

Par défaut, Goooy est autonome : il accepte le courrier entrant sur ses propres écouteurs SMTP (2525) et LMTP (2526), relaie le sortant via nodemailer, évalue le spam avec une heuristique intégrée à base de règles, et distribue localement entre les utilisateurs hébergés, si bien que le courrier interne fonctionne sans aucune infrastructure externe.

Pour du vrai courrier Internet, activez la pile Postfix + Dovecot + Rspamd et l’API devient le centre de distribution d’un serveur de messagerie complet :

helm upgrade goooy ./deploy/helm/goooy --set mail.enabled=true

Internet ─SMTP:25─▶ Postfix ──milter──▶ Rspamd ──LMTP──▶ api ─┬─▶ Postgres (web UI; spam→Junk)
 clients ─587/465─▶  (MTA, SASL)        (scan+DKIM)           └─▶ Dovecot ─▶ Maildir (IMAP/POP3)

• Postfix accepte le courrier de vos domaines hébergés (recherchés en direct dans Postgres), le fait passer par le milter Rspamd (SPF/DKIM/DMARC + scoring du spam), et le distribue à l’API via LMTP.
• L’API écrit le message dans Postgres (le magasin webmail, en classant dans les Indésirables le spam signalé par Rspamd) et le duplique dans Dovecot pour que les clients IMAP/POP3 natifs le voient.
• Le sortant est relayé en retour par Postfix, signé DKIM par Rspamd.

L’anti-phishing est intégré : les résultats d’authentification de l’expéditeur entrant sont stockés par message ; une bannière d’expéditeur externe signale le courrier provenant de l’extérieur de vos domaines ; les usurpations de votre propre domaine non authentifiées sont classées dans les Indésirables avec un avertissement fort ; les actions « Signaler » / « Non indésirable » des utilisateurs entraînent le filtre bayésien de Rspamd ; et le lecteur avertit sur les liens trompeurs, les hôtes homographes/punycode et l’usurpation de nom d’affichage, avec le contenu distant bloqué par défaut et relayé par proxy.

Liens sûrs et sandboxing des pièces jointes. Deux défenses supplémentaires pour le courrier entrant peuvent être activées par organisation dans Admin ▸ Sécurité de la messagerie (toutes deux désactivées par défaut) :

• Les liens sûrs réécrivent chaque lien du courrier externe entrant et revérifient la destination au moment du clic : les URL de la liste de blocage reçoivent une page de blocage, les URL suspectes (hôtes en adresse IP littérale, identifiants intégrés, sosies punycode) une page d’avertissement, et les URL saines redirigent directement: chaque clic est audité. Les copies envoyées, le courrier interne et les corps signés ou chiffrés restent intacts.
• Le sandboxing des pièces jointes détone statiquement les pièces jointes entrantes, en plus de l’analyse antivirus toujours active : exécutables détectés par leur contenu, projets de macros Office, archives protégées par mot de passe ou imbriquées, et HTML/SVG scriptés. Le courrier malveillant est classé dans Indésirables, et toute pièce jointe signalée est mise en quarantaine (téléchargement bloqué) jusqu’à ce qu’un administrateur de l’organisation la libère.

Précaution opérationnelle : ne mettez jamais permit_mynetworks sur un écouteur SMTP exposé sur Internet. Cela crée un relais ouvert. Les configurations livrées séparent le port public :25 d’un port de soumission interne uniquement, précisément pour cette raison. Le détail complet et les limites figurent dans Serveur de messagerie et deploy/mail/README.md.

Clients natifs et gestion des appareils

Goooy parle les protocoles standard, si bien que vos utilisateurs conservent les applications qu’ils ont déjà. Tous sont montés sur leurs racines bien connues et utilisent HTTP Basic (e-mail + mot de passe) là où le protocole l’attend :

Application mobile Outlook : l’application Outlook iOS/Android a besoin d’un EAS de style OAuth que Goooy n’offre pas ; conseillez aux utilisateurs d’iPhone/iPad d’utiliser plutôt l’application Apple Mail intégrée.

Gestion des appareils mobiles. Les appareils qui s’enrôlent via ActiveSync sont suivis. Depuis la console MDM, vous pouvez lister les appareils enrôlés et demander un effacement à distance. L’appareil est signalé et effacé lors de sa prochaine synchronisation.

L’assistance

Une assistance est une couche de flux de travail posée sur une boîte partagée, pas un système distinct. Créez d’abord la boîte partagée, partagez-la avec les agents, puis activez l’assistance dessus dans Administration ▸ Assistance.

• Les agents sont exactement les personnes avec qui la boîte est partagée. Un accès en lecture seule permet d’ouvrir les tickets, mais pas de les attribuer, d’y répondre ni d’en changer le statut.
• Les réglages de la file contiennent le préfixe de clé (TCK), les heures ouvrées, les objectifs de première réponse et de résolution en minutes ouvrées, le délai de fermeture automatique et l’accusé de réception envoyé à un nouvel expéditeur.
• Les réponses types valent pour une file ou pour toute l’organisation.
• Le tri par IA s’active file par file : il propose une priorité et des étiquettes, et n’envoie jamais rien de lui-même.

La remise du courrier n’est pas touchée : chaque message arrive toujours dans la boîte de réception et reste visible en IMAP, ActiveSync, MAPI et JMAP. Désactivez l’assistance et la boîte et son courrier restent exactement comme avant.

Authentification du courrier et rapports

Publier SPF, DKIM et DMARC est la première étape ; savoir si cela fonctionne est la seconde. Pointez l’adresse rua= de votre enregistrement DMARC vers une boîte du domaine, et Goooy analyse chaque rapport agrégé à sa livraison.

Administration ▸ Authentification du courrier affiche alors, par domaine : le taux de conformité, l’alignement SPF et DKIM, et les sources d’envoi en échec, ce qui permet de distinguer un expéditeur légitime oublié de quelqu’un qui vous usurpe. Les rapports TLS SMTP (TLS-RPT) arrivent de la même façon et révèlent les connexions échouées ou rétrogradées.

Goooy peut aussi héberger une politique MTA-STS par domaine sur /.well-known/mta-sts.txt, pour que les autres fournisseurs refusent de remettre votre courrier sur une connexion non chiffrée.

Provisionnement avec SCIM et LDAP

Trois façons de garder les comptes alignés sur votre annuaire :

• SCIM 2.0 sur /scim/v2, authentifié par un jeton bearer propre à chaque organisation. Votre fournisseur d’identité crée, met à jour et désactive les utilisateurs et les groupes au fil des arrivées, des mobilités et des départs.
• La synchronisation LDAP / Active Directory récupère utilisateurs et groupes périodiquement.
• L’import CSV en masse pour un chargement ponctuel.

Combinez-les avec le SSO par organisation : désactiver quelqu’un au centre lui retire l’accès partout, clients natifs compris.

Migrer depuis un autre système

Le Goooy Mover déplace les données d’une entreprise existante vers Goooy depuis un serveur IMAP en direct ou depuis des fichiers d’export importés : un administrateur associe chaque boîte aux lettres source à un utilisateur Goooy (les utilisateurs manquants sont provisionnés automatiquement), clique sur démarrer, et le transfert se fait en arrière-plan avec un suivi d’état en direct par utilisateur. L’interface d’administration est Admin ▸ Migrations.

Ce qu’il préserve et garantit :

• Hiérarchie des dossiers : les dossiers bien connus (Boîte de réception, Envoyés, Corbeille, Indésirables, Archive) sont associés à leurs rôles Goooy ; les dossiers plus profonds sont recréés en tant qu’enfants.
• Dates et état : les dates de réception d’origine et le statut lu/marqué, pour qu’une boîte aux lettres migrée ressemble à l’originale.
• Reprenable et idempotent : il enregistre des points de contrôle de la progression, si bien que tuer l’API en plein lot reprend là où elle s’était arrêtée, et une réexécution ne crée jamais de doublons (dédupliqué par Message-ID, ou par un UID pour l’agenda/les contacts).

La voie du serveur en direct fonctionne avec Gmail, Microsoft 365, Dovecot, Zimbra et la plupart des serveurs IMAP (utilisez un mot de passe d’application là où le fournisseur en exige un: l’assistant propose des profils de connexion en un clic pour les fournisseurs courants). La voie d’import de fichiers accepte Outlook .pst (courrier + agenda + contacts), .mbox (courrier, y compris un export Google Takeout: le moyen le plus simple de quitter un compte Gmail personnel), .ics (agenda) et .vcf (contacts), le format étant détecté automatiquement à partir du contenu du fichier. Le flux est Source → Comptes → utilisateurs (avec un Test d’identifiants par ligne, ou un import par fichier) → Exécution → Tableau de bord en direct avec réessai par ligne et pause/annulation par lot. Toutes les mutations sont auditées. Le détail complet et la feuille de route (CalDAV/CardDAV, Microsoft 365 Graph, Gmail API, tenant-à-tenant) figurent dans Migration.

Multi-tenancy et isolation

Par défaut, Goooy est logiquement multi-tenant : chaque requête est cloisonnée par orgId et protégée par RBAC, tous les tenants partageant une seule base de données. Pour des exigences plus strictes, un mode d’isolation forte optionnel donne à chaque tenant son propre schéma PostgreSQL ou sa propre base de données :

TENANT_ISOLATION = shared (default) | schema | database

Un catalogue de plan de contrôle résout la bonne connexion par requête (req.db), si bien que la valeur par défaut (base de données partagée) reste totalement inchangée lorsque vous n’optez pas pour l’isolation. Cela vous permet d’offrir une résidence des données par tenant ou une isolation contractuelle sans exécuter des déploiements séparés. Voir Tenancy.

Sécurité et conformité

Une liste de contrôle condensée. La référence qui fait foi est Sécurité.

• Transport. Le TLS se termine à l’Ingress (éventuellement automatisé avec cert-manager). Le TLS vers les stores sous-jacents est piloté par l’URL et ne nécessite aucun changement de code : ?sslmode=require sur DATABASE_URL, rediss:// pour Redis, point de terminaison S3 en https://.

• En-têtes. Helmet sur l’API ; nginx définit une CSP stricte, X-Frame-Options: SAMEORIGIN, Referrer-Policy et une Permissions-Policy cloisonnant caméra/micro/capture d’affichage à self. Le CORS est cloisonné à PUBLIC_WEB_URL (les chemins de protocole natifs en sont intentionnellement exemptés, ne « corrigez » pas cela).

• Sécurité du courrier de bout en bout (S/MIME). Chaque utilisateur peut avoir une identité X.509 auto-signée pour signer/vérifier (RSA-SHA256) et chiffrer/déchiffrer (hybride RSA-OAEP + AES-256-GCM, multi-destinataires) ; la clé privée est scellée au repos et jamais renvoyée en clair.

• Rendu des e-mails. Le courrier HTML est nettoyé par DOMPurify et contraint par la CSP nginx. Conservez les deux.

• Secrets au repos. Les clés S/MIME, les secrets clients SSO et les identifiants de migration sont scellés en AES-256-GCM à l’aide de JWT_SECRET. Fournissez votre propre Secret ; effectuez la rotation de JWT_SECRET de façon délibérée (elle invalide les valeurs scellées).

• Les conteneurs s’exécutent en non-root sous un contexte de sécurité restrictif.

• Souveraineté des données. Goooy est auto-hébergé de bout en bout. Vous choisissez la région et le fournisseur pour chaque store. Voir Souveraineté des données.

• Rétention. Des politiques par organisation font expirer courrier, fichiers et messages selon le calendrier que vous fixez. Le balayage tourne en arrière-plan et est journalisé.

• Gel légal. Un gel sur une personne concernée conserve ses données, prime sur la rétention jusqu’à sa levée, et exporte tout en JSON pour examen.

• Prévention des fuites de données. Analyse sur toute l’organisation, du courrier aux conversations et aux fichiers, selon les motifs que vous configurez.

Licence : AGPL-3.0-or-later.

Sauvegardes et exploitation

• Ce qu’il faut sauvegarder : PostgreSQL (le système de référence) et votre bucket S3 (les blobs de fichiers et de pièces jointes). Redis est éphémère et ne nécessite aucune sauvegarde. Le chart peut exécuter un CronJob pg_dump nocturne (backup.enabled=true).
• Sondes de santé : l’API expose /healthz (liveness) et /readyz (readiness adossée à la base de données) pour Kubernetes.
• Mise à l’échelle : l’API est sans état (auth JWT) et diffuse le temps réel via le pub/sub Redis, elle passe donc à l’échelle horizontalement. Activez le HPA (autoscaling.enabled=true, nécessite metrics-server) et un PodDisruptionBudget pour des déploiements sûrs.
• Observabilité : journaux JSON structurés (pino).
• Changements de schéma : le conteneur API exécute prisma migrate deploy au démarrage, si bien que les migrations validées s’appliquent automatiquement au déploiement.
• Ne tuez pas les ports d’ingestion (2525/2526) pour les « libérer » dans un environnement en cours d’exécution. C’est ainsi qu’arrive le courrier entrant.

Inscription en libre-service et votre vitrine marketing

Goooy peut exécuter un flux public d’inscription en libre-service pour que les clients créent leur propre organisation. Il est désactivé par défaut. Définissez SELF_SIGNUP_ENABLED=true pour l’activer. Le point de terminaison crée de façon atomique une Organisation, son premier Domaine et un utilisateur ORGADMIN (jamais SYSADMIN), et renvoie une session active. Il est limité en débit par IP comme garde-fou contre les abus.

L’application web fournie livre déjà une page publique /signup qui pilote ce flux en same-origin, vous n’avez donc pas à la construire. Et un site marketing Astro statique (apps/marketing) est inclus pour la porte d’entrée publique. Activez-le sur son propre hôte :

helm upgrade goooy ./deploy/helm/goooy \
  --set marketing.enabled=true \
  --set marketing.host=www.example.com

Son CTA « Get started » renvoie vers la page /signup de l’application. L’API d’auth externe complète (connexion, MFA, SSO, sessions, vérification de domaine), tout ce dont vous auriez besoin pour construire votre propre vitrine d’inscription à la place, est documentée dans Intégration en libre-service et authentification externe.

Commencer

• Nouveau ici ? Lisez le Guide de l’utilisateur pour la vue de chaque application côté utilisateur final.
• Vous déployez ou intégrez la plateforme ? Le Guide du développeur couvre l’architecture, le déploiement Helm/Docker Compose et la configuration.
• Parcourez les pages aperçu des fonctionnalités, sécurité et conformité et auto-hébergement.
• La référence technique complète (architecture, modèle de données, serveur de messagerie, multi-tenancy, déploiement, migration et les protocoles clients natifs) est fournie avec le code source du produit.