Quand un éditeur dit « les données sont chiffrées », ça peut vouloir dire des choses très différentes. Le chiffrement n'est pas un interrupteur on/off : c'est trois couches indépendantes, qui protègent contre des risques différents. La plupart des éditeurs en couvrent une, certains deux. Très peu en couvrent trois — et c'est précisément ça que vous voulez vérifier.
« HTTPS » protège vos données pendant le voyage. Pas pendant qu'elles dorment sur les disques. Et certainement pas une fois qu'elles sont chargées en mémoire dans le logiciel.
01.Les trois niveaux de chiffrement
Vos données passent par trois états successifs, et chacun peut être chiffré ou pas, indépendamment :
1. En transit (TLS)
Pendant le voyage entre votre navigateur et le serveur. Standard depuis 10 ans, tout le monde le fait.
- Standard : TLS 1.2 minimum, idéalement TLS 1.3
- Vérifiable : URL en
https://+ cadenas valide - Protège contre : interception réseau (Wi-Fi public, FAI)
2. Au repos (at-rest)
Quand les données dorment sur les disques durs des serveurs. Beaucoup d'éditeurs l'oublient.
- Standard : AES-256
- Vérifiable : documentation explicite
- Protège contre : vol de disque, ransomware, accès interne illégitime
3. Applicatif (par champ)
Chiffrement de champs spécifiques (mot de passe, RIB, NIR) avec une clé dédiée, séparée du stockage.
- Standard : bcrypt/argon2 (mots de passe), AES-GCM (champs)
- Vérifiable : rare en doc publique, demander en RFP
- Protège contre : compromission du serveur lui-même
02.La confusion entretenue
Le piège classique en RFP : vous demandez « comment les données sont-elles chiffrées sur vos serveurs ? », l'éditeur répond « nous utilisons HTTPS / TLS / une connexion chiffrée ». Ce n'est pas la même question. La connexion ≠ le stockage.
Le chiffrement at-rest est celui qui compte le plus pour des données MJPM. Si un éditeur n'en a pas (et il y en a, sur le marché), un employé du datacenter, un sous-traitant de maintenance, ou un attaquant qui passe les défenses réseau peut potentiellement lire toute la base de données en clair. Pour des dossiers de tutelle qui contiennent identités, comptes bancaires, jugements, ce risque est totalement disproportionné.
03.Ce qu'il faut demander à l'éditeur
| Question précise | Réponse acceptable | Réponse rouge |
|---|---|---|
| Le périmètre at-rest | Base + pièces jointes + sauvegardes, AES-256 | "On chiffre les données" sans préciser |
| Gestion des clés | KMS dédié, rotation périodique, accès loggé | Clé en clair dans la config du serveur |
| Mots de passe utilisateurs | bcrypt ou argon2 avec salt | MD5, SHA-1, ou "chiffrement réversible" |
| Données sensibles (RIB, NIR) | Chiffrement applicatif par champ | Stockées en clair dans la base |
| TLS minimum | TLS 1.2 (idéalement 1.3) + HSTS | TLS 1.0/1.1 toléré |
04.Le cas particulier des sauvegardes
Beaucoup d'éditeurs chiffrent leur base de données mais oublient leurs sauvegardes. Or les sauvegardes sont, en pratique, le point d'attaque le plus commun (vol de disques de backup, accès aux snapshots cloud non chiffrés). Demandez explicitement : « Les sauvegardes sont-elles également chiffrées at-rest, et avec une clé séparée du stockage principal ? »
Une bonne réponse : oui, AES-256, clé gérée séparément (idéalement dans un service KMS dédié type AWS KMS, Azure Key Vault, ou solution interne équivalente).
L'éditeur parle uniquement de « connexion sécurisée » ou « HTTPS » quand vous posez la question du chiffrement sur les serveurs. C'est soit qu'il n'a pas de chiffrement at-rest, soit qu'il n'a pas pensé au sujet en interne. Les deux sont problématiques.
Et concrètement ?
Pour faire simple, vous devez avoir trois "oui" écrits :
- TLS 1.2+ pour les communications (vérifiable en 5 secondes sur l'URL)
- AES-256 at-rest sur la base, les pièces jointes, et les sauvegardes
- Hashage moderne (bcrypt, argon2) pour les mots de passe utilisateurs
Le chiffrement applicatif par champ est un plus, pas une obligation. Mais s'il est documenté, c'est un signal fort de maturité de l'éditeur.
Trois niveaux de chiffrement, documentés
Aidalys applique TLS 1.3, chiffrement AES-256 at-rest sur base + pièces + sauvegardes, et chiffrement applicatif sur les champs sensibles. Tout est public.
Voir la page sécurité d'Aidalys ↗