Architecture de sécurité

Ce qui arrive à vos données, de bout en bout :

• Isolation multi-tenant : chaque requête de base de données est limitée par organization_id au niveau ORM ; les tests d'intégration vérifient que les requêtes inter-tenants ne renvoient aucune ligne. Pas d'accès SQL brut pour le code applicatif.

• Journalisation d'audit : chaque mutation administrative (création / mise à jour / suppression de collaborateur, planning, pointage, modification de facturation) est enregistrée avec acteur, cible, valeurs avant/après, adresse IP et horodatage. Rétention selon le niveau : 7 jours (Free) / 1 an (Starter+) / 3 ans (Pro+).

• Sauvegardes : snapshots automatisés RDS quotidiens, conservés 30 jours ; restauration point-in-time à n'importe quelle seconde dans la fenêtre de rétention. Restaurations testées trimestriellement selon le runbook de reprise après sinistre.

• Flux droit à l'effacement : les demandes RGPD / CCPA passent par /admin/identity/users — anonymise les PII des collaborateurs (nom, e-mail, téléphone, modèle biométrique) tout en préservant les données d'attendance agrégées dont le responsable du traitement (votre organisation) a besoin pour la conformité au droit du travail. Voir Politique de confidentialité §4 pour le mécanisme complet.

• Données biométriques (reconnaissance faciale pour le pointage) : collectées uniquement lorsqu'un collaborateur consent explicitement à la première utilisation (article 9, 2, a du RGPD). Les modèles faciaux sont stockés sous forme de hachages unidirectionnels — l'image originale n'est jamais conservée. Les administrateurs d'organisation peuvent désactiver la reconnaissance faciale globalement dans les Règles d'attendance ; le consentement peut être retiré à tout moment dans le profil collaborateur.

Comment nous gérons la sécurité comme une fonction :

• Pratique d'ingénierie : chaque changement de code passe par une revue de pull request avec au moins un reviewer approuvant. Les changements pertinents pour la sécurité (auth, chiffrement, IAM) requièrent un reviewer désigné sécurité supplémentaire.

• Gestion des dépendances : Python via Poetry avec versions verrouillées ; JavaScript via lockfile Bun. Les dépendances vulnérables sont remontées via GitHub Dependabot et traitées par ordre de priorité.

• Contrôle d'accès : l'accès production est en lecture seule par défaut ; l'accès en écriture nécessite un ticket de change documenté. L'offboarding des ingénieurs révoque tous les accès dans les 24 heures suivant le départ.

• Réponse aux incidents : un runbook interne couvre identification → confinement → éradication → récupération → post-mortem. Les incidents de sévérité 1 déclenchent un engagement de notification client sous 24 heures (Politique de confidentialité §6).

• Revue sécurité fournisseurs : chaque sous-traitant ultérieur ajouté (actuellement 5 listés sur /trust/sub-processors) passe par une revue documentée — DPA en place, questionnaire de sécurité examiné, périmètre de données minimisé.

Nous nous engageons sur une feuille de route publique et datée plutôt que sur des revendications rétroactives. Progression en direct :

• SOC 2 Type II — VISÉ T1 2027. Pas encore certifié. Vanta + A-LIGN sélectionnés (décision consignée 2026-05-24). Chronologie publique en 8 jalons sur /trust/soc2 ; rapport émis T3 2027.

• Architecture prête RGPD — audit de confidentialité Wave 1-4 terminé (minimisation des données, droit à l'effacement, portes de consentement, traitement biométrique sous l'article 9). Pas de certification formelle par un régulateur (le RGPD n'a pas d'organisme de certification formel) ; nous fournissons notre DPA sur demande à /trust/dpa.

• ISO 27001 — PAS ENCORE ENGAGÉ. Peut suivre SOC 2 en 2027 ou 2028 selon la demande des prospects entreprise UE.

• Spécifique secteur (HIPAA / PCI-DSS / FedRAMP) — HORS PÉRIMÈTRE aujourd'hui. svdy cible la gestion de la main-d'œuvre PME ; PHI healthcare / cardholder data / charges fédérales gouvernementales sont hors usage jusqu'à inclusion explicite.