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.
Dans l’imaginaire collectif, envoyer un fichier est un geste sans poids : on glisse une pièce jointe, on colle un lien, et l’affaire est réglée. Pour nous, professionnels de l’IT, la réalité est plus matérielle. Un fichier qui part, c’est un droit que l’on cède : le droit de lire. Et la question n’a jamais été de savoir si ce fichier arrive à destination. Elle est de savoir qui, en chemin, détient la clé.
On parle beaucoup de chiffrement, de bout en bout, de confidentialité. C’est le vocabulaire rassurant des fiches produit. Mais entre ce vocabulaire et nos pratiques réelles, il y a un écart que personne n’aime regarder en face. Alors posons les choses à plat.
Le confort du service qu’on avait sous la main
Pourquoi la donnée sensible des organisations transite-t-elle encore, chaque jour, par WeTransfer, Dropbox ou Google Drive ? Ce n’est pas par négligence, ni par méconnaissance du risque. C’est par pragmatisme.
Le fichier part 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à. Et ces services fonctionnent : vite, partout, sans installer quoi que ce soit, sans demander un mode d’emploi. Dans une journée déjà pleine, cliquer sur « envoyer » est d’une séduction redoutable.
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 : logs, dumps de bases, configurations, livrables. Nous avons tous, à un moment, échangé un peu de maîtrise contre beaucoup de confort. Et tant que rien ne fuite, tout le monde est content.
Le réveil
Sauf que ce confort repose sur des mécanismes qu’on a appris à ne pas regarder. Le problème n’est pas théorique, et il ne se résume pas au piratage spectaculaire :
- 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. Une décision prise ailleurs prime sur la nôtre.
- 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.
Le mur de la réalité
La solution technique existe : les alternatives chiffrées sérieuses ne manquent pas. Mais leur mise en œuvre se heurte à trois freins bien concrets, et c’est là que le débat devient honnête.
Le premier, c’est que ce qui est pénible se contourne. Beaucoup d’outils chiffrés 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.
Le deuxième, c’est la boîte noire. « 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.
Le troisième, c’est la dépendance étrangère. Confier ses fichiers les plus sensibles à un service soumis à un droit extraterritorial, c’est accepter qu’une décision prise dans un conseil d’administration à l’autre bout du monde 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.
Ce que nous essayons de construire avec ÉCLAT
ÉCLAT, Échange Chiffré, Local, Anonyme et Temporaire, part d’un constat simple. L’ANSSI a publié en open source un format d’archive chiffré issu de la recherche publique. Le matériau souverain existait déjà. Ce qui manquait, ce n’était pas la science : c’était d’en faire un objet réellement déployable, pensé pour être utilisé, où les clés ne quittent jamais le poste.
Concrètement, voici ce qu’ÉCLAT vise à garantir, 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. Au fond, c’est 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 partis pris ont guidé sa conception, et ils répondent directement au mur décrit plus haut. Security by design : 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 : parce qu’un outil de sécurité qu’on trouve pénible finit contourné, le geste sûr doit être 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.
Reste un troisième frein, et il serait malhonnête de prétendre qu’un produit le fait disparaître : la dépendance étrangère ne se remplace pas par un slogan. C’est pour cela qu’ÉCLAT est pensé pour être déployé jusque sur vos propres serveurs, sur un socle qu’on peut inspecter. La maîtrise ne se promet pas, elle se rend vérifiable.
Sur le comment, voici ce qui peut être dit sans ouvrir le coffre. L’architecture s’appuie sur les référentiels de l’ANSSI, ses guides d’hygiène et ses recommandations de durcissement, plutôt que sur nos propres intuitions. Le socle système repose sur NixOS, pour une configuration déclarative, reproductible et durcie selon ces mêmes référentiels : ce qui tourne en production est décrit, versionné et vérifiable, pas assemblé à la main. La sécurité est pensée en défense en profondeur, par couches successives, pour qu’aucune ne constitue à elle seule un point unique de défaillance. Et l’ensemble est construit selon une démarche DevSecOps, où le contrôle de sécurité fait partie du cycle de développement dès le départ, pas d’une revue de dernière minute.
Une certaine idée de la tech
Le moment n’est pas neutre. Le cadre se durcit : NIS2 élargit le périmètre des organisations tenues à un niveau de sécurité sérieux, le RGPD réclame depuis des années des mesures techniques à la hauteur de la sensibilité des données, et la souveraineté numérique est passée du débat d’experts à la décision de direction. Le besoin, lui, déborde largement les secteurs qu’on cite par réflexe : équipes IT, DSI et prestataires qui poussent chaque jour des données sensibles vers l’extérieur, industriels qui échangent des plans, cabinets tenus au secret, acteurs de la finance, équipes de R&D privée. Partout, la même question revient : qui détient la clé ?
Notre réponse tient dans une certaine idée de la tech : transférer une donnée sensible de la manière la plus simple possible, déployable jusque sur vos propres serveurs, conforme aux recommandations de l’ANSSI. ÉCLAT est en construction, conçu en France, posé sur un format souverain issu de la recherche publique, et s’inscrit dans la Stratégie nationale de cybersécurité 2026-2030 : faire de la sécurité souveraine non pas une contrainte de plus, mais le chemin le plus court. Entre le confort d’un service qu’on n’a jamais vraiment choisi et l’effort d’une maîtrise qu’on construit, la question n’est plus technique, elle est stratégique :
Sommes-nous prêts à reprendre la clé de ce que nous faisons circuler ?
Voir la démo : eclat.kodetis.cloud
Une donnée sensible à faire circuler sans la confier ? Parlons-en.