Sécurité publique
La sécurité que nous pouvons décrire, rien de plus.
Mesures techniques vérifiables dans le code Cortex : authentification, isolation des dossiers, dépôts, webhooks et limites. Aucune certification n’est inventée.
Ce que cette page est, et n’est pas
Cette page décrit des mécanismes présents dans le code du service au 11 septembre 2026. Elle aide un acheteur ou une fiduciaire à comprendre le contrôle, pas à remplacer un audit.
Elle n’est pas un certificat ISO ou SOC, ni un rapport de test d’intrusion, ni une garantie d’absence d’incident. Les paramètres de votre compte restent dans l’espace connecté.
Accès au compte
La connexion utilise Passport et une session stockée dans PostgreSQL. Le cookie de session est httpOnly ; en production il est aussi marqué sécurisé.
Les mots de passe sont enregistrés sous forme de hachage. Un second facteur TOTP peut être activé ; le secret est chiffré avec AES-256-GCM, avec une clé distincte de celle qui signe la session.
Les mutations authentifiées de l’API (POST, PUT, PATCH, DELETE) sont protégées contre les requêtes intersites par un jeton CSRF. Les chemins publics, les webhooks et les routes d’authentification en sont exemptés.
Séparation des dossiers
Les données métier sont rattachées à un identifiant de dossier (cible_id). Le contexte fiduciaire résout ce dossier pour l’utilisateur connecté avant les lectures.
Cette séparation est applicative. PostgreSQL n’applique pas ici de cloisonnement automatique de type RLS. Un oubli de filtre dans une nouvelle route resterait donc un risque réel — c’est pourquoi nous le disons.
Dépôt des pièces
Un fichier n’est pas accepté sur la seule foi de son extension. Le service compare le type déclaré aux octets magiques du fichier et refuse un contenu incohérent.
La lecture OCR des images passe par Google Cloud Vision, endpoint européen par défaut (eu-vision.googleapis.com). La configuration effective reste à vérifier, sauf preuve opérationnelle versionnée. Cette étape n’est pas un hébergement suisse de l’image.
Paiements et e-mails
Stripe reçoit les événements de paiement. Si le secret de signature webhook est absent, la vérification échoue au lieu d’accepter l’événement.
Les e-mails transactionnels passent par Brevo. La signature des webhooks e-mail est comparée en temps constant.
Où tourne le service
L’application web et le worker tournent sur une machine Infomaniak, en Suisse. Cela décrit l’hébergement des process Cortex, pas tous les traitements.
La base, l’OCR, certaines propositions, le paiement, l’e-mail et le suivi d’erreurs font appel à d’autres prestataires. Leurs pays et clauses restent à confirmer ; ils sont listés dans la politique de confidentialité.
Conservation des fichiers sources
Le code prévoit, par défaut, de supprimer les fichiers sources des documents comptables après deux jours. Ce n’est pas une durée imposée par le RGPD ; c’est un choix technique.
La mise en œuvre effective de ce délai reste à vérifier avant de le présenter comme garanti. Les écritures et données extraites suivent une conservation séparée, tant que le compte existe.
Limites honnêtes
Le limiteur de débit vit dans la mémoire du process. Il n’est pas partagé entre plusieurs machines.
Les en-têtes de sécurité (CSP, HTTPS) sont appliqués par le serveur. Aucune mesure ne permet de garantir l’absence totale d’incident.
Auteur, date et sources
Équipe éditoriale Cortex · mise à jour le 11 septembre 2026. Chaque affirmation de cette page renvoie à un fichier du dépôt ou à une confirmation d’exploitation déjà écrite. Les éléments impossibles à prouver restent hors de cette page.
- Authentification et sessions : server/auth.ts
- 2FA : server/lib/auth/totp.ts
- CSRF : server/middleware/csrf.ts
- Contexte dossier : server/middleware/fiduciary-context.ts
- Dépôts : server/middleware/upload.ts
- OCR : workflows/OCR/OCR.ts
- Stripe : server/integrations/stripe/stripe.ts
- Brevo : server/middleware/brevo-webhook-signature.ts
- Purge sources : common/jobs/gdpr-cleanup.ts