Sécurité

Comment Jamdesk protège votre documentation et les données de votre compte.

Sécurité de l'infrastructure

Hébergement

Jamdesk s'appuie sur des fournisseurs cloud conformes SOC 2. Les builds, les données applicatives et la documentation compilée résident chacun dans des services managés et renforcés de ces fournisseurs, et le trafic est servi via un CDN mondial avec protection DDoS intégrée.

Chiffrement

Contrôles d'accès

Connexion

Vous pouvez vous connecter au dashboard avec un email et un mot de passe, ou via l'authentification unique (SSO) par Google ou GitHub. Les mots de passe ne sont jamais stockés en clair ; notre fournisseur d'authentification ne conserve que des hachages unidirectionnels.

Si vous vous connectez via Google ou GitHub, tout MFA que vous avez configuré sur ce compte (TOTP, clés de sécurité, passkeys) s'applique également à votre connexion Jamdesk. Pour une protection maximale, nous recommandons d'activer le MFA sur votre compte Google ou GitHub et d'utiliser le SSO.

Accès de l'équipe

L'accès basé sur les rôles (Owner, Admin, Member) est appliqué à la fois dans les règles de sécurité de notre base de données et sur chaque appel backend. Les sessions expirent automatiquement après des périodes d'inactivité, et les modifications apportées à la facturation, aux membres, aux domaines personnalisés ou aux clés API sont consignées dans un journal d'audit par projet.

Intégration GitHub

Jamdesk se connecte à vos dépôts via une GitHub App avec les permissions minimales nécessaires :

• Accès en lecture seule au contenu des dépôts
• Livraison de Webhook pour les déclencheurs de build
• Aucun accès en écriture à votre code

Nous ne poussons jamais, ne créons pas de branches et ne modifions pas votre dépôt. Vous pouvez révoquer l'accès de Jamdesk à tout moment depuis vos Paramètres des applications GitHub.

Tokens et secrets

Chaque secret que vous nous confiez est chiffré au repos. Cela inclut :

• Les connexions GitHub App, pour lesquelles nous ne conservons que votre identifiant d'installation numérique. Les tokens d'installation de courte durée (valables une heure) sont générés à la demande et ne sont jamais persistés.
• Les tokens OAuth GitHub utilisés lors du flux de création de dépôt de démarrage, qui sont échangés une fois, utilisés pour cloner le modèle, puis supprimés.
• Les identifiants d'intégrations tierces tels que les URL de webhooks entrants Slack, les tokens de vérification de domaines personnalisés et les clés API d'analytique.

Le dashboard ne renvoie jamais ces valeurs au navigateur après leur enregistrement ; seul le pipeline de build côté serveur peut les lire.

Les clés API programmatiques sont stockées sous forme de hachages unidirectionnels. Le texte en clair vous est affiché exactement une fois lors de la création. Si vous le perdez, effectuez une rotation de la clé.

Gestion des données

Ce que nous stockons

• Votre configuration docs.json et tout actif de marque importé
• La documentation compilée (HTML, CSS, JS)
• Les journaux de build, conservés 30 jours
• Les événements d'analytique anonymisés (pages vues, pays, famille d'appareils)
• Les secrets chiffrés pour toute intégration tierce que vous avez configurée

Ce que nous ne stockons pas

• Votre code source. Nous clonons le dépôt au moment du build et supprimons l'arborescence de travail lorsque le conteneur de build est détruit.
• Les identifiants GitHub à longue durée de vie. Voir Tokens et secrets ci-dessus.
• Les mots de passe utilisateur sous quelque forme réversible que ce soit.
• Les numéros de cartes de paiement. Stripe gère toutes les données de carte ; nous ne conservons que l'identifiant client et les métadonnées d'abonnement.

Accès interne

L'accès aux données de production est limité à un petit nombre d'employés qui en ont besoin pour opérer le service ou répondre aux demandes de support. L'accès est journalisé.

Isolation des builds

Chaque build de documentation s'exécute dans un conteneur dédié :

• Aucun accès aux données des autres clients
• Environnement vierge pour chaque build, avec les secrets injectés en temps réel
• Le conteneur est détruit une fois le build terminé ou échoué

Conformité

GDPR

Jamdesk est conforme aux exigences du GDPR :

• Accord de traitement des données disponible sur demande à privacy@jamdesk.com
• Une liste publique des sous-traitants sur jamdesk.com/subprocessors
• Droit à la suppression honoré dans un délai de 30 jours
• Portabilité des données prise en charge via l'export

Confidentialité

Notre analytique intégrée :

• N'utilise pas de cookies
• Ne suit pas les individus
• Respecte les en-têtes Do Not Track

Consultez notre Politique de confidentialité pour plus de détails.

Gestion des incidents

Si un incident de sécurité affecte votre compte ou vos données, nous prenons trois mesures :

1. Investiguer et contenir le problème.
2. Notifier les clients concernés dans les 72 heures, conformément à nos obligations GDPR.
3. Fournir un rapport post-incident écrit une fois la cause confirmée.

Signalement de vulnérabilités

Vous avez découvert un problème de sécurité ? Signalez-le de manière responsable :

• Envoyez un email à security@jamdesk.com
• Incluez une description, les étapes de reproduction et une évaluation de l'impact
• Nous accuserons réception dans les 48 heures

Nous ne proposons pas actuellement de programme de bug bounty rémunéré, mais nous sommes heureux de créditer les chercheurs qui signalent de bonne foi.

Questions ?

Articles connexes