Contrôle d'accès
Choisissez comment vos lecteurs accèdent à vos docs : entièrement public, protégé par mot de passe, mixte ou SSO. Comparez les options et choisissez celle qui convient.
Jamdesk vous offre quatre façons de contrôler qui peut lire vos docs. La plupart des équipes en choisissent une et s'y tiennent ; certaines combinent les approches.
Choisir la bonne approche
| Approche | À utiliser quand | Configuration |
|---|---|---|
| Entièrement public | Docs produit externe, projets open source, tout ce que vous souhaitez indexer et partager. | Par défaut — aucune configuration. |
| Mot de passe sur tout le site | Tout est interne : runbooks d'ingénierie, docs partenaires, produit non encore lancé. Une phrase secrète commune protège l'ensemble du site. | auth.password.enabled: true dans docs.json + définir le mot de passe dans le dashboard. Voir Protection par mot de passe. |
| Mixte (certaines pages privées) | La plupart des docs sont publiques ; quelques-unes sont internes (un runbook, une fonctionnalité bêta, une référence API interne). | Ajoutez private: true dans le frontmatter des pages internes, ou listez-les sous auth.password.private[]. Voir Protection par mot de passe. |
| SSO (Enterprise) | Les lecteurs doivent se connecter avec votre fournisseur d'identité existant — pas de mot de passe partagé, piste d'audit, révocation par suppression de l'utilisateur. | Plan Enterprise. Voir SSO. |
Vous pouvez passer d'une approche à l'autre à tout moment en modifiant docs.json et en poussant vos modifications. Passer du mode site entier au mode mixte (ou inversement) nécessite un seul build.
Cas d'usage courants
Docs internes et externes dans un seul projet
La plupart des équipes veulent des docs internes étendues protégées par une connexion, en parallèle d'un site public plus restreint pour les clients. Vous n'avez pas besoin de deux projets. Utilisez le mode mixte dans un seul projet Jamdesk :
---
title: Incident Runbook
private: true
---Les pages avec private: true sont protégées ; tout le reste reste public. Un seul dépôt, un seul build, un seul dashboard. L'écran de déverrouillage n'apparaît que lorsqu'un lecteur accède à une page protégée.
Pour les sections internes plus importantes, listez les chemins dans docs.json plutôt que de marquer chaque fichier. Remarque : auth.password.private[] active automatiquement le mode pages spécifiques — vous n'ajoutez pas enabled: true (c'est le mode site entier, soit l'opposé de ce que vous souhaitez ici).
{
"auth": {
"password": {
"hint": "Ask the on-call engineer",
"private": ["/internal/**", "/admin/runbook"]
}
}
}Deux projets séparés
Utilisez deux projets uniquement lorsque les audiences nécessitent des identités visuelles entièrement distinctes, des domaines personnalisés séparés, des analytics séparées ou des niveaux de plan différents. Par exemple : un site de docs public sur docs.acme.com et un wiki interne séparé sur internal.acme.com. Le coût de maintenance est plus élevé : deux builds, deux dashboards, deux domaines.
SSO pour le site de docs
Sur les plans Enterprise, les lecteurs se connectent avec votre fournisseur d'identité (Okta, Google Workspace, Azure AD, etc.) plutôt que de saisir un mot de passe partagé. Cette approche convient mieux lorsque vous avez besoin d'une piste d'audit de qui a lu quoi, ou lorsque le retrait d'un utilisateur doit révoquer immédiatement son accès aux docs. Voir SSO pour la vue d'ensemble et pour initier une conversation avec l'équipe commerciale.
Éditeurs et lecteurs
On confond parfois trois concepts d'accès distincts :
| Rôle | Ce qu'ils font | Comment l'accès est accordé |
|---|---|---|
| Éditeurs | Rédigent et mettent à jour le contenu MDX. | Les docs sont modifiées en committant du MDX dans votre dépôt GitHub connecté, donc les permissions de votre dépôt GitHub sont les permissions des éditeurs. Il n'existe pas de rôle éditeur Jamdesk distinct en plus — toute personne pouvant pousser vers votre branche docs peut publier une modification. |
| Lecteurs | Consultent le site de docs publié. | Tout le monde (public), toute personne connaissant le mot de passe (mode mot de passe), ou toute personne authentifiée via votre IdP (SSO). |
| Membres de l'équipe dashboard | Gèrent les builds, les analytics et les paramètres du projet dans le dashboard Jamdesk. | Invités via Paramètres → Équipe dans le dashboard. Ils ne rédigent pas de contenu directement. Voir Membres de l'équipe. |
Un membre de l'équipe peut cumuler n'importe quelle combinaison des trois rôles. Ce sont des axes indépendants.