Notre sécurité

Tous les transferts de données sont chiffrés en TLS (au moins TLS 1.2, de préférence TLS 1.3) entre le navigateur, l'application, la base de données et le moteur de transcription. HSTS est actif sur tous les points de terminaison publics ; les requêtes HTTP sont redirigées vers HTTPS et les suites de chiffrement sont configurées selon le profil « Modern » de Mozilla.

Les données sont chiffrées au repos : les sauvegardes sont sécurisées avec AES-256 et les volumes de base de données sont entièrement chiffrés au niveau du disque. Les mots de passe sont stockés exclusivement avec bcrypt (coût ≥ 10). Les clés API sont stockées sous forme de hachage et affichées en clair une seule fois, lors de leur création.

Les accès administratifs aux systèmes de production se font exclusivement via SSH avec authentification par clé asymétrique – la connexion par mot de passe est désactivée. Tous les comptes du personnel sur les consoles de plateforme et de cloud sont protégés par une authentification à deux facteurs basée sur TOTP.

• Contrôle d'accès basé sur les rôles (RBAC) selon le principe du moindre privilège
• Révision trimestrielle de toutes les autorisations d'accès
• Journal d'audit complet de tous les accès administratifs (qui, quand, quoi, d'où)
• En fonctionnement normal, le personnel d'Aliru n'a aucun accès en lecture au contenu des transcriptions
• Côté client : 2FA TOTP optionnelle, codes de secours, journal d'audit distinct par compte

Chaque espace de travail (en interne un « Directory ») est logiquement séparé de tous les autres via un UUID. Chaque requête à la base de données vérifie le contexte Directory de la requête en cours – un accès en lecture inter-locataires est techniquement impossible, car la couche applicative n'autorise jamais de requête non vérifiée contre la base de données. Les sauvegardes, journaux d'audit et caches suivent la même séparation.

• Sauvegardes automatisées quotidiennes ; conservation glissante de 14 jours
• Sauvegardes chiffrées (AES-256) et conservées sur du matériel distinct dans un second centre de données
• Tests de restauration documentés tous les six mois
• RTO (Recovery Time Objective) : 4 heures en cas de panne totale
• RPO (Recovery Point Objective) : au maximum 24 heures de perte de données
• Page de statut sur deepscript.com/status avec sonde à la minute et historique des incidents sur 90 jours

Nous appliquons un processus de réponse aux incidents documenté avec une chaîne d'escalade claire : détection → confinement → analyse → remédiation → notification au client → post-mortem.

• Notification des violations de données aux clients dans les 24 heures suivant leur connaissance
• Contenu de la notification : nature de la violation, catégories et nombre approximatif de données concernées, mesures prises, point de contact
• La notification à l'autorité au titre de l'art. 33 RGPD (délai de 72 heures) incombe au responsable du traitement – nous apportons notre soutien avec toutes les informations nécessaires
• Un post-mortem pour chaque incident avec analyse des causes profondes et mesures pour éviter qu'il ne se reproduise

Chaque année, nous mandatons un prestataire de sécurité externe indépendant pour réaliser un test d'intrusion sur l'application web et l'API REST publique. Les résultats sont priorisés selon une pondération du risque ; les conclusions critiques sont corrigées dans un délai de 14 jours. Nous mettons un résumé exécutif à la disposition des clients professionnels sur demande, sous NDA.

En interne, nous menons chaque trimestre un contrôle de l'efficacité des MTO – la version actuelle est documentée à l'annexe 1 du contrat de sous-traitance (DPA).

• Revue de code obligatoire pour toutes les modifications du code de production
• Analyse des dépendances à chaque build (pnpm audit) – aucune CVE critique connue en production
• CI automatisée avec vérification de type, tests unitaires et tests E2E avant chaque déploiement
• Séparation stricte des environnements de développement, de pré-production et de production – aucune donnée réelle dans les systèmes hors production
• Secrets dans les configurations de production via des variables d'environnement chiffrées ; aucun secret dans le dépôt de code

Notre moteur de reconnaissance vocale relève de la catégorie « risque limité » du règlement IA de l'UE (règlement (UE) 2024/1689). Il n'y a ni identification biométrique, ni notation sociale, ni décision automatisée produisant des effets juridiques. Les détails figurent dans la déclaration de conformité IA (annexe 4 du DPA).

• Engagement de confidentialité de tout le personnel conformément à l'art. 28, par. 3, point b) RGPD
• Formation annuelle obligatoire sur la protection des données et la sécurité de l'information
• Formation d'intégration pour chaque nouveau collaborateur ayant accès aux systèmes de production
• Processus de départ avec révocation immédiate de tous les accès à la fin du contrat