Architecture de sécurité

Données dans l'Union européenne (Francfort), chiffrement au repos et en transit, sauvegardes quotidiennes.

Diffusion des ressources et protection contre les dénis de service fournies par Vercel ; les fonctions serveur s’exécutent dans la région Francfort (fra1).

PostgreSQL managé ; chiffrement au repos et sauvegardes automatiques assurés par Supabase selon son offre.

Redis serverless, données éphémères uniquement, aucune donnée sensible persistée.

Chiffrement authentifié de ce que le code écrit explicitement par ce module, au 25 septembre 2026 : identifiants de connecteurs, déclarations de soupçon du laboratoire TRACFIN, sauvegarde avant dépôt distant. L’IBAN des notes de frais l’est depuis l’application de la migration 108 en production (25 septembre 2026, 22:30 UTC) ; les IBAN saisis avant restent dans les métadonnées du compte, en clair, jusqu’à ressaisie. Le SIRET n’est pas chiffré. Sans clé, le module refuse de chiffrer comme de déchiffrer : aucune valeur n’est rendue en clair par défaut.

Transport chiffré assuré par Vercel et Supabase, dans les versions du protocole qu’ils prennent en charge.

Les champs sensibles sont chiffrés avec une clé unique détenue par Kontia, pas avec une clé propre à chaque cabinet. Le cloisonnement entre cabinets repose sur tenant_id, la RLS PostgreSQL — effective depuis le 25 septembre 2026, 03:08 UTC (migration 100) — et la résolution du cabinet côté serveur, pas sur des clés distinctes.

Aucune rotation automatique n’est en place. Le format stocké porte l’empreinte de la clé utilisée et les valeurs écrites avec une clé antérieure restent déchiffrables : une rotation est possible, elle reste une opération décidée et exécutée à la main.

Activable par chaque utilisateur depuis ses paramètres, avec une application d’authentification. Le cabinet peut l’imposer aux signataires et administrateurs, ou à tous (Administration › Politique de revue) — réglage ouvert depuis le 25 septembre 2026 ; par défaut, aucun compte n’y est tenu. Ce que la porte a réellement fait : jusqu’à la version 7.99.25, la lecture du réglage échouait en production (droit de table refusé par la base au rôle du navigateur), l’issue devenait « indisponible » et la porte laissait passer avec l’en-tête x-kontia-mfa: indisponible pour seul témoin. Depuis 7.99.25, le réglage est lu côté serveur (clé de service, filtre strict sur le cabinet et le compte du jeton vérifié) et la décision est prise sur le jeton signé.

Le plan Entreprise porte un drapeau « sso » dans le code, mais aucune fédération d’identité n’est implémentée. La connexion se fait par adresse e-mail et mot de passe, avec le second facteur ci-dessus.

Six niveaux : super_admin, admin, manager, collaborateur, stagiaire, lecteur — complétés par un rôle métier qui adapte la navigation.

Une pièce qui sort du cabinet (rapport, liasse, acte, classeur, FEC — 19 routes recensées) ne sort au nom d’un professionnel que si son profil, déclaré par l’administration du cabinet, le dit inscrit au Tableau (verrou du signataire inscrit) ; sinon elle ne sort qu’à l’état de projet. Le bloc de signature imprime qui la remet, sa qualité et son numéro d’inscription tels que déclarés, la société pour laquelle elle sort (art. 12 al. 3 de l’ordonnance n° 45-2138 : signature personnelle et signature sociale) et la date ; exécuter habituellement ces travaux sans inscription est l’exercice illégal de l’art. 20 al. 2. À partir de la version 7.99.25, l’empreinte SHA-256 de la pièce remise est signée en Ed25519 par la clé de la chaîne du journal et rendue avec elle (en-tête X-Kontia-Signature) ; clé absente, la pièce le dit (X-Kontia-Signature-Absente). Kontia n’interroge ni le Tableau de l’Ordre ni la liste de la CNCC.

Signature des travaux

Le cloisonnement des cabinets par la RLS PostgreSQL est effectif depuis le 25 septembre 2026, 03:08 UTC (migration 100), heure inscrite au registre des migrations. Avant cette application, 55 politiques sans filtre l’annulaient sur 55 tables du schéma public. Les faits, ce qui reste ouvert et ce que Kontia ne sait pas sont publiés sur la page de déclaration d’incident.

Déclaration d’incident : politiques d’accès ouvertes

Chaque action enregistre l’horodatage, l’utilisateur, le module et le statut ; l’adresse IP et l’agent lorsque l’appelant les transmet. Les lignes sont chaînées par empreinte SHA-256 : une modification ou une suppression rompt la chaîne, et le scellement, écrit par le cron /api/cron/scellement à chacun de ses six passages (02:15, 04:45, 08:30, 13:30, 18:30 et 23:55 UTC) dès que le journal a avancé, est publié au centre de confiance. Ce ne sont pas les contrôles nocturnes qui scellent : ceux-là tournent à 01:00, 02:30 et 03:45 UTC et ne touchent jamais au registre des scellements.

Chaque jour à 03:20 UTC, un contrôle automatique lit dans le catalogue PostgreSQL l’état réel des politiques et des droits — et non ce que les fichiers du dépôt promettent. Il le compare au contrat de sécurité fixé par les migrations 100 et suivantes (la version en vigueur est publiée dans GET /api/health, champ rls.contratVersion), journalise le passage et alerte par courriel dès qu’un écart apparaît. Son dernier passage est public : GET /api/health, champ rls. Ce contrôle constate, il n’empêche rien, et il ne compare pas la base aux fichiers du dépôt : cette confrontation-là reste manuelle.

Appels API uniquement. Selon les conditions commerciales d’Anthropic, les données envoyées à l’API ne servent pas à entraîner ses modèles.

Kontia n’a négocié aucune clause particulière de non-rétention. La durée de conservation applicable est celle des conditions commerciales standard d’Anthropic — à vérifier par le cabinet avant tout traitement de données sensibles.

Les réponses citent les textes consultés : CGI, BOFiP, jurisprudence, documentation officielle. Un montant qui ne sort d’aucun moteur du dépôt est annoté « à vérifier » dans la réponse.

Pour les actes à valeur légale, une validation humaine nominative est exigée, puis journalisée dans le journal d’audit.

Aucun test d’intrusion externe n’a été commandé. Le dépôt est couvert par une suite de tests automatisés rejouée avant chaque mise en ligne.

La suite de tests et la compilation sont rejouées à chaque poussée et à chaque proposition de modification. Aucun scanner de vulnérabilités n’est branché à ce jour.

Programme à venir — contactez-nous si vous êtes chercheur en sécurité.

Les dépendances sont mises à jour à la main ; aucune veille automatisée n’est branchée à ce jour.