Chiffrement de bout en bout : ce que ça signifie pour un cabinet

Trois concepts qui ne disent pas la même chose

Parler de « chiffrement » sans préciser ce qu'on chiffre, quand et où, n'a pas de sens. Trois notions coexistent, qui protègent contre des risques différents.

1. Chiffrement en transit (TLS / HTTPS)

Ce que c'est : vos données sont chiffrées pendant leur transfert entre deux points (votre navigateur et le serveur, par exemple). Standard moderne : TLS 1.3.

Ce que ça protège : une interception réseau (Wi-Fi public, homme du milieu). Personne ne peut lire ce qui passe sur le câble.

Ce que ça ne protège pas : ce qui se passe sur le serveur de destination — c'est là que les données sont déchiffrées pour être traitées.

2. Chiffrement au repos

Ce que c'est : les données sont chiffrées quand elles sont stockées (sur un disque, dans une base). Standard moderne : AES-256-GCM.

Ce que ça protège : un vol physique du disque dur, un accès illégitime à la base (fuite technique, employé malveillant sans accès aux clés).

Ce que ça ne protège pas : les données en train d'être traitées en mémoire vive (elles sont en clair pendant le traitement).

3. Chiffrement de bout en bout (E2EE)

Ce que c'est : seuls les deux extrémités (l'émetteur et le destinataire final) possèdent les clés. Le serveur intermédiaire ne peut jamais lire le contenu.

Ce que ça protège : tout — y compris l'éditeur du service lui-même, les autorités qui le forceraient à remettre des données.

Le problème pour une IA : si le serveur ne peut pas déchiffrer les prompts, il ne peut pas non plus les traiter avec un LLM. Le E2EE est techniquement incompatible avec le modèle économique et fonctionnel d'une IA.

Ce qu'offre concrètement Consia

Nous n'annonçons pas un chiffrement de bout en bout — nous expliquons ce que nous faisons réellement.

Niveau 1 — En transit

Entre votre navigateur et nos serveurs :

• TLS 1.3 obligatoire
• Certificats renouvelés automatiquement (autorité de certification reconnue)
• HSTS activé (empêche toute communication en HTTP)

Entre nos serveurs et notre fournisseur de modèle de langage :

• TLS 1.3 via le SDK officiel du fournisseur
• Authentification par compte de service dédié
• Traffic interne au réseau du fournisseur en région française

Entre nos serveurs et notre base de données :

• TLS 1.3 avec certificats pinned
• Authentification forte

Niveau 2 — Au repos

Dans la base de données :

• Chiffrement disque natif (AES-256) de l'infrastructure de stockage
• En supplément, chiffrement applicatif des champs sensibles :
  • Titres de conversation : AES-256-GCM avec clé gérée séparément
  • Contenu des messages (parts) : AES-256-GCM
  • Pièces jointes : AES-256-GCM

Double chiffrement = si quelqu'un compromet la base, il a encore besoin de compromettre l'environnement applicatif pour avoir les clés.

Niveau 3 — En traitement

C'est le niveau où aucun outil d'IA ne peut offrir de E2EE.

Pendant qu'un prompt est traité par le LLM :

• Il est en mémoire vive sur nos serveurs applicatifs (~5 secondes)
• Il est en mémoire vive chez notre fournisseur d'infrastructure IA (~5 secondes)

Ces données sont protégées par :

• L'isolation des processus (Linux namespaces, conteneurs)
• L'accès administratif restreint et journalisé
• Les engagements contractuels de notre fournisseur d'infrastructure IA (pas d'utilisation pour l'entraînement, pas de conservation au-delà du traitement)

Ce qui n'est pas possible aujourd'hui avec les technologies actuelles : qu'un fournisseur IA traite un prompt chiffré sans jamais le déchiffrer. Le confidential computing progresse mais n'est pas encore opérationnel sur les LLM à cette échelle.

Ce que ça signifie pour vous concrètement

Contre une écoute réseau → protégé

Si quelqu'un tente d'intercepter votre trafic (Wi-Fi publics, ISP malveillant), il ne voit que du chiffré. ✅

Contre un vol physique de disque → protégé

Si un disque de notre base était volé ou saisi physiquement, les données sont chiffrées en base. Sans la clé applicative (gérée séparément), illisibles. ✅

Contre une attaque sur la base seule → protégé

Si la base était compromise (admin malveillant, faille système), les données sont en plus chiffrées applicativement. La clé est ailleurs. ✅

Contre une compromission simultanée de la base + de l'environnement applicatif → non protégé

Scénario très improbable mais théoriquement possible. Les deux systèmes ont des contrôles d'accès indépendants. ⚠️

Contre une réquisition judiciaire française → non protégé

Sous mandat judiciaire français, nous pouvons être contraints de remettre les données déchiffrées des utilisateurs visés. C'est le droit français. ℹ️

Contre une réquisition étrangère (CLOUD Act) → risque réduit mais non nul

Voir notre article dédié sur le CLOUD Act. Le risque est réduit par notre choix d'infrastructure européenne sous contrat de droit européen, mais pas éliminé à 100 %.

Contre une faille de sécurité chez notre hébergeur → protégé partiellement

Les prompts en traitement (5 secondes) pourraient théoriquement être exposés. Les prompts stockés chez nous n'y transitent pas.

Ce qu'une IA juridique ne peut pas garantir aujourd'hui

Par honnêteté, voici ce qu'aucune IA juridique ne peut offrir en 2026 :

• E2EE complet des prompts (incompatible avec le traitement LLM)
• Zero-knowledge côté éditeur (nous pouvons techniquement lire les prompts en clair pour répondre à une demande judiciaire)
• Inviolabilité absolue face à une faille combinée (tous les systèmes ont des vecteurs d'attaque théoriques)

Si une IA juridique prétend offrir ces garanties, creusez : soit elle utilise des termes techniques abusivement, soit elle repose sur des technologies encore émergentes (TEE, FHE) avec des compromis en qualité.

Comment vérifier pour votre outil actuel

Posez à votre fournisseur ces 5 questions techniques :

1. Quel protocole utilisez-vous pour les communications (TLS 1.x) ?
2. Comment sont chiffrées mes données au repos (algorithme, clé, rotation) ?
3. Y a-t-il un chiffrement applicatif en plus du chiffrement disque natif ?
4. Qui a accès aux clés de chiffrement ? Combien d'administrateurs humains ?
5. Quelle est votre politique en cas de réquisition étrangère (notification, contestation) ?

Un fournisseur sérieux répond par écrit en 48 h avec des détails techniques précis. Un fournisseur qui fuit ou simplifie excessivement est à écarter.

Pour aller plus loin

• Anonymisation des prompts : comment ça marche techniquement — le cycle de vie d'un prompt
• Pourquoi votre IA juridique doit être hébergée en Europe — le volet hébergement
• Cloud Act et IA : ce que tout avocat doit savoir — le volet réquisition étrangère
• Notre page sécurité — détail technique complet

Le chiffrement est une discipline technique, pas un argument marketing. Un cabinet qui veut des garanties réelles doit exiger des réponses techniques précises — et savoir lire la différence entre TLS, chiffrement au repos et E2EE.