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

THEMIOT Informatique / Version 1.2 / Octobre 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, chaque compte PrivCloud chiffre ses fichiers de bout en bout par défaut, et la clé n'est pas transmise à nos serveurs : ni PrivCloud ni ses propres opérateurs ne peuvent accéder au contenu en clair de ces fichiers. La clé n'y passe que si l'utilisateur choisit de l'envoyer par e-mail. 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 : par défaut, les clés de déchiffrement de vos contenus ne transitent pas par nos serveurs et ne sont pas accessibles à notre infrastructure. Elles n'y passent que si vous choisissez de les envoyer par e-mail.

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 aléatoirement dans le navigateur et, par défaut, n'est pas 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 combine X25519 et ML-KEM-768. La clé d'équipe, qui chiffre les fichiers de l'équipe, parvient à chaque membre par un lien dont le fragment n'est jamais envoyé au serveur, puis chacun la conserve chiffrée par sa propre clé maître. Quand un membre partage des fichiers de l'équipe avec d'autres membres, une copie de cette clé est enveloppée pour chaque destinataire en hybride X25519 + ML-KEM-768. Quand un administrateur d'équipe l'active, le détail des notifications pour les partages de fichiers, les demandes de fichiers et les signatures est chiffré avec le même mécanisme, sinon avec X25519 seul. Les notifications que le serveur écrit lui-même ne portent qu'un texte générique, sans aucun nom.

Le mode 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 ce qu'ils protègent.

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.
• Par défaut, les clés de chiffrement ne transitent pas par nos serveurs (elles résident dans le fragment d'URL, non transmis au serveur). Elles n'y passent que si l'utilisateur choisit de les envoyer par e-mail.
• Le détail des notifications d'équipe pour les partages de fichiers, les demandes de fichiers et les signatures est chiffré de bout en bout. Les notifications d'équipe que le serveur écrit lui-même, leurs messages push et les e-mails de service d'équipe ne portent qu'un texte générique, sans nom de membre, d'équipe, de dossier ou de fichier.
• 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 Infrastructure et stockage européens

Infrastructure applicative opérée en France, stockage des contenus E2EE en France, doublon de backup dans l'Union européenne (Allemagne).

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 Résidence des données et maîtrise des clés

L'infrastructure applicative de PrivCloud est opérée en France. Les contenus E2EE sont stockés en France avec un doublon de sauvegarde en Allemagne. La résidence européenne des données ne suffit pas, à elle seule, à déterminer toutes les juridictions applicables à un prestataire. Le modèle zero-knowledge réduit cette exposition : le stockage objet reçoit des contenus chiffrés sans leur clé de déchiffrement.

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)
• Aperçus inclus dans les partages Starter, Pro et Team. Documents DOCX et ODT, classeurs XLSX, XLS/XLT, XLSB et ODS, présentations PPTX et ODP, modèles et variantes compatibles. Mise en forme, couleurs, tableaux, cellules fusionnées, formats numériques et images compatibles selon le format. Zoom et navigation par feuille ou diapositive. CSV, TSV, RTF, OpenDocument XML plat, textes et code source avec coloration syntaxique sont également pris en charge.
• Les vidéos, l'audio et les PDF compatibles chargent progressivement les parties utiles, y compris pour les fichiers E2E chiffrés en blocs. Les classeurs XLSX et présentations PPTX chargent les informations utiles, puis la feuille ou la diapositive sélectionnée. Aucun plafond supplémentaire de taille totale ne s'applique à ces aperçus. Les limites de l'offre et les capacités de l'appareil restent applicables.
• Les fichiers complexes peuvent donner un aperçu partiel. Les polices absentes, graphiques, équations et objets avancés peuvent différer ou ne pas apparaître. Les anciens DOC et PPT nécessitent un téléchargement. Les tableurs XLS/XLT, XLSB, SYLK, DIF, Lotus et DBF affichent leurs valeurs enregistrées dans un aperçu local limité à 16 Mio, 500 lignes et 100 colonnes par feuille. Les macros et formules ne sont jamais exécutées. Les résultats de formules enregistrés sont affichés. La lecture des médias dépend des codecs et du support des Service Workers du navigateur ou de la WebView. Les images et les anciens fichiers E2E à bloc unique peuvent nécessiter un chargement complet, dans les limites du format et de l'appareil.
• 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 la clé d'équipe, transmise par un lien dont le fragment n'atteint jamais le serveur
• Grants cryptographiques (AccessGrant) par destinataire, en hybride X25519 + ML-KEM-768
• Détail des partages, demandes de fichiers et signatures chiffré E2E dans les notifications, aucun nom dans celles du serveur
• 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 Prestataires externes : copies en consultation et preuves vérifiables

Le plan Team permet de confier un document à un prestataire externe (expert, auditeur, sous-traitant) sans jamais lui remettre le fichier original. Deux places de prestataire sont incluses par équipe.

• Copie dérivée en consultation seule : pages rendues en images de résolution bornée dans le navigateur de l'administrateur, filigranées, chiffrées pour ce seul prestataire en hybride X25519 + ML-KEM-768. Ni l'original ni la clé d'équipe ne lui sont servis.
• Validation par passkey du manifeste canonique de la remise, puis horodatage RFC 3161 de son enregistrement. Une chaîne TSA valide ne suffit pas à établir le statut qualifié historique du service.
• Journal chaîné des ouvertures et demandes de pages autorisées, pas d'une lecture humaine. Le scellement horaire peut laisser une fin de journal non ancrée. Un checkpoint doit être conservé indépendamment avant un incident pour comparer l'état retenu.
• Marquage invisible propre à chaque copie, recherché localement dans le navigateur. Une correspondance renseigne sur un motif compatible, pas sur l'identité de l'auteur d'une fuite. Les réductions extrêmes, la binarisation et le mélange de copies ont des échecs mesurés.
• Dossier exportable : certificat, preuve.json, jetons et vérificateur Python/OpenSSL hors ligne. Le mode strict distingue VALID, INVALID et INDETERMINATE et exige des références indépendantes, dont l'original, la racine TSA et le checkpoint.
• Conservation technique de trois ans, y compris après suppression de l'équipe, avec restitution sur demande écrite depuis un coffre-fort ouvert par passkey pour dix minutes. Chaque extraction est journalisée. La nécessité juridique de cette durée doit être documentée et les demandes d'effacement examinées.

Une capture ou photo de l'écran reste possible. Les échecs historiques sont conservés. Un nouveau corpus privé de préproduction, fourni avec son motif dérivé et le PDF exact, retrouve une photo verticale après recalage local à 17,53 et deux petits fragments à 17,99 et 12,86 dans le worker de production. Les contrôles sans le bon motif ou avec une autre clé ne retiennent aucun candidat. Le complément automatique des fragments utilise un seuil renforcé à 10 et refuse une attribution unique dès qu'un concurrent atteint 8. Un candidat réel et sept candidats synthétiques ne valident pas tout le registre ni une attribution générale. Six passages OCR réels effacent le motif. La reconstruction depuis la source non marquée peut aussi supprimer toute information propre à la copie. Les nouvelles pages sont en PNG sans perte. Les rappels personnels de fin d'accès restent facultatifs. Le certificat, le dossier de preuve et l'export explicite d'un motif exigent une passkey fraîche d'un administrateur actif. L'export reste sensible et non chiffré, la dérivation reste côté client. Le coffre plateforme demeure séparé.

7.4 Signature électronique

• Signature électronique : consentement explicite, contrôles propres à chaque niveau, liaison au document, audit trail et conservation des preuves
• Niveau standard avec OTP e-mail obligatoire, niveau renforcé avec compte attribué et passkey liée à la transaction, sans revendiquer une identité civile qualifiée
• Scellement PDF PAdES-B-T : seule l'empreinte de la signature est soumise à la TSA RFC 3161, réponse cryptographiquement vérifiée puis jeton incorporé au PDF
• Workflow multi-signataires : SIGNER, APPROVER, CC
• Tokens de signature standard pour signataires externes (pas de compte requis)
• Support E2E : documents chiffrés pendant le workflow de signature
• Piste d'audit chaînée par SHA-256 et page de preuve automatique
• QES non incluse, extension future via un prestataire qualifié et une interface Cloud Signature Consortium (CSC)

7.5 Connecteurs, PrivCloud Companion et application native

• Import WebDAV depuis Nextcloud, ownCloud et NAS compatibles
• PrivCloud Companion local : cloud distant -> appareil utilisateur -> upload chiffré PrivCloud
• Application native Android : authentification dédiée, connecteur WebDAV intégré et transferts chiffrés pilotés sur l'appareil
• 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é, TypeScript strict progressif, images de production Docker distroless basées sur Debian 13, sans shell ni gestionnaire de paquets.

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 : le contenu de vos fichiers est illisible sur nos serveurs. Le chiffrement AES-256 résiste aux attaques quantiques connues, et les clés partagées entre membres d'une équipe sont enveloppées en hybride X25519 + ML-KEM-768.
• Architecture zero-knowledge : sans clés de déchiffrement, nous ne pouvons pas accéder à vos contenus. Le détail des notifications sur les partages, les demandes de fichiers et les signatures est chiffré, et celles que notre serveur écrit ne nomment personne.
• 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 avec OTP e-mail au niveau standard, compte et passkey au niveau renforcé, chiffrement E2E natif, QES future via prestataire qualifié et interface CSC.
• Prestataires externes sous contrôle : copies en consultation seule validées par passkey, horodatées, journalisées et marquées de façon invisible. Vérification hors ligne avec références indépendantes et limites documentées.
• 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