---
term: 'Chiffrement des Données au Repos et en Transit'
seoTitle: 'Chiffrement au repos vs. en transit : TLS, AES-256, gestion des clés'
headline: "Qu'est-ce que le chiffrement des données au repos et en transit ?"
slug: chiffrement-des-donnees
category: auth-security
shortDefinition: 'Le chiffrement au repos est un contrôle qui rend illisibles sans les clés les données stockées ; le chiffrement en transit protège les données sur le réseau.'
relatedTerms:
- data-layer-vs-application-layer-security
- row-level-security
- api-key-security
- tenant-isolation
contrastsWith:
- data-layer-vs-application-layer-security
aboutTerms:
- 'Encryption at Rest'
- 'Encryption in Transit'
- 'TLS'
- 'Key Management'
faq:
- question: "Qu'est-ce que le chiffrement au repos ?"
answer: "Chiffrer les données stockées — disques, bases de données, sauvegardes, stockage objet — pour que quiconque obtient le support de stockage sans les clés ne détienne que du texte chiffré. La norme est AES-256 ; la protection vise le matériel volé, les sauvegardes qui fuitent et les couches de stockage compromises."
- question: "Qu'est-ce que le chiffrement en transit ?"
answer: "Chiffrer les données pendant qu'elles traversent les réseaux, pour que le trafic intercepté soit illisible — le rôle de TLS, autrement dit ce qu'apporte le S de HTTPS. Il protège contre les écoutes et les attaques de l'homme du milieu (man-in-the-middle) sur n'importe quel saut entre le client et le serveur."
- question: 'Quelle est la différence entre chiffrement au repos et chiffrement en transit ?'
answer: "Des états de données différents, des menaces différentes. Le chiffrement au repos protège les copies stockées contre le vol de supports et de sauvegardes ; le chiffrement en transit protège les données en mouvement contre les écoutes. Ils sont complémentaires, pas interchangeables — tout référentiel de sécurité sérieux exige les deux, car chacun arrête des attaques que l'autre ne voit pas."
- question: 'HTTPS est-il la même chose que TLS ?'
answer: "HTTPS, c'est HTTP transporté sur TLS, le protocole cryptographique qui sécurise la connexion. TLS 1.3 est la version actuelle — handshakes plus rapides, suites de chiffrement faibles supprimées, confidentialité persistante (forward secrecy) obligatoire ; les versions 1.0 et 1.1 sont officiellement dépréciées et doivent être désactivées."
- question: "Qu'est-ce qu'AES-256 ?"
answer: "L'Advanced Encryption Standard avec une clé de 256 bits — un algorithme de chiffrement symétrique par blocs normalisé par le NIST, pratiquement insensible à la force brute, et le choix de facto pour les données au repos. En pratique, privilégiez un mode authentifié comme AES-GCM, qui détecte les altérations en plus de masquer le contenu."
- question: 'Quelle est la différence entre chiffrement symétrique et asymétrique ?'
answer: "Le symétrique utilise une seule clé partagée dans les deux sens — rapide, adapté aux gros volumes de données (AES). L'asymétrique utilise une paire de clés publique/privée — plus lent, adapté à l'échange de clés, aux certificats et aux signatures. TLS utilise les deux : un handshake asymétrique établit une clé de session symétrique qui chiffre le trafic proprement dit."
- question: 'En quoi le chiffrement de bout en bout diffère-t-il du chiffrement en transit ?'
answer: "Par le périmètre de confiance. TLS protège chaque saut, mais le serveur déchiffre et peut tout lire. Le chiffrement de bout en bout signifie que seuls les utilisateurs qui communiquent détiennent les clés — l'opérateur du service lui-même ne peut pas lire le contenu. L'E2EE protège contre le serveur ; TLS protège le chemin qui y mène."
- question: 'Le chiffrement au repos protège-t-il contre les pirates ?'
answer: "Seulement contre une catégorie précise : ceux qui mettent la main sur le stockage — disques volés, sauvegardes qui fuitent, buckets mal configurés. Un attaquant qui compromet l'application ou vole des identifiants lit les données librement, car l'app les déchiffre légitimement. Le chiffrement n'est pas du contrôle d'accès ; il complète les ACL, sans jamais les remplacer."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'NIST FIPS 197 — Advanced Encryption Standard (AES)'
url: 'https://csrc.nist.gov/pubs/fips/197/final'
- name: 'RFC 8446 — TLS 1.3'
url: 'https://datatracker.ietf.org/doc/html/rfc8446'
- name: 'NIST SP 800-57 — Key Management Recommendations'
url: 'https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final'
- name: 'OWASP Cryptographic Storage Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html'
- name: 'Encryption — Wikipedia'
url: 'https://en.wikipedia.org/wiki/Encryption'
cta:
title: "Chiffré par défaut, d'un bout à l'autre de votre stack"
text: "Back4app sert chaque API, chaque fichier et chaque Live Query via TLS et stocke les données et les sauvegardes chiffrées — il vous reste la politique : des mots de passe uniquement hachés (intégré), le chiffrement au niveau du champ pour ce qui est vraiment sensible, et les ACL pour l'accès."
linkText: 'Commencez gratuitement'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-15'
translationKey: data-encryption-at-rest-transit
---
**Le chiffrement au repos est un contrôle qui rend illisibles sans les clés les données stockées ; le chiffrement en transit protège les données sur le réseau.** Les données existent dans trois états — au repos sur le stockage, en transit sur le réseau et en cours d'utilisation en mémoire — et les deux premiers constituent l'obligation de base de toute application : [AES-256](https://csrc.nist.gov/pubs/fips/197/final) pour ce qui est stocké, TLS pour ce qui circule. Le troisième état (protégé par les environnements d'exécution de confiance et, à la pointe, par le chiffrement homomorphe) est bien réel mais, pour la plupart des équipes applicatives, relève de la couche de quelqu'un d'autre.
## Points clés
| Question | Réponse |
| --- | --- |
| Au repos | AES-256 sur les disques, bases de données, sauvegardes — contre le vol de supports |
| En transit | TLS 1.2+ sur chaque connexion — contre les écoutes et le MITM |
| L'angle mort | Aucun des deux n'arrête une app compromise — le chiffrement n'est pas du contrôle d'accès |
| Le vrai problème | La gestion des clés — des clés stockées à côté des données, c'est du théâtre |
| La confusion à dissiper | Les mots de passe sont *hachés* (bcrypt/argon2), jamais chiffrés |
## Les deux protections — et ce que chacune arrête vraiment
Le tableau honnête que les pages les mieux classées omettent — y compris la colonne qui compte le plus :
```text
Norme Couvre Arrête N'arrête PAS
En transit TLS 1.2+/HTTPS chaque saut réseau écoutes, MITM, endpoints compromis —
espionnage au café le serveur lit tout sans souci
Au repos AES-256 (GCM) disques, BDD, sauvegardes disques volés, sauvegardes identifiants volés,
fuitées, buckets ouverts injection SQL, bugs applicatifs
En usage TEE RAM pendant le traitement extraction de mémoire — surtout l'affaire de la plateforme
Aucune ne stoppe un attaquant auquel l'app elle-même fait confiance. L'app détient les
clés et déchiffre à la demande — le chiffrement complète le contrôle d'accès, sans le remplacer.
```
À quoi ressemblent les réglages par défaut depuis le code applicatif :
**JavaScript:**
```javascript
// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Flutter:**
```dart
// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, 'ada@example.com');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Swift:**
```swift
// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself
// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code
```
## Le fonctionnement de TLS, en un paragraphe
L'astuce élégante : la cryptographie asymétrique est lente mais ne nécessite aucun secret partagé ; la symétrique est rapide mais en exige un. Le [handshake TLS](https://datatracker.ietf.org/doc/html/rfc8446) utilise donc la première pour établir la seconde — le client vérifie le certificat du serveur (le contrôle d'identité qui rend l'interception détectable), les deux parties conviennent d'une nouvelle clé de session via un échange de clés asymétrique, et tout ce qui suit passe par un chiffrement symétrique rapide. TLS 1.3 a tout resserré : un aller-retour au lieu de deux, suppression des suites de chiffrement obsolètes et de l'échange de clés RSA, confidentialité persistante (forward secrecy) obligatoire — ainsi, un trafic enregistré ne peut pas être déchiffré plus tard, même si la clé à long terme du serveur fuite. Complément mobile que les pages les mieux classées ignorent : les apps peuvent en outre *épingler* les certificats attendus (certificate pinning), échangeant une résistance aux autorités de certification malveillantes contre une vigilance opérationnelle au moment de la rotation.
## Les couches au repos : disque vs. base de données vs. champ vs. application
"Chiffré au repos" recouvre quatre promesses très différentes — chacune neutralise un attaquant différent :
| Couche | Comment | Neutralise | N'affecte pas |
| --- | --- | --- | --- |
| Disque complet (LUKS/dm-crypt) | L'OS chiffre le volume | Matériel volé ou mis au rebut | Quiconque se trouve sur le système en marche |
| Transparent (TDE) | La base de données chiffre les fichiers à l'écriture | Fichiers de données et sauvegardes volés | Quiconque dispose d'identifiants de la base |
| Champ/colonne | Colonnes ciblées chiffrées, l'app détient les clés | DBA curieux, brèches plus larges de la base | La compromission de l'app elle-même |
| Niveau applicatif | Chiffré *avant* d'atteindre le stockage | Tout ce qui se trouve sous l'app | L'app et son magasin de clés |
```mermaid
flowchart LR
accTitle: Chiffrement d'enveloppe (envelope encryption) qui garde les clés séparées des données
accDescr: Les données de l'application sont chiffrées avec une clé de chiffrement des données. Cette clé de données est elle-même chiffrée par une clé de chiffrement de clés conservée dans un service de gestion des clés ou un module matériel de sécurité, si bien qu'une base de données volée contient du texte chiffré et des clés enveloppées, mais rien qui se déchiffre sans le service de clés gardé séparément.
D["Données"] -->|"AES-256-GCM"| C["Texte chiffré
dans la base de données"]
DEK["Clé de données (DEK)"] -->|"chiffre"| D
KEK["Clé de chiffrement de clés (KEK)"] -->|"enveloppe"| DEK
KMS["Service de clés / HSM
système séparé, audité"] -->|"détient"| KEK
T["Voleur en possession de la base"] -.->|"obtient texte chiffré +
clés enveloppées — rien ne s'ouvre"| C
```
La règle qui vaut pour tout le tableau : **plus la couche est haute, plus elle protège, et plus elle coûte**. Le chiffrement au niveau du champ est le compromis honnête — les colonnes chiffrées ne peuvent être ni indexées ni recherchées normalement (le chiffrement déterministe rétablit les recherches par égalité au prix d'une certaine fuite d'information) — c'est pourquoi on le réserve à ce qui est réellement sensible : données de santé, pièces d'identité, secrets. Et l'échec d'audit classique se niche ici : la base de données chiffrée dont les *sauvegardes* partent en clair.
## Le chiffrement de bout en bout est une autre promesse
TLS partout signifie toujours que le serveur lit tout — il déchiffre chaque connexion par conception. Le chiffrement de bout en bout déplace les clés vers les utilisateurs : seuls l'expéditeur et le destinataire peuvent déchiffrer, et l'opérateur sert un texte chiffré qu'il ne peut pas ouvrir. C'est une décision produit différente, pas un réglage plus fort : l'E2EE signifie pas de recherche côté serveur, pas de modération de contenu, pas de récupération si les utilisateurs perdent leurs clés. Les modèles de menace s'emboîtent proprement — TLS défend le chemin, le chiffrement au repos défend le stockage, l'E2EE défend contre le service lui-même — et la plupart des applications s'arrêtent à juste titre aux deux premiers, tandis que les messageries et les coffres-forts numériques justifient le troisième.
## Hachage vs. chiffrement
| | Chiffrement | Hachage |
| --- | --- | --- |
| Réversible | Oui — avec la clé | Non — par conception |
| Adapté à | Les données que vous devez relire | Mots de passe, contrôles d'intégrité |
| Standards | AES-256-GCM | bcrypt, scrypt, argon2 (lents + salés) |
| L'échec typique | Perdre les clés ou les laisser fuiter | Hashes rapides sans sel (MD5, SHA-256 brut) |
Un encadré suffit à dissiper une confusion répandue : **les mots de passe sont hachés, jamais chiffrés.** Personne — serveur compris — ne devrait pouvoir récupérer un mot de passe ; la connexion compare des hashes. Chiffrer les mots de passe, c'est faire exister une clé qui les déchiffre tous — exactement la catastrophe que le hachage est là pour empêcher.
## Cas d'usage courants
- **Toutes les apps web et mobiles** — TLS sur toutes les connexions et un stockage chiffré sont le minimum, pas des features.
- **Données réglementées** — le RGPD cite le chiffrement comme mesure technique appropriée (avec un allègement de l'obligation de notification des violations), les règles sur les données de santé l'imposent pour les données des patients, et les standards de paiement exigent des numéros de carte illisibles au repos et une cryptographie robuste en transit.
- **Sauvegardes et mise hors service** — des sauvegardes chiffrées et le crypto-shredding (détruisez la clé, et les données meurent partout) referment le chapitre de la copie volée.
- **Protection des champs contenant des données personnelles (PII)** — chiffrement au niveau applicatif pour les colonnes dont la fuite ferait la une, et pas un simple incident.
- **Clients mobiles sur des réseaux hostiles** — TLS plus validation des certificats, la défense qui voyage avec l'utilisateur.
## De quelle couche avez-vous besoin ? Matrice de décision
| Situation | Solution |
| --- | --- |
| Toute donnée, toute app | TLS partout + chiffrement au repos de la plateforme — le minimum |
| Le cauchemar de la sauvegarde volée | Sauvegardes chiffrées + clés stockées ailleurs |
| Colonnes sensibles (santé, pièces d'identité) | Chiffrement au niveau du champ ou de l'application, clés dans l'env ou un KMS |
| "Même nous ne devrions pas pouvoir le lire" | Chiffrement de bout en bout — acceptez les coûts produit |
| Mots de passe | Hachage (bcrypt/argon2) — jamais de chiffrement |
| Risque d'accès, pas de vol | [ACL et sécurité au niveau des lignes](/glossary/fr/securite-au-niveau-des-lignes/) — le chiffrement n'y changera rien |
## Limites et trade-offs
- **Le chiffrement n'est pas du contrôle d'accès.** L'argument de la [sécurité en couches](/glossary/fr/securite-couche-donnees-vs-application/) en une ligne : le chiffrement au repos est transparent pour l'app en cours d'exécution, donc les permissions — ACL, CLP, politiques par ligne — restent la défense contre tout attaquant muni d'identifiants.
- **La gestion des clés est le vrai chantier.** Les [recommandations du NIST](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) existent parce que la génération, la séparation, la rotation et la révocation — et non le choix de l'algorithme — sont les points où les déploiements échouent.
- **Le chiffrement au niveau du champ lutte contre la base de données.** Pas d'index, pas de requêtes LIKE, des migrations délicates ; chiffrez les champs qui en ont besoin, pas tout le schéma.
- **TLS s'arrête au point de terminaison.** Les proxies et load balancers qui déchiffrent en cours de route recréent des sauts en clair ; le trafic interne exige la même discipline que l'edge.
- **Conformité ≠ sécurité.** Un chiffrement pour cocher la case, avec les clés à côté des données, satisfait les auditeurs et personne d'autre ; c'est la colonne du modèle de menace qui doit guider la conception.
## Le chiffrement sur Back4app
Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le minimum est fourni par la plateforme : chaque connexion REST, GraphQL et Live Query passe par TLS, et les données comme les sauvegardes sont chiffrées au repos — les deux couches de base arrivent comme des réglages par défaut plutôt que comme des projets. La part restante du développeur correspond exactement à ce qu'esquissent les onglets de code : les mots de passe sont hachés avec bcrypt par Back4app d'office (jamais stockés en clair, jamais récupérables — la règle du hachage imposée par la structure) ; les champs réellement sensibles reçoivent un chiffrement au niveau applicatif dans un `beforeSave` Cloud Code, avec la clé dans la configuration côté serveur plutôt que dans le code, pour que le texte en clair n'atteigne jamais le stockage ; et les secrets restent hors des logs, des URL et des bundles client — la [discipline des clés d'API](/glossary/fr/securite-des-cles-d-api/) appliquée aux données. Reste la pièce que le chiffrement ne peut pas assurer : les [ACL et les permissions de classe](/glossary/fr/listes-de-controle-d-acces-acl/) déterminent qui lit quoi, car le contrôle qui arrête un attaquant muni d'identifiants n'a jamais été la cryptographie — c'était l'autorisation.