Chiffrement en transit vs au repos : deux protections pour deux menaces
Quand un fournisseur cloud écrit « vos données sont chiffrées », il dit techniquement la vérité de la même manière qu’un restaurant qui affiche « cuisine maison » tout en utilisant des surgelés Brake France. Le mot « chiffré » couvre au minimum deux réalités complètement distinctes – le chiffrement en transit et le chiffrement au repos – et confondre les deux revient à croire qu’une lettre est en sécurité parce qu’on l’a mise dans une enveloppe opaque, sans se demander si le bureau de poste ouvre les enveloppes à l’arrivée. Si vous venez de la section sur la sécurité et le chiffrement cloud, vous savez déjà que le chiffrement est un empilement de couches. Cet article décompose les deux premières, celles que tout le monde devrait comprendre avant de signer un contrat cloud.
La réponse courte : le chiffrement en transit (TLS) protège vos fichiers pendant qu’ils voyagent entre votre appareil et le serveur. Le chiffrement au repos (typiquement AES-256) protège vos fichiers quand ils dorment sur les disques du datacenter. Avoir l’un sans l’autre, c’est verrouiller la porte d’entrée en laissant la fenêtre du salon grande ouverte.
En transit : quand vos fichiers prennent le train
Le chiffrement en transit, c’est TLS (Transport Layer Security), le même protocole qui fait apparaître le petit cadenas dans votre navigateur. Quand vous uploadez un fichier sur kDrive, Dropbox, Google Drive ou n’importe quel cloud sérieux en 2026, les données sont chiffrées entre votre appareil et le serveur du fournisseur. Un attaquant qui intercepte le flux réseau – sur un Wi-Fi public de café, par exemple – ne verra qu’un flux de données incompréhensible.
C’est une protection contre l’interception en chemin. Et uniquement ça. Une fois que le fichier arrive sur le serveur, TLS a fait son travail et disparaît. Le fichier est déchiffré côté serveur pour être traité, indexé, stocké. C’est à ce moment-là que le chiffrement au repos prend (ou ne prend pas) le relais.
L’analogie du fourgon blindé est parlante : TLS, c’est le fourgon qui transporte votre argent entre la banque et votre entreprise. Personne ne peut braquer le fourgon en chemin (en théorie). Mais une fois l’argent déposé dans votre coffre, la sécurité du fourgon n’a plus aucune importance – ce qui compte, c’est la qualité du coffre.
En pratique, tous les fournisseurs cloud réputés utilisent TLS 1.2 ou 1.3. C’est devenu un strict minimum, pas un argument de vente. Un fournisseur qui ne proposerait pas TLS en 2026 serait comme un taxi sans ceinture de sécurité – techniquement légal nulle part et pratiquement suicidaire.
Pourquoi aller plus loin avec le chiffrement bout-en-bout
Si TLS protège le trajet et AES-256 protège le stockage, qui protège contre le fournisseur lui-même ? C’est exactement la question à laquelle répond le chiffrement bout-en-bout. Avec l’E2EE, les données ne sont jamais déchiffrées côté serveur – le fournisseur reçoit un blob opaque et le stocke tel quel. C’est la seule couche qui protège contre une fuite chez le fournisseur.
Au repos, c’est une autre histoire. Le chiffrement au repos protège contre un scénario précis : quelqu’un qui accède physiquement aux disques durs du datacenter. Un employé malveillant du sous-traitant qui gère les serveurs, un cambrioleur qui vole un rack (ça arrive, rarement, mais ça arrive), ou une saisie judiciaire des disques physiques. Avec AES-256 au repos, les données sur le disque sont illisibles sans la clé de déchiffrement.
Mais voici le piège : dans la configuration standard, c’est le fournisseur cloud qui détient cette clé. Vos données sont chiffrées au repos pour les protéger des autres, pas du fournisseur. Google, Microsoft, Dropbox, Infomaniak – tous chiffrent au repos, et tous peuvent techniquement déchiffrer vos fichiers s’ils le décident ou y sont contraints par une autorité. Le chiffrement au repos standard vous protège du vol physique, pas de la surveillance institutionnelle.
C’est la raison pour laquelle la question fondamentale n’est pas « mes données sont-elles chiffrées ? » mais « qui détient la clé ? ». Et c’est exactement ce qui distingue le chiffrement standard de l’architecture zero-knowledge.
La gestion des clés change absolument tout
Le vrai pouvoir n’est pas dans l’algorithme de chiffrement – AES-256 est AES-256 partout. Le vrai pouvoir est dans qui contrôle la clé de déchiffrement. Dans un modèle classique (Google Drive, OneDrive, kDrive en configuration standard), le fournisseur génère la clé, la stocke, et l’utilise pour chiffrer et déchiffrer vos fichiers de manière transparente. Vous ne voyez jamais cette clé, vous ne savez pas où elle est, et vous n’avez aucun contrôle dessus.
Dans un modèle BYOK (Bring Your Own Key) ou zero-knowledge, c’est vous qui fournissez la clé – ou elle est dérivée de votre mot de passe côté client, avant que quoi que ce soit n’arrive sur le serveur. Le fournisseur ne peut littéralement pas déchiffrer vos données, même s’il le voulait, même sous injonction judiciaire.
En résumé : le chiffrement en transit est un acquis – ne signez jamais avec un fournisseur qui ne l’offre pas (ce serait comme acheter une voiture sans freins). Le chiffrement au repos est la norme, mais son efficacité dépend entièrement de qui détient la clé. Et la combinaison des deux sans E2EE ou zero-knowledge vous protège de tout le monde sauf de votre fournisseur. Pour la plupart des utilisateurs, c’est suffisant. Pour les données sensibles – médicales, juridiques, financières – c’est un compromis à évaluer soigneusement.