Coffrify chiffre vos contenus dans tous les cas. Par défaut, le chiffrement est géré côté serveur en AES-256-GCM : vos fichiers ne transitent et ne reposent jamais en clair, et l'hébergement reste en Union européenne. Pour les besoins les plus sensibles, Coffrify propose en plus un mode zero-knowledge (chiffrement de bout en bout) : la clé reste chez vous et le serveur ne peut pas lire le contenu. Cette page explique, pour les décideurs comme pour les équipes techniques, ce que ce mode garantit, ce qu'il implique au quotidien, et comment choisir entre les deux approches selon votre cas d'usage.
Ce que le mode zero-knowledge garantit
Le principe est simple à énoncer : en mode zero-knowledge, la clé reste chez vous. Le serveur Coffrify stocke et transmet vos fichiers sous forme chiffrée, mais il ne dispose d'aucun moyen de les déchiffrer. Concrètement, ni nos systèmes, ni nos équipes, ni un tiers qui obtiendrait une copie du stockage ne peuvent accéder au contenu de vos documents. Seules les personnes à qui vous transmettez la clé ou la phrase secrète peuvent ouvrir les fichiers.
Cette garantie est volontairement radicale. Elle vous protège même dans les scénarios où le chiffrement serveur classique pourrait théoriquement être contourné par un accès au système, à une sauvegarde ou à un sous-traitant d'hébergement. En zero-knowledge, ces vecteurs ne donnent accès qu'à des données illisibles.
Ce que cela implique pour vous
La contrepartie de cette garantie est tout aussi nette : vous devenez responsable de la clé et de la phrase secrète. Puisque le serveur ne les détient jamais, Coffrify ne peut ni les régénérer, ni les réinitialiser, ni déchiffrer vos contenus à votre place. Il n'existe pas de procédure de récupération de dernier recours côté serveur.
- Si vous perdez la clé ou la phrase secrète, les données chiffrées correspondantes deviennent définitivement inaccessibles.
- Le support Coffrify ne peut pas "débloquer" un contenu zero-knowledge, par construction et non par choix de politique.
- Le partage d'accès passe par la transmission de la clé ou de la phrase secrète à vos destinataires, par un canal que vous maîtrisez.
- Certaines fonctions qui nécessitent que le serveur lise le contenu (par exemple un aperçu généré côté serveur) ne s'appliquent pas aux contenus chiffrés de bout en bout.
Comparaison honnête avec le chiffrement serveur par défaut
Le chiffrement serveur en AES-256-GCM, activé par défaut, couvre déjà la très grande majorité des besoins professionnels avec un niveau de protection élevé et une expérience fluide. Le zero-knowledge n'est pas "meilleur dans l'absolu" : il déplace le curseur entre garantie de confidentialité et responsabilité opérationnelle. Le tableau ci-dessous résume les différences concrètes pour vous aider à choisir.
| Critère | Chiffrement serveur (défaut) | Zero-knowledge (bout en bout) |
|---|---|---|
| Chiffrement | AES-256-GCM côté serveur | Bout en bout, clé chez vous |
| Le serveur peut lire le contenu | Oui (pour assurer le service) | Non, jamais |
| Récupération si secret perdu | Possible via votre compte | Impossible, données perdues |
| Responsabilité de la clé | Coffrify | Vous |
| Aperçus et traitements serveur | Disponibles | Limités ou indisponibles |
| Mise en route | Immédiate, aucune action | Gestion de clé à prévoir |
| Hébergement et conformité | UE, RGPD | UE, RGPD |
Dans les deux modes, vos données restent hébergées en Union européenne et le traitement respecte le RGPD. Le choix porte sur le modèle de confiance, pas sur la localisation ni sur la conformité.
Pour quels cas d'usage activer le zero-knowledge
Réservez ce mode aux contenus pour lesquels la garantie "le serveur ne peut pas lire" apporte une valeur réelle, et pour lesquels vous êtes prêts à assumer la gestion des secrets. Quelques exemples typiques.
- Transferts de documents hautement confidentiels (juridique, M&A, santé, secrets industriels) où l'exposition serveur doit être exclue.
- Data rooms (coffres) destinées à un cercle restreint dont vous contrôlez vous-même l'accès cryptographique.
- Réception de pièces sensibles de tiers via un point de dépôt, lorsque le contenu ne doit être lisible que par vous.
- Exigences contractuelles ou réglementaires imposant que le prestataire n'ait techniquement aucun accès au contenu.
À l'inverse, pour des partages courants, des documents collaboratifs ou tout flux où vous voulez bénéficier des aperçus et d'une récupération possible via votre compte, le chiffrement serveur par défaut reste le choix recommandé.
Où l'activer
Le mode zero-knowledge s'active au niveau de la ressource concernée, au moment de sa création, depuis votre tableau de bord Coffrify. Il s'applique notamment aux transferts de fichiers, aux coffres (data rooms) et aux points de réception (intake). Le réglage est défini ressource par ressource : vous pouvez réserver le bout-en-bout à vos contenus les plus sensibles tout en conservant le chiffrement serveur par défaut pour le reste.
Côté API et SDK, vos appels restent inchangés dans leur forme : vous continuez d'utiliser l'authentification par en-tête Authorization: Bearer <clé> et les mêmes points d'entrée. La différence tient au modèle de confiance retenu pour la ressource, pas à une mécanique que vous auriez à implémenter dans vos requêtes.
En résumé
Le zero-knowledge offre la garantie la plus forte de Coffrify : le serveur ne peut pas lire vos contenus. En échange, vous gérez la clé et la phrase secrète, et toute perte est définitive. C'est le bon choix pour vos données les plus sensibles, à condition d'avoir préparé la conservation des secrets. Pour tout le reste, le chiffrement serveur AES-256-GCM activé par défaut, hébergé en UE et conforme au RGPD, reste un excellent niveau de protection sans contrainte opérationnelle supplémentaire.