Sécurité de la plateforme DocPilot

Authentification

L’accès à l’API et aux applications repose sur une authentification à jetons, pas sur une session serveur classique.

• Mot de passe haché avec Argon2id ; jamais stocké en clair. Politique minimale : 10 caractères, majuscule, minuscule et chiffre.
• Jeton d’accès JWT à durée courte (15 minutes), porté dans l’en-tête d’autorisation.
• Jeton de renouvellement opaque, stocké haché côté serveur, transmis dans un cookie httpOnly (et secure en production). Rotation à chaque renouvellement, avec détection de réutilisation.
• Vérification de l’adresse e-mail obligatoire avant la première connexion.
• Réinitialisation de mot de passe via un lien à usage unique (validité une heure).
• Invitations d’équipe et liens d’activation pour rejoindre une organisation.
• Limitation du débit sur la connexion, l’inscription et la demande de réinitialisation (seuil applicatif et protection au reverse-proxy).
• Déconnexion de la session courante ou de toutes les sessions (invalidation des jetons en cours).

Permissions

Les droits d’accès sont gérés par un modèle RBAC (rôles et permissions) appliqué côté serveur.

• Rôles système prédéfinis : administrateur d’organisation, manager, validateur, utilisateur, lecteur.
• Permissions granulaires (documents, contrats, workflows, membres, audit, etc.) contrôlées par des gardes sur chaque endpoint.
• Périmètres supplémentaires : service, domaine et grants documentaires — un membre ne voit que ce que ses droits et son périmètre autorisent.
• Console d’administration plateforme séparée, avec ses propres permissions et gardes.

Organisation et workspace

DocPilot est multi-tenant : chaque organisation dispose d’un espace isolé.

• L’organisation active est portée par le jeton d’authentification. Un en-tête client du type « organisation » n’est pas utilisé pour choisir le tenant.
• Requêtes base de données scopées à l’organisation, avec renforcement par politiques RLS PostgreSQL lorsque le rôle applicatif est en place.
• Objets stockés sous un préfixe dédié par organisation (`tenants/{id}/…`).
• Une organisation suspendue ne peut plus s’authentifier.
• Tests d’isolation automatisés sur documents, recherche, audit et accès inter-organisations.

Stockage

Les fichiers sont conservés dans un stockage objet compatible S3, hors de la base applicative.

• Bucket privé : aucun accès anonyme public.
• Chiffrement côté serveur demandé à l’écriture (SSE-S3, AES-256).
• Accès fichier via URL signées à durée limitée (upload, téléchargement, aperçu).
• Versions immuables : une nouvelle version s’ajoute ; pas d’écrasement silencieux de l’original.
• Contrôle du type de fichier (magic bytes) à la finalisation d’un dépôt.
• Scan antivirus (ClamAV) sur le parcours d’ingestion par e-mail, avant OCR et routage.

Transmission

Les échanges entre clients et API sont protégés au niveau transport et applicatif.

• HTTPS entre les applications (web, mobile) et l’API.
• En-têtes de sécurité HTTP (Helmet) : politique CSP, frame deny, HSTS en production, nosniff.
• CORS limité aux origines configurées, avec cookies d’authentification autorisés uniquement pour ces origines.
• Contrôle CSRF sur les mutations lorsque le cookie d’authentification est présent (vérification Origin / Referer).
• Réponses API marquées no-store (hors health et documentation technique).
• Limitation de débit au reverse-proxy (API, auth, front).

Audit

Les actions sensibles sont journalisées pour la traçabilité métier et le support.

• Journal d’audit par organisation, en écriture seule (append-only) : pas d’API de modification ou de suppression des entrées.
• Actions couvertes : authentification, documents, workflows, permissions, membres, et autres événements sensibles du catalogue produit.
• Métadonnées enrichies (utilisateur, date, adresse IP, agent, identifiant de requête) ; secrets retirés avant enregistrement.
• Journal d’activité documentaire complémentaire pour le suivi d’un dossier.
• Journal d’audit distinct pour les opérations de la console plateforme.

Confidentialité

La confidentialité des données s’appuie sur l’isolation technique et sur les engagements décrits dans la politique de confidentialité.

• Hébergement du service sur une infrastructure cloud dans l’Union européenne.
• Journaux applicatifs avec redaction des chemins sensibles (mots de passe, jetons, en-têtes d’autorisation).
• Suppression logique (soft-delete) des comptes, memberships et documents selon les parcours produit.
• Webhooks entrants vérifiés (signature) avant traitement (ingestion e-mail, facturation).
• Fournisseurs OCR / IA choisis par organisation ; DocPilot ne revendique pas d’entraînement de modèles sur vos documents.
• Détail des traitements, durées et droits des personnes : politique de confidentialité. Synthèse des pratiques : page RGPD.

Lire la politique de confidentialité

Ce que DocPilot ne revendique pas

Cette page décrit des mesures réellement présentes dans le produit. Elle ne constitue pas une attestation de conformité.

• Aucune certification ISO, SOC 2 ou HDS n’est revendiquée.
• Aucune garantie réglementaire générique n’est affichée sur ce site.
• L’authentification multi-facteur (MFA) et le SSO (SAML / OIDC) ne sont pas proposés à ce stade.

Voir la page RGPD

Contact

Pour une question sécurité ou un questionnaire fournisseur : social@docpilot-app.com.