Chiffrement au repos vs en transit : l’essentiel à connaître

Thomas Blanc
Thomas Blanc
DPO externalisé et Formateur RGPD
Mis à jour le juin 20, 2025

Privacy by design : pourquoi nous ?

  • ✅ Privacy dès la conception
  • ✅ Analyse des risques
  • ✅ Intégration simple

Le chiffrement est partout. Vous en entendez parler à chaque audit de sécurité, chaque discussion RGPD, chaque fois qu’une donnée sensible circule ou est stockée. Mais savez-vous vraiment faire la différence entre chiffrement au repos et chiffrement en transit ? Et surtout, savez-vous quand utiliser l’un ou l’autre, comment, et pourquoi ?


Chiffrement au repos vs en transit : la différence clé

Le chiffrement peut intervenir à deux moments bien distincts du cycle de vie de la donnée quand elle est immobile, et quand elle circule.

  • Chiffrement au repos : il protège les données lorsqu’elles sont stockées sur un support physique ou virtuel disque dur, base de données, machine virtuelle, cloud, smartphone… L’objectif : éviter que des tiers malveillants puissent les lire en cas de vol, d’intrusion ou de compromission serveur.
  • Chiffrement en transit : ici, l’enjeu est de sécuriser les données pendant leur transfert via un réseau (internet, VPN, réseau privé, email, API…). Il agit comme un tunnel chiffré qui empêche toute interception, écoute ou modification pendant l’envoi.

📌 Ce qu’il faut retenir :

Chiffrement au reposChiffrement en transit
Quand ?Données stockéesDonnées envoyées / reçues
OutilsFDE, chiffrement fichier, base de donnéesTLS/SSL, VPN, HTTPS
Risques visésVol physique, piratage serveur, accès non autoriséInterception réseau, attaque Man-in-the-Middle, fuite en clair

💡 Conseil : Le chiffrement en transit est souvent visible (ex : HTTPS dans le navigateur). Le chiffrement au repos est invisible pour l’utilisateur… mais tout aussi crucial.

Les deux sont indispensables : sécuriser uniquement le transport sans protéger le stockage (ou l’inverse) revient à verrouiller la porte d’entrée mais laisser les fenêtres grandes ouvertes.


Symétrique ou asymétrique : bien choisir pour mieux protéger

Deux familles de chiffrement, deux philosophies, un objectif commun : la confidentialité.

Chiffrement symétrique (ex : AES, Blowfish)
Une seule clé partagée pour chiffrer et déchiffrer. Ultra rapide, il excelle sur les volumes importants de données : bases de données, sauvegardes, fichiers sensibles
✅ Avantage : performance
⚠️ Limite : la gestion sécurisée de la clé (distribution, stockage)

Chiffrement asymétrique (ex : RSA, ECC, DSA)
Deux clés différentes : une clé publique pour chiffrer, une clé privée pour déchiffrer. Idéal pour les échanges sensibles, l’authentification, les certificats numériques.
✅ Avantage : sécurité renforcée, pas besoin d’échanger la clé privée
⚠️ Limite : plus lent, donc réservé aux échanges ciblés


Et dans la vraie vie ? On mixe.
C’est ce qu’on appelle le chiffrement hybride :

  • Une connexion sécurisée (TLS/SSL) s’établit avec un chiffrement asymétrique pour échanger une clé symétrique éphémère
  • Ensuite, le flux de données passe en chiffrement symétrique, pour allier vitesse et sécurité

💡 C’est ce principe qui sécurise vos achats en ligne, vos emails, ou vos accès aux outils métiers.


RGPD : ce que dit (vraiment) l’article 32 sur le chiffrement

Le RGPD n’impose pas explicitement le chiffrement, mais attention : il l’attend fortement.

Article 32 – Sécurité du traitement :

“Le responsable du traitement et le sous-traitant mettent en œuvre des mesures techniques et organisationnelles appropriées […] notamment le chiffrement des données à caractère personnel.”

Cela signifie quoi concrètement ?

👉 Le chiffrement n’est pas obligatoire par défaut, mais il fait partie des bonnes pratiques attendues.
👉 Si vous choisissez de ne pas chiffrer certaines données sensibles, vous devez le justifier et le documenter : contexte métier, analyse de risque, mesures compensatoires.

🔍 Autrement dit : le chiffrement est une ligne de défense forte, facile à activer et difficile à critiquer en cas de contrôle CNIL.

Et côté DPO/RSSI ?
Le chiffrement devient un élément central des PIA (analyses d’impact), un levier pour prouver la conformité, et un filet de sécurité juridique en cas de fuite.

Ne pas chiffrer, aujourd’hui, c’est s’exposer à devoir se justifier. Et en cas de litige ou d’incident, c’est souvent ce point qui fait la différence entre une simple déclaration et une sanction.


Où, quand et pourquoi chiffrer

Le chiffrement devient réellement utile lorsqu’il est appliqué au bon endroit, en fonction des risques réels et de la valeur des données. Voici quatre cas concrets pour illustrer comment faire les bons choix.

1. Emails internes contenant des données RH
Ces échanges peuvent contenir des informations sensibles : arrêts maladie, bulletins de paie, contrats, etc.
➡ Le chiffrement en transit (via TLS) protège les messages lorsqu’ils circulent entre serveurs.
➡ Mais ce n’est pas suffisant : une fois reçues, les pièces jointes doivent aussi être chiffrées au repos si elles sont stockées sur un poste de travail, un serveur ou dans le cloud.

2. Base de données clients dans un SaaS B2B
Un CRM, un outil de gestion client ou un back-office e-commerce traite souvent des données personnelles à grande échelle.
➡ Ici, le chiffrement au repos est indispensable (via FDE ou TDE) pour éviter qu’un attaquant accédant aux disques ou aux sauvegardes puisse les lire.
➡ Complétez avec une bonne gestion des droits d’accès et une rotation régulière des clés de chiffrement.

3. Données de santé hébergées dans le cloud
Le stockage d’informations médicales est encadré par des exigences fortes (HDS, RGPD).
➡ Un chiffrement au repos est nécessaire, mais pas suffisant si vous externalisez l’hébergement.
➡ Il faut garder la maîtrise des clés (modèle BYOK ou HYOK), afin que le prestataire cloud ne puisse pas lui-même déchiffrer les données.

4. Transferts API entre systèmes d’information
Les flux API automatisés peuvent transporter des données sensibles (commandes, factures, identités clients).
➡ Protégez ces transferts avec un chiffrement en transit basé sur TLS 1.3.
➡ Vérifiez aussi que les certificats sont valides, que les accès sont bien restreints, et que chaque appel est tracé pour des raisons de conformité.


Les bonnes pratiques qui font vraiment la différence

Mettre en place du chiffrement, c’est bien. Mais le faire intelligemment, c’est ce qui fait la différence entre une simple case cochée et une vraie stratégie de sécurité. Voici les pratiques qui comptent réellement :

Choisissez des algorithmes robustes et à jour
Privilégiez des standards éprouvés comme AES-256 (chiffrement symétrique), RSA-2048 ou ECC (chiffrement asymétrique), et TLS 1.3 pour les communications. Bannissez les algorithmes obsolètes (DES, RC4, TLS 1.0/1.1), encore présents dans certaines vieilles applications métiers.

Séparez les clés des données chiffrées
Une erreur encore trop fréquente : stocker la clé de chiffrement dans la même base ou le même répertoire que les données chiffrées. En cas de compromission, l’attaquant a accès à tout. Optez pour une solution de gestion de clés dédiée (KMS, HSM ou solution BYOK).

Double chiffrement pour les données ultra-sensibles
Dans certains cas critiques (santé, juridique, souveraineté), une seule couche de chiffrement peut ne pas suffire. Le double chiffrement (avec deux clés ou deux niveaux distincts) permet d’ajouter une défense en profondeur, notamment face aux risques d’accès interne non autorisé.

Anticipez la cryptographie post-quantique
Même si les menaces liées à l’informatique quantique semblent lointaines, certaines données doivent rester confidentielles pendant 10 à 20 ans. Il est temps de penser à l’intégration d’algorithmes post-quantiques ou hybrides, surtout pour les secteurs critiques.

Formez vos équipes et documentez vos pratiques
90 % des fuites de données sont liées à des erreurs humaines. Des clés mal stockées, des transferts non chiffrés par méconnaissance, des configurations faibles… Une sensibilisation régulière et des procédures documentées réduisent fortement les risques d’exposition involontaire.


FAQ – Chiffrement des données : les questions fréquentes

1. Le chiffrement remplace-t-il un pare-feu ou une authentification forte ?

Non, le chiffrement ne remplace aucune autre mesure de sécurité. Il la complète. Là où un pare-feu filtre les accès et l’authentification vérifie l’identité, le chiffrement protège la donnée elle-même, même si l’infrastructure est compromise. C’est la logique du modèle Zero Trust : supposez que la brèche est inévitable, et protégez la donnée au cœur.


2. Quelle est la différence entre un chiffrement “activé par défaut” et un chiffrement “géré” ?

Le chiffrement “activé par défaut” (ex : FDE sur un disque dur) protège passivement, mais sans contrôle fin. Un chiffrement “géré” (chiffrement applicatif, avec gestion des clés) permet d’appliquer des politiques : qui accède, quand, comment, avec quelles conditions.
👉 Pour répondre au RGPD et à des exigences sectorielles fortes, le chiffrement doit être maîtrisé et contextualisé, pas juste activé.


3. En cas de fuite de données, le chiffrement peut-il exonérer l’entreprise ?

Pas automatiquement, mais c’est un élément majeur d’atténuation de la responsabilité. Si les données compromises sont chiffrées, et que la clé n’a pas été exposée, l’entreprise peut ne pas être obligée de notifier les personnes concernées (RGPD art. 34). C’est une protection juridique autant que technique.


4. Peut-on auditer un chiffrement ? Et comment le prouver en cas de contrôle ?

Oui, un chiffrement peut et doit être audité. Cela passe par des logs, des preuves de configuration, des rapports de conformité (ex : PCI DSS, ISO 27001), ou des preuves de rotation des clés. En cas de contrôle CNIL, il est crucial de documenter votre politique de chiffrement : périmètre, méthodes, clés, accès, preuves d’application.


5. Quels sont les défis du chiffrement dans les environnements multicloud ?

Dans un contexte multicloud, les données circulent et sont stockées chez plusieurs fournisseurs. Les défis sont nombreux :

  • Unifier la gestion des clés (multi-KMS ou solution centralisée)
  • Maintenir la souveraineté des données
  • Auditer les configurations de chaque cloud
  • Assurer l’interopérabilité des politiques de chiffrement

Une stratégie cloud-native sans chiffrement maîtrisé est une bombe à retardement réglementaire.