Sécurité et architecture technique

Conformitiel est hébergée exclusivement sur des infrastructures françaises certifiées, sans aucune donnée ni traitement hors de l'Union européenne.

Toutes les données sensibles sont chiffrées au repos et en transit. Aucun accès en clair par l'équipe Conformitiel n'est possible sur les données métier des cabinets.

Chaque cabinet est une organization logique. Toutes les requêtes SQL sont filtrées côté service par organizationId — impossible d'accéder aux données d'un autre cabinet, même en cas de bug de contrôleur.

• 31 tables sur 42 portent la colonne organization_id avec FK ON DELETE CASCADE.
• Les services async Drizzle valident systématiquement le filtre dans le WHERE — audit codé.
• Routes API : appel obligatoire à getRequiredAuth() puis requirePermission(role, module, action, organizationId).
• Les tokens Bearer API sont scopés à une organization unique.

Deux familles de jetons, jamais interchangeables

• cft_ (jeton cabinet) : créé pour un utilisateur d'un cabinet, hérite de son rôle RBAC et n'ouvre que les données de ce cabinet. Seul jeton capable de lire ou produire des données LCB-FT (fiches, criblages, audits, documents signés).
• cfp_ (jeton partenaire intégrateur) : limité à /api/partner/* avec des scopes granulaires — provisionner un cabinet, inviter ses administrateurs, lire ses compteurs d'usage. Il n'accède jamais au contenu LCB-FT des cabinets (isolation stricte v1).
• Cross-usage refusé à deux niveaux : le middleware Edge, puis les auth-helpers de chaque route (401 explicite, tentative journalisée côté serveur).

Traçabilité des jetons

• Création et révocation d'un jeton cft_ : entrées API_TOKEN_CREATED / API_TOKEN_REVOKED dans le journal de contrôle chaîné du cabinet. Jetons cfp_ : créateur, dates de création, de révocation et de dernier usage conservés sur l'enregistrement du jeton.
• Chaque appel authentifié met à jour la date de dernier usage du jeton. Les actions d'un partenaire sur un cabinet (provisioning, invitation, archivage) sont inscrites dans le journal du cabinet concerné avec l'identifiant du partenaire et du jeton.
• Signatures déclenchées par API : lorsqu'un document signé (fiche validée, rapport d'audit, dossier consolidé) est produit via un jeton cft_, la signature enregistre la méthode jeton API avec le nom et le préfixe du jeton, imprimés dans le PDF (« via jeton API « Prod » (cft_xxxxxxxx…) ») et repris dans le journal (authMethod, apiTokenId). Le signataire reste l'utilisateur porteur du jeton.

4 rôles couvrent 22 modules fonctionnels, chacun avec des actions précises (read, write, delete, export, validate_hierarchique).

Les 22 modules sont paramétrables par override par organization via l'écran /admin/permissions. Résolution en 3 niveaux : override org → override global → matrice statique.

Chaque action opposable (criblage, fiche vigilance créée, validation, gel, DS Tracfin, signature électronique...) est loggée dans la table control_logs avec :

• Horodatage UTC (précision millseconde)
• Utilisateur ayant déclenché l'action (ou null pour les actions externes tracées comme le portail collecte)
• Type d'action + catégorie fonctionnelle
• Metadata JSON (contexte : ids, hashes, résultats)
• Hash SHA-256 chaîné avec le log précédent — la modification d'un log casse la chaîne, détectable par le job cron /api/admin/verify-chain

Base juridique : Art. L.561-12 CMF (conservation 5 ans opposable en cas de contrôle ACPR / autorité de tutelle).

Les documents opposables (dossiers LCB-FT PDF, rapports criblage, fiches vigilance PDF, PDFs signés électroniquement) sont stockés en mode WORM (Write Once Read Many) avec S3 Object Lock en mode COMPLIANCE.

• Rétention 5 ans obligatoire (Art. L.561-12 CMF) — impossible de supprimer avant expiration, même pour un admin OVH.
• Empreinte SHA-256 calculée avant upload et stockée en DB — vérifiable par recalcul après téléchargement.
• Horodatage RFC 3161 optionnel via TSA FreeTSA (pour les audits individuels).
• Dédup 24h par contenu : un même contenu re-généré ne consomme pas d'espace en double.
• Soft-delete au niveau DB uniquement — le fichier S3 reste immuable pour audit historique.

Les cabinets peuvent uploader un fichier CSV ou XLSX pour créer en masse des fiches de vigilance + lancer le criblage automatique. Le module encadre le traitement pour éviter tout dépassement de quota, toute fuite de données ou tout blocage silencieux.

• Limites strictes : 30 Mo par fichier, 10 000 lignes max par batch. Au-delà, fractionner en plusieurs imports.
• Consentement RGPD explicite : case à cocher obligatoire à l'upload attestant de la base légale de traitement (Art. 6.1.b/c RGPD — exécution d'un contrat ou obligation légale LCB-FT). Trace horodatée avec userId + IP + user-agent dans le log de contrôle interne.
• Guard quota strict : le worker refuse toute création de fiche ou criblage qui dépasserait la limite mensuelle du plan. Lignes excédentaires marquées quota_exceeded dans le rapport final — pas de dépassement facturé silencieusement.
• Détection de doublons : SIREN pour PM, nom+prenom pour PP. Aucune fiche recréée sur un client déjà en base — la ligne est marquéeskipped avec lien vers la fiche existante.
• Watchdog anti-blocage : un cron (5 min) détecte les batches bloqués > 15 min (crash worker, deploy, OOM) et les marque failed. Reprise possible via bouton dédié — les fiches déjà créées sont préservées.
• Annulation propre : le worker check le statut du batch toutes les 10 lignes et s'arrête sans écraser les résultats déjà enregistrés.
• Rapport CSV téléchargeable : ligne par ligne avec statut final + message + fiche créée. Rétention 5 ans pour audit trail cabinet (Art. L.561-12 CMF).
• Log de contrôle interne : événements IMPORT_UPLOADED, IMPORT_EXECUTED, IMPORT_COMPLETED, IMPORT_RETRIED tous horodatés et signés dans la chaîne SHA-256.
• Isolation multi-tenant : chaque ligne et chaque fiche créée est indexée sur organizationId — impossible qu'un import d'un cabinet contamine un autre.

À la validation d'une fiche vigilance, l'app crée automatiquement 1..N recriblages récurrents pour le client + chaque BE identifié. Ce module réalise la vigilance constante exigée par l'Art. L.561-6 CMF sans intervention manuelle du cabinet.

• Fréquence adaptée : dérivée du niveau de vigilance (annuel / semestriel / trimestriel selon le risque). Modifiable ligne par ligne pour les cas particuliers (PPE, hits confirmés).
• Guard quota strict : le worker refuse tout criblage qui dépasserait la limite mensuelle du plan. Aucun dépassement facturé silencieusement — le job est repoussé de 24h pour retry le lendemain.
• Throttle par source externe (INSEE 5 req/s, INPI 3 req/s, BODACC 5 req/s, OpenSanctions 8 req/s — marge 30% sous les limites publiques). Aucun risque de bannissement des APIs officielles même sur des cabinets à plusieurs milliers de clients.
• Détection delta : le worker compare les hits aux résultats du run précédent. Toute nouvelle source qui produit un hit déclenche une alerte delta + email au responsable LCB-FT + webhook screening.delta_detected pour intégration SI.
• Actions immédiates suggérées dans l'email : qualifier (faux positif / vrai hit), déclencher le gel Art. L.562-1 CMF si nécessaire, préparer la déclaration Tracfin.
• Audit trail complet : chaque run est loggé en control_logs (RECURRING_SCREENING_NEW_HIT), chaque criblage est persistant dans screening_alerts pendant 5 ans (Art. L.561-12 CMF).
• Rapport annuel exportable (CSV) avec synthèse + détail par alerte : justifie le respect de la vigilance constante en cas de contrôle ACPR / CSN / CNB / AMF.
• Résilience : job en erreur → repoussé de 6h pour retry automatique au prochain cron. Aucune perte silencieuse.

Détails techniques : Documentation API partenaires — Surveillance continue.

Chaque cabinet peut configurer 1..N endpoints qui recevront un POST HTTPS signé à chaque événement Conformitiel (import batch terminé, hit criblage détecté, signature complétée, audit fini). Format et garanties conçus pour une intégration sûre côté SI partenaire.

• HTTPS uniquement — refus des URL non-TLS à la création.
• Signature HMAC-SHA256 pattern Stripe : X-Conformitiel-Signature: t=timestamp,v1=hex. Le destinataire valide en recalcul + comparaison timing-safe.
• Anti-replay 5 min : le timestamp signé permet de rejeter toute requête plus vieille de 5 minutes.
• Secret révocable : rotation en 1 clic depuis les paramètres cabinet — l'ancien secret devient invalide immédiatement.
• Timeout 10s + retry exponentiel : 4 tentatives max (immédiat, 1 min, 10 min, 1 h). Codes 5xx et 429 déclenchent un retry, 4xx un abandon explicite (marqué abandoned).
• Dédup côté destinataire : chaque événement porte un X-Conformitiel-Event-Id stable — un même événement retenté aura toujours le même ID.
• Historique des livraisons : les 50 dernières tentatives par endpoint sont consultables (statut, HTTP, latence, message d'erreur) dans les paramètres cabinet.
• Circuit breaker souple : compteur consecutiveFailures affiché dans l'UI pour alerter le cabinet si un endpoint est systématiquement KO.

Détails d'intégration + exemples de validation en Node.js / Python : Documentation API partenaires — Webhooks.

Les fonctionnalités d'assistance IA (synthèses de vigilance, brouillons de déclaration de soupçon, analyse de graphe portefeuille) reposent sur un modèle Bring Your Own Key (BYOK) : chaque cabinet fournit sa propre clé API auprès du fournisseur qu'il a choisi (Anthropic ou OpenAI, à ce jour).

• Aucune clé plateforme : Conformitiel ne détient aucune clé IA partagée. Il n'y a pas de compte fournisseur IA au nom de l'éditeur qui servirait tous les cabinets.
• Chiffrement au repos AES-256-GCM : la clé du Client est chiffrée dès sa réception, IV aléatoire 12 bytes par enregistrement, auth tag 16 bytes vérifié au déchiffrement. Secret de chiffrement stocké uniquement en variable d'environnement du process Node, jamais en base.
• Transit TLS 1.2+ : appels sortants versapi.anthropic.com ou api.openai.com exclusivement en HTTPS, via fetch natif.
• Aucune conservation persistante : le contenu de la requête et de la réponse IA n'est jamais stocké côté Conformitiel. Seules les métadonnées techniques (timestamp, statut HTTP, nombre de tokens) sont conservées pour la facturation et l'audit interne.
• Aucun ré-entraînement : Conformitiel n'entraîne aucun modèle. Les données transitant par l'éditeur ne sont ni ré-utilisées, ni agrégées.
• Révocation immédiate : depuis Paramètres > IA, un dirigeant peut supprimer la clé du cabinet. Toutes les fonctions IA sont désactivées immédiatement pour l'ensemble de l'organisation.
• Acceptation opposable : à la première activation, le système enregistre une acceptation horodatée (utilisateur, IP, empreinte SHA-256 du texte des conditions IA) dans une table immuable dédiée.

Qualification juridique : au sens de l'Art. 28 RGPD, les fournisseurs IA ne sont PAS des sous-traitants ultérieurs de Conformitiellorsqu'ils sont sollicités via la clé du Client. Le Client est responsable de traitement direct vis-à-vis d'eux ; il lui appartient d'évaluer la nécessité d'une AIPD Art. 35 et d'encadrer les transferts hors UE (SCC 2021/914, Data Privacy Framework 2023/1795). Détails : Politique de confidentialité section 12bis et DPA Annexe 3.

Pour l'intégrateur : l'IA est optionnelle. La totalité du service LCB-FT (audits SIREN, criblage multi-registres, fiches de vigilance, dossier d'inspection) fonctionne sans aucun appel IA. Un partenaire qui embarque Conformitiel dans son propre logiciel n'a rien à provisionner côté IA — c'est le cabinet utilisateur qui active, sur son propre compte fournisseur, s'il le souhaite.

En cas d'incident de sécurité (fuite de données, indisponibilité majeure, compromission suspectée), notre procédure interne s'engage sur les délais suivants :

• Détection → confinement : < 1h (bascule DNS, révocation de tokens, isolation d'instance).
• Communication aux clients impactés : < 24h, email direct + bandeau dans l'app.
• Notification CNIL : < 72h en cas de fuite de données personnelles (RGPD art. 33).
• Post-mortem public : < 7 jours ouvrés, sur /status (à venir).

Signalement responsable de vulnérabilité : security@conformitiel.fr — nous nous engageons à répondre sous 48h ouvrées. Programme bug bounty non public à ce stade, hall of fame en préparation.

Conformitiel agit en tant que sous-traitant du cabinet client (Art. 28 RGPD). Le cabinet reste responsable de traitement pour les données KYC/LCB-FT qu'il collecte auprès de ses propres clients.

• DPA modèle signable en ligne (Data Processing Agreement).
• Liste des sous-traitants ultérieurs (OVH, Resend, Sentry, Stripe pour billing).
• Politique de confidentialité détaillée.
• Droits d'accès / rectification / effacement : demande viaprivacy@conformitiel.fr — traité sous 30 jours.
• Registre des traitements disponible sur demande auprès du DPO (contact ci-dessus).

Note : les données LCB-FT (fiches vigilance, criblages, gels) relèvent d'une obligation légale de conservation 5 ans (Art. L.561-12 CMF) qui prime sur le droit à l'effacement RGPD pour la durée de conservation légale.