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 géré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 e-mail et un mot de passe, ou via SSO avec Google ou GitHub. Les mots de passe ne sont jamais stockés en clair ; notre fournisseur d'authentification ne conserve que des hachages à sens unique.

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

Accès de l'équipe

Le contrôle d'accès basé sur les rôles (Propriétaire, Administrateur, Membre) est appliqué à la fois dans les règles de sécurité de notre base de données et à 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 du dépôt
• Livraison via 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 d'applications GitHub.

Tokens et secrets

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

• Les connexions GitHub App, pour lesquelles nous ne conservons que votre identifiant d'installation numérique. Des tokens d'installation à courte durée de vie (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 du 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 à sens unique. Le texte en clair vous est affiché une seule fois au moment de la création. Si vous le perdez, faites pivoter la clé.

Gestion des données

Ce que nous stockons

• Votre configuration docs.json et les ressources de marque téléchargées
• La documentation compilée (HTML, CSS, JS)
• Les journaux de build, conservés pendant 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'arbre 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 utilisateurs sous quelque forme réversible que ce soit.
• Les numéros de carte 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 exploiter le service ou répondre aux demandes d'assistance. Cet 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 au moment opportun
• Le conteneur est détruit une fois le build terminé ou en échec

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 respecté 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.

Réponse aux incidents

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

1. Nous enquêtons et contenons le problème.
2. Nous notifions les clients concernés dans les 72 heures, conformément à nos obligations GDPR.
3. Nous fournissons un rapport écrit post-incident une fois la cause confirmée.

Signalement de vulnérabilités

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

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

Nous ne gérons 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