Chiffrement côté client vs côté serveur expliqué avec modèles de menace et compromis UX pour stocker contrats, pièces d'identité et fichiers médicaux dans une application métier.
Si votre application permet aux gens de téléverser des fichiers, vous ne stockez pas seulement des « documents ». Vous stockez souvent une seconde identité pour l'utilisateur : contrats signés, photos de passeport ou permis, formulaires médicaux et résultats de laboratoire. Les fichiers sont petits. Les risques qui leur sont associés ne le sont pas.
Un contrat divulgué peut déclencher des conséquences juridiques et financières : les prix deviennent publics, les signatures sont copiées et les conflits dégénèrent rapidement. Un scan d'identité volé peut conduire à du vol d'identité et à la prise de contrôle de comptes. Des documents médicaux peuvent exposer des informations de santé privées que les gens n'avaient jamais prévu de partager largement. Une erreur peut nuire à la confiance pendant des années.
Les équipes disent souvent « stockage chiffré » en voulant dire des choses différentes. Parfois elles parlent de la connexion de téléversement (HTTPS). Parfois elles parlent du fichier chiffré sur le disque (chiffrement au repos). Parfois elles parlent du fichier chiffré avant de quitter l'appareil de l'utilisateur, de sorte que le serveur ne voit jamais le texte en clair (chiffrement côté client). Ce ne sont pas des concepts interchangeables. Ils protègent contre des défaillances différentes.
Les choix de sécurité influencent aussi l'utilisabilité et le support au quotidien. Plus de confidentialité peut signifier plus de friction : étapes supplémentaires pour voir un fichier, partage plus difficile, recherche et aperçus limités, et récupération pénible quand quelqu'un perd un appareil ou une clé. Un accès plus simple permet l'indexation, l'analyse antivirus, les aperçus et les réinitialisations de mot de passe, mais augmente aussi ce que votre serveur (et toute personne qui le compromet) peut voir.
Imaginez une petite clinique téléversant des assurances et des PDF médicaux. Le personnel doit retrouver le bon fichier rapidement, mais la clinique veut aussi réduire les dégâts si un compte admin est piraté. Le modèle « correct » dépend de l'échec qui ferait le plus de mal et du niveau d'inconvénient que les utilisateurs toléreront.
La question pratique est simple : quand le fichier est-il chiffré, et qui peut le déchiffrer ensuite ?
Le chiffrement côté serveur signifie que le fichier arrive lisible à votre backend, et que votre serveur le chiffre avant de le sauvegarder. C'est le chiffrement au repos : si quelqu'un vole un disque ou obtient un accès brut à un bucket de stockage, il voit des données chiffrées. Votre serveur peut cependant déchiffrer le fichier quand c'est nécessaire.
Le chiffrement côté client signifie que le fichier est chiffré sur l'appareil de l'utilisateur (navigateur ou mobile) avant l'envoi. Votre serveur ne stocke que le texte chiffré. En fonctionnement normal, le serveur ne peut pas lire le document à moins d'avoir accès aussi à la clé de déchiffrement.
La propriété des clés est la vraie ligne de démarcation :
Dans les deux modèles, vous avez toujours besoin d'authentification et d'autorisations. Le chiffrement ne remplace pas le contrôle d'accès.
Les gens utilisent aussi « chiffrement de bout en bout » pour dire : le fichier est chiffré sur l'appareil de l'expéditeur, reste chiffré sur le serveur, et n'est déchiffré que sur l'appareil d'un destinataire approuvé. Cela peut améliorer la confidentialité, mais complique les aperçus côté serveur, la recherche plein texte, l'analyse antivirus et la récupération facile, sauf si vous acceptez de modifier le modèle de menace.
Le chiffrement n'aide que si vous êtes clair sur les risques que vous voulez réduire. « Personne sauf l'utilisateur prévu ne doit pouvoir lire le fichier » mène à des choix différents de « réduire les dégâts si le stockage est divulgué ».
Les menaces courantes pour les applications qui stockent des contrats, des IDs ou des documents médicaux comprennent :
Il aide aussi de séparer où l'exposition peut se produire :
Voici la différence centrale. Avec le chiffrement côté serveur, votre système peut déchiffrer, donc il peut prévisualiser, scanner et indexer. Avec le chiffrement côté client, le serveur stocke du texte chiffré et ne peut pas lire le contenu sans les clés détenues par l'utilisateur. Cela réduit généralement le périmètre d'impact en cas de compromission du serveur et de l'accès interne.
Le chiffrement n'empêche pas tout. Si un appareil est infecté, le malware peut récupérer le fichier avant chiffrement ou après déchiffrement. Si quelqu'un peut voir un document, il peut toujours en faire une capture d'écran, le repartager ou l'imprimer.
Une façon utile de comparer ces approches est de demander : qui peut voir le fichier en clair à un moment donné ? Cette réponse façonne l'impact d'une fuite, le risque interne et la sécurité des sauvegardes.
Avec le chiffrement côté serveur, une brèche du serveur peut encore exposer beaucoup. Le backend a généralement accès aux clés de déchiffrement (ou peut les demander) parce qu'il doit générer des aperçus, lancer des antivirus, supporter la recherche ou gérer le partage. Dans le pire des cas, un attaquant qui obtient à la fois les données stockées et l'accès aux clés peut tout déchiffrer.
Avec le chiffrement côté client, un attaquant qui compromet votre infrastructure vole typiquement des blobs chiffrés. Sans clés détenues par les utilisateurs, ces blobs sont beaucoup moins utiles.
L'accès interne est l'endroit où la différence devient la plus visible. Avec le chiffrement côté serveur, un employé privilégié, un administrateur cloud ou un compte support compromis peut souvent accéder aux documents en se faisant passer pour l'application ou en interrogeant le stockage. Avec le chiffrement côté client, votre infrastructure peut stocker et déplacer les fichiers, mais ne peut pas les lire sans que des clés soient fournies.
Le chiffrement côté client ne résout pas un appareil piraté. Pour les téléversements à haut risque comme les IDs et les PDF médicaux, la sécurité des appareils et la protection des comptes comptent autant que le chiffrement du stockage.
Faites aussi attention aux fuites hors du « dépôt de fichiers ». Beaucoup d'incidents surviennent via :
La plus grande différence n'est pas mathématique. C'est ce que les utilisateurs peuvent faire facilement et ce qui devient difficile.
Le chiffrement côté serveur est souvent invisible. Les utilisateurs se connectent, téléversent et prévisualisent immédiatement. Le support peut réinitialiser l'accès. Les admins peuvent généralement réaffecter des permissions quand quelqu'un est en congé.
Le chiffrement côté client change l'onboarding et le travail quotidien. Les utilisateurs peuvent avoir besoin d'une phrase secrète plus forte, d'une clé locale stockée sur un appareil ou d'une étape de déverrouillage supplémentaire. Changer d'appareil, vider un navigateur ou réinstaller une application peut bloquer l'accès à moins d'avoir prévu la sauvegarde et la récupération des clés.
La récupération de compte surprend souvent les équipes. Si seul l'utilisateur détient la clé de déchiffrement, « mot de passe oublié » peut se transformer en « accès perdu ». Vous pouvez ajouter une clé de récupération ou un flux d'entiercement, mais vous devez être honnête sur ce que cela implique et l'expliquer clairement.
Le partage devient aussi plus compliqué. Avec le chiffrement côté serveur, le partage relève surtout des autorisations. Avec le chiffrement côté client, le partage implique souvent aussi le partage de clés, ainsi que des questions comme la révocation et le devenir des anciennes copies.
La recherche et les fonctionnalités de commodité peuvent forcer le déchiffrement quelque part. La recherche en texte intégral, les aperçus et l'OCR sont plus simples quand le serveur peut lire le fichier. Si vous voulez une confidentialité de type bout en bout, vous devrez peut-être faire de l'OCR côté client, de l'indexation locale ou accepter une recherche limitée (par exemple, seulement noms de fichiers et étiquettes).
Exemple : une clinique téléverse des PDF de laboratoire et veut de l'OCR pour trouver les noms des patients dans les scans. Le chiffrement côté serveur supporte l'OCR et la recherche rapides. Le chiffrement côté client pousse ce travail sur les appareils utilisateurs, ce qui peut être plus lent et plus difficile à supporter sur web et mobile.
Le meilleur choix dépend moins du type de fichier que du flux de travail : qui doit le lire, à quelle vitesse, à quelle fréquence et pendant combien de temps.
Les contrats impliquent souvent révision, modifications, approbations et pistes d'audit. Les équipes veulent aussi la recherche fiable, le partage et des règles de rétention.
Si votre application prend en charge la revue collaborative dans le produit, le chiffrement côté serveur est souvent le défaut pratique parce que le système peut rendre des aperçus, exécuter la recherche et appliquer l'accès basé sur les rôles sans demander aux utilisateurs de gérer des clés.
Le chiffrement côté client peut convenir si l'application est surtout un coffre-fort, comme stocker des PDF signés finaux pour un petit groupe d'exécutifs. Le compromis est une commodité intégrée plus faible à moins d'ajouter des outils côté client.
Les IDs sont à haut risque mais souvent de courte durée. Beaucoup d'équipes n'en ont besoin que le temps de vérifier une personne, puis les suppriment. Le flux est une visualisation rapide et des règles de manipulation strictes, pas de collaboration.
Une approche courante est le chiffrement côté serveur associé à un contrôle d'accès strict, des journaux d'audit forts et une rétention courte. Le chiffrement côté client peut convenir si le personnel de support ne doit jamais pouvoir voir les IDs, mais il faut alors un autre moyen de compléter la vérification.
Les dossiers médicaux portent des attentes de confidentialité plus fortes. Les utilisateurs supposent souvent que seul le minimum de personnes peut y accéder.
Le chiffrement côté client peut réduire l'exposition si le serveur est compromis ou si l'accès admin est détourné. Mais il peut aussi créer de vrais problèmes UX et opérationnels : réinitialisations de mot de passe, changements d'appareil et accès d'urgence deviennent compliqués.
Avant de choisir, mappez chaque type de document au flux de travail :
Commencez par écrire ce que vous stockez et qui y touche. Un dossier appelé « uploads » n'est pas une politique.
Listez les rôles et répondez à deux questions : qui doit pouvoir ouvrir le fichier, et qui ne doit jamais pouvoir l'ouvrir (y compris les admins) ? Incluez la rétention pendant que vous y êtes.
Soyez direct sur ce que vous défendez.
Ensuite, testez l'expérience :
Récupération et support : Que se passe-t-il lorsqu'une personne oublie un mot de passe ou perd un téléphone ? Si vous devez récupérer l'accès, le chiffrement purement côté client peut ne pas convenir.
Fonctionnalités indispensables : Avez-vous besoin d'aperçus, de recherche, d'OCR, de signature électronique ou de traitement via API ? Beaucoup de ces fonctions sont plus simples avec le déchiffrement côté serveur quelque part dans le flux.
Audit et conformité : Avez-vous besoin de journaux clairs indiquant qui a accédé à quoi et quand ? Les deux modèles peuvent journaliser les accès, mais les architectures côté client demandent un soin supplémentaire pour éviter les réponses « nous ne pouvons pas vous aider ».
La plupart des équipes finissent par adopter un hybride : chiffrement côté serveur pour la plupart des documents, et chiffrement côté client pour un petit ensemble de téléversements « invisibles au personnel ».
Le piège le plus grand est de traiter le chiffrement comme toute l'histoire. La confidentialité et la conformité dépendent aussi de qui peut accéder aux données, comment l'accès est approuvé, ce qui est journalisé, combien de temps les fichiers sont conservés et comment les demandes de suppression sont traitées.
Un second piège est de construire le chiffrement côté client sans plan de récupération. Si un utilisateur perd un appareil, oublie une phrase secrète ou quitte l'entreprise, pouvez-vous restaurer l'accès sans casser votre promesse de sécurité ? « Nous ne pouvons pas vous aider » peut être acceptable pour un coffre personnel, mais échoue souvent dans les applications métier.
Ces erreurs provoquent des fuites et des contournements réels :
Exemple : une clinique chiffre des formulaires d'admission, puis le personnel exporte un rapport de facturation qui crée un dossier local non chiffré. Ce dossier est sauvegardé sur un drive partagé. La fuite se produit dans le flux de travail, pas dans la crypto.
Écrivez une phrase simple : qui doit pouvoir lire ces fichiers, et qui ne doit jamais pouvoir le faire, même si quelqu'un obtient accès à vos serveurs.
Ensuite vérifiez :
Une petite clinique a une application où le personnel téléverse des orientations patient (PDF) et des photos d'ID d'assurance. L'objectif est d'acheminer rapidement les documents aux bonnes personnes, tout en réduisant les dégâts dus à la perte d'appareils, aux comptes compromis ou aux erreurs cloud.
Une approche viable est le chiffrement côté serveur avec des rôles stricts. Les fichiers sont chiffrés au repos, et l'accès est contrôlé par des permissions : l'accueil peut téléverser, la facturation peut voir les IDs, et les cliniciens peuvent voir les orientations. C'est généralement plus facile au quotidien parce que le personnel peut ouvrir les documents sur desktop ou mobile sans étapes supplémentaires, et les superviseurs peuvent réassigner l'accès en cas d'absence.
Une autre approche utilise le chiffrement côté client pour les éléments les plus sensibles. Le fichier est chiffré sur l'appareil avant le téléversement, donc le serveur stocke du texte chiffré. Cela peut réduire l'impact des fuites serveur et de l'accès interne, mais change les opérations :
Les utilisateurs ressentent de la friction autour du partage, de l'accès mobile et de la récupération après la perte d'un téléphone. Ces détails comptent autant que le modèle de chiffrement lui-même.
Commencez par écrire vos hypothèses de menace en langage clair. Choisissez l'approche la plus simple qui satisfait votre risque, puis renforcez seulement là où les documents le justifient vraiment.
Mettez la décision dans un court jeu de règles interne que les gens peuvent suivre :
Concevez ensuite l'implémentation autour de ces règles : vérifications de rôle, actions auditées (visualisation, téléchargement, partage), aperçus sûrs et gestion soignée des clés.
Si vous construisez sur une plateforme no-code comme AppMaster (appmaster.io), il aide de modéliser les rôles et les flux d'approbation tôt, puis d'ajuster au fur et à mesure que les exigences changent sans réécrire toute l'application. L'important est de faire en sorte que le chemin sécurisé soit le chemin facile pour les vrais utilisateurs.
When should I choose client-side encryption instead of server-side encryption?Utilisez le chiffrement côté serveur quand vous avez besoin de prévisualisations fluides, d'OCR, d'analyse antivirus et d'une récupération de compte facile. Utilisez le chiffrement côté client quand réduire le risque interne et limiter ce que vos serveurs peuvent lire compte plus que la commodité.
Is HTTPS the same as “encrypted storage” for uploads?Non. HTTPS protège le fichier en transit pendant son transfert sur le réseau. Il vous faut toujours le chiffrement au repos et un bon contrôle d'accès pour protéger les fichiers dans le stockage, les sauvegardes et les systèmes internes.
What does server-side encryption actually protect against?Le chiffrement côté serveur vous protège surtout si quelqu'un obtient un accès brut au stockage (comme un bucket divulgué, un disque volé ou une sauvegarde exposée). Il n'empêche pas quelqu'un qui peut accéder à votre backend ou aux clés de déchiffrer les fichiers.
What does client-side encryption actually protect against?Le chiffrement côté client aide surtout quand votre serveur, les administrateurs ou le compte cloud pourraient être compromis, car le serveur ne stocke que des blobs chiffrés. Il n'aidera pas si l'appareil d'un utilisateur est infecté ou si l'utilisateur partage le fichier déchiffré.
How do I handle password resets and device loss with client-side encryption?Si vous ne prévoyez pas de récupération, les utilisateurs peuvent perdre l'accès de façon permanente après la perte d'un appareil, la réinitialisation du navigateur ou l'oubli d'une phrase secrète. Par défaut sûr, concevez une méthode de récupération claire (comme une clé de récupération ou un flux d'entiercement approuvé) et expliquez honnêtement le compromis.
How does encryption choice affect sharing files with coworkers?Le chiffrement côté serveur rend le partage principalement une question d'autorisations, car le serveur peut déchiffrer pour les utilisateurs autorisés. Le chiffrement côté client exige souvent un partage de clés et des règles de révocation, ce qui complique l'accès de groupe et le offboarding.
Will client-side encryption break OCR and full-text search?Généralement oui, car l'OCR et la recherche en texte intégral nécessitent la lecture du contenu du document. Avec le chiffrement côté client, vous devez soit faire ce travail sur l'appareil (plus difficile à supporter), soit accepter une recherche limitée (par exemple par noms de fichiers et étiquettes).
What’s the best approach for storing passport or driver’s license uploads?Par défaut, optez pour le chiffrement côté serveur avec des rôles stricts, une rétention courte et un audit renforcé si le personnel doit voir rapidement les IDs. Envisagez le chiffrement côté client seulement si le personnel ne doit absolument jamais pouvoir voir les IDs, et que vous disposez d'un flux de vérification alternatif.
How should I treat contracts compared to other document types?Si vous avez besoin de workflows d'équipe (revue, approbations, pistes d'audit, prévisualisations), le chiffrement côté serveur est généralement la base pratique. Si c'est plus comme un coffre privé pour un petit groupe, le chiffrement côté client peut convenir, mais attendez-vous à plus de friction pour l'accès et le partage.
What’s a simple way to decide on an encryption model for my app?Commencez par lister qui doit pouvoir ouvrir chaque type de document et qui ne doit jamais pouvoir le faire, même avec un accès administrateur. Décidez ensuite où la déchiffrement est autorisé (serveur, client ou les deux), définissez la rétention et assurez-vous que vos journaux enregistrent les événements de consultation et de téléchargement.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
