Politique de Sécurité

TOTP (Time-based One-Time Password) disponible pour tous les utilisateurs du portail client. Activation via Profil → Sécurité. Dès l'activation, la vérification d'un code à 6 chiffres est requise à chaque connexion. Compatible Google Authenticator, Authy, Microsoft Authenticator. 10 codes de récupération générés à l'activation.

OAuth2/OIDC via Google et Microsoft, flux Authorization Code PKCE. Le MFA des utilisateurs SSO est délégué au provider d'identité de l'organisation.

Trois rôles natifs : Owner (propriétaire de l'organisation, accès complet), Admin (administration et configuration), Member (opérationnel). Chaque membre dispose en complément de permissions granulaires configurables (canViewAnalytics, canManageAgents, canViewConversations, canViewProspects, canManageTeam, canManageBilling, canExportData, canViewCopilot) permettant de définir des profils de type lecture seule ou personnalisés. La permission canExportData est requise pour l'export SIEM, vérifiée côté serveur (HTTP 403 si absente).

Job quotidien automatique : avertissement à 60 jours d'inactivité (événement INACTIVITY_WARNING dans le SIEM). Révocation automatique de toutes les sessions à 90 jours (RGPD Art. 32 / DORA Art. 9). Chaque événement est horodaté dans l'audit trail.

TLS 1.2 / 1.3 enforced sur toutes les connexions. HTTPS obligatoire, HSTS activé (max-age=31536000; includeSubDomains; preload). HTTP redirigé automatiquement vers HTTPS.

Données sensibles (credentials CRM, tokens OAuth, fichiers prospects) : chiffrement applicatif AES-256-GCM avant persistance. Base de données PostgreSQL : AES-256 au niveau infrastructure (Neon). Backups : AES-256.

RS256, rotation automatique toutes les 7 jours. Clé primaire + clé backup maintenues pour haute disponibilité multi-instances. Révocation immédiate via cache LRU des tokens invalidés. Jamais transmises en clair.

Format godia_live_<base64url-32bytes> (ou godia_test_ pour l'environnement de test) : seul le hash SHA-256 est persisté en base. La clé en clair n'est affichée qu'une seule fois à la création, jamais stockée ni récupérable.

Global : 3 000 req / 15 min par IP (fenêtre glissante). Login : 5 tentatives / 15 min, blocage temporaire automatique de 30 minutes. API v1 : 1 000 req / heure par clé. Export SIEM : 10 exports / heure par organisation.

HSTS (max-age=31536000; includeSubDomains; preload), X-Content-Type-Options: nosniff, Content-Security-Policy strict activés sur toutes les réponses. X-Frame-Options est défini à DENY pour le portail client (anti-clickjacking) et à ALLOWALL pour les widgets de chat afin de permettre leur intégration cross-domain volontaire chez les sites clients (encadré par CSP frame-ancestors).

Token synchronisé (sessionStorage) + validation côté serveur sur toutes les routes mutantes. Les requêtes GET sont exemptées.

Liste blanche stricte des origines autorisées. Seules les APIs du widget de chat sont ouvertes volontairement pour permettre l'intégration sur les sites clients.

4 tables non modifiables via l'interface : auth_events (connexions, MFA, révocations), rétention 90 jours. access_logs (accès aux données sensibles, actions admins), rétention 90 jours. client_activity_logs (actions dans le portail), rétention 30 jours. alert_history (alertes sécurité), rétention 90 jours.

Format JSON et CSV depuis le portail client, compatible Elastic, Splunk, QRadar, Microsoft Sentinel. Filtres par période et type d'événement. Isolé par organisation côté serveur. Permission canExportData requise. Rate limit anti-exfiltration : 10 exports / heure.

5 règles d'alerte actives dans le moteur SIEM : tentatives de brute force login, violations CSRF, violations d'isolation tenant, tentatives de tokens invalides, activité suspecte. À cela s'ajoute un job quotidien dédié de détection d'inactivité prolongée (60j / 90j). Notification email immédiate via Mailjet dès déclenchement.

npm audit exécuté automatiquement à chaque push et pull request via GitHub Actions (workflow security-audit.yml), et de manière hebdomadaire planifiée (cron). Le pipeline échoue si une vulnérabilité de sévérité Haute ou Critique est détectée. Rapport JSON archivé 30 jours.

Critique : 48h / Haute : 7 jours / Moyenne : 30 jours / Faible : prochaine release.

Pentest externe par un tiers certifié planifié H2 2026. Tests de sécurité internes réalisés à chaque release majeure.

Programme officiel disponible sur notre page dédiée. Signalement via legal@godia.ai (SLA de réponse : 48h pour toute vulnérabilité signalée).

Zod (schémas stricts TypeScript) sur 100 % des routes backend. Rejet systématique des données non conformes au schéma attendu.

Drizzle ORM, requêtes paramétrées uniquement. Aucune concaténation de chaînes SQL dans la base de code.

Systématiques sur chaque pull request avant merge en production.

Variables d'environnement Railway, jamais dans le code source ni le dépôt Git. Credentials OAuth et CRM chiffrés AES-256-GCM avant persistance.

Environnements production et développement séparés, base de données et variables d'environnement distinctes. Aucun accès croisé prod/dev.

RTO (Recovery Time Objective) contractuel : 4 heures (pire cas, restauration complète depuis artefacts). Redémarrage applicatif automatique typique observé via Railway : < 15 minutes (incidents applicatifs courants, sans intervention humaine). RPO (Recovery Point Objective) : 24 heures, aligné sur la fréquence des sauvegardes Neon (restauration point-in-time sub-heure en pratique pour les incidents applicatifs).

99,5 % mensuel garanti, 99,9 % contractualisable. Voir notre SLA complet. Statut en temps réel : status.godia.ai.

Backups quotidiens chiffrés AES-256, managés par Neon. Rétention conforme au plan Neon souscrit. Réplication multi-zone UE.

En cas d'indisponibilité du moteur IA, les données existantes (conversations, prospects, analytics) restent accessibles. Messages d'erreur explicites retournés, aucun fallback silencieux vers un autre fournisseur.

Détection via alertes SIEM → qualification interne → notification client (SLA 4h pour incidents critiques) → remédiation → rapport post-incident (REX).

Disponibles dans le portail client : création, suivi et clôture depuis l'interface. Chaque incident documenté avec chronologie, impact et mesures correctives.

Procédure documentée : notification des autorités de contrôle compétentes (CNIL France, CNPD Luxembourg) dans les 72 heures en cas de violation de données à caractère personnel (RGPD Art. 33). Notification email aux organisations affectées via Mailjet, déclenchée depuis le portail d'administration.

L1 : ticket in-app → L2 : support@godia.ai → L3 : direction technique → L4 : urgence sécurité legal@godia.ai (SLA 4h).

Analyse d'impact formalisée (DPIA-GODIA-2026-001 v1.0, mars 2026), 4 traitements documentés : (1) conversations IA, (2) gestion des prospects, (3) authentification & journalisation SIEM, (4) clés API développeurs. Disponible sur demande à legal@godia.ai. Prochaine révision : mars 2027.

Registre formel et opérationnel couvrant 6 prestataires ICT au titre de l'Art. 28 DORA : Railway (infrastructure applicative), Neon (base de données), Mistral AI SAS (moteur IA, France), Mailjet/Sinch (emails transactionnels, France), Google LLC (OAuth), Microsoft Corporation (OAuth). Disponible sur demande.

Rapports post-incident accessibles depuis le portail client, signalement d'incident intégré, suivi et clôture depuis l'interface.

JSON/CSV depuis le portail, compatible avec les outils SIEM du marché (Elastic, Splunk, QRadar, Microsoft Sentinel).

Convention de traitement disponible à la signature avant tout démarrage de relation contractuelle. Contact : legal@godia.ai.

Engagement contractuel : export complet des données fourni sur demande sous 30 jours en cas de résiliation. Suppression définitive des données sous 60 jours après la fin du contrat (sauf obligation légale de conservation). Aucun lock-in propriétaire : PostgreSQL standard, données exportables en JSON/CSV via le portail. Détails par prestataire ICT documentés dans le registre DORA.