PParselex ← Retour à l'accueil

Architecture de sécurité

Dernière mise à jour : 7 octobre 2026

La sécurité par l’architecture, pas par la promesse. Parselex repose sur un réseau mesh Zero-Trust conçu pour les exigences éthiques et de conformité de la pratique juridique. Cette page décrit les mécanismes concrets qui protègent les données couvertes par le secret professionnel de l’avocat — ce que fait notre architecture, et ce qu’elle laisse délibérément à la charge de l’utilisateur.

1. Isolation réseau (LexConnect)

Les espaces de travail Parselex n’existent pas sur l’internet public. L’accès est assuré exclusivement par LexConnect, notre client réseau Zero-Trust, qui établit un tunnel mesh chiffré entre un appareil authentifié et l’espace de travail. Nos nœuds d’inférence ne portent aucune adresse IP publique, ce qui les rend invisibles au balayage à l’échelle de l’internet comme aux activités DDoS. Aucun port exposé, aucun point d’entrée partagé : chaque connexion est un tunnel chiffré point à point, et les droits d’accès suivent le principe du moindre privilège.

2. Anonymisation des données personnelles côté poste (edge) — le pare-feu éthique

Avant qu’un document ne quitte votre appareil, le client LexConnect peut retirer les données personnelles identifiables et les remplacer par des jetons déterministes : le nom d’un client devient [PERSON_1], une partie adverse devient [ENTITY_A], et les identifiants tels qu’un numéro de sécurité sociale ou un numéro de compte bancaire deviennent [REDACTED_SSN] ou [REDACTED_ACCOUNT]. Seul le texte sanitisé entre dans le tunnel chiffré : nos moteurs d’inférence raisonnent ainsi sur la structure et la logique d’un dossier sans jamais voir les identités confidentielles qui le sous-tendent. Sur le chemin du retour, le client réassemble les identités d’origine localement, et le document final s’affiche complet.

Les identités étant dé-identifiées dès le poste, les serveurs ne traitent que des jetons sanitisés et non des données personnelles. Cette conception répond à la norme des « efforts raisonnables » qu’attendent les règles déontologiques de la profession lorsque des informations clients confidentielles sont manipulées, et elle réduit l’exposition du cabinet en matière de protection des données lorsque le travail s’effectue dans des cadres tels que le GDPR ou le CCPA. Un dictionnaire personnalisé d’étiquettes d’entités (par exemple, marquer une partie comme [CLIENT] et une autre comme [OPPOSING_COUNSEL]) préserve les distinctions dont l’IA a besoin pour produire des livrables exacts.

3. Souveraineté des données et traitement éphémère

Vos dossiers ne servent jamais à entraîner un modèle public — point final. Les requêtes et les documents sont traités dans des sessions éphémères : le contexte de travail existe en mémoire pendant la durée de la session et est détruit à la fermeture de celle-ci. Nous ne consignons pas le contenu des requêtes et nous ne conservons pas les documents après traitement. La propriété intellectuelle de votre cabinet reste la propriété intellectuelle de votre cabinet.

4. État du poste et identité

L’accès exige plus qu’un mot de passe. Le client LexConnect vérifie la santé de l’appareil, impose l’authentification unique (SSO) associée à une authentification multifacteur (MFA) — notamment Microsoft Entra ID et Okta — et coupe automatiquement le tunnel si un appareil échoue à un contrôle de l’état du poste (device posture), se connecte depuis un réseau non fiable ou semble provenir d’une juridiction non autorisée. Les sessions sont éphémères par conception : la fermeture du client démonte le tunnel.

5. Audit des accès sans consignation du contenu

Pour la surveillance de la sécurité et la facturation, nous enregistrons qui s’est connecté, depuis quelle classe d’appareil et quand. Nous n’enregistrons pas la charge utile. Les métadonnées de connexion et le contenu des sessions sont séparés cryptographiquement : un journal d’accès ne peut donc jamais être rejoué sous forme de transcription d’un travail couvert par le secret professionnel.

6. Notre modèle de menace

Nous publions ce contre quoi notre architecture protège — et ce qui relève de la responsabilité de l’utilisateur — car la transparence vaut mieux qu’un badge.

Protégé contre :

Hors de notre contrôle (responsabilité de l’utilisateur) :

7. Le client LexConnect

LexConnect se connecte à un espace de travail de cabinet, vérifie l’appareil et maintient le tunnel chiffré pendant toute l’utilisation de Parselex. Il applique un filtrage à la couche DNS (prévention des fuites de données, DLP) pour empêcher toute exfiltration accidentelle vers des API tierces non autorisées, et il démonte la session dès qu’une politique est enfreinte. Pour les avocats en solo et les petits cabinets, Parselex est étendu pour prendre en charge un déploiement « bring-your-own-infrastructure » : l’espace de travail s’exécute dans le compte cloud du cabinet lui-même et LexConnect fournit la couche sécurisée par-dessus, de sorte que la souveraineté des données ne dépend plus du tout de notre hébergement.

8. Questions de sécurité

Pour signaler une vulnérabilité, demander notre documentation de sécurité ou soumettre une question relative à cette page, écrivez à contact@parselex.app. Nous traitons les signalements de divulgation responsable en priorité et accusons réception de chaque signalement.

© 2026 Parselex — Plateforme d'Intelligence Documentaire Juridique