Transfert chiffré zero-knowledge et messages éphémères, posés sur un format d’archive souverain. Le serveur ne détient jamais la clé, et c’est précisément là que tout se joue.
La vraie question n’a jamais été de savoir si le fichier arriverait à destination. Elle est de savoir qui, en chemin, détient la clé.
Le fichier part. En pièce jointe, ou derrière un lien, avec la petite phrase qui rassure : « ça devrait aller ». Un contrat, un dossier patient, un plan industriel, les comptes d’un client. Déposés sur un service gratuit, commode, jamais vraiment choisi, celui qu’on avait sous la main ce jour-là. Par confort, l’organisation vient de confier à un tiers la chose la plus intime qu’elle possède : le droit de lire. Et derrière l’hébergeur, parfois, un autre droit, étranger, qui peut exiger d’y accéder.
Ce n’est pas un cas limite. C’est le quotidien, et ce n’est pas qu’une affaire d’utilisateurs pressés. Les équipes IT elles-mêmes, DSI et prestataires techniques, ont structurellement besoin d’échanger des données sensibles vers l’extérieur. WeTransfer, Dropbox, Google Drive : la donnée sensible des organisations transite encore, chaque jour, par des canaux où quelqu’un d’autre que l’expéditeur et le destinataire peut, techniquement ou juridiquement, ouvrir le paquet.
Ce qui menace réellement un fichier en transit
Le problème n’est pas théorique, et il ne se résume pas au piratage spectaculaire. Il tient à une série de mécanismes bien documentés :
- Le chiffrement « en transit » n’est pas le chiffrement de bout en bout. Beaucoup de services chiffrent le trajet, mais détiennent la clé à l’arrivée. Le contenu est donc lisible côté serveur — par l’hébergeur, par un administrateur, par toute autorité qui le lui ordonne.
- « Harvest now, decrypt later ». Des acteurs collectent aujourd’hui des données chiffrées qu’ils ne peuvent pas encore casser, en pariant sur la puissance de calcul de demain — notamment l’arrivée de l’ordinateur quantique. Ce qui semble protégé en 2026 peut être déchiffré dans dix ans.
- L’extraterritorialité du droit. Le Cloud Act et le FISA permettent à des autorités américaines d’exiger l’accès à des données hébergées par une société soumise à leur juridiction — où que ces données soient physiquement stockées.
- L’accumulation comme surface d’attaque. Chaque fichier qui reste indéfiniment sur un serveur partagé est un fichier de plus à voler le jour de la fuite. La donnée qui ne s’efface jamais devient une dette de sécurité qui grossit toute seule.
Pourquoi les réponses actuelles ne tiennent pas
Parce qu’elles sont pénibles, et que ce qui est pénible se contourne. Les alternatives chiffrées sérieuses existent, mais beaucoup sont illisibles : échange de clés manuel, interfaces austères, étapes qui découragent. Résultat, à la première urgence, l’utilisateur rouvre l’onglet WeTransfer. L’ergonomie n’est pas un confort secondaire : c’est une condition de sécurité. Un outil que l’on contourne ne protège rien.
Parce que beaucoup sont des boîtes noires que personne ne peut vérifier. « Faites-nous confiance, c’est chiffré » n’est pas une garantie, c’est une promesse. Quand le fonctionnement cryptographique est opaque et propriétaire, on ne sait pas où vivent les clés, ni ce que le serveur voit réellement. La confiance se décrète au lieu de se prouver.
Parce que la majorité reposent sur une dépendance étrangère. Confier ses fichiers les plus sensibles à un service soumis à un droit extraterritorial, c’est accepter qu’une décision prise ailleurs prime sur la sienne. Pour une collectivité, un industriel, un cabinet d’avocats, un acteur de la finance ou de la santé, ce n’est pas un détail de conformité : c’est une perte de maîtrise sur ce qui circule.
L’approche ÉCLAT : des garanties, pas une boîte noire
ÉCLAT, Échange Chiffré, Local, Anonyme et Temporaire, part d’un constat simple. L’agence nationale de cybersécurité, l’ANSSI, a publié en open source un format d’archive chiffré issu de la recherche publique. Le NIST CSF, NIS2 et le RGPD convergent tous vers la même exigence : un chiffrement où les clés ne quittent jamais le poste. Le matériau souverain existait. Ce qui manquait, c’était d’en faire un produit réellement déployable et pensé pour être utilisé.
Concrètement, voici ce qu’ÉCLAT garantit, sans entrer dans le « comment » :
- Cryptographie post-quantique — pensée pour résister à la menace « harvest now, decrypt later ».
- Clé détenue côté serveur : zéro. Le service ne peut pas lire ce qu’il transporte, par conception et non par engagement.
- Partages éphémères par défaut. La donnée ne s’accumule pas : moins de surface, moins de dette, moins de risque.
C’est la logique du zero-knowledge : le serveur achemine sans jamais connaître le contenu. Et c’est, au fond, une logique de frontière plutôt que de mur. ÉCLAT ne sert pas à s’enfermer ni à couper les échanges : il sert à protéger ce qui circule pour que cela circule mieux, entre les bonnes personnes, sans renoncer à la fluidité d’un simple lien.
Deux principes ont guidé sa conception, et ils sont indissociables. Security by design d’abord : la confidentialité n’est pas une option qu’on active, c’est le socle : le zero-knowledge et l’éphémérité sont présents dès la première ligne, pas greffés après coup. User-centric ensuite : parce qu’un outil de sécurité qu’on trouve pénible finit contourné, ÉCLAT est pensé pour que le geste sûr soit aussi le geste le plus simple, y compris pour une équipe IT qui pousse un dump de base à un prestataire. La sécurité la plus solide est celle qui se fait oublier.
Ce qu’ÉCLAT n’expose pas
Vous ne trouverez dans cet article ni l’architecture interne, ni les détails d’implémentation, ni la mécanique précise qui produit ces garanties. Ce n’est pas une omission : c’est une posture. Un système de sécurité dont on peut reconstituer le fonctionnement à la lecture d’un billet de blog est un système dont on peut aussi anticiper les failles. L’opacité maîtrisée, ici, n’est pas un manque de transparence sur les garanties, elles sont claires et tenables, mais une protection de la valeur. On dit ce que l’on protège. On ne distribue pas le plan du coffre.
Pourquoi maintenant
Parce que le cadre se durcit et que les échéances arrivent. NIS2 élargit le périmètre des organisations tenues à un niveau de sécurité sérieux. Le RGPD réclame, depuis des années déjà, des mesures techniques à la hauteur de la sensibilité des données. Et la question de la souveraineté numérique a cessé d’être un débat d’experts pour devenir une décision de direction.
Surtout, le besoin déborde largement les secteurs que l’on cite par réflexe. Ce sont d’abord les équipes IT, les DSI et les prestataires techniques qui, au quotidien, doivent échanger des données sensibles avec l’extérieur : partenaires, sous-traitants, clients, auditeurs ; logs, dumps de bases, configurations, livrables, autant de fichiers critiques qui partent vers des tiers. À cela s’ajoutent les industriels qui échangent des plans, les cabinets d’avocats tenus au secret, les acteurs de la finance, les équipes de R&D privée. Partout où des données sensibles transitent, la même question revient : qui détient la clé ?
On construit ça en France
ÉCLAT est en construction, conçu en France, posé sur un format souverain issu de la recherche publique et pensé pour être déployé jusque sur vos propres serveurs. C’est un projet de R&D que nous menons à découvert, parce que nous croyons qu’un outil de confiance se montre avant de se vendre.
La vraie question n’a jamais été de savoir si le fichier arriverait. Elle est de savoir qui détient la clé. Avec ÉCLAT, la réponse est simple : personne d’autre que vous.
Voir la démo : share.kodetis.cloud
Une donnée sensible à faire circuler sans la confier ? Parlons-en.