Quand vous déposez un fichier sur un service cloud, il quitte votre ordinateur pour atterrir sur un serveur distant. Ce serveur appartient à un fournisseur tiers, hébergé dans un datacenter que vous ne visitez pas. Sans chiffrement, ce fichier reste lisible par quiconque accède à l’infrastructure, qu’il s’agisse d’un administrateur, d’un attaquant ou d’une autorité étrangère. Le chiffrement des données dans le cloud transforme ce fichier en une suite inintelligible que seul le détenteur de la clé peut reconstituer.
Qui contrôle la clé de chiffrement contrôle réellement la donnée
La plupart des fournisseurs cloud chiffrent les données au repos et en transit. Le problème n’est pas l’absence de chiffrement, mais l’endroit où la clé est stockée.
Quand le fournisseur génère et conserve la clé, il peut techniquement déchiffrer vos fichiers. En cas de faille sur son infrastructure, la clé et la donnée sont exposées simultanément. Ce scénario n’est pas théorique : les attaques ciblant les prestataires de services cloud se multiplient.
Trois modèles de gestion des clés coexistent :
- Clé gérée par le fournisseur : le service cloud génère, stocke et utilise la clé. Vous n’avez rien à configurer, mais aucun contrôle réel sur l’accès aux données.
- Clé gérée par le client (BYOK) : vous fournissez votre propre clé au fournisseur, qui l’utilise pour chiffrer et déchiffrer. Vous gardez la main sur la génération, mais la clé transite tout de même sur l’infrastructure du prestataire.
- Clé détenue exclusivement côté client (HYOK ou chiffrement client-side) : le chiffrement et le déchiffrement se font sur votre poste ou votre serveur avant tout envoi. Le fournisseur ne voit jamais la clé en clair. C’est le seul modèle qui garantit que le prestataire ne peut pas lire vos fichiers.
Vous stockez des données de santé, des contrats ou des éléments de propriété intellectuelle ? Le chiffrement côté client est le seul qui empêche le fournisseur d’accéder au contenu. Les autres modèles restent utiles, mais ils déplacent la confiance sans l’éliminer.

DORA et NIS2 : le chiffrement cloud passe d’une bonne pratique à une obligation légale
Jusqu’à récemment, chiffrer ses données dans le cloud relevait d’une recommandation. Deux textes européens changent la donne.
DORA pour le secteur financier
Depuis le 17 janvier 2025, le règlement DORA (Regulation (EU) 2022/2554) impose aux entités financières et à leurs prestataires cloud des exigences précises. Chaque organisation doit disposer d’une politique de chiffrement documentée, gérer le cycle de vie complet de ses clés et être capable de remplacer une technologie cryptographique dès qu’une vulnérabilité est identifiée.
DORA ne se contente pas de recommander : il soumet les prestataires ICT (y compris les hyperscalers cloud) à la supervision directe des autorités européennes. Un fournisseur qui ne respecte pas ces exigences expose son client à un risque réglementaire direct.
NIS2 pour les opérateurs de services cloud et datacenters
La directive NIS2 (Directive (EU) 2022/2555) élargit le périmètre. Les fournisseurs de cloud, de datacenters, de DNS et de CDN figurent désormais parmi les entités soumises à des obligations cryptographiques détaillées. Les textes d’application vont bien au-delà du simple conseil de chiffrer au repos et en transit : ils prescrivent des mesures techniques spécifiques.
DORA et NIS2 transforment le chiffrement en obligation réglementaire directe, identique dans tous les États membres. Si votre organisation traite des données sensibles dans le cloud, la conformité passe désormais par une stratégie de chiffrement formalisée et vérifiable.
Données au repos, en transit, en cours d’utilisation : trois états, trois protections
Le chiffrement ne s’applique pas de la même façon selon l’état de la donnée. Comprendre cette distinction évite de croire qu’un seul mécanisme suffit.
Les données au repos sont les fichiers stockés sur les disques du fournisseur cloud. Le chiffrement au repos (AES-256 par exemple) les rend illisibles en cas de vol physique d’un disque ou d’accès non autorisé au stockage.
Les données en transit circulent entre votre appareil et le serveur du fournisseur, ou entre deux services cloud. Le protocole TLS protège ce canal de communication. Sans lui, un attaquant positionné sur le réseau peut intercepter les échanges.
Les données en cours d’utilisation posent le problème le plus complexe. Quand une application traite un fichier, elle doit le déchiffrer en mémoire. À cet instant, la donnée est vulnérable. Deux approches tentent de résoudre ce problème :
- Le confidential computing utilise des enclaves matérielles (environnements d’exécution sécurisés) pour isoler les données en mémoire. Même l’administrateur du serveur ne peut pas lire ce qui se passe dans l’enclave.
- Le chiffrement homomorphe permet de réaliser des calculs directement sur des données chiffrées, sans jamais les déchiffrer. Cette technologie reste lourde en ressources, mais elle progresse rapidement.
La majorité des services cloud couvrent correctement le repos et le transit. La protection des données en cours d’utilisation reste le maillon faible, et c’est là que se concentrent les investissements actuels.

Mettre en place une stratégie de chiffrement cloud sans se perdre
Chiffrer tout, partout, avec le niveau maximal semble séduisant. En pratique, cette approche génère une complexité ingérable et dégrade les performances des applications.
La première étape consiste à classifier vos données. Toutes n’ont pas la même sensibilité. Un document marketing public ne justifie pas le même niveau de protection qu’un fichier contenant des données personnelles de clients. La classification oriente le choix du modèle de gestion des clés et du niveau de chiffrement.
Viennent ensuite les questions opérationnelles. Qui génère les clés ? Où sont-elles stockées ? Comment les renouveler ? Que se passe-t-il si une clé est compromise ? Une stratégie solide couvre tout le cycle de vie de la clé, de sa création à sa destruction.
Le choix du fournisseur cloud entre aussi en jeu. Certains proposent nativement le chiffrement côté client, d’autres nécessitent une solution tierce. Les services de gestion de clés (KMS) varient considérablement d’un fournisseur à l’autre en matière de contrôle et de transparence.
Dernier point souvent négligé : tester la restauration des données chiffrées. Un chiffrement parfait ne sert à rien si la procédure de déchiffrement échoue le jour où vous en avez besoin. La sécurité des données dans le cloud repose autant sur la rigueur opérationnelle que sur la technologie elle-même.

