Partage de fichiers chiffré de bout en bout : architecture, sécurité et souveraineté

THEMIOT Informatique / Version 1.0 / Juin 2026

1. Synthèse

PrivCloud est une plateforme européenne de partage sécurisé de fichiers, d'espaces collaboratifs chiffrés et de signature électronique, développée et opérée par THEMIOT Informatique, entreprise française indépendante spécialisée en cybersécurité et architecture système. Elle repose sur trois piliers indissociables : chiffrement de bout en bout avec mécanismes résistants aux menaces quantiques, architecture zero-knowledge et infrastructure souveraine durcie.

Dans un contexte marqué par l'intensification des cybermenaces, des tensions géopolitiques croissantes, le durcissement du cadre réglementaire européen (RGPD, NIS2, DORA) et la prise de conscience des risques liés aux législations extraterritoriales américaines (Cloud Act, FISA), les organisations ont besoin de solutions dont la confidentialité repose sur des garanties cryptographiques, et non uniquement sur des engagements contractuels.

Par conception, PrivCloud rend tout accès aux contenus en clair impossible, y compris par ses propres opérateurs. Les fichiers sont chiffrés localement sur l'appareil de l'utilisateur avant tout envoi vers nos serveurs. Seuls les destinataires autorisés disposent des clés de déchiffrement. L'infrastructure elle-même est déployée sur un environnement durci, segmenté en VLANs isolés, protégé par cinq couches de sécurité et supervisé en temps réel.

2. Le défi : protéger les données sensibles dans un monde numérique hostile

2.1 Un cadre réglementaire européen en renforcement

Le Règlement Général sur la Protection des Données (RGPD, 2016/679) impose depuis 2018 des obligations strictes sur le traitement des données personnelles. La conformité n'est plus optionnelle : les sanctions peuvent atteindre 4 % du chiffre d'affaires mondial annuel.

• NIS2 (directive sur la sécurité des réseaux et de l'information, 2022) : élargit les obligations de cybersécurité à de nombreux secteurs.
• DORA (Digital Operational Resilience Act, 2022) : impose des exigences de résilience numérique pour le secteur financier.
• Secret professionnel (avocats, experts-comptables, médecins) : obligation déontologique renforcée par des risques de sanctions ordinales et juridiques.

2.2 La menace réelle sur les transferts de fichiers

• Données exposées sur les serveurs du fournisseur : les plateformes de partage grand public chiffrent les données en transit (HTTPS/TLS) et parfois au repos, mais conservent les clés de déchiffrement. Un accès non autorisé aux serveurs, une réquisition judiciaire ou une fuite de données expose intégralement vos contenus.
• Exposition aux législations extraterritoriales : les fournisseurs hébergés par des entreprises américaines (même si les centres de données sont en Union Européenne) sont soumis au Cloud Act (2018) et au FISA, qui autorisent les autorités américaines à accéder aux données sans nécessairement en informer les personnes concernées.
• Absence de traçabilité : les solutions informelles (email, messagerie instantanée) ne permettent aucun audit des accès ni aucune révocation des droits après envoi.
• Menaces futures sur les données actuelles : la stratégie dite « harvest now, decrypt later » consiste à capturer des données chiffrées aujourd'hui en anticipant les progrès matériels (notamment les ordinateurs quantiques) qui pourraient permettre de les déchiffrer dans quelques années.

2.3 La limite des approches contractuelles

Un engagement contractuel peut encadrer un usage. Il ne supprime pas la possibilité technique d'accéder aux données. La protection la plus robuste repose sur l'architecture cryptographique elle-même : lorsque les contenus sont chiffrés côté client et que les clés de déchiffrement ne sont pas accessibles au fournisseur, la confidentialité ne dépend plus d'une promesse, d'une procédure interne ou d'un cadre contractuel. Elle repose sur une contrainte technique vérifiable.

3. Architecture technique et modèle de sécurité

3.1 Principe fondamental

L'architecture de PrivCloud est conçue pour empêcher tout accès opérateur aux contenus en clair, y compris par l'éditeur du service. Ce n'est pas une question de confiance dans nos équipes ou de robustesse de nos politiques internes. C'est une contrainte cryptographique imposée par notre architecture : les clés de déchiffrement de vos contenus ne transitent jamais par nos serveurs et ne sont jamais accessibles à notre infrastructure.

3.2 Flux de chiffrement

1. Le fichier est chiffré localement dans le navigateur avec AES-256-GCM. La clé de chiffrement est générée localement et n'est jamais transmise au serveur.
2. Le fichier chiffré est envoyé par chunks adaptatifs de 6 à 50 Mo. Le serveur préinitialise le multipart et autorise chaque part ; la page navigateur partage une fenêtre bornée de 12 requêtes entre deux origines S3. Nous ne voyons que des données illisibles.
3. Le destinataire reçoit un lien contenant la clé dans le fragment d'URL (après le caractère #), qui n'est jamais envoyé au serveur par le navigateur.
4. Le destinataire télécharge le fichier chiffré par plages S3 ordonnées et le déchiffre localement. Une coupure reprend à l'octet exact lorsque le navigateur permet l'écriture en flux.

3.3 Ce que nous pouvons et ne pouvons pas voir

4. Chiffrement de bout en bout avec mécanismes post-quantiques

4.1 Les trois niveaux de protection

4.2 Primitives cryptographiques

4.3 Schéma hybride post-quantique pour les équipes

Pour les espaces collaboratifs d'équipe, PrivCloud utilise un schéma hybride combinant X25519 et ML-KEM-768. La clé de chiffrement du fichier (DEK) est enveloppée pour chaque destinataire autorisé avec son couple de clés publiques. Les notifications d'équipe sont également chiffrées de bout en bout avec ce mécanisme : aucune métadonnée (nom de l'expéditeur, nom du fichier, contexte du dossier) n'est visible par le serveur.

Cette approche hybride protège contre deux scénarios : une avancée mathématique contre les courbes elliptiques (X25519), et une faiblesse découverte dans ML-KEM-768. Les deux mécanismes doivent être compromis simultanément pour briser la confidentialité.

4.4 Gestion des clés et rotation

• La clé maître est générée localement au premier envoi et stockée dans le sessionStorage du navigateur (survit au rechargement de page, effacée à la fermeture).
• La clé d'équipe est générée par le propriétaire et enveloppée (wrapped) avec sa clé maître personnelle. Chaque membre reçoit la clé enveloppée avec sa propre clé maître.
• La rotation de clé d'équipe invalide atomiquement les copies des autres membres via transaction Prisma.
• Re-chiffrement complet disponible : téléchargement avec l'ancienne clé, re-chiffrement avec la nouvelle, re-dépôt par chunks. Protection WAF intégrée avec backoff exponentiel.

5. Architecture zero-knowledge : la confidentialité par conception

Une architecture zero-knowledge signifie que le fournisseur de service n'a aucune connaissance du contenu des données qu'il traite. Cette propriété est garantie par construction cryptographique.

• Nous ne disposons pas des éléments permettant d'accéder en clair au contenu des fichiers.
• Les clés de chiffrement ne transitent jamais par nos serveurs (elles résident dans le fragment d'URL, non transmis au serveur).
• Les notifications d'équipe sont chiffrées de bout en bout : ni le nom de l'expéditeur, ni le nom du fichier ne sont visibles par le serveur.
• Si un utilisateur perd sa clé maître, nous ne pouvons ni la récupérer ni déchiffrer les données associées.

Implications pour la conformité

• RGPD : les données chiffrées dont nous ne possédons pas les clés nous sont inaccessibles en clair. Nous ne pouvons pas les exploiter à des fins non autorisées.
• Secret professionnel : l'architecture zero-knowledge apporte un renforcement cryptographique que nous ne pouvons pas contourner.
• Réquisitions judiciaires : en cas de demande d'accès par une autorité, nous ne pouvons livrer que des données chiffrées illisibles et les journaux de connexion.

6. Infrastructure souveraine et durcie

6.1 Hébergement 100% européen

6.2 Mesures de sécurité suivies

6.3 Défense en profondeur (5 couches)

L'infrastructure repose sur 12 VLANs isolés, une politique par défaut DROP sur la totalité des machines (INPUT/FORWARD/OUTPUT), et un accès SSH Zero Trust (clé Ed25519 + passphrase 80 caractères + 2FA).

6.4 Indépendance vis-à-vis des GAFAM

PrivCloud n'utilise aucun service d'hébergement ou d'infrastructure des plateformes américaines (Google Cloud, AWS, Microsoft Azure). L'intégralité des données utilisateurs est hébergée exclusivement auprès d'opérateurs européens. Le Cloud Act (2018) contraint les entreprises américaines à fournir aux autorités américaines les données qu'elles hébergent. En choisissant une infrastructure exclusivement européenne, PrivCloud élimine ce vecteur de risque.

7. Fonctionnalités

7.1 Partage de fichiers sécurisé

• Chiffrement AES-256-GCM côté client avant tout envoi
• Upload préinitialisé, résilient et partagé équitablement par le serveur
• Download parallèle par plages ordonnées avec reprise à l'octet
• Expiration configurable, protection par mot de passe, limitation des téléchargements
• Reverse shares E2E : réception chiffrée de fichiers de tiers
• Notifications de téléchargement (push instantané + email)
• Prévisualisation vidéo E2E (jusqu'à 100 Mo) et code source avec coloration syntaxique
• Taille maximale selon le plan ; pas de restriction applicative de format au-delà des contrôles de sécurité

7.2 Espaces collaboratifs d'équipe

• Chiffrement E2E avec clés hybrides post-quantiques (X25519 + ML-KEM-768)
• Grants cryptographiques (AccessGrant) par destinataire
• Notifications chiffrées E2E (zéro fuite de métadonnées)
• Rôles granulaires : OWNER, ADMIN, MEMBER
• Permissions par dossier (canDownload, canDelete) et par fichier (READ/WRITE/ADMIN/DENY)
• Pool de stockage dynamique : 500 Go + 100 Go par membre supplémentaire
• Révocation cryptographique instantanée lors du retrait d'un membre

7.3 Signature électronique

• Workflow de signature avancée aligné eIDAS : OTP email, consentement explicite, audit trail et conservation des preuves
• Signature PDF et horodatage selon la configuration serveur disponible
• Workflow multi-signataires : SIGNER, APPROVER, CC
• Tokens de signature pour signataires externes (pas de compte requis)
• Support E2E : documents chiffrés pendant le workflow de signature
• Piste d'audit complète et page de certificat automatique
• Signature qualifiée (QES) prévue via prestataire qualifié, non incluse dans cette version

7.4 Connecteurs et PrivCloud Companion

• Import WebDAV depuis Nextcloud, ownCloud et NAS compatibles, en direct navigateur si CORS est autorisé
• PrivCloud Companion local pour éviter les limites CORS : cloud distant -> appareil utilisateur -> upload chiffré PrivCloud
• Tokens Bridge courts et limités au partage en cours pour les imports managés
• Artefacts bêta non signés pour Linux (.deb/.rpm/portable), Windows, macOS, extension navigateur, Thunderbird, Outlook et Google Workspace
• Publication signée et validation stores prévues ; aucun statut store officiel n'est revendiqué dans cette version

8. Transparence opérationnelle

• Code source ouvert : projet open source sous licence BSD 2-Clause. Le code complet (backend + frontend) est accessible sur GitHub pour audit.
• Gestion des vulnérabilités : arbre de dépendances durci, audits réguliers via npm audit, Snyk et scans d'images, overrides ciblées et réduction des dépendances runtime quand c'est possible.
• Politique zéro IA : aucune intelligence artificielle dans le produit. Vos fichiers ne servent pas à entraîner des modèles. Nous ne pouvons pas analyser ce que nous ne pouvons pas lire.
• Pipeline sécurisé : CI/CD GitLab privé, Renovate pour les mises à jour automatiques, TypeScript strict progressif, images Docker Alpine minimales.

9. Cas d'usage

10. Offres et déploiement

11. Conclusion

Face aux enjeux croissants de cybersécurité, d'indépendance et de conformité réglementaire, les organisations européennes ont besoin de solutions de partage de fichiers qui offrent une sécurité supérieure et qui ne reposent pas uniquement sur des engagements contractuels. PrivCloud apporte cette garantie en combinant :

• Chiffrement de bout en bout : vos fichiers sont illisibles sur nos serveurs, aujourd'hui et face aux menaces futures (schéma hybride X25519 + ML-KEM-768).
• Architecture zero-knowledge : sans clés de déchiffrement, nous ne pouvons pas accéder à vos contenus. Les notifications elles-mêmes sont chiffrées.
• Infrastructure souveraine durcie : hébergement en France, segmentation réseau, politiques restrictives, supervision et défense en profondeur.
• Signature électronique intégrée : workflow de signature avancée avec chiffrement E2E natif ; QES prévue via prestataire qualifié.
• Transparence : code source ouvert et auditable, gestion active des vulnérabilités, politique zéro IA.

Contact

THEMIOT Informatique

• Site web : www.stprive.net
• Contact : simon.themiot@informatiquenevers.fr
• Code source : github.com/Simthem/PrivCloud_Sharing

Ce document est fourni à titre informatif. Les informations qu'il contient reflètent l'état de la plateforme au moment de sa rédaction. THEMIOT Informatique se réserve le droit de faire évoluer son architecture et ses fonctionnalités.

- THEMIOT Informatique, Juin 2026